diff options
| author | Stefan Metzmacher <metze@samba.org> | 2021-12-24 01:52:32 +0100 |
|---|---|---|
| committer | Joseph Sutton <jsutton@samba.org> | 2022-01-19 20:50:35 +0000 |
| commit | 40b65c840e03bd5eb7f3b02fe80144650c63c005 (patch) | |
| tree | d11b9bf5bcf1c71c0696d2153489447d47d03a0e /source4/heimdal/doc/standardisation/draft-ietf-krb-wg-rfc1510ter-01.txt | |
| parent | d2a3016a9c59f93f89cf4bb86d40938d56400453 (diff) | |
| download | samba-40b65c840e03bd5eb7f3b02fe80144650c63c005.tar.gz | |
s4:heimdal: import lorikeet-heimdal-202201172009 (commit 5a0b45cd723628b3690ea848548b05771c40f14e)
See
https://git.samba.org/?p=lorikeet-heimdal.git;a=shortlog;h=refs/heads/lorikeet-heimdal-202201172009
or
https://gitlab.com/samba-team/devel/lorikeet-heimdal/-/tree/lorikeet-heimdal-202201172009
NOTE: THIS COMMIT WON'T COMPILE/WORK ON ITS OWN!
Pair-Programmed-With: Joseph Sutton <josephsutton@catalyst.net.nz>
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Diffstat (limited to 'source4/heimdal/doc/standardisation/draft-ietf-krb-wg-rfc1510ter-01.txt')
| -rw-r--r-- | source4/heimdal/doc/standardisation/draft-ietf-krb-wg-rfc1510ter-01.txt | 6049 |
1 files changed, 6049 insertions, 0 deletions
diff --git a/source4/heimdal/doc/standardisation/draft-ietf-krb-wg-rfc1510ter-01.txt b/source4/heimdal/doc/standardisation/draft-ietf-krb-wg-rfc1510ter-01.txt new file mode 100644 index 00000000000..5728927e468 --- /dev/null +++ b/source4/heimdal/doc/standardisation/draft-ietf-krb-wg-rfc1510ter-01.txt @@ -0,0 +1,6049 @@ + + +INTERNET-DRAFT Tom Yu +draft-ietf-krb-wg-rfc1510ter-01.txt MIT +Expires: 19 March 2005 15 September 2005 + + The Kerberos Network Authentication Service (Version 5) + +Status of This Memo + + By submitting this Internet-Draft, each author represents that any + 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 + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + + http://www.ietf.org/shadow.html + + +Copyright Notice + + Copyright (C) The Internet Society (2005). All Rights Reserved. + +Abstract + + This document describes version 5 of the Kerberos network + authentication protocol. It describes a framework to allow for + extensions to be made to the protocol without creating + interoperability problems. + +Key Words for Requirements + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are + to be interpreted as described in RFC 2119. + + + + +Yu Expires: Mar 2005 [Page 1] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + +Table of Contents + + Status of This Memo .............................................. 1 + Copyright Notice ................................................. 1 + Abstract ......................................................... 1 + Key Words for Requirements ....................................... 1 + Table of Contents ................................................ 2 + 1. Introduction ................................................. 5 + 1.1. Kerberos Protocol Overview ................................. 5 + 1.2. Document Organization ...................................... 6 + 2. Compatibility Considerations ................................. 6 + 2.1. Extensibility .............................................. 7 + 2.2. Compatibility with RFC 1510 ................................ 7 + 2.3. Backwards Compatibility .................................... 7 + 2.4. 1.4.2. Sending Extensible Messages ......................... 8 + 2.5. Criticality ................................................ 8 + 2.6. Authenticating Cleartext Portions of Messages .............. 9 + 2.7. Capability Negotiation ..................................... 10 + 3. Use of ASN.1 in Kerberos ..................................... 10 + 3.1. Module Header .............................................. 11 + 3.2. Top-Level Type ............................................. 11 + 3.3. Previously Unused ASN.1 Notation (informative) ............. 12 + 3.3.1. Parameterized Types ...................................... 12 + 3.3.2. COMPONENTS OF Notation ................................... 12 + 3.3.3. Constraints .............................................. 12 + 3.4. New Types .................................................. 13 + 4. Basic Types .................................................. 14 + 4.1. Constrained Integer Types .................................. 14 + 4.2. KerberosTime ............................................... 15 + 4.3. KerberosString ............................................. 15 + 4.4. Language Tags .............................................. 16 + 4.5. KerberosFlags .............................................. 16 + 4.6. Typed Holes ................................................ 16 + 4.7. HostAddress and HostAddresses .............................. 17 + 4.7.1. Internet (IPv4) Addresses ................................ 17 + 4.7.2. Internet (IPv6) Addresses ................................ 17 + 4.7.3. DECnet Phase IV addresses ................................ 18 + 4.7.4. Netbios addresses ........................................ 18 + 4.7.5. Directional Addresses .................................... 18 + 5. Principals ................................................... 19 + 5.1. Name Types ................................................. 19 + 5.2. Principal Type Definition .................................. 19 + 5.3. Principal Name Reuse ....................................... 20 + 5.4. Realm Names ................................................ 20 + 5.5. Printable Representations of Principal Names ............... 21 + 5.6. Ticket-Granting Service Principal .......................... 21 + 5.6.1. Cross-Realm TGS Principals ............................... 21 + 6. Types Relating to Encryption ................................. 21 + 6.1. Assigned Numbers for Encryption ............................ 22 + 6.1.1. EType .................................................... 22 + 6.1.2. Key Usages ............................................... 22 + +Yu Expires: Mar 2005 [Page 2] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + 6.2. Which Key to Use ........................................... 23 + 6.3. EncryptionKey .............................................. 24 + 6.4. EncryptedData .............................................. 24 + 6.5. Checksums .................................................. 25 + 6.5.1. ChecksumOf ............................................... 26 + 6.5.2. Signed ................................................... 27 + 7. Tickets ...................................................... 27 + 7.1. Timestamps ................................................. 28 + 7.2. Ticket Flags ............................................... 28 + 7.2.1. Flags Relating to Initial Ticket Acquisition ............. 29 + 7.2.2. Invalid Tickets .......................................... 29 + 7.2.3. OK as Delegate ........................................... 30 + 7.2.4. Renewable Tickets ........................................ 30 + 7.2.5. Postdated Tickets ........................................ 31 + 7.2.6. Proxiable and Proxy Tickets .............................. 32 + 7.2.7. Forwarded and Forwardable Tickets ........................ 33 + 7.3. Transited Realms ........................................... 34 + 7.4. Authorization Data ......................................... 34 + 7.4.1. AD-IF-RELEVANT ........................................... 35 + 7.4.2. AD-KDCIssued ............................................. 35 + 7.4.3. AD-AND-OR ................................................ 37 + 7.4.4. AD-MANDATORY-FOR-KDC ..................................... 37 + 7.5. Encrypted Part of Ticket ................................... 37 + 7.6. Cleartext Part of Ticket ................................... 38 + 8. Credential Acquisition ....................................... 40 + 8.1. KDC-REQ .................................................... 40 + 8.2. PA-DATA .................................................... 46 + 8.3. KDC-REQ Processing ......................................... 46 + 8.3.1. Handling Replays ......................................... 46 + 8.3.2. Request Validation ....................................... 47 + 8.3.2.1. AS-REQ Authentication .................................. 47 + 8.3.2.2. TGS-REQ Authentication ................................. 47 + 8.3.2.3. Principal Validation ................................... 47 + 8.3.2.4. Checking For Revoked or Invalid Tickets ................ 48 + 8.3.3. Timestamp Handling ....................................... 48 + 8.3.3.1. AS-REQ Timestamp Processing ............................ 49 + 8.3.3.2. TGS-REQ Timestamp Processing ........................... 49 + 8.3.4. Handling Transited Realms ................................ 50 + 8.3.5. Address Processing ....................................... 50 + 8.3.6. Ticket Flag Processing ................................... 51 + 8.3.7. Key Selection ............................................ 52 + 8.3.7.1. Reply Key and Session Key Selection .................... 52 + 8.3.7.2. Ticket Key Selection ................................... 52 + 8.4. KDC-REP .................................................... 52 + 8.5. Reply Validation ........................................... 55 + 8.6. IP Transports .............................................. 55 + 8.6.1. UDP/IP transport ......................................... 55 + 8.6.2. TCP/IP transport ......................................... 56 + 8.6.3. KDC Discovery on IP Networks ............................. 57 + 8.6.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names ..... 57 + 8.6.3.2. DNS SRV records for KDC location ....................... 58 + +Yu Expires: Mar 2005 [Page 3] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + 8.6.3.3. KDC Discovery for Domain Style Realm Names on IP + Networks ............................................ 58 + 9. Errors ....................................................... 58 + 10. Session Key Exchange ........................................ 61 + 10.1. AP-REQ .................................................... 61 + 10.2. AP-REP .................................................... 63 + 11. Session Key Use ............................................. 65 + 11.1. KRB-SAFE .................................................. 65 + 11.2. KRB-PRIV .................................................. 65 + 11.3. KRB-CRED .................................................. 66 + 12. Security Considerations ..................................... 67 + 12.1. Time Synchronization ...................................... 67 + 12.2. Replays ................................................... 67 + 12.3. Principal Name Reuse ...................................... 67 + 12.4. Password Guessing ......................................... 67 + 12.5. Forward Secrecy ........................................... 67 + 12.6. Authorization ............................................. 68 + 12.7. Login Authentication ...................................... 68 + 13. IANA Considerations ......................................... 68 + 14. Acknowledgments ............................................. 69 + Appendices ....................................................... 69 + A. ASN.1 Module (Normative) ..................................... 69 + B. Kerberos and Character Encodings (Informative) ...............103 + C. Kerberos History (Informative) ...............................104 + D. Notational Differences from [KCLAR] ..........................105 + Normative References .............................................106 + Informative References ...........................................106 + Author's Address .................................................108 + Copyright Statement ..............................................108 + Intellectual Property Statement ..................................108 + + + + + + + + + + + + + + + + + + + + + + +Yu Expires: Mar 2005 [Page 4] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + +1. Introduction + + The Kerberos network authentication protocol is a trusted-third-party + protocol utilizing symmetric-key cryptography. It assumes that all + communications between parties in the protocol may be arbitrarily + tampered with or monitored, and that the security of the overall + system depends only on the effectiveness of the cryptographic + techniques and the secrecy of the cryptographic keys used. The + Kerberos protocol authenticates an application client's identity to + an application server, and likewise authenticates the application + server's identity to the application client. These assurances are + made possible by the client and the server sharing secrets with the + trusted third party: the Kerberos server, also known as the Key + Distribution Center (KDC). In addition, the protocol establishes an + ephemeral shared secret (the session key) between the client and the + server, allowing the protection of further communications between + them. + + The Kerberos protocol, as originally specified, provides insufficient + means for extending the protocol in a backwards-compatible way. This + deficiency has caused problems for interoperability. This document + describes a framework which enables backwards-compatible extensions + to the Kerberos protocol. + +1.1. Kerberos Protocol Overview + + Kerberos comprises three main sub-protocols: credentials acquisition, + session key exchange, and session key usage. A client acquires + credentials by asking the KDC for a credential for a service; the KDC + issues the credential, which contains a ticket and a session key. + The ticket, containing the client's identity, timestamps, expiration + time, and a session key, is a encrypted in a key known to the + application server. The KDC encrypts the credential using a key + known to the client, and transmits the credential to the client. + + There are two means of requesting credentials: the Authentication + Service (AS) exchange, and the Ticket-Granting Service (TGS) + exchange. In the typical AS exchange, a client uses a password- + derived key to decrypt the response. In the TGS exchange, the KDC + behaves as an application server; the client authenticates to the TGS + by using a Ticket-Granting Ticket (TGT). The client usually obtains + the TGT by using the AS exchange. + + Session key exchange consists of the client transmitting the ticket + to the application server, accompanied by an authenticator. The + authenticator contains a timestamp and additional data encrypted + using the ticket's session key. The application server decrypts the + ticket, extracting the session key. The application server then uses + the session key to decrypt the authenticator. Upon successful + decryption of the authenticator, the application server knows that + the data in the authenticator were sent by the client named in the + +Yu Expires: Mar 2005 [Page 5] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + associated ticket. Additionally, since authenticators expire more + quickly than tickets, the application server has some assurance that + the transaction is not a replay. The application server may send an + encrypted acknowledgment to the client, verifying its identity to the + client. + + Once session key exchange has occurred, the client and server may use + the established session key to protect further traffic. This + protection may consist of protection of integrity only, or of + protection of confidentiality and integrity. Additional measures + exist for a client to securely forward credentials to a server. + + The entire scheme depends on loosely synchronized clocks. + Synchronization of the clock on the KDC with the application server + clock allows the application server to accurately determine whether a + credential is expired. Likewise, synchronization of the clock on the + client with the application server clock prevents replay attacks + utilizing the same credential. Careful design of the application + protocol may allow replay prevention without requiring client-server + clock synchronization. + + After establishing a session key, application client and the + application server can exchange Kerberos protocol messages that use + the session key to protect the integrity or confidentiality of + communications between the client and the server. Additionally, the + client may forward credentials to the application server. + + The credentials acquisition protocol takes place over specific, + defined transports (UDP and TCP). Application protocols define which + transport to use for the session key establishment protocol and for + messages using the session key; the application may choose to perform + its own encapsulation of the Kerberos messages, for example. + +1.2. Document Organization + + The remainder of this document begins by describing the general + frameworks for protocol extensibility, including whether to interpret + unknown extensions as critical. It then defines the protocol + messages and exchanges. + + The definition of the Kerberos protocol uses Abstract Syntax Notation + One (ASN.1) [X680], which specifies notation for describing the + abstract content of protocol messages. This document defines a + number of base types using ASN.1; these base types subsequently + appear in multiple types which define actual protocol messages. + Definitions of principal names and of tickets, which are central to + the protocol, also appear preceding the protocol message definitions. + + + + + +Yu Expires: Mar 2005 [Page 6] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + +2. Compatibility Considerations + +2.1. Extensibility + + In the past, significant interoperability problems have resulted from + conflicting assumptions about how the Kerberos protocol can be + extended. As the deployed base of Kerberos grows, the ability to + extend the Kerberos protocol becomes more important. In order to + ensure that vendors and the IETF can extend the protocol while + maintaining backwards compatibility, this document outlines a + framework for extending Kerberos. + + Kerberos provides two general mechanisms for protocol extensibility. + Many protocol messages, including some defined in RFC 1510, contain + typed holes--sub-messages containing an octet string along with an + integer that identifies how to interpret the octet string. The + integer identifiers are registered centrally, but can be used both + for vendor extensions and for extensions standardized in the IETF. + This document adds typed holes to a number of messages which + previously lacked typed holes. + + Many new messages defined in this document also contain ASN.1 + extension markers. These markers allow future revisions of this + document to add additional elements to messages, for cases where + typed holes are inadequate for some reason. Because tag numbers and + position in a sequence need to be coordinated in order to maintain + interoperability, implementations MUST NOT include ASN.1 extensions + except when those extensions are specified by IETF standards-track + documents. + +2.2. Compatibility with RFC 1510 + + Implementations of RFC 1510 did not use extensible ASN.1 types. + Sending additional fields not in RFC 1510 to these implementations + results in undefined behavior. Examples of this behavior are known + to include discarding messages with no error indications. + + Where messages have been changed since RFC 1510, ASN.1 CHOICE types + are used; one alternative of the CHOICE provides a message which is + wire-encoding compatible with RFC 1510, and the other alternative + provides the new, extensible message. + + Implementations sending new messages MUST ensure that the recipient + supports these new messages. Along with each extensible message is a + guideline for when that message MAY be used. IF that guideline is + followed, then the recipient is guaranteed to understand the message. + +2.3. Backwards Compatibility + + 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 + +Yu Expires: Mar 2005 [Page 7] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + [KCLAR]. The second set of types is the set of types enabling + extensibility. This second set may be referred to as + "extensibility-enabled types". [ need to make this consistent + throughout? ] + + A major difference between the new extensibility-enabled types and + the types for RFC 1510 compatibility is that the extensibility- + enabled types allow for the use of UTF-8 encodings in various + character strings in the protocol. Each party in the protocol must + have some knowledge of the capabilities of the other parties in the + protocol. There are methods for establishing this knowledge without + necessarily requiring explicit configuration. + + An extensibility-enabled client can detect whether a KDC supports the + extensibility-enabled types by requesting an extensibility-enabled + reply. If the KDC replies with an extensibility-enabled reply, the + client knows that the KDC supports extensibility. If the KDC issues + an extensibility-enabled ticket, the client knows that the service + named in the ticket is extensibility-enabled. + +2.4. 1.4.2. Sending Extensible Messages + + Care must be taken to make sure that old implementations can + understand messages sent to them even if they do not understand an + extension that is used. Unless the sender knows the extension is + supported, the extension cannot change the semantics of the core + message or previously defined extensions. + + For example, an extension including key information necessary to + decrypt the encrypted part of a KDC-REP could only be used in + situations where the recipient was known to support the extension. + Thus when designing such extensions it is important to provide a way + for the recipient to notify the sender of support for the extension. + For example in the case of an extension that changes the KDC-REP + reply key, the client could indicate support for the extension by + including a padata element in the AS-REQ sequence. The KDC should + only use the extension if this padata element is present in the AS- + REQ. Even if policy requires the use of the extension, it is better + to return an error indicating that the extension is required than to + use the extension when the recipient may not support it; debugging + why implementations do not interoperate is easier when errors are + returned. + +2.5. Criticality + + Recipients of unknown message extensions (including typed holes, new + flags, and ASN.1 extension elements) should preserve the encoding of + the extension but otherwise ignore the presence of the extension; + i.e., unknown extensions SHOULD be treated as non-critical. If a + copy of the message is used later--for example, when a Ticket + received in a KDC-REP is later used in an AP-REQ--then the unknown + +Yu Expires: Mar 2005 [Page 8] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + extensions MUST be included. + + An implementation SHOULD NOT reject a request merely because it does + not understand some element of the request. As a related + consequence, implementations SHOULD handle communicating with other + implementations which do not implement some requested options. This + may require designers of options to provide means to determine + whether an option has been rejected, not understood, or (perhaps + maliciously) deleted or modified in transit. + + There is one exception to non-criticality described above: if an + unknown authorization data element is received by a server either in + an AP-REQ or in a Ticket contained in an AP-REQ, then the + authentication SHOULD fail. Authorization data is intended to + restrict the use of a ticket. If the service cannot determine + whether the restriction applies to that service then a security + weakness may result if authentication succeeds. Authorization + elements meant to be truly optional can be enclosed in the AD-IF- + RELEVANT element. + + Many RFC 1510 implementations ignore unknown authorization data + elements. Depending on these implementations to honor authorization + data restrictions may create a security weakness. + +2.6. Authenticating Cleartext Portions of Messages + + Various denial of service attacks and downgrade attacks against + Kerberos are possible unless plaintexts are somehow protected against + modification. An early design goal of Kerberos Version 5 was to + avoid encrypting more of the authentication exchange that was + required. (Version 4 doubly-encrypted the encrypted part of a ticket + in a KDC reply, for example.) This minimization of encryption + reduces the load on the KDC and busy servers. Also, during the + initial design of Version 5, the existence of legal restrictions on + the export of cryptography made it desirable to minimize of the + number of uses of encryption in the protocol. Unfortunately, + performing this minimization created numerous instances of + unauthenticated security-relevant plaintext fields. + + The extensible variants of the messages described in this document + wrap the actual message in an ASN.1 sequence containing a keyed + checksum of the contents of the message. Guidelines in [XXX] section + 3 specify when the checksum MUST be included and what key MUST be + used. Guidelines on when to include a checksum are never ambiguous: + a particular PDU is never correct both with and without a checksum. + With the exception of the KRB-ERROR message, receiving + implementations MUST reject messages where a checksum is included and + not expected or where a checksum is expected but not included. The + receiving implementation does not always have sufficient information + to know whether a KRB-ERROR should contain a checksum. Even so, + KRB-ERROR messages with invalid checksums MUST be rejected and + +Yu Expires: Mar 2005 [Page 9] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + implementations MAY consider the presence or absence of a checksum + when evaluating whether to trust the error. + + This authenticated cleartext protection is provided only in the + extensible variants of the messages; it is never used when + communicating with an RFC 1510 implementation. + +2.7. Capability Negotiation + + Kerberos is a three-party protocol. Each of the three parties + involved needs a means of detecting the capabilities supported by the + others. Two of the parties, the KDC and the application server, do + not communicate directly in the Kerberos protocol. Communicating + capabilities from the KDC to the application server requires using a + ticket as an intermediary. + + The main capability requiring negotiation is the support of the + extensibility framework described in this document. Negotiation of + this capability while remaining compatible with RFC 1510 + implementations is possible. The main complication is that the + client needs to know whether the application server supports the + extensibility framework prior to sending any message to the + application server. This can be accomplished if the KDC has + knowledge of whether an application server supports the extensibility + framework. + + Client software advertizes its capabilities when requesting + credentials from the KDC. If the KDC recognizes the capabilities, it + acknowledges this fact to the client in its reply. In addition, if + the KDC has knowledge that the application server supports certain + capabilities, it also communicates this knowledge to the client in + its reply. The KDC can encode its own capabilities in the ticket so + that the application server may discover these capabilities. The + client advertizes its capabilities to the application server when it + initiates authentication to the application server. + +3. Use of ASN.1 in Kerberos + + Kerberos uses the ASN.1 Distinguished Encoding Rules (DER) [X690]. + Even though ASN.1 theoretically allows the description of protocol + messages to be independent of the encoding rules used to encode the + messages, Kerberos messages MUST be encoded with DER. Subtleties in + the semantics of the notation, such as whether tags carry any + semantic content to the application, may cause the use of other ASN.1 + encoding rules to be problematic. + + Implementors not using existing ASN.1 tools (e.g., compilers or + support libraries) are cautioned to thoroughly read and understand + the actual ASN.1 specification to ensure correct implementation + behavior. There is more complexity in the notation than is + immediately obvious, and some tutorials and guides to ASN.1 are + +Yu Expires: Mar 2005 [Page 10] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + misleading or erroneous. Recommended tutorials and guides include + [Dub00], [Lar99], though there is still no substitute for reading the + actual ASN.1 specification. + +3.1. Module Header + + The type definitions in this document assume an ASN.1 module + definition of the following form: + + KerberosV5Spec3 { + iso(1) identified-organization(3) dod(6) internet(1) + security(5) kerberosV5(2) modules(4) krb5spec3(4) + } DEFINITIONS EXPLICIT TAGS ::= BEGIN + + -- Rest of definitions here + + END + + This specifies that the tagging context for the module will be + explicit and that automatic tagging is not done. + + Some other publications [RFC1510] [RFC1964] erroneously specify an + object identifier (OID) having an incorrect value of "5" for the + "dod" component of the OID. In the case of RFC 1964, use of the + "correct" OID value would result in a change in the wire protocol; + therefore, the RFC 1964 OID remains unchanged for now. + +3.2. Top-Level Type + + The ASN.1 type "KRB-PDU" is a CHOICE over all the types (Protocol + Data Units or PDUs) which an application may directly reference. + Applications SHOULD NOT transmit any types other than those which are + alternatives of the KRB-PDU CHOICE. + + + + + + + + + + + + + + + + + + + +Yu Expires: Mar 2005 [Page 11] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + -- top-level type + -- + -- Applications should not directly reference any types + -- other than KRB-PDU and its component types. + -- + KRB-PDU ::= CHOICE { + ticket Ticket, + as-req AS-REQ, + as-rep AS-REP, + tgs-req TGS-REQ, + tgs-rep TGS-REP, + ap-req AP-REQ, + ap-rep AP-REP, + krb-safe KRB-SAFE, + krb-priv KRB-PRIV, + krb-cred KRB-CRED, + tgt-req TGT-REQ, + krb-error KRB-ERROR, + ... + } + + +3.3. Previously Unused ASN.1 Notation (informative) + + Some aspects of ASN.1 notation used in this document were not used in + [KCLAR], and may be unfamiliar to some readers. This subsection is + informative; for normative definitions of the notation, see the + actual ASN.1 specifications [X680], [X682], [X683]. + +3.3.1. Parameterized Types + + This document uses ASN.1 parameterized types [X683] to make + 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 + for transmission in a protocol message. These advisory parameters + can describe implementation behavior associated with the type. + +3.3.2. COMPONENTS OF Notation + + 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 + "UserDefinedConstraint" notation [X682]. Some constraints can be + handled automatically by tools that can parse them. Uses of the + +Yu Expires: Mar 2005 [Page 12] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + "UserDefinedConstraint" notation (the "CONSTRAINED BY" notation) will + typically need to have behavior manually coded; the notation provides + a formalized way of conveying intended implementation behavior. + + The "WITH COMPONENTS" constraint notation allows constraints to apply + to component types of a SEQUENCE type. This constraint notation + effectively allows constraints to "reach into" a type to constrain + its component types. + +3.4. New Types + + 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 + "Ext", indicating that the types are intended to support + extensibility. Types original to RFC 1510 and [KCLAR] have been + renamed to have a suffix like "1510". The "Ext" and "1510" types + often contain a number of common elements; these common elements have + a suffix like "Common". The "1510" types have various ASN.1 + 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. + + +Yu Expires: Mar 2005 [Page 13] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + -- example type equivalent to Foo-1510 + Foo-1510-Equiv ::= SEQUENCE { + a [0] INTEGER, + b [1] OCTET STRING + } + + +4. Basic Types + + These "basic" Kerberos ASN.1 types appear in multiple other Kerberos + types. + +4.1. Constrained Integer Types + + In RFC 1510, many types contained references to the unconstrained + INTEGER type. Since an unconstrained INTEGER can contain almost any + possible abstract integer value, most of the unconstrained references + to INTEGER in RFC 1510 were constrained to 32 bits or smaller in + [KCLAR]. + + -- signed values representable in 32 bits + -- + -- These are often used as assigned numbers for various things. + Int32 ::= INTEGER (-2147483648..2147483647) + + The "Int32" type often contains an assigned number identifying the + contents of a typed hole. Unless otherwise stated, non-negative + values are registered, and negative values are available for local + use. + + -- unsigned 32 bit values + UInt32 ::= INTEGER (0..4294967295) + + The "UInt32" type is used in some places where an unsigned 32-bit + integer is needed. + + -- unsigned 64 bit values + UInt64 ::= INTEGER (0..18446744073709551615) + + The "UInt64" type is used in places where 32 bits of precision may + provide inadequate security. + + -- sequence numbers + SeqNum ::= UInt64 + + Sequence numbers were constrained to 32 bits in [KCLAR], but this + document allows for 64-bit sequence numbers. + + -- nonces + Nonce ::= UInt64 + + +Yu Expires: Mar 2005 [Page 14] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + Likewise, nonces were constrained to 32 bits in [KCLAR], but expanded + to 64 bits here. + + -- microseconds + Microseconds ::= INTEGER (0..999999) + + The "microseconds" type is intended to carry the microseconds part of + a time value. + +4.2. KerberosTime + + KerberosTime ::= GeneralizedTime (CONSTRAINED BY { + -- MUST NOT include fractional seconds + }) + + The timestamps used in Kerberos are encoded as GeneralizedTimes. A + KerberosTime value MUST NOT include any fractional portions of the + seconds. As required by the DER, it further MUST NOT include any + separators, and it specifies the UTC time zone (Z). Example: The + only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6 + November 1985 is "19851106210627Z". + +4.3. KerberosString + + -- used for names and for error messages + KerberosString ::= CHOICE { + ia5 GeneralString (IA5String), + utf8 UTF8String, + ... -- no extension may be sent + -- to an rfc1510 implementation -- + } + + The KerberosString type is used for character strings in various + places in the Kerberos protocol. For compatibility with RFC 1510, + GeneralString values constrained to IA5String (US-ASCII) are + permitted in messages exchanged with RFC 1510 implementations. The + new protocol messages contain strings encoded as UTF-8, and these + strings MUST be normalized using [SASLPREP]. KerberosString values + are present in principal names and in error messages. Control + characters SHOULD NOT be used in principal names, and used with + caution in error messages. + + -- IA5 choice only; useful for constraints + KerberosStringIA5 ::= KerberosString + (WITH COMPONENTS { ia5 PRESENT }) + + -- IA5 excluded; useful for constraints + KerberosStringExt ::= KerberosString + (WITH COMPONENTS { ia5 ABSENT }) + + KerberosStringIA5 requires the use of the "ia5" alternative, while + +Yu Expires: Mar 2005 [Page 15] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + KerberosStringExt forbids it. These types appear in ASN.1 + constraints on messages. + + For detailed background regarding the history of character string use + in Kerberos, as well as discussion of some compatibility issues, see + Appendix B. + +4.4. Language Tags + + -- used for language tags + LangTag ::= PrintableString + (FROM ("A".."Z" | "a".."z" | "0".."9" | "-")) + + The "LangTag" type is used to specify language tags for localization + purposes, using the [RFC3066] format. + +4.5. KerberosFlags + + For several message types, a specific constrained bit string type, + KerberosFlags, is used. + + KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX)) + (CONSTRAINED BY { + -- MUST be a valid value of -- NamedBits + -- but if the value to be sent would be truncated to shorter + -- than 32 bits according to DER, the value MUST be padded + -- with trailing zero bits to 32 bits. Otherwise, no + -- trailing zero bits may be present. + + }) + + + The actual bit string type encoded in Kerberos messages does not use + named bits. The advisory parameter of the KerberosFlags type names a + bit string type defined using named bits, whose value is encoded as + if it were a bit string with unnamed bits. This practice is + necessary because the DER require trailing zero bits to be removed + when encoding bit strings defined using named bits. Existing + implementations of Kerberos send exactly 32 bits rather than + truncating, so the size constraint requires the transmission of at + least 32 bits. Trailing zero bits beyond the first 32 bits are + truncated. + +4.6. Typed Holes + + -- Typed hole identifiers + TH-id ::= CHOICE { + int32 Int32, + rel-oid RELATIVE-OID + } + + +Yu Expires: Mar 2005 [Page 16] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + The "TH-id" type is a generalized means to identify the contents of a + typed hole. The "int32" alternative may be used for simple integer + assignments, in the same manner as "Int32", while the "rel-oid" + alternative may be used for hierarchical delegation. + +4.7. HostAddress and HostAddresses + + AddrType ::= Int32 + + HostAddress ::= SEQUENCE { + addr-type [0] AddrType, + address [1] OCTET STRING + } + + -- NOTE: HostAddresses is always used as an OPTIONAL field and + -- should not be a zero-length SEQUENCE OF. + -- + -- The extensible messages explicitly constrain this to be + -- non-empty. + HostAddresses ::= SEQUENCE OF HostAddress + + + addr-type + This field specifies the type of address that follows. + + address + This field encodes a single address of the type identified by + "addr-type". + + All negative values for the host address type are reserved for local + use. All non-negative values are reserved for officially assigned + type fields and interpretations. + + + addr-type | meaning + __________|______________ + 2 | IPv4 + 3 | directional + 12 | DECnet + 20 | NetBIOS + 24 | IPv6 + + + +4.7.1. Internet (IPv4) Addresses + + Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in + MSB order (most significant byte first). The IPv4 loopback address + SHOULD NOT appear in a Kerberos PDU. The type of IPv4 addresses is + two (2). + + +Yu Expires: Mar 2005 [Page 17] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + +4.7.2. Internet (IPv6) Addresses + + IPv6 addresses [RFC2373] are 128-bit (16-octet) quantities, encoded + in MSB order (most significant byte first). The type of IPv6 + addresses is twenty-four (24). The following addresses MUST NOT + appear in any Kerberos PDU: + + * the Unspecified Address + + * the Loopback Address + + * Link-Local addresses + + This restriction applies to the inclusion in the address fields of + Kerberos PDUs, but not to the address fields of packets that might + carry such PDUs. The restriction is necessary because the use of an + 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 + host intended by the entity that added the restriction. If the + link-local address type needs to be used for communication, then the + address restriction in tickets must not be used (i.e. addressless + tickets must be used). + + IPv4-mapped IPv6 addresses MUST be represented as addresses of type + 2. + +4.7.3. DECnet Phase IV addresses + + DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order. + The type of DECnet Phase IV addresses is twelve (12). + +4.7.4. Netbios addresses + + Netbios addresses are 16-octet addresses typically composed of 1 to + 15 alphanumeric characters and padded with the US-ASCII SPC character + (code 32). The 16th octet MUST be the US-ASCII NUL character (code + 0). The type of Netbios addresses is twenty (20). + +4.7.5. Directional Addresses + + In many environments, including the sender address in KRB-SAFE and + KRB-PRIV messages is undesirable because the addresses may be changed + in transport by network address translators. However, if these + addresses are removed, the messages may be subject to a reflection + attack in which a message is reflected back to its originator. The + directional address type provides a way to avoid transport addresses + and reflection attacks. Directional addresses are encoded as four + byte unsigned integers in network byte order. If the message is + originated by the party sending the original AP-REQ message, then an + address of 0 SHOULD be used. If the message is originated by the + party to whom that AP-REQ was sent, then the address 1 SHOULD be + +Yu Expires: Mar 2005 [Page 18] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + used. Applications involving multiple parties can specify the use of + other addresses. + + Directional addresses MUST only be used for the sender address field + in the KRB-SAFE or KRB-PRIV messages. They MUST NOT be used as a + ticket address or in a AP-REQ message. This address type SHOULD only + be used in situations where the sending party knows that the + receiving party supports the address type. This generally means that + directional addresses may only be used when the application protocol + requires their support. Directional addresses are type (3). + +5. Principals + + Principals are participants in the Kerberos protocol. A "realm" + consists of principals in one administrative domain, served by one + KDC (or one replicated set of KDCs). Each principal name has an + arbitrary number of components, though typical principal names will + only have one or two components. A principal name is meant to be + readable by and meaningful to humans, especially in a realm lacking a + centrally adminstered authorization infrastructure. + +5.1. Name Types + + Each PrincipalName has NameType indicating what sort of name it is. + The name-type SHOULD be treated as a hint. Ignoring the name type, + no two names can be the same (i.e., at least one of the components, + or the realm, must be different). + + -- assigned numbers for name types (used in principal names) + NameType ::= Int32 + + -- Name type not known + nt-unknown NameType ::= 0 + -- Just the name of the principal as in DCE, or for users + nt-principal NameType ::= 1 + -- Service and other unique instance (krbtgt) + nt-srv-inst NameType ::= 2 + -- Service with host name as instance (telnet, rcommands) + nt-srv-hst NameType ::= 3 + -- Service with host as remaining components + nt-srv-xhst NameType ::= 4 + -- Unique ID + nt-uid NameType ::= 5 + -- Encoded X.509 Distingished name [RFC 2253] + nt-x500-principal NameType ::= 6 + -- Name in form of SMTP email name (e.g. user@foo.com) + nt-smtp-name NameType ::= 7 + -- Enterprise name - may be mapped to principal name + nt-enterprise NameType ::= 10 + + + +Yu Expires: Mar 2005 [Page 19] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + +5.2. Principal Type Definition + + PrincipalName ::= SEQUENCE { + name-type [0] NameType, + -- May have zero elements, or individual elements may be + -- zero-length, but this is NOT RECOMMENDED. + name-string [1] SEQUENCE OF KerberosString + } + + + name-type + hint of the type of name that follows + + name-string + The "name-string" encodes a sequence of components that form a + name, each component encoded as a KerberosString. Taken + together, a PrincipalName and a Realm form a principal + identifier. Most PrincipalNames will have only a few components + (typically one or two). + +5.3. Principal Name Reuse + + Realm administrators SHOULD use extreme caution when considering + reusing a principal name. A service administrator might explicitly + enter principal names into a local access control list (ACL) for the + service. If such local ACLs exist independently of a centrally + administered authorization infrastructure, realm administrators + SHOULD NOT reuse principal names until confirming that all extant ACL + entries referencing that principal name have been updated. Failure + to perform this check can result in a security vulnerability, as a + new principal can inadvertently inherit unauthorized privileges upon + receiving a reused principal name. An organization whose Kerberos- + authenticated services all use a centrally-adminstered authorization + infrastructure may not need to take these precautions regarding + principal name reuse. + +5.4. Realm Names + + Realm ::= KerberosString + + -- IA5 only + RealmIA5 ::= Realm (KerberosStringIA5) + + -- IA5 excluded + RealmExt ::= Realm (KerberosStringExt) + + + Kerberos realm names are KerberosStrings. Realms MUST NOT contain a + character with the code 0 (the US-ASCII NUL). Most realms will + usually consist of several components separated by periods (.), in + the style of Internet Domain Names, or separated by slashes (/) in + +Yu Expires: Mar 2005 [Page 20] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + the style of X.500 names. + +5.5. Printable Representations of Principal Names + + [ perhaps non-normative? ] + + The printable form of a principal name consists of the concatenation + of components of the PrincipalName value using the slash character + (/), followed by an at-sign (@), followed by the realm name. Any + occurrence of a backslash (\), slash (/) or at-sign (@) in the + PrincipalName value is quoted by a backslash. + +5.6. Ticket-Granting Service Principal + + The PrincipalName value corresponding to a ticket-granting service + 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 + ticket-granting ticket having this service principal name. The realm + name of service always indicates which realm issued the ticket. A + ticket-granting ticket issued by "A.EXAMPLE.COM" which is valid for + obtaining tickets in the same realm would have the following ASN.1 + values for its "realm" and "sname" components, respectively: + + -- Example Realm and PrincipalName for a TGS + + tgtRealm1 Realm ::= ia5 : "A.EXAMPLE.COM" + + tgtPrinc1 PrincipalName ::= { + name-type nt-srv-inst, + name-string { ia5 : "krbtgt", ia5 : "A.EXAMPLE.COM" } + } + + Its printable representation would be written as + "krbtgt/A.EXAMPLE.COM@A.EXAMPLE.COM". + +5.6.1. Cross-Realm TGS Principals + + 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- + granting ticket to allow one of its principals to authenticate to a + service in a foreign realm. For example, the TGS principal + "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 + 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 + client's realm name remains "A.EXAMPLE.COM", even though the service + principal will have the realm "B.EXAMPLE.COM". + + + + + +Yu Expires: Mar 2005 [Page 21] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + +6. Types Relating to Encryption + + Many Kerberos protocol messages contain encrypted encodings of + various data types. Some Kerberos protocol messages also contain + checksums (signatures) of encodings of various types. + +6.1. Assigned Numbers for Encryption + + Encryption algorithm identifiers and key usages both have assigned + numbers, described in [KCRYPTO]. + +6.1.1. EType + + EType is the integer type for assigned numbers for encryption + algorithms. Defined in [KCRYPTO]. + + -- Assigned numbers denoting encryption mechanisms. + EType ::= Int32 + + -- assigned numbers for encryption schemes + et-des-cbc-crc EType ::= 1 + et-des-cbc-md4 EType ::= 2 + et-des-cbc-md5 EType ::= 3 + -- [reserved] 4 + et-des3-cbc-md5 EType ::= 5 + -- [reserved] 6 + et-des3-cbc-sha1 EType ::= 7 + et-dsaWithSHA1-CmsOID EType ::= 9 + et-md5WithRSAEncryption-CmsOID EType ::= 10 + et-sha1WithRSAEncryption-CmsOID EType ::= 11 + et-rc2CBC-EnvOID EType ::= 12 + et-rsaEncryption-EnvOID EType ::= 13 + et-rsaES-OAEP-ENV-OID EType ::= 14 + et-des-ede3-cbc-Env-OID EType ::= 15 + et-des3-cbc-sha1-kd EType ::= 16 + -- AES + et-aes128-cts-hmac-sha1-96 EType ::= 17 + -- AES + et-aes256-cts-hmac-sha1-96 EType ::= 18 + -- Microsoft + et-rc4-hmac EType ::= 23 + -- Microsoft + et-rc4-hmac-exp EType ::= 24 + -- opaque; PacketCable + et-subkey-keymaterial EType ::= 65 + + +6.1.2. Key Usages + + KeyUsage is the integer type for assigned numbers for key usages. + Key usage values are inputs to the encryption and decryption + +Yu Expires: Mar 2005 [Page 22] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + functions described in [KCRYPTO]. + + -- Assigned numbers denoting key usages. + KeyUsage ::= UInt32 + + -- + -- Actual identifier names are provisional and subject to + -- change. + -- + ku-pa-enc-ts KeyUsage ::= 1 + ku-Ticket KeyUsage ::= 2 + ku-EncASRepPart KeyUsage ::= 3 + ku-TGSReqAuthData-sesskey KeyUsage ::= 4 + ku-TGSReqAuthData-subkey KeyUsage ::= 5 + ku-pa-TGSReq-cksum KeyUsage ::= 6 + ku-pa-TGSReq-authenticator KeyUsage ::= 7 + ku-EncTGSRepPart-sesskey KeyUsage ::= 8 + ku-EncTGSRepPart-subkey KeyUsage ::= 9 + ku-Authenticator-cksum KeyUsage ::= 10 + ku-APReq-authenticator KeyUsage ::= 11 + ku-EncAPRepPart KeyUsage ::= 12 + ku-EncKrbPrivPart KeyUsage ::= 13 + ku-EncKrbCredPart KeyUsage ::= 14 + ku-KrbSafe-cksum KeyUsage ::= 15 + ku-ad-KDCIssued-cksum KeyUsage ::= 19 + + + -- The following numbers are provisional... + -- conflicts may exist elsewhere. + ku-Ticket-cksum KeyUsage ::= 25 + ku-ASReq-cksum KeyUsage ::= 26 + ku-TGSReq-cksum KeyUsage ::= 27 + ku-ASRep-cksum KeyUsage ::= 28 + ku-TGSRep-cksum KeyUsage ::= 29 + ku-APReq-cksum KeyUsage ::= 30 + ku-APRep-cksum KeyUsage ::= 31 + ku-KrbCred-cksum KeyUsage ::= 32 + ku-KrbError-cksum KeyUsage ::= 33 + ku-KDCRep-cksum KeyUsage ::= 34 + + +6.2. Which Key to Use + + + + + + + + + + +Yu Expires: Mar 2005 [Page 23] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + -- KeyToUse identifies which key is to be used to encrypt or + -- sign a given value. + -- + -- Values of KeyToUse are never actually transmitted over the + -- wire, or even used directly by the implementation in any + -- way, as key usages are; it exists primarily to identify + -- which key gets used for what purpose. Thus, the specific + -- numeric values associated with this type are irrelevant. + KeyToUse ::= ENUMERATED { + -- unspecified + key-unspecified, + -- server long term key + key-server, + -- client long term key + key-client, + -- key selected by KDC for encryption of a KDC-REP + key-kdc-rep, + -- session key from ticket + key-session, + -- subsession key negotiated via AP-REQ/AP-REP + key-subsession, + ... + } + + +6.3. EncryptionKey + + The "EncryptionKey" type holds an encryption key. + + EncryptionKey ::= SEQUENCE { + keytype [0] EType, + keyvalue [1] OCTET STRING + } + + + keytype + This "EType" identifies the encryption algorithm, described in + [KCRYPTO]. + + keyvalue + Contains the actual key. + +6.4. EncryptedData + + The "EncryptedData" type contains the encryption of another data + type. The recipient uses fields within EncryptedData to determine + which key to use for decryption. + + + + + +Yu Expires: Mar 2005 [Page 24] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + + -- "Type" specifies which ASN.1 type is encrypted to the + -- ciphertext in the EncryptedData. "Keys" specifies a set of + -- keys of which one key may be used to encrypt the data. + -- "KeyUsages" specifies a set of key usages, one of which may + -- be used to encrypt. + -- + -- None of the parameters is transmitted over the wire. + EncryptedData { + Type, KeyToUse:Keys, KeyUsage:KeyUsages + } ::= SEQUENCE { + etype [0] EType, + kvno [1] UInt32 OPTIONAL, + cipher [2] OCTET STRING (CONSTRAINED BY { + -- must be encryption of -- + OCTET STRING (CONTAINING Type), + -- with one of the keys -- KeyToUse:Keys, + -- with key usage being one of -- + KeyUsage:KeyUsages + }), + ... + } + + + + KeyUsages + Advisory parameter indicating which key usage to use when + encrypting the ciphertext. If "KeyUsages" indicate multiple + "KeyUsage" values, the detailed description of the containing + message will indicate which key to use under which conditions. + + Type + Advisory parameter indicating the ASN.1 type whose DER encoding + is the plaintext encrypted into the EncryptedData. + + Keys + Advisory parameter indicating which key to use to perform the + encryption. If "Keys" indicate multiple "KeyToUse" values, the + detailed description of the containing message will indicate + which key to use under which conditions. + + KeyUsages + Advisory parameter indicating which "KeyUsage" value is used to + encrypt. If "KeyUsages" indicates multiple "KeyUsage" values, + the detailed description of the containing message will indicate + which key usage to use under which conditions. + +6.5. Checksums + + Several types contain checksums (actually signatures) of data. + + +Yu Expires: Mar 2005 [Page 25] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + CksumType ::= Int32 + + -- The parameters specify which key to use to produce the + -- signature, as well as which key usage to use. The + -- parameters are not actually sent over the wire. + Checksum { + KeyToUse:Keys, KeyUsage:KeyUsages + } ::= SEQUENCE { + cksumtype [0] CksumType, + checksum [1] OCTET STRING (CONSTRAINED BY { + -- signed using one of the keys -- + KeyToUse:Keys, + -- with key usage being one of -- + KeyUsage:KeyUsages + }) + } + + + CksumType + Integer type for assigned numbers for signature algorithms. + Defined in [KCRYPTO] + + Keys + As in EncryptedData + + KeyUsages + As in EncryptedData + + cksumtype + Signature algorithm used to produce the signature. + + checksum + The actual checksum. + +6.5.1. ChecksumOf + + ChecksumOf is similar to "Checksum", but specifies which type is + signed. + + -- a Checksum that must contain the checksum + -- of a particular type + ChecksumOf { + Type, KeyToUse:Keys, KeyUsage:KeyUsages + } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS { + ..., + checksum (CONSTRAINED BY { + -- must be checksum of -- + OCTET STRING (CONTAINING Type) + }) + }) + + +Yu Expires: Mar 2005 [Page 26] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + Type + Indicates the ASN.1 type whose DER encoding is signed. + +6.5.2. Signed + + Signed is similar to "ChecksumOf", but contains an actual instance of + the type being signed in addition to the signature. + + -- parameterized type for wrapping authenticated plaintext + Signed { + InnerType, KeyToUse:Keys, KeyUsage:KeyUsages + } ::= SEQUENCE { + cksum [0] ChecksumOf { + InnerType, Keys, KeyUsages + } OPTIONAL, + inner [1] InnerType, + ... + } + + +7. Tickets + + [ A large number of items described here are duplicated in the + sections describing KDC-REQ processing. Should find a way to avoid + this duplication. ] + + A ticket binds a principal name to a session key. The important + fields of a ticket are in the encrypted part. The components in + common between the RFC 1510 and the extensible versions are + + EncTicketPartCommon ::= SEQUENCE { + flags [0] TicketFlags, + key [1] EncryptionKey, + crealm [2] Realm, + cname [3] PrincipalName, + 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, + ... + } + + + crealm + This field contains the client's realm. + + cname + This field contains the client's name. + +Yu Expires: Mar 2005 [Page 27] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + caddr + This field lists the network addresses (if absent, all addresses + are permitted) from which the ticket is valid. + + Descriptions of the other fields appear in the following sections. + +7.1. Timestamps + + Three of the ticket timestamps may be requested from the KDC. The + timestamps may differ from those requested, depending on site policy. + + authtime + The time at which the client authenticated, as recorded by the + KDC. + + starttime + The earliest time when the ticket is valid. If not present, the + ticket is valid starting at the authtime. This is requested as + the "from" field of KDC-REQ-BODY-COMMON. + + endtime + This time is requested in the "till" field of KDC-REQ-BODY- + COMMON. Contains the time after which the ticket will not be + honored (its expiration time). Note that individual services + MAY place their own limits on the life of a ticket and MAY + reject tickets which have not yet expired. As such, this is + really an upper bound on the expiration time for the ticket. + + renew-till + This time is requested in the "rtime" field of KDC-REQ-BODY- + COMMON. It is only present in tickets that have the "renewable" + flag set in the flags field. It indicates the maximum endtime + that may be included in a renewal. It can be thought of as the + absolute expiration time for the ticket, including all renewals. + +7.2. Ticket Flags + + 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. + + + + + + + + + + + + + +Yu Expires: Mar 2005 [Page 28] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + TicketFlags ::= KerberosFlags { TicketFlagsBits } + + TicketFlagsBits ::= BIT STRING { + reserved (0), + forwardable (1), + forwarded (2), + proxiable (3), + proxy (4), + may-postdate (5), + postdated (6), + invalid (7), + renewable (8), + initial (9), + pre-authent (10), + hw-authent (11), + transited-policy-checked (12), + ok-as-delegate (13), + anonymous (14), + cksummed-ticket (15) + } + + +7.2.1. Flags Relating to Initial Ticket Acquisition + + [ adapted KCLAR 2.1. ] + + Several flags indicate the details of how the initial ticket was + acquired. + + initial + The "initial" flag indicates that a ticket was issued using the + AS protocol, rather than issued based on a ticket-granting + ticket. Application servers (e.g., a password-changing program) + requiring a client's definite knowledge of its secret key can + insist that this flag be set in any tickets they accept, thus + being assured that the client's key was recently presented to + the application client. + + pre-authent + The "pre-authent" flag indicates that some sort of pre- + authentication was used during the AS exchange. + + hw-authent + The "hw-authent" flag indicates that some sort of hardware-based + pre-authentication occurred during the AS exchange. + + Both the "pre-authent" and the "hw-authent" flags may be present with + or without the "initial" flag; such tickets with the "initial" flag + clear are ones which are derived from initial tickets with the "pre- + authent" or "hw-authent" flags set. + + +Yu Expires: Mar 2005 [Page 29] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + +7.2.2. Invalid Tickets + + [ KCLAR 2.2. ] + + The "invalid" flag indicates that a ticket is invalid. Application + servers MUST reject tickets which have this flag set. A postdated + ticket will be issued in this form. Invalid tickets MUST be + validated by the KDC before use, by presenting them to the KDC in a + TGS request with the "validate" option specified. The KDC will only + validate tickets after their starttime has passed. The validation is + required so that postdated tickets which have been stolen before + their starttime can be rendered permanently invalid (through a hot- + list mechanism -- see Section 8.3.2.4). + +7.2.3. OK as Delegate + + [ KCLAR 2.8. ] + + The "ok-as-delegate" flag provides a way for a KDC to communicate + local realm policy to a client regarding whether the service for + which the ticket is issued is trusted to accept delegated + credentials. For some applications, a client may need to delegate + credentials to a service to act on its behalf in contacting other + services. The ability of a client to obtain a service ticket for a + service conveys no information to the client about whether the + service should be trusted to accept delegated credentials. + + The copy of the ticket flags visible to the client may have the "ok- + as-delegate" flag set to indicate to the client that the service + specified in the ticket has been determined by policy of the realm to + be a suitable recipient of delegation. A client can use the presence + of this flag to help it make a decision whether to delegate + credentials (either grant a proxy or a forwarded ticket-granting + ticket) to this service. It is acceptable to ignore the value of + this flag. When setting this flag, an administrator should consider + the security and placement of the server on which the service will + run, as well as whether the service requires the use of delegated + credentials. + +7.2.4. Renewable Tickets + + [ adapted KCLAR 2.3. ] + + The "renewable" flag indicates whether the ticket may be renewed. + + Renewable tickets can be used to mitigate the consequences of ticket + theft. Applications may desire to hold credentials which can be + valid for long periods of time. However, this can expose the + credentials to potential theft for equally long periods, and those + stolen credentials would be valid until the expiration time of the + ticket(s). Simply using short-lived tickets and obtaining new ones + +Yu Expires: Mar 2005 [Page 30] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + periodically would require the application to have long-term access + to the client's secret key, which is an even greater risk. + + Renewable tickets have two "expiration times": the first is when the + current instance of the ticket expires, and the second is the latest + permissible value for an individual expiration time. An application + client must periodically present an unexpired renewable ticket to the + KDC, setting the "renew" option in the KDC request. The KDC will + issue a new ticket with a new session key and a later expiration + time. All other fields of the ticket are left unmodified by the + renewal process. When the latest permissible expiration time + arrives, the ticket expires permanently. At each renewal, the KDC + MAY consult a hot-list to determine if the ticket had been reported + stolen since its last renewal; it will refuse to renew such stolen + tickets, and thus the usable lifetime of stolen tickets is reduced. + + The "renewable" flag in a ticket is normally only interpreted by the + ticket-granting service. It can usually be ignored by application + servers. However, some particularly careful application servers MAY + disallow renewable tickets. + + If a renewable ticket is not renewed by its expiration time, the KDC + will not renew the ticket. The "renewable" flag is clear by default, + but a client can request it be set by setting the "renewable" option + in the AS-REQ message. If it is set, then the "renew-till" field in + the ticket contains the time after which the ticket may not be + renewed. + +7.2.5. Postdated Tickets + + postdated + indicates a ticket which has been postdated + + may-postdate + indicates that postdated tickets may be issued based on this + ticket + + [ KCLAR 2.4. ] + + Applications may occasionally need to obtain tickets for use much + later, e.g., a batch submission system would need tickets to be valid + at the time the batch job is serviced. However, it is dangerous to + hold valid tickets in a batch queue, since they will be on-line + longer and more prone to theft. Postdated tickets provide a way to + obtain these tickets from the KDC at job submission time, but to + leave them "dormant" until they are activated and validated by a + further request of the KDC. If a ticket theft were reported in the + interim, the KDC would refuse to validate the ticket, and the thief + would be foiled. + + + +Yu Expires: Mar 2005 [Page 31] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + The "may-postdate" flag in a ticket is normally only interpreted by + the TGS. It can be ignored by application servers. This flag MUST + be set in a ticket-granting ticket in order for the KDC to issue a + postdated ticket based on the presented ticket. It is reset by + default; it MAY be requested by a client by setting the "allow- + postdate" option in the AS-REQ [?also TGS-REQ?] message. This flag + does not allow a client to obtain a postdated ticket-granting ticket; + postdated ticket-granting tickets can only by obtained by requesting + the postdating in the AS-REQ message. The life (endtime minus + starttime) of a postdated ticket will be the remaining life of the + ticket-granting ticket at the time of the request, unless the + "renewable" option is also set, in which case it can be the full life + (endtime minus starttime) of the ticket-granting ticket. The KDC MAY + limit how far in the future a ticket may be postdated. + + The "postdated" flag indicates that a ticket has been postdated. The + application server can check the authtime field in the ticket to see + when the original authentication occurred. Some services MAY choose + to reject postdated tickets, or they may only accept them within a + certain period after the original authentication. When the KDC + issues a "postdated" ticket, it will also be marked as "invalid", so + that the application client MUST present the ticket to the KDC for + validation before use. + +7.2.6. Proxiable and Proxy Tickets + + proxy + indicates a proxy ticket + + proxiable + indicates that proxy tickets may be issued based on this ticket + + [ KCLAR 2.5. ] + + It may be necessary for a principal to allow a service to perform an + operation on its behalf. The service must be able to take on the + identity of the client, but only for a particular purpose. A + principal can allow a service to take on the principal's identity for + a particular purpose by granting it a proxy. + + The process of granting a proxy using the "proxy" and "proxiable" + flags is used to provide credentials for use with specific services. + Though conceptually also a proxy, users wishing to delegate their + identity in a form usable for all purposes MUST use the ticket + forwarding mechanism described in the next section to forward a + ticket-granting ticket. + + The "proxiable" flag in a ticket is normally only interpreted by the + ticket-granting service. It can be ignored by application servers. + When set, this flag tells the ticket-granting server that it is OK to + issue a new ticket (but not a ticket-granting ticket) with a + +Yu Expires: Mar 2005 [Page 32] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + different network address based on this ticket. This flag is set if + requested by the client on initial authentication. By default, the + client will request that it be set when requesting a ticket-granting + ticket, and reset when requesting any other ticket. + + This flag allows a client to pass a proxy to a server to perform a + remote request on its behalf (e.g. a print service client can give + the print server a proxy to access the client's files on a particular + file server in order to satisfy a print request). + + In order to complicate the use of stolen credentials, Kerberos + tickets may contain a set of network addresses from which they are + valid. When granting a proxy, the client MUST specify the new + network address from which the proxy is to be used, or indicate that + the proxy is to be issued for use from any address. + + The "proxy" flag is set in a ticket by the TGS when it issues a proxy + ticket. Application servers MAY check this flag and at their option + they MAY require additional authentication from the agent presenting + the proxy in order to provide an audit trail. + +7.2.7. Forwarded and Forwardable Tickets + + forwarded + indicates a forwarded ticket + + forwardable + indicates that forwarded tickets may be issued based on this + ticket + + [ KCLAR 2.6. ] + + Authentication forwarding is an instance of a proxy where the service + that is granted is complete use of the client's identity. An example + where it might be used is when a user logs in to a remote system and + wants authentication to work from that system as if the login were + local. + + The "forwardable" flag in a ticket is normally only interpreted by + the ticket-granting service. It can be ignored by application + servers. The "forwardable" flag has an interpretation similar to + that of the "proxiable" flag, except ticket-granting tickets may also + be issued with different network addresses. This flag is reset by + default, but users MAY request that it be set by setting the + "forwardable" option in the AS request when they request their + initial ticket-granting ticket. + + This flag allows for authentication forwarding without requiring the + user to enter a password again. If the flag is not set, then + authentication forwarding is not permitted, but the same result can + still be achieved if the user engages in the AS exchange specifying + +Yu Expires: Mar 2005 [Page 33] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + the requested network addresses and supplies a password. + + The "forwarded" flag is set by the TGS when a client presents a + ticket with the "forwardable" flag set and requests a forwarded + ticket by specifying the "forwarded" KDC option and supplying a set + of addresses for the new ticket. It is also set in all tickets + issued based on tickets with the "forwarded" flag set. Application + servers may choose to process "forwarded" tickets differently than + non-forwarded tickets. + + If addressless tickets are forwarded from one system to another, + clients SHOULD still use this option to obtain a new TGT in order to + have different session keys on the different systems. + +7.3. Transited Realms + + [ KCLAR 2.7., plus new stuff ] + +7.4. Authorization Data + + [ KCLAR 5.2.6. ] + + ADType ::= TH-id + + AuthorizationData ::= SEQUENCE OF SEQUENCE { + ad-type [0] ADType, + ad-data [1] OCTET STRING + } + + + ad-type + This field identifies the contents of the ad-data. All negative + values are reserved for local use. Non-negative values are + reserved for registered use. + + ad-data + This field contains authorization data to be interpreted + according to the value of the corresponding ad-type field. + + Each sequence of ADType and OCTET STRING is referred to as an + authorization element. Elements MAY be application specific, + however, there is a common set of recursive elements that should be + understood by all implementations. These elements contain other + AuthorizationData, and the interpretation of the encapsulating + element determines which enclosed elements must be interpreted, and + which may be ignored. + + Depending on the meaning of the encapsulating element, the + encapsulated AuthorizationData may be ignored, interpreted as issued + directly by the KDC, or be stored in a separate plaintext part of the + ticket. The types of the encapsulating elements are specified as + +Yu Expires: Mar 2005 [Page 34] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + part of the Kerberos protocol because behavior based on these + container elements should be understood across implementations, while + other elements need only be understood by the applications which they + affect. + + Authorization data elements are considered critical if present in a + ticket or authenticator. Unless encapsulated in a known + authorization data element modifying the criticality of the elements + it contains, an application server MUST reject the authentication of + a client whose AP-REQ or ticket contains an unrecognized + authorization data element. Authorization data is intended to + restrict the use of a ticket. If the service cannot determine + whether it is the target of a restriction, a security weakness may + exist if the ticket can be used for that service. Authorization + elements that are truly optional can be enclosed in AD-IF-RELEVANT + element. + + + ad-type | contents of ad-data + ________|_______________________________________ + 1 | DER encoding of AD-IF-RELEVANT + 4 | DER encoding of AD-KDCIssued + 5 | DER encoding of AD-AND-OR + 8 | DER encoding of AD-MANDATORY-FOR-KDC + + + +7.4.1. AD-IF-RELEVANT + + ad-if-relevant ADType ::= int32 : 1 + + -- Encapsulates another AuthorizationData. + -- Intended for application servers; receiving application servers + -- MAY ignore. + AD-IF-RELEVANT ::= AuthorizationData + + AD elements encapsulated within the if-relevant element are intended + for interpretation only by application servers that understand the + particular ad-type of the embedded element. Application servers that + do not understand the type of an element embedded within the if- + relevant element MAY ignore the uninterpretable element. This element + promotes interoperability across implementations which may have local + extensions for authorization. The ad-type for AD-IF-RELEVANT is (1). + +7.4.2. AD-KDCIssued + + + + + + + +Yu Expires: Mar 2005 [Page 35] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + -- KDC-issued privilege attributes + ad-kdcissued ADType ::= int32 : 4 + + AD-KDCIssued ::= SEQUENCE { + ad-checksum [0] ChecksumOf { + AuthorizationData, { key-session }, + { ku-ad-KDCIssued-cksum }}, + i-realm [1] Realm OPTIONAL, + i-sname [2] PrincipalName OPTIONAL, + elements [3] AuthorizationData + } + + + ad-checksum + A cryptographic checksum computed over the DER encoding of the + AuthorizationData in the "elements" field, keyed with the + session key. Its checksumtype is the mandatory checksum type + for the encryption type of the session key, and its key usage + value is 19. + + i-realm, i-sname + The name of the issuing principal if different from the KDC + itself. This field would be used when the KDC can verify the + authenticity of elements signed by the issuing principal and it + allows this KDC to notify the application server of the validity + of those elements. + + elements + AuthorizationData issued by the KDC. + + The KDC-issued ad-data field is intended to provide a means for + Kerberos credentials to embed within themselves privilege attributes + and other mechanisms for positive authorization, amplifying the + privileges of the principal beyond what it would have if using + credentials without such an authorization-data element. + + This amplification of privileges cannot be provided without this + element because the definition of the authorization-data field allows + elements to be added at will by the bearer of a TGT at the time that + they request service tickets and elements may also be added to a + delegated ticket by inclusion in the authenticator. + + For KDC-issued elements this is prevented because the elements are + signed by the KDC by including a checksum encrypted using the + server's key (the same key used to encrypt the ticket -- or a key + derived from that key). AuthorizationData encapsulated with in the + AD-KDCIssued element MUST be ignored by the application server if + this "signature" is not present. Further, AuthorizationData + encapsulated within this element from a ticket-granting ticket MAY be + interpreted by the KDC, and used as a basis according to policy for + including new signed elements within derivative tickets, but they + +Yu Expires: Mar 2005 [Page 36] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + will not be copied to a derivative ticket directly. If they are + copied directly to a derivative ticket by a KDC that is not aware of + this element, the signature will not be correct for the application + ticket elements, and the field will be ignored by the application + server. + + This element and the elements it encapsulates MAY be safely ignored + by applications, application servers, and KDCs that do not implement + this element. + + The ad-type for AD-KDC-ISSUED is (4). + +7.4.3. AD-AND-OR + + ad-and-or ADType ::= int32 : 5 + + AD-AND-OR ::= SEQUENCE { + condition-count [0] INTEGER, + elements [1] AuthorizationData + } + + + When restrictive AD elements are encapsulated within the and-or + element, the and-or element is considered satisfied if and only if at + least the number of encapsulated elements specified in condition- + count are satisfied. Therefore, this element MAY be used to + implement an "or" operation by setting the condition-count field to + 1, and it MAY specify an "and" operation by setting the condition + count to the number of embedded elements. Application servers that do + not implement this element MUST reject tickets that contain + authorization data elements of this type. + + The ad-type for AD-AND-OR is (5). + +7.4.4. AD-MANDATORY-FOR-KDC + + -- KDCs MUST interpret any AuthorizationData wrapped in this. + ad-mandatory-for-kdc ADType ::= int32 : 8 + AD-MANDATORY-FOR-KDC ::= AuthorizationData + + AD elements encapsulated within the mandatory-for-kdc element are to + be interpreted by the KDC. KDCs that do not understand the type of + an element embedded within the mandatory-for-kdc element MUST reject + the request. + + The ad-type for AD-MANDATORY-FOR-KDC is (8). + +7.5. Encrypted Part of Ticket + + The complete definition of the encrypted part is + + +Yu Expires: Mar 2005 [Page 37] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + -- Encrypted part of ticket + EncTicketPart ::= CHOICE { + rfc1510 [APPLICATION 3] EncTicketPart1510, + ext [APPLICATION 5] EncTicketPartExt + } + + with the common portion being + + EncTicketPartCommon ::= SEQUENCE { + flags [0] TicketFlags, + key [1] EncryptionKey, + crealm [2] Realm, + cname [3] PrincipalName, + 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, + ... + } + + + 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: + + EncTicketPartExt ::= EncTicketPartCommon (WITH COMPONENTS { + ..., + -- 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)) + }) + + + + +Yu Expires: Mar 2005 [Page 38] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + +7.6. Cleartext Part of Ticket + + The complete definition of Ticket is: + + Ticket ::= CHOICE { + rfc1510 [APPLICATION 1] Ticket1510, + ext [APPLICATION 4] Signed { + 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 + in cleartext, as a hint to aid the server in choosing the correct + decryption key. + + The backwards-compatibility form of Ticket is: + + Ticket1510 ::= SEQUENCE { + COMPONENTS OF TicketCommon { EncTicketPart1510 } + } (WITH COMPONENTS { + ..., + -- explicitly force IA5 in strings + realm (RealmIA5), + sname (PrincipalNameIA5) + }) + + The extensible form of Ticket is: + + + + + + + + + +Yu Expires: Mar 2005 [Page 39] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + -- 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) + }) + + + TicketExtensions, which may only be present in the extensible form of + Ticket, are a cleartext typed hole for extension use. + AuthorizationData already provides an encrypted typed hole. + + TEType ::= TH-id + + -- ticket extensions: for TicketExt only + TicketExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE { + te-type [0] TEType, + te-data [1] OCTET STRING + } + + + A client will only receive an extensible Ticket if the application + server supports extensibility. + +8. Credential Acquisition + + There are two exchanges that can be used for acquiring credentials: + the AS exchange and the TGS exchange. These exchanges have many + similarities, and this document describes them in parallel, noting + which behaviors are specific to one type of exchange. The AS request + (AS-REQ) and TGS request (TGS-REQ) are both forms of KDC requests + (KDC-REQ). Likewise, the AS reply (AS-REP) and TGS reply (TGS-REP) + are forms of KDC replies (KDC-REP). + + The credentials acquisition protocol operates over specific + transports. Additionally, specific methods exist to permit a client + to discover the KDC host with which to communicate. + +8.1. KDC-REQ + + 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 + directly encoded; it is always a part of a AS-REQ or a TGS-REQ. + + + + + +Yu Expires: Mar 2005 [Page 40] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + KDC-REQ-COMMON ::= SEQUENCE { + -- NOTE: first tag is [1], not [0] + pvno [1] INTEGER (5), + msg-type [2] INTEGER (10 -- AS-REQ.rfc1510 -- + | 12 -- TGS-REQ.rfc1510 -- + | 6 -- AS-REQ.ext -- + | 8 -- TGS-REQ.ext -- ), + padata [3] SEQUENCE OF PA-DATA OPTIONAL + -- NOTE: not empty + } + + + KDC-REQ-BODY-COMMON ::= SEQUENCE { + kdc-options [0] KDCOptions, + cname [1] PrincipalName OPTIONAL + -- Used only in AS-REQ --, + + realm [2] Realm + -- Server's realm; also client's in AS-REQ --, + + sname [3] PrincipalName OPTIONAL, + 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-sesskey } + } OPTIONAL, + + additional-tickets [11] SEQUENCE OF Ticket OPTIONAL + -- NOTE: not empty --, + ... + lang-tags [5] SEQUENCE (SIZE (1..MAX)) OF + LangTag OPTIONAL, + ... + } + + + Many fields of KDC-REQ-BODY-COMMON correspond directly to fields of + an EncTicketPartCommon. The KDC copies most of them unchanged, + provided that the requested values meet site policy. + +Yu Expires: Mar 2005 [Page 41] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + kdc-options + These flags do not correspond directly to "flags" in + EncTicketPartCommon. + + cname + This field is copied to the "cname" field in + EncTicketPartCommon. The "cname" field is required in an AS- + REQ; the client places its own name here. In a TGS-REQ, the + "cname" in the ticket in the AP-REQ takes precedence. + + realm + This field is the server's realm, and also holds the client's + realm in an AS-REQ. + + sname + The "sname" field indicates the server's name. It may be absent + in a TGS-REQ which requests user-to-user authentication, in + which case the "sname" of the issued ticket will be taken from + the included additional ticket. + + The "from", "till", and "rtime" fields correspond to the "starttime", + "endtime", and "renew-till" fields of EncTicketPartCommon. + + addresses + This field corresponds to the "caddr" field of + EncTicketPartCommon. + + enc-authorization-data + For TGS-REQ, this field contains authorization data encrypted + using either the TGT session key or the AP-REQ subsession key; + the KDC may copy these into the "authorization-data" field of + EncTicketPartCommon if policy permits. + + lang-tags + Only present in the extensible messages. Specifies the set of + languages which the client is willing to accept in error + messages. + + KDC options used in a KDC-REQ are: + + + + + + + + + + + + + +Yu Expires: Mar 2005 [Page 42] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + KDCOptions ::= KerberosFlags { KDCOptionsBits } + + KDCOptionsBits ::= BIT STRING { + reserved (0), + forwardable (1), + forwarded (2), + proxiable (3), + proxy (4), + allow-postdate (5), + postdated (6), + unused7 (7), + renewable (8), + unused9 (9), + unused10 (10), + unused11 (11), + unused12 (12), + unused13 (13), + requestanonymous (14), + canonicalize (15), + disable-transited-check (26), + renewable-ok (27), + enc-tkt-in-skey (28), + renew (30), + validate (31) + -- XXX need "need ticket1" flag? + } + + Different options apply to different phases of KDC-REQ processing. + + The backwards-compatibility form of a KDC-REQ is: + + KDC-REQ-1510 ::= SEQUENCE { + COMPONENTS OF KDC-REQ-COMMON, + req-body [4] KDC-REQ-BODY-1510 + } (WITH COMPONENTS { ..., msg-type (10 | 12) }) + + 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 { + COMPONENTS OF KDC-REQ-COMMON, + 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: + +Yu Expires: Mar 2005 [Page 43] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + KDC-REQ-BODY-1510 ::= SEQUENCE { + COMPONENTS OF KDC-REQ-BODY-COMMON + } (WITH COMPONENTS { + ..., + cname (PrincipalNameIA5), + realm (RealmIA5), + sname (PrincipalNameIA5), + till PRESENT, + nonce (UInt32) + }) + + The extensible form of a KDC-REQ-BODY is: + + 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)) + }) + + The AS-REQ is: + + + + + + + + + + + + + + + + + + + + + + +Yu Expires: Mar 2005 [Page 44] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + AS-REQ ::= CHOICE { + rfc1510 [APPLICATION 10] KDC-REQ-1510 + (WITH COMPONENTS { + ..., + 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 { + ..., + msg-type (6), + -- AS-REQ must include client name + req-body (WITH COMPONENTS { ..., cname PRESENT }) + }) + } + + 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 + framework. A client SHOULD send the extensible AS-REQ alternative in + 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 + what if their contents conflict? ] + + The TGS-REQ is: + + + + + + + + + + + + + + + + + + + +Yu Expires: Mar 2005 [Page 45] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + TGS-REQ ::= CHOICE { + rfc1510 [APPLICATION 12] KDC-REQ-1510 + (WITH COMPONENTS { + ..., + 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 { + ..., + msg-type (8), + -- client name optional in TGS-REQ + req-body (WITH COMPONENTS { ..., cname ABSENT }) + }) + } + + +8.2. PA-DATA + + PA-DATA have multiple uses in the Kerberos protocol. They may pre- + authenticate an AS-REQ; they may also modify several of the + 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 + use. PA-DATA may also include "hints" about which pre-authentication + mechanisms to use, or include data for input into a pre- + authentication mechanism. + + [ XXX enumerate standard padata here ] + +8.3. KDC-REQ Processing + + Processing of a KDC-REQ proceeds through several steps. An + implementation need not perform these steps exactly as described, as + long as it behaves as if the steps were performed as described. The + KDC performs replay handling upon receiving the request; it then + validates the request, adjusts timestamps, and selects the keys used + in the reply. It copies data from the request into the issued + ticket, adjusting the values to conform with its policies. The KDC + then transmits the reply to the client. + +8.3.1. Handling Replays + + Because Kerberos can run over unreliable transports such as UDP, the + KDC MUST be prepared to retransmit responses in case they are lost. + If a KDC receives a request identical to one it has recently + +Yu Expires: Mar 2005 [Page 46] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + successfully processed, the KDC MUST respond with a KDC-REP message + rather than a replay error. In order to reduce the amount of + ciphertext given to a potential attacker, KDCs MAY send the same + response generated when the request was first handled. KDCs MUST + obey this replay behavior even if the actual transport in use is + reliable. If the AP-REQ which authenticates a TGS-REQ is a replay, + and the entire request is not identical to a recently successfully + processed request, the KDC SHOULD return "krb-ap-err-repeat", as is + appropriate for AP-REQ processing. + +8.3.2. Request Validation + +8.3.2.1. AS-REQ Authentication + + Site policy determines whether a given client principal is required + to provide some pre-authentication prior to receiving an AS-REP. + Since the default reply key is typically the client's long-term + password-based key, an attacker may easily request known plaintext + (in the form of an AS-REP) upon which to mount a dictionary attack. + Pre-authentication can limit the possibility of such an attack. + + If site policy requires pre-authentication for a client principal, + and no pre-authentication is provided, the KDC returns the error + "kdc-err-preauth-required". Accompanying this error are "e-data" + which include hints telling the client which pre-authentication + mechanisms to use, or data for input to pre-authentication mechanisms + (e.g., input to challenge-response systems). If pre-authentication + fails, the KDC returns the error "kdc-err-preauth-failed". + + [ may need additional changes based on Sam's preauth draft ] + +8.3.2.2. TGS-REQ Authentication + + A TGS-REQ has an accompanying AP-REQ, which is included in the "pa- + tgs-req". The KDC MUST validate the checksum in the Authenticator of + the AP-REQ, which is computed over the KDC-REQ-BODY-1510 or KDC-REQ- + BODY-EXT (for TGS-REQ-1510 or TGS-REQ-EXT, respectively) of the + request. [ padata not signed by authenticator! ] Any error from the + AP-REQ validation process SHOULD be returned in a KRB-ERROR message. + The service principal in the ticket of the AP-REQ may be a ticket- + granting service principal, or a normal application service + principal. A ticket which is not a ticket-granting ticket MUST NOT + be used to issue a ticket for any service other than the one named in + the ticket. In this case, the "renew", "validate", or "proxy" [?also + forwarded?] option must be set in the request. + +8.3.2.3. Principal Validation + + If the client principal in an AS-REQ is unknown, the KDC returns the + error "kdc-err-c-principal-unknown". If the server principal in a + KDC-REQ is unknown, the KDC returns the error "kdc-err-s-principal- + +Yu Expires: Mar 2005 [Page 47] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + unknown". + +8.3.2.4. Checking For Revoked or Invalid Tickets + + [ KCLAR 3.3.3.1 ] + + Whenever a request is made to the ticket-granting server, the + presented ticket(s) is(are) checked against a hot-list of tickets + which have been canceled. This hot-list might be implemented by + storing a range of issue timestamps for "suspect tickets"; if a + presented ticket had an authtime in that range, it would be rejected. + In this way, a stolen ticket-granting ticket or renewable ticket + cannot be used to gain additional tickets (renewals or otherwise) + once the theft has been reported to the KDC for the realm in which + the server resides. Any normal ticket obtained before it was + reported stolen will still be valid (because they require no + interaction with the KDC), but only until their normal expiration + time. If TGTs have been issued for cross-realm authentication, use + of the cross-realm TGT will not be affected unless the hot-list is + propagated to the KDCs for the realms for which such cross-realm + tickets were issued. + + If a TGS-REQ ticket has its "invalid" flag set, the KDC MUST NOT + issue any ticket unless the TGS-REQ requests the "validate" option. + +8.3.3. Timestamp Handling + + [ some aspects of timestamp handling, especially regarding postdating + and renewal, are difficult to read in KCLAR... needs closer + examination here ] + + Processing of "starttime" (requested in the "from" field) differs + depending on whether the "postdated" option is set in the request. + If the "postdated" option is not set, and the requested "starttime" + is in the future beyond the window of acceptable clock skew, the KDC + returns the error "kdc-err-cannot-postdate". If the "postdated" + option is not set, and the requested "starttime" is absent or does + not indicate a time in the future beyond the acceptable clock skew, + the KDC sets the "starttime" to the KDC's current time. The + "postdated" option MUST NOT be honored if the ticket is being + requested by TGS-REQ and the "may-postdate" is not set in the TGT. + Otherwise, if the "postdated" option is set, and site policy permits, + the KDC sets the "starttime" as requested, and sets the "invalid" + flag in the new ticket. + + The "till" field is required in the RFC 1510 version of the KDC-REQ. + If the "till" field is equal to "19700101000000Z" (midnight, January + 1, 1970), the KDC SHOULD behave as if the "till" field were absent. + + The KDC MUST NOT issue a ticket whose "starttime", "endtime", or + "renew-till" time is later than the "renew-till" time of the ticket + +Yu Expires: Mar 2005 [Page 48] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + from which it is derived. + +8.3.3.1. AS-REQ Timestamp Processing + + In the AS exchange, the "authtime" of a ticket is set to the local + time at the KDC. + + The "endtime" of the ticket will be set to the earlier of the + requested "till" time and a time determined by local policy, possibly + determined using factors specific to the realm or principal. For + example, the expiration time MAY be set to the earliest of the + following: + + * the expiration time ("till" value) requested + + * the ticket's start time plus the maximum allowable lifetime + associated with the client principal from the authentication + server's database + + * the ticket's start time plus the maximum allowable lifetime + associated with the server principal + + * the ticket's start time plus the maximum lifetime set by the + policy of the local realm + + If the requested expiration time minus the start time (as determined + above) is less than a site-determined minimum lifetime, an error + message with code "kdc-err-never-valid" is returned. If the + requested expiration time for the ticket exceeds what was determined + as above, and if the "renewable-ok" option was requested, then the + "renewable" flag is set in the new ticket, and the "renew-till" value + is set as if the "renewable" option were requested. + + If the "renewable" option has been requested or if the "renewable-ok" + option has been set and a renewable ticket is to be issued, then the + "renew-till" field MAY be set to the earliest of: + + * its requested value + + * the start time of the ticket plus the minimum of the two maximum + renewable lifetimes associated with the principals' database + entries + + * the start time of the ticket plus the maximum renewable lifetime + set by the policy of the local realm + +8.3.3.2. TGS-REQ Timestamp Processing + + In the TGS exchange, the KDC sets the "authtime" to that of the + ticket in the AP-REQ authenticating the TGS-REQ. [?application + server can print a ticket for itself with a spoofed authtime. + +Yu Expires: Mar 2005 [Page 49] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + security issues for hot-list?] [ MIT implementation may change + authtime of renewed tickets; needs check... ] + + If the TGS-REQ has a TGT as the ticket in its AP-REQ, and the TGS-REQ + requests an "endtime" (in the "till" field), then the "endtime" of + the new ticket is set to the minimum of + + * the requested "endtime" value, + + * the "endtime" in the TGT, and + + * an "endtime" determined by site policy on ticket lifetimes. + + If the new ticket is a renewal, the "endtime" of the new ticket is + bounded by the minimum of + + * the requested "endtime" value, + + * the value of the "renew-till" value of the old, + + * the "starttime" of the new ticket plus the lifetime (endtime + minus starttime) of the old ticket, i.e., the lifetime of the + new ticket may not exceed that of the ticket being renewed [ + adapted from KCLAR 3.3.3. ], and + + * an "endtime" determined by site policy on ticket lifetimes. + + When handling a TGS-REQ, a KDC MUST NOT issue a postdated ticket with + a "starttime", "endtime", or "renew-till" time later than the + "renew-till" time of the TGT. + +8.3.4. Handling Transited Realms + + 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 + policy permits the transit path in the TGS-REQ ticket, the KDC sets + the "transited-policy-checked" flag in the issued ticket. If the + "disable-transited-check" option is set, the issued ticket will have + the "transited-policy-checked" flag cleared. + +8.3.5. Address Processing The requested "addresses" in the KDC-REQ are + copied into the issued ticket. If the "addresses" field is absent or + empty in a TGS-REQ, the KDC copies addresses from the ticket in the + TGS-REQ into the issued ticket, unless the either "forwarded" or + "proxy" option is set. If the "forwarded" option is set, and the + ticket in the TGS-REQ has its "forwardable" flag set, the KDC copies + the addresses from the TGS-REQ, not the from TGS-REQ ticket, into the + issued ticket. The KDC behaves similarly if the "proxy" option is + set in the TGS-REQ and the "proxiable" flag is set in the ticket. + The "proxy" option will not be honored on requests for additional + ticket-granting tickets. + +Yu Expires: Mar 2005 [Page 50] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + +8.3.6. Ticket Flag Processing + + Many kdc-options request that the KDC set a corresponding flag in the + issued ticket. kdc-options marked with an asterisk (*) in the + following table do not directly request the corresponding ticket flag + and therefore require special handling. + + + kdc-option | ticket flag affected + ________________________|__________________________ + forwardable | forwardable + forwarded | forwarded + proxiable | proxiable + proxy | proxy + allow-postdate | may-postdate + postdated | postdated + renewable | renewable + requestanonymous | anonymous + canonicalize | - + disable-transited-check*| transited-policy-checked + renewable-ok* | renewable + enc-tkt-in-skey | - + renew | - + validate* | invalid + + + + forwarded + The KDC sets the "forwarded" flag in the issued ticket if the + "forwarded" option is set in the TGS-REQ and the "forwardable" + flag is set in the TGS-REQ ticket. + + proxy + The KDC sets the "proxy" flag in the issued ticket if the + "proxy" option is set in the TGS-REQ and the "proxiable" flag is + set in the TGS-REQ ticket. + + disable-transited-check + The handling of the "disable-transited-check" kdc-option is + described in Section 8.3.4. + + renewable-ok + The handling of the "renewable-ok" kdc-option is described in + Section 8.3.3.1. + + enc-tkt-in-skey + This flag modifies ticket key selection to use the session key + of an additional ticket included in the TGS-REQ, for the purpose + of user-to-user authentication. + + + +Yu Expires: Mar 2005 [Page 51] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + validate + If the "validate" kdc-option is set in a TGS-REQ, and the + "starttime" has passed, the KDC will clear the "invalid" bit on + the ticket before re-issuing it. + +8.3.7. Key Selection + + Three keys are involved in creating a KDC-REP. The reply key + encrypts the encrypted part of the KDC-REP. The session key is + stored in the encrypted part of the ticket, and is also present in + 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 + initial values for a given exchange; pre-authentication and other + extension mechanisms may change the value used for any of these keys. + + [ again, may need changes based on Sam's preauth draft ] + +8.3.7.1. Reply Key and Session Key Selection + + 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 + of possible reply keys and the set of session key encryption types + based on the "etype" field. + + 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" + field. The KDC SHOULD use the first valid strong "etype" for which + an encryption key is available. For the TGS exchange, the reply key + is initially the subsession key of the Authenticator. If the + Authenticator subsesion key is absent, the reply key is initially the + session key of the ticket used to authenticate the TGS-REQ. + + The session key is initially randomly generated, and has an + encryption type which both the client and the server will understand. + Typically, the KDC has prior knowledge of which encryption types the + server will understand. It selects the first valid strong "etype" + listed the request which the server also will understand. + +8.3.7.2. Ticket Key Selection + + The ticket key is initially the long-term key of the service. The + "enc-tkt-in-skey" option requests user-to-user authentication, where + the ticket encryption key of the issued ticket is set equal to the + session key of the additional ticket in the request. + +8.4. KDC-REP + + The important parts of the KDC-REP are encrypted. + + + + +Yu Expires: Mar 2005 [Page 52] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + EncASRepPart1510 ::= [APPLICATION 25] EncKDCRepPart1510 + EncTGSRepPart1510 ::= [APPLICATION 26] EncKDCRepPart1510 + + EncASRepPartExt ::= [APPLICATION 32] EncKDCRepPartExt + EncTGSRepPartExt ::= [APPLICATION 33] EncKDCRepPartExt + + EncKDCRepPartCom ::= SEQUENCE { + key [0] EncryptionKey, + last-req [1] LastReq, + nonce [2] Nonce, + 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] Realm, + sname [10] PrincipalName, + 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 + corresponding fields in the returned ticket. + + + + + + + + + + + + + +Yu Expires: Mar 2005 [Page 53] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + KDC-REP-COMMON { EncPart } ::= SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (11 -- AS-REP.rfc1510 -- | + 13 -- TGS.rfc1510 -- | + 7 -- AS-REP.ext -- | + 9 -- TGS-REP.ext -- ), + padata [2] SEQUENCE OF PA-DATA OPTIONAL, + crealm [3] Realm, + cname [4] PrincipalName, + 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 -- } + }, + + ..., + -- In extensible version, KDC signs original request + -- to avoid replay attacks against client. + req-cksum [7] ChecksumOf { CHOICE { + as-req AS-REQ, + tgs-req TGS-REQ + }, { key-reply }, { ku-KDCRep-cksum }} 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) + }) + + + + + + + + +Yu Expires: Mar 2005 [Page 54] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + KDC-REP-EXT { EncPart } ::= KDC-REP-COMMON { EncPart } + (WITH COMPONENTS { + ..., + msg-type (7 | 9), + crealm (RealmExt), + cname (PrincipalNameExt) + }) + + + req-cksum + Signature of the original request using the reply key, to avoid + replay attacks against the client, among other things. Only + present in the extensible version of KDC-REP. + + AS-REP ::= CHOICE { + rfc1510 [APPLICATION 11] KDC-REP-1510 { + EncASRepPart1510 + } (WITH COMPONENTS { ..., msg-type (11) }), + ext [APPLICATION 7] Signed { + [APPLICATION 7] KDC-REP-EXT { EncASRepPartExt }, + { key-reply }, { ku-ASRep-cksum } + } (WITH COMPONENTS { ..., msg-type (7) }) + } + + + TGS-REP ::= CHOICE { + rfc1510 [APPLICATION 13] KDC-REP-1510 { + EncTGSRepPart1510 + } (WITH COMPONENTS { ..., msg-type (13) }), + ext [APPLICATION 9] Signed { + [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt }, + { key-reply }, { ku-TGSRep-cksum } + } (WITH COMPONENTS { ..., msg-type (9) }) + } + + + The extensible versions of AS-REQ and TGS-REQ are signed with the + reply key, to prevent an attacker from performing a delayed denial- + of-service attack by substituting the ticket. + +8.5. Reply Validation + + [ signature verification ] + +8.6. IP Transports + + [ KCLAR 7.2 ] + + Kerberos defines two IP transport mechanisms for the credentials + acquisition protocol: UDP/IP and TCP/IP. + + +Yu Expires: Mar 2005 [Page 55] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + +8.6.1. UDP/IP transport + + Kerberos servers (KDCs) supporting IP transports MUST accept UDP + requests and SHOULD listen for such requests on port 88 (decimal) + unless specifically configured to listen on an alternative UDP port. + Alternate ports MAY be used when running multiple KDCs for multiple + realms on the same host. + + Kerberos clients supporting IP transports SHOULD support the sending + of UDP requests. Clients SHOULD use KDC discovery (Section 8.6.3) to + identify the IP address and port to which they will send their + request. + + When contacting a KDC for a KRB_KDC_REQ request using UDP/IP + transport, the client shall send a UDP datagram containing only an + encoding of the request to the KDC. The KDC will respond with a reply + datagram containing only an encoding of the reply message (either a + KRB-ERROR or a KDC-REP) to the sending port at the sender's IP + address. The response to a request made through UDP/IP transport MUST + also use UDP/IP transport. If the response can not be handled using + UDP (for example because it is too large), the KDC MUST return "krb- + err-response-too-big", forcing the client to retry the request using + the TCP transport. + +8.6.2. TCP/IP transport + + Kerberos servers (KDCs) supporting IP transports MUST accept TCP + requests and SHOULD listen for such requests on port 88 (decimal) + unless specifically configured to listen on an alternate TCP port. + Alternate ports MAY be used when running multiple KDCs for multiple + realms on the same host. + + Clients MUST support the sending of TCP requests, but MAY choose to + initially try a request using the UDP transport. Clients SHOULD use + KDC discovery (Section 8.6.3) to identify the IP address and port to + which they will send their request. + + Implementation note: Some extensions to the Kerberos protocol will + not succeed if any client or KDC not supporting the TCP transport is + involved. Implementations of RFC 1510 were not required to support + TCP/IP transports. + + When the KDC-REQ message is sent to the KDC over a TCP stream, the + response (KDC-REP or KRB-ERROR message) MUST be returned to the + client on the same TCP stream that was established for the request. + The KDC MAY close the TCP stream after sending a response, but MAY + leave the stream open for a reasonable period of time if it expects a + followup. Care must be taken in managing TCP/IP connections on the + KDC to prevent denial of service attacks based on the number of open + TCP/IP connections. + + +Yu Expires: Mar 2005 [Page 56] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + The client MUST be prepared to have the stream closed by the KDC at + anytime after the receipt of a response. A stream closure SHOULD NOT + be treated as a fatal error. Instead, if multiple exchanges are + required (e.g., certain forms of pre-authentication) the client may + need to establish a new connection when it is ready to send + subsequent messages. A client MAY close the stream after receiving a + response, and SHOULD close the stream if it does not expect to send + followup messages. + + A client MAY send multiple requests before receiving responses, + though it must be prepared to handle the connection being closed + after the first response. + + Each request (KDC-REQ) and response (KDC-REP or KRB-ERROR) sent over + the TCP stream is preceded by the length of the request as 4 octets + in network byte order. The high bit of the length is reserved for + future expansion and MUST currently be set to zero. If a KDC that + does not understand how to interpret a set high bit of the length + encoding receives a request with the high order bit of the length + set, it MUST return a KRB-ERROR message with the error "krb-err- + field-toolong" and MUST close the TCP stream. + + If multiple requests are sent over a single TCP connection, and the + KDC sends multiple responses, the KDC is not required to send the + responses in the order of the corresponding requests. This may + permit some implementations to send each response as soon as it is + ready even if earlier requests are still being processed (for + example, waiting for a response from an external device or database). + +8.6.3. KDC Discovery on IP Networks + + Kerberos client implementations MUST provide a means for the client + to determine the location of the Kerberos Key Distribution Centers + (KDCs). Traditionally, Kerberos implementations have stored such + configuration information in a file on each client machine. + Experience has shown this method of storing configuration information + presents problems with out-of-date information and scaling problems, + especially when using cross-realm authentication. This section + describes a method for using the Domain Name System [RFC 1035] for + storing KDC location information. + +8.6.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names + + In Kerberos, realm names are case sensitive. While it is strongly + encouraged that all realm names be all upper case this recommendation + has not been adopted by all sites. Some sites use all lower case + names and other use mixed case. DNS, on the other hand, is case + insensitive for queries. Since the realm names "MYREALM", "myrealm", + and "MyRealm" are all different, but resolve the same in the domain + name system, it is necessary that only one of the possible + combinations of upper and lower case characters be used in realm + +Yu Expires: Mar 2005 [Page 57] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + names. + +8.6.3.2. DNS SRV records for KDC location + + KDC location information is to be stored using the DNS SRV RR [RFC + 2782]. The format of this RR is as follows: + + _Service._Proto.Realm TTL Class SRV Priority Weight Port Target + + The Service name for Kerberos is always "kerberos". + + The Proto can be one of "udp", "tcp". If these SRV records are to be + used, both "udp" and "tcp" records MUST be specified for all KDC + deployments. + + The Realm is the Kerberos realm that this record corresponds to. The + realm MUST be a domain style realm name. + + TTL, Class, SRV, Priority, Weight, and Target have the standard + meaning as defined in RFC 2782. + + As per RFC 2782 the Port number used for "_udp" and "_tcp" SRV + records SHOULD be the value assigned to "kerberos" by the Internet + Assigned Number Authority: 88 (decimal) unless the KDC is configured + to listen on an alternate TCP port. + + Implementation note: Many existing client implementations do not + support KDC Discovery and are configured to send requests to the IANA + assigned port (88 decimal), so it is strongly recommended that KDCs + be configured to listen on that port. + +8.6.3.3. KDC Discovery for Domain Style Realm Names on IP Networks + + These are DNS records for a Kerberos realm EXAMPLE.COM. It has two + Kerberos servers, kdc1.example.com and kdc2.example.com. Queries + should be directed to kdc1.example.com first as per the specified + priority. Weights are not used in these sample records. + + _kerberos._udp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. + _kerberos._udp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. + _kerberos._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. + _kerberos._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. + + +9. Errors + + The KRB-ERROR message is returned by the KDC if an error occurs + during credentials acquisition. It may also be returned by an + application server if an error occurs during authentication. + + + +Yu Expires: Mar 2005 [Page 58] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + ErrCode ::= Int32 + + KRB-ERROR ::= CHOICE { + rfc1510 [APPLICATION 30] KRB-ERROR-1510, + ext [APPLICATION 23] Signed { + KRB-ERROR-EXT, { ku-KrbError-cksum } } + } + + + The extensible KRB-ERROR is only signed if there has been a key + negotiated with its recipient. KRB-ERROR messages sent in response + to AS-REQ messages will probably not be signed unless a + preauthentication mechanism has negotiated a key. (Signing using a + client's long-term key can expose ciphertext to dictionary attacks.) + + The parts of a KRB-ERROR common to both the backwards-compatibility + and the extensibile messages are + + KRB-ERROR-COMMON ::= SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (30 | 23), + ctime [2] KerberosTime OPTIONAL, + cusec [3] Microseconds OPTIONAL, + stime [4] KerberosTime, + susec [5] Microseconds, + error-code [6] ErrCode, + crealm [7] Realm OPTIONAL, + cname [8] PrincipalName OPTIONAL, + realm [9] Realm -- Correct realm --, + sname [10] PrincipalName -- Correct name --, + e-text [11] KerberosString OPTIONAL, + e-data [12] OCTET STRING OPTIONAL, + ..., + typed-data [13] TYPED-DATA OPTIONAL, + nonce [14] Nonce OPTIONAL, + lang-tag [15] LangTag OPTIONAL, + ... + } + + + 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) }) + + +Yu Expires: Mar 2005 [Page 59] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + ctime, cusec + Client's time, if known from a KDC-REQ or AP-REQ. + + stime, susec + KDC or application server's current time. + + error-code + Numeric error code designating the error. + + crealm, cname + Client's realm and name, if known. + + realm, sname + server's realm and name. [ XXX what if these aren't known? ] + + e-text + Human-readable text providing additional details for the error. + + e-data + This field contains additional data about the error for use by + the client to help it recover from or handle the error. If the + "error-code" is "kdc-err-preauth-required", then the e-data + field will contain an encoding of a sequence of padata fields, + each corresponding to an acceptable pre-authentication method + and optionally containing data for the method: + + METHOD-DATA ::= SEQUENCE OF PA-DATA + + + For error codes defined in this document other than "kdc-err- + preauth-required", the format and contents of the e-data field + are implementation-defined. Similarly, for future error codes, + the format and contents of the e-data field are implementation- + defined unless specified. + + lang-tag + Indicates the language of the message in the "e-text" field. It + is only present in the extensible KRB-ERROR. + + nonce + is the nonce from a KDC-REQ. It is only present in the + extensible KRB-ERROR. + + typed-data + TYPED-DATA is a typed hole allowing for additional data to be + returned in error conditions, since "e-data" is insufficiently + flexible for some purposes. TYPED-DATA is only present in the + extensible KRB-ERROR. + + + + +Yu Expires: Mar 2005 [Page 60] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + TDType ::= TH-id + + TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { + data-type [0] TDType, + data-value [1] OCTET STRING OPTIONAL + } + + +10. Session Key Exchange + + Session key exchange consists of the AP-REQ and AP-REP messages. The + client sends the AP-REQ message, and the service responds with an + AP-REP message if mutual authentication is desired. Following + session key exchange, the client and service share a secret session + key, or possibly a subsesion key, which can be used to protect + further communications. Additionally, the session key exchange + process can establish initial sequence numbers which the client and + service can use to detect replayed messages. + +10.1. AP-REQ + + An AP-REQ message contains a ticket and a authenticator. The + authenticator is ciphertext encrypted with the session key contained + in the ticket. The plaintext contents of the authenticator are: + + -- plaintext of authenticator + Authenticator ::= [APPLICATION 2] SEQUENCE { + authenticator-vno [0] INTEGER (5), + crealm [1] Realm, + cname [2] PrincipalName, + 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 + } + + The common parts between the RFC 1510 and the extensible versions of + the AP-REQ are: + + + + + + + + + + +Yu Expires: Mar 2005 [Page 61] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + AP-REQ-COMMON ::= SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (14 | 18), + ap-options [2] APOptions, + ticket [3] Ticket, + authenticator [4] EncryptedData { + Authenticator, + { key-session }, + { ku-APReq-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 { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (14 | 18), + ap-options [2] APOptions, + ticket [3] Ticket, + authenticator [4] EncryptedData { + Authenticator, + { key-session }, + { ku-APReq-authenticator | + ku-pa-TGSReq-authenticator } + }, + ..., + extensions [5] ApReqExtensions OPTIONAL, + lang-tag [6] SEQUENCE (SIZE (1..MAX)) + OF LangTag OPTIONAL, + ... + } + + + + + + + +Yu Expires: Mar 2005 [Page 62] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + 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 } + + APOptionsBits ::= BIT STRING { + reserved (0), + use-session-key (1), + mutual-required (2) + } + + +10.2. AP-REP + + An AP-REP message provides mutual authentication of the service to + the client. + + EncAPRepPart ::= CHOICE { + rfc1510 [APPLICATION 27] EncAPRepPart1510, + ext [APPLICATION 31] EncAPRepPartExt + } + + +Yu Expires: Mar 2005 [Page 63] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + EncAPRepPartCom ::= SEQUENCE { + ctime [0] KerberosTime, + cusec [1] Microseconds, + subkey [2] EncryptionKey OPTIONAL, + seq-number [3] SeqNum OPTIONAL, + ..., + authorization-data [4] AuthorizationData OPTIONAL, + ... + } + + + EncAPRepPart1510 ::= SEQUENCE { + COMPONENTS OF ENCAPRepPartCom + } (WITH COMPONENTS { + ..., + seq-number (UInt32), + authorization-data ABSENT + }) + + + EncAPRepPartExt ::= EncAPRepPartCom + + + AP-REP ::= CHOICE { + rfc1510 [APPLICATION 15] AP-REP-1510, + ext [APPLICATION 19] Signed { + AP-REP-EXT, + { key-session | key-subsession }, { ku-APRep-cksum }} + } + + + AP-REP-COMMON { EncPart } ::= SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (15 | 19), + enc-part [2] EncryptedData { + EncPart, + { key-session | key-subsession }, { ku-EncAPRepPart }}, + ..., + extensions [3] ApRepExtensions OPTIONAL, + ... + } + + + AP-REP-1510 ::= SEQUENCE { + COMPONENTS OF AP-REP-COMMON { EncAPRepPart1510 } + } (WITH COMPONENTS { + ..., + msg-type (15) + }) + + + +Yu Expires: Mar 2005 [Page 64] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + AP-REP-EXT ::= [APPLICATION 19] AP-REP-COMMON { + EncAPRepPartExt + } (WITH COMPONENTS { ..., msg-type (19) }) + + +11. Session Key Use + + Once a session key has been established, the client and server can + use several kinds of messages to securely transmit data. KRB-SAFE + provides integrity protection for application data, while KRB-PRIV + provides confidentiality along with integrity protection. The KRB- + CRED message provides a means of securely forwarding credentials from + the client host to the server host. + +11.1. KRB-SAFE + + The KRB-SAFE message provides integrity protection for an included + cleartext message. + + -- Do we chew up another tag for KRB-SAFE-EXT? That would + -- allow us to make safe-body optional, allowing for a GSS-MIC + -- sort of message. + 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 { + user-data [0] OCTET STRING, + timestamp [1] KerberosTime OPTIONAL, + usec [2] Microseconds OPTIONAL, + seq-number [3] SeqNum OPTIONAL, + s-address [4] HostAddress, + r-address [5] HostAddress OPTIONAL, + ... -- ASN.1 extensions must be excluded + -- when sending to rfc1510 implementations + } + + +11.2. KRB-PRIV + + The KRB-PRIV message provides confidentiality and integrity + protection. + + +Yu Expires: Mar 2005 [Page 65] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + KRB-PRIV ::= [APPLICATION 21] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (21), + enc-part [3] EncryptedData { + EncKrbPrivPart, + { key-session | key-subsession }, { ku-EncKrbPrivPart }}, + ... + } + + + EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { + user-data [0] OCTET STRING, + timestamp [1] KerberosTime OPTIONAL, + usec [2] Microseconds OPTIONAL, + seq-number [3] SeqNum OPTIONAL, + s-address [4] HostAddress -- sender's addr --, + r-address [5] HostAddress OPTIONAL -- recip's addr --, + ... -- ASN.1 extensions must be excluded + -- when sending to rfc1510 implementations + } + + +11.3. KRB-CRED + + The KRB-CRED message provides a means of securely transferring + credentials from the client to the service. + + KRB-CRED ::= CHOICE { + rfc1510 [APPLICATION 22] KRB-CRED-1510, + ext [APPLICATION 24] Signed { + KRB-CRED-EXT, + { key-session | key-subsession }, { ku-KrbCred-cksum }} + } + + + KRB-CRED-COMMON ::= SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (22 | 24), + tickets [2] SEQUENCE OF Ticket, + enc-part [3] EncryptedData { + EncKrbCredPart, + { key-session | key-subsession }, { ku-EncKrbCredPart }}, + ... + } + + + KRB-CRED-1510 ::= SEQUENCE { + COMPONENTS OF KRB-CRED-COMMON + } (WITH COMPONENTS { ..., msg-type (22) }) + + + +Yu Expires: Mar 2005 [Page 66] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + KRB-CRED-EXT ::= [APPLICATION 24] KRB-CRED-COMMON + (WITH COMPONENTS { ..., msg-type (24) }) + + + EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { + ticket-info [0] SEQUENCE OF KrbCredInfo, + nonce [1] Nonce OPTIONAL, + timestamp [2] KerberosTime OPTIONAL, + usec [3] Microseconds OPTIONAL, + s-address [4] HostAddress OPTIONAL, + r-address [5] HostAddress OPTIONAL + } + + + KrbCredInfo ::= SEQUENCE { + key [0] EncryptionKey, + prealm [1] Realm OPTIONAL, + pname [2] PrincipalName OPTIONAL, + flags [3] TicketFlags OPTIONAL, + authtime [4] KerberosTime OPTIONAL, + starttime [5] KerberosTime OPTIONAL, + endtime [6] KerberosTime OPTIONAL, + renew-till [7] KerberosTime OPTIONAL, + srealm [8] Realm OPTIONAL, + sname [9] PrincipalName OPTIONAL, + caddr [10] HostAddresses OPTIONAL + } + + +12. Security Considerations + +12.1. Time Synchronization + + Time synchronization between the KDC and application servers is + necessary to prevent acceptance of expired tickets. + + Time synchronization is needed between application servers and + clients to prevent replay attacks if a replay cache is being used. + If negotiated subsession keys are used to encrypt application data, + replay caches may not be necessary. + +12.2. Replays + +12.3. Principal Name Reuse + + See Section 5.3. + +12.4. Password Guessing + + + + +Yu Expires: Mar 2005 [Page 67] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + +12.5. Forward Secrecy + + [from KCLAR 10.; needs some rewriting] + + The Kerberos protocol in its basic form does not provide perfect + forward secrecy for communications. If traffic has been recorded by + an eavesdropper, then messages encrypted using the KRB-PRIV message, + or messages encrypted using application-specific encryption under + keys exchanged using Kerberos can be decrypted if any of the user's, + application server's, or KDC's key is subsequently discovered. This + is because the session key used to encrypt such messages is + transmitted over the network encrypted in the key of the application + server, and also encrypted under the session key from the user's + ticket-granting ticket when returned to the user in the TGS-REP + message. The session key from the ticket-granting ticket was sent to + the user in the AS-REP message encrypted in the user's secret key, + and embedded in the ticket-granting ticket, which was encrypted in + the key of the KDC. Application requiring perfect forward secrecy + must exchange keys through mechanisms that provide such assurance, + but may use Kerberos for authentication of the encrypted channel + established through such other means. + +12.6. Authorization + + As an authentication service, Kerberos provides a means of verifying + the identity of principals on a network. Kerberos does not, by + itself, provide authorization. Applications SHOULD NOT accept the + mere issuance of a service ticket by the Kerberos server as granting + authority to use the service. + +12.7. Login Authentication + + Some applications, particularly those which provide login access when + provided with a password, SHOULD NOT treat successful acquisition of + credentials as sufficient proof of the user's identity. An attacker + posing as a user could generate an illegitimate KDC-REP message which + decrypts properly. To authenticate a user logging on to a local + system, the credentials obtained SHOULD be used in a TGS exchange to + obtain credentials for a local service. Successful use of those + credentials to authenticate to the local service assures that the + initially obtained credentials are from a valid KDC. + +13. IANA Considerations + + [ needs more work ] + + Each use of Int32 in this document defines a number space. [ XXX + enumerate these ] Negative numbers are reserved for private use; + local and experimental extensions should use these values. Zero is + reserved and may not be assigned. + + +Yu Expires: Mar 2005 [Page 68] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + Typed hole contents may be identified by either Int32 values or by + RELATIVE-OID values. Since RELATIVE-OIDs define a hierarchical + namespace, assignments to the top level of the RELATIVE-OID space may + be made on a first-come, first-served basis. + +14. Acknowledgments + + Much of the text here is adapted from draft-ietf-krb-wg-kerberos- + clarifications-07. The description of the general form of the + extensibility framework was derived from text by Sam Hartman. + +Appendices + +A. ASN.1 Module (Normative) + + KerberosV5Spec3 { + iso(1) identified-organization(3) dod(6) internet(1) + security(5) kerberosV5(2) modules(4) krb5spec3(4) + } DEFINITIONS EXPLICIT TAGS ::= BEGIN + + + -- OID arc for KerberosV5 + -- + -- This OID may be used to identify Kerberos protocol messages + -- encapsulated in other protocols. + -- + -- This OID also designates the OID arc for KerberosV5-related + -- OIDs. + -- + -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its + -- OID. + id-krb5 OBJECT IDENTIFIER ::= { + iso(1) identified-organization(3) dod(6) internet(1) + security(5) kerberosV5(2) + } + + + + + + + + + + + + + + + + + +Yu Expires: Mar 2005 [Page 69] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + -- top-level type + -- + -- Applications should not directly reference any types + -- other than KRB-PDU and its component types. + -- + KRB-PDU ::= CHOICE { + ticket Ticket, + as-req AS-REQ, + as-rep AS-REP, + tgs-req TGS-REQ, + tgs-rep TGS-REP, + ap-req AP-REQ, + ap-rep AP-REP, + krb-safe KRB-SAFE, + krb-priv KRB-PRIV, + krb-cred KRB-CRED, + tgt-req TGT-REQ, + krb-error KRB-ERROR, + ... + } + + + -- + -- *** basic types + -- + + + -- signed values representable in 32 bits + -- + -- These are often used as assigned numbers for various things. + Int32 ::= INTEGER (-2147483648..2147483647) + + + -- Typed hole identifiers + TH-id ::= CHOICE { + int32 Int32, + rel-oid RELATIVE-OID + } + + + -- unsigned 32 bit values + UInt32 ::= INTEGER (0..4294967295) + + + -- unsigned 64 bit values + UInt64 ::= INTEGER (0..18446744073709551615) + + + -- sequence numbers + SeqNum ::= UInt64 + + +Yu Expires: Mar 2005 [Page 70] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + -- nonces + Nonce ::= UInt64 + + + -- microseconds + Microseconds ::= INTEGER (0..999999) + + + KerberosTime ::= GeneralizedTime (CONSTRAINED BY { + -- MUST NOT include fractional seconds + }) + + + -- used for names and for error messages + KerberosString ::= CHOICE { + ia5 GeneralString (IA5String), + utf8 UTF8String, + ... -- no extension may be sent + -- to an rfc1510 implementation -- + } + + + -- IA5 choice only; useful for constraints + KerberosStringIA5 ::= KerberosString + (WITH COMPONENTS { ia5 PRESENT }) + + -- IA5 excluded; useful for constraints + KerberosStringExt ::= KerberosString + (WITH COMPONENTS { ia5 ABSENT }) + + + -- used for language tags + LangTag ::= PrintableString + (FROM ("A".."Z" | "a".."z" | "0".."9" | "-")) + + + + + + + + + + + + + + + + + + +Yu Expires: Mar 2005 [Page 71] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + -- assigned numbers for name types (used in principal names) + NameType ::= Int32 + + -- Name type not known + nt-unknown NameType ::= 0 + -- Just the name of the principal as in DCE, or for users + nt-principal NameType ::= 1 + -- Service and other unique instance (krbtgt) + nt-srv-inst NameType ::= 2 + -- Service with host name as instance (telnet, rcommands) + nt-srv-hst NameType ::= 3 + -- Service with host as remaining components + nt-srv-xhst NameType ::= 4 + -- Unique ID + nt-uid NameType ::= 5 + -- Encoded X.509 Distingished name [RFC 2253] + nt-x500-principal NameType ::= 6 + -- Name in form of SMTP email name (e.g. user@foo.com) + nt-smtp-name NameType ::= 7 + -- Enterprise name - may be mapped to principal name + nt-enterprise NameType ::= 10 + + + PrincipalName ::= SEQUENCE { + name-type [0] NameType, + -- May have zero elements, or individual elements may be + -- zero-length, but this is NOT RECOMMENDED. + name-string [1] SEQUENCE OF KerberosString + } + + + -- IA5 only + PrincipalNameIA5 ::= PrincipalName (WITH COMPONENTS { + ..., + name-string (WITH COMPONENT (KerberosStringIA5)) + }) + + -- IA5 excluded + PrincipalNameExt ::= PrincpalName (WITH COMPONENTS { + ..., + name-string (WITH COMPONENT (KerberosStringExt)) + }) + + + + + + + + + + +Yu Expires: Mar 2005 [Page 72] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + Realm ::= KerberosString + + -- IA5 only + RealmIA5 ::= Realm (KerberosStringIA5) + + -- IA5 excluded + RealmExt ::= Realm (KerberosStringExt) + + + KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX)) + (CONSTRAINED BY { + -- MUST be a valid value of -- NamedBits + -- but if the value to be sent would be truncated to shorter + -- than 32 bits according to DER, the value MUST be padded + -- with trailing zero bits to 32 bits. Otherwise, no + -- trailing zero bits may be present. + + }) + + + AddrType ::= Int32 + + HostAddress ::= SEQUENCE { + addr-type [0] AddrType, + address [1] OCTET STRING + } + + -- NOTE: HostAddresses is always used as an OPTIONAL field and + -- should not be a zero-length SEQUENCE OF. + -- + -- The extensible messages explicitly constrain this to be + -- non-empty. + HostAddresses ::= SEQUENCE OF HostAddress + + + -- + -- *** crypto-related types and assignments + -- + + + + + + + + + + + + + + +Yu Expires: Mar 2005 [Page 73] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + -- Assigned numbers denoting encryption mechanisms. + EType ::= Int32 + + -- assigned numbers for encryption schemes + et-des-cbc-crc EType ::= 1 + et-des-cbc-md4 EType ::= 2 + et-des-cbc-md5 EType ::= 3 + -- [reserved] 4 + et-des3-cbc-md5 EType ::= 5 + -- [reserved] 6 + et-des3-cbc-sha1 EType ::= 7 + et-dsaWithSHA1-CmsOID EType ::= 9 + et-md5WithRSAEncryption-CmsOID EType ::= 10 + et-sha1WithRSAEncryption-CmsOID EType ::= 11 + et-rc2CBC-EnvOID EType ::= 12 + et-rsaEncryption-EnvOID EType ::= 13 + et-rsaES-OAEP-ENV-OID EType ::= 14 + et-des-ede3-cbc-Env-OID EType ::= 15 + et-des3-cbc-sha1-kd EType ::= 16 + -- AES + et-aes128-cts-hmac-sha1-96 EType ::= 17 + -- AES + et-aes256-cts-hmac-sha1-96 EType ::= 18 + -- Microsoft + et-rc4-hmac EType ::= 23 + -- Microsoft + et-rc4-hmac-exp EType ::= 24 + -- opaque; PacketCable + et-subkey-keymaterial EType ::= 65 + + + + + + + + + + + + + + + + + + + + + + + +Yu Expires: Mar 2005 [Page 74] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + -- Assigned numbers denoting key usages. + KeyUsage ::= UInt32 + + -- + -- Actual identifier names are provisional and subject to + -- change. + -- + ku-pa-enc-ts KeyUsage ::= 1 + ku-Ticket KeyUsage ::= 2 + ku-EncASRepPart KeyUsage ::= 3 + ku-TGSReqAuthData-sesskey KeyUsage ::= 4 + ku-TGSReqAuthData-subkey KeyUsage ::= 5 + ku-pa-TGSReq-cksum KeyUsage ::= 6 + ku-pa-TGSReq-authenticator KeyUsage ::= 7 + ku-EncTGSRepPart-sesskey KeyUsage ::= 8 + ku-EncTGSRepPart-subkey KeyUsage ::= 9 + ku-Authenticator-cksum KeyUsage ::= 10 + ku-APReq-authenticator KeyUsage ::= 11 + ku-EncAPRepPart KeyUsage ::= 12 + ku-EncKrbPrivPart KeyUsage ::= 13 + ku-EncKrbCredPart KeyUsage ::= 14 + ku-KrbSafe-cksum KeyUsage ::= 15 + ku-ad-KDCIssued-cksum KeyUsage ::= 19 + + + -- The following numbers are provisional... + -- conflicts may exist elsewhere. + ku-Ticket-cksum KeyUsage ::= 25 + ku-ASReq-cksum KeyUsage ::= 26 + ku-TGSReq-cksum KeyUsage ::= 27 + ku-ASRep-cksum KeyUsage ::= 28 + ku-TGSRep-cksum KeyUsage ::= 29 + ku-APReq-cksum KeyUsage ::= 30 + ku-APRep-cksum KeyUsage ::= 31 + ku-KrbCred-cksum KeyUsage ::= 32 + ku-KrbError-cksum KeyUsage ::= 33 + ku-KDCRep-cksum KeyUsage ::= 34 + + + + + + + + + + + + + + + +Yu Expires: Mar 2005 [Page 75] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + -- KeyToUse identifies which key is to be used to encrypt or + -- sign a given value. + -- + -- Values of KeyToUse are never actually transmitted over the + -- wire, or even used directly by the implementation in any + -- way, as key usages are; it exists primarily to identify + -- which key gets used for what purpose. Thus, the specific + -- numeric values associated with this type are irrelevant. + KeyToUse ::= ENUMERATED { + -- unspecified + key-unspecified, + -- server long term key + key-server, + -- client long term key + key-client, + -- key selected by KDC for encryption of a KDC-REP + key-kdc-rep, + -- session key from ticket + key-session, + -- subsession key negotiated via AP-REQ/AP-REP + key-subsession, + ... + } + + + EncryptionKey ::= SEQUENCE { + keytype [0] EType, + keyvalue [1] OCTET STRING + } + + + + + + + + + + + + + + + + + + + + + + + +Yu Expires: Mar 2005 [Page 76] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + + -- "Type" specifies which ASN.1 type is encrypted to the + -- ciphertext in the EncryptedData. "Keys" specifies a set of + -- keys of which one key may be used to encrypt the data. + -- "KeyUsages" specifies a set of key usages, one of which may + -- be used to encrypt. + -- + -- None of the parameters is transmitted over the wire. + EncryptedData { + Type, KeyToUse:Keys, KeyUsage:KeyUsages + } ::= SEQUENCE { + etype [0] EType, + kvno [1] UInt32 OPTIONAL, + cipher [2] OCTET STRING (CONSTRAINED BY { + -- must be encryption of -- + OCTET STRING (CONTAINING Type), + -- with one of the keys -- KeyToUse:Keys, + -- with key usage being one of -- + KeyUsage:KeyUsages + }), + ... + } + + + + CksumType ::= Int32 + + -- The parameters specify which key to use to produce the + -- signature, as well as which key usage to use. The + -- parameters are not actually sent over the wire. + Checksum { + KeyToUse:Keys, KeyUsage:KeyUsages + } ::= SEQUENCE { + cksumtype [0] CksumType, + checksum [1] OCTET STRING (CONSTRAINED BY { + -- signed using one of the keys -- + KeyToUse:Keys, + -- with key usage being one of -- + KeyUsage:KeyUsages + }) + } + + + + + + + + + + + +Yu Expires: Mar 2005 [Page 77] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + -- a Checksum that must contain the checksum + -- of a particular type + ChecksumOf { + Type, KeyToUse:Keys, KeyUsage:KeyUsages + } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS { + ..., + checksum (CONSTRAINED BY { + -- must be checksum of -- + OCTET STRING (CONTAINING Type) + }) + }) + + + -- parameterized type for wrapping authenticated plaintext + Signed { + InnerType, KeyToUse:Keys, KeyUsage:KeyUsages + } ::= SEQUENCE { + cksum [0] ChecksumOf { + InnerType, Keys, KeyUsages + } OPTIONAL, + inner [1] InnerType, + ... + } + + + -- + -- *** Tickets + -- + + + Ticket ::= CHOICE { + rfc1510 [APPLICATION 1] Ticket1510, + ext [APPLICATION 4] Signed { + TicketExt, { key-server }, { ku-Ticket-cksum } + } + } + + + -- 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, + ... + } + + +Yu Expires: Mar 2005 [Page 78] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + 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 + EncTicketPart ::= CHOICE { + rfc1510 [APPLICATION 3] EncTicketPart1510, + ext [APPLICATION 5] EncTicketPartExt + } + + + EncTicketPartCommon ::= SEQUENCE { + flags [0] TicketFlags, + key [1] EncryptionKey, + crealm [2] Realm, + cname [3] PrincipalName, + 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, + ... + } + + + + + + + + + +Yu Expires: Mar 2005 [Page 79] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + EncTicketPart1510 ::= SEQUENCE { + COMPONENTS OF EncTicketPartCommon + } (WITH COMPONENTS { + ..., + -- explicitly force IA5 in strings + crealm (RealmIA5), + cname (PrincipalNameIA5) + }) + + + EncTicketPartExt ::= EncTicketPartCommon (WITH COMPONENTS { + ..., + -- 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 + -- + + + ADType ::= TH-id + + AuthorizationData ::= SEQUENCE OF SEQUENCE { + ad-type [0] ADType, + ad-data [1] OCTET STRING + } + + + ad-if-relevant ADType ::= int32 : 1 + + -- Encapsulates another AuthorizationData. + -- Intended for application servers; receiving application servers + -- MAY ignore. + AD-IF-RELEVANT ::= AuthorizationData + + + + + + + + + + + +Yu Expires: Mar 2005 [Page 80] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + -- KDC-issued privilege attributes + ad-kdcissued ADType ::= int32 : 4 + + AD-KDCIssued ::= SEQUENCE { + ad-checksum [0] ChecksumOf { + AuthorizationData, { key-session }, + { ku-ad-KDCIssued-cksum }}, + i-realm [1] Realm OPTIONAL, + i-sname [2] PrincipalName OPTIONAL, + elements [3] AuthorizationData + } + + + ad-and-or ADType ::= int32 : 5 + + AD-AND-OR ::= SEQUENCE { + condition-count [0] INTEGER, + elements [1] AuthorizationData + } + + + -- KDCs MUST interpret any AuthorizationData wrapped in this. + ad-mandatory-for-kdc ADType ::= int32 : 8 + AD-MANDATORY-FOR-KDC ::= AuthorizationData + + + TrType ::= TH-id -- must be registered + + -- encoded Transited field + TransitedEncoding ::= SEQUENCE { + tr-type [0] TrType, + contents [1] OCTET STRING + } + + + TEType ::= TH-id + + -- ticket extensions: for TicketExt only + TicketExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE { + te-type [0] TEType, + te-data [1] OCTET STRING + } + + + + + + + + + + +Yu Expires: Mar 2005 [Page 81] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + TicketFlags ::= KerberosFlags { TicketFlagsBits } + + TicketFlagsBits ::= BIT STRING { + reserved (0), + forwardable (1), + forwarded (2), + proxiable (3), + proxy (4), + may-postdate (5), + postdated (6), + invalid (7), + renewable (8), + initial (9), + pre-authent (10), + hw-authent (11), + transited-policy-checked (12), + ok-as-delegate (13), + anonymous (14), + cksummed-ticket (15) + } + + + -- + -- *** KDC protocol + -- + + + + + + + + + + + + + + + + + + + + + + + + + + + +Yu Expires: Mar 2005 [Page 82] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + AS-REQ ::= CHOICE { + rfc1510 [APPLICATION 10] KDC-REQ-1510 + (WITH COMPONENTS { + ..., + 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 { + ..., + msg-type (6), + -- AS-REQ must include client name + req-body (WITH COMPONENTS { ..., cname PRESENT }) + }) + } + + + TGS-REQ ::= CHOICE { + rfc1510 [APPLICATION 12] KDC-REQ-1510 + (WITH COMPONENTS { + ..., + 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 { + ..., + msg-type (8), + -- client name optional in TGS-REQ + req-body (WITH COMPONENTS { ..., cname ABSENT }) + }) + } + + + + + +Yu Expires: Mar 2005 [Page 83] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + KDC-REQ-COMMON ::= SEQUENCE { + -- NOTE: first tag is [1], not [0] + pvno [1] INTEGER (5), + msg-type [2] INTEGER (10 -- AS-REQ.rfc1510 -- + | 12 -- TGS-REQ.rfc1510 -- + | 6 -- AS-REQ.ext -- + | 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 + } (WITH COMPONENTS { ..., msg-type (10 | 12) }) + + + -- APPLICATION tag goes inside Signed{} as well as outside, + -- to prevent possible substitution attacks. + KDC-REQ-EXT ::= SEQUENCE { + COMPONENTS OF KDC-REQ-COMMON, + req-body [4] KDC-REQ-BODY-EXT, + ... + } (WITH COMPONENTS { + ..., + msg-type (6 | 8), + padata (SIZE (1..MAX)) + }) + + + + + + + + + + + + + + + + + + + + + + + +Yu Expires: Mar 2005 [Page 84] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + KDC-REQ-BODY-COMMON ::= SEQUENCE { + kdc-options [0] KDCOptions, + cname [1] PrincipalName OPTIONAL + -- Used only in AS-REQ --, + + realm [2] Realm + -- Server's realm; also client's in AS-REQ --, + + sname [3] PrincipalName OPTIONAL, + 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-sesskey } + } OPTIONAL, + + additional-tickets [11] SEQUENCE OF Ticket OPTIONAL + -- NOTE: not empty --, + ... + lang-tags [5] SEQUENCE (SIZE (1..MAX)) OF + 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) + }) + + + + + + +Yu Expires: Mar 2005 [Page 85] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + 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 } + + KDCOptionsBits ::= BIT STRING { + reserved (0), + forwardable (1), + forwarded (2), + proxiable (3), + proxy (4), + allow-postdate (5), + postdated (6), + unused7 (7), + renewable (8), + unused9 (9), + unused10 (10), + unused11 (11), + unused12 (12), + unused13 (13), + requestanonymous (14), + canonicalize (15), + disable-transited-check (26), + renewable-ok (27), + enc-tkt-in-skey (28), + renew (30), + validate (31) + -- XXX need "need ticket1" flag? + } + + + + + + + + + +Yu Expires: Mar 2005 [Page 86] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + AS-REP ::= CHOICE { + rfc1510 [APPLICATION 11] KDC-REP-1510 { + EncASRepPart1510 + } (WITH COMPONENTS { ..., msg-type (11) }), + ext [APPLICATION 7] Signed { + [APPLICATION 7] KDC-REP-EXT { EncASRepPartExt }, + { key-reply }, { ku-ASRep-cksum } + } (WITH COMPONENTS { ..., msg-type (7) }) + } + + + TGS-REP ::= CHOICE { + rfc1510 [APPLICATION 13] KDC-REP-1510 { + EncTGSRepPart1510 + } (WITH COMPONENTS { ..., msg-type (13) }), + ext [APPLICATION 9] Signed { + [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt }, + { key-reply }, { ku-TGSRep-cksum } + } (WITH COMPONENTS { ..., msg-type (9) }) + } + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Yu Expires: Mar 2005 [Page 87] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + KDC-REP-COMMON { EncPart } ::= SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (11 -- AS-REP.rfc1510 -- | + 13 -- TGS.rfc1510 -- | + 7 -- AS-REP.ext -- | + 9 -- TGS-REP.ext -- ), + padata [2] SEQUENCE OF PA-DATA OPTIONAL, + crealm [3] Realm, + cname [4] PrincipalName, + 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 -- } + }, + + ..., + -- In extensible version, KDC signs original request + -- to avoid replay attacks against client. + req-cksum [7] ChecksumOf { CHOICE { + as-req AS-REQ, + tgs-req TGS-REQ + }, { key-reply }, { ku-KDCRep-cksum }} 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) + }) + + + + + + + + +Yu Expires: Mar 2005 [Page 88] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + KDC-REP-EXT { EncPart } ::= KDC-REP-COMMON { EncPart } + (WITH COMPONENTS { + ..., + msg-type (7 | 9), + crealm (RealmExt), + cname (PrincipalNameExt) + }) + + + EncASRepPart1510 ::= [APPLICATION 25] EncKDCRepPart1510 + EncTGSRepPart1510 ::= [APPLICATION 26] EncKDCRepPart1510 + + EncASRepPartExt ::= [APPLICATION 32] EncKDCRepPartExt + EncTGSRepPartExt ::= [APPLICATION 33] EncKDCRepPartExt + + EncKDCRepPartCom ::= SEQUENCE { + key [0] EncryptionKey, + last-req [1] LastReq, + nonce [2] Nonce, + 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] Realm, + sname [10] PrincipalName, + 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) + }) + + + + + + + + +Yu Expires: Mar 2005 [Page 89] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + LRType ::= TH-id + LastReq ::= SEQUENCE OF SEQUENCE { + lr-type [0] LRType, + lr-value [1] KerberosTime + } + + + -- + -- *** preauth + -- + + + PaDataType ::= TH-id + PaDataOID ::= RELATIVE-OID + + PA-DATA ::= SEQUENCE { + -- NOTE: first tag is [1], not [0] + padata-type [1] PaDataType, + padata-value [2] OCTET STRING + } + + + -- AP-REQ authenticating a TGS-REQ + pa-tgs-req PaDataType ::= int32 : 1 + PA-TGS-REQ ::= AP-REQ + + + -- Encrypted timestamp preauth + -- Encryption key used is client's long-term key. + pa-enc-timestamp PaDataType ::= int32 : 2 + + PA-ENC-TIMESTAMP ::= EncryptedData { + PA-ENC-TS-ENC, { key-client }, { ku-pa-enc-ts } + } + + PA-ENC-TS-ENC ::= SEQUENCE { + patimestamp [0] KerberosTime -- client's time --, + pausec [1] Microseconds OPTIONAL + } + + + + + + + + + + + + + +Yu Expires: Mar 2005 [Page 90] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + -- Hints returned in AS-REP or KRB-ERROR to help client + -- choose a password-derived key, either for preauthentication + -- or for decryption of the reply. + pa-etype-info PaDataType ::= int32 : 11 + + ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY + + ETYPE-INFO-ENTRY ::= SEQUENCE { + etype [0] EType, + salt [1] OCTET STRING OPTIONAL + } + + + -- Similar to etype-info, but with parameters provided for + -- the string-to-key function. + pa-etype-info2 PaDataType ::= int32 : 19 + + ETYPE-INFO2 ::= SEQUENCE (SIZE (1..MAX)) + OF ETYPE-INFO-ENTRY + + ETYPE-INFO2-ENTRY ::= SEQUENCE { + etype [0] EType, + salt [1] KerberosString OPTIONAL, + s2kparams [2] OCTET STRING OPTIONAL + } + + + -- Obsolescent. Salt for client's long-term key. + -- Its character encoding is unspecified. + pa-pw-salt PaDataType ::= int32 : 3 + -- The "padata-value" does not encode an ASN.1 type. + -- Instead, "padata-value" must consist of the salt string to + -- be used by the client, in an unspecified character + -- encoding. + + + -- An extensible AS-REQ may be sent as a padata in a + -- non-extensible AS-REQ to allow for backwards compatibility. + pa-as-req PaDataType ::= int32 : 42 -- provisional + PA-AS-REQ ::= AS-REQ (WITH COMPONENTS ext) + + + -- + -- *** Session key exchange + -- + + + + + + + +Yu Expires: Mar 2005 [Page 91] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + 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 { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (14 | 18), + ap-options [2] APOptions, + ticket [3] Ticket, + authenticator [4] EncryptedData { + Authenticator, + { key-session }, + { ku-APReq-authenticator | + ku-pa-TGSReq-authenticator } + }, + ..., + extensions [5] ApReqExtensions OPTIONAL, + lang-tag [6] SEQUENCE (SIZE (1..MAX)) + OF LangTag OPTIONAL, + ... + } + + + 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 }}) + }) + + + + + + + + + + + + +Yu Expires: Mar 2005 [Page 92] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + 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 + + ApReqExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE { + apReqExt-Type [0] ApReqExtType, + apReqExt-Data [1] OCTET STRING + } + + + APOptions ::= KerberosFlags { APOptionsBits } + + APOptionsBits ::= BIT STRING { + reserved (0), + use-session-key (1), + mutual-required (2) + } + + + -- plaintext of authenticator + Authenticator ::= [APPLICATION 2] SEQUENCE { + authenticator-vno [0] INTEGER (5), + crealm [1] Realm, + cname [2] PrincipalName, + 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 + } + + + + +Yu Expires: Mar 2005 [Page 93] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + AP-REP ::= CHOICE { + rfc1510 [APPLICATION 15] AP-REP-1510, + ext [APPLICATION 19] Signed { + AP-REP-EXT, + { key-session | key-subsession }, { ku-APRep-cksum }} + } + + + AP-REP-COMMON { EncPart } ::= SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (15 | 19), + enc-part [2] EncryptedData { + EncPart, + { key-session | key-subsession }, { ku-EncAPRepPart }}, + ..., + extensions [3] ApRepExtensions OPTIONAL, + ... + } + + + 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 + + ApRepExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE { + apRepExt-Type [0] ApRepExtType, + apRepExt-Data [1] OCTET STRING + } + + + EncAPRepPart ::= CHOICE { + rfc1510 [APPLICATION 27] EncAPRepPart1510, + ext [APPLICATION 31] EncAPRepPartExt + } + + + + + + + +Yu Expires: Mar 2005 [Page 94] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + EncAPRepPart1510 ::= SEQUENCE { + COMPONENTS OF ENCAPRepPartCom + } (WITH COMPONENTS { + ..., + seq-number (UInt32), + authorization-data ABSENT + }) + + + EncAPRepPartExt ::= EncAPRepPartCom + + + EncAPRepPartCom ::= SEQUENCE { + ctime [0] KerberosTime, + cusec [1] Microseconds, + subkey [2] EncryptionKey OPTIONAL, + seq-number [3] SeqNum OPTIONAL, + ..., + authorization-data [4] AuthorizationData OPTIONAL, + ... + } + + + -- + -- *** Application messages + -- + + + -- Do we chew up another tag for KRB-SAFE-EXT? That would + -- allow us to make safe-body optional, allowing for a GSS-MIC + -- sort of message. + 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 + } + + + + + + + + + + + +Yu Expires: Mar 2005 [Page 95] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + KRB-SAFE-BODY ::= SEQUENCE { + user-data [0] OCTET STRING, + timestamp [1] KerberosTime OPTIONAL, + usec [2] Microseconds OPTIONAL, + seq-number [3] SeqNum OPTIONAL, + s-address [4] HostAddress, + r-address [5] HostAddress OPTIONAL, + ... -- ASN.1 extensions must be excluded + -- when sending to rfc1510 implementations + } + + + KRB-PRIV ::= [APPLICATION 21] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (21), + enc-part [3] EncryptedData { + EncKrbPrivPart, + { key-session | key-subsession }, { ku-EncKrbPrivPart }}, + ... + } + + + EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { + user-data [0] OCTET STRING, + timestamp [1] KerberosTime OPTIONAL, + usec [2] Microseconds OPTIONAL, + seq-number [3] SeqNum OPTIONAL, + s-address [4] HostAddress -- sender's addr --, + r-address [5] HostAddress OPTIONAL -- recip's addr --, + ... -- ASN.1 extensions must be excluded + -- when sending to rfc1510 implementations + } + + + KRB-CRED ::= CHOICE { + rfc1510 [APPLICATION 22] KRB-CRED-1510, + ext [APPLICATION 24] Signed { + KRB-CRED-EXT, + { key-session | key-subsession }, { ku-KrbCred-cksum }} + } + + + + + + + + + + + + +Yu Expires: Mar 2005 [Page 96] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + KRB-CRED-COMMON ::= SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (22 | 24), + tickets [2] SEQUENCE OF Ticket, + enc-part [3] EncryptedData { + EncKrbCredPart, + { key-session | key-subsession }, { ku-EncKrbCredPart }}, + ... + } + + + 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 { + ticket-info [0] SEQUENCE OF KrbCredInfo, + nonce [1] Nonce OPTIONAL, + timestamp [2] KerberosTime OPTIONAL, + usec [3] Microseconds OPTIONAL, + s-address [4] HostAddress OPTIONAL, + r-address [5] HostAddress OPTIONAL + } + + + KrbCredInfo ::= SEQUENCE { + key [0] EncryptionKey, + prealm [1] Realm OPTIONAL, + pname [2] PrincipalName OPTIONAL, + flags [3] TicketFlags OPTIONAL, + authtime [4] KerberosTime OPTIONAL, + starttime [5] KerberosTime OPTIONAL, + endtime [6] KerberosTime OPTIONAL, + renew-till [7] KerberosTime OPTIONAL, + srealm [8] Realm OPTIONAL, + sname [9] PrincipalName OPTIONAL, + caddr [10] HostAddresses OPTIONAL + } + + + + + + + + + +Yu Expires: Mar 2005 [Page 97] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + TGT-REQ ::= [APPLICATION 16] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (16), + sname [2] PrincipalName OPTIONAL, + srealm [3] Realm OPTIONAL, + ... + } + + + -- + -- *** Error messages + -- + + + ErrCode ::= Int32 + + KRB-ERROR ::= CHOICE { + rfc1510 [APPLICATION 30] KRB-ERROR-1510, + ext [APPLICATION 23] Signed { + KRB-ERROR-EXT, { ku-KrbError-cksum } } + } + + + KRB-ERROR-COMMON ::= SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (30 | 23), + ctime [2] KerberosTime OPTIONAL, + cusec [3] Microseconds OPTIONAL, + stime [4] KerberosTime, + susec [5] Microseconds, + error-code [6] ErrCode, + crealm [7] Realm OPTIONAL, + cname [8] PrincipalName OPTIONAL, + realm [9] Realm -- Correct realm --, + sname [10] PrincipalName -- Correct name --, + e-text [11] KerberosString OPTIONAL, + e-data [12] OCTET STRING OPTIONAL, + ..., + typed-data [13] TYPED-DATA OPTIONAL, + nonce [14] Nonce OPTIONAL, + lang-tag [15] LangTag OPTIONAL, + ... + } + + + + + + + + + +Yu Expires: Mar 2005 [Page 98] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + 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 + + + TDType ::= TH-id + + TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { + data-type [0] TDType, + data-value [1] OCTET STRING OPTIONAL + } + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Yu Expires: Mar 2005 [Page 99] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + -- + -- *** Error codes + -- + + -- No error + kdc-err-none ErrCode ::= 0 + -- Client's entry in database has expired + kdc-err-name-exp ErrCode ::= 1 + -- Server's entry in database has expired + kdc-err-service-exp ErrCode ::= 2 + -- Requested protocol version number not supported + kdc-err-bad-pvno ErrCode ::= 3 + -- Client's key encrypted in old master key + kdc-err-c-old-mast-kvno ErrCode ::= 4 + -- Server's key encrypted in old master key + kdc-err-s-old-mast-kvno ErrCode ::= 5 + -- Client not found in Kerberos database + kdc-err-c-principal-unknown ErrCode ::= 6 + -- Server not found in Kerberos database + kdc-err-s-principal-unknown ErrCode ::= 7 + -- Multiple principal entries in database + kdc-err-principal-not-unique ErrCode ::= 8 + -- The client or server has a null key + kdc-err-null-key ErrCode ::= 9 + -- Ticket not eligible for postdating + kdc-err-cannot-postdate ErrCode ::= 10 + -- Requested start time is later than end time + kdc-err-never-valid ErrCode ::= 11 + -- KDC policy rejects request + kdc-err-policy ErrCode ::= 12 + -- KDC cannot accommodate requested option + kdc-err-badoption ErrCode ::= 13 + -- KDC has no support for encryption type + kdc-err-etype-nosupp ErrCode ::= 14 + -- KDC has no support for checksum type + kdc-err-sumtype-nosupp ErrCode ::= 15 + -- KDC has no support for padata type + kdc-err-padata-type-nosupp ErrCode ::= 16 + -- KDC has no support for transited type + kdc-err-trtype-nosupp ErrCode ::= 17 + -- Clients credentials have been revoked + kdc-err-client-revoked ErrCode ::= 18 + -- Credentials for server have been revoked + kdc-err-service-revoked ErrCode ::= 19 + -- TGT has been revoked + kdc-err-tgt-revoked ErrCode ::= 20 + + + + + + +Yu Expires: Mar 2005 [Page 100] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + -- Client not yet valid - try again later + kdc-err-client-notyet ErrCode ::= 21 + -- Server not yet valid - try again later + kdc-err-service-notyet ErrCode ::= 22 + -- Password has expired - change password to reset + kdc-err-key-expired ErrCode ::= 23 + -- Pre-authentication information was invalid + kdc-err-preauth-failed ErrCode ::= 24 + -- Additional pre-authenticationrequired + kdc-err-preauth-required ErrCode ::= 25 + -- Requested server and ticket don't match + kdc-err-server-nomatch ErrCode ::= 26 + -- Server principal valid for user2user only + kdc-err-must-use-user2user ErrCode ::= 27 + -- KDC Policy rejects transited path + kdc-err-path-not-accpeted ErrCode ::= 28 + -- A service is not available + kdc-err-svc-unavailable ErrCode ::= 29 + -- Integrity check on decrypted field failed + krb-ap-err-bad-integrity ErrCode ::= 31 + -- Ticket expired + krb-ap-err-tkt-expired ErrCode ::= 32 + -- Ticket not yet valid + krb-ap-err-tkt-nyv ErrCode ::= 33 + -- Request is a replay + krb-ap-err-repeat ErrCode ::= 34 + -- The ticket isn't for us + krb-ap-err-not-us ErrCode ::= 35 + -- Ticket and authenticator don't match + krb-ap-err-badmatch ErrCode ::= 36 + -- Clock skew too great + krb-ap-err-skew ErrCode ::= 37 + -- Incorrect net address + krb-ap-err-badaddr ErrCode ::= 38 + -- Protocol version mismatch + krb-ap-err-badversion ErrCode ::= 39 + -- Invalid msg type + krb-ap-err-msg-type ErrCode ::= 40 + + + + + + + + + + + + + + +Yu Expires: Mar 2005 [Page 101] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + -- Message stream modified + krb-ap-err-modified ErrCode ::= 41 + -- Message out of order + krb-ap-err-badorder ErrCode ::= 42 + -- Specified version of key is not available + krb-ap-err-badkeyver ErrCode ::= 44 + -- Service key not available + krb-ap-err-nokey ErrCode ::= 45 + -- Mutual authentication failed + krb-ap-err-mut-fail ErrCode ::= 46 + -- Incorrect message direction + krb-ap-err-baddirection ErrCode ::= 47 + -- Alternative authentication method required + krb-ap-err-method ErrCode ::= 48 + -- Incorrect sequence number in message + krb-ap-err-badseq ErrCode ::= 49 + -- Inappropriate type of checksum in message + krb-ap-err-inapp-cksum ErrCode ::= 50 + -- Policy rejects transited path + krb-ap-path-not-accepted ErrCode ::= 51 + -- Response too big for UDP, retry with TCP + krb-err-response-too-big ErrCode ::= 52 + -- Generic error (description in e-text) + krb-err-generic ErrCode ::= 60 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Yu Expires: Mar 2005 [Page 102] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + -- Field is too long for this implementation + krb-err-field-toolong ErrCode ::= 61 + -- Reserved for PKINIT + kdc-error-client-not-trusted ErrCode ::= 62 + -- Reserved for PKINIT + kdc-error-kdc-not-trusted ErrCode ::= 63 + -- Reserved for PKINIT + kdc-error-invalid-sig ErrCode ::= 64 + -- Reserved for PKINIT + kdc-err-key-too-weak ErrCode ::= 65 + -- Reserved for PKINIT + kdc-err-certificate-mismatch ErrCode ::= 66 + -- No TGT available to validate USER-TO-USER + krb-ap-err-no-tgt ErrCode ::= 67 + -- USER-TO-USER TGT issued different KDC + kdc-err-wrong-realm ErrCode ::= 68 + -- Ticket must be for USER-TO-USER + krb-ap-err-user-to-user-required ErrCode ::= 69 + -- Reserved for PKINIT + kdc-err-cant-verify-certificate ErrCode ::= 70 + -- Reserved for PKINIT + kdc-err-invalid-certificate ErrCode ::= 71 + -- Reserved for PKINIT + kdc-err-revoked-certificate ErrCode ::= 72 + -- Reserved for PKINIT + kdc-err-revocation-status-unknown ErrCode ::= 73 + -- Reserved for PKINIT + kdc-err-revocation-status-unavailable ErrCode ::= 74 + + + END + + +B. Kerberos and Character Encodings (Informative) + + [adapted from KCLAR 5.2.1] + + The original specification of the Kerberos protocol in RFC 1510 uses + GeneralString in numerous places for human-readable string data. + Historical implementations of Kerberos cannot utilize the full power + of GeneralString. This ASN.1 type requires the use of designation + and invocation escape sequences as specified in ISO 2022 | ECMA-35 + [ISO2022] to switch character sets, and the default character set + that is designated as G0 is the ISO 646 | ECMA-6 [ISO646] + International Reference Version (IRV) (aka U.S. ASCII), which mostly + works. + + ISO 2022 | ECMA-35 defines four character-set code elements (G0..G3) + and two Control-function code elements (C0..C1). DER previously + [X690-1997] prohibited the designation of character sets as any but + the G0 and C0 sets. This had the side effect of prohibiting the use + +Yu Expires: Mar 2005 [Page 103] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + of (ISO Latin) character-sets such as ISO 8859-1 [ISO8859-1] or any + other character-sets that utilize a 96-character set, since it is + prohibited by ISO 2022 | ECMA-35 to designate them as the G0 code + element. Recent revisions to the ASN.1 standards resolve this + contradiction. + + In practice, many implementations treat RFC 1510 GeneralStrings as if + they were 8-bit strings of whichever character set the implementation + defaults to, without regard for correct usage of character-set + designation escape sequences. The default character set is often + determined by the current user's operating system dependent locale. + At least one major implementation places unescaped UTF-8 encoded + Unicode characters in the GeneralString. This failure to conform to + the GeneralString specifications results in interoperability issues + when conflicting character encodings are utilized by the Kerberos + clients, services, and KDC. + + This unfortunate situation is the result of improper documentation of + the restrictions of the ASN.1 GeneralString type in prior Kerberos + specifications. + + [the following should probably be rewritten and moved into the + principal name section] + + For compatibility, implementations MAY choose to accept GeneralString + values that contain characters other than those permitted by + IA5String, but they should be aware that character set designation + codes will likely be absent, and that the encoding should probably be + treated as locale-specific in almost every way. Implementations MAY + also choose to emit GeneralString values that are beyond those + permitted by IA5String, but should be aware that doing so is + extraordinarily risky from an interoperability perspective. + + Some existing implementations use GeneralString to encode unescaped + locale-specific characters. This is a violation of the ASN.1 + standard. Most of these implementations encode US-ASCII in the left- + hand half, so as long the implementation transmits only US-ASCII, the + ASN.1 standard is not violated in this regard. As soon as such an + implementation encodes unescaped locale-specific characters with the + high bit set, it violates the ASN.1 standard. + + Other implementations have been known to use GeneralString to contain + a UTF-8 encoding. This also violates the ASN.1 standard, since UTF-8 + is a different encoding, not a 94 or 96 character "G" set as defined + by ISO 2022. It is believed that these implementations do not even + use the ISO 2022 escape sequence to change the character encoding. + Even if implementations were to announce the change of encoding by + using that escape sequence, the ASN.1 standard prohibits the use of + any escape sequences other than those used to designate/invoke "G" or + "C" sets allowed by GeneralString. + + +Yu Expires: Mar 2005 [Page 104] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + +C. Kerberos History (Informative) + + [Adapted from KCLAR "BACKGROUND"] + + The Kerberos model is based in part on Needham and Schroeder's + trusted third-party authentication protocol [NS78] and on + modifications suggested by Denning and Sacco [DS81]. The original + design and implementation of Kerberos Versions 1 through 4 was the + work of two former Project Athena staff members, Steve Miller of + Digital Equipment Corporation and Clifford Neuman (now at the + Information Sciences Institute of the University of Southern + California), along with Jerome Saltzer, Technical Director of Project + Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other + members of Project Athena have also contributed to the work on + Kerberos. + + Version 5 of the Kerberos protocol (described in this document) has + evolved from Version 4 based on new requirements and desires for + features not available in Version 4. The design of Version 5 of the + Kerberos protocol was led by Clifford Neuman and John Kohl with much + input from the community. The development of the MIT reference + implementation was led at MIT by John Kohl and Theodore Ts'o, with + help and contributed code from many others. Since RFC1510 was + issued, extensions and revisions to the protocol have been proposed + by many individuals. Some of these proposals are reflected in this + document. Where such changes involved significant effort, the + document cites the contribution of the proposer. + + Reference implementations of both version 4 and version 5 of Kerberos + are publicly available and commercial implementations have been + developed and are widely used. Details on the differences between + Kerberos Versions 4 and 5 can be found in [KNT94]. + +D. Notational Differences from [KCLAR] + + [ possible point for discussion ] + + [KCLAR] uses notational conventions slightly different from this + document. As a derivative of RFC 1510, the text of [KCLAR] uses C- + language style identifier names for defined values. In ASN.1 + notation, identifiers referencing defined values must begin with a + lowercase letter and contain hyphen (-) characters rather than + underscore (_) characters, while identifiers referencing types begin + with an uppercase letter. [KCLAR] and RFC 1510 use all-uppercase + identifiers with underscores to identify defined values. This has + the potential to create confusion, but neither document defines + values using actual ASN.1 value-assignment notation. + + It is debatable whether it is advantageous to write all identifier + names (regardless of their ASN.1 token type) in all-uppercase letters + for the purpose of emphasis in running text. The alternative is to + +Yu Expires: Mar 2005 [Page 105] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + use double-quote characters (") when ambiguity is possible. + +Normative References + + [ISO646] + "7-bit coded character set", ISO/IEC 646:1991 | ECMA-6:1991. + + [ISO2022] + "Information technology -- Character code structure and + extension techniques", ISO/IEC 2022:1994 | ECMA-35:1994. + + [KCRYPTO] + K. Raeburn, "Encryption and Checksum Specifications for Kerberos + 5", draft-ietf-krb-wg-crypto-07.txt, work in progress. + + [RFC2119] + S. Bradner, RFC2119: "Key words for use in RFC's to Indicate + Requirement Levels", March 1997. + + [RFC3660] + H. Alvestrand, "Tags for the Identification of Languages", + RFC 3660, January 2001. + + [SASLPREP] + Kurt D. Zeilenga, "SASLprep: Stringprep profile for user names + and passwords", draft-ietf-sasl-saslprep-10.txt, work in + progress. + + [X680] + "Information technology -- Abstract Syntax Notation One (ASN.1): + Specification of basic notation", ITU-T Recommendation X.680 + (2002) | ISO/IEC 8824-1:2002. + + [X682] + "Information technology -- Abstract Syntax Notation One (ASN.1): + Constraint specification", ITU-T Recommendation X.682 (2002) | + ISO/IEC 8824-3:2002. + + [X683] + "Information technology -- Abstract Syntax Notation One (ASN.1): + Parameterization of ASN.1 specifications", ITU-T Recommendation + X.683 (2002) | ISO/IEC 8824-4:2002. + + [X690] + "Information technology -- ASN.1 encoding Rules: Specification + of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) + and Distinguished Encoding Rules (DER)", ITU-T Recommendation + X.690 (2002) | ISO/IEC 8825-1:2002. + + + + +Yu Expires: Mar 2005 [Page 106] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + +Informative References + + [DS81] + Dorothy E. Denning and Giovanni Maria Sacco, "Time-stamps in Key + Distribution Protocols," Communications of the ACM, Vol. 24(8), + pp. 533-536 (August 1981). + + [Dub00] + Olivier Dubuisson, "ASN.1 - Communication between Heterogeneous + Systems", Elsevier-Morgan Kaufmann, 2000. + <http://www.oss.com/asn1/dubuisson.html> + + [ISO8859-1] + "Information technology -- 8-bit single-byte coded graphic + character sets -- Part 1: Latin alphabet No. 1", ISO/IEC 8859- + 1:1998. + + [KCLAR] + Clifford Neuman, Tom Yu, Sam Hartman, Ken Raeburn, "The Kerberos + Network Authentication Service (V5)", draft-ietf-krb-wg- + kerberos-clarifications-07.txt, work in progress. + + [KNT94] + John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The + Evolution of the Kerberos Authentication System". In + Distributed Open Systems, pages 78-94. IEEE Computer Society + Press, 1994. + + [Lar96] + John Larmouth, "Understanding OSI", International Thomson + Computer Press, 1996. + <http://www.isi.salford.ac.uk/books/osi.html> + + [Lar99] + John Larmouth, "ASN.1 Complete", Elsevier-Morgan Kaufmann, + 1999. <http://www.oss.com/asn1/larmouth.html> + + [NS78] + Roger M. Needham and Michael D. Schroeder, "Using Encryption for + Authentication in Large Networks of Computers", Communications + of the ACM, Vol. 21(12), pp. 993-999 (December, 1978). + + [RFC1510] + J. Kohl and B. C. Neuman, "The Kerberos Network Authentication + Service (v5)", RFC1510, September 1993, Status: Proposed + Standard. + + [RFC1964] + J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, + June 1996, Status: Proposed Standard. + + +Yu Expires: Mar 2005 [Page 107] + +Internet-Draft rfc1510ter-01 15 Sep 2005 + + [X690-2002] + "Information technology -- ASN.1 encoding rules: Specification + of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) + and Distinguished Encoding Rules (DER)", ITU-T Recommendation + X.690 (2002) | ISO/IEC 8825-1:2002. + +Author's Address + + Tom Yu + 77 Massachusetts Ave + Cambridge, MA 02139 + USA + tlyu@mit.edu + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Yu Expires: Mar 2005 [Page 108] + + |