draft-ietf-krb-wg-rfc1510ter-03.txt   draft-ietf-krb-wg-rfc1510ter-04.txt 
INTERNET-DRAFT Tom Yu INTERNET-DRAFT Tom Yu
draft-ietf-krb-wg-rfc1510ter-03.txt MIT draft-ietf-krb-wg-rfc1510ter-04.txt MIT
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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 27 skipping to change at page 1, line 25
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
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 (2006). All Rights Reserved. Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes version 5 of the Kerberos network This document specifies version 5 of the Kerberos network
authentication protocol. It describes a framework to allow for authentication protocol. It obsoletes RFC 4120, and in addition to
extensions to be made to the protocol without creating providing a detailed description of the protocol, it describes a
interoperability problems. framework to allow for extensions to be made to the protocol without
creating interoperability problems.
Key Words for Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
to be interpreted as described in RFC 2119.
Table of Contents Table of Contents
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
Table of Contents ................................................ 2 Table of Contents ................................................ 2
1. Introduction ................................................. 5 1. Introduction ................................................. 4
1.1. Kerberos Protocol Overview ................................. 5 1.1. Kerberos Protocol Overview ................................. 4
1.2. Document Organization ...................................... 6 1.2. Document Organization ...................................... 5
2. Compatibility Considerations ................................. 6 2. Compatibility Considerations ................................. 6
2.1. Extensibility .............................................. 7 2.1. Extensibility .............................................. 6
2.2. Compatibility with RFC 1510 ................................ 7 2.2. Compatibility with RFC 1510 ................................ 6
2.3. Backwards Compatibility .................................... 7 2.3. Backwards Compatibility .................................... 6
2.4. Sending Extensible Messages ................................ 8 2.4. Sending Extensible Messages ................................ 7
2.5. Criticality ................................................ 8 2.5. Criticality ................................................ 7
2.6. Authenticating Cleartext Portions of Messages .............. 9 2.6. Authenticating Cleartext Portions of Messages .............. 8
2.7. Capability Negotiation ..................................... 10 2.7. Capability Negotiation ..................................... 9
2.7.1. KDC protocol ............................................. 10 2.8. Strings .................................................... 10
2.7.2. Application protocol ..................................... 11 3. Use of ASN.1 in Kerberos ..................................... 10
2.8. Strings .................................................... 11 3.1. Module Header .............................................. 11
3. Use of ASN.1 in Kerberos ..................................... 11 3.2. Top-Level Type ............................................. 11
3.1. Module Header .............................................. 12 3.3. Previously Unused ASN.1 Notation (informative) ............. 12
3.2. Top-Level Type ............................................. 12 3.4. New Types .................................................. 12
3.3. Previously Unused ASN.1 Notation (informative) ............. 13 4. Basic Types .................................................. 13
3.3.1. Parameterized Types ...................................... 13 4.1. Constrained Integer Types .................................. 13
3.3.2. Constraints .............................................. 13 4.2. KerberosTime ............................................... 14
3.4. New Types .................................................. 13 4.3. KerberosString ............................................. 14
4. Basic Types .................................................. 14 4.4. Language Tags .............................................. 15
4.1. Constrained Integer Types .................................. 14 4.5. KerberosFlags .............................................. 15
4.2. KerberosTime ............................................... 15 4.6. Typed Holes ................................................ 16
4.3. KerberosString ............................................. 15 4.7. HostAddress and HostAddresses .............................. 16
4.4. Language Tags .............................................. 16 5. Principals ................................................... 18
4.5. KerberosFlags .............................................. 16 5.1. Name Types ................................................. 18
4.6. Typed Holes ................................................ 17 5.2. Principal Type Definition .................................. 19
4.7. HostAddress and HostAddresses .............................. 17 5.3. Principal Name Reuse ....................................... 20
4.7.1. Internet (IPv4) Addresses ................................ 18
4.7.2. Internet (IPv6) Addresses ................................ 18
4.7.3. DECnet Phase IV addresses ................................ 18
4.7.4. Netbios addresses ........................................ 18
4.7.5. Directional Addresses .................................... 18
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: .......................................... 21 Domain Names: .......................................... 20
5.5. Realm Names ................................................ 22 5.5. Realm Names ................................................ 21
5.6. Best Common Practice Recommendations for the Processing 5.6. Best Common Practice Recommendations for the Processing
of Internationalized Domain-Style Realm Names: ......... 22 of Internationalized Domain-Style Realm Names: ......... 21
5.7. Printable Representations of Principal Names ............... 23 5.7. Printable Representations of Principal Names ............... 22
5.8. Ticket-Granting Service Principal .......................... 23 5.8. Ticket-Granting Service Principal .......................... 22
5.8.1. Cross-Realm TGS Principals ............................... 24 6. Types Relating to Encryption ................................. 23
6. Types Relating to Encryption ................................. 24 6.1. Assigned Numbers for Encryption ............................ 23
6.1. Assigned Numbers for Encryption ............................ 24
6.1.1. EType .................................................... 24
6.1.2. Key Usages ............................................... 25
6.2. Which Key to Use ........................................... 26 6.2. Which Key to Use ........................................... 26
6.3. EncryptionKey .............................................. 27 6.3. EncryptionKey .............................................. 27
6.4. EncryptedData .............................................. 27 6.4. EncryptedData .............................................. 27
6.5. Checksums .................................................. 28 6.5. Checksums .................................................. 28
6.5.1. ChecksumOf ............................................... 29
6.5.2. Signed ................................................... 30
7. Tickets ...................................................... 30 7. Tickets ...................................................... 30
7.1. Timestamps ................................................. 31 7.1. Timestamps ................................................. 31
7.2. Ticket Flags ............................................... 32 7.2. Ticket Flags ............................................... 32
7.2.1. Flags Relating to Initial Ticket Acquisition ............. 32
7.2.2. Invalid Tickets .......................................... 33
7.2.3. OK as Delegate ........................................... 33
7.2.4. Renewable Tickets ........................................ 34
7.2.5. Postdated Tickets ........................................ 34
7.2.6. Proxiable and Proxy Tickets .............................. 35
7.2.7. Forwarded and Forwardable Tickets ........................ 36
7.3. Transited Realms ........................................... 37 7.3. Transited Realms ........................................... 37
7.4. Authorization Data ......................................... 37 7.4. Authorization Data ......................................... 37
7.4.1. AD-IF-RELEVANT ........................................... 38
7.4.2. AD-KDCIssued ............................................. 39
7.4.3. AD-AND-OR ................................................ 40
7.4.4. AD-MANDATORY-FOR-KDC ..................................... 40
7.5. Encrypted Part of Ticket ................................... 41 7.5. Encrypted Part of Ticket ................................... 41
7.6. Cleartext Part of Ticket ................................... 41 7.6. Cleartext Part of Ticket ................................... 41
8. Credential Acquisition ....................................... 43 8. Credential Acquisition ....................................... 43
8.1. KDC-REQ .................................................... 43 8.1. KDC-REQ .................................................... 43
8.2. PA-DATA .................................................... 50 8.2. PA-DATA .................................................... 50
8.3. KDC-REQ Processing ......................................... 50 8.3. KDC-REQ Processing ......................................... 50
8.3.1. Handling Replays ......................................... 50
8.3.2. Request Validation ....................................... 51
8.3.2.1. AS-REQ Authentication .................................. 51
8.3.2.2. TGS-REQ Authentication ................................. 51
8.3.2.3. Principal Validation ................................... 51
8.3.2.4. Checking For Revoked or Invalid Tickets ................ 51
8.3.3. Timestamp Handling ....................................... 52
8.3.3.1. AS-REQ Timestamp Processing ............................ 52
8.3.3.2. TGS-REQ Timestamp Processing ........................... 53
8.3.4. Handling Transited Realms ................................ 54
8.3.5. Address Processing ....................................... 54
8.3.6. Ticket Flag Processing ................................... 54
8.3.7. Key Selection ............................................ 56
8.3.7.1. Reply Key and Session Key Selection .................... 56
8.3.7.2. Ticket Key Selection ................................... 56
8.4. KDC-REP .................................................... 56 8.4. KDC-REP .................................................... 56
8.5. Reply Validation ........................................... 60 8.5. Reply Validation ........................................... 60
8.6. IP Transports .............................................. 60 8.6. IP Transports .............................................. 60
8.6.1. UDP/IP transport ......................................... 60
8.6.2. TCP/IP transport ......................................... 60
8.6.3. KDC Discovery on IP Networks ............................. 62
8.6.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names ..... 62
8.6.3.2. DNS SRV records for KDC location ....................... 62
8.6.3.3. KDC Discovery for Domain Style Realm Names on IP
Networks ............................................ 63
9. Errors ....................................................... 63 9. Errors ....................................................... 63
10. Session Key Exchange ........................................ 65 10. Session Key Exchange ........................................ 65
10.1. AP-REQ .................................................... 66 10.1. AP-REQ .................................................... 66
10.2. AP-REP .................................................... 67 10.2. AP-REP .................................................... 67
11. Session Key Use ............................................. 69 11. Session Key Use ............................................. 69
11.1. KRB-SAFE .................................................. 69 11.1. KRB-SAFE .................................................. 69
11.2. KRB-PRIV .................................................. 69 11.2. KRB-PRIV .................................................. 69
11.3. KRB-CRED .................................................. 70 11.3. KRB-CRED .................................................. 70
12. Security Considerations ..................................... 71 12. Security Considerations ..................................... 71
12.1. Time Synchronization ...................................... 71 12.1. Time Synchronization ...................................... 71
12.2. Replays ................................................... 71 12.2. Replays ................................................... 72
12.3. Principal Name Reuse ...................................... 72 12.3. Principal Name Reuse ...................................... 72
12.4. Password Guessing ......................................... 72 12.4. Password Guessing ......................................... 72
12.5. Forward Secrecy ........................................... 72 12.5. Forward Secrecy ........................................... 72
12.6. Authorization ............................................. 72 12.6. Authorization ............................................. 72
12.7. Login Authentication ...................................... 72 12.7. Login Authentication ...................................... 72
13. IANA Considerations ......................................... 72 13. IANA Considerations ......................................... 72
14. Acknowledgments ............................................. 73 14. Acknowledgments ............................................. 73
Appendices ....................................................... 73 Appendices ....................................................... 73
A. ASN.1 Module (Normative) ..................................... 73 A. ASN.1 Module (Normative) ..................................... 73
B. Kerberos and Character Encodings (Informative) ...............105 B. Kerberos and Character Encodings (Informative) ...............109
C. Kerberos History (Informative) ...............................107 C. Kerberos History (Informative) ...............................110
D. Notational Differences from [KCLAR] ..........................107 D. Notational Differences from [RFC4120] ........................111
Normative References .............................................108 Normative References .............................................111
Informative References ...........................................109 Informative References ...........................................112
Author's Address .................................................110 Author's Address .................................................113
Copyright Statement ..............................................110 Full Copyright Statement .........................................113
Intellectual Property Statement ..................................110 Intellectual Property ............................................113
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
an application server, and likewise authenticates the application an application server, and likewise authenticates the application
server's identity to the application client. These assurances are server's identity to the application client. These assurances are
made possible by the client and the server sharing secrets with the made possible by the client and the server sharing secrets with the
trusted third party: the Kerberos server, also known as the Key trusted third party: the Kerberos server, also known as the Key
Distribution Center (KDC). In addition, the protocol establishes an Distribution Center (KDC). In addition, the protocol establishes an
ephemeral shared secret (the session key) between the client and the ephemeral shared secret (the session key) between the client and the
server, allowing the protection of further communications between server, allowing the protection of further communications between
them. them.
The Kerberos protocol, as originally specified, provides insufficient The Kerberos protocol, as originally specified in [RFC1510] and
means for extending the protocol in a backwards-compatible way. This [RFC4120], provides insufficient means for extending the protocol in
deficiency has caused problems for interoperability. This document a backwards-compatible way. This deficiency has caused problems for
describes a framework which enables backwards-compatible extensions interoperability. This document describes a framework which enables
to the Kerberos protocol. backwards-compatible extensions to the Kerberos protocol.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
to be interpreted as described in [RFC2119].
1.1. Kerberos Protocol Overview 1.1. Kerberos Protocol Overview
Kerberos comprises three main sub-protocols: credentials acquisition, Kerberos comprises three main sub-protocols: credentials acquisition,
session key exchange, and session key usage. A client acquires session key exchange, and session key usage. A client acquires
credentials by asking the KDC for a credential for a service; the KDC credentials by asking the KDC for a credential for a service; the KDC
issues the credential, which contains a ticket and a session key. issues the credential, which contains a ticket and a session key.
The ticket, containing the client's identity, timestamps, expiration The ticket, containing the client's identity, timestamps, expiration
time, and a session key, is a encrypted in a key known to the time, and a session key, is a encrypted in a key known to the
application server. The KDC encrypts the credential using a key application server. The KDC encrypts the credential using a key
skipping to change at page 8, line 4 skipping to change at page 7, line 4
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 [RFC4120]. The second set of types is the set of types enabling
extensibility. This second set may be referred to as extensibility. This second set may be referred to as
"extensibility-enabled types". [ need to make this consistent "extensibility-enabled types". [ need to make this consistent
throughout? ] 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
skipping to change at page 13, line 29 skipping to change at page 12, line 29
krb-priv KRB-PRIV, krb-priv KRB-PRIV,
krb-cred KRB-CRED, krb-cred KRB-CRED,
tgt-req TGT-REQ, tgt-req TGT-REQ,
krb-error KRB-ERROR, krb-error KRB-ERROR,
... ...
} }
3.3. Previously Unused ASN.1 Notation (informative) 3.3. Previously Unused ASN.1 Notation (informative)
Some aspects of ASN.1 notation used in this document were not used in Some aspects of ASN.1 notation used in this document were not used in
[KCLAR], and may be unfamiliar to some readers. This subsection is [RFC4120], and may be unfamiliar to some readers. This subsection is
informative; for normative definitions of the notation, see the informative; for normative definitions of the notation, see the
actual ASN.1 specifications [X680], [X682], [X683]. actual ASN.1 specifications [X680], [X682], [X683].
3.3.1. Parameterized Types 3.3.1. Parameterized Types
This document uses ASN.1 parameterized types [X683] to make This document uses ASN.1 parameterized types [X683] to make
definitions of types more readable. For some types, some or all of definitions of types more readable. For some types, some or all of
the parameters are advisory, i.e., they are not encoded in any form the parameters are advisory, i.e., they are not encoded in any form
for transmission in a protocol message. These advisory parameters for transmission in a protocol message. These advisory parameters
can describe implementation behavior associated with the type. can describe implementation behavior associated with the type.
skipping to change at page 14, line 8 skipping to change at page 13, line 8
a formalized way of conveying intended implementation behavior. a formalized way of conveying intended implementation behavior.
The "WITH COMPONENTS" constraint notation allows constraints to apply The "WITH COMPONENTS" constraint notation allows constraints to apply
to component types of a SEQUENCE type. This constraint notation to component types of a SEQUENCE type. This constraint notation
effectively allows constraints to "reach into" a type to constrain effectively allows constraints to "reach into" a type to constrain
its component types. its component types.
3.4. New Types 3.4. New Types
This document defines a number of ASN.1 types which are new since This document defines a number of ASN.1 types which are new since
[KCLAR]. The names of these types will typically have a suffix like [RFC4120]. The names of these types will typically have a suffix
"Ext", indicating that the types are intended to support like "Ext", indicating that the types are intended to support
extensibility. Types original to RFC 1510 and [KCLAR] have been extensibility. Types original to RFC 1510 and [RFC4120] have been
renamed to have a suffix like "1510". The "Ext" and "1510" types renamed to have a suffix like "1510". The "Ext" and "1510" types
often contain a number of common elements, but differ primarily in often contain a number of common elements, but differ primarily in
the way strings are encoded. the way strings are encoded.
4. Basic Types 4. Basic Types
These "basic" Kerberos ASN.1 types appear in multiple other Kerberos These "basic" Kerberos ASN.1 types appear in multiple other Kerberos
types. types.
4.1. Constrained Integer Types 4.1. Constrained Integer Types
In RFC 1510, many types contained references to the unconstrained In RFC 1510, many types contained references to the unconstrained
INTEGER type. Since an unconstrained INTEGER can contain almost any INTEGER type. Since an unconstrained INTEGER can contain almost any
possible abstract integer value, most of the unconstrained references possible abstract integer value, most of the unconstrained references
to INTEGER in RFC 1510 were constrained to 32 bits or smaller in to INTEGER in RFC 1510 were constrained to 32 bits or smaller in
[KCLAR]. [RFC4120].
-- signed values representable in 32 bits -- signed values representable in 32 bits
-- --
-- These are often used as assigned numbers for various things. -- These are often used as assigned numbers for various things.
Int32 ::= INTEGER (-2147483648..2147483647) Int32 ::= INTEGER (-2147483648..2147483647)
The "Int32" type often contains an assigned number identifying the The "Int32" type often contains an assigned number identifying the
contents of a typed hole. Unless otherwise stated, non-negative contents of a typed hole. Unless otherwise stated, non-negative
values are registered, and negative values are available for local values are registered, and negative values are available for local
use. use.
skipping to change at page 14, line 53 skipping to change at page 13, line 53
-- unsigned 64 bit values -- unsigned 64 bit values
UInt64 ::= INTEGER (0..18446744073709551615) UInt64 ::= INTEGER (0..18446744073709551615)
The "UInt64" type is used in places where 32 bits of precision may The "UInt64" type is used in places where 32 bits of precision may
provide inadequate security. provide inadequate security.
-- sequence numbers -- sequence numbers
SeqNum ::= UInt64 SeqNum ::= UInt64
Sequence numbers were constrained to 32 bits in [KCLAR], but this Sequence numbers were constrained to 32 bits in [RFC4120], but this
document allows for 64-bit sequence numbers. document allows for 64-bit sequence numbers.
-- nonces -- nonces
Nonce ::= UInt64 Nonce ::= UInt64
Likewise, nonces were constrained to 32 bits in [KCLAR], but expanded Likewise, nonces were constrained to 32 bits in [RFC4120], but
to 64 bits here. expanded to 64 bits here.
-- microseconds -- microseconds
Microseconds ::= INTEGER (0..999999) Microseconds ::= INTEGER (0..999999)
The "microseconds" type is intended to carry the microseconds part of The "microseconds" type is intended to carry the microseconds part of
a time value. a time value.
4.2. KerberosTime 4.2. KerberosTime
KerberosTime ::= GeneralizedTime (CONSTRAINED BY { KerberosTime ::= GeneralizedTime (CONSTRAINED BY {
skipping to change at page 15, line 45 skipping to change at page 14, line 45
utf8 UTF8String, utf8 UTF8String,
... -- no extension may be sent ... -- no extension may be sent
-- to an rfc1510 implementation -- -- to an rfc1510 implementation --
} }
The KerberosString type is used for character strings in various The KerberosString type is used for character strings in various
places in the Kerberos protocol. For compatibility with RFC 1510, places in the Kerberos protocol. For compatibility with RFC 1510,
GeneralString values constrained to IA5String (US-ASCII) are GeneralString values constrained to IA5String (US-ASCII) are
permitted in messages exchanged with RFC 1510 implementations. The permitted in messages exchanged with RFC 1510 implementations. The
new protocol messages contain strings encoded as UTF-8, and these new protocol messages contain strings encoded as UTF-8, and these
strings MUST be normalized using [SASLPREP]. KerberosString values strings MUST be normalized using [RFC4013]. KerberosString values
are present in principal names and in error messages. Control are present in principal names and in error messages. Control
characters SHOULD NOT be used in principal names, and used with characters SHOULD NOT be used in principal names, and used with
caution in error messages. caution in error messages.
-- IA5 choice only; useful for constraints -- IA5 choice only; useful for constraints
KerberosStringIA5 ::= KerberosString KerberosStringIA5 ::= KerberosString
(WITH COMPONENTS { ia5 PRESENT }) (WITH COMPONENTS { ia5 PRESENT })
-- IA5 excluded; useful for constraints -- IA5 excluded; useful for constraints
KerberosStringExt ::= KerberosString KerberosStringExt ::= KerberosString
skipping to change at page 16, line 28 skipping to change at page 15, line 28
in Kerberos, as well as discussion of some compatibility issues, see in Kerberos, as well as discussion of some compatibility issues, see
Appendix B. Appendix B.
4.4. Language Tags 4.4. Language Tags
-- used for language tags -- used for language tags
LangTag ::= PrintableString LangTag ::= PrintableString
(FROM ("A".."Z" | "a".."z" | "0".."9" | "-")) (FROM ("A".."Z" | "a".."z" | "0".."9" | "-"))
The "LangTag" type is used to specify language tags for localization The "LangTag" type is used to specify language tags for localization
purposes, using the [RFC3066] format. purposes, using the [RFC4646] format.
4.5. KerberosFlags 4.5. KerberosFlags
For several message types, a specific constrained bit string type, For several message types, a specific constrained bit string type,
KerberosFlags, is used. KerberosFlags, is used.
KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX)) KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX))
(CONSTRAINED BY { (CONSTRAINED BY {
-- MUST be a valid value of -- NamedBits -- MUST be a valid value of -- NamedBits
-- but if the value to be sent would be truncated to shorter
-- than 32 bits according to DER, the value MUST be padded -- but if the value to be sent would be truncated to
-- with trailing zero bits to 32 bits. Otherwise, no -- shorter than 32 bits according to DER, the value MUST be
-- trailing zero bits may be present. -- padded with trailing zero bits to 32 bits. Otherwise,
-- no trailing zero bits may be present.
}) })
The actual bit string type encoded in Kerberos messages does not use The actual bit string type encoded in Kerberos messages does not use
named bits. The advisory parameter of the KerberosFlags type names a named bits. The advisory parameter of the KerberosFlags type names a
bit string type defined using named bits, whose value is encoded as bit string type defined using named bits, whose value is encoded as
if it were a bit string with unnamed bits. This practice is if it were a bit string with unnamed bits. This practice is
necessary because the DER require trailing zero bits to be removed necessary because the DER require trailing zero bits to be removed
when encoding bit strings defined using named bits. Existing when encoding bit strings defined using named bits. Existing
implementations of Kerberos send exactly 32 bits rather than implementations of Kerberos send exactly 32 bits rather than
skipping to change at page 18, line 14 skipping to change at page 17, line 22
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
SHOULD NOT appear in a Kerberos PDU. The type of IPv4 addresses is SHOULD NOT appear in a Kerberos PDU. The type of IPv4 addresses is
two (2). two (2).
4.7.2. Internet (IPv6) Addresses 4.7.2. Internet (IPv6) Addresses
IPv6 addresses [RFC2373] are 128-bit (16-octet) quantities, encoded IPv6 addresses [RFC4291] are 128-bit (16-octet) quantities, encoded
in MSB order (most significant byte first). The type of IPv6 in MSB order (most significant byte first). The type of IPv6
addresses is twenty-four (24). The following addresses MUST NOT addresses is twenty-four (24). The following addresses MUST NOT
appear in any Kerberos PDU: appear in any Kerberos PDU:
* the Unspecified Address * the Unspecified Address
* the Loopback Address * the Loopback Address
* Link-Local addresses * Link-Local addresses
skipping to change at page 20, line 26 skipping to change at page 19, line 26
-- Service with host as remaining components -- Service with host as remaining components
nt-srv-xhst NameType ::= 4 nt-srv-xhst NameType ::= 4
-- Unique ID -- Unique ID
nt-uid NameType ::= 5 nt-uid NameType ::= 5
-- Encoded X.509 Distingished name [RFC 2253] -- Encoded X.509 Distingished name [RFC 2253]
nt-x500-principal NameType ::= 6 nt-x500-principal NameType ::= 6
-- Name in form of SMTP email name (e.g. user@foo.com) -- Name in form of SMTP email name (e.g. user@foo.com)
nt-smtp-name NameType ::= 7 nt-smtp-name NameType ::= 7
-- Enterprise name - may be mapped to principal name -- Enterprise name - may be mapped to principal name
nt-enterprise NameType ::= 10 nt-enterprise NameType ::= 10
-- reserved principal names [krb-wg-naming]
nt-wellknown NameType ::= 11
5.2. Principal Type Definition 5.2. Principal Type Definition
The "PrincipalName" type takes a parameter to constrain which string The "PrincipalName" type takes a parameter to constrain which string
type it contains. type it contains.
PrincipalName { StrType } ::= SEQUENCE { PrincipalName { StrType } ::= SEQUENCE {
name-type [0] NameType, name-type [0] NameType,
-- May have zero elements, or individual elements may be -- May have zero elements, or individual elements may be
-- zero-length, but this is NOT RECOMMENDED. -- zero-length, but this is NOT RECOMMENDED.
skipping to change at page 23, line 21 skipping to change at page 22, line 22
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 [RFC4120], 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
output of NamePrep and StringPrep string preparation must be output of NamePrep and StringPrep string preparation must be
equivalent.) equivalent.)
5.7. Printable Representations of Principal Names 5.7. Printable Representations of Principal Names
skipping to change at page 24, line 39 skipping to change at page 23, line 39
6. Types Relating to Encryption 6. Types Relating to Encryption
Many Kerberos protocol messages contain encrypted encodings of Many Kerberos protocol messages contain encrypted encodings of
various data types. Some Kerberos protocol messages also contain various data types. Some Kerberos protocol messages also contain
checksums (signatures) of encodings of various types. checksums (signatures) of encodings of various types.
6.1. Assigned Numbers for Encryption 6.1. Assigned Numbers for Encryption
Encryption algorithm identifiers and key usages both have assigned Encryption algorithm identifiers and key usages both have assigned
numbers, described in [KCRYPTO]. numbers, described in [RFC3961].
6.1.1. EType 6.1.1. EType
EType is the integer type for assigned numbers for encryption EType is the integer type for assigned numbers for encryption
algorithms. Defined in [KCRYPTO]. algorithms. Defined in [RFC3961].
-- Assigned numbers denoting encryption mechanisms. -- Assigned numbers denoting encryption mechanisms.
EType ::= Int32 EType ::= Int32
-- assigned numbers for encryption schemes -- assigned numbers for encryption schemes
et-des-cbc-crc EType ::= 1 et-des-cbc-crc EType ::= 1
et-des-cbc-md4 EType ::= 2 et-des-cbc-md4 EType ::= 2
et-des-cbc-md5 EType ::= 3 et-des-cbc-md5 EType ::= 3
-- [reserved] 4 -- [reserved] 4
et-des3-cbc-md5 EType ::= 5 et-des3-cbc-md5 EType ::= 5
skipping to change at page 25, line 39 skipping to change at page 24, line 39
et-rc4-hmac EType ::= 23 et-rc4-hmac EType ::= 23
-- Microsoft -- Microsoft
et-rc4-hmac-exp EType ::= 24 et-rc4-hmac-exp EType ::= 24
-- opaque; PacketCable -- opaque; PacketCable
et-subkey-keymaterial EType ::= 65 et-subkey-keymaterial EType ::= 65
6.1.2. Key Usages 6.1.2. Key Usages
KeyUsage is the integer type for assigned numbers for key usages. KeyUsage is the integer type for assigned numbers for key usages.
Key usage values are inputs to the encryption and decryption Key usage values are inputs to the encryption and decryption
functions described in [KCRYPTO]. functions described in [RFC3961].
-- Assigned numbers denoting key usages. -- Assigned numbers denoting key usages.
KeyUsage ::= UInt32 KeyUsage ::= UInt32
-- --
-- Actual identifier names are provisional and subject to -- Actual identifier names are provisional and subject to
-- change. -- change.
-- --
ku-pa-enc-ts KeyUsage ::= 1 ku-pa-enc-ts KeyUsage ::= 1
ku-Ticket KeyUsage ::= 2 ku-Ticket KeyUsage ::= 2
skipping to change at page 27, line 5 skipping to change at page 26, line 28
ku-kg-acceptor-sign KeyUsage ::= 23 ku-kg-acceptor-sign KeyUsage ::= 23
ku-kg-intiator-seal KeyUsage ::= 24 ku-kg-intiator-seal KeyUsage ::= 24
ku-kg-intiator-sign KeyUsage ::= 25 ku-kg-intiator-sign KeyUsage ::= 25
-- KeyUsage values 25..27 used by hardware preauth? -- KeyUsage values 25..27 used by hardware preauth?
-- for KINK -- for KINK
ku-kink-encrypt KeyUsage ::= 39 ku-kink-encrypt KeyUsage ::= 39
ku-kink-cksum KeyUsage ::= 40 ku-kink-cksum KeyUsage ::= 40
6.2. Which Key to Use -- IAKERB
ku-iakerb-finished KeyUsage ::= 41
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 27, line 42 skipping to change at page 27, line 39
The "EncryptionKey" type holds an encryption key. The "EncryptionKey" type holds an encryption key.
EncryptionKey ::= SEQUENCE { EncryptionKey ::= SEQUENCE {
keytype [0] EType, keytype [0] EType,
keyvalue [1] OCTET STRING keyvalue [1] OCTET STRING
} }
keytype keytype
This "EType" identifies the encryption algorithm, described in This "EType" identifies the encryption algorithm, described in
[KCRYPTO]. [RFC3961].
keyvalue keyvalue
Contains the actual key. Contains the actual key.
6.4. EncryptedData 6.4. EncryptedData
The "EncryptedData" type contains the encryption of another data The "EncryptedData" type contains the encryption of another data
type. The recipient uses fields within EncryptedData to determine type. The recipient uses fields within EncryptedData to determine
which key to use for decryption. which key to use for decryption.
skipping to change at page 29, line 24 skipping to change at page 29, line 24
checksum [1] OCTET STRING (CONSTRAINED BY { checksum [1] OCTET STRING (CONSTRAINED BY {
-- signed using one of the keys -- -- signed using one of the keys --
KeyToUse:Keys, KeyToUse:Keys,
-- with key usage being one of -- -- with key usage being one of --
KeyUsage:KeyUsages KeyUsage:KeyUsages
}) })
} }
CksumType CksumType
Integer type for assigned numbers for signature algorithms. Integer type for assigned numbers for signature algorithms.
Defined in [KCRYPTO] Defined in [RFC3961]
Keys Keys
As in EncryptedData As in EncryptedData
KeyUsages KeyUsages
As in EncryptedData As in EncryptedData
cksumtype cksumtype
Signature algorithm used to produce the signature. Signature algorithm used to produce the signature.
skipping to change at page 32, line 40 skipping to change at page 32, line 40
pre-authent (10), pre-authent (10),
hw-authent (11), hw-authent (11),
transited-policy-checked (12), transited-policy-checked (12),
ok-as-delegate (13), ok-as-delegate (13),
anonymous (14), anonymous (14),
cksummed-ticket (15) cksummed-ticket (15)
} }
7.2.1. Flags Relating to Initial Ticket Acquisition 7.2.1. Flags Relating to Initial Ticket Acquisition
[ adapted KCLAR 2.1. ] [ adapted RFC4120 2.1. ]
Several flags indicate the details of how the initial ticket was Several flags indicate the details of how the initial ticket was
acquired. acquired.
initial initial
The "initial" flag indicates that a ticket was issued using the The "initial" flag indicates that a ticket was issued using the
AS protocol, rather than issued based on a ticket-granting AS protocol, rather than issued based on a ticket-granting
ticket. Application servers (e.g., a password-changing program) ticket. Application servers (e.g., a password-changing program)
requiring a client's definite knowledge of its secret key can requiring a client's definite knowledge of its secret key can
insist that this flag be set in any tickets they accept, thus insist that this flag be set in any tickets they accept, thus
skipping to change at page 33, line 20 skipping to change at page 33, line 20
The "hw-authent" flag indicates that some sort of hardware-based The "hw-authent" flag indicates that some sort of hardware-based
pre-authentication occurred during the AS exchange. pre-authentication occurred during the AS exchange.
Both the "pre-authent" and the "hw-authent" flags may be present with Both the "pre-authent" and the "hw-authent" flags may be present with
or without the "initial" flag; such tickets with the "initial" flag or without the "initial" flag; such tickets with the "initial" flag
clear are ones which are derived from initial tickets with the "pre- clear are ones which are derived from initial tickets with the "pre-
authent" or "hw-authent" flags set. authent" or "hw-authent" flags set.
7.2.2. Invalid Tickets 7.2.2. Invalid Tickets
[ KCLAR 2.2. ] [ RFC4120 2.2. ]
The "invalid" flag indicates that a ticket is invalid. Application The "invalid" flag indicates that a ticket is invalid. Application
servers MUST reject tickets which have this flag set. A postdated servers MUST reject tickets which have this flag set. A postdated
ticket will be issued in this form. Invalid tickets MUST be ticket will be issued in this form. Invalid tickets MUST be
validated by the KDC before use, by presenting them to the KDC in a validated by the KDC before use, by presenting them to the KDC in a
TGS request with the "validate" option specified. The KDC will only TGS request with the "validate" option specified. The KDC will only
validate tickets after their starttime has passed. The validation is validate tickets after their starttime has passed. The validation is
required so that postdated tickets which have been stolen before required so that postdated tickets which have been stolen before
their starttime can be rendered permanently invalid (through a hot- their starttime can be rendered permanently invalid (through a hot-
list mechanism -- see Section 8.3.2.4). list mechanism -- see Section 8.3.2.4).
7.2.3. OK as Delegate 7.2.3. OK as Delegate
[ KCLAR 2.8. ] [ RFC4120 2.8. ]
The "ok-as-delegate" flag provides a way for a KDC to communicate The "ok-as-delegate" flag provides a way for a KDC to communicate
local realm policy to a client regarding whether the service for local realm policy to a client regarding whether the service for
which the ticket is issued is trusted to accept delegated which the ticket is issued is trusted to accept delegated
credentials. For some applications, a client may need to delegate credentials. For some applications, a client may need to delegate
credentials to a service to act on its behalf in contacting other credentials to a service to act on its behalf in contacting other
services. The ability of a client to obtain a service ticket for a services. The ability of a client to obtain a service ticket for a
service conveys no information to the client about whether the service conveys no information to the client about whether the
service should be trusted to accept delegated credentials. service should be trusted to accept delegated credentials.
skipping to change at page 34, line 7 skipping to change at page 34, line 7
of this flag to help it make a decision whether to delegate of this flag to help it make a decision whether to delegate
credentials (either grant a proxy or a forwarded ticket-granting credentials (either grant a proxy or a forwarded ticket-granting
ticket) to this service. It is acceptable to ignore the value of ticket) to this service. It is acceptable to ignore the value of
this flag. When setting this flag, an administrator should consider this flag. When setting this flag, an administrator should consider
the security and placement of the server on which the service will the security and placement of the server on which the service will
run, as well as whether the service requires the use of delegated run, as well as whether the service requires the use of delegated
credentials. credentials.
7.2.4. Renewable Tickets 7.2.4. Renewable Tickets
[ adapted KCLAR 2.3. ] [ adapted RFC4120 2.3. ]
The "renewable" flag indicates whether the ticket may be renewed. The "renewable" flag indicates whether the ticket may be renewed.
Renewable tickets can be used to mitigate the consequences of ticket Renewable tickets can be used to mitigate the consequences of ticket
theft. Applications may desire to hold credentials which can be theft. Applications may desire to hold credentials which can be
valid for long periods of time. However, this can expose the valid for long periods of time. However, this can expose the
credentials to potential theft for equally long periods, and those credentials to potential theft for equally long periods, and those
stolen credentials would be valid until the expiration time of the stolen credentials would be valid until the expiration time of the
ticket(s). Simply using short-lived tickets and obtaining new ones ticket(s). Simply using short-lived tickets and obtaining new ones
periodically would require the application to have long-term access periodically would require the application to have long-term access
skipping to change at page 34, line 54 skipping to change at page 34, line 54
7.2.5. Postdated Tickets 7.2.5. Postdated Tickets
postdated postdated
indicates a ticket which has been postdated indicates a ticket which has been postdated
may-postdate may-postdate
indicates that postdated tickets may be issued based on this indicates that postdated tickets may be issued based on this
ticket ticket
[ KCLAR 2.4. ] [ RFC4120 2.4. ]
Applications may occasionally need to obtain tickets for use much Applications may occasionally need to obtain tickets for use much
later, e.g., a batch submission system would need tickets to be valid later, e.g., a batch submission system would need tickets to be valid
at the time the batch job is serviced. However, it is dangerous to at the time the batch job is serviced. However, it is dangerous to
hold valid tickets in a batch queue, since they will be on-line hold valid tickets in a batch queue, since they will be on-line
longer and more prone to theft. Postdated tickets provide a way to longer and more prone to theft. Postdated tickets provide a way to
obtain these tickets from the KDC at job submission time, but to obtain these tickets from the KDC at job submission time, but to
leave them "dormant" until they are activated and validated by a leave them "dormant" until they are activated and validated by a
further request of the KDC. If a ticket theft were reported in the further request of the KDC. If a ticket theft were reported in the
interim, the KDC would refuse to validate the ticket, and the thief interim, the KDC would refuse to validate the ticket, and the thief
would be foiled. would be foiled.
skipping to change at page 35, line 47 skipping to change at page 35, line 47
validation before use. validation before use.
7.2.6. Proxiable and Proxy Tickets 7.2.6. Proxiable and Proxy Tickets
proxy proxy
indicates a proxy ticket indicates a proxy ticket
proxiable proxiable
indicates that proxy tickets may be issued based on this ticket indicates that proxy tickets may be issued based on this ticket
[ KCLAR 2.5. ] [ RFC4120 2.5. ]
It may be necessary for a principal to allow a service to perform an It may be necessary for a principal to allow a service to perform an
operation on its behalf. The service must be able to take on the operation on its behalf. The service must be able to take on the
identity of the client, but only for a particular purpose. A identity of the client, but only for a particular purpose. A
principal can allow a service to take on the principal's identity for principal can allow a service to take on the principal's identity for
a particular purpose by granting it a proxy. a particular purpose by granting it a proxy.
The process of granting a proxy using the "proxy" and "proxiable" The process of granting a proxy using the "proxy" and "proxiable"
flags is used to provide credentials for use with specific services. flags is used to provide credentials for use with specific services.
Though conceptually also a proxy, users wishing to delegate their Though conceptually also a proxy, users wishing to delegate their
skipping to change at page 36, line 46 skipping to change at page 36, line 46
7.2.7. Forwarded and Forwardable Tickets 7.2.7. Forwarded and Forwardable Tickets
forwarded forwarded
indicates a forwarded ticket indicates a forwarded ticket
forwardable forwardable
indicates that forwarded tickets may be issued based on this indicates that forwarded tickets may be issued based on this
ticket ticket
[ KCLAR 2.6. ] [ RFC4120 2.6. ]
Authentication forwarding is an instance of a proxy where the service Authentication forwarding is an instance of a proxy where the service
that is granted is complete use of the client's identity. An example that is granted is complete use of the client's identity. An example
where it might be used is when a user logs in to a remote system and where it might be used is when a user logs in to a remote system and
wants authentication to work from that system as if the login were wants authentication to work from that system as if the login were
local. local.
The "forwardable" flag in a ticket is normally only interpreted by The "forwardable" flag in a ticket is normally only interpreted by
the ticket-granting service. It can be ignored by application the ticket-granting service. It can be ignored by application
servers. The "forwardable" flag has an interpretation similar to servers. The "forwardable" flag has an interpretation similar to
skipping to change at page 37, line 31 skipping to change at page 37, line 31
issued based on tickets with the "forwarded" flag set. Application issued based on tickets with the "forwarded" flag set. Application
servers may choose to process "forwarded" tickets differently than servers may choose to process "forwarded" tickets differently than
non-forwarded tickets. non-forwarded tickets.
If addressless tickets are forwarded from one system to another, If addressless tickets are forwarded from one system to another,
clients SHOULD still use this option to obtain a new TGT in order to clients SHOULD still use this option to obtain a new TGT in order to
have different session keys on the different systems. have different session keys on the different systems.
7.3. Transited Realms 7.3. Transited Realms
[ KCLAR 2.7., plus new stuff ] [ RFC4120 2.7., plus new stuff ]
7.4. Authorization Data 7.4. Authorization Data
[ KCLAR 5.2.6. ] [ RFC4120 5.2.6. ]
ADType ::= TH-id ADType ::= TH-id
AuthorizationData ::= SEQUENCE OF SEQUENCE { AuthorizationData ::= SEQUENCE OF SEQUENCE {
ad-type [0] ADType, ad-type [0] ADType,
ad-data [1] OCTET STRING ad-data [1] OCTET STRING
} }
ad-type ad-type
This field identifies the contents of the ad-data. All negative This field identifies the contents of the ad-data. All negative
skipping to change at page 38, line 46 skipping to change at page 38, line 46
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.
-- Intended for application servers; receiving application servers -- Intended for application servers; receiving application
-- MAY ignore. -- servers MAY ignore.
AD-IF-RELEVANT ::= AuthorizationData AD-IF-RELEVANT ::= AuthorizationData
AD elements encapsulated within the if-relevant element are intended AD elements encapsulated within the if-relevant element are intended
for interpretation only by application servers that understand the for interpretation only by application servers that understand the
particular ad-type of the embedded element. Application servers that particular ad-type of the embedded element. Application servers that
do not understand the type of an element embedded within the if- do not understand the type of an element embedded within the if-
relevant element MAY ignore the uninterpretable element. This element relevant element MAY ignore the uninterpretable element. This element
promotes interoperability across implementations which may have local promotes interoperability across implementations which may have local
extensions for authorization. The ad-type for AD-IF-RELEVANT is (1). extensions for authorization. The ad-type for AD-IF-RELEVANT is (1).
skipping to change at page 43, line 44 skipping to change at page 44, line 4
directly encoded; it is always a part of a AS-REQ or a TGS-REQ. directly encoded; it is always a part of a AS-REQ or a TGS-REQ.
KDC-REQ-1510 ::= SEQUENCE { KDC-REQ-1510 ::= SEQUENCE {
-- NOTE: first tag is [1], not [0] -- NOTE: first tag is [1], not [0]
pvno [1] INTEGER (5), pvno [1] INTEGER (5),
msg-type [2] INTEGER ( 10 -- AS-REQ -- msg-type [2] INTEGER ( 10 -- AS-REQ --
| 12 -- TGS-REQ -- ), | 12 -- TGS-REQ -- ),
padata [3] SEQUENCE OF PA-DATA OPTIONAL, padata [3] SEQUENCE OF PA-DATA OPTIONAL,
req-body [4] KDC-REQ-BODY-1510 req-body [4] KDC-REQ-BODY-1510
} }
KDC-REQ-EXT ::= SEQUENCE { KDC-REQ-EXT ::= SEQUENCE {
pvno [1] INTEGER (5), pvno [1] INTEGER (5),
msg-type [2] INTEGER ( 6 -- AS-REQ -- msg-type [2] INTEGER ( 6 -- AS-REQ --
| 8 -- TGS-REQ -- ), | 8 -- TGS-REQ -- ),
padata [3] SEQUENCE (SIZE (1..MAX)) OF PA-DATA OPTIONAL, padata [3] SEQUENCE (SIZE (1..MAX))
OF PA-DATA OPTIONAL,
req-body [4] KDC-REQ-BODY-EXT, req-body [4] KDC-REQ-BODY-EXT,
... ...
} }
KDC-REQ-BODY-1510 ::= SEQUENCE { KDC-REQ-BODY-1510 ::= SEQUENCE {
kdc-options [0] KDCOptions, kdc-options [0] KDCOptions,
cname [1] PrincipalNameIA5 OPTIONAL cname [1] PrincipalNameIA5 OPTIONAL
-- Used only in AS-REQ --, -- Used only in AS-REQ --,
realm [2] RealmIA5 realm [2] RealmIA5
-- Server's realm; also client's in AS-REQ --, -- Server's realm; also client's in AS-REQ --,
sname [3] PrincipalNameIA5 OPTIONAL, sname [3] PrincipalNameIA5 OPTIONAL,
from [4] KerberosTime OPTIONAL, from [4] KerberosTime OPTIONAL,
skipping to change at page 47, line 51 skipping to change at page 48, line 9
padata [3] SEQUENCE OF PA-DATA OPTIONAL, padata [3] SEQUENCE OF PA-DATA OPTIONAL,
req-body [4] KDC-REQ-BODY-1510 req-body [4] KDC-REQ-BODY-1510
} }
The extensible form of a KDC-REQ is: The extensible form of a KDC-REQ is:
KDC-REQ-EXT ::= SEQUENCE { KDC-REQ-EXT ::= SEQUENCE {
pvno [1] INTEGER (5), pvno [1] INTEGER (5),
msg-type [2] INTEGER ( 6 -- AS-REQ -- msg-type [2] INTEGER ( 6 -- AS-REQ --
| 8 -- TGS-REQ -- ), | 8 -- TGS-REQ -- ),
padata [3] SEQUENCE (SIZE (1..MAX)) OF PA-DATA OPTIONAL, padata [3] SEQUENCE (SIZE (1..MAX))
OF PA-DATA OPTIONAL,
req-body [4] KDC-REQ-BODY-EXT, req-body [4] KDC-REQ-BODY-EXT,
... ...
} }
The backwards-compatibility form of a KDC-REQ-BODY is: The backwards-compatibility form of a KDC-REQ-BODY is:
KDC-REQ-BODY-1510 ::= SEQUENCE { KDC-REQ-BODY-1510 ::= SEQUENCE {
kdc-options [0] KDCOptions, kdc-options [0] KDCOptions,
cname [1] PrincipalNameIA5 OPTIONAL cname [1] PrincipalNameIA5 OPTIONAL
-- Used only in AS-REQ --, -- Used only in AS-REQ --,
realm [2] RealmIA5 realm [2] RealmIA5
-- Server's realm; also client's in AS-REQ --, -- Server's realm; also client's in AS-REQ --,
skipping to change at page 49, line 50 skipping to change at page 49, line 50
The AS-REQ is: The AS-REQ is:
AS-REQ ::= CHOICE { AS-REQ ::= CHOICE {
rfc1510 AS-REQ-1510, rfc1510 AS-REQ-1510,
ext AS-REQ-EXT ext AS-REQ-EXT
} }
AS-REQ-1510 ::= [APPLICATION 10] KDC-REQ-1510 AS-REQ-1510 ::= [APPLICATION 10] KDC-REQ-1510
-- AS-REQ must include client name -- AS-REQ must include client name
AS-REQ-EXT ::= [APPLICATION 6] Signed { AS-REQ-EXT ::= [APPLICATION 6] Signed {
[APPLICATION 6] KDC-REQ-EXT, { key-client }, { ku-ASReq-cksum } [APPLICATION 6] KDC-REQ-EXT,
{ key-client }, { ku-ASReq-cksum }
} }
-- AS-REQ must include client name -- AS-REQ must include client name
A client SHOULD NOT send the extensible AS-REQ alternative to a KDC A client SHOULD NOT send the extensible AS-REQ alternative to a KDC
if the client does not know that the KDC supports the extensibility if the client does not know that the KDC supports the extensibility
framework. A client SHOULD send the extensible AS-REQ alternative in framework. A client SHOULD send the extensible AS-REQ alternative in
a PA-AS-REQ PA-DATA. A KDC supporting extensibility will treat the a PA-AS-REQ PA-DATA. A KDC supporting extensibility will treat the
AS-REQ contained within the PA-AS-REQ as the actual AS-REQ. [ XXX AS-REQ contained within the PA-AS-REQ as the actual AS-REQ. [ XXX
what if their contents conflict? ] what if their contents conflict? ]
The TGS-REQ is: The TGS-REQ is:
TGS-REQ ::= CHOICE { TGS-REQ ::= CHOICE {
rfc1510 TGS-REQ-1510, rfc1510 TGS-REQ-1510,
ext TGS-REQ-EXT ext TGS-REQ-EXT
} }
TGS-REQ-1510 ::= [APPLICATION 12] KDC-REQ-1510 TGS-REQ-1510 ::= [APPLICATION 12] KDC-REQ-1510
TGS-REQ-EXT ::= [APPLICATION 8] Signed { TGS-REQ-EXT ::= [APPLICATION 8] Signed {
[APPLICATION 8] KDC-REQ-EXT, { key-session }, { ku-TGSReq-cksum } [APPLICATION 8] KDC-REQ-EXT,
{ key-session }, { ku-TGSReq-cksum }
} }
8.2. PA-DATA 8.2. PA-DATA
PA-DATA have multiple uses in the Kerberos protocol. They may pre- PA-DATA have multiple uses in the Kerberos protocol. They may pre-
authenticate an AS-REQ; they may also modify several of the authenticate an AS-REQ; they may also modify several of the
encryption keys used in a KDC-REP. PA-DATA may also provide "hints" encryption keys used in a KDC-REP. PA-DATA may also provide "hints"
to the client about which long-term key (usually password-derived) to to the client about which long-term key (usually password-derived) to
use. PA-DATA may also include "hints" about which pre-authentication use. PA-DATA may also include "hints" about which pre-authentication
mechanisms to use, or include data for input into a pre- mechanisms to use, or include data for input into a pre-
skipping to change at page 52, line 7 skipping to change at page 52, line 7
8.3.2.3. Principal Validation 8.3.2.3. Principal Validation
If the client principal in an AS-REQ is unknown, the KDC returns the If the client principal in an AS-REQ is unknown, the KDC returns the
error "kdc-err-c-principal-unknown". If the server principal in a error "kdc-err-c-principal-unknown". If the server principal in a
KDC-REQ is unknown, the KDC returns the error "kdc-err-s-principal- KDC-REQ is unknown, the KDC returns the error "kdc-err-s-principal-
unknown". unknown".
8.3.2.4. Checking For Revoked or Invalid Tickets 8.3.2.4. Checking For Revoked or Invalid Tickets
[ KCLAR 3.3.3.1 ] [ RFC4120 3.3.3.1 ]
Whenever a request is made to the ticket-granting server, the Whenever a request is made to the ticket-granting server, the
presented ticket(s) is(are) checked against a hot-list of tickets presented ticket(s) is(are) checked against a hot-list of tickets
which have been canceled. This hot-list might be implemented by which have been canceled. This hot-list might be implemented by
storing a range of issue timestamps for "suspect tickets"; if a storing a range of issue timestamps for "suspect tickets"; if a
presented ticket had an authtime in that range, it would be rejected. presented ticket had an authtime in that range, it would be rejected.
In this way, a stolen ticket-granting ticket or renewable ticket In this way, a stolen ticket-granting ticket or renewable ticket
cannot be used to gain additional tickets (renewals or otherwise) cannot be used to gain additional tickets (renewals or otherwise)
once the theft has been reported to the KDC for the realm in which once the theft has been reported to the KDC for the realm in which
the server resides. Any normal ticket obtained before it was the server resides. Any normal ticket obtained before it was
skipping to change at page 52, line 31 skipping to change at page 52, line 31
of the cross-realm TGT will not be affected unless the hot-list is of the cross-realm TGT will not be affected unless the hot-list is
propagated to the KDCs for the realms for which such cross-realm propagated to the KDCs for the realms for which such cross-realm
tickets were issued. tickets were issued.
If a TGS-REQ ticket has its "invalid" flag set, the KDC MUST NOT If a TGS-REQ ticket has its "invalid" flag set, the KDC MUST NOT
issue any ticket unless the TGS-REQ requests the "validate" option. issue any ticket unless the TGS-REQ requests the "validate" option.
8.3.3. Timestamp Handling 8.3.3. Timestamp Handling
[ some aspects of timestamp handling, especially regarding postdating [ some aspects of timestamp handling, especially regarding postdating
and renewal, are difficult to read in KCLAR... needs closer and renewal, are difficult to read in RFC4120... needs closer
examination here ] examination here ]
Processing of "starttime" (requested in the "from" field) differs Processing of "starttime" (requested in the "from" field) differs
depending on whether the "postdated" option is set in the request. depending on whether the "postdated" option is set in the request.
If the "postdated" option is not set, and the requested "starttime" If the "postdated" option is not set, and the requested "starttime"
is in the future beyond the window of acceptable clock skew, the KDC is in the future beyond the window of acceptable clock skew, the KDC
returns the error "kdc-err-cannot-postdate". If the "postdated" returns the error "kdc-err-cannot-postdate". If the "postdated"
option is not set, and the requested "starttime" is absent or does option is not set, and the requested "starttime" is absent or does
not indicate a time in the future beyond the acceptable clock skew, not indicate a time in the future beyond the acceptable clock skew,
the KDC sets the "starttime" to the KDC's current time. The the KDC sets the "starttime" to the KDC's current time. The
skipping to change at page 54, line 24 skipping to change at page 54, line 24
If the new ticket is a renewal, the "endtime" of the new ticket is If the new ticket is a renewal, the "endtime" of the new ticket is
bounded by the minimum of bounded by the minimum of
* the requested "endtime" value, * the requested "endtime" value,
* 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 RFC4120 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 a "starttime", "endtime", or "renew-till" time later than the
"renew-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
skipping to change at page 60, line 8 skipping to change at page 60, line 8
} }
AS-REP-1510 ::= [APPLICATION 11] KDC-REP-1510 AS-REP-1510 ::= [APPLICATION 11] KDC-REP-1510
AS-REP-EXT ::= [APPLICATION 7] Signed { AS-REP-EXT ::= [APPLICATION 7] Signed {
[APPLICATION 7] KDC-REP-EXT, [APPLICATION 7] KDC-REP-EXT,
{ key-reply }, { ku-ASRep-cksum } { key-reply }, { ku-ASRep-cksum }
} }
TGS-REP ::= CHOICE { TGS-REP ::= CHOICE {
rfc1510 TGS-REP-1510, rfc1510 TGS-REP-1510,
ext TGS-REP-EXT ext TGS-REP-EXT
} }
TGS-REP-1510 ::= [APPLICATION 13] KDC-REP-1510 { EncTGSRepPart1510 } TGS-REP-1510 ::= [APPLICATION 13] KDC-REP-1510 {
EncTGSRepPart1510 }
TGS-REP-EXT ::= [APPLICATION 9] Signed { TGS-REP-EXT ::= [APPLICATION 9] Signed {
[APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt }, [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt },
{ key-reply }, { ku-TGSRep-cksum } { key-reply }, { ku-TGSRep-cksum }
} }
The extensible versions of AS-REQ and TGS-REQ are signed with the The extensible versions of AS-REQ and TGS-REQ are signed with the
reply key, to prevent an attacker from performing a delayed denial- reply key, to prevent an attacker from performing a delayed denial-
of-service attack by substituting the ticket. of-service attack by substituting the ticket.
8.5. Reply Validation 8.5. Reply Validation
[ signature verification ] [ signature verification ]
8.6. IP Transports 8.6. IP Transports
[ KCLAR 7.2 ] [ RFC4120 7.2 ]
Kerberos defines two IP transport mechanisms for the credentials Kerberos defines two IP transport mechanisms for the credentials
acquisition protocol: UDP/IP and TCP/IP. acquisition protocol: UDP/IP and TCP/IP.
8.6.1. UDP/IP transport 8.6.1. UDP/IP transport
Kerberos servers (KDCs) supporting IP transports MUST accept UDP Kerberos servers (KDCs) supporting IP transports MUST accept UDP
requests and SHOULD listen for such requests on port 88 (decimal) requests and SHOULD listen for such requests on port 88 (decimal)
unless specifically configured to listen on an alternative UDP port. unless specifically configured to listen on an alternative UDP port.
Alternate ports MAY be used when running multiple KDCs for multiple Alternate ports MAY be used when running multiple KDCs for multiple
skipping to change at page 69, line 10 skipping to change at page 69, line 10
enc-part [2] EncryptedData { enc-part [2] EncryptedData {
EncApRepPart1510, EncApRepPart1510,
{ key-session | key-subsession }, { ku-EncAPRepPart }} { key-session | key-subsession }, { ku-EncAPRepPart }}
} }
AP-REP-EXT ::= [APPLICATION 19] Signed { AP-REP-EXT ::= [APPLICATION 19] Signed {
[APPLICATION 19] SEQUENCE { [APPLICATION 19] SEQUENCE {
pvno [0] INTEGER (5), pvno [0] INTEGER (5),
msg-type [1] INTEGER (19), msg-type [1] INTEGER (19),
enc-part [2] EncryptedData { enc-part [2] EncryptedData {
EncAPRepPartExt, EncAPRepPartExt,
{ key-session | key-subsession }, { ku-EncAPRepPart }}, { key-session | key-subsession },
{ ku-EncAPRepPart }},
..., ...,
extensions [3] ApRepExtensions OPTIONAL, extensions [3] ApRepExtensions OPTIONAL,
... ...
}, { key-session | key-subsession }, { ku-APRep-cksum } }, { key-session | key-subsession }, { ku-APRep-cksum }
} }
11. Session Key Use 11. Session Key Use
Once a session key has been established, the client and server can Once a session key has been established, the client and server can
use several kinds of messages to securely transmit data. KRB-SAFE use several kinds of messages to securely transmit data. KRB-SAFE
skipping to change at page 70, line 10 skipping to change at page 70, line 10
11.2. KRB-PRIV 11.2. KRB-PRIV
The KRB-PRIV message provides confidentiality and integrity The KRB-PRIV message provides confidentiality and integrity
protection. protection.
KRB-PRIV ::= [APPLICATION 21] SEQUENCE { KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
pvno [0] INTEGER (5), pvno [0] INTEGER (5),
msg-type [1] INTEGER (21), msg-type [1] INTEGER (21),
enc-part [3] EncryptedData { enc-part [3] EncryptedData {
EncKrbPrivPart, EncKrbPrivPart,
{ key-session | key-subsession }, { ku-EncKrbPrivPart }}, { key-session | key-subsession },
{ ku-EncKrbPrivPart }},
... ...
} }
EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE {
user-data [0] OCTET STRING, user-data [0] OCTET STRING,
timestamp [1] KerberosTime OPTIONAL, timestamp [1] KerberosTime OPTIONAL,
usec [2] Microseconds OPTIONAL, usec [2] Microseconds OPTIONAL,
seq-number [3] SeqNum OPTIONAL, seq-number [3] SeqNum OPTIONAL,
s-address [4] HostAddress -- sender's addr --, s-address [4] HostAddress -- sender's addr --,
r-address [5] HostAddress OPTIONAL -- recip's addr --, r-address [5] HostAddress OPTIONAL -- recip's addr --,
skipping to change at page 70, line 33 skipping to change at page 70, line 34
} }
11.3. KRB-CRED 11.3. KRB-CRED
The KRB-CRED message provides a means of securely transferring The KRB-CRED message provides a means of securely transferring
credentials from the client to the service. credentials from the client to the service.
KRB-CRED ::= CHOICE { KRB-CRED ::= CHOICE {
rfc1510 KRB-CRED-1510, rfc1510 KRB-CRED-1510,
ext KRB-CRED-EXT ext KRB-CRED-EXT
} }
KRB-CRED-1510 ::= [APPLICATION 22] SEQUENCE { KRB-CRED-1510 ::= [APPLICATION 22] SEQUENCE {
pvno [0] INTEGER (5), pvno [0] INTEGER (5),
msg-type [1] INTEGER (22), msg-type [1] INTEGER (22),
tickets [2] SEQUENCE OF Ticket, tickets [2] SEQUENCE OF Ticket,
enc-part [3] EncryptedData { enc-part [3] EncryptedData {
EncKrbCredPart, EncKrbCredPart,
{ key-session | key-subsession }, { ku-EncKrbCredPart }} { key-session | key-subsession },
{ ku-EncKrbCredPart }}
} }
KRB-CRED-EXT ::= [APPLICATION 24] Signed { KRB-CRED-EXT ::= [APPLICATION 24] Signed {
[APPLICATION 24] SEQUENCE { [APPLICATION 24] SEQUENCE {
pvno [0] INTEGER (5), pvno [0] INTEGER (5),
msg-type [1] INTEGER (24), msg-type [1] INTEGER (24),
tickets [2] SEQUENCE OF Ticket, tickets [2] SEQUENCE OF Ticket,
enc-part [3] EncryptedData { enc-part [3] EncryptedData {
EncKrbCredPart, EncKrbCredPart,
{ key-session | key-subsession }, { ku-EncKrbCredPart }}, { key-session | key-subsession },
{ ku-EncKrbCredPart }},
... ...
}, { key-session | key-subsession }, { ku-KrbCred-cksum } }, { key-session | key-subsession }, { ku-KrbCred-cksum }
} }
EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { EncKrbCredPart ::= [APPLICATION 29] SEQUENCE {
ticket-info [0] SEQUENCE OF KrbCredInfo, ticket-info [0] SEQUENCE OF KrbCredInfo,
nonce [1] Nonce OPTIONAL, nonce [1] Nonce OPTIONAL,
timestamp [2] KerberosTime OPTIONAL, timestamp [2] KerberosTime OPTIONAL,
usec [3] Microseconds OPTIONAL, usec [3] Microseconds OPTIONAL,
s-address [4] HostAddress OPTIONAL, s-address [4] HostAddress OPTIONAL,
skipping to change at page 72, line 15 skipping to change at page 72, line 15
12.2. Replays 12.2. Replays
12.3. Principal Name Reuse 12.3. Principal Name Reuse
See Section 5.3. See Section 5.3.
12.4. Password Guessing 12.4. Password Guessing
12.5. Forward Secrecy 12.5. Forward Secrecy
[from KCLAR 10.; needs some rewriting] [from RFC4120 10.; needs some rewriting]
The Kerberos protocol in its basic form does not provide perfect The Kerberos protocol in its basic form does not provide perfect
forward secrecy for communications. If traffic has been recorded by forward secrecy for communications. If traffic has been recorded by
an eavesdropper, then messages encrypted using the KRB-PRIV message, an eavesdropper, then messages encrypted using the KRB-PRIV message,
or messages encrypted using application-specific encryption under or messages encrypted using application-specific encryption under
keys exchanged using Kerberos can be decrypted if any of the user's, keys exchanged using Kerberos can be decrypted if any of the user's,
application server's, or KDC's key is subsequently discovered. This application server's, or KDC's key is subsequently discovered. This
is because the session key used to encrypt such messages is is because the session key used to encrypt such messages is
transmitted over the network encrypted in the key of the application transmitted over the network encrypted in the key of the application
server, and also encrypted under the session key from the user's server, and also encrypted under the session key from the user's
skipping to change at page 73, line 21 skipping to change at page 73, line 21
local and experimental extensions should use these values. Zero is local and experimental extensions should use these values. Zero is
reserved and may not be assigned. reserved and may not be assigned.
Typed hole contents may be identified by either Int32 values or by Typed hole contents may be identified by either Int32 values or by
RELATIVE-OID values. Since RELATIVE-OIDs define a hierarchical RELATIVE-OID values. Since RELATIVE-OIDs define a hierarchical
namespace, assignments to the top level of the RELATIVE-OID space may namespace, assignments to the top level of the RELATIVE-OID space may
be made on a first-come, first-served basis. be made on a first-come, first-served basis.
14. Acknowledgments 14. Acknowledgments
Much of the text here is adapted from draft-ietf-krb-wg-kerberos- Much of the text here is adapted from RFC 4120. The description of
clarifications-07. The description of the general form of the the general form of the extensibility framework was derived from text
extensibility framework was derived from text by Sam Hartman. Some by Sam Hartman. Some text concerning internationalization of
text concerning internationalization of internationalized domain internationalized domain names in principal names and realm names was
names in principal names and realm names was contributed by Jeffrey contributed by Jeffrey Altman and Jeffrey Hutzelman.
Altman and Jeffrey Hutzelman.
Appendices Appendices
A. ASN.1 Module (Normative) A. ASN.1 Module (Normative)
KerberosV5Spec3 { KerberosV5Spec3 {
iso(1) identified-organization(3) dod(6) internet(1) iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2) modules(4) krb5spec3(4) security(5) kerberosV5(2) modules(4) krb5spec3(4)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN } DEFINITIONS EXPLICIT TAGS ::= BEGIN
skipping to change at page 76, line 25 skipping to change at page 76, line 25
-- Service with host as remaining components -- Service with host as remaining components
nt-srv-xhst NameType ::= 4 nt-srv-xhst NameType ::= 4
-- Unique ID -- Unique ID
nt-uid NameType ::= 5 nt-uid NameType ::= 5
-- Encoded X.509 Distingished name [RFC 2253] -- Encoded X.509 Distingished name [RFC 2253]
nt-x500-principal NameType ::= 6 nt-x500-principal NameType ::= 6
-- Name in form of SMTP email name (e.g. user@foo.com) -- Name in form of SMTP email name (e.g. user@foo.com)
nt-smtp-name NameType ::= 7 nt-smtp-name NameType ::= 7
-- Enterprise name - may be mapped to principal name -- Enterprise name - may be mapped to principal name
nt-enterprise NameType ::= 10 nt-enterprise NameType ::= 10
-- reserved principal names [krb-wg-naming]
nt-wellknown NameType ::= 11
PrincipalName { StrType } ::= SEQUENCE { PrincipalName { StrType } ::= SEQUENCE {
name-type [0] NameType, name-type [0] NameType,
-- May have zero elements, or individual elements may be -- May have zero elements, or individual elements may be
-- zero-length, but this is NOT RECOMMENDED. -- zero-length, but this is NOT RECOMMENDED.
name-string [1] SEQUENCE OF KerberosString (StrType) name-string [1] SEQUENCE OF KerberosString (StrType)
} }
-- IA5 only -- IA5 only
PrincipalNameIA5 ::= PrincipalName { KerberosStringIA5 } PrincipalNameIA5 ::= PrincipalName { KerberosStringIA5 }
skipping to change at page 77, line 4 skipping to change at page 77, line 14
Realm { StrType } ::= KerberosString (StrType) Realm { StrType } ::= KerberosString (StrType)
-- IA5 only -- IA5 only
RealmIA5 ::= Realm { KerberosStringIA5 } RealmIA5 ::= Realm { KerberosStringIA5 }
-- IA5 excluded -- IA5 excluded
RealmExt ::= Realm { KerberosStringExt } RealmExt ::= Realm { KerberosStringExt }
-- Either -- Either
RealmEither ::= Realm { KerberosString } RealmEither ::= Realm { KerberosString }
KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX)) KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX))
(CONSTRAINED BY { (CONSTRAINED BY {
-- MUST be a valid value of -- NamedBits -- MUST be a valid value of -- NamedBits
-- but if the value to be sent would be truncated to shorter
-- than 32 bits according to DER, the value MUST be padded -- but if the value to be sent would be truncated to
-- with trailing zero bits to 32 bits. Otherwise, no -- shorter than 32 bits according to DER, the value MUST be
-- trailing zero bits may be present. -- padded with trailing zero bits to 32 bits. Otherwise,
-- no trailing zero bits may be present.
}) })
AddrType ::= Int32 AddrType ::= Int32
HostAddress ::= SEQUENCE { HostAddress ::= SEQUENCE {
addr-type [0] AddrType, addr-type [0] AddrType,
address [1] OCTET STRING address [1] OCTET STRING
} }
skipping to change at page 80, line 4 skipping to change at page 80, line 27
ku-kg-acceptor-seal KeyUsage ::= 22 ku-kg-acceptor-seal KeyUsage ::= 22
ku-kg-acceptor-sign KeyUsage ::= 23 ku-kg-acceptor-sign KeyUsage ::= 23
ku-kg-intiator-seal KeyUsage ::= 24 ku-kg-intiator-seal KeyUsage ::= 24
ku-kg-intiator-sign KeyUsage ::= 25 ku-kg-intiator-sign KeyUsage ::= 25
-- KeyUsage values 25..27 used by hardware preauth? -- KeyUsage values 25..27 used by hardware preauth?
-- for KINK -- for KINK
ku-kink-encrypt KeyUsage ::= 39 ku-kink-encrypt KeyUsage ::= 39
ku-kink-cksum KeyUsage ::= 40 ku-kink-cksum KeyUsage ::= 40
-- IAKERB
ku-iakerb-finished KeyUsage ::= 41
-- 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 84, line 33 skipping to change at page 85, line 33
ADType ::= TH-id ADType ::= TH-id
AuthorizationData ::= SEQUENCE OF SEQUENCE { AuthorizationData ::= SEQUENCE OF SEQUENCE {
ad-type [0] ADType, ad-type [0] ADType,
ad-data [1] OCTET STRING ad-data [1] OCTET STRING
} }
ad-if-relevant ADType ::= int32 : 1 ad-if-relevant ADType ::= int32 : 1
-- Encapsulates another AuthorizationData. -- Encapsulates another AuthorizationData.
-- Intended for application servers; receiving application servers -- Intended for application servers; receiving application
-- MAY ignore. -- servers MAY ignore.
AD-IF-RELEVANT ::= AuthorizationData AD-IF-RELEVANT ::= AuthorizationData
-- KDC-issued privilege attributes -- KDC-issued privilege attributes
ad-kdcissued ADType ::= int32 : 4 ad-kdcissued ADType ::= int32 : 4
AD-KDCIssued ::= SEQUENCE { AD-KDCIssued ::= SEQUENCE {
ad-checksum [0] ChecksumOf { ad-checksum [0] ChecksumOf {
AuthorizationData, { key-session }, AuthorizationData, { key-session },
{ ku-ad-KDCIssued-cksum }}, { ku-ad-KDCIssued-cksum }},
i-realm [1] Realm OPTIONAL, i-realm [1] Realm OPTIONAL,
skipping to change at page 86, line 37 skipping to change at page 87, line 37
-- --
AS-REQ ::= CHOICE { AS-REQ ::= CHOICE {
rfc1510 AS-REQ-1510, rfc1510 AS-REQ-1510,
ext AS-REQ-EXT ext AS-REQ-EXT
} }
AS-REQ-1510 ::= [APPLICATION 10] KDC-REQ-1510 AS-REQ-1510 ::= [APPLICATION 10] KDC-REQ-1510
-- AS-REQ must include client name -- AS-REQ must include client name
AS-REQ-EXT ::= [APPLICATION 6] Signed { AS-REQ-EXT ::= [APPLICATION 6] Signed {
[APPLICATION 6] KDC-REQ-EXT, { key-client }, { ku-ASReq-cksum } [APPLICATION 6] KDC-REQ-EXT,
{ key-client }, { ku-ASReq-cksum }
} }
-- AS-REQ must include client name -- AS-REQ must include client name
TGS-REQ ::= CHOICE { TGS-REQ ::= CHOICE {
rfc1510 TGS-REQ-1510, rfc1510 TGS-REQ-1510,
ext TGS-REQ-EXT ext TGS-REQ-EXT
} }
TGS-REQ-1510 ::= [APPLICATION 12] KDC-REQ-1510 TGS-REQ-1510 ::= [APPLICATION 12] KDC-REQ-1510
TGS-REQ-EXT ::= [APPLICATION 8] Signed { TGS-REQ-EXT ::= [APPLICATION 8] Signed {
[APPLICATION 8] KDC-REQ-EXT, { key-session }, { ku-TGSReq-cksum } [APPLICATION 8] KDC-REQ-EXT,
{ key-session }, { ku-TGSReq-cksum }
} }
KDC-REQ-1510 ::= SEQUENCE { KDC-REQ-1510 ::= SEQUENCE {
-- NOTE: first tag is [1], not [0] -- NOTE: first tag is [1], not [0]
pvno [1] INTEGER (5), pvno [1] INTEGER (5),
msg-type [2] INTEGER ( 10 -- AS-REQ -- msg-type [2] INTEGER ( 10 -- AS-REQ --
| 12 -- TGS-REQ -- ), | 12 -- TGS-REQ -- ),
padata [3] SEQUENCE OF PA-DATA OPTIONAL, padata [3] SEQUENCE OF PA-DATA OPTIONAL,
req-body [4] KDC-REQ-BODY-1510 req-body [4] KDC-REQ-BODY-1510
} }
KDC-REQ-EXT ::= SEQUENCE { KDC-REQ-EXT ::= SEQUENCE {
skipping to change at page 87, line 17 skipping to change at page 88, line 29
msg-type [2] INTEGER ( 10 -- AS-REQ -- msg-type [2] INTEGER ( 10 -- AS-REQ --
| 12 -- TGS-REQ -- ), | 12 -- TGS-REQ -- ),
padata [3] SEQUENCE OF PA-DATA OPTIONAL, padata [3] SEQUENCE OF PA-DATA OPTIONAL,
req-body [4] KDC-REQ-BODY-1510 req-body [4] KDC-REQ-BODY-1510
} }
KDC-REQ-EXT ::= SEQUENCE { KDC-REQ-EXT ::= SEQUENCE {
pvno [1] INTEGER (5), pvno [1] INTEGER (5),
msg-type [2] INTEGER ( 6 -- AS-REQ -- msg-type [2] INTEGER ( 6 -- AS-REQ --
| 8 -- TGS-REQ -- ), | 8 -- TGS-REQ -- ),
padata [3] SEQUENCE (SIZE (1..MAX)) OF PA-DATA OPTIONAL, padata [3] SEQUENCE (SIZE (1..MAX))
OF PA-DATA OPTIONAL,
req-body [4] KDC-REQ-BODY-EXT, req-body [4] KDC-REQ-BODY-EXT,
... ...
} }
KDC-REQ-BODY-1510 ::= SEQUENCE { KDC-REQ-BODY-1510 ::= SEQUENCE {
kdc-options [0] KDCOptions, kdc-options [0] KDCOptions,
cname [1] PrincipalNameIA5 OPTIONAL cname [1] PrincipalNameIA5 OPTIONAL
-- Used only in AS-REQ --, -- Used only in AS-REQ --,
realm [2] RealmIA5 realm [2] RealmIA5
-- Server's realm; also client's in AS-REQ --, -- Server's realm; also client's in AS-REQ --,
sname [3] PrincipalNameIA5 OPTIONAL, sname [3] PrincipalNameIA5 OPTIONAL,
from [4] KerberosTime OPTIONAL, from [4] KerberosTime OPTIONAL,
skipping to change at page 89, line 45 skipping to change at page 91, line 45
AS-REP-1510 ::= [APPLICATION 11] KDC-REP-1510 AS-REP-1510 ::= [APPLICATION 11] KDC-REP-1510
AS-REP-EXT ::= [APPLICATION 7] Signed { AS-REP-EXT ::= [APPLICATION 7] Signed {
[APPLICATION 7] KDC-REP-EXT, [APPLICATION 7] KDC-REP-EXT,
{ key-reply }, { ku-ASRep-cksum } { key-reply }, { ku-ASRep-cksum }
} }
TGS-REP ::= CHOICE { TGS-REP ::= CHOICE {
rfc1510 TGS-REP-1510, rfc1510 TGS-REP-1510,
ext TGS-REP-EXT ext TGS-REP-EXT
} }
TGS-REP-1510 ::= [APPLICATION 13] KDC-REP-1510 { EncTGSRepPart1510 } TGS-REP-1510 ::= [APPLICATION 13] KDC-REP-1510 {
EncTGSRepPart1510 }
TGS-REP-EXT ::= [APPLICATION 9] Signed { TGS-REP-EXT ::= [APPLICATION 9] Signed {
[APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt }, [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt },
{ key-reply }, { ku-TGSRep-cksum } { key-reply }, { ku-TGSRep-cksum }
} }
KDC-REP-1510 { EncPart } ::= SEQUENCE { KDC-REP-1510 { EncPart } ::= SEQUENCE {
pvno [0] INTEGER (5), pvno [0] INTEGER (5),
msg-type [1] INTEGER (11 -- AS-REP.rfc1510 -- | msg-type [1] INTEGER (11 -- AS-REP.rfc1510 -- |
13 -- TGS.rfc1510 -- ), 13 -- TGS.rfc1510 -- ),
padata [2] SEQUENCE OF PA-DATA OPTIONAL, padata [2] SEQUENCE OF PA-DATA OPTIONAL,
crealm [3] RealmIA5, crealm [3] RealmIA5,
skipping to change at page 97, line 10 skipping to change at page 99, line 10
enc-part [2] EncryptedData { enc-part [2] EncryptedData {
EncApRepPart1510, EncApRepPart1510,
{ key-session | key-subsession }, { ku-EncAPRepPart }} { key-session | key-subsession }, { ku-EncAPRepPart }}
} }
AP-REP-EXT ::= [APPLICATION 19] Signed { AP-REP-EXT ::= [APPLICATION 19] Signed {
[APPLICATION 19] SEQUENCE { [APPLICATION 19] SEQUENCE {
pvno [0] INTEGER (5), pvno [0] INTEGER (5),
msg-type [1] INTEGER (19), msg-type [1] INTEGER (19),
enc-part [2] EncryptedData { enc-part [2] EncryptedData {
EncAPRepPartExt, EncAPRepPartExt,
{ key-session | key-subsession }, { ku-EncAPRepPart }}, { key-session | key-subsession },
{ ku-EncAPRepPart }},
..., ...,
extensions [3] ApRepExtensions OPTIONAL, extensions [3] ApRepExtensions OPTIONAL,
... ...
}, { key-session | key-subsession }, { ku-APRep-cksum } }, { key-session | key-subsession }, { ku-APRep-cksum }
} }
ApRepExtType ::= TH-id ApRepExtType ::= TH-id
ApRepExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE { ApRepExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
apRepExt-Type [0] ApRepExtType, apRepExt-Type [0] ApRepExtType,
skipping to change at page 98, line 18 skipping to change at page 100, line 22
KRB-SAFE-1510 ::= [APPLICATION 20] SEQUENCE { KRB-SAFE-1510 ::= [APPLICATION 20] SEQUENCE {
pvno [0] INTEGER (5), pvno [0] INTEGER (5),
msg-type [1] INTEGER (20), msg-type [1] INTEGER (20),
safe-body [2] KRB-SAFE-BODY, safe-body [2] KRB-SAFE-BODY,
cksum [3] ChecksumOf { cksum [3] ChecksumOf {
KRB-SAFE-BODY, KRB-SAFE-BODY,
{ key-session | key-subsession }, { ku-KrbSafe-cksum }} { key-session | key-subsession }, { ku-KrbSafe-cksum }}
} }
-- Has safe-body optional to allow for GSS-MIC type functionality -- Has safe-body optional to allow for GSS-MIC type
-- functionality
KRB-SAFE-EXT ::= [APPLICATION 34] SEQUENCE { KRB-SAFE-EXT ::= [APPLICATION 34] SEQUENCE {
pvno [0] INTEGER (5), pvno [0] INTEGER (5),
msg-type [1] INTEGER (20), msg-type [1] INTEGER (20),
safe-body [2] KRB-SAFE-BODY OPTIONAL, safe-body [2] KRB-SAFE-BODY OPTIONAL,
cksum [3] ChecksumOf { cksum [3] ChecksumOf {
KRB-SAFE-BODY, KRB-SAFE-BODY,
{ key-session | key-subsession }, { ku-KrbSafe-cksum }}, { key-session | key-subsession },
{ ku-KrbSafe-cksum }},
... ...
} }
KRB-SAFE-BODY ::= SEQUENCE { KRB-SAFE-BODY ::= SEQUENCE {
user-data [0] OCTET STRING, user-data [0] OCTET STRING,
timestamp [1] KerberosTime OPTIONAL, timestamp [1] KerberosTime OPTIONAL,
usec [2] Microseconds OPTIONAL, usec [2] Microseconds OPTIONAL,
seq-number [3] SeqNum OPTIONAL, seq-number [3] SeqNum OPTIONAL,
s-address [4] HostAddress, s-address [4] HostAddress,
r-address [5] HostAddress OPTIONAL, r-address [5] HostAddress OPTIONAL,
skipping to change at page 98, line 39 skipping to change at page 101, line 4
KRB-SAFE-BODY ::= SEQUENCE { KRB-SAFE-BODY ::= SEQUENCE {
user-data [0] OCTET STRING, user-data [0] OCTET STRING,
timestamp [1] KerberosTime OPTIONAL, timestamp [1] KerberosTime OPTIONAL,
usec [2] Microseconds OPTIONAL, usec [2] Microseconds OPTIONAL,
seq-number [3] SeqNum OPTIONAL, seq-number [3] SeqNum OPTIONAL,
s-address [4] HostAddress, s-address [4] HostAddress,
r-address [5] HostAddress OPTIONAL, r-address [5] HostAddress OPTIONAL,
... -- ASN.1 extensions must be excluded ... -- ASN.1 extensions must be excluded
-- when sending to rfc1510 implementations -- when sending to rfc1510 implementations
} }
KRB-PRIV ::= [APPLICATION 21] SEQUENCE { KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
pvno [0] INTEGER (5), pvno [0] INTEGER (5),
msg-type [1] INTEGER (21), msg-type [1] INTEGER (21),
enc-part [3] EncryptedData { enc-part [3] EncryptedData {
EncKrbPrivPart, EncKrbPrivPart,
{ key-session | key-subsession }, { ku-EncKrbPrivPart }}, { key-session | key-subsession },
{ ku-EncKrbPrivPart }},
... ...
} }
EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE {
user-data [0] OCTET STRING, user-data [0] OCTET STRING,
timestamp [1] KerberosTime OPTIONAL, timestamp [1] KerberosTime OPTIONAL,
usec [2] Microseconds OPTIONAL, usec [2] Microseconds OPTIONAL,
seq-number [3] SeqNum OPTIONAL, seq-number [3] SeqNum OPTIONAL,
s-address [4] HostAddress -- sender's addr --, s-address [4] HostAddress -- sender's addr --,
r-address [5] HostAddress OPTIONAL -- recip's addr --, r-address [5] HostAddress OPTIONAL -- recip's addr --,
... -- ASN.1 extensions must be excluded ... -- ASN.1 extensions must be excluded
-- when sending to rfc1510 implementations -- when sending to rfc1510 implementations
} }
skipping to change at page 99, line 18 skipping to change at page 101, line 28
seq-number [3] SeqNum OPTIONAL, seq-number [3] SeqNum OPTIONAL,
s-address [4] HostAddress -- sender's addr --, s-address [4] HostAddress -- sender's addr --,
r-address [5] HostAddress OPTIONAL -- recip's addr --, r-address [5] HostAddress OPTIONAL -- recip's addr --,
... -- ASN.1 extensions must be excluded ... -- ASN.1 extensions must be excluded
-- when sending to rfc1510 implementations -- when sending to rfc1510 implementations
} }
KRB-CRED ::= CHOICE { KRB-CRED ::= CHOICE {
rfc1510 KRB-CRED-1510, rfc1510 KRB-CRED-1510,
ext KRB-CRED-EXT ext KRB-CRED-EXT
} }
KRB-CRED-1510 ::= [APPLICATION 22] SEQUENCE { KRB-CRED-1510 ::= [APPLICATION 22] SEQUENCE {
pvno [0] INTEGER (5), pvno [0] INTEGER (5),
msg-type [1] INTEGER (22), msg-type [1] INTEGER (22),
tickets [2] SEQUENCE OF Ticket, tickets [2] SEQUENCE OF Ticket,
enc-part [3] EncryptedData { enc-part [3] EncryptedData {
EncKrbCredPart, EncKrbCredPart,
{ key-session | key-subsession }, { ku-EncKrbCredPart }} { key-session | key-subsession },
{ ku-EncKrbCredPart }}
} }
KRB-CRED-EXT ::= [APPLICATION 24] Signed { KRB-CRED-EXT ::= [APPLICATION 24] Signed {
[APPLICATION 24] SEQUENCE { [APPLICATION 24] SEQUENCE {
pvno [0] INTEGER (5), pvno [0] INTEGER (5),
msg-type [1] INTEGER (24), msg-type [1] INTEGER (24),
tickets [2] SEQUENCE OF Ticket, tickets [2] SEQUENCE OF Ticket,
enc-part [3] EncryptedData { enc-part [3] EncryptedData {
EncKrbCredPart, EncKrbCredPart,
{ key-session | key-subsession }, { ku-EncKrbCredPart }}, { key-session | key-subsession },
{ ku-EncKrbCredPart }},
... ...
}, { key-session | key-subsession }, { ku-KrbCred-cksum } }, { key-session | key-subsession }, { ku-KrbCred-cksum }
} }
EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { EncKrbCredPart ::= [APPLICATION 29] SEQUENCE {
ticket-info [0] SEQUENCE OF KrbCredInfo, ticket-info [0] SEQUENCE OF KrbCredInfo,
nonce [1] Nonce OPTIONAL, nonce [1] Nonce OPTIONAL,
timestamp [2] KerberosTime OPTIONAL, timestamp [2] KerberosTime OPTIONAL,
usec [3] Microseconds OPTIONAL, usec [3] Microseconds OPTIONAL,
s-address [4] HostAddress OPTIONAL, s-address [4] HostAddress OPTIONAL,
r-address [5] HostAddress OPTIONAL r-address [5] HostAddress OPTIONAL
} }
KrbCredInfo ::= SEQUENCE { KrbCredInfo ::= SEQUENCE {
skipping to change at page 102, line 4 skipping to change at page 104, line 35
} }
METHOD-DATA ::= SEQUENCE OF PA-DATA METHOD-DATA ::= SEQUENCE OF PA-DATA
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
} }
td-dh-parameters TDType ::= int32 : 109
td-dh-parameters TDType ::= int32 : 109
-- iakerb
td-iakerb-finished TDType ::= int32 : 110
-- pkinit-alg-agility
td-cms-data-digest-algorithms TDType ::= int32 : 111
-- pkinit-alg-agility
td-cert-digest-algorithms TDType ::= int32 : 112
-- --
-- *** Error codes -- *** Error codes
-- --
-- No error -- No error
kdc-err-none ErrCode ::= 0 kdc-err-none ErrCode ::= 0
-- Client's entry in database has expired -- Client's entry in database has expired
kdc-err-name-exp ErrCode ::= 1 kdc-err-name-exp ErrCode ::= 1
-- Server's entry in database has expired -- Server's entry in database has expired
kdc-err-service-exp ErrCode ::= 2 kdc-err-service-exp ErrCode ::= 2
skipping to change at page 105, line 46 skipping to change at page 108, line 46
-- Reserved for PKINIT -- Reserved for PKINIT
kdc-err-inconsistent-key-purpose ErrCode ::= 77 kdc-err-inconsistent-key-purpose ErrCode ::= 77
-- Reserved for PKINIT -- Reserved for PKINIT
kdc-err-digest-in-cert-not-accepted ErrCode ::= 78 kdc-err-digest-in-cert-not-accepted ErrCode ::= 78
-- Reserved for PKINIT -- Reserved for PKINIT
kdc-err-pa-checksum-must-be-included ErrCode ::= 79 kdc-err-pa-checksum-must-be-included ErrCode ::= 79
-- Reserved for PKINIT -- Reserved for PKINIT
kdc-err-digest-in-signed-data-not-accepted ErrCode ::= 80 kdc-err-digest-in-signed-data-not-accepted ErrCode ::= 80
-- Reserved for PKINIT -- Reserved for PKINIT
kdc-err-public-key-encryption-not-supported ErrCode ::= 81 kdc-err-public-key-encryption-not-supported ErrCode ::= 81
-- [krb-wg-naming]
krb-ap-err-wellknown-principal-name-unsupported ErrCode ::= 82
-- [krb-wg-naming]
krb-ap-err-wellknown-realm-name-not-supported ErrCode ::= 83
-- [krb-wg-naming]
krb-ap-err-reserved-principal-name-unknown ErrCode ::= 84
-- IAKERB proxy could not find a KDC
krb-ap-err-iakerb-kdc-not-found ErrCode ::= 85
-- KDC did not respond to IAKERB proxy
krb-ap-err-iakerb-kdc-no-response ErrCode ::= 86
END END
B. Kerberos and Character Encodings (Informative) B. Kerberos and Character Encodings (Informative)
[adapted from KCLAR 5.2.1] [adapted from RFC4120 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 20 skipping to change at page 110, line 30
is a different encoding, not a 94 or 96 character "G" set as defined is a different encoding, not a 94 or 96 character "G" set as defined
by ISO 2022. It is believed that these implementations do not even by ISO 2022. It is believed that these implementations do not even
use the ISO 2022 escape sequence to change the character encoding. use the ISO 2022 escape sequence to change the character encoding.
Even if implementations were to announce the change of encoding by Even if implementations were to announce the change of encoding by
using that escape sequence, the ASN.1 standard prohibits the use of using that escape sequence, the ASN.1 standard prohibits the use of
any escape sequences other than those used to designate/invoke "G" or any escape sequences other than those used to designate/invoke "G" or
"C" sets allowed by GeneralString. "C" sets allowed by GeneralString.
C. Kerberos History (Informative) C. Kerberos History (Informative)
[Adapted from KCLAR "BACKGROUND"] [Adapted from RFC4120 "BACKGROUND"]
The Kerberos model is based in part on Needham and Schroeder's The Kerberos model is based in part on Needham and Schroeder's
trusted third-party authentication protocol [NS78] and on trusted third-party authentication protocol [NS78] and on
modifications suggested by Denning and Sacco [DS81]. The original modifications suggested by Denning and Sacco [DS81]. The original
design and implementation of Kerberos Versions 1 through 4 was the design and implementation of Kerberos Versions 1 through 4 was the
work of two former Project Athena staff members, Steve Miller of work of two former Project Athena staff members, Steve Miller of
Digital Equipment Corporation and Clifford Neuman (now at the Digital Equipment Corporation and Clifford Neuman (now at the
Information Sciences Institute of the University of Southern Information Sciences Institute of the University of Southern
California), along with Jerome Saltzer, Technical Director of Project California), along with Jerome Saltzer, Technical Director of Project
Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other
skipping to change at page 107, line 51 skipping to change at page 111, line 10
issued, extensions and revisions to the protocol have been proposed issued, extensions and revisions to the protocol have been proposed
by many individuals. Some of these proposals are reflected in this by many individuals. Some of these proposals are reflected in this
document. Where such changes involved significant effort, the document. Where such changes involved significant effort, the
document cites the contribution of the proposer. document cites the contribution of the proposer.
Reference implementations of both version 4 and version 5 of Kerberos Reference implementations of both version 4 and version 5 of Kerberos
are publicly available and commercial implementations have been are publicly available and commercial implementations have been
developed and are widely used. Details on the differences between developed and are widely used. Details on the differences between
Kerberos Versions 4 and 5 can be found in [KNT94]. Kerberos Versions 4 and 5 can be found in [KNT94].
D. Notational Differences from [KCLAR] D. Notational Differences from [RFC4120]
[ possible point for discussion ] [ possible point for discussion ]
[KCLAR] uses notational conventions slightly different from this
document. As a derivative of RFC 1510, the text of [KCLAR] uses C- [RFC4120] uses notational conventions slightly different from this
language style identifier names for defined values. In ASN.1 document. As a derivative of RFC 1510, the text of [RFC4120] uses
C-language style identifier names for defined values. In ASN.1
notation, identifiers referencing defined values must begin with a notation, identifiers referencing defined values must begin with a
lowercase letter and contain hyphen (-) characters rather than lowercase letter and contain hyphen (-) characters rather than
underscore (_) characters, while identifiers referencing types begin underscore (_) characters, while identifiers referencing types begin
with an uppercase letter. [KCLAR] and RFC 1510 use all-uppercase with an uppercase letter. [RFC4120] and RFC 1510 use all-uppercase
identifiers with underscores to identify defined values. This has identifiers with underscores to identify defined values. This has
the potential to create confusion, but neither document defines the potential to create confusion, but neither document defines
values using actual ASN.1 value-assignment notation. values using actual ASN.1 value-assignment notation.
It is debatable whether it is advantageous to write all identifier It is debatable whether it is advantageous to write all identifier
names (regardless of their ASN.1 token type) in all-uppercase letters names (regardless of their ASN.1 token type) in all-uppercase letters
for the purpose of emphasis in running text. The alternative is to for the purpose of emphasis in running text. The alternative is to
use double-quote characters (") when ambiguity is possible. use double-quote characters (") when ambiguity is possible.
Normative References Normative References
[ISO646] [RFC2119]
"7-bit coded character set", ISO/IEC 646:1991 | ECMA-6:1991. S. Bradner, "Key words for use in RFC's to Indicate Requirement
Levels", RFC 2119, March 1997.
[ISO2022] [RFC3490]
"Information technology -- Character code structure and P. Faltstrom, P. Hoffman, A. Costello, "Internationalizing
extension techniques", ISO/IEC 2022:1994 | ECMA-35:1994. Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[KCRYPTO] [RFC3961]
K. Raeburn, "Encryption and Checksum Specifications for Kerberos K. Raeburn, "Encryption and Checksum Specifications for Kerberos
5", draft-ietf-krb-wg-crypto-07.txt, work in progress. 5", RFC 3961, February 2005.
[RFC2119] [RFC4013]
S. Bradner, RFC2119: "Key words for use in RFC's to Indicate Kurt D. Zeilenga, "SASLprep: Stringprep profile for user names
Requirement Levels", March 1997. and passwords", RFC 4013, February 2005.
[RFC3660] [RFC4291]
H. Alvestrand, "Tags for the Identification of Languages", R. Hinden and S. Deering, "IP Version 6 Addressing
RFC 3660, January 2001. Architecture", RFC 4291, February 2006.
[SASLPREP] [RFC4646]
Kurt D. Zeilenga, "SASLprep: Stringprep profile for user names A. Philllips and M. Davis, "Tags for Identifying Languages",
and passwords", draft-ietf-sasl-saslprep-10.txt, work in RFC 4646, January 2001.
progress.
[X680] [X680]
"Information technology -- Abstract Syntax Notation One (ASN.1): "Information technology -- Abstract Syntax Notation One (ASN.1):
Specification of basic notation", ITU-T Recommendation X.680 Specification of basic notation", ITU-T Recommendation X.680
(2002) | ISO/IEC 8824-1:2002. (2002) | ISO/IEC 8824-1:2002.
[X682] [X682]
"Information technology -- Abstract Syntax Notation One (ASN.1): "Information technology -- Abstract Syntax Notation One (ASN.1):
Constraint specification", ITU-T Recommendation X.682 (2002) | Constraint specification", ITU-T Recommendation X.682 (2002) |
ISO/IEC 8824-3:2002. ISO/IEC 8824-3:2002.
skipping to change at page 109, line 28 skipping to change at page 112, line 38
[DS81] [DS81]
Dorothy E. Denning and Giovanni Maria Sacco, "Time-stamps in Key Dorothy E. Denning and Giovanni Maria Sacco, "Time-stamps in Key
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>
[ISO646]
"7-bit coded character set", ISO/IEC 646:1991 | ECMA-6:1991.
[ISO2022]
"Information technology -- Character code structure and
extension techniques", ISO/IEC 2022:1994 | ECMA-35:1994.
[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 8859- character sets -- Part 1: Latin alphabet No. 1",
1:1998. ISO/IEC 8859-1:1998.
[KCLAR]
Clifford Neuman, Tom Yu, Sam Hartman, Ken Raeburn, "The Kerberos
Network Authentication Service (V5)", draft-ietf-krb-wg-
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
Press, 1994. Press, 1994.
[Lar96] [Lar96]
John Larmouth, "Understanding OSI", International Thomson John Larmouth, "Understanding OSI", International Thomson
Computer Press, 1996. Computer Press, 1996.
skipping to change at page 110, line 15 skipping to change at page 113, line 28
[RFC1510] [RFC1510]
J. Kohl and B. C. Neuman, "The Kerberos Network Authentication J. Kohl and B. C. Neuman, "The Kerberos Network Authentication
Service (v5)", RFC1510, September 1993, Status: Proposed Service (v5)", RFC1510, September 1993, Status: Proposed
Standard. Standard.
[RFC1964] [RFC1964]
J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,
June 1996, Status: Proposed Standard. June 1996, Status: Proposed Standard.
[X690-2002] [RFC4120]
"Information technology -- ASN.1 encoding rules: Specification C. Neuman, T. Yu, S. Hartman, K. Raeburn, "The Kerberos Network
of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) Authentication Service (V5)", RFC 4120, July 2005.
and Distinguished Encoding Rules (DER)", ITU-T Recommendation
X.690 (2002) | ISO/IEC 8825-1:2002.
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 Full Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The IETF Trust (2007).
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. This document is subject to the rights, licenses and restrictions
contained in BCP 78, and 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, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE 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.
Intellectual Property Statement Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. ietf-ipr@ietf.org.
 End of changes. 112 change blocks. 
236 lines changed or deleted 233 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/