draft-ietf-krb-wg-rfc1510ter-01.txt   draft-ietf-krb-wg-rfc1510ter-02.txt 
INTERNET-DRAFT Tom Yu INTERNET-DRAFT Tom Yu
draft-ietf-krb-wg-rfc1510ter-01.txt MIT draft-ietf-krb-wg-rfc1510ter-02.txt MIT
Expires: 19 March 2005 15 September 2005 Expires: 26 April 2006 23 October 2005
The Kerberos Network Authentication Service (Version 5) The Kerberos Network Authentication Service (Version 5)
Status of This Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 2, line 16 skipping to change at page 2, line 16
Status of This Memo .............................................. 1 Status of This Memo .............................................. 1
Copyright Notice ................................................. 1 Copyright Notice ................................................. 1
Abstract ......................................................... 1 Abstract ......................................................... 1
Key Words for Requirements ....................................... 1 Key Words for Requirements ....................................... 1
Table of Contents ................................................ 2 Table of Contents ................................................ 2
1. Introduction ................................................. 5 1. Introduction ................................................. 5
1.1. Kerberos Protocol Overview ................................. 5 1.1. Kerberos Protocol Overview ................................. 5
1.2. Document Organization ...................................... 6 1.2. Document Organization ...................................... 6
2. Compatibility Considerations ................................. 6 2. Compatibility Considerations ................................. 6
2.1. Extensibility .............................................. 7 2.1. Extensibility .............................................. 6
2.2. Compatibility with RFC 1510 ................................ 7 2.2. Compatibility with RFC 1510 ................................ 7
2.3. Backwards Compatibility .................................... 7 2.3. Backwards Compatibility .................................... 7
2.4. 1.4.2. Sending Extensible Messages ......................... 8 2.4. Sending Extensible Messages ................................ 8
2.5. Criticality ................................................ 8 2.5. Criticality ................................................ 8
2.6. Authenticating Cleartext Portions of Messages .............. 9 2.6. Authenticating Cleartext Portions of Messages .............. 9
2.7. Capability Negotiation ..................................... 10 2.7. Capability Negotiation ..................................... 10
3. Use of ASN.1 in Kerberos ..................................... 10 3. Use of ASN.1 in Kerberos ..................................... 10
3.1. Module Header .............................................. 11 3.1. Module Header .............................................. 11
3.2. Top-Level Type ............................................. 11 3.2. Top-Level Type ............................................. 11
3.3. Previously Unused ASN.1 Notation (informative) ............. 12 3.3. Previously Unused ASN.1 Notation (informative) ............. 12
3.3.1. Parameterized Types ...................................... 12 3.3.1. Parameterized Types ...................................... 12
3.3.2. COMPONENTS OF Notation ................................... 12 3.3.2. Constraints .............................................. 12
3.3.3. Constraints .............................................. 12 3.4. New Types .................................................. 12
3.4. New Types .................................................. 13 4. Basic Types .................................................. 12
4. Basic Types .................................................. 14 4.1. Constrained Integer Types .................................. 12
4.1. Constrained Integer Types .................................. 14 4.2. KerberosTime ............................................... 13
4.2. KerberosTime ............................................... 15 4.3. KerberosString ............................................. 14
4.3. KerberosString ............................................. 15 4.4. Language Tags .............................................. 14
4.4. Language Tags .............................................. 16 4.5. KerberosFlags .............................................. 14
4.5. KerberosFlags .............................................. 16 4.6. Typed Holes ................................................ 15
4.6. Typed Holes ................................................ 16 4.7. HostAddress and HostAddresses .............................. 15
4.7. HostAddress and HostAddresses .............................. 17 4.7.1. Internet (IPv4) Addresses ................................ 16
4.7.1. Internet (IPv4) Addresses ................................ 17 4.7.2. Internet (IPv6) Addresses ................................ 16
4.7.2. Internet (IPv6) Addresses ................................ 17 4.7.3. DECnet Phase IV addresses ................................ 17
4.7.3. DECnet Phase IV addresses ................................ 18 4.7.4. Netbios addresses ........................................ 17
4.7.4. Netbios addresses ........................................ 18 4.7.5. Directional Addresses .................................... 17
4.7.5. Directional Addresses .................................... 18 5. Principals ................................................... 17
5. Principals ................................................... 19 5.1. Name Types ................................................. 17
5.1. Name Types ................................................. 19 5.2. Principal Type Definition .................................. 18
5.2. Principal Type Definition .................................. 19 5.3. Principal Name Reuse ....................................... 19
5.3. Principal Name Reuse ....................................... 20 5.4. Best Common Practice Recommendations for the Processing
5.4. Realm Names ................................................ 20 of Principal Names Consisting of Internationalized
5.5. Printable Representations of Principal Names ............... 21 Domain Names: ........................................... 19
5.6. Ticket-Granting Service Principal .......................... 21 5.5. Realm Names ................................................ 20
5.6.1. Cross-Realm TGS Principals ............................... 21 5.6. Best Common Practice Recommendations for the Processing
6. Types Relating to Encryption ................................. 21 of Internationalized Domain-Style Realm Names: .......... 20
5.7. Printable Representations of Principal Names ............... 21
5.8. Ticket-Granting Service Principal .......................... 21
5.8.1. Cross-Realm TGS Principals ............................... 22
6. Types Relating to Encryption ................................. 22
6.1. Assigned Numbers for Encryption ............................ 22 6.1. Assigned Numbers for Encryption ............................ 22
6.1.1. EType .................................................... 22 6.1.1. EType .................................................... 22
6.1.2. Key Usages ............................................... 22 6.1.2. Key Usages ............................................... 23
6.2. Which Key to Use ........................................... 23 6.2. Which Key to Use ........................................... 24
6.3. EncryptionKey .............................................. 24 6.3. EncryptionKey .............................................. 25
6.4. EncryptedData .............................................. 24 6.4. EncryptedData .............................................. 25
6.5. Checksums .................................................. 25 6.5. Checksums .................................................. 26
6.5.1. ChecksumOf ............................................... 26 6.5.1. ChecksumOf ............................................... 27
6.5.2. Signed ................................................... 27 6.5.2. Signed ................................................... 28
7. Tickets ...................................................... 27 7. Tickets ...................................................... 28
7.1. Timestamps ................................................. 28 7.1. Timestamps ................................................. 29
7.2. Ticket Flags ............................................... 28 7.2. Ticket Flags ............................................... 30
7.2.1. Flags Relating to Initial Ticket Acquisition ............. 29 7.2.1. Flags Relating to Initial Ticket Acquisition ............. 30
7.2.2. Invalid Tickets .......................................... 29 7.2.2. Invalid Tickets .......................................... 31
7.2.3. OK as Delegate ........................................... 30 7.2.3. OK as Delegate ........................................... 31
7.2.4. Renewable Tickets ........................................ 30 7.2.4. Renewable Tickets ........................................ 32
7.2.5. Postdated Tickets ........................................ 31 7.2.5. Postdated Tickets ........................................ 32
7.2.6. Proxiable and Proxy Tickets .............................. 32 7.2.6. Proxiable and Proxy Tickets .............................. 33
7.2.7. Forwarded and Forwardable Tickets ........................ 33 7.2.7. Forwarded and Forwardable Tickets ........................ 34
7.3. Transited Realms ........................................... 34 7.3. Transited Realms ........................................... 35
7.4. Authorization Data ......................................... 34 7.4. Authorization Data ......................................... 35
7.4.1. AD-IF-RELEVANT ........................................... 35 7.4.1. AD-IF-RELEVANT ........................................... 36
7.4.2. AD-KDCIssued ............................................. 35 7.4.2. AD-KDCIssued ............................................. 37
7.4.3. AD-AND-OR ................................................ 37 7.4.3. AD-AND-OR ................................................ 38
7.4.4. AD-MANDATORY-FOR-KDC ..................................... 37 7.4.4. AD-MANDATORY-FOR-KDC ..................................... 38
7.5. Encrypted Part of Ticket ................................... 37 7.5. Encrypted Part of Ticket ................................... 39
7.6. Cleartext Part of Ticket ................................... 38 7.6. Cleartext Part of Ticket ................................... 39
8. Credential Acquisition ....................................... 40 8. Credential Acquisition ....................................... 41
8.1. KDC-REQ .................................................... 40 8.1. KDC-REQ .................................................... 41
8.2. PA-DATA .................................................... 46 8.2. PA-DATA .................................................... 48
8.3. KDC-REQ Processing ......................................... 46 8.3. KDC-REQ Processing ......................................... 48
8.3.1. Handling Replays ......................................... 46 8.3.1. Handling Replays ......................................... 48
8.3.2. Request Validation ....................................... 47 8.3.2. Request Validation ....................................... 49
8.3.2.1. AS-REQ Authentication .................................. 47 8.3.2.1. AS-REQ Authentication .................................. 49
8.3.2.2. TGS-REQ Authentication ................................. 47 8.3.2.2. TGS-REQ Authentication ................................. 49
8.3.2.3. Principal Validation ................................... 47 8.3.2.3. Principal Validation ................................... 49
8.3.2.4. Checking For Revoked or Invalid Tickets ................ 48 8.3.2.4. Checking For Revoked or Invalid Tickets ................ 49
8.3.3. Timestamp Handling ....................................... 48 8.3.3. Timestamp Handling ....................................... 50
8.3.3.1. AS-REQ Timestamp Processing ............................ 49 8.3.3.1. AS-REQ Timestamp Processing ............................ 50
8.3.3.2. TGS-REQ Timestamp Processing ........................... 49 8.3.3.2. TGS-REQ Timestamp Processing ........................... 51
8.3.4. Handling Transited Realms ................................ 50 8.3.4. Handling Transited Realms ................................ 52
8.3.5. Address Processing ....................................... 50 8.3.5. Address Processing ....................................... 52
8.3.6. Ticket Flag Processing ................................... 51 8.3.6. Ticket Flag Processing ................................... 52
8.3.7. Key Selection ............................................ 52 8.3.7. Key Selection ............................................ 54
8.3.7.1. Reply Key and Session Key Selection .................... 52 8.3.7.1. Reply Key and Session Key Selection .................... 54
8.3.7.2. Ticket Key Selection ................................... 52 8.3.7.2. Ticket Key Selection ................................... 54
8.4. KDC-REP .................................................... 52 8.4. KDC-REP .................................................... 54
8.5. Reply Validation ........................................... 55 8.5. Reply Validation ........................................... 58
8.6. IP Transports .............................................. 55 8.6. IP Transports .............................................. 58
8.6.1. UDP/IP transport ......................................... 55 8.6.1. UDP/IP transport ......................................... 58
8.6.2. TCP/IP transport ......................................... 56 8.6.2. TCP/IP transport ......................................... 58
8.6.3. KDC Discovery on IP Networks ............................. 57 8.6.3. KDC Discovery on IP Networks ............................. 60
8.6.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names ..... 57 8.6.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names ..... 60
8.6.3.2. DNS SRV records for KDC location ....................... 58 8.6.3.2. DNS SRV records for KDC location ....................... 60
8.6.3.3. KDC Discovery for Domain Style Realm Names on IP 8.6.3.3. KDC Discovery for Domain Style Realm Names on IP
Networks ............................................ 58 Networks ............................................ 61
9. Errors ....................................................... 58 9. Errors ....................................................... 61
10. Session Key Exchange ........................................ 61 10. Session Key Exchange ........................................ 63
10.1. AP-REQ .................................................... 61 10.1. AP-REQ .................................................... 64
10.2. AP-REP .................................................... 63 10.2. AP-REP .................................................... 65
11. Session Key Use ............................................. 65 11. Session Key Use ............................................. 67
11.1. KRB-SAFE .................................................. 65 11.1. KRB-SAFE .................................................. 67
11.2. KRB-PRIV .................................................. 65 11.2. KRB-PRIV .................................................. 67
11.3. KRB-CRED .................................................. 66 11.3. KRB-CRED .................................................. 68
12. Security Considerations ..................................... 67 12. Security Considerations ..................................... 69
12.1. Time Synchronization ...................................... 67 12.1. Time Synchronization ...................................... 69
12.2. Replays ................................................... 67 12.2. Replays ................................................... 69
12.3. Principal Name Reuse ...................................... 67 12.3. Principal Name Reuse ...................................... 70
12.4. Password Guessing ......................................... 67 12.4. Password Guessing ......................................... 70
12.5. Forward Secrecy ........................................... 67 12.5. Forward Secrecy ........................................... 70
12.6. Authorization ............................................. 68 12.6. Authorization ............................................. 70
12.7. Login Authentication ...................................... 68 12.7. Login Authentication ...................................... 70
13. IANA Considerations ......................................... 68 13. IANA Considerations ......................................... 70
14. Acknowledgments ............................................. 69 14. Acknowledgments ............................................. 71
Appendices ....................................................... 69 Appendices ....................................................... 71
A. ASN.1 Module (Normative) ..................................... 69 A. ASN.1 Module (Normative) ..................................... 71
B. Kerberos and Character Encodings (Informative) ...............103 B. Kerberos and Character Encodings (Informative) ...............103
C. Kerberos History (Informative) ...............................104 C. Kerberos History (Informative) ...............................104
D. Notational Differences from [KCLAR] ..........................105 D. Notational Differences from [KCLAR] ..........................105
Normative References .............................................106 Normative References .............................................106
Informative References ...........................................106 Informative References ...........................................106
Author's Address .................................................108 Author's Address .................................................108
Copyright Statement ..............................................108 Copyright Statement ..............................................108
Intellectual Property Statement ..................................108 Intellectual Property Statement ..................................108
1. Introduction 1. Introduction
skipping to change at page 7, line 49 skipping to change at page 7, line 47
results in undefined behavior. Examples of this behavior are known results in undefined behavior. Examples of this behavior are known
to include discarding messages with no error indications. to include discarding messages with no error indications.
Where messages have been changed since RFC 1510, ASN.1 CHOICE types Where messages have been changed since RFC 1510, ASN.1 CHOICE types
are used; one alternative of the CHOICE provides a message which is are used; one alternative of the CHOICE provides a message which is
wire-encoding compatible with RFC 1510, and the other alternative wire-encoding compatible with RFC 1510, and the other alternative
provides the new, extensible message. provides the new, extensible message.
Implementations sending new messages MUST ensure that the recipient Implementations sending new messages MUST ensure that the recipient
supports these new messages. Along with each extensible message is a supports these new messages. Along with each extensible message is a
guideline for when that message MAY be used. IF that guideline is guideline for when that message MAY be used. If that guideline is
followed, then the recipient is guaranteed to understand the message. followed, then the recipient is guaranteed to understand the message.
2.3. Backwards Compatibility 2.3. Backwards Compatibility
This document describes two sets (for the most part) of ASN.1 types. This document describes two sets (for the most part) of ASN.1 types.
The first set of types is wire-encoding compatible with RFC 1510 and The first set of types is wire-encoding compatible with RFC 1510 and
[KCLAR]. The second set of types is the set of types enabling [KCLAR]. The second set of types is the set of types enabling
extensibility. This second set may be referred to as extensibility. This second set may be referred to as "extensibility-
"extensibility-enabled types". [ need to make this consistent 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
necessarily requiring explicit configuration. necessarily requiring explicit configuration.
An extensibility-enabled client can detect whether a KDC supports the An extensibility-enabled client can detect whether a KDC supports the
extensibility-enabled types by requesting an extensibility-enabled extensibility-enabled types by requesting an extensibility-enabled
reply. If the KDC replies with an extensibility-enabled reply, the reply. If the KDC replies with an extensibility-enabled reply, the
client knows that the KDC supports extensibility. If the KDC issues client knows that the KDC supports extensibility. If the KDC issues
an extensibility-enabled ticket, the client knows that the service an extensibility-enabled ticket, the client knows that the service
named in the ticket is extensibility-enabled. named in the ticket is extensibility-enabled.
2.4. 1.4.2. Sending Extensible Messages 2.4. Sending Extensible Messages
Care must be taken to make sure that old implementations can Care must be taken to make sure that old implementations can
understand messages sent to them even if they do not understand an understand messages sent to them even if they do not understand an
extension that is used. Unless the sender knows the extension is extension that is used. Unless the sender knows the extension is
supported, the extension cannot change the semantics of the core supported, the extension cannot change the semantics of the core
message or previously defined extensions. message or previously defined extensions.
For example, an extension including key information necessary to For example, an extension including key information necessary to
decrypt the encrypted part of a KDC-REP could only be used in decrypt the encrypted part of a KDC-REP could only be used in
situations where the recipient was known to support the extension. situations where the recipient was known to support the extension.
skipping to change at page 9, line 53 skipping to change at page 9, line 52
The extensible variants of the messages described in this document The extensible variants of the messages described in this document
wrap the actual message in an ASN.1 sequence containing a keyed wrap the actual message in an ASN.1 sequence containing a keyed
checksum of the contents of the message. Guidelines in [XXX] section checksum of the contents of the message. Guidelines in [XXX] section
3 specify when the checksum MUST be included and what key MUST be 3 specify when the checksum MUST be included and what key MUST be
used. Guidelines on when to include a checksum are never ambiguous: used. Guidelines on when to include a checksum are never ambiguous:
a particular PDU is never correct both with and without a checksum. a particular PDU is never correct both with and without a checksum.
With the exception of the KRB-ERROR message, receiving With the exception of the KRB-ERROR message, receiving
implementations MUST reject messages where a checksum is included and implementations MUST reject messages where a checksum is included and
not expected or where a checksum is expected but not included. The not expected or where a checksum is expected but not included. The
receiving implementation does not always have sufficient information receiving implementation does not always have sufficient information
to know whether a KRB-ERROR should contain a checksum. Even so, to know whether a KRB-ERROR should contain a checksum. Even so, KRB-
KRB-ERROR messages with invalid checksums MUST be rejected and ERROR messages with invalid checksums MUST be rejected and
implementations MAY consider the presence or absence of a checksum implementations MAY consider the presence or absence of a checksum
when evaluating whether to trust the error. when evaluating whether to trust the error.
This authenticated cleartext protection is provided only in the This authenticated cleartext protection is provided only in the
extensible variants of the messages; it is never used when extensible variants of the messages; it is never used when
communicating with an RFC 1510 implementation. communicating with an RFC 1510 implementation.
2.7. Capability Negotiation 2.7. Capability Negotiation
Kerberos is a three-party protocol. Each of the three parties Kerberos is a three-party protocol. Each of the three parties
skipping to change at page 12, line 41 skipping to change at page 12, line 20
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.
3.3.2. COMPONENTS OF Notation 3.3.2. Constraints
The "COMPONENTS OF" notation, used to define the RFC 1510
compatibility types, extracts all of the component types of an ASN.1
SEQUENCE type. The extension marker (the "..." notation) and any
extension components are not extracted by "COMPONENTS OF". The
"COMPONENTS OF" notation permits concise definition of multiple types
which have many components in common with each other.
3.3.3. Constraints
This document uses ASN.1 constraints, including the This document uses ASN.1 constraints, including the
"UserDefinedConstraint" notation [X682]. Some constraints can be "UserDefinedConstraint" notation [X682]. Some constraints can be
handled automatically by tools that can parse them. Uses of the handled automatically by tools that can parse them. Uses of the
"UserDefinedConstraint" notation (the "CONSTRAINED BY" notation) will "UserDefinedConstraint" notation (the "CONSTRAINED BY" notation) will
typically need to have behavior manually coded; the notation provides typically need to have behavior manually coded; the notation provides
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 [KCLAR]. The names of these types will typically have a suffix like
"Ext", indicating that the types are intended to support "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 [KCLAR] 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; these common elements have often contain a number of common elements, but differ primarily in
a suffix like "Common". The "1510" types have various ASN.1 the way strings are encoded.
constraints applied to them; the constraints limit the possible
values of the "1510" types to those permitted by RFC 1510 or by
[KCLAR]. The "Ext" types may have different constraints, typically
to force string values to be sent as UTF-8.
For example, consider
-- example "common" type
Foo-Common ::= SEQUENCE {
a [0] INTEGER,
b [1] OCTET STRING,
...,
c [2] INTEGER,
...
}
-- example "RFC 1510 compatibility" type
Foo-1510 ::= SEQUENCE {
-- the COMPONENTS OF notation drops the extension marker
-- and all extension additions.
COMPONENTS OF Foo-Common
}
-- example "extensibility-enabled" type
Foo-Ext ::= Foo-Common
where "Foo-Common" is a common type used to define both the "1510"
and "Ext" versions of a type. "Foo-1510" is the RFC 1510 version of
the type, while "Foo-Ext" is the extensible version. "Foo-1510" does
not contain the extension marker, nor does it contain the extension
component "c". The type "Foo-1510" is equivalent to "Foo-1510-
Equiv", shown below.
-- example type equivalent to Foo-1510
Foo-1510-Equiv ::= SEQUENCE {
a [0] INTEGER,
b [1] OCTET STRING
}
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
skipping to change at page 17, line 36 skipping to change at page 16, line 15
This field specifies the type of address that follows. This field specifies the type of address that follows.
address address
This field encodes a single address of the type identified by This field encodes a single address of the type identified by
"addr-type". "addr-type".
All negative values for the host address type are reserved for local All negative values for the host address type are reserved for local
use. All non-negative values are reserved for officially assigned use. All non-negative values are reserved for officially assigned
type fields and interpretations. type fields and interpretations.
|
addr-type | meaning addr-type | meaning
__________|______________ -----------+--------------
2 | IPv4 2 | IPv4
3 | directional 3 | directional
12 | DECnet 12 | DECnet
20 | NetBIOS 20 | NetBIOS
24 | IPv6 24 | IPv6
4.7.1. Internet (IPv4) Addresses 4.7.1. Internet (IPv4) Addresses
Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in
MSB order (most significant byte first). The IPv4 loopback address MSB order (most significant byte first). The IPv4 loopback address
skipping to change at page 18, line 23 skipping to change at page 16, line 49
* the Loopback Address * the Loopback Address
* Link-Local addresses * Link-Local addresses
This restriction applies to the inclusion in the address fields of This restriction applies to the inclusion in the address fields of
Kerberos PDUs, but not to the address fields of packets that might Kerberos PDUs, but not to the address fields of packets that might
carry such PDUs. The restriction is necessary because the use of an carry such PDUs. The restriction is necessary because the use of an
address with non-global scope could allow the acceptance of a message address with non-global scope could allow the acceptance of a message
sent from a node that may have the same address, but which is not the sent from a node that may have the same address, but which is not the
host intended by the entity that added the restriction. If the host intended by the entity that added the restriction. If the link-
link-local address type needs to be used for communication, then the local address type needs to be used for communication, then the
address restriction in tickets must not be used (i.e. addressless address restriction in tickets must not be used (i.e. addressless
tickets must be used). tickets must be used).
IPv4-mapped IPv6 addresses MUST be represented as addresses of type IPv4-mapped IPv6 addresses MUST be represented as addresses of type
2. 2.
4.7.3. DECnet Phase IV addresses 4.7.3. DECnet Phase IV addresses
DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order. DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order.
The type of DECnet Phase IV addresses is twelve (12). The type of DECnet Phase IV addresses is twelve (12).
skipping to change at page 20, line 7 skipping to change at page 18, line 36
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
5.2. Principal Type Definition 5.2. Principal Type Definition
PrincipalName ::= SEQUENCE { The "PrincipalName" type takes a parameter to constrain which string
type it contains.
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 name-string [1] SEQUENCE OF KerberosString (StrType)
} }
The constrained types have their own names.
-- IA5 only
PrincipalNameIA5 ::= PrincipalName { KerberosStringIA5 }
-- IA5 excluded
PrincipalNameExt ::= PrincipalName { KerberosStringExt }
-- Either one?
PrincipalNameEither ::= PrincipalName { KerberosString }
name-type name-type
hint of the type of name that follows hint of the type of name that follows
name-string name-string
The "name-string" encodes a sequence of components that form a The "name-string" encodes a sequence of components that form a
name, each component encoded as a KerberosString. Taken name, each component encoded as a KerberosString. Taken
together, a PrincipalName and a Realm form a principal together, a PrincipalName and a Realm form a principal
identifier. Most PrincipalNames will have only a few components identifier. Most PrincipalNames will have only a few components
(typically one or two). (typically one or two).
skipping to change at page 20, line 40 skipping to change at page 19, line 30
administered authorization infrastructure, realm administrators administered authorization infrastructure, realm administrators
SHOULD NOT reuse principal names until confirming that all extant ACL SHOULD NOT reuse principal names until confirming that all extant ACL
entries referencing that principal name have been updated. Failure entries referencing that principal name have been updated. Failure
to perform this check can result in a security vulnerability, as a to perform this check can result in a security vulnerability, as a
new principal can inadvertently inherit unauthorized privileges upon new principal can inadvertently inherit unauthorized privileges upon
receiving a reused principal name. An organization whose Kerberos- receiving a reused principal name. An organization whose Kerberos-
authenticated services all use a centrally-adminstered authorization authenticated services all use a centrally-adminstered authorization
infrastructure may not need to take these precautions regarding infrastructure may not need to take these precautions regarding
principal name reuse. principal name reuse.
5.4. Realm Names 5.4. Best Common Practice Recommendations for the Processing of
Principal Names Consisting of Internationalized Domain Names:
Realm ::= KerberosString Kerberos principals are often created for the purpose of
authenticating a service located on a machine identified by an domain
name. Unfortunately, once a principal name is created it is
impossible to know the source from which the resulting KerberosString
was derived. It is therefore required that principal names
containing internationalized domain names be processed via the
following procedure:
* ensure that the IDN component must be a valid domain name as per
the rules of IDNA [RFC3490]
* separate the IDN component into labels separated by any of the
Full Stop characters
* fold all Full Stop characters to Full Stop (0x002E)
* for each label (perform all steps):
o if the label begins with an ACE prefix as registered with IANA,
the prefix will be removed and the rest of the label will be
converted from the ACE representation to Unicode [need
reference]
o if the label consists of one or more internationalized
characters separately apply the NamePrep and then the SASLprep
string preparation methods.
o if the label consists of zero internalizationalized characters,
the label is to be lower-cased
o if the output of the two methods match, continue on to the next
label; otherwise reject the principal name as invalid
* the result of a valid principal name component derived from an IDN
is the joining of the individual string prepared labels separated
by the Full Stop (0x002E)
5.5. Realm Names
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
RealmEither ::= Realm { KerberosString }
Kerberos realm names are KerberosStrings. Realms MUST NOT contain a Kerberos realm names are KerberosStrings. Realms MUST NOT contain a
character with the code 0 (the US-ASCII NUL). Most realms will character with the code 0 (the US-ASCII NUL). Most realms will
usually consist of several components separated by periods (.), in usually consist of several components separated by periods (.), in
the style of Internet Domain Names, or separated by slashes (/) in the style of Internet Domain Names, or separated by slashes (/) in
the style of X.500 names. the style of X.500 names.
5.5. Printable Representations of Principal Names 5.6. Best Common Practice Recommendations for the Processing of
Internationalized Domain-Style Realm Names:
Domain Style Realm names are defined as all realm names whose
components are separated by Full Stop (0x002E) (aka periods, '.') and
contain neither colons, name containing one or more internationalized
characters (not included in US-ASCII), this procedure must be used:
* the realm name must be a valid domain name as per the rules of
IDNA [RFC3490]
* the following string preparation routine must be followed:
- separate the string into components separated by any of the
Full Stop characters
- fold all Full Stop characters to Full Stop (0x002E)
- for each component (perform all steps):
o if the component begins with an ACE prefix as registered
with IANA, the prefix will be removed and the rest of the
component will be converted from the ACE representation to
Unicode [need reference]
o if the component consists of one or more internationalized
characters separately apply the NamePrep and SASLprep string
preparation methods.
if the output of the two methods match, continue on to the
next component; otherwise reject the realm name as invalid
-
the result of a valid realm name is the joining of the
individual string prepared components separated by the Full
Stop (0x002E)
In [KCLAR], the recommendation is that all domain style realm names
be represented in uppercase. This recommendation is modified in the
following manner. All components of domain style realm names not
including internationalized characters should be upper-cased. All
components of domain style realm names including internationalized
characters must be lower-cased. (The lower case representation of
internationalized components is enforced by the requirement that the
output of NamePrep and StringPrep string preparation must be
equivalent.)
5.7. Printable Representations of Principal Names
[ perhaps non-normative? ] [ perhaps non-normative? ]
The printable form of a principal name consists of the concatenation The printable form of a principal name consists of the concatenation
of components of the PrincipalName value using the slash character of components of the PrincipalName value using the slash character
(/), followed by an at-sign (@), followed by the realm name. Any (/), followed by an at-sign (@), followed by the realm name. Any
occurrence of a backslash (\), slash (/) or at-sign (@) in the occurrence of a backslash (\), slash (/) or at-sign (@) in the
PrincipalName value is quoted by a backslash. PrincipalName value is quoted by a backslash.
5.6. Ticket-Granting Service Principal 5.8. Ticket-Granting Service Principal
The PrincipalName value corresponding to a ticket-granting service The PrincipalName value corresponding to a ticket-granting service
has two components: the first component is the string "krbtgt", and has two components: the first component is the string "krbtgt", and
the second component is the realm name of the TGS which will accept a the second component is the realm name of the TGS which will accept a
ticket-granting ticket having this service principal name. The realm ticket-granting ticket having this service principal name. The realm
name of service always indicates which realm issued the ticket. A name of service always indicates which realm issued the ticket. A
ticket-granting ticket issued by "A.EXAMPLE.COM" which is valid for ticket-granting ticket issued by "A.EXAMPLE.COM" which is valid for
obtaining tickets in the same realm would have the following ASN.1 obtaining tickets in the same realm would have the following ASN.1
values for its "realm" and "sname" components, respectively: values for its "realm" and "sname" components, respectively:
skipping to change at page 21, line 39 skipping to change at page 22, line 17
tgtRealm1 Realm ::= ia5 : "A.EXAMPLE.COM" tgtRealm1 Realm ::= ia5 : "A.EXAMPLE.COM"
tgtPrinc1 PrincipalName ::= { tgtPrinc1 PrincipalName ::= {
name-type nt-srv-inst, name-type nt-srv-inst,
name-string { ia5 : "krbtgt", ia5 : "A.EXAMPLE.COM" } name-string { ia5 : "krbtgt", ia5 : "A.EXAMPLE.COM" }
} }
Its printable representation would be written as Its printable representation would be written as
"krbtgt/A.EXAMPLE.COM@A.EXAMPLE.COM". "krbtgt/A.EXAMPLE.COM@A.EXAMPLE.COM".
5.6.1. Cross-Realm TGS Principals 5.8.1. Cross-Realm TGS Principals
It is possible for a principal in one realm to authenticate to a It is possible for a principal in one realm to authenticate to a
service in another realm. A KDC can issue a cross-realm ticket- service in another realm. A KDC can issue a cross-realm ticket-
granting ticket to allow one of its principals to authenticate to a granting ticket to allow one of its principals to authenticate to a
service in a foreign realm. For example, the TGS principal service in a foreign realm. For example, the TGS principal
"krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" is a principal that permits a "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" is a principal that permits a
client principal in the realm A.EXAMPLE.COM to authenticate to a client principal in the realm A.EXAMPLE.COM to authenticate to a
service in the realm B.EXAMPLE.COM. When the KDC for B.EXAMPLE.COM service in the realm B.EXAMPLE.COM. When the KDC for B.EXAMPLE.COM
issues a ticket to a client originating in A.EXAMPLE.COM, the issues a ticket to a client originating in A.EXAMPLE.COM, the
client's realm name remains "A.EXAMPLE.COM", even though the service client's realm name remains "A.EXAMPLE.COM", even though the service
skipping to change at page 27, line 30 skipping to change at page 28, line 30
... ...
} }
7. Tickets 7. Tickets
[ A large number of items described here are duplicated in the [ A large number of items described here are duplicated in the
sections describing KDC-REQ processing. Should find a way to avoid sections describing KDC-REQ processing. Should find a way to avoid
this duplication. ] this duplication. ]
A ticket binds a principal name to a session key. The important A ticket binds a principal name to a session key. The important
fields of a ticket are in the encrypted part. The components in fields of a ticket are in the encrypted part.
common between the RFC 1510 and the extensible versions are
EncTicketPartCommon ::= SEQUENCE { -- Encrypted part of ticket
EncTicketPart ::= CHOICE {
rfc1510 EncTicketPart1510,
ext EncTicketPartExt
}
EncTicketPart1510 ::= [APPLICATION 3] SEQUENCE {
flags [0] TicketFlags, flags [0] TicketFlags,
key [1] EncryptionKey, key [1] EncryptionKey,
crealm [2] Realm, crealm [2] RealmIA5,
cname [3] PrincipalName, cname [3] PrincipalNameIA5,
transited [4] TransitedEncoding,
authtime [5] KerberosTime,
starttime [6] KerberosTime OPTIONAL,
endtime [7] KerberosTime,
renew-till [8] KerberosTime OPTIONAL,
caddr [9] HostAddresses OPTIONAL,
authorization-data [10] AuthorizationData OPTIONAL
}
EncTicketPartExt ::= [APPLICATION 5] SEQUENCE {
flags [0] TicketFlags,
key [1] EncryptionKey,
crealm [2] RealmExt,
cname [3] PrincipalNameExt,
transited [4] TransitedEncoding, transited [4] TransitedEncoding,
authtime [5] KerberosTime, authtime [5] KerberosTime,
starttime [6] KerberosTime OPTIONAL, starttime [6] KerberosTime OPTIONAL,
endtime [7] KerberosTime, endtime [7] KerberosTime,
renew-till [8] KerberosTime OPTIONAL, renew-till [8] KerberosTime OPTIONAL,
caddr [9] HostAddresses OPTIONAL, caddr [9] HostAddresses OPTIONAL,
authorization-data [10] AuthorizationData OPTIONAL, authorization-data [10] AuthorizationData OPTIONAL,
... ...,
} }
crealm crealm
This field contains the client's realm. This field contains the client's realm.
cname cname
This field contains the client's name. This field contains the client's name.
caddr caddr
This field lists the network addresses (if absent, all addresses This field lists the network addresses (if absent, all addresses
skipping to change at page 28, line 23 skipping to change at page 29, line 43
Three of the ticket timestamps may be requested from the KDC. The Three of the ticket timestamps may be requested from the KDC. The
timestamps may differ from those requested, depending on site policy. timestamps may differ from those requested, depending on site policy.
authtime authtime
The time at which the client authenticated, as recorded by the The time at which the client authenticated, as recorded by the
KDC. KDC.
starttime starttime
The earliest time when the ticket is valid. If not present, the The earliest time when the ticket is valid. If not present, the
ticket is valid starting at the authtime. This is requested as ticket is valid starting at the authtime. This is requested as
the "from" field of KDC-REQ-BODY-COMMON. the "from" field of KDC-REQ-BODY.
endtime endtime
This time is requested in the "till" field of KDC-REQ-BODY- This time is requested in the "till" field of KDC-REQ-BODY.
COMMON. Contains the time after which the ticket will not be Contains the time after which the ticket will not be honored
honored (its expiration time). Note that individual services (its expiration time). Note that individual services MAY place
MAY place their own limits on the life of a ticket and MAY their own limits on the life of a ticket and MAY reject tickets
reject tickets which have not yet expired. As such, this is which have not yet expired. As such, this is really an upper
really an upper bound on the expiration time for the ticket. bound on the expiration time for the ticket.
renew-till renew-till
This time is requested in the "rtime" field of KDC-REQ-BODY- This time is requested in the "rtime" field of KDC-REQ-BODY. It
COMMON. It is only present in tickets that have the "renewable" is only present in tickets that have the "renewable" flag set in
flag set in the flags field. It indicates the maximum endtime the flags field. It indicates the maximum endtime that may be
that may be included in a renewal. It can be thought of as the included in a renewal. It can be thought of as the absolute
absolute expiration time for the ticket, including all renewals. expiration time for the ticket, including all renewals.
7.2. Ticket Flags 7.2. Ticket Flags
A number of flags may be set in the ticket, further defining some of A number of flags may be set in the ticket, further defining some of
its capabilities. Some of these flags map to flags in a KDC request. its capabilities. Some of these flags map to flags in a KDC request.
TicketFlags ::= KerberosFlags { TicketFlagsBits } TicketFlags ::= KerberosFlags { TicketFlagsBits }
TicketFlagsBits ::= BIT STRING { TicketFlagsBits ::= BIT STRING {
reserved (0), reserved (0),
skipping to change at page 35, line 21 skipping to change at page 36, line 34
authorization data element modifying the criticality of the elements authorization data element modifying the criticality of the elements
it contains, an application server MUST reject the authentication of it contains, an application server MUST reject the authentication of
a client whose AP-REQ or ticket contains an unrecognized a client whose AP-REQ or ticket contains an unrecognized
authorization data element. Authorization data is intended to authorization data element. Authorization data is intended to
restrict the use of a ticket. If the service cannot determine restrict the use of a ticket. If the service cannot determine
whether it is the target of a restriction, a security weakness may whether it is the target of a restriction, a security weakness may
exist if the ticket can be used for that service. Authorization exist if the ticket can be used for that service. Authorization
elements that are truly optional can be enclosed in AD-IF-RELEVANT elements that are truly optional can be enclosed in AD-IF-RELEVANT
element. element.
|
ad-type | contents of ad-data ad-type | contents of ad-data
________|_______________________________________ ---------+---------------------------------------
1 | DER encoding of AD-IF-RELEVANT 1 | DER encoding of AD-IF-RELEVANT
4 | DER encoding of AD-KDCIssued 4 | DER encoding of AD-KDCIssued
5 | DER encoding of AD-AND-OR 5 | DER encoding of AD-AND-OR
8 | DER encoding of AD-MANDATORY-FOR-KDC 8 | DER encoding of AD-MANDATORY-FOR-KDC
7.4.1. AD-IF-RELEVANT 7.4.1. AD-IF-RELEVANT
ad-if-relevant ADType ::= int32 : 1 ad-if-relevant ADType ::= int32 : 1
-- Encapsulates another AuthorizationData. -- Encapsulates another AuthorizationData.
skipping to change at page 37, line 21 skipping to change at page 38, line 31
by applications, application servers, and KDCs that do not implement by applications, application servers, and KDCs that do not implement
this element. this element.
The ad-type for AD-KDC-ISSUED is (4). The ad-type for AD-KDC-ISSUED is (4).
7.4.3. AD-AND-OR 7.4.3. AD-AND-OR
ad-and-or ADType ::= int32 : 5 ad-and-or ADType ::= int32 : 5
AD-AND-OR ::= SEQUENCE { AD-AND-OR ::= SEQUENCE {
condition-count [0] INTEGER, condition-count [0] Int32,
elements [1] AuthorizationData elements [1] AuthorizationData
} }
When restrictive AD elements are encapsulated within the and-or When restrictive AD elements are encapsulated within the and-or
element, the and-or element is considered satisfied if and only if at element, the and-or element is considered satisfied if and only if at
least the number of encapsulated elements specified in condition- least the number of encapsulated elements specified in condition-
count are satisfied. Therefore, this element MAY be used to count are satisfied. Therefore, this element MAY be used to
implement an "or" operation by setting the condition-count field to implement an "or" operation by setting the condition-count field to
1, and it MAY specify an "and" operation by setting the condition 1, and it MAY specify an "and" operation by setting the condition
count to the number of embedded elements. Application servers that do count to the number of embedded elements. Application servers that do
skipping to change at page 38, line 4 skipping to change at page 39, line 12
AD elements encapsulated within the mandatory-for-kdc element are to AD elements encapsulated within the mandatory-for-kdc element are to
be interpreted by the KDC. KDCs that do not understand the type of be interpreted by the KDC. KDCs that do not understand the type of
an element embedded within the mandatory-for-kdc element MUST reject an element embedded within the mandatory-for-kdc element MUST reject
the request. the request.
The ad-type for AD-MANDATORY-FOR-KDC is (8). The ad-type for AD-MANDATORY-FOR-KDC is (8).
7.5. Encrypted Part of Ticket 7.5. Encrypted Part of Ticket
The complete definition of the encrypted part is The complete definition of the encrypted part is
-- Encrypted part of ticket -- Encrypted part of ticket
EncTicketPart ::= CHOICE { EncTicketPart ::= CHOICE {
rfc1510 [APPLICATION 3] EncTicketPart1510, rfc1510 EncTicketPart1510,
ext [APPLICATION 5] EncTicketPartExt ext EncTicketPartExt
} }
with the common portion being The encrypted part of the backwards-compatibility form of a ticket
is:
EncTicketPartCommon ::= SEQUENCE { EncTicketPart1510 ::= [APPLICATION 3] SEQUENCE {
flags [0] TicketFlags, flags [0] TicketFlags,
key [1] EncryptionKey, key [1] EncryptionKey,
crealm [2] Realm, crealm [2] RealmIA5,
cname [3] PrincipalName, cname [3] PrincipalNameIA5,
transited [4] TransitedEncoding, transited [4] TransitedEncoding,
authtime [5] KerberosTime, authtime [5] KerberosTime,
starttime [6] KerberosTime OPTIONAL, starttime [6] KerberosTime OPTIONAL,
endtime [7] KerberosTime, endtime [7] KerberosTime,
renew-till [8] KerberosTime OPTIONAL, renew-till [8] KerberosTime OPTIONAL,
caddr [9] HostAddresses OPTIONAL, caddr [9] HostAddresses OPTIONAL,
authorization-data [10] AuthorizationData OPTIONAL, authorization-data [10] AuthorizationData OPTIONAL
...
} }
The encrypted part of the backwards-compatibility form of a ticket
is:
EncTicketPart1510 ::= SEQUENCE {
COMPONENTS OF EncTicketPartCommon
} (WITH COMPONENTS {
...,
-- explicitly force IA5 in strings
crealm (RealmIA5),
cname (PrincipalNameIA5)
})
The encrypted part of the extensible form of a ticket is: The encrypted part of the extensible form of a ticket is:
EncTicketPartExt ::= EncTicketPartCommon (WITH COMPONENTS { EncTicketPartExt ::= [APPLICATION 5] SEQUENCE {
flags [0] TicketFlags,
key [1] EncryptionKey,
crealm [2] RealmExt,
cname [3] PrincipalNameExt,
transited [4] TransitedEncoding,
authtime [5] KerberosTime,
starttime [6] KerberosTime OPTIONAL,
endtime [7] KerberosTime,
renew-till [8] KerberosTime OPTIONAL,
caddr [9] HostAddresses OPTIONAL,
authorization-data [10] AuthorizationData OPTIONAL,
..., ...,
-- explicitly force UTF-8 in strings }
crealm (RealmExt),
cname (PrincipalNameExt),
-- explicitly constrain caddr to be non-empty if present
caddr (SIZE (1..MAX)),
-- forbid empty authorization-data encodings
authorization-data (SIZE (1..MAX))
})
7.6. Cleartext Part of Ticket 7.6. Cleartext Part of Ticket
The complete definition of Ticket is: The complete definition of Ticket is:
Ticket ::= CHOICE { Ticket ::= CHOICE {
rfc1510 [APPLICATION 1] Ticket1510, rfc1510 Ticket1510,
ext [APPLICATION 4] Signed { ext TicketExt
TicketExt, { key-server }, { ku-Ticket-cksum }
}
}
with the common portion being:
-- takes a parameter specifying which type gets encrypted
TicketCommon { EncPart } ::= SEQUENCE {
tkt-vno [0] INTEGER (5),
realm [1] Realm,
sname [2] PrincipalName,
enc-part [3] EncryptedData {
EncPart, { key-server }, { ku-Ticket }
},
...,
extensions [4] TicketExtensions OPTIONAL,
...
} }
The "sname" field provides the name of the target service principal The "sname" field provides the name of the target service principal
in cleartext, as a hint to aid the server in choosing the correct in cleartext, as a hint to aid the server in choosing the correct
decryption key. decryption key.
The backwards-compatibility form of Ticket is: The backwards-compatibility form of Ticket is:
Ticket1510 ::= SEQUENCE { Ticket1510 ::= [APPLICATION 1] SEQUENCE {
COMPONENTS OF TicketCommon { EncTicketPart1510 } tkt-vno [0] INTEGER (5),
} (WITH COMPONENTS { realm [1] RealmIA5,
..., sname [2] PrincipalNameIA5,
-- explicitly force IA5 in strings enc-part [3] EncryptedData {
realm (RealmIA5), EncTicketPart1510, { key-server }, { ku-Ticket }
sname (PrincipalNameIA5) }
}) }
The extensible form of Ticket is: The extensible form of Ticket is:
-- APPLICATION tag goes inside Signed{} as well as outside, TicketExt ::= [APPLICATION 4] Signed {
-- to prevent possible substitution attacks. [APPLICATION 4] SEQUENCE {
TicketExt ::= [APPLICATION 4] TicketCommon { tkt-vno [0] INTEGER (5),
EncTicketPartExt realm [1] RealmExt,
} (WITH COMPONENTS { sname [2] PrincipalNameExt,
enc-part [3] EncryptedData {
EncTicketPartExt, { key-server }, { ku-Ticket }
},
..., ...,
-- explicitly force UTF-8 in strings extensions [4] TicketExtensions OPTIONAL,
realm (RealmExt), ...
sname (PrincipalNameExt) },
}) { key-ticket }, { ku-Ticket-cksum }
}
TicketExtensions, which may only be present in the extensible form of TicketExtensions, which may only be present in the extensible form of
Ticket, are a cleartext typed hole for extension use. Ticket, are a cleartext typed hole for extension use.
AuthorizationData already provides an encrypted typed hole. AuthorizationData already provides an encrypted typed hole.
TEType ::= TH-id TEType ::= TH-id
-- ticket extensions: for TicketExt only -- ticket extensions: for TicketExt only
TicketExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE { TicketExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
te-type [0] TEType, te-type [0] TEType,
skipping to change at page 41, line 5 skipping to change at page 41, line 36
The credentials acquisition protocol operates over specific The credentials acquisition protocol operates over specific
transports. Additionally, specific methods exist to permit a client transports. Additionally, specific methods exist to permit a client
to discover the KDC host with which to communicate. to discover the KDC host with which to communicate.
8.1. KDC-REQ 8.1. KDC-REQ
The KDC-REQ has a large number of fields in common between the RFC The KDC-REQ has a large number of fields in common between the RFC
1510 and the extensible versions. The KDC-REQ type itself is never 1510 and the extensible versions. The KDC-REQ type itself is never
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-COMMON ::= 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.rfc1510 -- msg-type [2] INTEGER ( 10 -- AS-REQ --
| 12 -- TGS-REQ.rfc1510 -- | 12 -- TGS-REQ -- ),
| 6 -- AS-REQ.ext -- padata [3] SEQUENCE OF PA-DATA OPTIONAL,
| 8 -- TGS-REQ.ext -- ), req-body [4] KDC-REQ-BODY-1510
padata [3] SEQUENCE OF PA-DATA OPTIONAL
-- NOTE: not empty
} }
KDC-REQ-BODY-COMMON ::= SEQUENCE { KDC-REQ-EXT ::= SEQUENCE {
pvno [1] INTEGER (5),
msg-type [2] INTEGER ( 6 -- AS-REQ --
| 8 -- TGS-REQ -- ),
padata [3] SEQUENCE (SIZE (1..MAX)) OF PA-DATA OPTIONAL,
req-body [4] KDC-REQ-BODY-EXT,
...
}
KDC-REQ-BODY-1510 ::= SEQUENCE {
kdc-options [0] KDCOptions,
cname [1] PrincipalNameIA5 OPTIONAL
-- Used only in AS-REQ --,
realm [2] RealmIA5
-- Server's realm; also client's in AS-REQ --,
sname [3] PrincipalNameIA5 OPTIONAL,
from [4] KerberosTime OPTIONAL,
till [5] KerberosTime,
rtime [6] KerberosTime OPTIONAL,
nonce [7] Nonce32,
etype [8] SEQUENCE OF EType
-- in preference order --,
addresses [9] HostAddresses OPTIONAL,
enc-authorization-data [10] EncryptedData {
AuthorizationData, { key-session | key-subsession },
{ ku-TGSReqAuthData-subkey |
ku-TGSReqAuthData-sesskey }
} OPTIONAL,
additional-tickets [11] SEQUENCE OF Ticket OPTIONAL
-- NOTE: not empty --
}
KDC-REQ-BODY-EXT ::= SEQUENCE {
kdc-options [0] KDCOptions, kdc-options [0] KDCOptions,
cname [1] PrincipalName OPTIONAL cname [1] PrincipalName OPTIONAL
-- Used only in AS-REQ --, -- Used only in AS-REQ --,
realm [2] Realm realm [2] Realm
-- Server's realm; also client's in AS-REQ --, -- Server's realm; also client's in AS-REQ --,
sname [3] PrincipalName OPTIONAL, sname [3] PrincipalName OPTIONAL,
from [4] KerberosTime OPTIONAL, from [4] KerberosTime OPTIONAL,
till [5] KerberosTime OPTIONAL till [5] KerberosTime OPTIONAL
skipping to change at page 41, line 51 skipping to change at page 43, line 39
} OPTIONAL, } OPTIONAL,
additional-tickets [11] SEQUENCE OF Ticket OPTIONAL additional-tickets [11] SEQUENCE OF Ticket OPTIONAL
-- NOTE: not empty --, -- NOTE: not empty --,
... ...
lang-tags [5] SEQUENCE (SIZE (1..MAX)) OF lang-tags [5] SEQUENCE (SIZE (1..MAX)) OF
LangTag OPTIONAL, LangTag OPTIONAL,
... ...
} }
Many fields of KDC-REQ-BODY-COMMON correspond directly to fields of Many fields of KDC-REQ-BODY correspond directly to fields of an
an EncTicketPartCommon. The KDC copies most of them unchanged, EncTicketPart. The KDC copies most of them unchanged, provided that
provided that the requested values meet site policy. the requested values meet site policy.
kdc-options kdc-options
These flags do not correspond directly to "flags" in These flags do not correspond directly to "flags" in
EncTicketPartCommon. EncTicketPart.
cname cname
This field is copied to the "cname" field in This field is copied to the "cname" field in EncTicketPart. The
EncTicketPartCommon. The "cname" field is required in an AS- "cname" field is required in an AS-REQ; the client places its
REQ; the client places its own name here. In a TGS-REQ, the own name here. In a TGS-REQ, the "cname" in the ticket in the
"cname" in the ticket in the AP-REQ takes precedence. AP-REQ takes precedence.
realm realm
This field is the server's realm, and also holds the client's This field is the server's realm, and also holds the client's
realm in an AS-REQ. realm in an AS-REQ.
sname sname
The "sname" field indicates the server's name. It may be absent The "sname" field indicates the server's name. It may be absent
in a TGS-REQ which requests user-to-user authentication, in in a TGS-REQ which requests user-to-user authentication, in
which case the "sname" of the issued ticket will be taken from which case the "sname" of the issued ticket will be taken from
the included additional ticket. the included additional ticket.
The "from", "till", and "rtime" fields correspond to the "starttime", The "from", "till", and "rtime" fields correspond to the "starttime",
"endtime", and "renew-till" fields of EncTicketPartCommon. "endtime", and "renew-till" fields of EncTicketPart.
addresses addresses
This field corresponds to the "caddr" field of This field corresponds to the "caddr" field of EncTicketPart.
EncTicketPartCommon.
enc-authorization-data enc-authorization-data
For TGS-REQ, this field contains authorization data encrypted For TGS-REQ, this field contains authorization data encrypted
using either the TGT session key or the AP-REQ subsession key; using either the TGT session key or the AP-REQ subsession key;
the KDC may copy these into the "authorization-data" field of the KDC may copy these into the "authorization-data" field of
EncTicketPartCommon if policy permits. EncTicketPart if policy permits.
lang-tags lang-tags
Only present in the extensible messages. Specifies the set of Only present in the extensible messages. Specifies the set of
languages which the client is willing to accept in error languages which the client is willing to accept in error
messages. messages.
KDC options used in a KDC-REQ are: KDC options used in a KDC-REQ are:
KDCOptions ::= KerberosFlags { KDCOptionsBits } KDCOptions ::= KerberosFlags { KDCOptionsBits }
skipping to change at page 43, line 37 skipping to change at page 45, line 37
renew (30), renew (30),
validate (31) validate (31)
-- XXX need "need ticket1" flag? -- XXX need "need ticket1" flag?
} }
Different options apply to different phases of KDC-REQ processing. Different options apply to different phases of KDC-REQ processing.
The backwards-compatibility form of a KDC-REQ is: The backwards-compatibility form of a KDC-REQ is:
KDC-REQ-1510 ::= SEQUENCE { KDC-REQ-1510 ::= SEQUENCE {
COMPONENTS OF KDC-REQ-COMMON, -- NOTE: first tag is [1], not [0]
pvno [1] INTEGER (5),
msg-type [2] INTEGER ( 10 -- AS-REQ --
| 12 -- TGS-REQ -- ),
padata [3] SEQUENCE OF PA-DATA OPTIONAL,
req-body [4] KDC-REQ-BODY-1510 req-body [4] KDC-REQ-BODY-1510
} (WITH COMPONENTS { ..., msg-type (10 | 12) }) }
The extensible form of a KDC-REQ is: The extensible form of a KDC-REQ is:
-- APPLICATION tag goes inside Signed{} as well as outside,
-- to prevent possible substitution attacks.
KDC-REQ-EXT ::= SEQUENCE { KDC-REQ-EXT ::= SEQUENCE {
COMPONENTS OF KDC-REQ-COMMON, pvno [1] INTEGER (5),
msg-type [2] INTEGER ( 6 -- AS-REQ --
| 8 -- TGS-REQ -- ),
padata [3] SEQUENCE (SIZE (1..MAX)) OF PA-DATA OPTIONAL,
req-body [4] KDC-REQ-BODY-EXT, req-body [4] KDC-REQ-BODY-EXT,
... ...
} (WITH COMPONENTS { }
...,
msg-type (6 | 8),
padata (SIZE (1..MAX))
})
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 {
COMPONENTS OF KDC-REQ-BODY-COMMON kdc-options [0] KDCOptions,
} (WITH COMPONENTS { cname [1] PrincipalNameIA5 OPTIONAL
..., -- Used only in AS-REQ --,
cname (PrincipalNameIA5),
realm (RealmIA5), realm [2] RealmIA5
sname (PrincipalNameIA5), -- Server's realm; also client's in AS-REQ --,
till PRESENT,
nonce (UInt32) sname [3] PrincipalNameIA5 OPTIONAL,
}) from [4] KerberosTime OPTIONAL,
till [5] KerberosTime,
rtime [6] KerberosTime OPTIONAL,
nonce [7] Nonce32,
etype [8] SEQUENCE OF EType
-- in preference order --,
addresses [9] HostAddresses OPTIONAL,
enc-authorization-data [10] EncryptedData {
AuthorizationData, { key-session | key-subsession },
{ ku-TGSReqAuthData-subkey |
ku-TGSReqAuthData-sesskey }
} OPTIONAL,
additional-tickets [11] SEQUENCE OF Ticket OPTIONAL
-- NOTE: not empty --
}
The extensible form of a KDC-REQ-BODY is: The extensible form of a KDC-REQ-BODY is:
KDC-REQ-BODY-EXT ::= KDC-REQ-BODY-COMMON KDC-REQ-BODY-EXT ::= SEQUENCE {
(WITH COMPONENTS { kdc-options [0] KDCOptions,
..., cname [1] PrincipalName OPTIONAL
cname (PrincipalNameExt), -- Used only in AS-REQ --,
realm (RealmExt),
sname (PrincipalNameExt), realm [2] Realm
addresses (SIZE (1..MAX)), -- Server's realm; also client's in AS-REQ --,
enc-authorization-data (EncryptedData {
AuthorizationData (SIZE (1..MAX)), sname [3] PrincipalName OPTIONAL,
{ key-session | key-subsession }, from [4] KerberosTime OPTIONAL,
till [5] KerberosTime OPTIONAL
-- was required in rfc1510;
-- still required for compat versions
-- of messages --,
rtime [6] KerberosTime OPTIONAL,
nonce [7] Nonce,
etype [8] SEQUENCE OF EType
-- in preference order --,
addresses [9] HostAddresses OPTIONAL,
enc-authorization-data [10] EncryptedData {
AuthorizationData, { key-session | key-subsession },
{ ku-TGSReqAuthData-subkey | { ku-TGSReqAuthData-subkey |
ku-TGSReqAuthData-sesskey } ku-TGSReqAuthData-sesskey }
}), } OPTIONAL,
additional-tickets (SIZE (1..MAX))
}) additional-tickets [11] SEQUENCE OF Ticket OPTIONAL
-- NOTE: not empty --,
...
lang-tags [5] SEQUENCE (SIZE (1..MAX)) OF
LangTag OPTIONAL,
...
}
The AS-REQ is: The AS-REQ is:
AS-REQ ::= CHOICE { AS-REQ ::= CHOICE {
rfc1510 [APPLICATION 10] KDC-REQ-1510 rfc1510 AS-REQ-1510,
(WITH COMPONENTS { ext AS-REQ-EXT
...,
msg-type (10),
-- AS-REQ must include client name
req-body (WITH COMPONENTS { ..., cname PRESENT })
}),
ext [APPLICATION 6] Signed {
-- APPLICATION tag goes inside Signed{} as well as
-- outside, to prevent possible substitution attacks.
[APPLICATION 6] KDC-REQ-EXT,
-- not sure this is correct key to use; do we even want
-- to sign AS-REQ?
{ key-client },
{ ku-ASReq-cksum }
} }
(WITH COMPONENTS { AS-REQ-1510 ::= [APPLICATION 10] KDC-REQ-1510
...,
msg-type (6),
-- AS-REQ must include client name -- AS-REQ must include client name
req-body (WITH COMPONENTS { ..., cname PRESENT })
}) AS-REQ-EXT ::= [APPLICATION 6] Signed {
[APPLICATION 6] KDC-REQ-EXT, { key-client }, { ku-ASReq-cksum }
} }
-- 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 [APPLICATION 12] KDC-REQ-1510 rfc1510 TGS-REQ-1510,
(WITH COMPONENTS { ext TGS-REQ-EXT
...,
msg-type (12),
-- client name optional in TGS-REQ
req-body (WITH COMPONENTS { ..., cname ABSENT })
}),
ext [APPLICATION 8] Signed {
-- APPLICATION tag goes inside Signed{} as well as
-- outside, to prevent possible substitution attacks.
[APPLICATION 8] KDC-REQ-EXT,
{ key-session }, { ku-TGSReq-cksum }
} }
(WITH COMPONENTS {
..., TGS-REQ-1510 ::= [APPLICATION 12] KDC-REQ-1510
msg-type (8),
-- client name optional in TGS-REQ TGS-REQ-EXT ::= [APPLICATION 8] Signed {
req-body (WITH COMPONENTS { ..., cname ABSENT }) [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 50, line 33 skipping to change at page 52, line 29
* the value of the "renew-till" value of the old, * the value of the "renew-till" value of the old,
* the "starttime" of the new ticket plus the lifetime (endtime * the "starttime" of the new ticket plus the lifetime (endtime
minus starttime) of the old ticket, i.e., the lifetime of the minus starttime) of the old ticket, i.e., the lifetime of the
new ticket may not exceed that of the ticket being renewed [ new ticket may not exceed that of the ticket being renewed [
adapted from KCLAR 3.3.3. ], and adapted from KCLAR 3.3.3. ], and
* an "endtime" determined by site policy on ticket lifetimes. * an "endtime" determined by site policy on ticket lifetimes.
When handling a TGS-REQ, a KDC MUST NOT issue a postdated ticket with When handling a TGS-REQ, a KDC MUST NOT issue a postdated ticket with
a "starttime", "endtime", or "renew-till" time later than the a "starttime", "endtime", or "renew-till" time later than the "renew-
"renew-till" time of the TGT. till" time of the TGT.
8.3.4. Handling Transited Realms 8.3.4. Handling Transited Realms
The KDC checks the ticket in a TGS-REQ against site policy, unless The KDC checks the ticket in a TGS-REQ against site policy, unless
the "disable-transited-check" option is set in the TGS-REQ. If site the "disable-transited-check" option is set in the TGS-REQ. If site
policy permits the transit path in the TGS-REQ ticket, the KDC sets policy permits the transit path in the TGS-REQ ticket, the KDC sets
the "transited-policy-checked" flag in the issued ticket. If the the "transited-policy-checked" flag in the issued ticket. If the
"disable-transited-check" option is set, the issued ticket will have "disable-transited-check" option is set, the issued ticket will have
the "transited-policy-checked" flag cleared. the "transited-policy-checked" flag cleared.
skipping to change at page 51, line 12 skipping to change at page 53, line 12
The "proxy" option will not be honored on requests for additional The "proxy" option will not be honored on requests for additional
ticket-granting tickets. ticket-granting tickets.
8.3.6. Ticket Flag Processing 8.3.6. Ticket Flag Processing
Many kdc-options request that the KDC set a corresponding flag in the Many kdc-options request that the KDC set a corresponding flag in the
issued ticket. kdc-options marked with an asterisk (*) in the issued ticket. kdc-options marked with an asterisk (*) in the
following table do not directly request the corresponding ticket flag following table do not directly request the corresponding ticket flag
and therefore require special handling. and therefore require special handling.
|
kdc-option | ticket flag affected kdc-option | ticket flag affected
________________________|__________________________ -------------------------+--------------------------
forwardable | forwardable forwardable | forwardable
forwarded | forwarded forwarded | forwarded
proxiable | proxiable proxiable | proxiable
proxy | proxy proxy | proxy
allow-postdate | may-postdate allow-postdate | may-postdate
postdated | postdated postdated | postdated
renewable | renewable renewable | renewable
requestanonymous | anonymous requestanonymous | anonymous
canonicalize | - canonicalize | -
disable-transited-check*| transited-policy-checked disable-transited-check*| transited-policy-checked
skipping to change at page 52, line 25 skipping to change at page 54, line 25
the encrypted part of the KDC-REP so that the client can retrieve it. the encrypted part of the KDC-REP so that the client can retrieve it.
The ticket key is used to encrypt the ticket. These keys all have The ticket key is used to encrypt the ticket. These keys all have
initial values for a given exchange; pre-authentication and other initial values for a given exchange; pre-authentication and other
extension mechanisms may change the value used for any of these keys. extension mechanisms may change the value used for any of these keys.
[ again, may need changes based on Sam's preauth draft ] [ again, may need changes based on Sam's preauth draft ]
8.3.7.1. Reply Key and Session Key Selection 8.3.7.1. Reply Key and Session Key Selection
The set of encryption types which the client will understand appears The set of encryption types which the client will understand appears
in the "etype" field of KDC-REQ-BODY-COMMON. The KDC limits the set in the "etype" field of KDC-REQ-BODY. The KDC limits the set of
of possible reply keys and the set of session key encryption types possible reply keys and the set of session key encryption types based
based on the "etype" field. on the "etype" field.
For the AS exchange, the reply key is initially a long-term key of For the AS exchange, the reply key is initially a long-term key of
the client, limited to those encryption types listed in the "etype" the client, limited to those encryption types listed in the "etype"
field. The KDC SHOULD use the first valid strong "etype" for which field. The KDC SHOULD use the first valid strong "etype" for which
an encryption key is available. For the TGS exchange, the reply key an encryption key is available. For the TGS exchange, the reply key
is initially the subsession key of the Authenticator. If the is initially the subsession key of the Authenticator. If the
Authenticator subsesion key is absent, the reply key is initially the Authenticator subsesion key is absent, the reply key is initially the
session key of the ticket used to authenticate the TGS-REQ. session key of the ticket used to authenticate the TGS-REQ.
The session key is initially randomly generated, and has an The session key is initially randomly generated, and has an
skipping to change at page 53, line 11 skipping to change at page 55, line 11
8.4. KDC-REP 8.4. KDC-REP
The important parts of the KDC-REP are encrypted. The important parts of the KDC-REP are encrypted.
EncASRepPart1510 ::= [APPLICATION 25] EncKDCRepPart1510 EncASRepPart1510 ::= [APPLICATION 25] EncKDCRepPart1510
EncTGSRepPart1510 ::= [APPLICATION 26] EncKDCRepPart1510 EncTGSRepPart1510 ::= [APPLICATION 26] EncKDCRepPart1510
EncASRepPartExt ::= [APPLICATION 32] EncKDCRepPartExt EncASRepPartExt ::= [APPLICATION 32] EncKDCRepPartExt
EncTGSRepPartExt ::= [APPLICATION 33] EncKDCRepPartExt EncTGSRepPartExt ::= [APPLICATION 33] EncKDCRepPartExt
EncKDCRepPartCom ::= SEQUENCE { EncKDCRepPart1510 ::= SEQUENCE {
key [0] EncryptionKey,
last-req [1] LastReq,
nonce [2] Nonce32,
key-expiration [3] KerberosTime OPTIONAL,
flags [4] TicketFlags,
authtime [5] KerberosTime,
starttime [6] KerberosTime OPTIONAL,
endtime [7] KerberosTime,
renew-till [8] KerberosTime OPTIONAL,
srealm [9] RealmIA5,
sname [10] PrincipalNameIA5,
caddr [11] HostAddresses OPTIONAL
}
EncKDCRepPartExt ::= SEQUENCE {
key [0] EncryptionKey, key [0] EncryptionKey,
last-req [1] LastReq, last-req [1] LastReq,
nonce [2] Nonce, nonce [2] Nonce,
key-expiration [3] KerberosTime OPTIONAL, key-expiration [3] KerberosTime OPTIONAL,
flags [4] TicketFlags, flags [4] TicketFlags,
authtime [5] KerberosTime, authtime [5] KerberosTime,
starttime [6] KerberosTime OPTIONAL, starttime [6] KerberosTime OPTIONAL,
endtime [7] KerberosTime, endtime [7] KerberosTime,
renew-till [8] KerberosTime OPTIONAL, renew-till [8] KerberosTime OPTIONAL,
srealm [9] Realm, srealm [9] Realm,
sname [10] PrincipalName, sname [10] PrincipalName,
caddr [11] HostAddresses OPTIONAL, caddr [11] HostAddresses OPTIONAL,
... ...
} }
EncKDCRepPart1510 ::= SEQUENCE {
COMPONENTS OF EncKDCRepPartCom
} (WITH COMPONENTS {
...,
srealm (RealmIA5),
sname (PrincipalNameIA5),
nonce UInt32 })
EncKdcRepPartExt ::= EncKDCRepPartCom (WITH COMPONENTS {
...,
srealm (RealmExt),
sname (PrincipalNameExt)
})
Most of the fields of EncKDCRepPartCom are duplicates of the Most of the fields of EncKDCRepPartCom are duplicates of the
corresponding fields in the returned ticket. corresponding fields in the returned ticket.
KDC-REP-COMMON { 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 -- ),
7 -- AS-REP.ext -- | padata [2] SEQUENCE OF PA-DATA OPTIONAL,
crealm [3] RealmIA5,
cname [4] PrincipalNameIA5,
ticket [5] Ticket,
enc-part [6] EncryptedData {
EncPart,
{ key-reply },
-- maybe reach into EncryptedData in AS-REP/TGS-REP
-- definitions to apply constraints on key usages?
{ ku-EncASRepPart -- if AS-REP -- |
ku-EncTGSRepPart-subkey -- if TGS-REP and
-- using Authenticator
-- session key -- |
ku-EncTGSRepPart-sesskey -- if TGS-REP and using
-- subsession key -- }
}
}
KDC-REP-EXT { EncPart } ::= SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (7 -- AS-REP.ext -- |
9 -- TGS-REP.ext -- ), 9 -- TGS-REP.ext -- ),
padata [2] SEQUENCE OF PA-DATA OPTIONAL, padata [2] SEQUENCE OF PA-DATA OPTIONAL,
crealm [3] Realm, crealm [3] RealmExt,
cname [4] PrincipalName, cname [4] PrincipalNameExt,
ticket [5] Ticket, ticket [5] Ticket,
enc-part [6] EncryptedData { enc-part [6] EncryptedData {
EncPart, EncPart,
{ key-reply }, { key-reply },
-- maybe reach into EncryptedData in AS-REP/TGS-REP -- maybe reach into EncryptedData in AS-REP/TGS-REP
-- definitions to apply constraints on key usages? -- definitions to apply constraints on key usages?
{ ku-EncASRepPart -- if AS-REP -- | { ku-EncASRepPart -- if AS-REP -- |
ku-EncTGSRepPart-subkey -- if TGS-REP and ku-EncTGSRepPart-subkey -- if TGS-REP and
-- using Authenticator -- using Authenticator
skipping to change at page 54, line 40 skipping to change at page 57, line 37
-- In extensible version, KDC signs original request -- In extensible version, KDC signs original request
-- to avoid replay attacks against client. -- to avoid replay attacks against client.
req-cksum [7] ChecksumOf { CHOICE { req-cksum [7] ChecksumOf { CHOICE {
as-req AS-REQ, as-req AS-REQ,
tgs-req TGS-REQ tgs-req TGS-REQ
}, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL, }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL,
lang-tag [8] LangTag OPTIONAL, lang-tag [8] LangTag OPTIONAL,
... ...
} }
KDC-REP-1510 { EncPart } ::= SEQUENCE {
COMPONENTS OF KDC-REP-COMMON { EncPart }
} (WITH COMPONENTS {
...,
msg-type (11 | 13),
crealm (RealmIA5),
cname (PrincipalNameIA5)
})
KDC-REP-EXT { EncPart } ::= KDC-REP-COMMON { EncPart }
(WITH COMPONENTS {
...,
msg-type (7 | 9),
crealm (RealmExt),
cname (PrincipalNameExt)
})
req-cksum req-cksum
Signature of the original request using the reply key, to avoid Signature of the original request using the reply key, to avoid
replay attacks against the client, among other things. Only replay attacks against the client, among other things. Only
present in the extensible version of KDC-REP. present in the extensible version of KDC-REP.
AS-REP ::= CHOICE { AS-REP ::= CHOICE {
rfc1510 [APPLICATION 11] KDC-REP-1510 { rfc1510 AS-REP-1510,
EncASRepPart1510 ext AS-REP-EXT
} (WITH COMPONENTS { ..., msg-type (11) }), }
ext [APPLICATION 7] Signed { AS-REP-1510 ::= [APPLICATION 11] KDC-REP-1510
[APPLICATION 7] KDC-REP-EXT { EncASRepPartExt }, AS-REP-EXT ::= [APPLICATION 7] Signed {
[APPLICATION 7] KDC-REP-EXT,
{ key-reply }, { ku-ASRep-cksum } { key-reply }, { ku-ASRep-cksum }
} (WITH COMPONENTS { ..., msg-type (7) })
} }
TGS-REP ::= CHOICE { TGS-REP ::= CHOICE {
rfc1510 [APPLICATION 13] KDC-REP-1510 { rfc1510 TGS-REP-1510,
EncTGSRepPart1510 ext TGS-REP-EXT
} (WITH COMPONENTS { ..., msg-type (13) }), }
ext [APPLICATION 9] Signed { TGS-REP-1510 ::= [APPLICATION 13] KDC-REP-1510 { EncTGSRepPart1510 }
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 }
} (WITH COMPONENTS { ..., msg-type (9) })
} }
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 ]
skipping to change at page 59, line 8 skipping to change at page 61, line 32
9. Errors 9. Errors
The KRB-ERROR message is returned by the KDC if an error occurs The KRB-ERROR message is returned by the KDC if an error occurs
during credentials acquisition. It may also be returned by an during credentials acquisition. It may also be returned by an
application server if an error occurs during authentication. application server if an error occurs during authentication.
ErrCode ::= Int32 ErrCode ::= Int32
KRB-ERROR ::= CHOICE { KRB-ERROR ::= CHOICE {
rfc1510 [APPLICATION 30] KRB-ERROR-1510, rfc1510 KRB-ERROR-1510,
ext [APPLICATION 23] Signed { ext KRB-ERROR-EXT
KRB-ERROR-EXT, { ku-KrbError-cksum } }
} }
The extensible KRB-ERROR is only signed if there has been a key The extensible KRB-ERROR is only signed if there has been a key
negotiated with its recipient. KRB-ERROR messages sent in response negotiated with its recipient. KRB-ERROR messages sent in response
to AS-REQ messages will probably not be signed unless a to AS-REQ messages will probably not be signed unless a
preauthentication mechanism has negotiated a key. (Signing using a preauthentication mechanism has negotiated a key. (Signing using a
client's long-term key can expose ciphertext to dictionary attacks.) client's long-term key can expose ciphertext to dictionary attacks.)
KRB-ERROR-1510 ::= [APPLICATION 30] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (30),
ctime [2] KerberosTime OPTIONAL,
cusec [3] Microseconds OPTIONAL,
stime [4] KerberosTime,
susec [5] Microseconds,
error-code [6] ErrCode,
crealm [7] RealmIA5 OPTIONAL,
cname [8] PrincipalNameIA5 OPTIONAL,
realm [9] RealmIA5 -- Correct realm --,
sname [10] PrincipalNameIA5 -- Correct name --,
e-text [11] KerberosString OPTIONAL,
e-data [12] OCTET STRING OPTIONAL
}
The parts of a KRB-ERROR common to both the backwards-compatibility KRB-ERROR-EXT ::= [APPLICATION 23] Signed {
and the extensibile messages are [APPLICATION 23] SEQUENCE{
KRB-ERROR-COMMON ::= SEQUENCE {
pvno [0] INTEGER (5), pvno [0] INTEGER (5),
msg-type [1] INTEGER (30 | 23), msg-type [1] INTEGER (23),
ctime [2] KerberosTime OPTIONAL, ctime [2] KerberosTime OPTIONAL,
cusec [3] Microseconds OPTIONAL, cusec [3] Microseconds OPTIONAL,
stime [4] KerberosTime, stime [4] KerberosTime,
susec [5] Microseconds, susec [5] Microseconds,
error-code [6] ErrCode, error-code [6] ErrCode,
crealm [7] Realm OPTIONAL, crealm [7] Realm OPTIONAL,
cname [8] PrincipalName OPTIONAL, cname [8] PrincipalName OPTIONAL,
realm [9] Realm -- Correct realm --, realm [9] Realm -- Correct realm --,
sname [10] PrincipalName -- Correct name --, sname [10] PrincipalName -- Correct name --,
e-text [11] KerberosString OPTIONAL, e-text [11] KerberosString OPTIONAL,
e-data [12] OCTET STRING OPTIONAL, e-data [12] OCTET STRING OPTIONAL,
..., ...,
typed-data [13] TYPED-DATA OPTIONAL, typed-data [13] TYPED-DATA OPTIONAL,
nonce [14] Nonce OPTIONAL, nonce [14] Nonce OPTIONAL,
lang-tag [15] LangTag OPTIONAL, lang-tag [15] LangTag OPTIONAL,
... ...
}, { }, { ku-KrbError-cksum }
} }
KRB-ERROR-1510 ::= SEQUENCE {
COMPONENTS OF KRB-ERROR-COMMON
} (WITH COMPONENTS {
...,
msg-type (30)
})
KRB-ERROR-EXT ::= [APPLICATION 23] KRB-ERROR-COMMON
(WITH COMPONENTS { ..., msg-type (23) })
ctime, cusec ctime, cusec
Client's time, if known from a KDC-REQ or AP-REQ. Client's time, if known from a KDC-REQ or AP-REQ.
stime, susec stime, susec
KDC or application server's current time. KDC or application server's current time.
error-code error-code
Numeric error code designating the error. Numeric error code designating the error.
crealm, cname crealm, cname
skipping to change at page 61, line 13 skipping to change at page 64, line 4
extensible KRB-ERROR. extensible KRB-ERROR.
TDType ::= TH-id TDType ::= TH-id
TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
data-type [0] TDType, data-type [0] TDType,
data-value [1] OCTET STRING OPTIONAL data-value [1] OCTET STRING OPTIONAL
} }
10. Session Key Exchange 10. Session Key Exchange
Session key exchange consists of the AP-REQ and AP-REP messages. The Session key exchange consists of the AP-REQ and AP-REP messages. The
client sends the AP-REQ message, and the service responds with an client sends the AP-REQ message, and the service responds with an AP-
AP-REP message if mutual authentication is desired. Following REP message if mutual authentication is desired. Following session
session key exchange, the client and service share a secret session key exchange, the client and service share a secret session key, or
key, or possibly a subsesion key, which can be used to protect possibly a subsesion key, which can be used to protect further
further communications. Additionally, the session key exchange communications. Additionally, the session key exchange process can
process can establish initial sequence numbers which the client and establish initial sequence numbers which the client and service can
service can use to detect replayed messages. use to detect replayed messages.
10.1. AP-REQ 10.1. AP-REQ
An AP-REQ message contains a ticket and a authenticator. The An AP-REQ message contains a ticket and a authenticator. The
authenticator is ciphertext encrypted with the session key contained authenticator is ciphertext encrypted with the session key contained
in the ticket. The plaintext contents of the authenticator are: in the ticket. The plaintext contents of the authenticator are:
-- plaintext of authenticator -- plaintext of authenticator
Authenticator ::= [APPLICATION 2] SEQUENCE { Authenticator1510 ::= [APPLICATION 2] SEQUENCE {
authenticator-vno [0] INTEGER (5), authenticator-vno [0] INTEGER (5),
crealm [1] Realm, crealm [1] RealmIA5,
cname [2] PrincipalName, cname [2] PrincipalNameIA5,
cksum [3] Checksum {{ key-session }, cksum [3] Checksum {{ key-session },
{ ku-Authenticator-cksum | { ku-Authenticator-cksum |
ku-pa-TGSReq-cksum }} OPTIONAL, ku-pa-TGSReq-cksum }} OPTIONAL,
cusec [4] Microseconds, cusec [4] Microseconds,
ctime [5] KerberosTime, ctime [5] KerberosTime,
subkey [6] EncryptionKey OPTIONAL, subkey [6] EncryptionKey OPTIONAL,
seq-number [7] SeqNum OPTIONAL, seq-number [7] SeqNum32 OPTIONAL,
authorization-data [8] AuthorizationData OPTIONAL authorization-data [8] AuthorizationData OPTIONAL
} }
The common parts between the RFC 1510 and the extensible versions of AuthenticatorExt ::= [APPLICATION 35] SEQUENCE {
the AP-REQ are: authenticator-vno [0] INTEGER (5),
crealm [1] RealmExt,
cname [2] PrincipalNameExt,
cksum [3] Checksum {{ key-session },
{ ku-Authenticator-cksum |
ku-pa-TGSReq-cksum }} OPTIONAL,
cusec [4] Microseconds,
ctime [5] KerberosTime,
subkey [6] EncryptionKey OPTIONAL,
seq-number [7] SeqNum OPTIONAL,
authorization-data [8] AuthorizationData OPTIONAL,
...
}
AP-REQ-COMMON ::= SEQUENCE { The complete definition of AP-REQ is:
AP-REQ ::= CHOICE {
rfc1510 AP-REQ-1510,
ext AP-REQ-EXT
}
AP-REQ-1510 ::= [APPLICATION 14] SEQUENCE {
pvno [0] INTEGER (5), pvno [0] INTEGER (5),
msg-type [1] INTEGER (14 | 18), msg-type [1] INTEGER (14),
ap-options [2] APOptions, ap-options [2] APOptions,
ticket [3] Ticket, ticket [3] Ticket1510,
authenticator [4] EncryptedData { authenticator [4] EncryptedData {
Authenticator, Authenticator1510,
{ key-session }, { key-session },
{ ku-APReq-authenticator | { ku-APReq-authenticator |
ku-pa-TGSReq-authenticator } ku-pa-TGSReq-authenticator }
},
...,
extensions [5] ApReqExtensions OPTIONAL,
lang-tag [6] SEQUENCE (SIZE (1..MAX))
OF LangTag OPTIONAL,
...
}
The complete definition of AP-REQ is:
AP-REQ ::= CHOICE {
rfc1510 [APPLICATION 14] AP-REQ-1510,
ext [APPLICATION 18] Signed {
AP-REQ-EXT, { key-session }, { ku-APReq-cksum }
} }
} }
AP-REQ-COMMON ::= SEQUENCE { AP-REQ-EXT ::= [APPLICATION 18] Signed {
[APPLICATION 18] SEQUENCE {
pvno [0] INTEGER (5), pvno [0] INTEGER (5),
msg-type [1] INTEGER (14 | 18), msg-type [1] INTEGER (18),
ap-options [2] APOptions, ap-options [2] APOptions,
ticket [3] Ticket, ticket [3] Ticket,
authenticator [4] EncryptedData { authenticator [4] EncryptedData {
Authenticator, AuthenticatorExt,
{ key-session }, { key-session },
{ ku-APReq-authenticator | { ku-APReq-authenticator |
ku-pa-TGSReq-authenticator } ku-pa-TGSReq-authenticator }
}, },
..., ...,
extensions [5] ApReqExtensions OPTIONAL, extensions [5] ApReqExtensions OPTIONAL,
lang-tag [6] SEQUENCE (SIZE (1..MAX)) lang-tag [6] SEQUENCE (SIZE (1..MAX))
OF LangTag OPTIONAL, OF LangTag OPTIONAL,
... ...
}, { key-session }, { ku-APReq-cksum }
} }
AP-REQ-1510 ::= SEQUENCE {
COMPONENTS OF AP-REQ-COMMON
} (WITH COMPONENTS {
...,
msg-type (14),
authenticator (EncryptedData {
Authenticator (WITH COMPONENTS {
...,
crealm (RealmIA5),
cname (PrincipalNameIA5),
seqnum (UInt32)
}), { key-session }, { ku-APReq-authenticator }})
})
AP-REQ-EXT ::= AP-REQ-COMMON
(WITH COMPONENTS {
...,
msg-type (18),
-- The following constraints on Authenticator assume that
-- we want to restrict the use of AP-REQ-EXT with TicketExt
-- only, since that is the only way we can enforce UTF-8.
authenticator (EncryptedData {
Authenticator (WITH COMPONENTS {
...,
crealm (RealmExt),
cname (PrincipalNameExt),
authorization-data (SIZE (1..MAX))
}), { key-session }, { ku-APReq-authenticator }})
})
APOptions ::= KerberosFlags { APOptionsBits } APOptions ::= KerberosFlags { APOptionsBits }
APOptionsBits ::= BIT STRING { APOptionsBits ::= BIT STRING {
reserved (0), reserved (0),
use-session-key (1), use-session-key (1),
mutual-required (2) mutual-required (2)
} }
10.2. AP-REP 10.2. AP-REP
An AP-REP message provides mutual authentication of the service to An AP-REP message provides mutual authentication of the service to
the client. the client.
EncAPRepPart ::= CHOICE { EncAPRepPart ::= CHOICE {
rfc1510 [APPLICATION 27] EncAPRepPart1510, rfc1510 EncAPRepPart1510,
ext [APPLICATION 31] EncAPRepPartExt ext EncAPRepPartExt
} }
EncAPRepPartCom ::= SEQUENCE {
EncAPRepPart1510 ::= [APPLICATION 27] SEQUENCE {
ctime [0] KerberosTime,
cusec [1] Microseconds,
subkey [2] EncryptionKey OPTIONAL,
seq-number [3] SeqNum32 OPTIONAL
}
EncAPRepPartExt ::= [APPLICATION 31] SEQUENCE {
ctime [0] KerberosTime, ctime [0] KerberosTime,
cusec [1] Microseconds, cusec [1] Microseconds,
subkey [2] EncryptionKey OPTIONAL, subkey [2] EncryptionKey OPTIONAL,
seq-number [3] SeqNum OPTIONAL, seq-number [3] SeqNum OPTIONAL,
..., ...,
authorization-data [4] AuthorizationData OPTIONAL, authorization-data [4] AuthorizationData OPTIONAL,
... ...
} }
EncAPRepPart1510 ::= SEQUENCE {
COMPONENTS OF ENCAPRepPartCom
} (WITH COMPONENTS {
...,
seq-number (UInt32),
authorization-data ABSENT
})
EncAPRepPartExt ::= EncAPRepPartCom
AP-REP ::= CHOICE { AP-REP ::= CHOICE {
rfc1510 [APPLICATION 15] AP-REP-1510, rfc1510 AP-REP-1510,
ext [APPLICATION 19] Signed { ext AP-REP-EXT
AP-REP-EXT,
{ key-session | key-subsession }, { ku-APRep-cksum }}
} }
AP-REP-COMMON { EncPart } ::= SEQUENCE { AP-REP-1510 ::= [APPLICATION 15] SEQUENCE {
pvno [0] INTEGER (5), pvno [0] INTEGER (5),
msg-type [1] INTEGER (15 | 19), msg-type [1] INTEGER (15),
enc-part [2] EncryptedData { enc-part [2] EncryptedData {
EncPart, EncApRepPart1510,
{ key-session | key-subsession }, { ku-EncAPRepPart }}
}
AP-REP-EXT ::= [APPLICATION 19] Signed {
[APPLICATION 19] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (19),
enc-part [2] EncryptedData {
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 }
} }
AP-REP-1510 ::= SEQUENCE {
COMPONENTS OF AP-REP-COMMON { EncAPRepPart1510 }
} (WITH COMPONENTS {
...,
msg-type (15)
})
AP-REP-EXT ::= [APPLICATION 19] AP-REP-COMMON {
EncAPRepPartExt
} (WITH COMPONENTS { ..., msg-type (19) })
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
provides integrity protection for application data, while KRB-PRIV provides integrity protection for application data, while KRB-PRIV
provides confidentiality along with integrity protection. The KRB- provides confidentiality along with integrity protection. The KRB-
CRED message provides a means of securely forwarding credentials from CRED message provides a means of securely forwarding credentials from
the client host to the server host. the client host to the server host.
11.1. KRB-SAFE 11.1. KRB-SAFE
The KRB-SAFE message provides integrity protection for an included The KRB-SAFE message provides integrity protection for an included
cleartext message. cleartext message.
-- Do we chew up another tag for KRB-SAFE-EXT? That would KRB-SAFE ::= CHOICE {
-- allow us to make safe-body optional, allowing for a GSS-MIC rfc1510 KRB-SAFE-1510,
-- sort of message. ext KRB-SAFE-EXT
KRB-SAFE ::= [APPLICATION 20] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (20),
safe-body [2] KRB-SAFE-BODY,
cksum [3] ChecksumOf {
KRB-SAFE-BODY,
{ key-session | key-subsession }, { ku-KrbSafe-cksum }},
... -- ASN.1 extensions must be excluded
-- when sending to rfc1510 implementations
} }
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
skipping to change at page 66, line 31 skipping to change at page 68, line 31
... -- ASN.1 extensions must be excluded ... -- ASN.1 extensions must be excluded
-- when sending to rfc1510 implementations -- when sending to rfc1510 implementations
} }
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 [APPLICATION 22] KRB-CRED-1510, rfc1510 KRB-CRED-1510,
ext [APPLICATION 24] Signed { ext KRB-CRED-EXT
KRB-CRED-EXT,
{ key-session | key-subsession }, { ku-KrbCred-cksum }}
} }
KRB-CRED-COMMON ::= SEQUENCE { KRB-CRED-1510 ::= [APPLICATION 22] SEQUENCE {
pvno [0] INTEGER (5), pvno [0] INTEGER (5),
msg-type [1] INTEGER (22 | 24), msg-type [1] INTEGER (22),
tickets [2] SEQUENCE OF Ticket,
enc-part [3] EncryptedData {
EncKrbCredPart,
{ key-session | key-subsession }, { ku-EncKrbCredPart }}
}
KRB-CRED-EXT ::= [APPLICATION 24] Signed {
[APPLICATION 24] SEQUENCE {
pvno [0] INTEGER (5),
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 }
} }
KRB-CRED-1510 ::= SEQUENCE {
COMPONENTS OF KRB-CRED-COMMON
} (WITH COMPONENTS { ..., msg-type (22) })
KRB-CRED-EXT ::= [APPLICATION 24] KRB-CRED-COMMON
(WITH COMPONENTS { ..., msg-type (24) })
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 69, line 14 skipping to change at page 71, line 23
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 draft-ietf-krb-wg-kerberos-
clarifications-07. The description of the general form of the clarifications-07. The description of the general form of the
extensibility framework was derived from text by Sam Hartman. extensibility framework was derived from text by Sam Hartman. Some
text concerning internationalization of internationalized domain
names in principal names and realm names was contributed by Jeffrey
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 72, line 26 skipping to change at page 74, line 26
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
PrincipalName ::= 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 name-string [1] SEQUENCE OF KerberosString (StrType)
} }
-- IA5 only -- IA5 only
PrincipalNameIA5 ::= PrincipalName (WITH COMPONENTS { PrincipalNameIA5 ::= PrincipalName { KerberosStringIA5 }
...,
name-string (WITH COMPONENT (KerberosStringIA5))
})
-- IA5 excluded -- IA5 excluded
PrincipalNameExt ::= PrincpalName (WITH COMPONENTS { PrincipalNameExt ::= PrincipalName { KerberosStringExt }
..., -- Either one?
name-string (WITH COMPONENT (KerberosStringExt)) PrincipalNameEither ::= PrincipalName { KerberosString }
})
Realm ::= KerberosString 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
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 -- but if the value to be sent would be truncated to shorter
-- than 32 bits according to DER, the value MUST be padded -- than 32 bits according to DER, the value MUST be padded
-- with trailing zero bits to 32 bits. Otherwise, no -- with trailing zero bits to 32 bits. Otherwise, no
-- trailing zero bits may be present. -- trailing zero bits may be present.
}) })
skipping to change at page 78, line 32 skipping to change at page 80, line 32
} OPTIONAL, } OPTIONAL,
inner [1] InnerType, inner [1] InnerType,
... ...
} }
-- --
-- *** Tickets -- *** Tickets
-- --
Ticket ::= CHOICE { Ticket ::= CHOICE {
rfc1510 [APPLICATION 1] Ticket1510, rfc1510 Ticket1510,
ext [APPLICATION 4] Signed { ext TicketExt
TicketExt, { key-server }, { ku-Ticket-cksum }
}
} }
-- takes a parameter specifying which type gets encrypted Ticket1510 ::= [APPLICATION 1] SEQUENCE {
TicketCommon { EncPart } ::= SEQUENCE {
tkt-vno [0] INTEGER (5), tkt-vno [0] INTEGER (5),
realm [1] Realm, realm [1] RealmIA5,
sname [2] PrincipalName, sname [2] PrincipalNameIA5,
enc-part [3] EncryptedData { enc-part [3] EncryptedData {
EncPart, { key-server }, { ku-Ticket } EncTicketPart1510, { key-server }, { ku-Ticket }
}
}
TicketExt ::= [APPLICATION 4] Signed {
[APPLICATION 4] SEQUENCE {
tkt-vno [0] INTEGER (5),
realm [1] RealmExt,
sname [2] PrincipalNameExt,
enc-part [3] EncryptedData {
EncTicketPartExt, { key-server }, { ku-Ticket }
}, },
..., ...,
extensions [4] TicketExtensions OPTIONAL, extensions [4] TicketExtensions OPTIONAL,
... ...
},
{ key-ticket }, { ku-Ticket-cksum }
} }
Ticket1510 ::= SEQUENCE {
COMPONENTS OF TicketCommon { EncTicketPart1510 }
} (WITH COMPONENTS {
...,
-- explicitly force IA5 in strings
realm (RealmIA5),
sname (PrincipalNameIA5)
})
-- APPLICATION tag goes inside Signed{} as well as outside,
-- to prevent possible substitution attacks.
TicketExt ::= [APPLICATION 4] TicketCommon {
EncTicketPartExt
} (WITH COMPONENTS {
...,
-- explicitly force UTF-8 in strings
realm (RealmExt),
sname (PrincipalNameExt)
})
-- Encrypted part of ticket -- Encrypted part of ticket
EncTicketPart ::= CHOICE { EncTicketPart ::= CHOICE {
rfc1510 [APPLICATION 3] EncTicketPart1510, rfc1510 EncTicketPart1510,
ext [APPLICATION 5] EncTicketPartExt ext EncTicketPartExt
} }
EncTicketPartCommon ::= SEQUENCE { EncTicketPart1510 ::= [APPLICATION 3] SEQUENCE {
flags [0] TicketFlags, flags [0] TicketFlags,
key [1] EncryptionKey, key [1] EncryptionKey,
crealm [2] Realm, crealm [2] RealmIA5,
cname [3] PrincipalName, cname [3] PrincipalNameIA5,
transited [4] TransitedEncoding, transited [4] TransitedEncoding,
authtime [5] KerberosTime, authtime [5] KerberosTime,
starttime [6] KerberosTime OPTIONAL, starttime [6] KerberosTime OPTIONAL,
endtime [7] KerberosTime, endtime [7] KerberosTime,
renew-till [8] KerberosTime OPTIONAL, renew-till [8] KerberosTime OPTIONAL,
caddr [9] HostAddresses OPTIONAL, caddr [9] HostAddresses OPTIONAL,
authorization-data [10] AuthorizationData OPTIONAL, authorization-data [10] AuthorizationData OPTIONAL
...
} }
EncTicketPart1510 ::= SEQUENCE { EncTicketPartExt ::= [APPLICATION 5] SEQUENCE {
COMPONENTS OF EncTicketPartCommon flags [0] TicketFlags,
} (WITH COMPONENTS { key [1] EncryptionKey,
..., crealm [2] RealmExt,
-- explicitly force IA5 in strings cname [3] PrincipalNameExt,
crealm (RealmIA5), transited [4] TransitedEncoding,
cname (PrincipalNameIA5) authtime [5] KerberosTime,
}) starttime [6] KerberosTime OPTIONAL,
endtime [7] KerberosTime,
EncTicketPartExt ::= EncTicketPartCommon (WITH COMPONENTS { renew-till [8] KerberosTime OPTIONAL,
caddr [9] HostAddresses OPTIONAL,
authorization-data [10] AuthorizationData OPTIONAL,
..., ...,
-- explicitly force UTF-8 in strings }
crealm (RealmExt),
cname (PrincipalNameExt),
-- explicitly constrain caddr to be non-empty if present
caddr (SIZE (1..MAX)),
-- forbid empty authorization-data encodings
authorization-data (SIZE (1..MAX))
})
-- --
-- *** Authorization Data -- *** Authorization Data
-- --
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
skipping to change at page 81, line 15 skipping to change at page 83, line 4
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,
i-sname [2] PrincipalName OPTIONAL, i-sname [2] PrincipalName OPTIONAL,
elements [3] AuthorizationData elements [3] AuthorizationData
} }
ad-and-or ADType ::= int32 : 5 ad-and-or ADType ::= int32 : 5
AD-AND-OR ::= SEQUENCE { AD-AND-OR ::= SEQUENCE {
condition-count [0] INTEGER, condition-count [0] Int32,
elements [1] AuthorizationData elements [1] AuthorizationData
} }
-- KDCs MUST interpret any AuthorizationData wrapped in this. -- KDCs MUST interpret any AuthorizationData wrapped in this.
ad-mandatory-for-kdc ADType ::= int32 : 8 ad-mandatory-for-kdc ADType ::= int32 : 8
AD-MANDATORY-FOR-KDC ::= AuthorizationData AD-MANDATORY-FOR-KDC ::= AuthorizationData
ad-initial-verified-cas ADType ::= int32 : 9
TrType ::= TH-id -- must be registered TrType ::= TH-id -- must be registered
-- encoded Transited field -- encoded Transited field
TransitedEncoding ::= SEQUENCE { TransitedEncoding ::= SEQUENCE {
tr-type [0] TrType, tr-type [0] TrType,
contents [1] OCTET STRING contents [1] OCTET STRING
} }
TEType ::= TH-id TEType ::= TH-id
skipping to change at page 83, line 4 skipping to change at page 84, line 28
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)
} }
-- --
-- *** KDC protocol -- *** KDC protocol
-- --
AS-REQ ::= CHOICE { AS-REQ ::= CHOICE {
rfc1510 [APPLICATION 10] KDC-REQ-1510 rfc1510 AS-REQ-1510,
(WITH COMPONENTS { ext AS-REQ-EXT
...,
msg-type (10),
-- AS-REQ must include client name
req-body (WITH COMPONENTS { ..., cname PRESENT })
}),
ext [APPLICATION 6] Signed {
-- APPLICATION tag goes inside Signed{} as well as
-- outside, to prevent possible substitution attacks.
[APPLICATION 6] KDC-REQ-EXT,
-- not sure this is correct key to use; do we even want
-- to sign AS-REQ?
{ key-client },
{ ku-ASReq-cksum }
} }
(WITH COMPONENTS { AS-REQ-1510 ::= [APPLICATION 10] KDC-REQ-1510
...,
msg-type (6),
-- AS-REQ must include client name -- AS-REQ must include client name
req-body (WITH COMPONENTS { ..., cname PRESENT })
}) AS-REQ-EXT ::= [APPLICATION 6] Signed {
[APPLICATION 6] KDC-REQ-EXT, { key-client }, { ku-ASReq-cksum }
} }
-- AS-REQ must include client name
TGS-REQ ::= CHOICE { TGS-REQ ::= CHOICE {
rfc1510 [APPLICATION 12] KDC-REQ-1510 rfc1510 TGS-REQ-1510,
(WITH COMPONENTS { ext TGS-REQ-EXT
...,
msg-type (12),
-- client name optional in TGS-REQ
req-body (WITH COMPONENTS { ..., cname ABSENT })
}),
ext [APPLICATION 8] Signed {
-- APPLICATION tag goes inside Signed{} as well as
-- outside, to prevent possible substitution attacks.
[APPLICATION 8] KDC-REQ-EXT,
{ key-session }, { ku-TGSReq-cksum }
} }
(WITH COMPONENTS {
..., TGS-REQ-1510 ::= [APPLICATION 12] KDC-REQ-1510
msg-type (8),
-- client name optional in TGS-REQ TGS-REQ-EXT ::= [APPLICATION 8] Signed {
req-body (WITH COMPONENTS { ..., cname ABSENT }) [APPLICATION 8] KDC-REQ-EXT, { key-session }, { ku-TGSReq-cksum }
})
} }
KDC-REQ-COMMON ::= 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.rfc1510 -- msg-type [2] INTEGER ( 10 -- AS-REQ --
| 12 -- TGS-REQ.rfc1510 -- | 12 -- TGS-REQ -- ),
| 6 -- AS-REQ.ext -- padata [3] SEQUENCE OF PA-DATA OPTIONAL,
| 8 -- TGS-REQ.ext -- ),
padata [3] SEQUENCE OF PA-DATA OPTIONAL
-- NOTE: not empty
}
KDC-REQ-1510 ::= SEQUENCE {
COMPONENTS OF KDC-REQ-COMMON,
req-body [4] KDC-REQ-BODY-1510 req-body [4] KDC-REQ-BODY-1510
} (WITH COMPONENTS { ..., msg-type (10 | 12) }) }
-- APPLICATION tag goes inside Signed{} as well as outside,
-- to prevent possible substitution attacks.
KDC-REQ-EXT ::= SEQUENCE { KDC-REQ-EXT ::= SEQUENCE {
COMPONENTS OF KDC-REQ-COMMON, pvno [1] INTEGER (5),
msg-type [2] INTEGER ( 6 -- AS-REQ --
| 8 -- TGS-REQ -- ),
padata [3] SEQUENCE (SIZE (1..MAX)) OF PA-DATA OPTIONAL,
req-body [4] KDC-REQ-BODY-EXT, req-body [4] KDC-REQ-BODY-EXT,
... ...
} (WITH COMPONENTS { }
...,
msg-type (6 | 8), KDC-REQ-BODY-1510 ::= SEQUENCE {
padata (SIZE (1..MAX)) kdc-options [0] KDCOptions,
}) cname [1] PrincipalNameIA5 OPTIONAL
KDC-REQ-BODY-COMMON ::= SEQUENCE { -- Used only in AS-REQ --,
realm [2] RealmIA5
-- Server's realm; also client's in AS-REQ --,
sname [3] PrincipalNameIA5 OPTIONAL,
from [4] KerberosTime OPTIONAL,
till [5] KerberosTime,
rtime [6] KerberosTime OPTIONAL,
nonce [7] Nonce32,
etype [8] SEQUENCE OF EType
-- in preference order --,
addresses [9] HostAddresses OPTIONAL,
enc-authorization-data [10] EncryptedData {
AuthorizationData, { key-session | key-subsession },
{ ku-TGSReqAuthData-subkey |
ku-TGSReqAuthData-sesskey }
} OPTIONAL,
additional-tickets [11] SEQUENCE OF Ticket OPTIONAL
-- NOTE: not empty --
}
KDC-REQ-BODY-EXT ::= SEQUENCE {
kdc-options [0] KDCOptions, kdc-options [0] KDCOptions,
cname [1] PrincipalName OPTIONAL cname [1] PrincipalName OPTIONAL
-- Used only in AS-REQ --, -- Used only in AS-REQ --,
realm [2] Realm realm [2] Realm
-- Server's realm; also client's in AS-REQ --, -- Server's realm; also client's in AS-REQ --,
sname [3] PrincipalName OPTIONAL, sname [3] PrincipalName OPTIONAL,
from [4] KerberosTime OPTIONAL, from [4] KerberosTime OPTIONAL,
till [5] KerberosTime OPTIONAL till [5] KerberosTime OPTIONAL
skipping to change at page 85, line 38 skipping to change at page 87, line 4
ku-TGSReqAuthData-sesskey } ku-TGSReqAuthData-sesskey }
} OPTIONAL, } OPTIONAL,
additional-tickets [11] SEQUENCE OF Ticket OPTIONAL additional-tickets [11] SEQUENCE OF Ticket OPTIONAL
-- NOTE: not empty --, -- NOTE: not empty --,
... ...
lang-tags [5] SEQUENCE (SIZE (1..MAX)) OF lang-tags [5] SEQUENCE (SIZE (1..MAX)) OF
LangTag OPTIONAL, LangTag OPTIONAL,
... ...
} }
KDC-REQ-BODY-1510 ::= SEQUENCE {
COMPONENTS OF KDC-REQ-BODY-COMMON
} (WITH COMPONENTS {
...,
cname (PrincipalNameIA5),
realm (RealmIA5),
sname (PrincipalNameIA5),
till PRESENT,
nonce (UInt32)
})
KDC-REQ-BODY-EXT ::= KDC-REQ-BODY-COMMON
(WITH COMPONENTS {
...,
cname (PrincipalNameExt),
realm (RealmExt),
sname (PrincipalNameExt),
addresses (SIZE (1..MAX)),
enc-authorization-data (EncryptedData {
AuthorizationData (SIZE (1..MAX)),
{ key-session | key-subsession },
{ ku-TGSReqAuthData-subkey |
ku-TGSReqAuthData-sesskey }
}),
additional-tickets (SIZE (1..MAX))
})
KDCOptions ::= KerberosFlags { KDCOptionsBits } KDCOptions ::= KerberosFlags { KDCOptionsBits }
KDCOptionsBits ::= BIT STRING { KDCOptionsBits ::= BIT STRING {
reserved (0), reserved (0),
forwardable (1), forwardable (1),
forwarded (2), forwarded (2),
proxiable (3), proxiable (3),
proxy (4), proxy (4),
allow-postdate (5), allow-postdate (5),
postdated (6), postdated (6),
skipping to change at page 87, line 4 skipping to change at page 87, line 30
unused13 (13), unused13 (13),
requestanonymous (14), requestanonymous (14),
canonicalize (15), canonicalize (15),
disable-transited-check (26), disable-transited-check (26),
renewable-ok (27), renewable-ok (27),
enc-tkt-in-skey (28), enc-tkt-in-skey (28),
renew (30), renew (30),
validate (31) validate (31)
-- XXX need "need ticket1" flag? -- XXX need "need ticket1" flag?
} }
AS-REP ::= CHOICE { AS-REP ::= CHOICE {
rfc1510 [APPLICATION 11] KDC-REP-1510 { rfc1510 AS-REP-1510,
EncASRepPart1510 ext AS-REP-EXT
} (WITH COMPONENTS { ..., msg-type (11) }), }
ext [APPLICATION 7] Signed { AS-REP-1510 ::= [APPLICATION 11] KDC-REP-1510
[APPLICATION 7] KDC-REP-EXT { EncASRepPartExt }, AS-REP-EXT ::= [APPLICATION 7] Signed {
[APPLICATION 7] KDC-REP-EXT,
{ key-reply }, { ku-ASRep-cksum } { key-reply }, { ku-ASRep-cksum }
} (WITH COMPONENTS { ..., msg-type (7) })
} }
TGS-REP ::= CHOICE { TGS-REP ::= CHOICE {
rfc1510 [APPLICATION 13] KDC-REP-1510 { rfc1510 TGS-REP-1510,
EncTGSRepPart1510 ext TGS-REP-EXT
} (WITH COMPONENTS { ..., msg-type (13) }), }
ext [APPLICATION 9] Signed { TGS-REP-1510 ::= [APPLICATION 13] KDC-REP-1510 { EncTGSRepPart1510 }
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 }
} (WITH COMPONENTS { ..., msg-type (9) })
} }
KDC-REP-COMMON { 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 -- ),
7 -- AS-REP.ext -- | padata [2] SEQUENCE OF PA-DATA OPTIONAL,
crealm [3] RealmIA5,
cname [4] PrincipalNameIA5,
ticket [5] Ticket,
enc-part [6] EncryptedData {
EncPart,
{ key-reply },
-- maybe reach into EncryptedData in AS-REP/TGS-REP
-- definitions to apply constraints on key usages?
{ ku-EncASRepPart -- if AS-REP -- |
ku-EncTGSRepPart-subkey -- if TGS-REP and
-- using Authenticator
-- session key -- |
ku-EncTGSRepPart-sesskey -- if TGS-REP and using
-- subsession key -- }
}
}
KDC-REP-EXT { EncPart } ::= SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (7 -- AS-REP.ext -- |
9 -- TGS-REP.ext -- ), 9 -- TGS-REP.ext -- ),
padata [2] SEQUENCE OF PA-DATA OPTIONAL, padata [2] SEQUENCE OF PA-DATA OPTIONAL,
crealm [3] Realm, crealm [3] RealmExt,
cname [4] PrincipalName, cname [4] PrincipalNameExt,
ticket [5] Ticket, ticket [5] Ticket,
enc-part [6] EncryptedData { enc-part [6] EncryptedData {
EncPart, EncPart,
{ key-reply }, { key-reply },
-- maybe reach into EncryptedData in AS-REP/TGS-REP -- maybe reach into EncryptedData in AS-REP/TGS-REP
-- definitions to apply constraints on key usages? -- definitions to apply constraints on key usages?
{ ku-EncASRepPart -- if AS-REP -- | { ku-EncASRepPart -- if AS-REP -- |
ku-EncTGSRepPart-subkey -- if TGS-REP and ku-EncTGSRepPart-subkey -- if TGS-REP and
-- using Authenticator -- using Authenticator
skipping to change at page 88, line 38 skipping to change at page 90, line 4
..., ...,
-- In extensible version, KDC signs original request -- In extensible version, KDC signs original request
-- to avoid replay attacks against client. -- to avoid replay attacks against client.
req-cksum [7] ChecksumOf { CHOICE { req-cksum [7] ChecksumOf { CHOICE {
as-req AS-REQ, as-req AS-REQ,
tgs-req TGS-REQ tgs-req TGS-REQ
}, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL, }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL,
lang-tag [8] LangTag OPTIONAL, lang-tag [8] LangTag OPTIONAL,
... ...
} }
KDC-REP-1510 { EncPart } ::= SEQUENCE {
COMPONENTS OF KDC-REP-COMMON { EncPart }
} (WITH COMPONENTS {
...,
msg-type (11 | 13),
crealm (RealmIA5),
cname (PrincipalNameIA5)
})
KDC-REP-EXT { EncPart } ::= KDC-REP-COMMON { EncPart }
(WITH COMPONENTS {
...,
msg-type (7 | 9),
crealm (RealmExt),
cname (PrincipalNameExt)
})
EncASRepPart1510 ::= [APPLICATION 25] EncKDCRepPart1510 EncASRepPart1510 ::= [APPLICATION 25] EncKDCRepPart1510
EncTGSRepPart1510 ::= [APPLICATION 26] EncKDCRepPart1510 EncTGSRepPart1510 ::= [APPLICATION 26] EncKDCRepPart1510
EncASRepPartExt ::= [APPLICATION 32] EncKDCRepPartExt EncASRepPartExt ::= [APPLICATION 32] EncKDCRepPartExt
EncTGSRepPartExt ::= [APPLICATION 33] EncKDCRepPartExt EncTGSRepPartExt ::= [APPLICATION 33] EncKDCRepPartExt
EncKDCRepPartCom ::= SEQUENCE { EncKDCRepPart1510 ::= SEQUENCE {
key [0] EncryptionKey,
last-req [1] LastReq,
nonce [2] Nonce32,
key-expiration [3] KerberosTime OPTIONAL,
flags [4] TicketFlags,
authtime [5] KerberosTime,
starttime [6] KerberosTime OPTIONAL,
endtime [7] KerberosTime,
renew-till [8] KerberosTime OPTIONAL,
srealm [9] RealmIA5,
sname [10] PrincipalNameIA5,
caddr [11] HostAddresses OPTIONAL
}
EncKDCRepPartExt ::= SEQUENCE {
key [0] EncryptionKey, key [0] EncryptionKey,
last-req [1] LastReq, last-req [1] LastReq,
nonce [2] Nonce, nonce [2] Nonce,
key-expiration [3] KerberosTime OPTIONAL, key-expiration [3] KerberosTime OPTIONAL,
flags [4] TicketFlags, flags [4] TicketFlags,
authtime [5] KerberosTime, authtime [5] KerberosTime,
starttime [6] KerberosTime OPTIONAL, starttime [6] KerberosTime OPTIONAL,
endtime [7] KerberosTime, endtime [7] KerberosTime,
renew-till [8] KerberosTime OPTIONAL, renew-till [8] KerberosTime OPTIONAL,
srealm [9] Realm, srealm [9] Realm,
sname [10] PrincipalName, sname [10] PrincipalName,
caddr [11] HostAddresses OPTIONAL, caddr [11] HostAddresses OPTIONAL,
... ...
} }
EncKDCRepPart1510 ::= SEQUENCE {
COMPONENTS OF EncKDCRepPartCom
} (WITH COMPONENTS {
...,
srealm (RealmIA5),
sname (PrincipalNameIA5),
nonce UInt32 })
EncKdcRepPartExt ::= EncKDCRepPartCom (WITH COMPONENTS {
...,
srealm (RealmExt),
sname (PrincipalNameExt)
})
LRType ::= TH-id LRType ::= TH-id
LastReq ::= SEQUENCE OF SEQUENCE { LastReq ::= SEQUENCE OF SEQUENCE {
lr-type [0] LRType, lr-type [0] LRType,
lr-value [1] KerberosTime lr-value [1] KerberosTime
} }
-- --
-- *** preauth -- *** preauth
-- --
PaDataType ::= TH-id PaDataType ::= TH-id
PaDataOID ::= RELATIVE-OID PaDataOID ::= RELATIVE-OID
PA-DATA ::= SEQUENCE { PA-DATA ::= SEQUENCE {
-- NOTE: first tag is [1], not [0] -- NOTE: first tag is [1], not [0]
padata-type [1] PaDataType, padata-type [1] PaDataType,
padata-value [2] OCTET STRING padata-value [2] OCTET STRING
} }
-- AP-REQ authenticating a TGS-REQ -- AP-REQ authenticating a TGS-REQ
skipping to change at page 91, line 29 skipping to change at page 92, line 17
ETYPE-INFO2 ::= SEQUENCE (SIZE (1..MAX)) ETYPE-INFO2 ::= SEQUENCE (SIZE (1..MAX))
OF ETYPE-INFO-ENTRY OF ETYPE-INFO-ENTRY
ETYPE-INFO2-ENTRY ::= SEQUENCE { ETYPE-INFO2-ENTRY ::= SEQUENCE {
etype [0] EType, etype [0] EType,
salt [1] KerberosString OPTIONAL, salt [1] KerberosString OPTIONAL,
s2kparams [2] OCTET STRING OPTIONAL s2kparams [2] OCTET STRING OPTIONAL
} }
-- Obsolescent. Salt for client's long-term key. -- Obsolescent. Salt for client long-term key
-- Its character encoding is unspecified. -- Its character encoding is unspecified.
pa-pw-salt PaDataType ::= int32 : 3 pa-pw-salt PaDataType ::= int32 : 3
-- The "padata-value" does not encode an ASN.1 type. -- The "padata-value" does not encode an ASN.1 type.
-- Instead, "padata-value" must consist of the salt string to -- Instead, "padata-value" must consist of the salt string to
-- be used by the client, in an unspecified character -- be used by the client, in an unspecified character
-- encoding. -- encoding.
-- An extensible AS-REQ may be sent as a padata in a -- An extensible AS-REQ may be sent as a padata in a
-- non-extensible AS-REQ to allow for backwards compatibility. -- non-extensible AS-REQ to allow for backwards compatibility.
pa-as-req PaDataType ::= int32 : 42 -- provisional pa-as-req PaDataType ::= int32 : 42 -- provisional
PA-AS-REQ ::= AS-REQ (WITH COMPONENTS ext) PA-AS-REQ ::= AS-REQ (WITH COMPONENTS ext)
skipping to change at page 92, line 4 skipping to change at page 92, line 34
-- encoding. -- encoding.
-- An extensible AS-REQ may be sent as a padata in a -- An extensible AS-REQ may be sent as a padata in a
-- non-extensible AS-REQ to allow for backwards compatibility. -- non-extensible AS-REQ to allow for backwards compatibility.
pa-as-req PaDataType ::= int32 : 42 -- provisional pa-as-req PaDataType ::= int32 : 42 -- provisional
PA-AS-REQ ::= AS-REQ (WITH COMPONENTS ext) PA-AS-REQ ::= AS-REQ (WITH COMPONENTS ext)
-- --
-- *** Session key exchange -- *** Session key exchange
-- --
AP-REQ ::= CHOICE { AP-REQ ::= CHOICE {
rfc1510 [APPLICATION 14] AP-REQ-1510, rfc1510 AP-REQ-1510,
ext [APPLICATION 18] Signed { ext AP-REQ-EXT
AP-REQ-EXT, { key-session }, { ku-APReq-cksum } }
AP-REQ-1510 ::= [APPLICATION 14] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (14),
ap-options [2] APOptions,
ticket [3] Ticket1510,
authenticator [4] EncryptedData {
Authenticator1510,
{ key-session },
{ ku-APReq-authenticator |
ku-pa-TGSReq-authenticator }
} }
} }
AP-REQ-COMMON ::= SEQUENCE { AP-REQ-EXT ::= [APPLICATION 18] Signed {
[APPLICATION 18] SEQUENCE {
pvno [0] INTEGER (5), pvno [0] INTEGER (5),
msg-type [1] INTEGER (14 | 18), msg-type [1] INTEGER (18),
ap-options [2] APOptions, ap-options [2] APOptions,
ticket [3] Ticket, ticket [3] Ticket,
authenticator [4] EncryptedData { authenticator [4] EncryptedData {
Authenticator, AuthenticatorExt,
{ key-session }, { key-session },
{ ku-APReq-authenticator | { ku-APReq-authenticator |
ku-pa-TGSReq-authenticator } ku-pa-TGSReq-authenticator }
}, },
..., ...,
extensions [5] ApReqExtensions OPTIONAL, extensions [5] ApReqExtensions OPTIONAL,
lang-tag [6] SEQUENCE (SIZE (1..MAX)) lang-tag [6] SEQUENCE (SIZE (1..MAX))
OF LangTag OPTIONAL, OF LangTag OPTIONAL,
... ...
}, { key-session }, { ku-APReq-cksum }
} }
AP-REQ-1510 ::= SEQUENCE {
COMPONENTS OF AP-REQ-COMMON
} (WITH COMPONENTS {
...,
msg-type (14),
authenticator (EncryptedData {
Authenticator (WITH COMPONENTS {
...,
crealm (RealmIA5),
cname (PrincipalNameIA5),
seqnum (UInt32)
}), { key-session }, { ku-APReq-authenticator }})
})
AP-REQ-EXT ::= AP-REQ-COMMON
(WITH COMPONENTS {
...,
msg-type (18),
-- The following constraints on Authenticator assume that
-- we want to restrict the use of AP-REQ-EXT with TicketExt
-- only, since that is the only way we can enforce UTF-8.
authenticator (EncryptedData {
Authenticator (WITH COMPONENTS {
...,
crealm (RealmExt),
cname (PrincipalNameExt),
authorization-data (SIZE (1..MAX))
}), { key-session }, { ku-APReq-authenticator }})
})
ApReqExtType ::= TH-id ApReqExtType ::= TH-id
ApReqExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE { ApReqExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
apReqExt-Type [0] ApReqExtType, apReqExt-Type [0] ApReqExtType,
apReqExt-Data [1] OCTET STRING apReqExt-Data [1] OCTET STRING
} }
APOptions ::= KerberosFlags { APOptionsBits } APOptions ::= KerberosFlags { APOptionsBits }
APOptionsBits ::= BIT STRING { APOptionsBits ::= BIT STRING {
skipping to change at page 93, line 34 skipping to change at page 94, line 4
apReqExt-Data [1] OCTET STRING apReqExt-Data [1] OCTET STRING
} }
APOptions ::= KerberosFlags { APOptionsBits } APOptions ::= KerberosFlags { APOptionsBits }
APOptionsBits ::= BIT STRING { APOptionsBits ::= BIT STRING {
reserved (0), reserved (0),
use-session-key (1), use-session-key (1),
mutual-required (2) mutual-required (2)
} }
-- plaintext of authenticator -- plaintext of authenticator
Authenticator ::= [APPLICATION 2] SEQUENCE { Authenticator1510 ::= [APPLICATION 2] SEQUENCE {
authenticator-vno [0] INTEGER (5), authenticator-vno [0] INTEGER (5),
crealm [1] Realm, crealm [1] RealmIA5,
cname [2] PrincipalName, cname [2] PrincipalNameIA5,
cksum [3] Checksum {{ key-session }, cksum [3] Checksum {{ key-session },
{ ku-Authenticator-cksum | { ku-Authenticator-cksum |
ku-pa-TGSReq-cksum }} OPTIONAL, ku-pa-TGSReq-cksum }} OPTIONAL,
cusec [4] Microseconds, cusec [4] Microseconds,
ctime [5] KerberosTime, ctime [5] KerberosTime,
subkey [6] EncryptionKey OPTIONAL, subkey [6] EncryptionKey OPTIONAL,
seq-number [7] SeqNum OPTIONAL, seq-number [7] SeqNum32 OPTIONAL,
authorization-data [8] AuthorizationData OPTIONAL authorization-data [8] AuthorizationData OPTIONAL
} }
AuthenticatorExt ::= [APPLICATION 35] SEQUENCE {
authenticator-vno [0] INTEGER (5),
crealm [1] RealmExt,
cname [2] PrincipalNameExt,
cksum [3] Checksum {{ key-session },
{ ku-Authenticator-cksum |
ku-pa-TGSReq-cksum }} OPTIONAL,
cusec [4] Microseconds,
ctime [5] KerberosTime,
subkey [6] EncryptionKey OPTIONAL,
seq-number [7] SeqNum OPTIONAL,
authorization-data [8] AuthorizationData OPTIONAL,
...
}
AP-REP ::= CHOICE { AP-REP ::= CHOICE {
rfc1510 [APPLICATION 15] AP-REP-1510, rfc1510 AP-REP-1510,
ext [APPLICATION 19] Signed { ext AP-REP-EXT
AP-REP-EXT,
{ key-session | key-subsession }, { ku-APRep-cksum }}
} }
AP-REP-COMMON { EncPart } ::= SEQUENCE { AP-REP-1510 ::= [APPLICATION 15] SEQUENCE {
pvno [0] INTEGER (5), pvno [0] INTEGER (5),
msg-type [1] INTEGER (15 | 19), msg-type [1] INTEGER (15),
enc-part [2] EncryptedData { enc-part [2] EncryptedData {
EncPart, EncApRepPart1510,
{ key-session | key-subsession }, { ku-EncAPRepPart }}
}
AP-REP-EXT ::= [APPLICATION 19] Signed {
[APPLICATION 19] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (19),
enc-part [2] EncryptedData {
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 }
} }
AP-REP-1510 ::= SEQUENCE {
COMPONENTS OF AP-REP-COMMON { EncAPRepPart1510 }
} (WITH COMPONENTS {
...,
msg-type (15)
})
AP-REP-EXT ::= [APPLICATION 19] AP-REP-COMMON {
EncAPRepPartExt
} (WITH COMPONENTS { ..., msg-type (19) })
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,
apRepExt-Data [1] OCTET STRING apRepExt-Data [1] OCTET STRING
} }
EncAPRepPart ::= CHOICE { EncAPRepPart ::= CHOICE {
rfc1510 [APPLICATION 27] EncAPRepPart1510, rfc1510 EncAPRepPart1510,
ext [APPLICATION 31] EncAPRepPartExt ext EncAPRepPartExt
} }
EncAPRepPart1510 ::= SEQUENCE {
COMPONENTS OF ENCAPRepPartCom
} (WITH COMPONENTS {
...,
seq-number (UInt32),
authorization-data ABSENT
})
EncAPRepPartExt ::= EncAPRepPartCom EncAPRepPart1510 ::= [APPLICATION 27] SEQUENCE {
ctime [0] KerberosTime,
cusec [1] Microseconds,
subkey [2] EncryptionKey OPTIONAL,
seq-number [3] SeqNum32 OPTIONAL
}
EncAPRepPartCom ::= SEQUENCE { EncAPRepPartExt ::= [APPLICATION 31] SEQUENCE {
ctime [0] KerberosTime, ctime [0] KerberosTime,
cusec [1] Microseconds, cusec [1] Microseconds,
subkey [2] EncryptionKey OPTIONAL, subkey [2] EncryptionKey OPTIONAL,
seq-number [3] SeqNum OPTIONAL, seq-number [3] SeqNum OPTIONAL,
..., ...,
authorization-data [4] AuthorizationData OPTIONAL, authorization-data [4] AuthorizationData OPTIONAL,
... ...
} }
-- --
-- *** Application messages -- *** Application messages
-- --
KRB-SAFE ::= CHOICE {
rfc1510 KRB-SAFE-1510,
ext KRB-SAFE-EXT
}
-- Do we chew up another tag for KRB-SAFE-EXT? That would KRB-SAFE-1510 ::= [APPLICATION 20] SEQUENCE {
-- allow us to make safe-body optional, allowing for a GSS-MIC
-- sort of message.
KRB-SAFE ::= [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 }}
}
-- Has safe-body optional to allow for GSS-MIC type functionality
KRB-SAFE-EXT ::= [APPLICATION 34] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (20),
safe-body [2] KRB-SAFE-BODY OPTIONAL,
cksum [3] ChecksumOf {
KRB-SAFE-BODY,
{ key-session | key-subsession }, { ku-KrbSafe-cksum }}, { key-session | key-subsession }, { ku-KrbSafe-cksum }},
... -- ASN.1 extensions must be excluded ...
-- when sending to rfc1510 implementations
} }
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
} }
skipping to change at page 96, line 36 skipping to change at page 97, line 16
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
} }
KRB-CRED ::= CHOICE { KRB-CRED ::= CHOICE {
rfc1510 [APPLICATION 22] KRB-CRED-1510, rfc1510 KRB-CRED-1510,
ext [APPLICATION 24] Signed { ext KRB-CRED-EXT
KRB-CRED-EXT,
{ key-session | key-subsession }, { ku-KrbCred-cksum }}
} }
KRB-CRED-COMMON ::= SEQUENCE {
KRB-CRED-1510 ::= [APPLICATION 22] SEQUENCE {
pvno [0] INTEGER (5), pvno [0] INTEGER (5),
msg-type [1] INTEGER (22 | 24), msg-type [1] INTEGER (22),
tickets [2] SEQUENCE OF Ticket,
enc-part [3] EncryptedData {
EncKrbCredPart,
{ key-session | key-subsession }, { ku-EncKrbCredPart }}
}
KRB-CRED-EXT ::= [APPLICATION 24] Signed {
[APPLICATION 24] SEQUENCE {
pvno [0] INTEGER (5),
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 }
} }
KRB-CRED-1510 ::= SEQUENCE {
COMPONENTS OF KRB-CRED-COMMON
} (WITH COMPONENTS { ..., msg-type (22) })
KRB-CRED-EXT ::= [APPLICATION 24] KRB-CRED-COMMON
(WITH COMPONENTS { ..., msg-type (24) })
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 {
key [0] EncryptionKey, key [0] EncryptionKey,
prealm [1] Realm OPTIONAL, prealm [1] Realm OPTIONAL,
pname [2] PrincipalName OPTIONAL, pname [2] PrincipalName OPTIONAL,
flags [3] TicketFlags OPTIONAL, flags [3] TicketFlags OPTIONAL,
authtime [4] KerberosTime OPTIONAL, authtime [4] KerberosTime OPTIONAL,
starttime [5] KerberosTime OPTIONAL, starttime [5] KerberosTime OPTIONAL,
endtime [6] KerberosTime OPTIONAL, endtime [6] KerberosTime OPTIONAL,
renew-till [7] KerberosTime OPTIONAL, renew-till [7] KerberosTime OPTIONAL,
srealm [8] Realm OPTIONAL, srealm [8] Realm OPTIONAL,
skipping to change at page 98, line 19 skipping to change at page 98, line 33
... ...
} }
-- --
-- *** Error messages -- *** Error messages
-- --
ErrCode ::= Int32 ErrCode ::= Int32
KRB-ERROR ::= CHOICE { KRB-ERROR ::= CHOICE {
rfc1510 [APPLICATION 30] KRB-ERROR-1510, rfc1510 KRB-ERROR-1510,
ext [APPLICATION 23] Signed { ext KRB-ERROR-EXT
KRB-ERROR-EXT, { ku-KrbError-cksum } } }
KRB-ERROR-1510 ::= [APPLICATION 30] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (30),
ctime [2] KerberosTime OPTIONAL,
cusec [3] Microseconds OPTIONAL,
stime [4] KerberosTime,
susec [5] Microseconds,
error-code [6] ErrCode,
crealm [7] RealmIA5 OPTIONAL,
cname [8] PrincipalNameIA5 OPTIONAL,
realm [9] RealmIA5 -- Correct realm --,
sname [10] PrincipalNameIA5 -- Correct name --,
e-text [11] KerberosString OPTIONAL,
e-data [12] OCTET STRING OPTIONAL
} }
KRB-ERROR-COMMON ::= SEQUENCE { KRB-ERROR-EXT ::= [APPLICATION 23] Signed {
[APPLICATION 23] SEQUENCE{
pvno [0] INTEGER (5), pvno [0] INTEGER (5),
msg-type [1] INTEGER (30 | 23), msg-type [1] INTEGER (23),
ctime [2] KerberosTime OPTIONAL, ctime [2] KerberosTime OPTIONAL,
cusec [3] Microseconds OPTIONAL, cusec [3] Microseconds OPTIONAL,
stime [4] KerberosTime, stime [4] KerberosTime,
susec [5] Microseconds, susec [5] Microseconds,
error-code [6] ErrCode, error-code [6] ErrCode,
crealm [7] Realm OPTIONAL, crealm [7] Realm OPTIONAL,
cname [8] PrincipalName OPTIONAL, cname [8] PrincipalName OPTIONAL,
realm [9] Realm -- Correct realm --, realm [9] Realm -- Correct realm --,
sname [10] PrincipalName -- Correct name --, sname [10] PrincipalName -- Correct name --,
e-text [11] KerberosString OPTIONAL, e-text [11] KerberosString OPTIONAL,
e-data [12] OCTET STRING OPTIONAL, e-data [12] OCTET STRING OPTIONAL,
..., ...,
typed-data [13] TYPED-DATA OPTIONAL, typed-data [13] TYPED-DATA OPTIONAL,
nonce [14] Nonce OPTIONAL, nonce [14] Nonce OPTIONAL,
lang-tag [15] LangTag OPTIONAL, lang-tag [15] LangTag OPTIONAL,
... ...
}, { }, { ku-KrbError-cksum }
} }
KRB-ERROR-1510 ::= SEQUENCE {
COMPONENTS OF KRB-ERROR-COMMON
} (WITH COMPONENTS {
...,
msg-type (30)
})
KRB-ERROR-EXT ::= [APPLICATION 23] KRB-ERROR-COMMON
(WITH COMPONENTS { ..., msg-type (23) })
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
-- --
-- *** 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 107, line 19 skipping to change at page 107, line 19
Distribution Protocols," Communications of the ACM, Vol. 24(8), Distribution Protocols," Communications of the ACM, Vol. 24(8),
pp. 533-536 (August 1981). pp. 533-536 (August 1981).
[Dub00] [Dub00]
Olivier Dubuisson, "ASN.1 - Communication between Heterogeneous Olivier Dubuisson, "ASN.1 - Communication between Heterogeneous
Systems", Elsevier-Morgan Kaufmann, 2000. Systems", Elsevier-Morgan Kaufmann, 2000.
<http://www.oss.com/asn1/dubuisson.html> <http://www.oss.com/asn1/dubuisson.html>
[ISO8859-1] [ISO8859-1]
"Information technology -- 8-bit single-byte coded graphic "Information technology -- 8-bit single-byte coded graphic
character sets -- Part 1: Latin alphabet No. 1", ISO/IEC 8859- character sets -- Part 1: Latin alphabet No. 1", ISO/IEC
1:1998. 8859-1:1998.
[KCLAR] [KCLAR]
Clifford Neuman, Tom Yu, Sam Hartman, Ken Raeburn, "The Kerberos Clifford Neuman, Tom Yu, Sam Hartman, Ken Raeburn, "The Kerberos
Network Authentication Service (V5)", draft-ietf-krb-wg- Network Authentication Service (V5)", draft-ietf-krb-wg-
kerberos-clarifications-07.txt, work in progress. kerberos-clarifications-07.txt, work in progress.
[KNT94] [KNT94]
John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The
Evolution of the Kerberos Authentication System". In Evolution of the Kerberos Authentication System". In
Distributed Open Systems, pages 78-94. IEEE Computer Society Distributed Open Systems, pages 78-94. IEEE Computer Society
 End of changes. 214 change blocks. 
846 lines changed or deleted 891 lines changed or added

This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/