draft-ietf-krb-wg-rfc1510ter-02.txt   draft-ietf-krb-wg-rfc1510ter-03.txt 
INTERNET-DRAFT Tom Yu INTERNET-DRAFT Tom Yu
draft-ietf-krb-wg-rfc1510ter-02.txt MIT draft-ietf-krb-wg-rfc1510ter-03.txt MIT
Expires: 26 April 2006 23 October 2005 Expires: 26 Apr 2006 23 October 2006
The Kerberos Network Authentication Service (Version 5) The Kerberos Network Authentication Service (Version 5)
Status of This Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2006). All Rights Reserved.
Abstract Abstract
This document describes version 5 of the Kerberos network This document describes version 5 of the Kerberos network
authentication protocol. It describes a framework to allow for authentication protocol. It describes a framework to allow for
extensions to be made to the protocol without creating extensions to be made to the protocol without creating
interoperability problems. interoperability problems.
Key Words for Requirements Key Words for Requirements
skipping to change at page 2, line 16 skipping to change at page 2, line 16
Status of This Memo .............................................. 1 Status of This Memo .............................................. 1
Copyright Notice ................................................. 1 Copyright Notice ................................................. 1
Abstract ......................................................... 1 Abstract ......................................................... 1
Key Words for Requirements ....................................... 1 Key Words for Requirements ....................................... 1
Table of Contents ................................................ 2 Table of Contents ................................................ 2
1. Introduction ................................................. 5 1. Introduction ................................................. 5
1.1. Kerberos Protocol Overview ................................. 5 1.1. Kerberos Protocol Overview ................................. 5
1.2. Document Organization ...................................... 6 1.2. Document Organization ...................................... 6
2. Compatibility Considerations ................................. 6 2. Compatibility Considerations ................................. 6
2.1. Extensibility .............................................. 6 2.1. Extensibility .............................................. 7
2.2. Compatibility with RFC 1510 ................................ 7 2.2. Compatibility with RFC 1510 ................................ 7
2.3. Backwards Compatibility .................................... 7 2.3. Backwards Compatibility .................................... 7
2.4. Sending Extensible Messages ................................ 8 2.4. Sending Extensible Messages ................................ 8
2.5. Criticality ................................................ 8 2.5. Criticality ................................................ 8
2.6. Authenticating Cleartext Portions of Messages .............. 9 2.6. Authenticating Cleartext Portions of Messages .............. 9
2.7. Capability Negotiation ..................................... 10 2.7. Capability Negotiation ..................................... 10
3. Use of ASN.1 in Kerberos ..................................... 10 2.7.1. KDC protocol ............................................. 10
3.1. Module Header .............................................. 11 2.7.2. Application protocol ..................................... 11
3.2. Top-Level Type ............................................. 11 2.8. Strings .................................................... 11
3.3. Previously Unused ASN.1 Notation (informative) ............. 12 3. Use of ASN.1 in Kerberos ..................................... 11
3.3.1. Parameterized Types ...................................... 12 3.1. Module Header .............................................. 12
3.3.2. Constraints .............................................. 12 3.2. Top-Level Type ............................................. 12
3.4. New Types .................................................. 12 3.3. Previously Unused ASN.1 Notation (informative) ............. 13
4. Basic Types .................................................. 12 3.3.1. Parameterized Types ...................................... 13
4.1. Constrained Integer Types .................................. 12 3.3.2. Constraints .............................................. 13
4.2. KerberosTime ............................................... 13 3.4. New Types .................................................. 13
4.3. KerberosString ............................................. 14 4. Basic Types .................................................. 14
4.4. Language Tags .............................................. 14 4.1. Constrained Integer Types .................................. 14
4.5. KerberosFlags .............................................. 14 4.2. KerberosTime ............................................... 15
4.6. Typed Holes ................................................ 15 4.3. KerberosString ............................................. 15
4.7. HostAddress and HostAddresses .............................. 15 4.4. Language Tags .............................................. 16
4.7.1. Internet (IPv4) Addresses ................................ 16 4.5. KerberosFlags .............................................. 16
4.7.2. Internet (IPv6) Addresses ................................ 16 4.6. Typed Holes ................................................ 17
4.7.3. DECnet Phase IV addresses ................................ 17 4.7. HostAddress and HostAddresses .............................. 17
4.7.4. Netbios addresses ........................................ 17 4.7.1. Internet (IPv4) Addresses ................................ 18
4.7.5. Directional Addresses .................................... 17 4.7.2. Internet (IPv6) Addresses ................................ 18
5. Principals ................................................... 17 4.7.3. DECnet Phase IV addresses ................................ 18
5.1. Name Types ................................................. 17 4.7.4. Netbios addresses ........................................ 18
5.2. Principal Type Definition .................................. 18 4.7.5. Directional Addresses .................................... 18
5.3. Principal Name Reuse ....................................... 19 5. Principals ................................................... 19
5.1. Name Types ................................................. 19
5.2. Principal Type Definition .................................. 20
5.3. Principal Name Reuse ....................................... 21
5.4. Best Common Practice Recommendations for the Processing 5.4. Best Common Practice Recommendations for the Processing
of Principal Names Consisting of Internationalized of Principal Names Consisting of Internationalized
Domain Names: ........................................... 19 Domain Names: .......................................... 21
5.5. Realm Names ................................................ 20 5.5. Realm Names ................................................ 22
5.6. Best Common Practice Recommendations for the Processing 5.6. Best Common Practice Recommendations for the Processing
of Internationalized Domain-Style Realm Names: .......... 20 of Internationalized Domain-Style Realm Names: ......... 22
5.7. Printable Representations of Principal Names ............... 21 5.7. Printable Representations of Principal Names ............... 23
5.8. Ticket-Granting Service Principal .......................... 21 5.8. Ticket-Granting Service Principal .......................... 23
5.8.1. Cross-Realm TGS Principals ............................... 22 5.8.1. Cross-Realm TGS Principals ............................... 24
6. Types Relating to Encryption ................................. 22 6. Types Relating to Encryption ................................. 24
6.1. Assigned Numbers for Encryption ............................ 22 6.1. Assigned Numbers for Encryption ............................ 24
6.1.1. EType .................................................... 22 6.1.1. EType .................................................... 24
6.1.2. Key Usages ............................................... 23 6.1.2. Key Usages ............................................... 25
6.2. Which Key to Use ........................................... 24 6.2. Which Key to Use ........................................... 26
6.3. EncryptionKey .............................................. 25 6.3. EncryptionKey .............................................. 27
6.4. EncryptedData .............................................. 25 6.4. EncryptedData .............................................. 27
6.5. Checksums .................................................. 26 6.5. Checksums .................................................. 28
6.5.1. ChecksumOf ............................................... 27 6.5.1. ChecksumOf ............................................... 29
6.5.2. Signed ................................................... 28 6.5.2. Signed ................................................... 30
7. Tickets ...................................................... 28 7. Tickets ...................................................... 30
7.1. Timestamps ................................................. 29 7.1. Timestamps ................................................. 31
7.2. Ticket Flags ............................................... 30 7.2. Ticket Flags ............................................... 32
7.2.1. Flags Relating to Initial Ticket Acquisition ............. 30 7.2.1. Flags Relating to Initial Ticket Acquisition ............. 32
7.2.2. Invalid Tickets .......................................... 31 7.2.2. Invalid Tickets .......................................... 33
7.2.3. OK as Delegate ........................................... 31 7.2.3. OK as Delegate ........................................... 33
7.2.4. Renewable Tickets ........................................ 32 7.2.4. Renewable Tickets ........................................ 34
7.2.5. Postdated Tickets ........................................ 32 7.2.5. Postdated Tickets ........................................ 34
7.2.6. Proxiable and Proxy Tickets .............................. 33 7.2.6. Proxiable and Proxy Tickets .............................. 35
7.2.7. Forwarded and Forwardable Tickets ........................ 34 7.2.7. Forwarded and Forwardable Tickets ........................ 36
7.3. Transited Realms ........................................... 35 7.3. Transited Realms ........................................... 37
7.4. Authorization Data ......................................... 35 7.4. Authorization Data ......................................... 37
7.4.1. AD-IF-RELEVANT ........................................... 36 7.4.1. AD-IF-RELEVANT ........................................... 38
7.4.2. AD-KDCIssued ............................................. 37 7.4.2. AD-KDCIssued ............................................. 39
7.4.3. AD-AND-OR ................................................ 38 7.4.3. AD-AND-OR ................................................ 40
7.4.4. AD-MANDATORY-FOR-KDC ..................................... 38 7.4.4. AD-MANDATORY-FOR-KDC ..................................... 40
7.5. Encrypted Part of Ticket ................................... 39 7.5. Encrypted Part of Ticket ................................... 41
7.6. Cleartext Part of Ticket ................................... 39 7.6. Cleartext Part of Ticket ................................... 41
8. Credential Acquisition ....................................... 41 8. Credential Acquisition ....................................... 43
8.1. KDC-REQ .................................................... 41 8.1. KDC-REQ .................................................... 43
8.2. PA-DATA .................................................... 48 8.2. PA-DATA .................................................... 50
8.3. KDC-REQ Processing ......................................... 48 8.3. KDC-REQ Processing ......................................... 50
8.3.1. Handling Replays ......................................... 48 8.3.1. Handling Replays ......................................... 50
8.3.2. Request Validation ....................................... 49 8.3.2. Request Validation ....................................... 51
8.3.2.1. AS-REQ Authentication .................................. 49 8.3.2.1. AS-REQ Authentication .................................. 51
8.3.2.2. TGS-REQ Authentication ................................. 49 8.3.2.2. TGS-REQ Authentication ................................. 51
8.3.2.3. Principal Validation ................................... 49 8.3.2.3. Principal Validation ................................... 51
8.3.2.4. Checking For Revoked or Invalid Tickets ................ 49 8.3.2.4. Checking For Revoked or Invalid Tickets ................ 51
8.3.3. Timestamp Handling ....................................... 50 8.3.3. Timestamp Handling ....................................... 52
8.3.3.1. AS-REQ Timestamp Processing ............................ 50 8.3.3.1. AS-REQ Timestamp Processing ............................ 52
8.3.3.2. TGS-REQ Timestamp Processing ........................... 51 8.3.3.2. TGS-REQ Timestamp Processing ........................... 53
8.3.4. Handling Transited Realms ................................ 52 8.3.4. Handling Transited Realms ................................ 54
8.3.5. Address Processing ....................................... 52 8.3.5. Address Processing ....................................... 54
8.3.6. Ticket Flag Processing ................................... 52 8.3.6. Ticket Flag Processing ................................... 54
8.3.7. Key Selection ............................................ 54 8.3.7. Key Selection ............................................ 56
8.3.7.1. Reply Key and Session Key Selection .................... 54 8.3.7.1. Reply Key and Session Key Selection .................... 56
8.3.7.2. Ticket Key Selection ................................... 54 8.3.7.2. Ticket Key Selection ................................... 56
8.4. KDC-REP .................................................... 54 8.4. KDC-REP .................................................... 56
8.5. Reply Validation ........................................... 58 8.5. Reply Validation ........................................... 60
8.6. IP Transports .............................................. 58 8.6. IP Transports .............................................. 60
8.6.1. UDP/IP transport ......................................... 58 8.6.1. UDP/IP transport ......................................... 60
8.6.2. TCP/IP transport ......................................... 58 8.6.2. TCP/IP transport ......................................... 60
8.6.3. KDC Discovery on IP Networks ............................. 60 8.6.3. KDC Discovery on IP Networks ............................. 62
8.6.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names ..... 60 8.6.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names ..... 62
8.6.3.2. DNS SRV records for KDC location ....................... 60 8.6.3.2. DNS SRV records for KDC location ....................... 62
8.6.3.3. KDC Discovery for Domain Style Realm Names on IP 8.6.3.3. KDC Discovery for Domain Style Realm Names on IP
Networks ............................................ 61 Networks ............................................ 63
9. Errors ....................................................... 61 9. Errors ....................................................... 63
10. Session Key Exchange ........................................ 63 10. Session Key Exchange ........................................ 65
10.1. AP-REQ .................................................... 64 10.1. AP-REQ .................................................... 66
10.2. AP-REP .................................................... 65 10.2. AP-REP .................................................... 67
11. Session Key Use ............................................. 67 11. Session Key Use ............................................. 69
11.1. KRB-SAFE .................................................. 67 11.1. KRB-SAFE .................................................. 69
11.2. KRB-PRIV .................................................. 67 11.2. KRB-PRIV .................................................. 69
11.3. KRB-CRED .................................................. 68 11.3. KRB-CRED .................................................. 70
12. Security Considerations ..................................... 69 12. Security Considerations ..................................... 71
12.1. Time Synchronization ...................................... 69 12.1. Time Synchronization ...................................... 71
12.2. Replays ................................................... 69 12.2. Replays ................................................... 71
12.3. Principal Name Reuse ...................................... 70 12.3. Principal Name Reuse ...................................... 72
12.4. Password Guessing ......................................... 70 12.4. Password Guessing ......................................... 72
12.5. Forward Secrecy ........................................... 70 12.5. Forward Secrecy ........................................... 72
12.6. Authorization ............................................. 70 12.6. Authorization ............................................. 72
12.7. Login Authentication ...................................... 70 12.7. Login Authentication ...................................... 72
13. IANA Considerations ......................................... 70 13. IANA Considerations ......................................... 72
14. Acknowledgments ............................................. 71 14. Acknowledgments ............................................. 73
Appendices ....................................................... 71 Appendices ....................................................... 73
A. ASN.1 Module (Normative) ..................................... 71 A. ASN.1 Module (Normative) ..................................... 73
B. Kerberos and Character Encodings (Informative) ...............103 B. Kerberos and Character Encodings (Informative) ...............105
C. Kerberos History (Informative) ...............................104 C. Kerberos History (Informative) ...............................107
D. Notational Differences from [KCLAR] ..........................105 D. Notational Differences from [KCLAR] ..........................107
Normative References .............................................106 Normative References .............................................108
Informative References ...........................................106 Informative References ...........................................109
Author's Address .................................................108 Author's Address .................................................110
Copyright Statement ..............................................108 Copyright Statement ..............................................110
Intellectual Property Statement ..................................108 Intellectual Property Statement ..................................110
1. Introduction 1. Introduction
The Kerberos network authentication protocol is a trusted-third-party The Kerberos network authentication protocol is a trusted-third-party
protocol utilizing symmetric-key cryptography. It assumes that all protocol utilizing symmetric-key cryptography. It assumes that all
communications between parties in the protocol may be arbitrarily communications between parties in the protocol may be arbitrarily
tampered with or monitored, and that the security of the overall tampered with or monitored, and that the security of the overall
system depends only on the effectiveness of the cryptographic system depends only on the effectiveness of the cryptographic
techniques and the secrecy of the cryptographic keys used. The techniques and the secrecy of the cryptographic keys used. The
Kerberos protocol authenticates an application client's identity to Kerberos protocol authenticates an application client's identity to
skipping to change at page 7, line 55 skipping to change at page 8, line 5
Implementations sending new messages MUST ensure that the recipient Implementations sending new messages MUST ensure that the recipient
supports these new messages. Along with each extensible message is a supports these new messages. Along with each extensible message is a
guideline for when that message MAY be used. If that guideline is guideline for when that message MAY be used. If that guideline is
followed, then the recipient is guaranteed to understand the message. followed, then the recipient is guaranteed to understand the message.
2.3. Backwards Compatibility 2.3. Backwards Compatibility
This document describes two sets (for the most part) of ASN.1 types. This document describes two sets (for the most part) of ASN.1 types.
The first set of types is wire-encoding compatible with RFC 1510 and The first set of types is wire-encoding compatible with RFC 1510 and
[KCLAR]. The second set of types is the set of types enabling [KCLAR]. The second set of types is the set of types enabling
extensibility. This second set may be referred to as "extensibility- extensibility. This second set may be referred to as
enabled types". [ need to make this consistent throughout? ] "extensibility-enabled types". [ need to make this consistent
throughout? ]
A major difference between the new extensibility-enabled types and A major difference between the new extensibility-enabled types and
the types for RFC 1510 compatibility is that the extensibility- the types for RFC 1510 compatibility is that the extensibility-
enabled types allow for the use of UTF-8 encodings in various enabled types allow for the use of UTF-8 encodings in various
character strings in the protocol. Each party in the protocol must character strings in the protocol. Each party in the protocol must
have some knowledge of the capabilities of the other parties in the have some knowledge of the capabilities of the other parties in the
protocol. There are methods for establishing this knowledge without protocol. There are methods for establishing this knowledge without
necessarily requiring explicit configuration. necessarily requiring explicit configuration.
An extensibility-enabled client can detect whether a KDC supports the An extensibility-enabled client can detect whether a KDC supports the
skipping to change at page 9, line 52 skipping to change at page 9, line 53
The extensible variants of the messages described in this document The extensible variants of the messages described in this document
wrap the actual message in an ASN.1 sequence containing a keyed wrap the actual message in an ASN.1 sequence containing a keyed
checksum of the contents of the message. Guidelines in [XXX] section checksum of the contents of the message. Guidelines in [XXX] section
3 specify when the checksum MUST be included and what key MUST be 3 specify when the checksum MUST be included and what key MUST be
used. Guidelines on when to include a checksum are never ambiguous: used. Guidelines on when to include a checksum are never ambiguous:
a particular PDU is never correct both with and without a checksum. a particular PDU is never correct both with and without a checksum.
With the exception of the KRB-ERROR message, receiving With the exception of the KRB-ERROR message, receiving
implementations MUST reject messages where a checksum is included and implementations MUST reject messages where a checksum is included and
not expected or where a checksum is expected but not included. The not expected or where a checksum is expected but not included. The
receiving implementation does not always have sufficient information receiving implementation does not always have sufficient information
to know whether a KRB-ERROR should contain a checksum. Even so, KRB- to know whether a KRB-ERROR should contain a checksum. Even so,
ERROR messages with invalid checksums MUST be rejected and KRB-ERROR messages with invalid checksums MUST be rejected and
implementations MAY consider the presence or absence of a checksum implementations MAY consider the presence or absence of a checksum
when evaluating whether to trust the error. when evaluating whether to trust the error.
This authenticated cleartext protection is provided only in the This authenticated cleartext protection is provided only in the
extensible variants of the messages; it is never used when extensible variants of the messages; it is never used when
communicating with an RFC 1510 implementation. communicating with an RFC 1510 implementation.
2.7. Capability Negotiation 2.7. Capability Negotiation
Kerberos is a three-party protocol. Each of the three parties Kerberos is a three-party protocol. Each of the three parties
skipping to change at page 10, line 38 skipping to change at page 10, line 40
Client software advertizes its capabilities when requesting Client software advertizes its capabilities when requesting
credentials from the KDC. If the KDC recognizes the capabilities, it credentials from the KDC. If the KDC recognizes the capabilities, it
acknowledges this fact to the client in its reply. In addition, if acknowledges this fact to the client in its reply. In addition, if
the KDC has knowledge that the application server supports certain the KDC has knowledge that the application server supports certain
capabilities, it also communicates this knowledge to the client in capabilities, it also communicates this knowledge to the client in
its reply. The KDC can encode its own capabilities in the ticket so its reply. The KDC can encode its own capabilities in the ticket so
that the application server may discover these capabilities. The that the application server may discover these capabilities. The
client advertizes its capabilities to the application server when it client advertizes its capabilities to the application server when it
initiates authentication to the application server. initiates authentication to the application server.
2.7.1. KDC protocol
A client may send an AS-REQ-EXT if it has prior knowledge that the
KDC in question will accept it. (possibly via a TCP extension?)
Otherwise, the client will send an AS-REQ-1510 with the AS-REQ-EXT
inside preauthentication data. The client will always know whether
to send TGS-REQ-EXT because (as in the application protocol) it knows
the type of the associated Ticket. (Note: could be a problem with
non-TGT tickets)
The KDC will send AS-REP-EXT or TGS-REP-EXT if the client's message
is extensible; otherwise, it will send AS-REP-1510 or TGS-REP-1510.
The Ticket contained within the AS-REP-EXT or TGS-REP-EXT will be a
TicketExt if the application server supports it; otherwise, it will
be a Ticket1510. AS-REP-1510 and TGS-REP-1510 always contain a
Ticket1510. The EncTicketPart will depend on the server's
capability; the client cannot distinguish EncTicketPart1510 from
EncTicketPartExt.
KDCs within a realm should be uniform in advertized capability for
extensible messages. A KDC SHOULD only issue a TicketExt TGT if all
KDCs support it. Similarly, a client receiving a TicketExt knows
that all instances of the application service will accept extensible
messages.
2.7.2. Application protocol
The client knows whether the application server supports AP-REQ-EXT
because it can distinguish Ticket1510 from TicketExt. The server
knows the client's capability due to the format of the AP-REQ.
2.8. Strings
Some implementations of RFC 1510 do not limit princpal names and
realm names to ASCII characters. As a result, migration difficulties
resulting from legacy non-ASCII principal and realm names can arise.
Is it reasonable to assume that any legacy non-ASCII character can be
uniquely represented in Unicode?
This may result in a situation where various parties of the protocol
need to know alternate, possibly multiple, legacy non-ASCII names for
principals and also to know how they map into Unicode. An
application server needs to know all possible legacy encodings of its
name if it receives a "mixed" ticket. (Ticket1510 containing
EncTicketPartExt) It also needs to be able to compare a legacy
encoding of a client principal against the normalized UTF-8 encoding
when checking the client's principal name in the Authenticator
against the one contained in the EncTicketPart. This check can be
avoided if the application protocol does not require a replay cache.
3. Use of ASN.1 in Kerberos 3. Use of ASN.1 in Kerberos
Kerberos uses the ASN.1 Distinguished Encoding Rules (DER) [X690]. Kerberos uses the ASN.1 Distinguished Encoding Rules (DER) [X690].
Even though ASN.1 theoretically allows the description of protocol Even though ASN.1 theoretically allows the description of protocol
messages to be independent of the encoding rules used to encode the messages to be independent of the encoding rules used to encode the
messages, Kerberos messages MUST be encoded with DER. Subtleties in messages, Kerberos messages MUST be encoded with DER. Subtleties in
the semantics of the notation, such as whether tags carry any the semantics of the notation, such as whether tags carry any
semantic content to the application, may cause the use of other ASN.1 semantic content to the application, may cause the use of other ASN.1
encoding rules to be problematic. encoding rules to be problematic.
skipping to change at page 16, line 15 skipping to change at page 17, line 45
This field specifies the type of address that follows. This field specifies the type of address that follows.
address address
This field encodes a single address of the type identified by This field encodes a single address of the type identified by
"addr-type". "addr-type".
All negative values for the host address type are reserved for local All negative values for the host address type are reserved for local
use. All non-negative values are reserved for officially assigned use. All non-negative values are reserved for officially assigned
type fields and interpretations. type fields and interpretations.
|
addr-type | meaning addr-type | meaning
-----------+-------------- __________|______________
2 | IPv4 2 | IPv4
3 | directional 3 | directional
12 | DECnet 12 | DECnet
20 | NetBIOS 20 | NetBIOS
24 | IPv6 24 | IPv6
4.7.1. Internet (IPv4) Addresses 4.7.1. Internet (IPv4) Addresses
Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in
MSB order (most significant byte first). The IPv4 loopback address MSB order (most significant byte first). The IPv4 loopback address
skipping to change at page 16, line 49 skipping to change at page 18, line 30
* the Loopback Address * the Loopback Address
* Link-Local addresses * Link-Local addresses
This restriction applies to the inclusion in the address fields of This restriction applies to the inclusion in the address fields of
Kerberos PDUs, but not to the address fields of packets that might Kerberos PDUs, but not to the address fields of packets that might
carry such PDUs. The restriction is necessary because the use of an carry such PDUs. The restriction is necessary because the use of an
address with non-global scope could allow the acceptance of a message address with non-global scope could allow the acceptance of a message
sent from a node that may have the same address, but which is not the sent from a node that may have the same address, but which is not the
host intended by the entity that added the restriction. If the link- host intended by the entity that added the restriction. If the
local address type needs to be used for communication, then the link-local address type needs to be used for communication, then the
address restriction in tickets must not be used (i.e. addressless address restriction in tickets must not be used (i.e. addressless
tickets must be used). tickets must be used).
IPv4-mapped IPv6 addresses MUST be represented as addresses of type IPv4-mapped IPv6 addresses MUST be represented as addresses of type
2. 2.
4.7.3. DECnet Phase IV addresses 4.7.3. DECnet Phase IV addresses
DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order. DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order.
The type of DECnet Phase IV addresses is twelve (12). The type of DECnet Phase IV addresses is twelve (12).
skipping to change at page 21, line 20 skipping to change at page 23, line 17
component will be converted from the ACE representation to component will be converted from the ACE representation to
Unicode [need reference] Unicode [need reference]
o if the component consists of one or more internationalized o if the component consists of one or more internationalized
characters separately apply the NamePrep and SASLprep string characters separately apply the NamePrep and SASLprep string
preparation methods. preparation methods.
if the output of the two methods match, continue on to the if the output of the two methods match, continue on to the
next component; otherwise reject the realm name as invalid next component; otherwise reject the realm name as invalid
- - the result of a valid realm name is the joining of the
the result of a valid realm name is the joining of the
individual string prepared components separated by the Full individual string prepared components separated by the Full
Stop (0x002E) Stop (0x002E)
In [KCLAR], the recommendation is that all domain style realm names In [KCLAR], the recommendation is that all domain style realm names
be represented in uppercase. This recommendation is modified in the be represented in uppercase. This recommendation is modified in the
following manner. All components of domain style realm names not following manner. All components of domain style realm names not
including internationalized characters should be upper-cased. All including internationalized characters should be upper-cased. All
components of domain style realm names including internationalized components of domain style realm names including internationalized
characters must be lower-cased. (The lower case representation of characters must be lower-cased. (The lower case representation of
internationalized components is enforced by the requirement that the internationalized components is enforced by the requirement that the
skipping to change at page 24, line 31 skipping to change at page 26, line 31
ku-Authenticator-cksum KeyUsage ::= 10 ku-Authenticator-cksum KeyUsage ::= 10
ku-APReq-authenticator KeyUsage ::= 11 ku-APReq-authenticator KeyUsage ::= 11
ku-EncAPRepPart KeyUsage ::= 12 ku-EncAPRepPart KeyUsage ::= 12
ku-EncKrbPrivPart KeyUsage ::= 13 ku-EncKrbPrivPart KeyUsage ::= 13
ku-EncKrbCredPart KeyUsage ::= 14 ku-EncKrbCredPart KeyUsage ::= 14
ku-KrbSafe-cksum KeyUsage ::= 15 ku-KrbSafe-cksum KeyUsage ::= 15
ku-ad-KDCIssued-cksum KeyUsage ::= 19 ku-ad-KDCIssued-cksum KeyUsage ::= 19
-- The following numbers are provisional... -- The following numbers are provisional...
-- conflicts may exist elsewhere. -- conflicts may exist elsewhere.
ku-Ticket-cksum KeyUsage ::= 25 ku-Ticket-cksum KeyUsage ::= 29
ku-ASReq-cksum KeyUsage ::= 26 ku-ASReq-cksum KeyUsage ::= 30
ku-TGSReq-cksum KeyUsage ::= 27 ku-TGSReq-cksum KeyUsage ::= 31
ku-ASRep-cksum KeyUsage ::= 28 ku-ASRep-cksum KeyUsage ::= 32
ku-TGSRep-cksum KeyUsage ::= 29 ku-TGSRep-cksum KeyUsage ::= 33
ku-APReq-cksum KeyUsage ::= 30 ku-APReq-cksum KeyUsage ::= 34
ku-APRep-cksum KeyUsage ::= 31 ku-APRep-cksum KeyUsage ::= 35
ku-KrbCred-cksum KeyUsage ::= 32 ku-KrbCred-cksum KeyUsage ::= 36
ku-KrbError-cksum KeyUsage ::= 33 ku-KrbError-cksum KeyUsage ::= 37
ku-KDCRep-cksum KeyUsage ::= 34 ku-KDCRep-cksum KeyUsage ::= 38
ku-kg-acceptor-seal KeyUsage ::= 22
ku-kg-acceptor-sign KeyUsage ::= 23
ku-kg-intiator-seal KeyUsage ::= 24
ku-kg-intiator-sign KeyUsage ::= 25
-- KeyUsage values 25..27 used by hardware preauth?
-- for KINK
ku-kink-encrypt KeyUsage ::= 39
ku-kink-cksum KeyUsage ::= 40
6.2. Which Key to Use 6.2. Which Key to Use
-- KeyToUse identifies which key is to be used to encrypt or -- KeyToUse identifies which key is to be used to encrypt or
-- sign a given value. -- sign a given value.
-- --
-- Values of KeyToUse are never actually transmitted over the -- Values of KeyToUse are never actually transmitted over the
-- wire, or even used directly by the implementation in any -- wire, or even used directly by the implementation in any
-- way, as key usages are; it exists primarily to identify -- way, as key usages are; it exists primarily to identify
-- which key gets used for what purpose. Thus, the specific -- which key gets used for what purpose. Thus, the specific
-- numeric values associated with this type are irrelevant. -- numeric values associated with this type are irrelevant.
KeyToUse ::= ENUMERATED { KeyToUse ::= ENUMERATED {
-- unspecified -- unspecified
skipping to change at page 36, line 34 skipping to change at page 38, line 34
authorization data element modifying the criticality of the elements authorization data element modifying the criticality of the elements
it contains, an application server MUST reject the authentication of it contains, an application server MUST reject the authentication of
a client whose AP-REQ or ticket contains an unrecognized a client whose AP-REQ or ticket contains an unrecognized
authorization data element. Authorization data is intended to authorization data element. Authorization data is intended to
restrict the use of a ticket. If the service cannot determine restrict the use of a ticket. If the service cannot determine
whether it is the target of a restriction, a security weakness may whether it is the target of a restriction, a security weakness may
exist if the ticket can be used for that service. Authorization exist if the ticket can be used for that service. Authorization
elements that are truly optional can be enclosed in AD-IF-RELEVANT elements that are truly optional can be enclosed in AD-IF-RELEVANT
element. element.
|
ad-type | contents of ad-data ad-type | contents of ad-data
---------+--------------------------------------- ________|_______________________________________
1 | DER encoding of AD-IF-RELEVANT 1 | DER encoding of AD-IF-RELEVANT
4 | DER encoding of AD-KDCIssued 4 | DER encoding of AD-KDCIssued
5 | DER encoding of AD-AND-OR 5 | DER encoding of AD-AND-OR
8 | DER encoding of AD-MANDATORY-FOR-KDC 8 | DER encoding of AD-MANDATORY-FOR-KDC
7.4.1. AD-IF-RELEVANT 7.4.1. AD-IF-RELEVANT
ad-if-relevant ADType ::= int32 : 1 ad-if-relevant ADType ::= int32 : 1
-- Encapsulates another AuthorizationData. -- Encapsulates another AuthorizationData.
skipping to change at page 52, line 29 skipping to change at page 54, line 29
* the value of the "renew-till" value of the old, * the value of the "renew-till" value of the old,
* the "starttime" of the new ticket plus the lifetime (endtime * the "starttime" of the new ticket plus the lifetime (endtime
minus starttime) of the old ticket, i.e., the lifetime of the minus starttime) of the old ticket, i.e., the lifetime of the
new ticket may not exceed that of the ticket being renewed [ new ticket may not exceed that of the ticket being renewed [
adapted from KCLAR 3.3.3. ], and adapted from KCLAR 3.3.3. ], and
* an "endtime" determined by site policy on ticket lifetimes. * an "endtime" determined by site policy on ticket lifetimes.
When handling a TGS-REQ, a KDC MUST NOT issue a postdated ticket with When handling a TGS-REQ, a KDC MUST NOT issue a postdated ticket with
a "starttime", "endtime", or "renew-till" time later than the "renew- a "starttime", "endtime", or "renew-till" time later than the
till" time of the TGT. "renew-till" time of the TGT.
8.3.4. Handling Transited Realms 8.3.4. Handling Transited Realms
The KDC checks the ticket in a TGS-REQ against site policy, unless The KDC checks the ticket in a TGS-REQ against site policy, unless
the "disable-transited-check" option is set in the TGS-REQ. If site the "disable-transited-check" option is set in the TGS-REQ. If site
policy permits the transit path in the TGS-REQ ticket, the KDC sets policy permits the transit path in the TGS-REQ ticket, the KDC sets
the "transited-policy-checked" flag in the issued ticket. If the the "transited-policy-checked" flag in the issued ticket. If the
"disable-transited-check" option is set, the issued ticket will have "disable-transited-check" option is set, the issued ticket will have
the "transited-policy-checked" flag cleared. the "transited-policy-checked" flag cleared.
skipping to change at page 53, line 12 skipping to change at page 55, line 12
The "proxy" option will not be honored on requests for additional The "proxy" option will not be honored on requests for additional
ticket-granting tickets. ticket-granting tickets.
8.3.6. Ticket Flag Processing 8.3.6. Ticket Flag Processing
Many kdc-options request that the KDC set a corresponding flag in the Many kdc-options request that the KDC set a corresponding flag in the
issued ticket. kdc-options marked with an asterisk (*) in the issued ticket. kdc-options marked with an asterisk (*) in the
following table do not directly request the corresponding ticket flag following table do not directly request the corresponding ticket flag
and therefore require special handling. and therefore require special handling.
|
kdc-option | ticket flag affected kdc-option | ticket flag affected
-------------------------+-------------------------- ________________________|__________________________
forwardable | forwardable forwardable | forwardable
forwarded | forwarded forwarded | forwarded
proxiable | proxiable proxiable | proxiable
proxy | proxy proxy | proxy
allow-postdate | may-postdate allow-postdate | may-postdate
postdated | postdated postdated | postdated
renewable | renewable renewable | renewable
requestanonymous | anonymous requestanonymous | anonymous
canonicalize | - canonicalize | -
disable-transited-check* | transited-policy-checked disable-transited-check* | transited-policy-checked
skipping to change at page 64, line 4 skipping to change at page 66, line 6
extensible KRB-ERROR. extensible KRB-ERROR.
TDType ::= TH-id TDType ::= TH-id
TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
data-type [0] TDType, data-type [0] TDType,
data-value [1] OCTET STRING OPTIONAL data-value [1] OCTET STRING OPTIONAL
} }
10. Session Key Exchange 10. Session Key Exchange
Session key exchange consists of the AP-REQ and AP-REP messages. The Session key exchange consists of the AP-REQ and AP-REP messages. The
client sends the AP-REQ message, and the service responds with an AP- client sends the AP-REQ message, and the service responds with an
REP message if mutual authentication is desired. Following session AP-REP message if mutual authentication is desired. Following
key exchange, the client and service share a secret session key, or session key exchange, the client and service share a secret session
possibly a subsesion key, which can be used to protect further key, or possibly a subsesion key, which can be used to protect
communications. Additionally, the session key exchange process can further communications. Additionally, the session key exchange
establish initial sequence numbers which the client and service can process can establish initial sequence numbers which the client and
use to detect replayed messages. service can use to detect replayed messages.
10.1. AP-REQ 10.1. AP-REQ
An AP-REQ message contains a ticket and a authenticator. The An AP-REQ message contains a ticket and a authenticator. The
authenticator is ciphertext encrypted with the session key contained authenticator is ciphertext encrypted with the session key contained
in the ticket. The plaintext contents of the authenticator are: in the ticket. The plaintext contents of the authenticator are:
-- plaintext of authenticator -- plaintext of authenticator
Authenticator1510 ::= [APPLICATION 2] SEQUENCE { Authenticator1510 ::= [APPLICATION 2] SEQUENCE {
authenticator-vno [0] INTEGER (5), authenticator-vno [0] INTEGER (5),
skipping to change at page 77, line 30 skipping to change at page 79, line 30
ku-Authenticator-cksum KeyUsage ::= 10 ku-Authenticator-cksum KeyUsage ::= 10
ku-APReq-authenticator KeyUsage ::= 11 ku-APReq-authenticator KeyUsage ::= 11
ku-EncAPRepPart KeyUsage ::= 12 ku-EncAPRepPart KeyUsage ::= 12
ku-EncKrbPrivPart KeyUsage ::= 13 ku-EncKrbPrivPart KeyUsage ::= 13
ku-EncKrbCredPart KeyUsage ::= 14 ku-EncKrbCredPart KeyUsage ::= 14
ku-KrbSafe-cksum KeyUsage ::= 15 ku-KrbSafe-cksum KeyUsage ::= 15
ku-ad-KDCIssued-cksum KeyUsage ::= 19 ku-ad-KDCIssued-cksum KeyUsage ::= 19
-- The following numbers are provisional... -- The following numbers are provisional...
-- conflicts may exist elsewhere. -- conflicts may exist elsewhere.
ku-Ticket-cksum KeyUsage ::= 25 ku-Ticket-cksum KeyUsage ::= 29
ku-ASReq-cksum KeyUsage ::= 26 ku-ASReq-cksum KeyUsage ::= 30
ku-TGSReq-cksum KeyUsage ::= 27 ku-TGSReq-cksum KeyUsage ::= 31
ku-ASRep-cksum KeyUsage ::= 28 ku-ASRep-cksum KeyUsage ::= 32
ku-TGSRep-cksum KeyUsage ::= 29 ku-TGSRep-cksum KeyUsage ::= 33
ku-APReq-cksum KeyUsage ::= 30 ku-APReq-cksum KeyUsage ::= 34
ku-APRep-cksum KeyUsage ::= 31 ku-APRep-cksum KeyUsage ::= 35
ku-KrbCred-cksum KeyUsage ::= 32 ku-KrbCred-cksum KeyUsage ::= 36
ku-KrbError-cksum KeyUsage ::= 33 ku-KrbError-cksum KeyUsage ::= 37
ku-KDCRep-cksum KeyUsage ::= 34 ku-KDCRep-cksum KeyUsage ::= 38
ku-kg-acceptor-seal KeyUsage ::= 22
ku-kg-acceptor-sign KeyUsage ::= 23
ku-kg-intiator-seal KeyUsage ::= 24
ku-kg-intiator-sign KeyUsage ::= 25
-- KeyUsage values 25..27 used by hardware preauth?
-- for KINK
ku-kink-encrypt KeyUsage ::= 39
ku-kink-cksum KeyUsage ::= 40
-- KeyToUse identifies which key is to be used to encrypt or -- KeyToUse identifies which key is to be used to encrypt or
-- sign a given value. -- sign a given value.
-- --
-- Values of KeyToUse are never actually transmitted over the -- Values of KeyToUse are never actually transmitted over the
-- wire, or even used directly by the implementation in any -- wire, or even used directly by the implementation in any
-- way, as key usages are; it exists primarily to identify -- way, as key usages are; it exists primarily to identify
-- which key gets used for what purpose. Thus, the specific -- which key gets used for what purpose. Thus, the specific
-- numeric values associated with this type are irrelevant. -- numeric values associated with this type are irrelevant.
KeyToUse ::= ENUMERATED { KeyToUse ::= ENUMERATED {
-- unspecified -- unspecified
skipping to change at page 103, line 32 skipping to change at page 105, line 32
-- Reserved for PKINIT -- Reserved for PKINIT
kdc-err-cant-verify-certificate ErrCode ::= 70 kdc-err-cant-verify-certificate ErrCode ::= 70
-- Reserved for PKINIT -- Reserved for PKINIT
kdc-err-invalid-certificate ErrCode ::= 71 kdc-err-invalid-certificate ErrCode ::= 71
-- Reserved for PKINIT -- Reserved for PKINIT
kdc-err-revoked-certificate ErrCode ::= 72 kdc-err-revoked-certificate ErrCode ::= 72
-- Reserved for PKINIT -- Reserved for PKINIT
kdc-err-revocation-status-unknown ErrCode ::= 73 kdc-err-revocation-status-unknown ErrCode ::= 73
-- Reserved for PKINIT -- Reserved for PKINIT
kdc-err-revocation-status-unavailable ErrCode ::= 74 kdc-err-revocation-status-unavailable ErrCode ::= 74
-- Reserved for PKINIT
kdc-err-client-name-mismatch ErrCode ::= 75
-- Reserved for PKINIT
kdc-err-kdc-name-mismatch ErrCode ::= 76
-- Reserved for PKINIT
kdc-err-inconsistent-key-purpose ErrCode ::= 77
-- Reserved for PKINIT
kdc-err-digest-in-cert-not-accepted ErrCode ::= 78
-- Reserved for PKINIT
kdc-err-pa-checksum-must-be-included ErrCode ::= 79
-- Reserved for PKINIT
kdc-err-digest-in-signed-data-not-accepted ErrCode ::= 80
-- Reserved for PKINIT
kdc-err-public-key-encryption-not-supported ErrCode ::= 81
END END
B. Kerberos and Character Encodings (Informative) B. Kerberos and Character Encodings (Informative)
[adapted from KCLAR 5.2.1] [adapted from KCLAR 5.2.1]
The original specification of the Kerberos protocol in RFC 1510 uses The original specification of the Kerberos protocol in RFC 1510 uses
GeneralString in numerous places for human-readable string data. GeneralString in numerous places for human-readable string data.
Historical implementations of Kerberos cannot utilize the full power Historical implementations of Kerberos cannot utilize the full power
of GeneralString. This ASN.1 type requires the use of designation of GeneralString. This ASN.1 type requires the use of designation
and invocation escape sequences as specified in ISO 2022 | ECMA-35 and invocation escape sequences as specified in ISO 2022 | ECMA-35
[ISO2022] to switch character sets, and the default character set [ISO2022] to switch character sets, and the default character set
that is designated as G0 is the ISO 646 | ECMA-6 [ISO646] that is designated as G0 is the ISO 646 | ECMA-6 [ISO646]
International Reference Version (IRV) (aka U.S. ASCII), which mostly International Reference Version (IRV) (aka U.S. ASCII), which mostly
works. works.
skipping to change at page 107, line 19 skipping to change at page 109, line 30
Distribution Protocols," Communications of the ACM, Vol. 24(8), Distribution Protocols," Communications of the ACM, Vol. 24(8),
pp. 533-536 (August 1981). pp. 533-536 (August 1981).
[Dub00] [Dub00]
Olivier Dubuisson, "ASN.1 - Communication between Heterogeneous Olivier Dubuisson, "ASN.1 - Communication between Heterogeneous
Systems", Elsevier-Morgan Kaufmann, 2000. Systems", Elsevier-Morgan Kaufmann, 2000.
<http://www.oss.com/asn1/dubuisson.html> <http://www.oss.com/asn1/dubuisson.html>
[ISO8859-1] [ISO8859-1]
"Information technology -- 8-bit single-byte coded graphic "Information technology -- 8-bit single-byte coded graphic
character sets -- Part 1: Latin alphabet No. 1", ISO/IEC character sets -- Part 1: Latin alphabet No. 1", ISO/IEC 8859-
8859-1:1998. 1:1998.
[KCLAR] [KCLAR]
Clifford Neuman, Tom Yu, Sam Hartman, Ken Raeburn, "The Kerberos Clifford Neuman, Tom Yu, Sam Hartman, Ken Raeburn, "The Kerberos
Network Authentication Service (V5)", draft-ietf-krb-wg- Network Authentication Service (V5)", draft-ietf-krb-wg-
kerberos-clarifications-07.txt, work in progress. kerberos-clarifications-07.txt, work in progress.
[KNT94] [KNT94]
John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The
Evolution of the Kerberos Authentication System". In Evolution of the Kerberos Authentication System". In
Distributed Open Systems, pages 78-94. IEEE Computer Society Distributed Open Systems, pages 78-94. IEEE Computer Society
skipping to change at page 108, line 21 skipping to change at page 110, line 31
Author's Address Author's Address
Tom Yu Tom Yu
77 Massachusetts Ave 77 Massachusetts Ave
Cambridge, MA 02139 Cambridge, MA 02139
USA USA
tlyu@mit.edu tlyu@mit.edu
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 28 change blocks. 
165 lines changed or deleted 252 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/