diff options
Diffstat (limited to 'doc/rfc/rfc4120.txt')
| -rw-r--r-- | doc/rfc/rfc4120.txt | 7731 |
1 files changed, 7731 insertions, 0 deletions
diff --git a/doc/rfc/rfc4120.txt b/doc/rfc/rfc4120.txt new file mode 100644 index 0000000..e2816af --- /dev/null +++ b/doc/rfc/rfc4120.txt @@ -0,0 +1,7731 @@ + + + + + + +Network Working Group C. Neuman +Request for Comments: 4120 USC-ISI +Obsoletes: 1510 T. Yu +Category: Standards Track S. Hartman + K. Raeburn + MIT + July 2005 + + + The Kerberos Network Authentication Service (V5) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document provides an overview and specification of Version 5 of + the Kerberos protocol, and it obsoletes RFC 1510 to clarify aspects + of the protocol and its intended use that require more detailed or + clearer explanation than was provided in RFC 1510. This document is + intended to provide a detailed description of the protocol, suitable + for implementation, together with descriptions of the appropriate use + of protocol messages and fields within those messages. + + + + + + + + + + + + + + + + + + + +Neuman, et al. Standards Track [Page 1] + +RFC 4120 Kerberos V5 July 2005 + + +Table of Contents + + 1. Introduction ....................................................5 + 1.1. The Kerberos Protocol ......................................6 + 1.2. Cross-Realm Operation ......................................8 + 1.3. Choosing a Principal with Which to Communicate .............9 + 1.4. Authorization .............................................10 + 1.5. Extending Kerberos without Breaking Interoperability ......11 + 1.5.1. Compatibility with RFC 1510 ........................11 + 1.5.2. Sending Extensible Messages ........................12 + 1.6. Environmental Assumptions .................................12 + 1.7. Glossary of Terms .........................................13 + 2. Ticket Flag Uses and Requests ..................................16 + 2.1. Initial, Pre-authenticated, and + Hardware-Authenticated Tickets ............................17 + 2.2. Invalid Tickets ...........................................17 + 2.3. Renewable Tickets .........................................17 + 2.4. Postdated Tickets .........................................18 + 2.5. Proxiable and Proxy Tickets ...............................19 + 2.6. Forwardable Tickets .......................................19 + 2.7. Transited Policy Checking .................................20 + 2.8. OK as Delegate ............................................21 + 2.9. Other KDC Options .........................................21 + 2.9.1. Renewable-OK .......................................21 + 2.9.2. ENC-TKT-IN-SKEY ....................................22 + 2.9.3. Passwordless Hardware Authentication ...............22 + 3. Message Exchanges ..............................................22 + 3.1. The Authentication Service Exchange .......................22 + 3.1.1. Generation of KRB_AS_REQ Message ...................24 + 3.1.2. Receipt of KRB_AS_REQ Message ......................24 + 3.1.3. Generation of KRB_AS_REP Message ...................24 + 3.1.4. Generation of KRB_ERROR Message ....................27 + 3.1.5. Receipt of KRB_AS_REP Message ......................27 + 3.1.6. Receipt of KRB_ERROR Message .......................28 + 3.2. The Client/Server Authentication Exchange .................29 + 3.2.1. The KRB_AP_REQ Message .............................29 + 3.2.2. Generation of a KRB_AP_REQ Message .................29 + 3.2.3. Receipt of KRB_AP_REQ Message ......................30 + 3.2.4. Generation of a KRB_AP_REP Message .................33 + 3.2.5. Receipt of KRB_AP_REP Message ......................33 + 3.2.6. Using the Encryption Key ...........................33 + 3.3. The Ticket-Granting Service (TGS) Exchange ................34 + 3.3.1. Generation of KRB_TGS_REQ Message ..................35 + 3.3.2. Receipt of KRB_TGS_REQ Message .....................37 + 3.3.3. Generation of KRB_TGS_REP Message ..................38 + 3.3.4. Receipt of KRB_TGS_REP Message .....................42 + + + + + +Neuman, et al. Standards Track [Page 2] + +RFC 4120 Kerberos V5 July 2005 + + + 3.4. The KRB_SAFE Exchange .....................................42 + 3.4.1. Generation of a KRB_SAFE Message ...................42 + 3.4.2. Receipt of KRB_SAFE Message ........................43 + 3.5. The KRB_PRIV Exchange .....................................44 + 3.5.1. Generation of a KRB_PRIV Message ...................44 + 3.5.2. Receipt of KRB_PRIV Message ........................44 + 3.6. The KRB_CRED Exchange .....................................45 + 3.6.1. Generation of a KRB_CRED Message ...................45 + 3.6.2. Receipt of KRB_CRED Message ........................46 + 3.7. User-to-User Authentication Exchanges .....................47 + 4. Encryption and Checksum Specifications .........................48 + 5. Message Specifications .........................................50 + 5.1. Specific Compatibility Notes on ASN.1 .....................51 + 5.1.1. ASN.1 Distinguished Encoding Rules .................51 + 5.1.2. Optional Integer Fields ............................52 + 5.1.3. Empty SEQUENCE OF Types ............................52 + 5.1.4. Unrecognized Tag Numbers ...........................52 + 5.1.5. Tag Numbers Greater Than 30 ........................53 + 5.2. Basic Kerberos Types ......................................53 + 5.2.1. KerberosString .....................................53 + 5.2.2. Realm and PrincipalName ............................55 + 5.2.3. KerberosTime .......................................55 + 5.2.4. Constrained Integer Types ..........................55 + 5.2.5. HostAddress and HostAddresses ......................56 + 5.2.6. AuthorizationData ..................................57 + 5.2.7. PA-DATA ............................................60 + 5.2.8. KerberosFlags ......................................64 + 5.2.9. Cryptosystem-Related Types .........................65 + 5.3. Tickets ...................................................66 + 5.4. Specifications for the AS and TGS Exchanges ...............73 + 5.4.1. KRB_KDC_REQ Definition .............................73 + 5.4.2. KRB_KDC_REP Definition .............................81 + 5.5. Client/Server (CS) Message Specifications .................84 + 5.5.1. KRB_AP_REQ Definition ..............................84 + 5.5.2. KRB_AP_REP Definition ..............................88 + 5.5.3. Error Message Reply ................................89 + 5.6. KRB_SAFE Message Specification ............................89 + 5.6.1. KRB_SAFE definition ................................89 + 5.7. KRB_PRIV Message Specification ............................91 + 5.7.1. KRB_PRIV Definition ................................91 + 5.8. KRB_CRED Message Specification ............................92 + 5.8.1. KRB_CRED Definition ................................92 + 5.9. Error Message Specification ...............................94 + 5.9.1. KRB_ERROR Definition ...............................94 + 5.10. Application Tag Numbers ..................................96 + + + + + + +Neuman, et al. Standards Track [Page 3] + +RFC 4120 Kerberos V5 July 2005 + + + 6. Naming Constraints .............................................97 + 6.1. Realm Names ...............................................97 + 6.2. Principal Names .......................................... 99 + 6.2.1. Name of Server Principals .........................100 + 7. Constants and Other Defined Values ............................101 + 7.1. Host Address Types .......................................101 + 7.2. KDC Messaging: IP Transports .............................102 + 7.2.1. UDP/IP transport ..................................102 + 7.2.2. TCP/IP Transport ..................................103 + 7.2.3. KDC Discovery on IP Networks ......................104 + 7.3. Name of the TGS ..........................................105 + 7.4. OID Arc for KerberosV5 ...................................106 + 7.5. Protocol Constants and Associated Values .................106 + 7.5.1. Key Usage Numbers .................................106 + 7.5.2. PreAuthentication Data Types ......................108 + 7.5.3. Address Types .....................................109 + 7.5.4. Authorization Data Types ..........................109 + 7.5.5. Transited Encoding Types ..........................109 + 7.5.6. Protocol Version Number ...........................109 + 7.5.7. Kerberos Message Types ............................110 + 7.5.8. Name Types ........................................110 + 7.5.9. Error Codes .......................................110 + 8. Interoperability Requirements .................................113 + 8.1. Specification 2 ..........................................113 + 8.2. Recommended KDC Values ...................................116 + 9. IANA Considerations ...........................................116 + 10. Security Considerations ......................................117 + 11. Acknowledgements .............................................121 + A. ASN.1 Module ..................................................123 + B. Changes since RFC 1510 ........................................131 + Normative References .............................................134 + Informative References ...........................................135 + + + + + + + + + + + + + + + + + + + +Neuman, et al. Standards Track [Page 4] + +RFC 4120 Kerberos V5 July 2005 + + +1. Introduction + + This document describes the concepts and model upon which the + Kerberos network authentication system is based. It also specifies + Version 5 of the Kerberos protocol. The motivations, goals, + assumptions, and rationale behind most design decisions are treated + cursorily; they are more fully described in a paper available in IEEE + communications [NT94] and earlier in the Kerberos portion of the + Athena Technical Plan [MNSS87]. + + This document is not intended to describe Kerberos to the end user, + system administrator, or application developer. Higher-level papers + describing Version 5 of the Kerberos system [NT94] and documenting + version 4 [SNS88] are available elsewhere. + + 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 because of new requirements and desires for features not + available in Version 4. The design of Version 5 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 RFC 1510 was issued, many individuals have proposed + extensions and revisions to the protocol. This document reflects + some of these proposals. 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 + Versions 4 and 5 can be found in [KNT94]. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + + + + +Neuman, et al. Standards Track [Page 5] + +RFC 4120 Kerberos V5 July 2005 + + +1.1. The Kerberos Protocol + + Kerberos provides a means of verifying the identities of principals, + (e.g., a workstation user or a network server) on an open + (unprotected) network. This is accomplished without relying on + assertions by the host operating system, without basing trust on host + addresses, without requiring physical security of all the hosts on + the network, and under the assumption that packets traveling along + the network can be read, modified, and inserted at will. Kerberos + performs authentication under these conditions as a trusted third- + party authentication service by using conventional (shared secret + key) cryptography. Extensions to Kerberos (outside the scope of this + document) can provide for the use of public key cryptography during + certain phases of the authentication protocol. Such extensions + support Kerberos authentication for users registered with public key + certification authorities and provide certain benefits of public key + cryptography in situations where they are needed. + + The basic Kerberos authentication process proceeds as follows: A + client sends a request to the authentication server (AS) for + "credentials" for a given server. The AS responds with these + credentials, encrypted in the client's key. The credentials consist + of a "ticket" for the server and a temporary encryption key (often + called a "session key"). The client transmits the ticket (which + contains the client's identity and a copy of the session key, all + encrypted in the server's key) to the server. The session key (now + shared by the client and server) is used to authenticate the client + and may optionally be used to authenticate the server. It may also + be used to encrypt further communication between the two parties or + to exchange a separate sub-session key to be used to encrypt further + communication. Note that many applications use Kerberos' functions + only upon the initiation of a stream-based network connection. + Unless an application performs encryption or integrity protection for + the data stream, the identity verification applies only to the + initiation of the connection, and it does not guarantee that + subsequent messages on the connection originate from the same + principal. + + Implementation of the basic protocol consists of one or more + authentication servers running on physically secure hosts. The + authentication servers maintain a database of principals (i.e., users + and servers) and their secret keys. Code libraries provide + encryption and implement the Kerberos protocol. In order to add + authentication to its transactions, a typical network application + adds calls to the Kerberos library directly or through the Generic + Security Services Application Programming Interface (GSS-API) + described in a separate document [RFC4121]. These calls result in + the transmission of the messages necessary to achieve authentication. + + + +Neuman, et al. Standards Track [Page 6] + +RFC 4120 Kerberos V5 July 2005 + + + The Kerberos protocol consists of several sub-protocols (or + exchanges). There are two basic methods by which a client can ask a + Kerberos server for credentials. In the first approach, the client + sends a cleartext request for a ticket for the desired server to the + AS. The reply is sent encrypted in the client's secret key. Usually + this request is for a ticket-granting ticket (TGT), which can later + be used with the ticket-granting server (TGS). In the second method, + the client sends a request to the TGS. The client uses the TGT to + authenticate itself to the TGS in the same manner as if it were + contacting any other application server that requires Kerberos + authentication. The reply is encrypted in the session key from the + TGT. Though the protocol specification describes the AS and the TGS + as separate servers, in practice they are implemented as different + protocol entry points within a single Kerberos server. + + Once obtained, credentials may be used to verify the identity of the + principals in a transaction, to ensure the integrity of messages + exchanged between them, or to preserve privacy of the messages. The + application is free to choose whatever protection may be necessary. + + To verify the identities of the principals in a transaction, the + client transmits the ticket to the application server. Because the + ticket is sent "in the clear" (parts of it are encrypted, but this + encryption doesn't thwart replay) and might be intercepted and reused + by an attacker, additional information is sent to prove that the + message originated with the principal to whom the ticket was issued. + This information (called the authenticator) is encrypted in the + session key and includes a timestamp. The timestamp proves that the + message was recently generated and is not a replay. Encrypting the + authenticator in the session key proves that it was generated by a + party possessing the session key. Since no one except the requesting + principal and the server know the session key (it is never sent over + the network in the clear), this guarantees the identity of the + client. + + The integrity of the messages exchanged between principals can also + be guaranteed by using the session key (passed in the ticket and + contained in the credentials). This approach provides detection of + both replay attacks and message stream modification attacks. It is + accomplished by generating and transmitting a collision-proof + checksum (elsewhere called a hash or digest function) of the client's + message, keyed with the session key. Privacy and integrity of the + messages exchanged between principals can be secured by encrypting + the data to be passed by using the session key contained in the + ticket or the sub-session key found in the authenticator. + + + + + + +Neuman, et al. Standards Track [Page 7] + +RFC 4120 Kerberos V5 July 2005 + + + The authentication exchanges mentioned above require read-only access + to the Kerberos database. Sometimes, however, the entries in the + database must be modified, such as when adding new principals or + changing a principal's key. This is done using a protocol between a + client and a third Kerberos server, the Kerberos Administration + Server (KADM). There is also a protocol for maintaining multiple + copies of the Kerberos database. Neither of these protocols are + described in this document. + +1.2. Cross-Realm Operation + + The Kerberos protocol is designed to operate across organizational + boundaries. A client in one organization can be authenticated to a + server in another. Each organization wishing to run a Kerberos + server establishes its own "realm". The name of the realm in which a + client is registered is part of the client's name and can be used by + the end-service to decide whether to honor a request. + + By establishing "inter-realm" keys, the administrators of two realms + can allow a client authenticated in the local realm to prove its + identity to servers in other realms. The exchange of inter-realm + keys (a separate key may be used for each direction) registers the + ticket-granting service of each realm as a principal in the other + realm. A client is then able to obtain a TGT for the remote realm's + ticket-granting service from its local realm. When that TGT is used, + the remote ticket-granting service uses the inter-realm key (which + usually differs from its own normal TGS key) to decrypt the TGT; thus + it is certain that the ticket was issued by the client's own TGS. + Tickets issued by the remote ticket-granting service will indicate to + the end-service that the client was authenticated from another realm. + + Without cross-realm operation, and with appropriate permission, the + client can arrange registration of a separately-named principal in a + remote realm and engage in normal exchanges with that realm's + services. However, for even small numbers of clients this becomes + cumbersome, and more automatic methods as described here are + necessary. + + A realm is said to communicate with another realm if the two realms + share an inter-realm key, or if the local realm shares an inter-realm + key with an intermediate realm that communicates with the remote + realm. An authentication path is the sequence of intermediate realms + that are transited in communicating from one realm to another. + + Realms may be organized hierarchically. Each realm shares a key with + its parent and a different key with each child. If an inter-realm + key is not directly shared by two realms, the hierarchical + organization allows an authentication path to be easily constructed. + + + +Neuman, et al. Standards Track [Page 8] + +RFC 4120 Kerberos V5 July 2005 + + + If a hierarchical organization is not used, it may be necessary to + consult a database in order to construct an authentication path + between realms. + + Although realms are typically hierarchical, intermediate realms may + be bypassed to achieve cross-realm authentication through alternate + authentication paths. (These might be established to make + communication between two realms more efficient.) It is important + for the end-service to know which realms were transited when deciding + how much faith to place in the authentication process. To facilitate + this decision, a field in each ticket contains the names of the + realms that were involved in authenticating the client. + + The application server is ultimately responsible for accepting or + rejecting authentication and SHOULD check the transited field. The + application server may choose to rely on the Key Distribution Center + (KDC) for the application server's realm to check the transited + field. The application server's KDC will set the + TRANSITED-POLICY-CHECKED flag in this case. The KDCs for + intermediate realms may also check the transited field as they issue + TGTs for other realms, but they are encouraged not to do so. A + client may request that the KDCs not check the transited field by + setting the DISABLE-TRANSITED-CHECK flag. KDCs SHOULD honor this + flag. + +1.3. Choosing a Principal with Which to Communicate + + The Kerberos protocol provides the means for verifying (subject to + the assumptions in Section 1.6) that the entity with which one + communicates is the same entity that was registered with the KDC + using the claimed identity (principal name). It is still necessary + to determine whether that identity corresponds to the entity with + which one intends to communicate. + + When appropriate data has been exchanged in advance, the application + may perform this determination syntactically based on the application + protocol specification, information provided by the user, and + configuration files. For example, the server principal name + (including realm) for a telnet server might be derived from the + user-specified host name (from the telnet command line), the "host/" + prefix specified in the application protocol specification, and a + mapping to a Kerberos realm derived syntactically from the domain + part of the specified hostname and information from the local + Kerberos realms database. + + One can also rely on trusted third parties to make this + determination, but only when the data obtained from the third party + is suitably integrity-protected while resident on the third-party + + + +Neuman, et al. Standards Track [Page 9] + +RFC 4120 Kerberos V5 July 2005 + + + server and when transmitted. Thus, for example, one should not rely + on an unprotected DNS record to map a host alias to the primary name + of a server, accepting the primary name as the party that one intends + to contact, since an attacker can modify the mapping and impersonate + the party. + + Implementations of Kerberos and protocols based on Kerberos MUST NOT + use insecure DNS queries to canonicalize the hostname components of + the service principal names (i.e., they MUST NOT use insecure DNS + queries to map one name to another to determine the host part of the + principal name with which one is to communicate). In an environment + without secure name service, application authors MAY append a + statically configured domain name to unqualified hostnames before + passing the name to the security mechanisms, but they should do no + more than that. Secure name service facilities, if available, might + be trusted for hostname canonicalization, but such canonicalization + by the client SHOULD NOT be required by KDC implementations. + + Implementation note: Many current implementations do some degree of + canonicalization of the provided service name, often using DNS even + though it creates security problems. However, there is no + consistency among implementations as to whether the service name is + case folded to lowercase or whether reverse resolution is used. To + maximize interoperability and security, applications SHOULD provide + security mechanisms with names that result from folding the user- + entered name to lowercase without performing any other modifications + or canonicalization. + +1.4. Authorization + + As an authentication service, Kerberos provides a means of verifying + the identity of principals on a network. Authentication is usually + useful primarily as a first step in the process of authorization, + determining whether a client may use a service, which objects the + client is allowed to access, and the type of access allowed for each. + Kerberos does not, by itself, provide authorization. Possession of a + client ticket for a service provides only for authentication of the + client to that service, and in the absence of a separate + authorization procedure, an application should not consider it to + authorize the use of that service. + + Separate authorization methods MAY be implemented as application- + specific access control functions and may utilize files on the + application server, on separately issued authorization credentials + such as those based on proxies [Neu93], or on other authorization + services. Separately authenticated authorization credentials MAY be + embedded in a ticket's authorization data when encapsulated by the + KDC-issued authorization data element. + + + +Neuman, et al. Standards Track [Page 10] + +RFC 4120 Kerberos V5 July 2005 + + + Applications should not accept the mere issuance of a service ticket + by the Kerberos server (even by a modified Kerberos server) as + granting authority to use the service, since such applications may + become vulnerable to the bypass of this authorization check in an + environment where other options for application authentication are + provided, or if they interoperate with other KDCs. + +1.5. Extending Kerberos without Breaking Interoperability + + As the deployed base of Kerberos implementations grows, extending + Kerberos becomes more important. Unfortunately, some extensions to + the existing Kerberos protocol create interoperability issues because + of uncertainty regarding the treatment of certain extensibility + options by some implementations. This section includes guidelines + that will enable future implementations to maintain interoperability. + + Kerberos provides a general mechanism for protocol extensibility. + Some protocol messages contain typed holes -- sub-messages that + contain an octet-string along with an integer that defines how to + interpret the octet-string. The integer types are registered + centrally, but they can be used both for vendor extensions and for + extensions standardized through the IETF. + + In this document, the word "extension" refers to extension by + defining a new type to insert into an existing typed hole in a + protocol message. It does not refer to extension by addition of new + fields to ASN.1 types, unless the text explicitly indicates + otherwise. + +1.5.1. Compatibility with RFC 1510 + + Note that existing Kerberos message formats cannot readily be + extended by adding fields to the ASN.1 types. Sending additional + fields often results in the entire message being discarded without an + error indication. Future versions of this specification will provide + guidelines to ensure that ASN.1 fields can be added without creating + an interoperability problem. + + In the meantime, all new or modified implementations of Kerberos that + receive an unknown message extension SHOULD preserve the encoding of + the extension but otherwise ignore its presence. Recipients MUST NOT + decline a request simply because an extension is present. + + There is one exception to this rule. If an unknown authorization + data element type is received by a server other than the ticket- + granting service either in an AP-REQ or in a ticket contained in an + AP-REQ, then authentication MUST fail. One of the primary uses of + authorization data is to restrict the use of the ticket. If the + + + +Neuman, et al. Standards Track [Page 11] + +RFC 4120 Kerberos V5 July 2005 + + + service cannot determine whether the restriction applies to that + service, then a security weakness may result if the ticket can be + used for that service. Authorization elements that are optional + SHOULD be enclosed in the AD-IF-RELEVANT element. + + The ticket-granting service MUST ignore but propagate to derivative + tickets any unknown authorization data types, unless those data types + are embedded in a MANDATORY-FOR-KDC element, in which case the + request will be rejected. This behavior is appropriate because + requiring that the ticket-granting service understand unknown + authorization data types would require that KDC software be upgraded + to understand new application-level restrictions before applications + used these restrictions, decreasing the utility of authorization data + as a mechanism for restricting the use of tickets. No security + problem is created because services to which the tickets are issued + will verify the authorization data. + + Implementation note: Many RFC 1510 implementations ignore unknown + authorization data elements. Depending on these implementations to + honor authorization data restrictions may create a security weakness. + +1.5.2. Sending Extensible Messages + + Care must be taken to ensure that old implementations can understand + messages sent to them, even if they do not understand an extension + that is used. Unless the sender knows that an 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 implementations that do not interoperate is easier when + errors are returned. + +1.6. Environmental Assumptions + + Kerberos imposes a few assumptions on the environment in which it can + properly function, including the following: + + + +Neuman, et al. Standards Track [Page 12] + +RFC 4120 Kerberos V5 July 2005 + + + * "Denial of service" attacks are not solved with Kerberos. There + are places in the protocols where an intruder can prevent an + application from participating in the proper authentication steps. + Detection and solution of such attacks (some of which can appear + to be not-uncommon "normal" failure modes for the system) are + usually best left to the human administrators and users. + + * Principals MUST keep their secret keys secret. If an intruder + somehow steals a principal's key, it will be able to masquerade as + that principal or to impersonate any server to the legitimate + principal. + + * "Password guessing" attacks are not solved by Kerberos. If a user + chooses a poor password, it is possible for an attacker to + successfully mount an offline dictionary attack by repeatedly + attempting to decrypt, with successive entries from a dictionary, + messages obtained which are encrypted under a key derived from the + user's password. + + * Each host on the network MUST have a clock which is "loosely + synchronized" to the time of the other hosts; this synchronization + is used to reduce the bookkeeping needs of application servers + when they do replay detection. The degree of "looseness" can be + configured on a per-server basis, but it is typically on the order + of 5 minutes. If the clocks are synchronized over the network, + the clock synchronization protocol MUST itself be secured from + network attackers. + + * Principal identifiers are not recycled on a short-term basis. A + typical mode of access control will use access control lists + (ACLs) to grant permissions to particular principals. If a stale + ACL entry remains for a deleted principal and the principal + identifier is reused, the new principal will inherit rights + specified in the stale ACL entry. By not re-using principal + identifiers, the danger of inadvertent access is removed. + +1.7. Glossary of Terms + + Below is a list of terms used throughout this document. + + Authentication + Verifying the claimed identity of a principal. + + Authentication header + A record containing a Ticket and an Authenticator to be presented + to a server as part of the authentication process. + + + + + +Neuman, et al. Standards Track [Page 13] + +RFC 4120 Kerberos V5 July 2005 + + + Authentication path + A sequence of intermediate realms transited in the authentication + process when communicating from one realm to another. + + Authenticator + A record containing information that can be shown to have been + recently generated using the session key known only by the client + and server. + + Authorization + The process of determining whether a client may use a service, + which objects the client is allowed to access, and the type of + access allowed for each. + + Capability + A token that grants the bearer permission to access an object or + service. In Kerberos, this might be a ticket whose use is + restricted by the contents of the authorization data field, but + which lists no network addresses, together with the session key + necessary to use the ticket. + + Ciphertext + The output of an encryption function. Encryption transforms + plaintext into ciphertext. + + Client + A process that makes use of a network service on behalf of a user. + Note that in some cases a Server may itself be a client of some + other server (e.g., a print server may be a client of a file + server). + + Credentials + A ticket plus the secret session key necessary to use that ticket + successfully in an authentication exchange. + + Encryption Type (etype) + When associated with encrypted data, an encryption type identifies + the algorithm used to encrypt the data and is used to select the + appropriate algorithm for decrypting the data. Encryption type + tags are communicated in other messages to enumerate algorithms + that are desired, supported, preferred, or allowed to be used for + encryption of data between parties. This preference is combined + with local information and policy to select an algorithm to be + used. + + KDC + Key Distribution Center. A network service that supplies tickets + and temporary session keys; or an instance of that service or the + + + +Neuman, et al. Standards Track [Page 14] + +RFC 4120 Kerberos V5 July 2005 + + + host on which it runs. The KDC services both initial ticket and + ticket-granting ticket requests. The initial ticket portion is + sometimes referred to as the Authentication Server (or service). + The ticket-granting ticket portion is sometimes referred to as the + ticket-granting server (or service). + + Kerberos + The name given to the Project Athena's authentication service, the + protocol used by that service, or the code used to implement the + authentication service. The name is adopted from the three-headed + dog that guards Hades. + + Key Version Number (kvno) + A tag associated with encrypted data identifies which key was used + for encryption when a long-lived key associated with a principal + changes over time. It is used during the transition to a new key + so that the party decrypting a message can tell whether the data + was encrypted with the old or the new key. + + Plaintext + The input to an encryption function or the output of a decryption + function. Decryption transforms ciphertext into plaintext. + + Principal + A named client or server entity that participates in a network + communication, with one name that is considered canonical. + + Principal identifier + The canonical name used to identify each different principal + uniquely. + + Seal + To encipher a record containing several fields in such a way that + the fields cannot be individually replaced without knowledge of + the encryption key or leaving evidence of tampering. + + Secret key + An encryption key shared by a principal and the KDC, distributed + outside the bounds of the system, with a long lifetime. In the + case of a human user's principal, the secret key MAY be derived + from a password. + + Server + A particular Principal that provides a resource to network + clients. The server is sometimes referred to as the Application + Server. + + + + + +Neuman, et al. Standards Track [Page 15] + +RFC 4120 Kerberos V5 July 2005 + + + Service + A resource provided to network clients; often provided by more + than one server (for example, remote file service). + + Session key + A temporary encryption key used between two principals, with a + lifetime limited to the duration of a single login "session". In + the Kerberos system, a session key is generated by the KDC. The + session key is distinct from the sub-session key, described next. + + Sub-session key + A temporary encryption key used between two principals, selected + and exchanged by the principals using the session key, and with a + lifetime limited to the duration of a single association. The + sub-session key is also referred to as the subkey. + + Ticket + A record that helps a client authenticate itself to a server; it + contains the client's identity, a session key, a timestamp, and + other information, all sealed using the server's secret key. It + only serves to authenticate a client when presented along with a + fresh Authenticator. + +2. Ticket Flag Uses and Requests + + Each Kerberos ticket contains a set of flags that are used to + indicate attributes of that ticket. Most flags may be requested by a + client when the ticket is obtained; some are automatically turned on + and off by a Kerberos server as required. The following sections + explain what the various flags mean and give examples of reasons to + use them. With the exception of the INVALID flag, clients MUST + ignore ticket flags that are not recognized. KDCs MUST ignore KDC + options that are not recognized. Some implementations of RFC 1510 + are known to reject unknown KDC options, so clients may need to + resend a request without new KDC options if the request was rejected + when sent with options added since RFC 1510. Because new KDCs will + ignore unknown options, clients MUST confirm that the ticket returned + by the KDC meets their needs. + + Note that it is not, in general, possible to determine whether an + option was not honored because it was not understood or because it + was rejected through either configuration or policy. When adding a + new option to the Kerberos protocol, designers should consider + whether the distinction is important for their option. If it is, a + mechanism for the KDC to return an indication that the option was + understood but rejected needs to be provided in the specification of + the option. Often in such cases, the mechanism needs to be broad + enough to permit an error or reason to be returned. + + + +Neuman, et al. Standards Track [Page 16] + +RFC 4120 Kerberos V5 July 2005 + + +2.1. Initial, Pre-authenticated, and Hardware-Authenticated Tickets + + The INITIAL flag indicates that a ticket was issued using the AS + protocol, rather than issued based on a TGT. Application servers + that want to require the demonstrated knowledge of a client's secret + key (e.g., a password-changing program) can insist that this flag be + set in any tickets they accept, and can thus be assured that the + client's key was recently presented to the authentication server. + + The PRE-AUTHENT and HW-AUTHENT flags provide additional information + about the initial authentication, regardless of whether the current + ticket was issued directly (in which case INITIAL will also be set) + or issued on the basis of a TGT (in which case the INITIAL flag is + clear, but the PRE-AUTHENT and HW-AUTHENT flags are carried forward + from the TGT). + +2.2. Invalid Tickets + + The INVALID flag indicates that a ticket is invalid. Application + servers MUST reject tickets that have this flag set. A postdated + ticket will be issued in this form. Invalid tickets MUST be + validated by the KDC before use, by being presented 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 that have been stolen before their + starttime can be rendered permanently invalid (through a hot-list + mechanism) (see Section 3.3.3.1). + +2.3. Renewable Tickets + + Applications may desire to hold tickets that can be valid for long + periods of time. However, this can expose their 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 + periodically would require the client to have long-term access to its + secret key, an even greater risk. Renewable tickets can be used to + mitigate the consequences of theft. 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 + (i.e., before it expires) present a renewable ticket to the KDC, with + the RENEW option set 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 whether the ticket had been reported stolen since its + + + +Neuman, et al. Standards Track [Page 17] + +RFC 4120 Kerberos V5 July 2005 + + + last renewal; it will refuse to renew 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 (discussed below in Section 3.3). 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 reset by default, + but a client MAY request it be set by setting the RENEWABLE option in + the KRB_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. + +2.4. Postdated Tickets + + 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. + + The MAY-POSTDATE flag in a ticket is normally only interpreted by the + ticket-granting service. It can be ignored by application servers. + This flag MUST be set in a TGT in order to issue a postdated ticket + based on the presented ticket. It is reset by default; a client MAY + request it by setting the ALLOW-POSTDATE option in the KRB_AS_REQ + message. This flag does not allow a client to obtain a postdated + TGT; postdated TGTs can only be obtained by requesting the postdating + in the KRB_AS_REQ message. The life (endtime-starttime) of a + postdated ticket will be the remaining life of the TGT at the time of + the request, unless the RENEWABLE option is also set, in which case + it can be the full life (endtime-starttime) of the TGT. 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 + + + +Neuman, et al. Standards Track [Page 18] + +RFC 4120 Kerberos V5 July 2005 + + + the application client MUST present the ticket to the KDC to be + validated before use. + +2.5. Proxiable and Proxy Tickets + + At times 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 do this by granting it a proxy. + + The process of granting a proxy by 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 TGT. + + 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 TGT) with a 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 TGT, and that it be 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 are often valid only from those network addresses + specifically included in the ticket, but it is permissible as a + policy option to allow requests and to issue tickets with no network + addresses specified. 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. + +2.6. Forwardable Tickets + + Authentication forwarding is an instance of a proxy where the service + that is granted is complete use of the client's identity. An example + of where it might be used is when a user logs in to a remote system + + + +Neuman, et al. Standards Track [Page 19] + +RFC 4120 Kerberos V5 July 2005 + + + 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 TGTs 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 TGT. + + 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, specifies + 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. + +2.7. Transited Policy Checking + + In Kerberos, the application server is ultimately responsible for + accepting or rejecting authentication, and it SHOULD check that only + suitably trusted KDCs are relied upon to authenticate a principal. + The transited field in the ticket identifies which realms (and thus + which KDCs) were involved in the authentication process, and an + application server would normally check this field. If any of these + are untrusted to authenticate the indicated client principal + (probably determined by a realm-based policy), the authentication + attempt MUST be rejected. The presence of trusted KDCs in this list + does not provide any guarantee; an untrusted KDC may have fabricated + the list. + + Although the end server ultimately decides whether authentication is + valid, the KDC for the end server's realm MAY apply a realm-specific + policy for validating the transited field and accepting credentials + for cross-realm authentication. When the KDC applies such checks and + accepts such cross-realm authentication, it will set the + TRANSITED-POLICY-CHECKED flag in the service tickets it issues based + + + +Neuman, et al. Standards Track [Page 20] + +RFC 4120 Kerberos V5 July 2005 + + + on the cross-realm TGT. A client MAY request that the KDCs not check + the transited field by setting the DISABLE-TRANSITED-CHECK flag. + KDCs are encouraged but not required to honor this flag. + + Application servers MUST either do the transited-realm checks + themselves or reject cross-realm tickets without + TRANSITED-POLICY-CHECKED set. + +2.8. OK as Delegate + + For some applications, a client may need to delegate authority to a + server to act on its behalf in contacting other services. This + requires that the client forward credentials to an intermediate + server. The ability for a client to obtain a service ticket to a + server conveys no information to the client about whether the server + should be trusted to accept delegated credentials. The + OK-AS-DELEGATE provides a way for a KDC to communicate local realm + policy to a client regarding whether an intermediate server is + trusted to accept such credentials. + + The copy of the ticket flags in the encrypted part of the KDC reply + may have the OK-AS-DELEGATE flag set to indicate to the client that + the server specified in the ticket has been determined by the policy + of the realm to be a suitable recipient of delegation. A client can + use the presence of this flag to help it decide whether to delegate + credentials (grant either a proxy or a forwarded TGT) to this server. + 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. + +2.9. Other KDC Options + + There are three additional options that MAY be set in a client's + request of the KDC. + +2.9.1. Renewable-OK + + The RENEWABLE-OK option indicates that the client will accept a + renewable ticket if a ticket with the requested life cannot otherwise + be provided. If a ticket with the requested life cannot be provided, + then the KDC MAY issue a renewable ticket with a renew-till equal to + the requested endtime. The value of the renew-till field MAY still + be adjusted by site-determined limits or limits imposed by the + individual principal or server. + + + + + + +Neuman, et al. Standards Track [Page 21] + +RFC 4120 Kerberos V5 July 2005 + + +2.9.2. ENC-TKT-IN-SKEY + + In its basic form, the Kerberos protocol supports authentication in a + client-server setting and is not well suited to authentication in a + peer-to-peer environment because the long-term key of the user does + not remain on the workstation after initial login. Authentication of + such peers may be supported by Kerberos in its user-to-user variant. + The ENC-TKT-IN-SKEY option supports user-to-user authentication by + allowing the KDC to issue a service ticket encrypted using the + session key from another TGT issued to another user. The + ENC-TKT-IN-SKEY option is honored only by the ticket-granting + service. It indicates that the ticket to be issued for the end + server is to be encrypted in the session key from the additional + second TGT provided with the request. See Section 3.3.3 for specific + details. + +2.9.3. Passwordless Hardware Authentication + + The OPT-HARDWARE-AUTH option indicates that the client wishes to use + some form of hardware authentication instead of or in addition to the + client's password or other long-lived encryption key. + OPT-HARDWARE-AUTH is honored only by the authentication service. If + supported and allowed by policy, the KDC will return an error code of + KDC_ERR_PREAUTH_REQUIRED and include the required METHOD-DATA to + perform such authentication. + +3. Message Exchanges + + The following sections describe the interactions between network + clients and servers and the messages involved in those exchanges. + +3.1. The Authentication Service Exchange + + Summary + + Message direction Message type Section + 1. Client to Kerberos KRB_AS_REQ 5.4.1 + 2. Kerberos to client KRB_AS_REP or 5.4.2 + KRB_ERROR 5.9.1 + + The Authentication Service (AS) Exchange between the client and the + Kerberos Authentication Server is initiated by a client when it + wishes to obtain authentication credentials for a given server but + currently holds no credentials. In its basic form, the client's + secret key is used for encryption and decryption. This exchange is + typically used at the initiation of a login session to obtain + credentials for a Ticket-Granting Server, which will subsequently be + used to obtain credentials for other servers (see Section 3.3) + + + +Neuman, et al. Standards Track [Page 22] + +RFC 4120 Kerberos V5 July 2005 + + + without requiring further use of the client's secret key. This + exchange is also used to request credentials for services that must + not be mediated through the Ticket-Granting Service, but rather + require knowledge of a principal's secret key, such as the password- + changing service (the password-changing service denies requests + unless the requester can demonstrate knowledge of the user's old + password; requiring this knowledge prevents unauthorized password + changes by someone walking up to an unattended session). + + This exchange does not by itself provide any assurance of the + identity of the user. To authenticate a user logging on to a local + system, the credentials obtained in the AS exchange may first be used + in a TGS exchange to obtain credentials for a local server; those + credentials must then be verified by a local server through + successful completion of the Client/Server exchange. + + The AS exchange consists of two messages: KRB_AS_REQ from the client + to Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for + these messages are described in Sections 5.4.1, 5.4.2, and 5.9.1. + + In the request, the client sends (in cleartext) its own identity and + the identity of the server for which it is requesting credentials, + other information about the credentials it is requesting, and a + randomly generated nonce, which can be used to detect replays and to + associate replies with the matching requests. This nonce MUST be + generated randomly by the client and remembered for checking against + the nonce in the expected reply. The response, KRB_AS_REP, contains + a ticket for the client to present to the server, and a session key + that will be shared by the client and the server. The session key + and additional information are encrypted in the client's secret key. + The encrypted part of the KRB_AS_REP message also contains the nonce + that MUST be matched with the nonce from the KRB_AS_REQ message. + + Without pre-authentication, the authentication server does not know + whether the client is actually the principal named in the request. + It simply sends a reply without knowing or caring whether they are + the same. This is acceptable because nobody but the principal whose + identity was given in the request will be able to use the reply. Its + critical information is encrypted in that principal's key. However, + an attacker can send a KRB_AS_REQ message to get known plaintext in + order to attack the principal's key. Especially if the key is based + on a password, this may create a security exposure. So the initial + request supports an optional field that can be used to pass + additional information that might be needed for the initial exchange. + This field SHOULD be used for pre-authentication as described in + sections 3.1.1 and 5.2.7. + + + + + +Neuman, et al. Standards Track [Page 23] + +RFC 4120 Kerberos V5 July 2005 + + + Various errors can occur; these are indicated by an error response + (KRB_ERROR) instead of the KRB_AS_REP response. The error message is + not encrypted. The KRB_ERROR message contains information that can + be used to associate it with the message to which it replies. The + contents of the KRB_ERROR message are not integrity-protected. As + such, the client cannot detect replays, fabrications, or + modifications. A solution to this problem will be included in a + future version of the protocol. + +3.1.1. Generation of KRB_AS_REQ Message + + The client may specify a number of options in the initial request. + Among these options are whether pre-authentication is to be + performed; whether the requested ticket is to be renewable, + proxiable, or forwardable; whether it should be postdated or allow + postdating of derivative tickets; and whether a renewable ticket will + be accepted in lieu of a non-renewable ticket if the requested ticket + expiration date cannot be satisfied by a non-renewable ticket (due to + configuration constraints). + + The client prepares the KRB_AS_REQ message and sends it to the KDC. + +3.1.2. Receipt of KRB_AS_REQ Message + + If all goes well, processing the KRB_AS_REQ message will result in + the creation of a ticket for the client to present to the server. + The format for the ticket is described in Section 5.3. + + 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 + processed successfully, the KDC MUST respond with a KRB_AS_REP + message rather than a replay error. In order to reduce 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. + +3.1.3. Generation of KRB_AS_REP Message + + The authentication server looks up the client and server principals + named in the KRB_AS_REQ in its database, extracting their respective + keys. If the requested client principal named in the request is + unknown because it doesn't exist in the KDC's principal database, + then an error message with a KDC_ERR_C_PRINCIPAL_UNKNOWN is returned. + + If required to do so, the server pre-authenticates the request, and + if the pre-authentication check fails, an error message with the code + KDC_ERR_PREAUTH_FAILED is returned. If pre-authentication is + + + +Neuman, et al. Standards Track [Page 24] + +RFC 4120 Kerberos V5 July 2005 + + + required, but was not present in the request, an error message with + the code KDC_ERR_PREAUTH_REQUIRED is returned, and a METHOD-DATA + object will be stored in the e-data field of the KRB-ERROR message to + specify which pre-authentication mechanisms are acceptable. Usually + this will include PA-ETYPE-INFO and/or PA-ETYPE-INFO2 elements as + described below. If the server cannot accommodate any encryption + type requested by the client, an error message with code + KDC_ERR_ETYPE_NOSUPP is returned. Otherwise, the KDC generates a + 'random' session key, meaning that, among other things, it should be + impossible to guess the next session key based on knowledge of past + session keys. Although this can be achieved in a pseudo-random + number generator if it is based on cryptographic principles, it is + more desirable to use a truly random number generator, such as one + based on measurements of random physical phenomena. See [RFC4086] + for an in-depth discussion of randomness. + + In response to an AS request, if there are multiple encryption keys + registered for a client in the Kerberos database, then the etype + field from the AS request is used by the KDC to select the encryption + method to be used to protect the encrypted part of the KRB_AS_REP + message that is sent to the client. If there is more than one + supported strong encryption type in the etype list, the KDC SHOULD + use the first valid strong etype for which an encryption key is + available. + + When the user's key is generated from a password or pass phrase, the + string-to-key function for the particular encryption key type is + used, as specified in [RFC3961]. The salt value and additional + parameters for the string-to-key function have default values + (specified by Section 4 and by the encryption mechanism + specification, respectively) that may be overridden by + pre-authentication data (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO, + PA-ETYPE-INFO2, etc). Since the KDC is presumed to store a copy of + the resulting key only, these values should not be changed for + password-based keys except when changing the principal's key. + + When the AS server is to include pre-authentication data in a + KRB-ERROR or in an AS-REP, it MUST use PA-ETYPE-INFO2, not PA-ETYPE- + INFO, if the etype field of the client's AS-REQ lists at least one + "newer" encryption type. Otherwise (when the etype field of the + client's AS-REQ does not list any "newer" encryption types), it MUST + send both PA-ETYPE-INFO2 and PA-ETYPE-INFO (both with an entry for + each enctype). A "newer" enctype is any enctype first officially + specified concurrently with or subsequent to the issue of this RFC. + The enctypes DES, 3DES, or RC4 and any defined in [RFC1510] are not + "newer" enctypes. + + + + + +Neuman, et al. Standards Track [Page 25] + +RFC 4120 Kerberos V5 July 2005 + + + It is not possible to generate a user's key reliably given a pass + phrase without contacting the KDC, since it will not be known whether + alternate salt or parameter values are required. + + The KDC will attempt to assign the type of the random session key + from the list of methods in the etype field. The KDC will select the + appropriate type using the list of methods provided and information + from the Kerberos database indicating acceptable encryption methods + for the application server. The KDC will not issue tickets with a + weak session key encryption type. + + If the requested starttime is absent, indicates a time in the past, + or is within the window of acceptable clock skew for the KDC and the + POSTDATE option has not been specified, then the starttime of the + ticket is set to the authentication server's current time. If it + indicates a time in the future beyond the acceptable clock skew, but + the POSTDATED option has not been specified, then the error + KDC_ERR_CANNOT_POSTDATE is returned. Otherwise the requested + starttime is checked against the policy of the local realm (the + administrator might decide to prohibit certain types or ranges of + postdated tickets), and if the ticket's starttime is acceptable, it + is set as requested, and the INVALID flag is set in the new ticket. + The postdated ticket MUST be validated before use by presenting it to + the KDC after the starttime has been reached. + + The expiration time of the ticket will be set to the earlier of the + requested endtime and a time determined by local policy, possibly by + using realm- or principal-specific factors. For example, the + expiration time MAY be set to the earliest of the following: + + * The expiration time (endtime) requested in the KRB_AS_REQ + message. + + * The ticket's starttime plus the maximum allowable lifetime + associated with the client principal from the authentication + server's database. + + * The ticket's starttime plus the maximum allowable lifetime + associated with the server principal. + + * The ticket's starttime plus the maximum lifetime set by the + policy of the local realm. + + If the requested expiration time minus the starttime (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' + + + +Neuman, et al. Standards Track [Page 26] + +RFC 4120 Kerberos V5 July 2005 + + + flag is set in the new ticket, and the renew-till value is set as if + the 'RENEWABLE' option were requested (the field and option names are + described fully in Section 5.4.1). + + 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 starttime of the ticket plus the minimum of the two maximum + renewable lifetimes associated with the principals' database + entries. + + * The starttime of the ticket plus the maximum renewable lifetime + set by the policy of the local realm. + + The flags field of the new ticket will have the following options set + if they have been requested and if the policy of the local realm + allows: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. + If the new ticket is postdated (the starttime is in the future), its + INVALID flag will also be set. + + If all of the above succeed, the server will encrypt the ciphertext + part of the ticket using the encryption key extracted from the server + principal's record in the Kerberos database using the encryption type + associated with the server principal's key. (This choice is NOT + affected by the etype field in the request.) It then formats a + KRB_AS_REP message (see Section 5.4.2), copying the addresses in the + request into the caddr of the response, placing any required pre- + authentication data into the padata of the response, and encrypts the + ciphertext part in the client's key using an acceptable encryption + method requested in the etype field of the request, or in some key + specified by pre-authentication mechanisms being used. + +3.1.4. Generation of KRB_ERROR Message + + Several errors can occur, and the Authentication Server responds by + returning an error message, KRB_ERROR, to the client, with the + error-code and e-text fields set to appropriate values. The error + message contents and details are described in Section 5.9.1. + +3.1.5. Receipt of KRB_AS_REP Message + + If the reply message type is KRB_AS_REP, then the client verifies + that the cname and crealm fields in the cleartext portion of the + reply match what it requested. If any padata fields are present, + they may be used to derive the proper secret key to decrypt the + + + +Neuman, et al. Standards Track [Page 27] + +RFC 4120 Kerberos V5 July 2005 + + + message. The client decrypts the encrypted part of the response + using its secret key and verifies that the nonce in the encrypted + part matches the nonce it supplied in its request (to detect + replays). It also verifies that the sname and srealm in the response + match those in the request (or are otherwise expected values), and + that the host address field is also correct. It then stores the + ticket, session key, start and expiration times, and other + information for later use. The last-req field (and the deprecated + key-expiration field) from the encrypted part of the response MAY be + checked to notify the user of impending key expiration. This enables + the client program to suggest remedial action, such as a password + change. + + Upon validation of the KRB_AS_REP message (by checking the returned + nonce against that sent in the KRB_AS_REQ message), the client knows + that the current time on the KDC is that read from the authtime field + of the encrypted part of the reply. The client can optionally use + this value for clock synchronization in subsequent messages by + recording with the ticket the difference (offset) between the + authtime value and the local clock. This offset can then be used by + the same user to adjust the time read from the system clock when + generating messages [DGT96]. + + This technique MUST be used when adjusting for clock skew instead of + directly changing the system clock, because the KDC reply is only + authenticated to the user whose secret key was used, but not to the + system or workstation. If the clock were adjusted, an attacker + colluding with a user logging into a workstation could agree on a + password, resulting in a KDC reply that would be correctly validated + even though it did not originate from a KDC trusted by the + workstation. + + Proper decryption of the KRB_AS_REP message is not sufficient for the + host to verify the identity of the user; the user and an attacker + could cooperate to generate a KRB_AS_REP format message that decrypts + properly but is not from the proper KDC. If the host wishes to + verify the identity of the user, it MUST require the user to present + application credentials that can be verified using a securely-stored + secret key for the host. If those credentials can be verified, then + the identity of the user can be assured. + +3.1.6. Receipt of KRB_ERROR Message + + If the reply message type is KRB_ERROR, then the client interprets it + as an error and performs whatever application-specific tasks are + necessary for recovery. + + + + + +Neuman, et al. Standards Track [Page 28] + +RFC 4120 Kerberos V5 July 2005 + + +3.2. The Client/Server Authentication Exchange + + Summary + + Message direction Message type Section + Client to Application server KRB_AP_REQ 5.5.1 + [optional] Application server to client KRB_AP_REP or 5.5.2 + KRB_ERROR 5.9.1 + + The client/server authentication (CS) exchange is used by network + applications to authenticate the client to the server and vice versa. + The client MUST have already acquired credentials for the server + using the AS or TGS exchange. + +3.2.1. The KRB_AP_REQ Message + + The KRB_AP_REQ contains authentication information that SHOULD be + part of the first message in an authenticated transaction. It + contains a ticket, an authenticator, and some additional bookkeeping + information (see Section 5.5.1 for the exact format). The ticket by + itself is insufficient to authenticate a client, since tickets are + passed across the network in cleartext (tickets contain both an + encrypted and unencrypted portion, so cleartext here refers to the + entire unit, which can be copied from one message and replayed in + another without any cryptographic skill). The authenticator is used + to prevent invalid replay of tickets by proving to the server that + the client knows the session key of the ticket and thus is entitled + to use the ticket. The KRB_AP_REQ message is referred to elsewhere + as the 'authentication header'. + +3.2.2. Generation of a KRB_AP_REQ Message + + When a client wishes to initiate authentication to a server, it + obtains (either through a credentials cache, the AS exchange, or the + TGS exchange) a ticket and session key for the desired service. The + client MAY re-use any tickets it holds until they expire. To use a + ticket, the client constructs a new Authenticator from the system + time and its name, and optionally from an application-specific + checksum, an initial sequence number to be used in KRB_SAFE or + KRB_PRIV messages, and/or a session subkey to be used in negotiations + for a session key unique to this particular session. Authenticators + MUST NOT be re-used and SHOULD be rejected if replayed to a server. + Note that this can make applications based on unreliable transports + difficult to code correctly. If the transport might deliver + duplicated messages, either a new authenticator MUST be generated for + each retry, or the application server MUST match requests and replies + and replay the first reply in response to a detected duplicate. + + + + +Neuman, et al. Standards Track [Page 29] + +RFC 4120 Kerberos V5 July 2005 + + + If a sequence number is to be included, it SHOULD be randomly chosen + so that even after many messages have been exchanged it is not likely + to collide with other sequence numbers in use. + + The client MAY indicate a requirement of mutual authentication or the + use of a session-key based ticket (for user-to-user authentication, + see section 3.7) by setting the appropriate flag(s) in the ap-options + field of the message. + + The Authenticator is encrypted in the session key and combined with + the ticket to form the KRB_AP_REQ message, which is then sent to the + end server along with any additional application-specific + information. + +3.2.3. Receipt of KRB_AP_REQ Message + + Authentication is based on the server's current time of day (clocks + MUST be loosely synchronized), the authenticator, and the ticket. + Several errors are possible. If an error occurs, the server is + expected to reply to the client with a KRB_ERROR message. This + message MAY be encapsulated in the application protocol if its raw + form is not acceptable to the protocol. The format of error messages + is described in Section 5.9.1. + + The algorithm for verifying authentication information is as follows. + If the message type is not KRB_AP_REQ, the server returns the + KRB_AP_ERR_MSG_TYPE error. If the key version indicated by the + Ticket in the KRB_AP_REQ is not one the server can use (e.g., it + indicates an old key, and the server no longer possesses a copy of + the old key), the KRB_AP_ERR_BADKEYVER error is returned. If the + USE-SESSION-KEY flag is set in the ap-options field, it indicates to + the server that user-to-user authentication is in use, and that the + ticket is encrypted in the session key from the server's TGT rather + than in the server's secret key. See Section 3.7 for a more complete + description of the effect of user-to-user authentication on all + messages in the Kerberos protocol. + + Because it is possible for the server to be registered in multiple + realms, with different keys in each, the srealm field in the + unencrypted portion of the ticket in the KRB_AP_REQ is used to + specify which secret key the server should use to decrypt that + ticket. The KRB_AP_ERR_NOKEY error code is returned if the server + doesn't have the proper key to decipher the ticket. + + The ticket is decrypted using the version of the server's key + specified by the ticket. If the decryption routines detect a + modification of the ticket (each encryption system MUST provide + safeguards to detect modified ciphertext), the + + + +Neuman, et al. Standards Track [Page 30] + +RFC 4120 Kerberos V5 July 2005 + + + KRB_AP_ERR_BAD_INTEGRITY error is returned (chances are good that + different keys were used to encrypt and decrypt). + + The authenticator is decrypted using the session key extracted from + the decrypted ticket. If decryption shows that is has been modified, + the KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm + of the client from the ticket are compared against the same fields in + the authenticator. If they don't match, the KRB_AP_ERR_BADMATCH + error is returned; normally this is caused by a client error or an + attempted attack. The addresses in the ticket (if any) are then + searched for an address matching the operating-system reported + address of the client. If no match is found or the server insists on + ticket addresses but none are present in the ticket, the + KRB_AP_ERR_BADADDR error is returned. If the local (server) time and + the client time in the authenticator differ by more than the + allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW error is + returned. + + Unless the application server provides its own suitable means to + protect against replay (for example, a challenge-response sequence + initiated by the server after authentication, or use of a server- + generated encryption subkey), the server MUST utilize a replay cache + to remember any authenticator presented within the allowable clock + skew. Careful analysis of the application protocol and + implementation is recommended before eliminating this cache. The + replay cache will store at least the server name, along with the + client name, time, and microsecond fields from the recently-seen + authenticators, and if a matching tuple is found, the + KRB_AP_ERR_REPEAT error is returned. Note that the rejection here is + restricted to authenticators from the same principal to the same + server. Other client principals communicating with the same server + principal should not have their authenticators rejected if the time + and microsecond fields happen to match some other client's + authenticator. + + If a server loses track of authenticators presented within the + allowable clock skew, it MUST reject all requests until the clock + skew interval has passed, providing assurance that any lost or + replayed authenticators will fall outside the allowable clock skew + and can no longer be successfully replayed. If this were not done, + an attacker could subvert the authentication by recording the ticket + and authenticator sent over the network to a server and replaying + them following an event that caused the server to lose track of + recently seen authenticators. + + Implementation note: If a client generates multiple requests to the + KDC with the same timestamp, including the microsecond field, all but + the first of the requests received will be rejected as replays. This + + + +Neuman, et al. Standards Track [Page 31] + +RFC 4120 Kerberos V5 July 2005 + + + might happen, for example, if the resolution of the client's clock is + too coarse. Client implementations SHOULD ensure that the timestamps + are not reused, possibly by incrementing the microseconds field in + the time stamp when the clock returns the same time for multiple + requests. + + If multiple servers (for example, different services on one machine, + or a single service implemented on multiple machines) share a service + principal (a practice that we do not recommend in general, but that + we acknowledge will be used in some cases), either they MUST share + this replay cache, or the application protocol MUST be designed so as + to eliminate the need for it. Note that this applies to all of the + services. If any of the application protocols does not have replay + protection built in, an authenticator used with such a service could + later be replayed to a different service with the same service + principal but no replay protection, if the former doesn't record the + authenticator information in the common replay cache. + + If a sequence number is provided in the authenticator, the server + saves it for later use in processing KRB_SAFE and/or KRB_PRIV + messages. If a subkey is present, the server either saves it for + later use or uses it to help generate its own choice for a subkey to + be returned in a KRB_AP_REP message. + + The server computes the age of the ticket: local (server) time minus + the starttime inside the Ticket. If the starttime is later than the + current time by more than the allowable clock skew, or if the INVALID + flag is set in the ticket, the KRB_AP_ERR_TKT_NYV error is returned. + Otherwise, if the current time is later than end time by more than + the allowable clock skew, the KRB_AP_ERR_TKT_EXPIRED error is + returned. + + If all these checks succeed without an error, the server is assured + that the client possesses the credentials of the principal named in + the ticket, and thus, that the client has been authenticated to the + server. + + Passing these checks provides only authentication of the named + principal; it does not imply authorization to use the named service. + Applications MUST make a separate authorization decision based upon + the authenticated name of the user, the requested operation, local + access control information such as that contained in a .k5login or + .k5users file, and possibly a separate distributed authorization + service. + + + + + + + +Neuman, et al. Standards Track [Page 32] + +RFC 4120 Kerberos V5 July 2005 + + +3.2.4. Generation of a KRB_AP_REP Message + + Typically, a client's request will include both the authentication + information and its initial request in the same message, and the + server need not explicitly reply to the KRB_AP_REQ. However, if + mutual authentication (authenticating not only the client to the + server, but also the server to the client) is being performed, the + KRB_AP_REQ message will have MUTUAL-REQUIRED set in its ap-options + field, and a KRB_AP_REP message is required in response. As with the + error message, this message MAY be encapsulated in the application + protocol if its "raw" form is not acceptable to the application's + protocol. The timestamp and microsecond field used in the reply MUST + be the client's timestamp and microsecond field (as provided in the + authenticator). If a sequence number is to be included, it SHOULD be + randomly chosen as described above for the authenticator. A subkey + MAY be included if the server desires to negotiate a different + subkey. The KRB_AP_REP message is encrypted in the session key + extracted from the ticket. + + Note that in the Kerberos Version 4 protocol, the timestamp in the + reply was the client's timestamp plus one. This is not necessary in + Version 5 because Version 5 messages are formatted in such a way that + it is not possible to create the reply by judicious message surgery + (even in encrypted form) without knowledge of the appropriate + encryption keys. + +3.2.5. Receipt of KRB_AP_REP Message + + If a KRB_AP_REP message is returned, the client uses the session key + from the credentials obtained for the server to decrypt the message + and verifies that the timestamp and microsecond fields match those in + the Authenticator it sent to the server. If they match, then the + client is assured that the server is genuine. The sequence number + and subkey (if present) are retained for later use. (Note that for + encrypting the KRB_AP_REP message, the sub-session key is not used, + even if it is present in the Authentication.) + +3.2.6. Using the Encryption Key + + After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and + server share an encryption key that can be used by the application. + In some cases, the use of this session key will be implicit in the + protocol; in others the method of use must be chosen from several + alternatives. The application MAY choose the actual encryption key + to be used for KRB_PRIV, KRB_SAFE, or other application-specific uses + based on the session key from the ticket and subkeys in the + KRB_AP_REP message and the authenticator. Implementations of the + protocol MAY provide routines to choose subkeys based on session keys + + + +Neuman, et al. Standards Track [Page 33] + +RFC 4120 Kerberos V5 July 2005 + + + and random numbers and to generate a negotiated key to be returned in + the KRB_AP_REP message. + + To mitigate the effect of failures in random number generation on the + client, it is strongly encouraged that any key derived by an + application for subsequent use include the full key entropy derived + from the KDC-generated session key carried in the ticket. We leave + the protocol negotiations of how to use the key (e.g., for selecting + an encryption or checksum type) to the application programmer. The + Kerberos protocol does not constrain the implementation options, but + an example of how this might be done follows. + + One way that an application may choose to negotiate a key to be used + for subsequent integrity and privacy protection is for the client to + propose a key in the subkey field of the authenticator. The server + can then choose a key using the key proposed by the client as input, + returning the new subkey in the subkey field of the application + reply. This key could then be used for subsequent communication. + + With both the one-way and mutual authentication exchanges, the peers + should take care not to send sensitive information to each other + without proper assurances. In particular, applications that require + privacy or integrity SHOULD use the KRB_AP_REP response from the + server to the client to assure both client and server of their peer's + identity. If an application protocol requires privacy of its + messages, it can use the KRB_PRIV message (section 3.5). The + KRB_SAFE message (Section 3.4) can be used to ensure integrity. + +3.3. The Ticket-Granting Service (TGS) Exchange + + Summary + + Message direction Message type Section + 1. Client to Kerberos KRB_TGS_REQ 5.4.1 + 2. Kerberos to client KRB_TGS_REP or 5.4.2 + KRB_ERROR 5.9.1 + + The TGS exchange between a client and the Kerberos TGS is initiated + by a client when it seeks to obtain authentication credentials for a + given server (which might be registered in a remote realm), when it + seeks to renew or validate an existing ticket, or when it seeks to + obtain a proxy ticket. In the first case, the client must already + have acquired a ticket for the Ticket-Granting Service using the AS + exchange (the TGT is usually obtained when a client initially + authenticates to the system, such as when a user logs in). The + message format for the TGS exchange is almost identical to that for + the AS exchange. The primary difference is that encryption and + decryption in the TGS exchange does not take place under the client's + + + +Neuman, et al. Standards Track [Page 34] + +RFC 4120 Kerberos V5 July 2005 + + + key. Instead, the session key from the TGT or renewable ticket, or + sub-session key from an Authenticator is used. As is the case for + all application servers, expired tickets are not accepted by the TGS, + so once a renewable or TGT expires, the client must use a separate + exchange to obtain valid tickets. + + The TGS exchange consists of two messages: a request (KRB_TGS_REQ) + from the client to the Kerberos Ticket-Granting Server, and a reply + (KRB_TGS_REP or KRB_ERROR). The KRB_TGS_REQ message includes + information authenticating the client plus a request for credentials. + The authentication information consists of the authentication header + (KRB_AP_REQ), which includes the client's previously obtained + ticket-granting, renewable, or invalid ticket. In the TGT and proxy + cases, the request MAY include one or more of the following: a list + of network addresses, a collection of typed authorization data to be + sealed in the ticket for authorization use by the application server, + or additional tickets (the use of which are described later). The + TGS reply (KRB_TGS_REP) contains the requested credentials, encrypted + in the session key from the TGT or renewable ticket, or, if present, + in the sub-session key from the Authenticator (part of the + authentication header). The KRB_ERROR message contains an error code + and text explaining what went wrong. The KRB_ERROR message is not + encrypted. The KRB_TGS_REP message contains information that can be + used to detect replays, and to associate it with the message to which + it replies. The KRB_ERROR message also contains information that can + be used to associate it with the message to which it replies. The + same comments about integrity protection of KRB_ERROR messages + mentioned in Section 3.1 apply to the TGS exchange. + +3.3.1. Generation of KRB_TGS_REQ Message + + Before sending a request to the ticket-granting service, the client + MUST determine in which realm the application server is believed to + be registered. This can be accomplished in several ways. It might + be known beforehand (since the realm is part of the principal + identifier), it might be stored in a nameserver, or it might be + obtained from a configuration file. If the realm to be used is + obtained from a nameserver, there is a danger of being spoofed if the + nameservice providing the realm name is not authenticated. This + might result in the use of a realm that has been compromised, which + would result in an attacker's ability to compromise the + authentication of the application server to the client. + + If the client knows the service principal name and realm and it does + not already possess a TGT for the appropriate realm, then one must be + obtained. This is first attempted by requesting a TGT for the + destination realm from a Kerberos server for which the client + possesses a TGT (by using the KRB_TGS_REQ message recursively). The + + + +Neuman, et al. Standards Track [Page 35] + +RFC 4120 Kerberos V5 July 2005 + + + Kerberos server MAY return a TGT for the desired realm, in which case + one can proceed. Alternatively, the Kerberos server MAY return a TGT + for a realm that is 'closer' to the desired realm (further along the + standard hierarchical path between the client's realm and the + requested realm server's realm). Note that in this case + misconfiguration of the Kerberos servers may cause loops in the + resulting authentication path, which the client should be careful to + detect and avoid. + + If the Kerberos server returns a TGT for a realm 'closer' than the + desired realm, the client MAY use local policy configuration to + verify that the authentication path used is an acceptable one. + Alternatively, a client MAY choose its own authentication path, + rather than rely on the Kerberos server to select one. In either + case, any policy or configuration information used to choose or + validate authentication paths, whether by the Kerberos server or by + the client, MUST be obtained from a trusted source. + + When a client obtains a TGT that is 'closer' to the destination + realm, the client MAY cache this ticket and reuse it in future + KRB-TGS exchanges with services in the 'closer' realm. However, if + the client were to obtain a TGT for the 'closer' realm by starting at + the initial KDC rather than as part of obtaining another ticket, then + a shorter path to the 'closer' realm might be used. This shorter + path may be desirable because fewer intermediate KDCs would know the + session key of the ticket involved. For this reason, clients SHOULD + evaluate whether they trust the realms transited in obtaining the + 'closer' ticket when making a decision to use the ticket in future. + + Once the client obtains a TGT for the appropriate realm, it + determines which Kerberos servers serve that realm and contacts one + of them. The list might be obtained through a configuration file or + network service, or it MAY be generated from the name of the realm. + As long as the secret keys exchanged by realms are kept secret, only + denial of service results from using a false Kerberos server. + + As in the AS exchange, the client MAY specify a number of options in + the KRB_TGS_REQ message. One of these options is the ENC-TKT-IN-SKEY + option used for user-to-user authentication. An overview of user- + to-user authentication can be found in Section 3.7. When generating + the KRB_TGS_REQ message, this option indicates that the client is + including a TGT obtained from the application server in the + additional tickets field of the request and that the KDC SHOULD + encrypt the ticket for the application server using the session key + from this additional ticket, instead of a server key from the + principal database. + + + + + +Neuman, et al. Standards Track [Page 36] + +RFC 4120 Kerberos V5 July 2005 + + + The client prepares the KRB_TGS_REQ message, providing an + authentication header as an element of the padata field, and + including the same fields as used in the KRB_AS_REQ message along + with several optional fields: the enc-authorizatfion-data field for + application server use and additional tickets required by some + options. + + In preparing the authentication header, the client can select a sub- + session key under which the response from the Kerberos server will be + encrypted. If the client selects a sub-session key, care must be + taken to ensure the randomness of the selected sub-session key. + + If the sub-session key is not specified, the session key from the TGT + will be used. If the enc-authorization-data is present, it MUST be + encrypted in the sub-session key, if present, from the authenticator + portion of the authentication header, or, if not present, by using + the session key from the TGT. + + Once prepared, the message is sent to a Kerberos server for the + destination realm. + +3.3.2. Receipt of KRB_TGS_REQ Message + + The KRB_TGS_REQ message is processed in a manner similar to the + KRB_AS_REQ message, but there are many additional checks to be + performed. First, the Kerberos server MUST determine which server + the accompanying ticket is for, and it MUST select the appropriate + key to decrypt it. For a normal KRB_TGS_REQ message, it will be for + the ticket-granting service, and the TGS's key will be used. If the + TGT was issued by another realm, then the appropriate inter-realm key + MUST be used. If (a) the accompanying ticket is not a TGT for the + current realm, but is for an application server in the current realm, + (b) the RENEW, VALIDATE, or PROXY options are specified in the + request, and (c) the server for which a ticket is requested is the + server named in the accompanying ticket, then the KDC will decrypt + the ticket in the authentication header using the key of the server + for which it was issued. If no ticket can be found in the padata + field, the KDC_ERR_PADATA_TYPE_NOSUPP error is returned. + + Once the accompanying ticket has been decrypted, the user-supplied + checksum in the Authenticator MUST be verified against the contents + of the request, and the message MUST be rejected if the checksums do + not match (with an error code of KRB_AP_ERR_MODIFIED) or if the + checksum is not collision-proof (with an error code of + KRB_AP_ERR_INAPP_CKSUM). If the checksum type is not supported, the + KDC_ERR_SUMTYPE_NOSUPP error is returned. If the authorization-data + are present, they are decrypted using the sub-session key from the + Authenticator. + + + +Neuman, et al. Standards Track [Page 37] + +RFC 4120 Kerberos V5 July 2005 + + + If any of the decryptions indicate failed integrity checks, the + KRB_AP_ERR_BAD_INTEGRITY error is returned. + + As discussed in Section 3.1.2, the KDC MUST send a valid KRB_TGS_REP + message if it receives a KRB_TGS_REQ message identical to one it has + recently processed. However, if the authenticator is a replay, but + the rest of the request is not identical, then the KDC SHOULD return + KRB_AP_ERR_REPEAT. + +3.3.3. Generation of KRB_TGS_REP Message + + The KRB_TGS_REP message shares its format with the KRB_AS_REP + (KRB_KDC_REP), but with its type field set to KRB_TGS_REP. The + detailed specification is in Section 5.4.2. + + The response will include a ticket for the requested server or for a + ticket granting server of an intermediate KDC to be contacted to + obtain the requested ticket. The Kerberos database is queried to + retrieve the record for the appropriate server (including the key + with which the ticket will be encrypted). If the request is for a + TGT for a remote realm, and if no key is shared with the requested + realm, then the Kerberos server will select the realm 'closest' to + the requested realm with which it does share a key and use that realm + instead. This is the only case where the response for the KDC will + be for a different server than that requested by the client. + + By default, the address field, the client's name and realm, the list + of transited realms, the time of initial authentication, the + expiration time, and the authorization data of the newly-issued + ticket will be copied from the TGT or renewable ticket. If the + transited field needs to be updated, but the transited type is not + supported, the KDC_ERR_TRTYPE_NOSUPP error is returned. + + If the request specifies an endtime, then the endtime of the new + ticket is set to the minimum of (a) that request, (b) the endtime + from the TGT, and (c) the starttime of the TGT plus the minimum of + the maximum life for the application server and the maximum life for + the local realm (the maximum life for the requesting principal was + already applied when the TGT was issued). If the new ticket is to be + a renewal, then the endtime above is replaced by the minimum of (a) + the value of the renew_till field of the ticket and (b) the starttime + for the new ticket plus the life (endtime-starttime) of the old + ticket. + + If the FORWARDED option has been requested, then the resulting ticket + will contain the addresses specified by the client. This option will + only be honored if the FORWARDABLE flag is set in the TGT. The PROXY + option is similar; the resulting ticket will contain the addresses + + + +Neuman, et al. Standards Track [Page 38] + +RFC 4120 Kerberos V5 July 2005 + + + specified by the client. It will be honored only if the PROXIABLE + flag in the TGT is set. The PROXY option will not be honored on + requests for additional TGTs. + + If the requested starttime is absent, indicates a time in the past, + or is within the window of acceptable clock skew for the KDC and the + POSTDATE option has not been specified, then the starttime of the + ticket is set to the authentication server's current time. If it + indicates a time in the future beyond the acceptable clock skew, but + the POSTDATED option has not been specified or the MAY-POSTDATE flag + is not set in the TGT, then the error KDC_ERR_CANNOT_POSTDATE is + returned. Otherwise, if the TGT has the MAY-POSTDATE flag set, then + the resulting ticket will be postdated, and the requested starttime + is checked against the policy of the local realm. If acceptable, the + ticket's starttime is set as requested, and the INVALID flag is set. + The postdated ticket MUST be validated before use by presenting it to + the KDC after the starttime has been reached. However, in no case + may the starttime, endtime, or renew-till time of a newly-issued + postdated ticket extend beyond the renew-till time of the TGT. + + If the ENC-TKT-IN-SKEY option has been specified and an additional + ticket has been included in the request, it indicates that the client + is using user-to-user authentication to prove its identity to a + server that does not have access to a persistent key. Section 3.7 + describes the effect of this option on the entire Kerberos protocol. + When generating the KRB_TGS_REP message, this option in the + KRB_TGS_REQ message tells the KDC to decrypt the additional ticket + using the key for the server to which the additional ticket was + issued and to verify that it is a TGT. If the name of the requested + server is missing from the request, the name of the client in the + additional ticket will be used. Otherwise, the name of the requested + server will be compared to the name of the client in the additional + ticket. If it is different, the request will be rejected. If the + request succeeds, the session key from the additional ticket will be + used to encrypt the new ticket that is issued instead of using the + key of the server for which the new ticket will be used. + + If (a) the name of the server in the ticket that is presented to the + KDC as part of the authentication header is not that of the TGS + itself, (b) the server is registered in the realm of the KDC, and (c) + the RENEW option is requested, then the KDC will verify that the + RENEWABLE flag is set in the ticket, that the INVALID flag is not set + in the ticket, and that the renew_till time is still in the future. + If the VALIDATE option is requested, the KDC will check that the + starttime has passed and that the INVALID flag is set. If the PROXY + option is requested, then the KDC will check that the PROXIABLE flag + + + + + +Neuman, et al. Standards Track [Page 39] + +RFC 4120 Kerberos V5 July 2005 + + + is set in the ticket. If the tests succeed and the ticket passes the + hotlist check described in the next section, the KDC will issue the + appropriate new ticket. + + The ciphertext part of the response in the KRB_TGS_REP message is + encrypted in the sub-session key from the Authenticator, if present, + or in the session key from the TGT. It is not encrypted using the + client's secret key. Furthermore, the client's key's expiration date + and the key version number fields are left out since these values are + stored along with the client's database record, and that record is + not needed to satisfy a request based on a TGT. + +3.3.3.1. Checking for Revoked Tickets + + Whenever a request is made to the ticket-granting server, the + presented ticket(s) is (are) checked against a hot-list of tickets + that 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 TGT 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 tickets require no interaction with the KDC), but only + until its 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. + +3.3.3.2. Encoding the Transited Field + + If the identity of the server in the TGT that is presented to the KDC + as part of the authentication header is that of the ticket-granting + service, but the TGT was issued from another realm, the KDC will look + up the inter-realm key shared with that realm and use that key to + decrypt the ticket. If the ticket is valid, then the KDC will honor + the request, subject to the constraints outlined above in the section + describing the AS exchange. The realm part of the client's identity + will be taken from the TGT. The name of the realm that issued the + TGT, if it is not the realm of the client principal, will be added to + the transited field of the ticket to be issued. This is accomplished + by reading the transited field from the TGT (which is treated as an + unordered set of realm names), adding the new realm to the set, and + then constructing and writing out its encoded (shorthand) form (this + may involve a rearrangement of the existing encoding). + + Note that the ticket-granting service does not add the name of its + own realm. Instead, its responsibility is to add the name of the + + + +Neuman, et al. Standards Track [Page 40] + +RFC 4120 Kerberos V5 July 2005 + + + previous realm. This prevents a malicious Kerberos server from + intentionally leaving out its own name (it could, however, omit other + realms' names). + + The names of neither the local realm nor the principal's realm are to + be included in the transited field. They appear elsewhere in the + ticket and both are known to have taken part in authenticating the + principal. Because the endpoints are not included, both local and + single-hop inter-realm authentication result in a transited field + that is empty. + + Because this field has the name of each transited realm added to it, + it might potentially be very long. To decrease the length of this + field, its contents are encoded. The initially supported encoding is + optimized for the normal case of inter-realm communication: a + hierarchical arrangement of realms using either domain or X.500 style + realm names. This encoding (called DOMAIN-X500-COMPRESS) is now + described. + + Realm names in the transited field are separated by a ",". The ",", + "\", trailing "."s, and leading spaces (" ") are special characters, + and if they are part of a realm name, they MUST be quoted in the + transited field by preceding them with a "\". + + A realm name ending with a "." is interpreted as being prepended to + the previous realm. For example, we can encode traversal of EDU, + MIT.EDU, ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as: + + "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.". + + Note that if either ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were + endpoints, they would not be included in this field, and we would + have: + + "EDU,MIT.,WASHINGTON.EDU" + + A realm name beginning with a "/" is interpreted as being appended to + the previous realm. For the purpose of appending, the realm + preceding the first listed realm is considered the null realm (""). + If a realm name beginning with a "/" is to stand by itself, then it + SHOULD be preceded by a space (" "). For example, we can encode + traversal of /COM/HP/APOLLO, /COM/HP, /COM, and /COM/DEC as: + + "/COM,/HP,/APOLLO, /COM/DEC". + + As in the example above, if /COM/HP/APOLLO and /COM/DEC were + endpoints, they would not be included in this field, and we would + have: + + + +Neuman, et al. Standards Track [Page 41] + +RFC 4120 Kerberos V5 July 2005 + + + "/COM,/HP" + + A null subfield preceding or following a "," indicates that all + realms between the previous realm and the next realm have been + traversed. For the purpose of interpreting null subfields, the + client's realm is considered to precede those in the transited field, + and the server's realm is considered to follow them. Thus, "," means + that all realms along the path between the client and the server have + been traversed. ",EDU, /COM," means that all realms from the + client's realm up to EDU (in a domain style hierarchy) have been + traversed, and that everything from /COM down to the server's realm + in an X.500 style has also been traversed. This could occur if the + EDU realm in one hierarchy shares an inter-realm key directly with + the /COM realm in another hierarchy. + +3.3.4. Receipt of KRB_TGS_REP Message + + When the KRB_TGS_REP is received by the client, it is processed in + the same manner as the KRB_AS_REP processing described above. The + primary difference is that the ciphertext part of the response must + be decrypted using the sub-session key from the Authenticator, if it + was specified in the request, or the session key from the TGT, rather + than the client's secret key. The server name returned in the reply + is the true principal name of the service. + +3.4. The KRB_SAFE Exchange + + The KRB_SAFE message MAY be used by clients requiring the ability to + detect modifications of messages they exchange. It achieves this by + including a keyed collision-proof checksum of the user data and some + control information. The checksum is keyed with an encryption key + (usually the last key negotiated via subkeys, or the session key if + no negotiation has occurred). + +3.4.1. Generation of a KRB_SAFE Message + + When an application wishes to send a KRB_SAFE message, it collects + its data and the appropriate control information and computes a + checksum over them. The checksum algorithm should be the keyed + checksum mandated to be implemented along with the crypto system used + for the sub-session or session key. The checksum is generated using + the sub-session key, if present, or the session key. Some + implementations use a different checksum algorithm for the KRB_SAFE + messages, but doing so in an interoperable manner is not always + possible. + + The control information for the KRB_SAFE message includes both a + timestamp and a sequence number. The designer of an application + + + +Neuman, et al. Standards Track [Page 42] + +RFC 4120 Kerberos V5 July 2005 + + + using the KRB_SAFE message MUST choose at least one of the two + mechanisms. This choice SHOULD be based on the needs of the + application protocol. + + Sequence numbers are useful when all messages sent will be received + by one's peer. Connection state is presently required to maintain + the session key, so maintaining the next sequence number should not + present an additional problem. + + If the application protocol is expected to tolerate lost messages + without their being resent, the use of the timestamp is the + appropriate replay detection mechanism. Using timestamps is also the + appropriate mechanism for multi-cast protocols in which all of one's + peers share a common sub-session key, but some messages will be sent + to a subset of one's peers. + + After computing the checksum, the client then transmits the + information and checksum to the recipient in the message format + specified in Section 5.6.1. + +3.4.2. Receipt of KRB_SAFE Message + + When an application receives a KRB_SAFE message, it verifies it as + follows. If any error occurs, an error code is reported for use by + the application. + + The message is first checked by verifying that the protocol version + and type fields match the current version and KRB_SAFE, respectively. + A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE + error. The application verifies that the checksum used is a + collision-proof keyed checksum that uses keys compatible with the + sub-session or session key as appropriate (or with the application + key derived from the session or sub-session keys). If it is not, a + KRB_AP_ERR_INAPP_CKSUM error is generated. The sender's address MUST + be included in the control information; the recipient verifies that + the operating system's report of the sender's address matches the + sender's address in the message, and (if a recipient address is + specified or the recipient requires an address) that one of the + recipient's addresses appears as the recipient's address in the + message. To work with network address translation, senders MAY use + the directional address type specified in Section 8.1 for the sender + address and not include recipient addresses. A failed match for + either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp + and usec and/or the sequence number fields are checked. If timestamp + and usec are expected and not present, or if they are present but not + current, the KRB_AP_ERR_SKEW error is generated. Timestamps are not + required to be strictly ordered; they are only required to be in the + skew window. If the server name, along with the client name, time, + + + +Neuman, et al. Standards Track [Page 43] + +RFC 4120 Kerberos V5 July 2005 + + + and microsecond fields from the Authenticator match any recently-seen + (sent or received) such tuples, the KRB_AP_ERR_REPEAT error is + generated. If an incorrect sequence number is included, or if a + sequence number is expected but not present, the KRB_AP_ERR_BADORDER + error is generated. If neither a time-stamp and usec nor a sequence + number is present, a KRB_AP_ERR_MODIFIED error is generated. + Finally, the checksum is computed over the data and control + information, and if it doesn't match the received checksum, a + KRB_AP_ERR_MODIFIED error is generated. + + If all the checks succeed, the application is assured that the + message was generated by its peer and was not modified in transit. + + Implementations SHOULD accept any checksum algorithm they implement + that has both adequate security and keys compatible with the sub- + session or session key. Unkeyed or non-collision-proof checksums are + not suitable for this use. + +3.5. The KRB_PRIV Exchange + + The KRB_PRIV message MAY be used by clients requiring confidentiality + and the ability to detect modifications of exchanged messages. It + achieves this by encrypting the messages and adding control + information. + +3.5.1. Generation of a KRB_PRIV Message + + When an application wishes to send a KRB_PRIV message, it collects + its data and the appropriate control information (specified in + Section 5.7.1) and encrypts them under an encryption key (usually the + last key negotiated via subkeys, or the session key if no negotiation + has occurred). As part of the control information, the client MUST + choose to use either a timestamp or a sequence number (or both); see + the discussion in Section 3.4.1 for guidelines on which to use. + After the user data and control information are encrypted, the client + transmits the ciphertext and some 'envelope' information to the + recipient. + +3.5.2. Receipt of KRB_PRIV Message + + When an application receives a KRB_PRIV message, it verifies it as + follows. If any error occurs, an error code is reported for use by + the application. + + The message is first checked by verifying that the protocol version + and type fields match the current version and KRB_PRIV, respectively. + A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE + error. The application then decrypts the ciphertext and processes + + + +Neuman, et al. Standards Track [Page 44] + +RFC 4120 Kerberos V5 July 2005 + + + the resultant plaintext. If decryption shows that the data has been + modified, a KRB_AP_ERR_BAD_INTEGRITY error is generated. + + The sender's address MUST be included in the control information; the + recipient verifies that the operating system's report of the sender's + address matches the sender's address in the message. If a recipient + address is specified or the recipient requires an address, then one + of the recipient's addresses MUST also appear as the recipient's + address in the message. Where a sender's or receiver's address might + not otherwise match the address in a message because of network + address translation, an application MAY be written to use addresses + of the directional address type in place of the actual network + address. + + A failed match for either case generates a KRB_AP_ERR_BADADDR error. + To work with network address translation, implementations MAY use the + directional address type defined in Section 7.1 for the sender + address and include no recipient address. + + Next the timestamp and usec and/or the sequence number fields are + checked. If timestamp and usec are expected and not present, or if + they are present but not current, the KRB_AP_ERR_SKEW error is + generated. If the server name, along with the client name, time, and + microsecond fields from the Authenticator match any such recently- + seen tuples, the KRB_AP_ERR_REPEAT error is generated. If an + incorrect sequence number is included, or if a sequence number is + expected but not present, the KRB_AP_ERR_BADORDER error is generated. + If neither a time-stamp and usec nor a sequence number is present, a + KRB_AP_ERR_MODIFIED error is generated. + + If all the checks succeed, the application can assume the message was + generated by its peer and was securely transmitted (without intruders + seeing the unencrypted contents). + +3.6. The KRB_CRED Exchange + + The KRB_CRED message MAY be used by clients requiring the ability to + send Kerberos credentials from one host to another. It achieves this + by sending the tickets together with encrypted data containing the + session keys and other information associated with the tickets. + +3.6.1. Generation of a KRB_CRED Message + + When an application wishes to send a KRB_CRED message, it first + (using the KRB_TGS exchange) obtains credentials to be sent to the + remote host. It then constructs a KRB_CRED message using the ticket + or tickets so obtained, placing the session key needed to use each + + + + +Neuman, et al. Standards Track [Page 45] + +RFC 4120 Kerberos V5 July 2005 + + + ticket in the key field of the corresponding KrbCredInfo sequence of + the encrypted part of the KRB_CRED message. + + Other information associated with each ticket and obtained during the + KRB_TGS exchange is also placed in the corresponding KrbCredInfo + sequence in the encrypted part of the KRB_CRED message. The current + time and, if they are specifically required by the application, the + nonce, s-address, and r-address fields are placed in the encrypted + part of the KRB_CRED message, which is then encrypted under an + encryption key previously exchanged in the KRB_AP exchange (usually + the last key negotiated via subkeys, or the session key if no + negotiation has occurred). + + Implementation note: When constructing a KRB_CRED message for + inclusion in a GSSAPI initial context token, the MIT implementation + of Kerberos will not encrypt the KRB_CRED message if the session key + is a DES or triple DES key. For interoperability with MIT, the + Microsoft implementation will not encrypt the KRB_CRED in a GSSAPI + token if it is using a DES session key. Starting at version 1.2.5, + MIT Kerberos can receive and decode either encrypted or unencrypted + KRB_CRED tokens in the GSSAPI exchange. The Heimdal implementation + of Kerberos can also accept either encrypted or unencrypted KRB_CRED + messages. Since the KRB_CRED message in a GSSAPI token is encrypted + in the authenticator, the MIT behavior does not present a security + problem, although it is a violation of the Kerberos specification. + +3.6.2. Receipt of KRB_CRED Message + + When an application receives a KRB_CRED message, it verifies it. If + any error occurs, an error code is reported for use by the + application. The message is verified by checking that the protocol + version and type fields match the current version and KRB_CRED, + respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or + KRB_AP_ERR_MSG_TYPE error. The application then decrypts the + ciphertext and processes the resultant plaintext. If decryption + shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY + error is generated. + + If present or required, the recipient MAY verify that the operating + system's report of the sender's address matches the sender's address + in the message, and that one of the recipient's addresses appears as + the recipient's address in the message. The address check does not + provide any added security, since the address, if present, has + already been checked in the KRB_AP_REQ message and there is not any + benefit to be gained by an attacker in reflecting a KRB_CRED message + back to its originator. Thus, the recipient MAY ignore the address + even if it is present in order to work better in Network Address + Translation (NAT) environments. A failed match for either case + + + +Neuman, et al. Standards Track [Page 46] + +RFC 4120 Kerberos V5 July 2005 + + + generates a KRB_AP_ERR_BADADDR error. Recipients MAY skip the + address check, as the KRB_CRED message cannot generally be reflected + back to the originator. The timestamp and usec fields (and the nonce + field, if required) are checked next. If the timestamp and usec are + not present, or if they are present but not current, the + KRB_AP_ERR_SKEW error is generated. + + If all the checks succeed, the application stores each of the new + tickets in its credentials cache together with the session key and + other information in the corresponding KrbCredInfo sequence from the + encrypted part of the KRB_CRED message. + +3.7. User-to-User Authentication Exchanges + + User-to-User authentication provides a method to perform + authentication when the verifier does not have a access to long-term + service key. This might be the case when running a server (for + example, a window server) as a user on a workstation. In such cases, + the server may have access to the TGT obtained when the user logged + in to the workstation, but because the server is running as an + unprivileged user, it might not have access to system keys. Similar + situations may arise when running peer-to-peer applications. + + Summary + + Message direction Message type Sections + 0. Message from application server Not specified + 1. Client to Kerberos KRB_TGS_REQ 3.3 & 5.4.1 + 2. Kerberos to client KRB_TGS_REP or 3.3 & 5.4.2 + KRB_ERROR 5.9.1 + 3. Client to application server KRB_AP_REQ 3.2 & 5.5.1 + + To address this problem, the Kerberos protocol allows the client to + request that the ticket issued by the KDC be encrypted using a + session key from a TGT issued to the party that will verify the + authentication. This TGT must be obtained from the verifier by means + of an exchange external to the Kerberos protocol, usually as part of + the application protocol. This message is shown in the summary above + as message 0. Note that because the TGT is encrypted in the KDC's + secret key, it cannot be used for authentication without possession + of the corresponding secret key. Furthermore, because the verifier + does not reveal the corresponding secret key, providing a copy of the + verifier's TGT does not allow impersonation of the verifier. + + Message 0 in the table above represents an application-specific + negotiation between the client and server, at the end of which both + have determined that they will use user-to-user authentication, and + the client has obtained the server's TGT. + + + +Neuman, et al. Standards Track [Page 47] + +RFC 4120 Kerberos V5 July 2005 + + + Next, the client includes the server's TGT as an additional ticket in + its KRB_TGS_REQ request to the KDC (message 1 in the table above) and + specifies the ENC-TKT-IN-SKEY option in its request. + + If validated according to the instructions in Section 3.3.3, the + application ticket returned to the client (message 2 in the table + above) will be encrypted using the session key from the additional + ticket and the client will note this when it uses or stores the + application ticket. + + When contacting the server using a ticket obtained for user-to-user + authentication (message 3 in the table above), the client MUST + specify the USE-SESSION-KEY flag in the ap-options field. This tells + the application server to use the session key associated with its TGT + to decrypt the server ticket provided in the application request. + +4. Encryption and Checksum Specifications + + The Kerberos protocols described in this document are designed to + encrypt messages of arbitrary sizes, using stream or block encryption + ciphers. Encryption is used to prove the identities of the network + entities participating in message exchanges. The Key Distribution + Center for each realm is trusted by all principals registered in that + realm to store a secret key in confidence. Proof of knowledge of + this secret key is used to verify the authenticity of a principal. + + The KDC uses the principal's secret key (in the AS exchange) or a + shared session key (in the TGS exchange) to encrypt responses to + ticket requests; the ability to obtain the secret key or session key + implies the knowledge of the appropriate keys and the identity of the + KDC. The ability of a principal to decrypt the KDC response and to + present a Ticket and a properly formed Authenticator (generated with + the session key from the KDC response) to a service verifies the + identity of the principal; likewise the ability of the service to + extract the session key from the Ticket and to prove its knowledge + thereof in a response verifies the identity of the service. + + [RFC3961] defines a framework for defining encryption and checksum + mechanisms for use with Kerberos. It also defines several such + mechanisms, and more may be added in future updates to that document. + + The string-to-key operation provided by [RFC3961] is used to produce + a long-term key for a principal (generally for a user). The default + salt string, if none is provided via pre-authentication data, is the + concatenation of the principal's realm and name components, in order, + with no separators. Unless it is indicated otherwise, the default + string-to-key opaque parameter set as defined in [RFC3961] is used. + + + + +Neuman, et al. Standards Track [Page 48] + +RFC 4120 Kerberos V5 July 2005 + + + Encrypted data, keys, and checksums are transmitted using the + EncryptedData, EncryptionKey, and Checksum data objects defined in + Section 5.2.9. The encryption, decryption, and checksum operations + described in this document use the corresponding encryption, + decryption, and get_mic operations described in [RFC3961], with + implicit "specific key" generation using the "key usage" values + specified in the description of each EncryptedData or Checksum object + to vary the key for each operation. Note that in some cases, the + value to be used is dependent on the method of choosing the key or + the context of the message. + + Key usages are unsigned 32-bit integers; zero is not permitted. The + key usage values for encrypting or checksumming Kerberos messages are + indicated in Section 5 along with the message definitions. The key + usage values 512-1023 are reserved for uses internal to a Kerberos + implementation. (For example, seeding a pseudo-random number + generator with a value produced by encrypting something with a + session key and a key usage value not used for any other purpose.) + Key usage values between 1024 and 2047 (inclusive) are reserved for + application use; applications SHOULD use even values for encryption + and odd values for checksums within this range. Key usage values are + also summarized in a table in Section 7.5.1. + + There might exist other documents that define protocols in terms of + the RFC 1510 encryption types or checksum types. These documents + would not know about key usages. In order that these specifications + continue to be meaningful until they are updated, if no key usage + values are specified, then key usages 1024 and 1025 must be used to + derive keys for encryption and checksums, respectively. (This does + not apply to protocols that do their own encryption independent of + this framework, by directly using the key resulting from the Kerberos + authentication exchange.) New protocols defined in terms of the + Kerberos encryption and checksum types SHOULD use their own key usage + values. + + Unless it is indicated otherwise, no cipher state chaining is done + from one encryption operation to another. + + Implementation note: Although it is not recommended, some application + protocols will continue to use the key data directly, even if only in + currently existing protocol specifications. An implementation + intended to support general Kerberos applications may therefore need + to make key data available, as well as the attributes and operations + described in [RFC3961]. One of the more common reasons for directly + performing encryption is direct control over negotiation and + selection of a "sufficiently strong" encryption algorithm (in the + context of a given application). Although Kerberos does not directly + provide a facility for negotiating encryption types between the + + + +Neuman, et al. Standards Track [Page 49] + +RFC 4120 Kerberos V5 July 2005 + + + application client and server, there are approaches for using + Kerberos to facilitate this negotiation. For example, a client may + request only "sufficiently strong" session key types from the KDC and + expect that any type returned by the KDC will be understood and + supported by the application server. + +5. Message Specifications + + The ASN.1 collected here should be identical to the contents of + Appendix A. In the case of a conflict, the contents of Appendix A + shall take precedence. + + The Kerberos protocol is defined here in terms of Abstract Syntax + Notation One (ASN.1) [X680], which provides a syntax for specifying + both the abstract layout of protocol messages as well as their + encodings. Implementors not utilizing an existing ASN.1 compiler or + support library are cautioned to understand the actual ASN.1 + specification thoroughly in order 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 + misleading or erroneous. + + Note that in several places, changes to abstract types from RFC 1510 + have been made. This is in part to address widespread assumptions + that various implementors have made, in some cases resulting in + unintentional violations of the ASN.1 standard. These are clearly + flagged where they occur. The differences between the abstract types + in RFC 1510 and abstract types in this document can cause + incompatible encodings to be emitted when certain encoding rules, + e.g., the Packed Encoding Rules (PER), are used. This theoretical + incompatibility should not be relevant for Kerberos, since Kerberos + explicitly specifies the use of the Distinguished Encoding Rules + (DER). It might be an issue for protocols seeking to use Kerberos + types with other encoding rules. (This practice is not recommended.) + With very few exceptions (most notably the usages of BIT STRING), the + encodings resulting from using the DER remain identical between the + types defined in RFC 1510 and the types defined in this document. + + The type definitions in this section assume an ASN.1 module + definition of the following form: + + + + + + + + + + + +Neuman, et al. Standards Track [Page 50] + +RFC 4120 Kerberos V5 July 2005 + + + KerberosV5Spec2 { + iso(1) identified-organization(3) dod(6) internet(1) + security(5) kerberosV5(2) modules(4) krb5spec2(2) + } DEFINITIONS EXPLICIT TAGS ::= BEGIN + + -- rest of definitions here + + END + + This specifies that the tagging context for the module will be + explicit and non-automatic. + + Note that in some other publications (such as [RFC1510] and + [RFC1964]), the "dod" portion of the object identifier is erroneously + specified as having the value "5". In the case of RFC 1964, use of + the "correct" OID value would result in a change in the wire + protocol; therefore, it remains unchanged for now. + + Note that elsewhere in this document, nomenclature for various + message types is inconsistent, but it largely follows C language + conventions, including use of underscore (_) characters and all-caps + spelling of names intended to be numeric constants. Also, in some + places, identifiers (especially those referring to constants) are + written in all-caps in order to distinguish them from surrounding + explanatory text. + + The ASN.1 notation does not permit underscores in identifiers, so in + actual ASN.1 definitions, underscores are replaced with hyphens (-). + Additionally, structure member names and defined values in ASN.1 MUST + begin with a lowercase letter, whereas type names MUST begin with an + uppercase letter. + +5.1. Specific Compatibility Notes on ASN.1 + + For compatibility purposes, implementors should heed the following + specific notes regarding the use of ASN.1 in Kerberos. These notes + do not describe deviations from standard usage of ASN.1. The purpose + of these notes is instead to describe some historical quirks and + non-compliance of various implementations, as well as historical + ambiguities, which, although they are valid ASN.1, can lead to + confusion during implementation. + +5.1.1. ASN.1 Distinguished Encoding Rules + + The encoding of Kerberos protocol messages shall obey the + Distinguished Encoding Rules (DER) of ASN.1 as described in [X690]. + Some implementations (believed primarily to be those derived from DCE + 1.1 and earlier) are known to use the more general Basic Encoding + + + +Neuman, et al. Standards Track [Page 51] + +RFC 4120 Kerberos V5 July 2005 + + + Rules (BER); in particular, these implementations send indefinite + encodings of lengths. Implementations MAY accept such encodings in + the interest of backward compatibility, though implementors are + warned that decoding fully-general BER is fraught with peril. + +5.1.2. Optional Integer Fields + + Some implementations do not internally distinguish between an omitted + optional integer value and a transmitted value of zero. The places + in the protocol where this is relevant include various microseconds + fields, nonces, and sequence numbers. Implementations SHOULD treat + omitted optional integer values as having been transmitted with a + value of zero, if the application is expecting this. + +5.1.3. Empty SEQUENCE OF Types + + There are places in the protocol where a message contains a SEQUENCE + OF type as an optional member. This can result in an encoding that + contains an empty SEQUENCE OF encoding. The Kerberos protocol does + not semantically distinguish between an absent optional SEQUENCE OF + type and a present optional but empty SEQUENCE OF type. + Implementations SHOULD NOT send empty SEQUENCE OF encodings that are + marked OPTIONAL, but SHOULD accept them as being equivalent to an + omitted OPTIONAL type. In the ASN.1 syntax describing Kerberos + messages, instances of these problematic optional SEQUENCE OF types + are indicated with a comment. + +5.1.4. Unrecognized Tag Numbers + + Future revisions to this protocol may include new message types with + different APPLICATION class tag numbers. Such revisions should + protect older implementations by only sending the message types to + parties that are known to understand them; e.g., by means of a flag + bit set by the receiver in a preceding request. In the interest of + robust error handling, implementations SHOULD gracefully handle + receiving a message with an unrecognized tag anyway, and return an + error message, if appropriate. + + In particular, KDCs SHOULD return KRB_AP_ERR_MSG_TYPE if the + incorrect tag is sent over a TCP transport. The KDCs SHOULD NOT + respond to messages received with an unknown tag over UDP transport + in order to avoid denial of service attacks. For non-KDC + applications, the Kerberos implementation typically indicates an + error to the application which takes appropriate steps based on the + application protocol. + + + + + + +Neuman, et al. Standards Track [Page 52] + +RFC 4120 Kerberos V5 July 2005 + + +5.1.5. Tag Numbers Greater Than 30 + + A naive implementation of a DER ASN.1 decoder may experience problems + with ASN.1 tag numbers greater than 30, due to such tag numbers being + encoded using more than one byte. Future revisions of this protocol + may utilize tag numbers greater than 30, and implementations SHOULD + be prepared to gracefully return an error, if appropriate, when they + do not recognize the tag. + +5.2. Basic Kerberos Types + + This section defines a number of basic types that are potentially + used in multiple Kerberos protocol messages. + +5.2.1. KerberosString + + 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 + [ISO-2022/ECMA-35] to switch character sets, and the default + character set that is designated as G0 is the ISO-646/ECMA-6 + [ISO-646/ECMA-6] International Reference Version (IRV) (a.k.a. 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 prohibits the + designation of character sets as any but the G0 and C0 sets. + Unfortunately, this seems to have the side effect of prohibiting the + use of ISO-8859 (ISO Latin) [ISO-8859] character sets or any other + character sets that utilize a 96-character set, as ISO-2022/ECMA-35 + prohibits designating them as the G0 code element. This side effect + is being investigated in the ASN.1 standards community. + + In practice, many implementations treat GeneralStrings as if they + were 8-bit strings of whichever character set the implementation + defaults to, without regard to 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 adhere to + the GeneralString specifications results in interoperability issues + when conflicting character encodings are utilized by the Kerberos + clients, services, and KDC. + + + + + + +Neuman, et al. Standards Track [Page 53] + +RFC 4120 Kerberos V5 July 2005 + + + This unfortunate situation is the result of improper documentation of + the restrictions of the ASN.1 GeneralString type in prior Kerberos + specifications. + + The new (post-RFC 1510) type KerberosString, defined below, is a + GeneralString that is constrained to contain only characters in + IA5String. + + KerberosString ::= GeneralString (IA5String) + + In general, US-ASCII control characters should not be used in + KerberosString. Control characters SHOULD NOT be used in principal + names or realm names. + + 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 they 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 as 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 encoding change 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. + + Future revisions to this protocol will almost certainly allow for a + more interoperable representation of principal names, probably + including UTF8String. + + Note that applying a new constraint to a previously unconstrained + type constitutes creation of a new ASN.1 type. In this particular + case, the change does not result in a changed encoding under DER. + + + +Neuman, et al. Standards Track [Page 54] + +RFC 4120 Kerberos V5 July 2005 + + +5.2.2. Realm and PrincipalName + + Realm ::= KerberosString + + PrincipalName ::= SEQUENCE { + name-type [0] Int32, + name-string [1] SEQUENCE OF KerberosString + } + + Kerberos realm names are encoded as KerberosStrings. Realms shall + 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 the style of X.500 names. Acceptable forms for realm + names are specified in Section 6.1. A PrincipalName is a typed + sequence of components consisting of the following subfields: + + name-type + This field specifies the type of name that follows. Pre-defined + values for this field are specified in Section 6.2. 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). + + name-string + This field 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.2.3. KerberosTime + + KerberosTime ::= GeneralizedTime -- with no fractional seconds + + The timestamps used in Kerberos are encoded as GeneralizedTimes. A + KerberosTime value shall not include any fractional portions of the + seconds. As required by the DER, it further shall not include any + separators, and it shall specify 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. + +5.2.4. Constrained Integer Types + + Some integer members of types SHOULD be constrained to values + representable in 32 bits, for compatibility with reasonable + implementation limits. + + + + +Neuman, et al. Standards Track [Page 55] + +RFC 4120 Kerberos V5 July 2005 + + + Int32 ::= INTEGER (-2147483648..2147483647) + -- signed values representable in 32 bits + + UInt32 ::= INTEGER (0..4294967295) + -- unsigned 32 bit values + + Microseconds ::= INTEGER (0..999999) + -- microseconds + + Although this results in changes to the abstract types from the RFC + 1510 version, the encoding in DER should be unaltered. Historical + implementations were typically limited to 32-bit integer values + anyway, and assigned numbers SHOULD fall in the space of integer + values representable in 32 bits in order to promote interoperability + anyway. + + Several integer fields in messages are constrained to fixed values. + + pvno + also TKT-VNO or AUTHENTICATOR-VNO, this recurring field is always + the constant integer 5. There is no easy way to make this field + into a useful protocol version number, so its value is fixed. + + msg-type + this integer field is usually identical to the application tag + number of the containing message type. + +5.2.5. HostAddress and HostAddresses + + HostAddress ::= SEQUENCE { + addr-type [0] Int32, + address [1] OCTET STRING + } + + -- NOTE: HostAddresses is always used as an OPTIONAL field and + -- should not be empty. + HostAddresses -- NOTE: subtly different from rfc1510, + -- but has a value mapping and encodes the same + ::= SEQUENCE OF HostAddress + + The host address encodings consist of two fields: + + addr-type + This field specifies the type of address that follows. Pre- + defined values for this field are specified in Section 7.5.3. + + address + This field encodes a single address of type addr-type. + + + +Neuman, et al. Standards Track [Page 56] + +RFC 4120 Kerberos V5 July 2005 + + +5.2.6. AuthorizationData + + -- NOTE: AuthorizationData is always used as an OPTIONAL field and + -- should not be empty. + AuthorizationData ::= SEQUENCE OF SEQUENCE { + ad-type [0] Int32, + ad-data [1] OCTET STRING + } + + ad-data + This field contains authorization data to be interpreted according + to the value of the corresponding ad-type field. + + ad-type + This field specifies the format for the ad-data subfield. All + negative values are reserved for local use. Non-negative values + are reserved for registered use. + + Each sequence of type and data 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 elements embedded + within them, and the interpretation of the encapsulating element + determines which of the embedded elements must be interpreted, and + which may be ignored. + + These common authorization data elements are recursively defined, + meaning that the ad-data for these types will itself contain a + sequence of authorization data whose interpretation is affected by + the encapsulating element. Depending on the meaning of the + encapsulating element, the encapsulated elements may be ignored, + might be interpreted as issued directly by the KDC, or might be + stored in a separate plaintext part of the ticket. The types of the + encapsulating elements are specified as part of the Kerberos + specification because the behavior based on these values should be + understood across implementations, whereas other elements need only + be understood by the applications that they affect. + + Authorization data elements are considered critical if present in a + ticket or authenticator. If an unknown authorization data element + type is received by a server either in an AP-REQ or in a ticket + contained in an AP-REQ, then, unless it is encapsulated in a known + authorization data element amending the criticality of the elements + it contains, authentication MUST 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 + + + + + +Neuman, et al. Standards Track [Page 57] + +RFC 4120 Kerberos V5 July 2005 + + + security weakness may result if the ticket can be used for that + service. Authorization elements that are optional can be enclosed in + an AD-IF-RELEVANT element. + + In the definitions that follow, the value of the ad-type for the + element will be specified as the least significant part of the + subsection number, and the value of the ad-data will be as shown in + the ASN.1 structure that follows the subsection heading. + + Contents of ad-data ad-type + + DER encoding of AD-IF-RELEVANT 1 + + DER encoding of AD-KDCIssued 4 + + DER encoding of AD-AND-OR 5 + + DER encoding of AD-MANDATORY-FOR-KDC 8 + +5.2.6.1. IF-RELEVANT + + 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 that may + have local extensions for authorization. The ad-type for + AD-IF-RELEVANT is (1). + +5.2.6.2. KDCIssued + + AD-KDCIssued ::= SEQUENCE { + ad-checksum [0] Checksum, + 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. + + + + + +Neuman, et al. Standards Track [Page 58] + +RFC 4120 Kerberos V5 July 2005 + + + i-realm, i-sname + The name of the issuing principal if different from that of 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 + A sequence of authorization data elements issued by the KDC. + + The KDC-issued ad-data field is intended to provide a means for + Kerberos principal credentials to embed within themselves privilege + attributes and other mechanisms for positive authorization, + amplifying the privileges of the principal beyond what can be done + using credentials without such an a-data element. + + The above means 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 when 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). Elements encapsulated with in the KDC-issued + element MUST be ignored by the application server if this "signature" + is not present. Further, elements encapsulated within this element + from a TGT MAY be interpreted by the KDC, and used as a basis + according to policy for including new signed elements within + derivative tickets, but they 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 safely be ignored + by applications, application servers, and KDCs that do not implement + this element. + + The ad-type for AD-KDC-ISSUED is (4). + +5.2.6.3. AND-OR + + AD-AND-OR ::= SEQUENCE { + condition-count [0] Int32, + elements [1] AuthorizationData + } + + + +Neuman, et al. Standards Track [Page 59] + +RFC 4120 Kerberos V5 July 2005 + + + 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). + +5.2.6.4. MANDATORY-FOR-KDC + + 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). + +5.2.7. PA-DATA + + Historically, PA-DATA have been known as "pre-authentication data", + meaning that they were used to augment the initial authentication + with the KDC. Since that time, they have also been used as a typed + hole with which to extend protocol exchanges with the KDC. + + PA-DATA ::= SEQUENCE { + -- NOTE: first tag is [1], not [0] + padata-type [1] Int32, + padata-value [2] OCTET STRING -- might be encoded AP-REQ + } + + padata-type + Indicates the way that the padata-value element is to be + interpreted. Negative values of padata-type are reserved for + unregistered use; non-negative values are used for a registered + interpretation of the element type. + + padata-value + Usually contains the DER encoding of another type; the padata-type + field identifies which type is encoded here. + + + + + + +Neuman, et al. Standards Track [Page 60] + +RFC 4120 Kerberos V5 July 2005 + + + padata-type Name Contents of padata-value + + 1 pa-tgs-req DER encoding of AP-REQ + + 2 pa-enc-timestamp DER encoding of PA-ENC-TIMESTAMP + + 3 pa-pw-salt salt (not ASN.1 encoded) + + 11 pa-etype-info DER encoding of ETYPE-INFO + + 19 pa-etype-info2 DER encoding of ETYPE-INFO2 + + This field MAY also contain information needed by certain + extensions to the Kerberos protocol. For example, it might be + used to verify the identity of a client initially before any + response is returned. + + The padata field can also contain information needed to help the + KDC or the client select the key needed for generating or + decrypting the response. This form of the padata is useful for + supporting the use of certain token cards with Kerberos. The + details of such extensions are specified in separate documents. + See [Pat92] for additional uses of this field. + +5.2.7.1. PA-TGS-REQ + + In the case of requests for additional tickets (KRB_TGS_REQ), + padata-value will contain an encoded AP-REQ. The checksum in the + authenticator (which MUST be collision-proof) is to be computed over + the KDC-REQ-BODY encoding. + +5.2.7.2. Encrypted Timestamp Pre-authentication + + There are pre-authentication types that may be used to pre- + authenticate a client by means of an encrypted timestamp. + + PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC + + PA-ENC-TS-ENC ::= SEQUENCE { + patimestamp [0] KerberosTime -- client's time --, + pausec [1] Microseconds OPTIONAL + } + + Patimestamp contains the client's time, and pausec contains the + microseconds, which MAY be omitted if a client will not generate more + than one request per second. The ciphertext (padata-value) consists + of the PA-ENC-TS-ENC encoding, encrypted using the client's secret + key and a key usage value of 1. + + + +Neuman, et al. Standards Track [Page 61] + +RFC 4120 Kerberos V5 July 2005 + + + This pre-authentication type was not present in RFC 1510, but many + implementations support it. + +5.2.7.3. PA-PW-SALT + + The padata-value for this pre-authentication type contains the salt + for the string-to-key to be used by the client to obtain the key for + decrypting the encrypted part of an AS-REP message. Unfortunately, + for historical reasons, the character set to be used is unspecified + and probably locale-specific. + + This pre-authentication type was not present in RFC 1510, but many + implementations support it. It is necessary in any case where the + salt for the string-to-key algorithm is not the default. + + In the trivial example, a zero-length salt string is very commonplace + for realms that have converted their principal databases from + Kerberos Version 4. + + A KDC SHOULD NOT send PA-PW-SALT when issuing a KRB-ERROR message + that requests additional pre-authentication. Implementation note: + Some KDC implementations issue an erroneous PA-PW-SALT when issuing a + KRB-ERROR message that requests additional pre-authentication. + Therefore, clients SHOULD ignore a PA-PW-SALT accompanying a + KRB-ERROR message that requests additional pre-authentication. As + noted in section 3.1.3, a KDC MUST NOT send PA-PW-SALT when the + client's AS-REQ includes at least one "newer" etype. + +5.2.7.4. PA-ETYPE-INFO + + The ETYPE-INFO pre-authentication type is sent by the KDC in a + KRB-ERROR indicating a requirement for additional pre-authentication. + It is usually used to notify a client of which key to use for the + encryption of an encrypted timestamp for the purposes of sending a + PA-ENC-TIMESTAMP pre-authentication value. It MAY also be sent in an + AS-REP to provide information to the client about which key salt to + use for the string-to-key to be used by the client to obtain the key + for decrypting the encrypted part the AS-REP. + + ETYPE-INFO-ENTRY ::= SEQUENCE { + etype [0] Int32, + salt [1] OCTET STRING OPTIONAL + } + + ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY + + The salt, like that of PA-PW-SALT, is also completely unspecified + with respect to character set and is probably locale-specific. + + + +Neuman, et al. Standards Track [Page 62] + +RFC 4120 Kerberos V5 July 2005 + + + If ETYPE-INFO is sent in an AS-REP, there shall be exactly one + ETYPE-INFO-ENTRY, and its etype shall match that of the enc-part in + the AS-REP. + + This pre-authentication type was not present in RFC 1510, but many + implementations that support encrypted timestamps for pre- + authentication need to support ETYPE-INFO as well. As noted in + Section 3.1.3, a KDC MUST NOT send PA-ETYPE-INFO when the client's + AS-REQ includes at least one "newer" etype. + +5.2.7.5. PA-ETYPE-INFO2 + + The ETYPE-INFO2 pre-authentication type is sent by the KDC in a + KRB-ERROR indicating a requirement for additional pre-authentication. + It is usually used to notify a client of which key to use for the + encryption of an encrypted timestamp for the purposes of sending a + PA-ENC-TIMESTAMP pre-authentication value. It MAY also be sent in an + AS-REP to provide information to the client about which key salt to + use for the string-to-key to be used by the client to obtain the key + for decrypting the encrypted part the AS-REP. + +ETYPE-INFO2-ENTRY ::= SEQUENCE { + etype [0] Int32, + salt [1] KerberosString OPTIONAL, + s2kparams [2] OCTET STRING OPTIONAL +} + +ETYPE-INFO2 ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY + + The type of the salt is KerberosString, but existing installations + might have locale-specific characters stored in salt strings, and + implementors MAY choose to handle them. + + The interpretation of s2kparams is specified in the cryptosystem + description associated with the etype. Each cryptosystem has a + default interpretation of s2kparams that will hold if that element is + omitted from the encoding of ETYPE-INFO2-ENTRY. + + If ETYPE-INFO2 is sent in an AS-REP, there shall be exactly one + ETYPE-INFO2-ENTRY, and its etype shall match that of the enc-part in + the AS-REP. + + The preferred ordering of the "hint" pre-authentication data that + affect client key selection is: ETYPE-INFO2, followed by ETYPE-INFO, + followed by PW-SALT. As noted in Section 3.1.3, a KDC MUST NOT send + ETYPE-INFO or PW-SALT when the client's AS-REQ includes at least one + "newer" etype. + + + + +Neuman, et al. Standards Track [Page 63] + +RFC 4120 Kerberos V5 July 2005 + + + The ETYPE-INFO2 pre-authentication type was not present in RFC 1510. + +5.2.8. KerberosFlags + + For several message types, a specific constrained bit string type, + KerberosFlags, is used. + + KerberosFlags ::= BIT STRING (SIZE (32..MAX)) + -- minimum number of bits shall be sent, + -- but no fewer than 32 + + Compatibility note: The following paragraphs describe a change from + the RFC 1510 description of bit strings that would result in + incompatility in the case of an implementation that strictly + conformed to ASN.1 DER and RFC 1510. + + ASN.1 bit strings have multiple uses. The simplest use of a bit + string is to contain a vector of bits, with no particular meaning + attached to individual bits. This vector of bits is not necessarily + a multiple of eight bits long. The use in Kerberos of a bit string + as a compact boolean vector wherein each element has a distinct + meaning poses some problems. The natural notation for a compact + boolean vector is the ASN.1 "NamedBit" notation, and the DER require + that encodings of a bit string using "NamedBit" notation exclude any + trailing zero bits. This truncation is easy to neglect, especially + given C language implementations that naturally choose to store + boolean vectors as 32-bit integers. + + For example, if the notation for KDCOptions were to include the + "NamedBit" notation, as in RFC 1510, and a KDCOptions value to be + encoded had only the "forwardable" (bit number one) bit set, the DER + encoding MUST include only two bits: the first reserved bit + ("reserved", bit number zero, value zero) and the one-valued bit (bit + number one) for "forwardable". + + Most existing implementations of Kerberos unconditionally send 32 + bits on the wire when encoding bit strings used as boolean vectors. + This behavior violates the ASN.1 syntax used for flag values in RFC + 1510, but it occurs on such a widely installed base that the protocol + description is being modified to accommodate it. + + Consequently, this document removes the "NamedBit" notations for + individual bits, relegating them to comments. The size constraint on + the KerberosFlags type requires that at least 32 bits be encoded at + all times, though a lenient implementation MAY choose to accept fewer + than 32 bits and to treat the missing bits as set to zero. + + + + + +Neuman, et al. Standards Track [Page 64] + +RFC 4120 Kerberos V5 July 2005 + + + Currently, no uses of KerberosFlags specify more than 32 bits' worth + of flags, although future revisions of this document may do so. When + more than 32 bits are to be transmitted in a KerberosFlags value, + future revisions to this document will likely specify that the + smallest number of bits needed to encode the highest-numbered one- + valued bit should be sent. This is somewhat similar to the DER + encoding of a bit string that is declared with the "NamedBit" + notation. + +5.2.9. Cryptosystem-Related Types + + Many Kerberos protocol messages contain an EncryptedData as a + container for arbitrary encrypted data, which is often the encrypted + encoding of another data type. Fields within EncryptedData assist + the recipient in selecting a key with which to decrypt the enclosed + data. + + EncryptedData ::= SEQUENCE { + etype [0] Int32 -- EncryptionType --, + kvno [1] UInt32 OPTIONAL, + cipher [2] OCTET STRING -- ciphertext + } + + etype + This field identifies which encryption algorithm was used to + encipher the cipher. + + kvno + This field contains the version number of the key under which data + is encrypted. It is only present in messages encrypted under long + lasting keys, such as principals' secret keys. + + cipher + This field contains the enciphered text, encoded as an OCTET + STRING. (Note that the encryption mechanisms defined in [RFC3961] + MUST incorporate integrity protection as well, so no additional + checksum is required.) + + The EncryptionKey type is the means by which cryptographic keys used + for encryption are transferred. + + EncryptionKey ::= SEQUENCE { + keytype [0] Int32 -- actually encryption type --, + keyvalue [1] OCTET STRING + } + + + + + + +Neuman, et al. Standards Track [Page 65] + +RFC 4120 Kerberos V5 July 2005 + + + keytype + This field specifies the encryption type of the encryption key + that follows in the keyvalue field. Although its name is + "keytype", it actually specifies an encryption type. Previously, + multiple cryptosystems that performed encryption differently but + were capable of using keys with the same characteristics were + permitted to share an assigned number to designate the type of + key; this usage is now deprecated. + + keyvalue + This field contains the key itself, encoded as an octet string. + + Messages containing cleartext data to be authenticated will usually + do so by using a member of type Checksum. Most instances of Checksum + use a keyed hash, though exceptions will be noted. + + Checksum ::= SEQUENCE { + cksumtype [0] Int32, + checksum [1] OCTET STRING + } + + cksumtype + This field indicates the algorithm used to generate the + accompanying checksum. + + checksum + This field contains the checksum itself, encoded as an octet + string. + + See Section 4 for a brief description of the use of encryption and + checksums in Kerberos. + +5.3. Tickets + + This section describes the format and encryption parameters for + tickets and authenticators. When a ticket or authenticator is + included in a protocol message, it is treated as an opaque object. A + ticket is a record that helps a client authenticate to a service. A + Ticket contains the following information: + + Ticket ::= [APPLICATION 1] SEQUENCE { + tkt-vno [0] INTEGER (5), + realm [1] Realm, + sname [2] PrincipalName, + enc-part [3] EncryptedData -- EncTicketPart + } + + -- Encrypted part of ticket + + + +Neuman, et al. Standards Track [Page 66] + +RFC 4120 Kerberos V5 July 2005 + + + EncTicketPart ::= [APPLICATION 3] 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 + } + + -- encoded Transited field + TransitedEncoding ::= SEQUENCE { + tr-type [0] Int32 -- must be registered --, + contents [1] OCTET STRING + } + + TicketFlags ::= KerberosFlags + -- 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), + -- the following are new since 1510 + -- transited-policy-checked(12), + -- ok-as-delegate(13) + + tkt-vno + This field specifies the version number for the ticket format. + This document describes version number 5. + + realm + This field specifies the realm that issued a ticket. It also + serves to identify the realm part of the server's principal + identifier. Since a Kerberos server can only issue tickets for + servers within its realm, the two will always be identical. + + + + + +Neuman, et al. Standards Track [Page 67] + +RFC 4120 Kerberos V5 July 2005 + + + sname + This field specifies all components of the name part of the + server's identity, including those parts that identify a specific + instance of a service. + + enc-part + This field holds the encrypted encoding of the EncTicketPart + sequence. It is encrypted in the key shared by Kerberos and the + end server (the server's secret key), using a key usage value of + 2. + + flags + This field indicates which of various options were used or + requested when the ticket was issued. The meanings of the flags + are as follows: + + Bit(s) Name Description + + 0 reserved Reserved for future expansion of this field. + + 1 forwardable The FORWARDABLE flag is normally only + interpreted by the TGS, and can be ignored + by end servers. When set, this flag tells + the ticket-granting server that it is OK to + issue a new TGT with a different network + address based on the presented ticket. + + 2 forwarded When set, this flag indicates that the + ticket has either been forwarded or was + issued based on authentication involving a + forwarded TGT. + + 3 proxiable The PROXIABLE flag is normally only + interpreted by the TGS, and can be ignored + by end servers. The PROXIABLE flag has an + interpretation identical to that of the + FORWARDABLE flag, except that the PROXIABLE + flag tells the ticket-granting server that + only non-TGTs may be issued with different + network addresses. + + 4 proxy When set, this flag indicates that a ticket + is a proxy. + + 5 may-postdate The MAY-POSTDATE flag is normally only + interpreted by the TGS, and can be ignored + by end servers. This flag tells the + + + + +Neuman, et al. Standards Track [Page 68] + +RFC 4120 Kerberos V5 July 2005 + + + ticket-granting server that a post-dated + ticket MAY be issued based on this TGT. + + 6 postdated This flag indicates that this ticket has + been postdated. The end-service can check + the authtime field to see when the original + authentication occurred. + + 7 invalid This flag indicates that a ticket is + invalid, and it must be validated by the KDC + before use. Application servers must reject + tickets which have this flag set. + + 8 renewable The RENEWABLE flag is normally only + interpreted by the TGS, and can usually be + ignored by end servers (some particularly + careful servers MAY disallow renewable + tickets). A renewable ticket can be used to + obtain a replacement ticket that expires at + a later date. + + 9 initial This flag indicates that this ticket was + issued using the AS protocol, and not issued + based on a TGT. + + 10 pre-authent This flag indicates that during initial + authentication, the client was authenticated + by the KDC before a ticket was issued. The + strength of the pre-authentication method is + not indicated, but is acceptable to the KDC. + + 11 hw-authent This flag indicates that the protocol + employed for initial authentication required + the use of hardware expected to be possessed + solely by the named client. The hardware + authentication method is selected by the KDC + and the strength of the method is not + indicated. + + 12 transited- This flag indicates that the KDC for + policy-checked the realm has checked the transited field + against a realm-defined policy for trusted + certifiers. If this flag is reset (0), then + the application server must check the + transited field itself, and if unable to do + so, it must reject the authentication. If + the flag is set (1), then the application + server MAY skip its own validation of the + + + +Neuman, et al. Standards Track [Page 69] + +RFC 4120 Kerberos V5 July 2005 + + + transited field, relying on the validation + performed by the KDC. At its option the + application server MAY still apply its own + validation based on a separate policy for + acceptance. + + This flag is new since RFC 1510. + + 13 ok-as-delegate This flag indicates that the server (not the + client) 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 + decide whether to delegate credentials + (either grant a proxy or a forwarded TGT) to + this server. The client is free 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. + + This flag is new since RFC 1510. + + 14-31 reserved Reserved for future use. + + key + This field exists in the ticket and the KDC response and is used + to pass the session key from Kerberos to the application server + and the client. + + crealm + This field contains the name of the realm in which the client is + registered and in which initial authentication took place. + + cname + This field contains the name part of the client's principal + identifier. + + transited + This field lists the names of the Kerberos realms that took part + in authenticating the user to whom this ticket was issued. It + does not specify the order in which the realms were transited. + See Section 3.3.3.2 for details on how this field encodes the + traversed realms. When the names of CAs are to be embedded in the + transited field (as specified for some extensions to the + + + + +Neuman, et al. Standards Track [Page 70] + +RFC 4120 Kerberos V5 July 2005 + + + protocol), the X.500 names of the CAs SHOULD be mapped into items + in the transited field using the mapping defined by RFC 2253. + + authtime + This field indicates the time of initial authentication for the + named principal. It is the time of issue for the original ticket + on which this ticket is based. It is included in the ticket to + provide additional information to the end service, and to provide + the necessary information for implementation of a "hot list" + service at the KDC. An end service that is particularly paranoid + could refuse to accept tickets for which the initial + authentication occurred "too far" in the past. This field is also + returned as part of the response from the KDC. When it is + returned as part of the response to initial authentication + (KRB_AS_REP), this is the current time on the Kerberos server. It + is NOT recommended that this time value be used to adjust the + workstation's clock, as the workstation cannot reliably determine + that such a KRB_AS_REP actually came from the proper KDC in a + timely manner. + + starttime + This field in the ticket specifies the time after which the ticket + is valid. Together with endtime, this field specifies the life of + the ticket. If the starttime field is absent from the ticket, + then the authtime field SHOULD be used in its place to determine + the life of the ticket. + + endtime + This field 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 field 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. + + caddr + This field in a ticket contains zero (if omitted) or more (if + present) host addresses. These are the addresses from which the + ticket can be used. If there are no addresses, the ticket can be + used from any location. The decision by the KDC to issue or by + the end server to accept addressless tickets is a policy decision + and is left to the Kerberos and end-service administrators; they + MAY refuse to issue or accept such tickets. Because of the wide + + + +Neuman, et al. Standards Track [Page 71] + +RFC 4120 Kerberos V5 July 2005 + + + deployment of network address translation, it is recommended that + policy allow the issue and acceptance of such tickets. + + Network addresses are included in the ticket to make it harder for + an attacker to use stolen credentials. Because the session key is + not sent over the network in cleartext, credentials can't be + stolen simply by listening to the network; an attacker has to gain + access to the session key (perhaps through operating system + security breaches or a careless user's unattended session) to make + use of stolen tickets. + + Note that the network address from which a connection is received + cannot be reliably determined. Even if it could be, an attacker + who has compromised the client's workstation could use the + credentials from there. Including the network addresses only + makes it more difficult, not impossible, for an attacker to walk + off with stolen credentials and then to use them from a "safe" + location. + + authorization-data + The authorization-data field is used to pass authorization data + from the principal on whose behalf a ticket was issued to the + application service. If no authorization data is included, this + field will be left out. Experience has shown that the name of + this field is confusing, and that a better name would be + "restrictions". Unfortunately, it is not possible to change the + name at this time. + + This field contains restrictions on any authority obtained on the + basis of authentication using the ticket. It is possible for any + principal in possession of credentials to add entries to the + authorization data field since these entries further restrict what + can be done with the ticket. Such additions can be made by + specifying the additional entries when a new ticket is obtained + during the TGS exchange, or they MAY be added during chained + delegation using the authorization data field of the + authenticator. + + Because entries may be added to this field by the holder of + credentials, except when an entry is separately authenticated by + encapsulation in the KDC-issued element, it is not allowable for + the presence of an entry in the authorization data field of a + ticket to amplify the privileges one would obtain from using a + ticket. + + The data in this field may be specific to the end service; the + field will contain the names of service specific objects, and the + rights to those objects. The format for this field is described + + + +Neuman, et al. Standards Track [Page 72] + +RFC 4120 Kerberos V5 July 2005 + + + in Section 5.2.6. Although Kerberos is not concerned with the + format of the contents of the subfields, it does carry type + information (ad-type). + + By using the authorization_data field, a principal is able to + issue a proxy that is valid for a specific purpose. For example, + a client wishing to print a file can obtain a file server proxy to + be passed to the print server. By specifying the name of the file + in the authorization_data field, the file server knows that the + print server can only use the client's rights when accessing the + particular file to be printed. + + A separate service providing authorization or certifying group + membership may be built using the authorization-data field. In + this case, the entity granting authorization (not the authorized + entity) may obtain a ticket in its own name (e.g., the ticket is + issued in the name of a privilege server), and this entity adds + restrictions on its own authority and delegates the restricted + authority through a proxy to the client. The client would then + present this authorization credential to the application server + separately from the authentication exchange. Alternatively, such + authorization credentials MAY be embedded in the ticket + authenticating the authorized entity, when the authorization is + separately authenticated using the KDC-issued authorization data + element (see 5.2.6.2). + + Similarly, if one specifies the authorization-data field of a + proxy and leaves the host addresses blank, the resulting ticket + and session key can be treated as a capability. See [Neu93] for + some suggested uses of this field. + + The authorization-data field is optional and does not have to be + included in a ticket. + +5.4. Specifications for the AS and TGS Exchanges + + This section specifies the format of the messages used in the + exchange between the client and the Kerberos server. The format of + possible error messages appears in Section 5.9.1. + +5.4.1. KRB_KDC_REQ Definition + + The KRB_KDC_REQ message has no application tag number of its own. + Instead, it is incorporated into either KRB_AS_REQ or KRB_TGS_REQ, + each of which has an application tag, depending on whether the + request is for an initial ticket or an additional ticket. In either + case, the message is sent from the client to the KDC to request + credentials for a service. + + + +Neuman, et al. Standards Track [Page 73] + +RFC 4120 Kerberos V5 July 2005 + + + The message fields are as follows: + +AS-REQ ::= [APPLICATION 10] KDC-REQ + +TGS-REQ ::= [APPLICATION 12] KDC-REQ + +KDC-REQ ::= SEQUENCE { + -- NOTE: first tag is [1], not [0] + pvno [1] INTEGER (5) , + msg-type [2] INTEGER (10 -- AS -- | 12 -- TGS --), + padata [3] SEQUENCE OF PA-DATA OPTIONAL + -- NOTE: not empty --, + req-body [4] KDC-REQ-BODY +} + +KDC-REQ-BODY ::= 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, + rtime [6] KerberosTime OPTIONAL, + nonce [7] UInt32, + etype [8] SEQUENCE OF Int32 -- EncryptionType + -- in preference order --, + addresses [9] HostAddresses OPTIONAL, + enc-authorization-data [10] EncryptedData OPTIONAL + -- AuthorizationData --, + additional-tickets [11] SEQUENCE OF Ticket OPTIONAL + -- NOTE: not empty +} + +KDCOptions ::= KerberosFlags + -- reserved(0), + -- forwardable(1), + -- forwarded(2), + -- proxiable(3), + -- proxy(4), + -- allow-postdate(5), + -- postdated(6), + -- unused7(7), + -- renewable(8), + -- unused9(9), + -- unused10(10), + + + +Neuman, et al. Standards Track [Page 74] + +RFC 4120 Kerberos V5 July 2005 + + + -- opt-hardware-auth(11), + -- unused12(12), + -- unused13(13), +-- 15 is reserved for canonicalize + -- unused15(15), +-- 26 was unused in 1510 + -- disable-transited-check(26), +-- + -- renewable-ok(27), + -- enc-tkt-in-skey(28), + -- renew(30), + -- validate(31) + + The fields in this message are as follows: + + pvno + This field is included in each message, and specifies the protocol + version number. This document specifies protocol version 5. + + msg-type + This field indicates the type of a protocol message. It will + almost always be the same as the application identifier associated + with a message. It is included to make the identifier more + readily accessible to the application. For the KDC-REQ message, + this type will be KRB_AS_REQ or KRB_TGS_REQ. + + padata + Contains pre-authentication data. Requests for additional tickets + (KRB_TGS_REQ) MUST contain a padata of PA-TGS-REQ. + + The padata (pre-authentication data) field contains a sequence of + authentication information that may be needed before credentials + can be issued or decrypted. + + req-body + This field is a placeholder delimiting the extent of the remaining + fields. If a checksum is to be calculated over the request, it is + calculated over an encoding of the KDC-REQ-BODY sequence which is + enclosed within the req-body field. + + kdc-options + This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to + the KDC and indicates the flags that the client wants set on the + tickets as well as other information that is to modify the + behavior of the KDC. Where appropriate, the name of an option may + be the same as the flag that is set by that option. Although in + most cases, the bit in the options field will be the same as that + in the flags field, this is not guaranteed, so it is not + + + +Neuman, et al. Standards Track [Page 75] + +RFC 4120 Kerberos V5 July 2005 + + + acceptable simply to copy the options field to the flags field. + There are various checks that must be made before an option is + honored anyway. + + The kdc_options field is a bit-field, where the selected options + are indicated by the bit being set (1), and the unselected options + and reserved fields being reset (0). The encoding of the bits is + specified in Section 5.2. The options are described in more + detail above in Section 2. The meanings of the options are as + follows: + + Bits Name Description + + 0 RESERVED Reserved for future expansion of + this field. + + 1 FORWARDABLE The FORWARDABLE option indicates + that the ticket to be issued is to + have its forwardable flag set. It + may only be set on the initial + request, or in a subsequent request + if the TGT on which it is based is + also forwardable. + + 2 FORWARDED The FORWARDED option is only + specified in a request to the + ticket-granting server and will only + be honored if the TGT in the request + has its FORWARDABLE bit set. This + option indicates that this is a + request for forwarding. The + address(es) of the host from which + the resulting ticket is to be valid + are included in the addresses field + of the request. + + 3 PROXIABLE The PROXIABLE option indicates that + the ticket to be issued is to have + its proxiable flag set. It may only + be set on the initial request, or a + subsequent request if the TGT on + which it is based is also proxiable. + + 4 PROXY The PROXY option indicates that this + is a request for a proxy. This + option will only be honored if the + TGT in the request has its PROXIABLE + bit set. The address(es) of the + + + +Neuman, et al. Standards Track [Page 76] + +RFC 4120 Kerberos V5 July 2005 + + + host from which the resulting ticket + is to be valid are included in the + addresses field of the request. + + 5 ALLOW-POSTDATE The ALLOW-POSTDATE option indicates + that the ticket to be issued is to + have its MAY-POSTDATE flag set. It + may only be set on the initial + request, or in a subsequent request + if the TGT on which it is based also + has its MAY-POSTDATE flag set. + + 6 POSTDATED The POSTDATED option indicates that + this is a request for a postdated + ticket. This option will only be + honored if the TGT on which it is + based has its MAY-POSTDATE flag set. + The resulting ticket will also have + its INVALID flag set, and that flag + may be reset by a subsequent request + to the KDC after the starttime in + the ticket has been reached. + + 7 RESERVED This option is presently unused. + + 8 RENEWABLE The RENEWABLE option indicates that + the ticket to be issued is to have + its RENEWABLE flag set. It may only + be set on the initial request, or + when the TGT on which the request is + based is also renewable. If this + option is requested, then the rtime + field in the request contains the + desired absolute expiration time for + the ticket. + + 9 RESERVED Reserved for PK-Cross. + + 10 RESERVED Reserved for future use. + + 11 RESERVED Reserved for opt-hardware-auth. + + 12-25 RESERVED Reserved for future use. + + 26 DISABLE-TRANSITED-CHECK By default the KDC will check the + transited field of a TGT against the + policy of the local realm before it + will issue derivative tickets based + + + +Neuman, et al. Standards Track [Page 77] + +RFC 4120 Kerberos V5 July 2005 + + + on the TGT. If this flag is set in + the request, checking of the + transited field is disabled. + Tickets issued without the + performance of this check will be + noted by the reset (0) value of the + TRANSITED-POLICY-CHECKED flag, + indicating to the application server + that the transited field must be + checked locally. KDCs are + encouraged but not required to honor + the DISABLE-TRANSITED-CHECK option. + + This flag is new since RFC 1510. + + 27 RENEWABLE-OK The RENEWABLE-OK option indicates + that a renewable ticket will be + acceptable if a ticket with the + requested life cannot otherwise be + provided, in which case a renewable + ticket may be issued with a renew- + till equal to the requested endtime. + The value of the renew-till field + may still be limited by local + limits, or limits selected by the + individual principal or server. + + 28 ENC-TKT-IN-SKEY This option is used only by the + ticket-granting service. The ENC- + TKT-IN-SKEY option indicates that + the ticket for the end server is to + be encrypted in the session key from + the additional TGT provided. + + 29 RESERVED Reserved for future use. + + 30 RENEW This option is used only by the + ticket-granting service. The RENEW + option indicates that the present + request is for a renewal. The + ticket provided is encrypted in the + secret key for the server on which + it is valid. This option will only + be honored if the ticket to be + renewed has its RENEWABLE flag set + and if the time in its renew-till + field has not passed. The ticket to + be renewed is passed in the padata + + + +Neuman, et al. Standards Track [Page 78] + +RFC 4120 Kerberos V5 July 2005 + + + field as part of the authentication + header. + + 31 VALIDATE This option is used only by the + ticket-granting service. The + VALIDATE option indicates that the + request is to validate a postdated + ticket. It will only be honored if + the ticket presented is postdated, + presently has its INVALID flag set, + and would otherwise be usable at + this time. A ticket cannot be + validated before its starttime. The + ticket presented for validation is + encrypted in the key of the server + for which it is valid and is passed + in the padata field as part of the + authentication header. + + cname and sname + These fields are the same as those described for the ticket in + section 5.3. The sname may only be absent when the ENC-TKT-IN- + SKEY option is specified. If the sname is absent, the name of the + server is taken from the name of the client in the ticket passed + as additional-tickets. + + enc-authorization-data + The enc-authorization-data, if present (and it can only be present + in the TGS_REQ form), is an encoding of the desired + authorization-data encrypted under the sub-session key if present + in the Authenticator, or alternatively from the session key in the + TGT (both the Authenticator and TGT come from the padata field in + the KRB_TGS_REQ). The key usage value used when encrypting is 5 + if a sub-session key is used, or 4 if the session key is used. + + realm + This field specifies the realm part of the server's principal + identifier. In the AS exchange, this is also the realm part of + the client's principal identifier. + + from + This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket + requests when the requested ticket is to be postdated. It + specifies the desired starttime for the requested ticket. If this + field is omitted, then the KDC SHOULD use the current time + instead. + + + + + +Neuman, et al. Standards Track [Page 79] + +RFC 4120 Kerberos V5 July 2005 + + + till + This field contains the expiration date requested by the client in + a ticket request. It is not optional, but if the requested + endtime is "19700101000000Z", the requested ticket is to have the + maximum endtime permitted according to KDC policy. Implementation + note: This special timestamp corresponds to a UNIX time_t value of + zero on most systems. + + rtime + This field is the requested renew-till time sent from a client to + the KDC in a ticket request. It is optional. + + nonce + This field is part of the KDC request and response. It is + intended to hold a random number generated by the client. If the + same number is included in the encrypted response from the KDC, it + provides evidence that the response is fresh and has not been + replayed by an attacker. Nonces MUST NEVER be reused. + + etype + This field specifies the desired encryption algorithm to be used + in the response. + + addresses + This field is included in the initial request for tickets, and it + is optionally included in requests for additional tickets from the + ticket-granting server. It specifies the addresses from which the + requested ticket is to be valid. Normally it includes the + addresses for the client's host. If a proxy is requested, this + field will contain other addresses. The contents of this field + are usually copied by the KDC into the caddr field of the + resulting ticket. + + additional-tickets + Additional tickets MAY be optionally included in a request to the + ticket-granting server. If the ENC-TKT-IN-SKEY option has been + specified, then the session key from the additional ticket will be + used in place of the server's key to encrypt the new ticket. When + the ENC-TKT-IN-SKEY option is used for user-to-user + authentication, this additional ticket MAY be a TGT issued by the + local realm or an inter-realm TGT issued for the current KDC's + realm by a remote KDC. If more than one option that requires + additional tickets has been specified, then the additional tickets + are used in the order specified by the ordering of the options + bits (see kdc-options, above). + + + + + + +Neuman, et al. Standards Track [Page 80] + +RFC 4120 Kerberos V5 July 2005 + + + The application tag number will be either ten (10) or twelve (12) + depending on whether the request is for an initial ticket (AS-REQ) or + for an additional ticket (TGS-REQ). + + The optional fields (addresses, authorization-data, and additional- + tickets) are only included if necessary to perform the operation + specified in the kdc-options field. + + Note that in KRB_TGS_REQ, the protocol version number appears twice + and two different message types appear: the KRB_TGS_REQ message + contains these fields as does the authentication header (KRB_AP_REQ) + that is passed in the padata field. + +5.4.2. KRB_KDC_REP Definition + + The KRB_KDC_REP message format is used for the reply from the KDC for + either an initial (AS) request or a subsequent (TGS) request. There + is no message type for KRB_KDC_REP. Instead, the type will be either + KRB_AS_REP or KRB_TGS_REP. The key used to encrypt the ciphertext + part of the reply depends on the message type. For KRB_AS_REP, the + ciphertext is encrypted in the client's secret key, and the client's + key version number is included in the key version number for the + encrypted data. For KRB_TGS_REP, the ciphertext is encrypted in the + sub-session key from the Authenticator; if it is absent, the + ciphertext is encrypted in the session key from the TGT used in the + request. In that case, no version number will be present in the + EncryptedData sequence. + + The KRB_KDC_REP message contains the following fields: + + AS-REP ::= [APPLICATION 11] KDC-REP + + TGS-REP ::= [APPLICATION 13] KDC-REP + + KDC-REP ::= SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (11 -- AS -- | 13 -- TGS --), + padata [2] SEQUENCE OF PA-DATA OPTIONAL + -- NOTE: not empty --, + crealm [3] Realm, + cname [4] PrincipalName, + ticket [5] Ticket, + enc-part [6] EncryptedData + -- EncASRepPart or EncTGSRepPart, + -- as appropriate + } + + EncASRepPart ::= [APPLICATION 25] EncKDCRepPart + + + +Neuman, et al. Standards Track [Page 81] + +RFC 4120 Kerberos V5 July 2005 + + + EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart + + EncKDCRepPart ::= SEQUENCE { + key [0] EncryptionKey, + last-req [1] LastReq, + nonce [2] UInt32, + 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 + } + + LastReq ::= SEQUENCE OF SEQUENCE { + lr-type [0] Int32, + lr-value [1] KerberosTime + } + + pvno and msg-type + These fields are described above in Section 5.4.1. msg-type is + either KRB_AS_REP or KRB_TGS_REP. + + padata + This field is described in detail in Section 5.4.1. One possible + use for it is to encode an alternate "salt" string to be used with + a string-to-key algorithm. This ability is useful for easing + transitions if a realm name needs to change (e.g., when a company + is acquired); in such a case all existing password-derived entries + in the KDC database would be flagged as needing a special salt + string until the next password change. + + crealm, cname, srealm, and sname + These fields are the same as those described for the ticket in + section 5.3. + + ticket + The newly-issued ticket, from Section 5.3. + + enc-part + This field is a place holder for the ciphertext and related + information that forms the encrypted part of a message. The + description of the encrypted part of the message follows each + appearance of this field. + + + + +Neuman, et al. Standards Track [Page 82] + +RFC 4120 Kerberos V5 July 2005 + + + The key usage value for encrypting this field is 3 in an AS-REP + message, using the client's long-term key or another key selected + via pre-authentication mechanisms. In a TGS-REP message, the key + usage value is 8 if the TGS session key is used, or 9 if a TGS + authenticator subkey is used. + + Compatibility note: Some implementations unconditionally send an + encrypted EncTGSRepPart (application tag number 26) in this field + regardless of whether the reply is a AS-REP or a TGS-REP. In the + interest of compatibility, implementors MAY relax the check on the + tag number of the decrypted ENC-PART. + + key + This field is the same as described for the ticket in Section 5.3. + + last-req + This field is returned by the KDC and specifies the time(s) of the + last request by a principal. Depending on what information is + available, this might be the last time that a request for a TGT + was made, or the last time that a request based on a TGT was + successful. It also might cover all servers for a realm, or just + the particular server. Some implementations MAY display this + information to the user to aid in discovering unauthorized use of + one's identity. It is similar in spirit to the last login time + displayed when logging in to timesharing systems. + + lr-type + This field indicates how the following lr-value field is to be + interpreted. Negative values indicate that the information + pertains only to the responding server. Non-negative values + pertain to all servers for the realm. + + If the lr-type field is zero (0), then no information is conveyed + by the lr-value subfield. If the absolute value of the lr-type + field is one (1), then the lr-value subfield is the time of last + initial request for a TGT. If it is two (2), then the lr-value + subfield is the time of last initial request. If it is three (3), + then the lr-value subfield is the time of issue for the newest TGT + used. If it is four (4), then the lr-value subfield is the time + of the last renewal. If it is five (5), then the lr-value + subfield is the time of last request (of any type). If it is (6), + then the lr-value subfield is the time when the password will + expire. If it is (7), then the lr-value subfield is the time when + the account will expire. + + + + + + + +Neuman, et al. Standards Track [Page 83] + +RFC 4120 Kerberos V5 July 2005 + + + lr-value + This field contains the time of the last request. The time MUST + be interpreted according to the contents of the accompanying lr- + type subfield. + + nonce + This field is described above in Section 5.4.1. + + key-expiration + The key-expiration field is part of the response from the KDC and + specifies the time that the client's secret key is due to expire. + The expiration might be the result of password aging or an account + expiration. If present, it SHOULD be set to the earlier of the + user's key expiration and account expiration. The use of this + field is deprecated, and the last-req field SHOULD be used to + convey this information instead. This field will usually be left + out of the TGS reply since the response to the TGS request is + encrypted in a session key and no client information has to be + retrieved from the KDC database. It is up to the application + client (usually the login program) to take appropriate action + (such as notifying the user) if the expiration time is imminent. + + flags, authtime, starttime, endtime, renew-till and caddr + These fields are duplicates of those found in the encrypted + portion of the attached ticket (see Section 5.3), provided so the + client MAY verify that they match the intended request and in + order to assist in proper ticket caching. If the message is of + type KRB_TGS_REP, the caddr field will only be filled in if the + request was for a proxy or forwarded ticket, or if the user is + substituting a subset of the addresses from the TGT. If the + client-requested addresses are not present or not used, then the + addresses contained in the ticket will be the same as those + included in the TGT. + +5.5. Client/Server (CS) Message Specifications + + This section specifies the format of the messages used for the + authentication of the client to the application server. + +5.5.1. KRB_AP_REQ Definition + + The KRB_AP_REQ message contains the Kerberos protocol version number, + the message type KRB_AP_REQ, an options field to indicate any options + in use, and the ticket and authenticator themselves. The KRB_AP_REQ + message is often referred to as the "authentication header". + + + + + + +Neuman, et al. Standards Track [Page 84] + +RFC 4120 Kerberos V5 July 2005 + + + AP-REQ ::= [APPLICATION 14] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (14), + ap-options [2] APOptions, + ticket [3] Ticket, + authenticator [4] EncryptedData -- Authenticator + } + + APOptions ::= KerberosFlags + -- reserved(0), + -- use-session-key(1), + -- mutual-required(2) + + pvno and msg-type + These fields are described above in Section 5.4.1. msg-type is + KRB_AP_REQ. + + ap-options + This field appears in the application request (KRB_AP_REQ) and + affects the way the request is processed. It is a bit-field, + where the selected options are indicated by the bit being set (1), + and the unselected options and reserved fields by being reset (0). + The encoding of the bits is specified in Section 5.2. The + meanings of the options are as follows: + + Bit(s) Name Description + + 0 reserved Reserved for future expansion of this field. + + 1 use-session-key The USE-SESSION-KEY option indicates that + the ticket the client is presenting to a + server is encrypted in the session key from + the server's TGT. When this option is not + specified, the ticket is encrypted in the + server's secret key. + + 2 mutual-required The MUTUAL-REQUIRED option tells the server + that the client requires mutual + authentication, and that it must respond + with a KRB_AP_REP message. + + 3-31 reserved Reserved for future use. + + ticket + This field is a ticket authenticating the client to the server. + + + + + + +Neuman, et al. Standards Track [Page 85] + +RFC 4120 Kerberos V5 July 2005 + + + authenticator + This contains the encrypted authenticator, which includes the + client's choice of a subkey. + + The encrypted authenticator is included in the AP-REQ; it certifies + to a server that the sender has recent knowledge of the encryption + key in the accompanying ticket, to help the server detect replays. + It also assists in the selection of a "true session key" to use with + the particular session. The DER encoding of the following is + encrypted in the ticket's session key, with a key usage value of 11 + in normal application exchanges, or 7 when used as the PA-TGS-REQ + PA-DATA field of a TGS-REQ exchange (see Section 5.4.1): + + -- Unencrypted authenticator + Authenticator ::= [APPLICATION 2] SEQUENCE { + authenticator-vno [0] INTEGER (5), + crealm [1] Realm, + cname [2] PrincipalName, + cksum [3] Checksum OPTIONAL, + cusec [4] Microseconds, + ctime [5] KerberosTime, + subkey [6] EncryptionKey OPTIONAL, + seq-number [7] UInt32 OPTIONAL, + authorization-data [8] AuthorizationData OPTIONAL + } + + authenticator-vno + This field specifies the version number for the format of the + authenticator. This document specifies version 5. + + crealm and cname + These fields are the same as those described for the ticket in + section 5.3. + + cksum + This field contains a checksum of the application data that + accompanies the KRB_AP_REQ, computed using a key usage value of 10 + in normal application exchanges, or 6 when used in the TGS-REQ + PA-TGS-REQ AP-DATA field. + + cusec + This field contains the microsecond part of the client's + timestamp. Its value (before encryption) ranges from 0 to 999999. + It often appears along with ctime. The two fields are used + together to specify a reasonably accurate timestamp. + + ctime + This field contains the current time on the client's host. + + + +Neuman, et al. Standards Track [Page 86] + +RFC 4120 Kerberos V5 July 2005 + + + subkey + This field contains the client's choice for an encryption key to + be used to protect this specific application session. Unless an + application specifies otherwise, if this field is left out, the + session key from the ticket will be used. + + seq-number + This optional field includes the initial sequence number to be + used by the KRB_PRIV or KRB_SAFE messages when sequence numbers + are used to detect replays. (It may also be used by application + specific messages.) When included in the authenticator, this + field specifies the initial sequence number for messages from the + client to the server. When included in the AP-REP message, the + initial sequence number is that for messages from the server to + the client. When used in KRB_PRIV or KRB_SAFE messages, it is + incremented by one after each message is sent. Sequence numbers + fall in the range 0 through 2^32 - 1 and wrap to zero following + the value 2^32 - 1. + + For sequence numbers to support the detection of replays + adequately, they SHOULD be non-repeating, even across connection + boundaries. The initial sequence number SHOULD be random and + uniformly distributed across the full space of possible sequence + numbers, so that it cannot be guessed by an attacker and so that + it and the successive sequence numbers do not repeat other + sequences. In the event that more than 2^32 messages are to be + generated in a series of KRB_PRIV or KRB_SAFE messages, rekeying + SHOULD be performed before sequence numbers are reused with the + same encryption key. + + Implmentation note: Historically, some implementations transmit + signed twos-complement numbers for sequence numbers. In the + interests of compatibility, implementations MAY accept the + equivalent negative number where a positive number greater than + 2^31 - 1 is expected. + + Implementation note: As noted before, some implementations omit + the optional sequence number when its value would be zero. + Implementations MAY accept an omitted sequence number when + expecting a value of zero, and SHOULD NOT transmit an + Authenticator with a initial sequence number of zero. + + authorization-data + This field is the same as described for the ticket in Section 5.3. + It is optional and will only appear when additional restrictions + are to be placed on the use of a ticket, beyond those carried in + the ticket itself. + + + + +Neuman, et al. Standards Track [Page 87] + +RFC 4120 Kerberos V5 July 2005 + + +5.5.2. KRB_AP_REP Definition + + The KRB_AP_REP message contains the Kerberos protocol version number, + the message type, and an encrypted time-stamp. The message is sent + in response to an application request (KRB_AP_REQ) for which the + mutual authentication option has been selected in the ap-options + field. + + AP-REP ::= [APPLICATION 15] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (15), + enc-part [2] EncryptedData -- EncAPRepPart + } + + EncAPRepPart ::= [APPLICATION 27] SEQUENCE { + ctime [0] KerberosTime, + cusec [1] Microseconds, + subkey [2] EncryptionKey OPTIONAL, + seq-number [3] UInt32 OPTIONAL + } + + The encoded EncAPRepPart is encrypted in the shared session key of + the ticket. The optional subkey field can be used in an + application-arranged negotiation to choose a per association session + key. + + pvno and msg-type + These fields are described above in Section 5.4.1. msg-type is + KRB_AP_REP. + + enc-part + This field is described above in Section 5.4.2. It is computed + with a key usage value of 12. + + ctime + This field contains the current time on the client's host. + + cusec + This field contains the microsecond part of the client's + timestamp. + + subkey + This field contains an encryption key that is to be used to + protect this specific application session. See Section 3.2.6 for + specifics on how this field is used to negotiate a key. Unless an + application specifies otherwise, if this field is left out, the + sub-session key from the authenticator or if the latter is also + left out, the session key from the ticket will be used. + + + +Neuman, et al. Standards Track [Page 88] + +RFC 4120 Kerberos V5 July 2005 + + + seq-number + This field is described above in Section 5.3.2. + +5.5.3. Error Message Reply + + If an error occurs while processing the application request, the + KRB_ERROR message will be sent in response. See Section 5.9.1 for + the format of the error message. The cname and crealm fields MAY be + left out if the server cannot determine their appropriate values from + the corresponding KRB_AP_REQ message. If the authenticator was + decipherable, the ctime and cusec fields will contain the values from + it. + +5.6. KRB_SAFE Message Specification + + This section specifies the format of a message that can be used by + either side (client or server) of an application to send a tamper- + proof message to its peer. It presumes that a session key has + previously been exchanged (for example, by using the + KRB_AP_REQ/KRB_AP_REP messages). + +5.6.1. KRB_SAFE definition + + The KRB_SAFE message contains user data along with a collision-proof + checksum keyed with the last encryption key negotiated via subkeys, + or with the session key if no negotiation has occurred. The message + fields are as follows: + + KRB-SAFE ::= [APPLICATION 20] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (20), + safe-body [2] KRB-SAFE-BODY, + cksum [3] Checksum + } + + KRB-SAFE-BODY ::= SEQUENCE { + user-data [0] OCTET STRING, + timestamp [1] KerberosTime OPTIONAL, + usec [2] Microseconds OPTIONAL, + seq-number [3] UInt32 OPTIONAL, + s-address [4] HostAddress, + r-address [5] HostAddress OPTIONAL + } + + pvno and msg-type + These fields are described above in Section 5.4.1. msg-type is + KRB_SAFE. + + + + +Neuman, et al. Standards Track [Page 89] + +RFC 4120 Kerberos V5 July 2005 + + + safe-body + This field is a placeholder for the body of the KRB-SAFE message. + + cksum + This field contains the checksum of the application data, computed + with a key usage value of 15. + + The checksum is computed over the encoding of the KRB-SAFE + sequence. First, the cksum is set to a type zero, zero-length + value, and the checksum is computed over the encoding of the KRB- + SAFE sequence. Then the checksum is set to the result of that + computation. Finally, the KRB-SAFE sequence is encoded again. + This method, although different than the one specified in RFC + 1510, corresponds to existing practice. + + user-data + This field is part of the KRB_SAFE and KRB_PRIV messages, and + contains the application-specific data that is being passed from + the sender to the recipient. + + timestamp + This field is part of the KRB_SAFE and KRB_PRIV messages. Its + contents are the current time as known by the sender of the + message. By checking the timestamp, the recipient of the message + is able to make sure that it was recently generated, and is not a + replay. + + usec + This field is part of the KRB_SAFE and KRB_PRIV headers. It + contains the microsecond part of the timestamp. + + seq-number + This field is described above in Section 5.3.2. + + s-address + Sender's address. + + This field specifies the address in use by the sender of the + message. + + r-address + This field specifies the address in use by the recipient of the + message. It MAY be omitted for some uses (such as broadcast + protocols), but the recipient MAY arbitrarily reject such + messages. This field, along with s-address, can be used to help + detect messages that have been incorrectly or maliciously + delivered to the wrong recipient. + + + + +Neuman, et al. Standards Track [Page 90] + +RFC 4120 Kerberos V5 July 2005 + + +5.7. KRB_PRIV Message Specification + + This section specifies the format of a message that can be used by + either side (client or server) of an application to send a message to + its peer securely and privately. It presumes that a session key has + previously been exchanged (for example, by using the + KRB_AP_REQ/KRB_AP_REP messages). + +5.7.1. KRB_PRIV Definition + + The KRB_PRIV message contains user data encrypted in the Session Key. + The message fields are as follows: + + KRB-PRIV ::= [APPLICATION 21] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (21), + -- NOTE: there is no [2] tag + enc-part [3] EncryptedData -- EncKrbPrivPart + } + + EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { + user-data [0] OCTET STRING, + timestamp [1] KerberosTime OPTIONAL, + usec [2] Microseconds OPTIONAL, + seq-number [3] UInt32 OPTIONAL, + s-address [4] HostAddress -- sender's addr --, + r-address [5] HostAddress OPTIONAL -- recip's addr + } + + pvno and msg-type + These fields are described above in Section 5.4.1. msg-type is + KRB_PRIV. + + enc-part + This field holds an encoding of the EncKrbPrivPart sequence + encrypted under the session key, with a key usage value of 13. + This encrypted encoding is used for the enc-part field of the + KRB-PRIV message. + + user-data, timestamp, usec, s-address, and r-address + These fields are described above in Section 5.6.1. + + seq-number + This field is described above in Section 5.3.2. + + + + + + + +Neuman, et al. Standards Track [Page 91] + +RFC 4120 Kerberos V5 July 2005 + + +5.8. KRB_CRED Message Specification + + This section specifies the format of a message that can be used to + send Kerberos credentials from one principal to another. It is + presented here to encourage a common mechanism to be used by + applications when forwarding tickets or providing proxies to + subordinate servers. It presumes that a session key has already been + exchanged, perhaps by using the KRB_AP_REQ/KRB_AP_REP messages. + +5.8.1. KRB_CRED Definition + + The KRB_CRED message contains a sequence of tickets to be sent and + information needed to use the tickets, including the session key from + each. The information needed to use the tickets is encrypted under + an encryption key previously exchanged or transferred alongside the + KRB_CRED message. The message fields are as follows: + + KRB-CRED ::= [APPLICATION 22] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (22), + tickets [2] SEQUENCE OF Ticket, + enc-part [3] EncryptedData -- EncKrbCredPart + } + + EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { + ticket-info [0] SEQUENCE OF KrbCredInfo, + nonce [1] UInt32 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 + } + + + + + +Neuman, et al. Standards Track [Page 92] + +RFC 4120 Kerberos V5 July 2005 + + + pvno and msg-type + These fields are described above in Section 5.4.1. msg-type is + KRB_CRED. + + tickets + These are the tickets obtained from the KDC specifically for use + by the intended recipient. Successive tickets are paired with the + corresponding KrbCredInfo sequence from the enc-part of the KRB- + CRED message. + + enc-part + This field holds an encoding of the EncKrbCredPart sequence + encrypted under the session key shared by the sender and the + intended recipient, with a key usage value of 14. This encrypted + encoding is used for the enc-part field of the KRB-CRED message. + + Implementation note: Implementations of certain applications, most + notably certain implementations of the Kerberos GSS-API mechanism, + do not separately encrypt the contents of the EncKrbCredPart of + the KRB-CRED message when sending it. In the case of those GSS- + API mechanisms, this is not a security vulnerability, as the + entire KRB-CRED message is itself embedded in an encrypted + message. + + nonce + If practical, an application MAY require the inclusion of a nonce + generated by the recipient of the message. If the same value is + included as the nonce in the message, it provides evidence that + the message is fresh and has not been replayed by an attacker. A + nonce MUST NEVER be reused. + + timestamp and usec + These fields specify the time that the KRB-CRED message was + generated. The time is used to provide assurance that the message + is fresh. + + s-address and r-address + These fields are described above in Section 5.6.1. They are used + optionally to provide additional assurance of the integrity of the + KRB-CRED message. + + key + This field exists in the corresponding ticket passed by the KRB- + CRED message and is used to pass the session key from the sender + to the intended recipient. The field's encoding is described in + Section 5.2.9. + + + + + +Neuman, et al. Standards Track [Page 93] + +RFC 4120 Kerberos V5 July 2005 + + + The following fields are optional. If present, they can be + associated with the credentials in the remote ticket file. If left + out, then it is assumed that the recipient of the credentials already + knows their values. + + prealm and pname + The name and realm of the delegated principal identity. + + flags, authtime, starttime, endtime, renew-till, srealm, sname, + and caddr + These fields contain the values of the corresponding fields from + the ticket found in the ticket field. Descriptions of the fields + are identical to the descriptions in the KDC-REP message. + +5.9. Error Message Specification + + This section specifies the format for the KRB_ERROR message. The + fields included in the message are intended to return as much + information as possible about an error. It is not expected that all + the information required by the fields will be available for all + types of errors. If the appropriate information is not available + when the message is composed, the corresponding field will be left + out of the message. + + Note that because the KRB_ERROR message is not integrity protected, + it is quite possible for an intruder to synthesize or modify it. In + particular, this means that the client SHOULD NOT use any fields in + this message for security-critical purposes, such as setting a system + clock or generating a fresh authenticator. The message can be + useful, however, for advising a user on the reason for some failure. + +5.9.1. KRB_ERROR Definition + + The KRB_ERROR message consists of the following fields: + + KRB-ERROR ::= [APPLICATION 30] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (30), + ctime [2] KerberosTime OPTIONAL, + cusec [3] Microseconds OPTIONAL, + stime [4] KerberosTime, + susec [5] Microseconds, + error-code [6] Int32, + crealm [7] Realm OPTIONAL, + cname [8] PrincipalName OPTIONAL, + realm [9] Realm -- service realm --, + sname [10] PrincipalName -- service name --, + e-text [11] KerberosString OPTIONAL, + + + +Neuman, et al. Standards Track [Page 94] + +RFC 4120 Kerberos V5 July 2005 + + + e-data [12] OCTET STRING OPTIONAL + } + + pvno and msg-type + These fields are described above in Section 5.4.1. msg-type is + KRB_ERROR. + + ctime and cusec + These fields are described above in Section 5.5.2. If the values + for these fields are known to the entity generating the error (as + they would be if the KRB-ERROR is generated in reply to, e.g., a + failed authentication service request), they should be populated + in the KRB-ERROR. If the values are not available, these fields + can be omitted. + + stime + This field contains the current time on the server. It is of type + KerberosTime. + + susec + This field contains the microsecond part of the server's + timestamp. Its value ranges from 0 to 999999. It appears along + with stime. The two fields are used in conjunction to specify a + reasonably accurate timestamp. + + error-code + This field contains the error code returned by Kerberos or the + server when a request fails. To interpret the value of this field + see the list of error codes in Section 7.5.9. Implementations are + encouraged to provide for national language support in the display + of error messages. + + crealm, and cname + These fields are described above in Section 5.3. When the entity + generating the error knows these values, they should be populated + in the KRB-ERROR. If the values are not known, the crealm and + cname fields SHOULD be omitted. + + realm and sname + These fields are described above in Section 5.3. + + e-text + This field contains additional text to help explain the error code + associated with the failed request (for example, it might include + a principal name which was unknown). + + + + + + +Neuman, et al. Standards Track [Page 95] + +RFC 4120 Kerberos V5 July 2005 + + + e-data + This field contains additional data about the error for use by the + application to help it recover from or handle the error. If the + errorcode 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 otherwise. Whether defined by the implementation or + in a future document, the e-data field MAY take the form of TYPED- + DATA: + + TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { + data-type [0] Int32, + data-value [1] OCTET STRING OPTIONAL + } + +5.10. Application Tag Numbers + + The following table lists the application class tag numbers used by + various data types defined in this section. + + Tag Number(s) Type Name Comments + + 0 unused + + 1 Ticket PDU + + 2 Authenticator non-PDU + + 3 EncTicketPart non-PDU + + 4-9 unused + + 10 AS-REQ PDU + + 11 AS-REP PDU + + 12 TGS-REQ PDU + + 13 TGS-REP PDU + + + + +Neuman, et al. Standards Track [Page 96] + +RFC 4120 Kerberos V5 July 2005 + + + 14 AP-REQ PDU + + 15 AP-REP PDU + + 16 RESERVED16 TGT-REQ (for user-to-user) + + 17 RESERVED17 TGT-REP (for user-to-user) + + 18-19 unused + + 20 KRB-SAFE PDU + + 21 KRB-PRIV PDU + + 22 KRB-CRED PDU + + 23-24 unused + + 25 EncASRepPart non-PDU + + 26 EncTGSRepPart non-PDU + + 27 EncApRepPart non-PDU + + 28 EncKrbPrivPart non-PDU + + 29 EncKrbCredPart non-PDU + + 30 KRB-ERROR PDU + + The ASN.1 types marked above as "PDU" (Protocol Data Unit) are the + only ASN.1 types intended as top-level types of the Kerberos + protocol, and are the only types that may be used as elements in + another protocol that makes use of Kerberos. + +6. Naming Constraints + +6.1. Realm Names + + Although realm names are encoded as GeneralStrings and technically a + realm can select any name it chooses, interoperability across realm + boundaries requires agreement on how realm names are to be assigned, + and what information they imply. + + To enforce these conventions, each realm MUST conform to the + conventions itself, and it MUST require that any realms with which + inter-realm keys are shared also conform to the conventions and + require the same from its neighbors. + + + +Neuman, et al. Standards Track [Page 97] + +RFC 4120 Kerberos V5 July 2005 + + + Kerberos realm names are case sensitive. Realm names that differ + only in the case of the characters are not equivalent. There are + presently three styles of realm names: domain, X500, and other. + Examples of each style follow: + + domain: ATHENA.MIT.EDU + X500: C=US/O=OSF + other: NAMETYPE:rest/of.name=without-restrictions + + Domain style realm names MUST look like domain names: they consist of + components separated by periods (.) and they contain neither colons + (:) nor slashes (/). Though domain names themselves are case + insensitive, in order for realms to match, the case must match as + well. When establishing a new realm name based on an internet domain + name it is recommended by convention that the characters be converted + to uppercase. + + X.500 names contain an equals sign (=) and cannot contain a colon (:) + before the equals sign. The realm names for X.500 names will be + string representations of the names with components separated by + slashes. Leading and trailing slashes will not be included. Note + that the slash separator is consistent with Kerberos implementations + based on RFC 1510, but it is different from the separator recommended + in RFC 2253. + + Names that fall into the other category MUST begin with a prefix that + contains no equals sign (=) or period (.), and the prefix MUST be + followed by a colon (:) and the rest of the name. All prefixes + expect those beginning with used. Presently none are assigned. + + The reserved category includes strings that do not fall into the + first three categories. All names in this category are reserved. It + is unlikely that names will be assigned to this category unless there + is a very strong argument for not using the 'other' category. + + These rules guarantee that there will be no conflicts between the + various name styles. The following additional constraints apply to + the assignment of realm names in the domain and X.500 categories: + either the name of a realm for the domain or X.500 formats must be + used by the organization owning (to whom it was assigned) an Internet + domain name or X.500 name, or, in the case that no such names are + registered, authority to use a realm name MAY be derived from the + authority of the parent realm. For example, if there is no domain + name for E40.MIT.EDU, then the administrator of the MIT.EDU realm can + authorize the creation of a realm with that name. + + This is acceptable because the organization to which the parent is + assigned is presumably the organization authorized to assign names to + + + +Neuman, et al. Standards Track [Page 98] + +RFC 4120 Kerberos V5 July 2005 + + + its children in the X.500 and domain name systems as well. If the + parent assigns a realm name without also registering it in the domain + name or X.500 hierarchy, it is the parent's responsibility to make + sure that in the future there will not exist a name identical to the + realm name of the child unless it is assigned to the same entity as + the realm name. + +6.2. Principal Names + + As was the case for realm names, conventions are needed to ensure + that all agree on what information is implied by a principal name. + The name-type field that is part of the principal name indicates the + kind of information implied by the name. The name-type SHOULD be + treated only as a hint to interpreting the meaning of a name. It is + not significant when checking for equivalence. Principal names that + differ only in the name-type identify the same principal. The name + type does not partition the name space. 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). The following name types are defined: + + Name Type Value Meaning + + NT-UNKNOWN 0 Name type not known + NT-PRINCIPAL 1 Just the name of the principal as in DCE, + or for users + NT-SRV-INST 2 Service and other unique instance (krbtgt) + NT-SRV-HST 3 Service with host name as instance + (telnet, rcommands) + NT-SRV-XHST 4 Service with host as remaining components + NT-UID 5 Unique ID + NT-X500-PRINCIPAL 6 Encoded X.509 Distinguished name [RFC2253] + NT-SMTP-NAME 7 Name in form of SMTP email name + (e.g., user@example.com) + NT-ENTERPRISE 10 Enterprise name - may be mapped to principal + name + + When a name implies no information other than its uniqueness at a + particular time, the name type PRINCIPAL SHOULD be used. The + principal name type SHOULD be used for users, and it might also be + used for a unique server. If the name is a unique machine-generated + ID that is guaranteed never to be reassigned, then the name type of + UID SHOULD be used. (Note that it is generally a bad idea to + reassign names of any type since stale entries might remain in access + control lists.) + + If the first component of a name identifies a service and the + remaining components identify an instance of the service in a + server-specified manner, then the name type of SRV-INST SHOULD be + + + +Neuman, et al. Standards Track [Page 99] + +RFC 4120 Kerberos V5 July 2005 + + + used. An example of this name type is the Kerberos ticket-granting + service whose name has a first component of krbtgt and a second + component identifying the realm for which the ticket is valid. + + If the first component of a name identifies a service and there is a + single component following the service name identifying the instance + as the host on which the server is running, then the name type + SRV-HST SHOULD be used. This type is typically used for Internet + services such as telnet and the Berkeley R commands. If the separate + components of the host name appear as successive components following + the name of the service, then the name type SRV-XHST SHOULD be used. + This type might be used to identify servers on hosts with X.500 + names, where the slash (/) might otherwise be ambiguous. + + A name type of NT-X500-PRINCIPAL SHOULD be used when a name from an + X.509 certificate is translated into a Kerberos name. The encoding + of the X.509 name as a Kerberos principal shall conform to the + encoding rules specified in RFC 2253. + + A name type of SMTP allows a name to be of a form that resembles an + SMTP email name. This name, including an "@" and a domain name, is + used as the one component of the principal name. + + A name type of UNKNOWN SHOULD be used when the form of the name is + not known. When comparing names, a name of type UNKNOWN will match + principals authenticated with names of any type. A principal + authenticated with a name of type UNKNOWN, however, will only match + other names of type UNKNOWN. + + Names of any type with an initial component of 'krbtgt' are reserved + for the Kerberos ticket-granting service. See Section 7.3 for the + form of such names. + +6.2.1. Name of Server Principals + + The principal identifier for a server on a host will generally be + composed of two parts: (1) the realm of the KDC with which the server + is registered, and (2) a two-component name of type NT-SRV-HST, if + the host name is an Internet domain name, or a multi-component name + of type NT-SRV-XHST, if the name of the host is of a form (such as + X.500) that allows slash (/) separators. The first component of the + two- or multi-component name will identify the service, and the + latter components will identify the host. Where the name of the host + is not case sensitive (for example, with Internet domain names) the + name of the host MUST be lowercase. If specified by the application + protocol for services such as telnet and the Berkeley R commands that + run with system privileges, the first component MAY be the string + 'host' instead of a service-specific identifier. + + + +Neuman, et al. Standards Track [Page 100] + +RFC 4120 Kerberos V5 July 2005 + + +7. Constants and Other Defined Values + +7.1. Host Address Types + + 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. + + 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). + + Internet (IPv6) Addresses + + IPv6 addresses [RFC3513] 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. + + 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). + + + + + + + + +Neuman, et al. Standards Track [Page 101] + +RFC 4120 Kerberos V5 July 2005 + + + 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). + + Directional Addresses + + Including the sender address in KRB_SAFE and KRB_PRIV messages is + undesirable in many environments 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 + KRB_AP_REQ message, then an address of 0 SHOULD be used. If the + message is originated by the party to whom that KRB_AP_REQ was + sent, then the address 1 SHOULD be 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 KRB_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). + +7.2. KDC Messaging: IP Transports + + Kerberos defines two IP transport mechanisms for communication + between clients and servers: UDP/IP and TCP/IP. + +7.2.1. UDP/IP transport + + Kerberos servers (KDCs) supporting IP transports MUST accept UDP + requests and SHOULD listen for them 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. + + + + + + + +Neuman, et al. Standards Track [Page 102] + +RFC 4120 Kerberos V5 July 2005 + + + Kerberos clients supporting IP transports SHOULD support the sending + of UDP requests. Clients SHOULD use KDC discovery [7.2.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 KRB_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 cannot 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. + +7.2.2. TCP/IP Transport + + Kerberos servers (KDCs) supporting IP transports MUST accept TCP + requests and SHOULD listen for them 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 + try a request initially using the UDP transport. Clients SHOULD use + KDC discovery [7.2.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 KRB_KDC_REQ message is sent to the KDC over a TCP stream, + the response (KRB_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 follow-up. 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. + + The client MUST be prepared to have the stream closed by the KDC at + any time 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 + + + +Neuman, et al. Standards Track [Page 103] + +RFC 4120 Kerberos V5 July 2005 + + + subsequent messages. A client MAY close the stream after receiving a + response, and SHOULD close the stream if it does not expect to send + follow-up 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 (KRB_KDC_REQ) and response (KRB_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). + +7.2.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 that this method of storing configuration + information presents problems with out-of-date information and + scaling, especially when using cross-realm authentication. This + section describes a method for using the Domain Name System [RFC1035] + for storing KDC location information. + +7.2.3.1. DNS vs. Kerberos: Case Sensitivity of Realm Names + + In Kerberos, realm names are case sensitive. Although it is strongly + encouraged that all realm names be all uppercase, this recommendation + has not been adopted by all sites. Some sites use all lowercase + names and other use mixed case. DNS, on the other hand, is case + insensitive for queries. Because 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 lowercase characters be used in realm + names. + + + + +Neuman, et al. Standards Track [Page 104] + +RFC 4120 Kerberos V5 July 2005 + + +7.2.3.2. Specifying KDC Location Information with DNS SRV records + + KDC location information is to be stored using the DNS SRV RR + [RFC2782]. 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 either "udp" or "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. + +7.2.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. + +7.3. Name of the TGS + + The principal identifier of the ticket-granting service shall be + composed of three parts: the realm of the KDC issuing the TGS ticket, + and a two-part name of type NT-SRV-INST, with the first part "krbtgt" + and the second part the name of the realm that will accept the TGT. + For example, a TGT issued by the ATHENA.MIT.EDU realm to be used to + + + +Neuman, et al. Standards Track [Page 105] + +RFC 4120 Kerberos V5 July 2005 + + + get tickets from the ATHENA.MIT.EDU KDC has a principal identifier of + "ATHENA.MIT.EDU" (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A TGT + issued by the ATHENA.MIT.EDU realm to be used to get tickets from the + MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU" (realm), + ("krbtgt", "MIT.EDU") (name). + +7.4. OID Arc for KerberosV5 + + This OID MAY be used to identify Kerberos protocol messages + encapsulated in other protocols. It also designates the OID arc for + KerberosV5-related OIDs assigned by future IETF action. + Implementation 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) + } + + Assignment of OIDs beneath the id-krb5 arc must be obtained by + contacting the registrar for the id-krb5 arc, or its designee. At + the time of the issuance of this RFC, such registrations can be + obtained by contacting krb5-oid-registrar@mit.edu. + +7.5. Protocol Constants and Associated Values + + The following tables list constants used in the protocol and define + their meanings. In the "specification" section, ranges are specified + that limit the values of constants for which values are defined here. + This allows implementations to make assumptions about the maximum + values that will be received for these constants. Implementations + receiving values outside the range specified in the "specification" + section MAY reject the request, but they MUST recover cleanly. + +7.5.1. Key Usage Numbers + + The encryption and checksum specifications in [RFC3961] require as + input a "key usage number", to alter the encryption key used in any + specific message in order to make certain types of cryptographic + attack more difficult. These are the key usage values assigned in + this document: + + 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with + the client key (Section 5.2.7.2) + + + + + + + +Neuman, et al. Standards Track [Page 106] + +RFC 4120 Kerberos V5 July 2005 + + + 2. AS-REP Ticket and TGS-REP Ticket (includes TGS session + key or application session key), encrypted with the + service key (Section 5.3) + 3. AS-REP encrypted part (includes TGS session key or + application session key), encrypted with the client key + (Section 5.4.2) + 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with + the TGS session key (Section 5.4.1) + 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with + the TGS authenticator subkey (Section 5.4.1) + 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, + keyed with the TGS session key (Section 5.5.1) + 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes + TGS authenticator subkey), encrypted with the TGS session + key (Section 5.5.1) + 8. TGS-REP encrypted part (includes application session + key), encrypted with the TGS session key (Section 5.4.2) + 9. TGS-REP encrypted part (includes application session + key), encrypted with the TGS authenticator subkey + (Section 5.4.2) + 10. AP-REQ Authenticator cksum, keyed with the application + session key (Section 5.5.1) + 11. AP-REQ Authenticator (includes application authenticator + subkey), encrypted with the application session key + (Section 5.5.1) + 12. AP-REP encrypted part (includes application session + subkey), encrypted with the application session key + (Section 5.5.2) + 13. KRB-PRIV encrypted part, encrypted with a key chosen by + the application (Section 5.7.1) + 14. KRB-CRED encrypted part, encrypted with a key chosen by + the application (Section 5.8.1) + 15. KRB-SAFE cksum, keyed with a key chosen by the + application (Section 5.6.1) + 16-18. Reserved for future use in Kerberos and related + protocols. + 19. AD-KDC-ISSUED checksum (ad-checksum in 5.2.6.4) + 20-21. Reserved for future use in Kerberos and related + protocols. + 22-25. Reserved for use in the Kerberos Version 5 GSS-API + mechanisms [RFC4121]. + 26-511. Reserved for future use in Kerberos and related + protocols. + 512-1023. Reserved for uses internal to a Kerberos implementation. + 1024. Encryption for application use in protocols that do not + specify key usage values + + + + + +Neuman, et al. Standards Track [Page 107] + +RFC 4120 Kerberos V5 July 2005 + + + 1025. Checksums for application use in protocols that do not + specify key usage values + 1026-2047. Reserved for application use. + +7.5.2. PreAuthentication Data Types + + Padata and Data Type Padata-type Comment + Value + + PA-TGS-REQ 1 + PA-ENC-TIMESTAMP 2 + PA-PW-SALT 3 + [reserved] 4 + PA-ENC-UNIX-TIME 5 (deprecated) + PA-SANDIA-SECUREID 6 + PA-SESAME 7 + PA-OSF-DCE 8 + PA-CYBERSAFE-SECUREID 9 + PA-AFS3-SALT 10 + PA-ETYPE-INFO 11 + PA-SAM-CHALLENGE 12 (sam/otp) + PA-SAM-RESPONSE 13 (sam/otp) + PA-PK-AS-REQ_OLD 14 (pkinit) + PA-PK-AS-REP_OLD 15 (pkinit) + PA-PK-AS-REQ 16 (pkinit) + PA-PK-AS-REP 17 (pkinit) + PA-ETYPE-INFO2 19 (replaces pa-etype-info) + PA-USE-SPECIFIED-KVNO 20 + PA-SAM-REDIRECT 21 (sam/otp) + PA-GET-FROM-TYPED-DATA 22 (embedded in typed data) + TD-PADATA 22 (embeds padata) + PA-SAM-ETYPE-INFO 23 (sam/otp) + PA-ALT-PRINC 24 (crawdad@fnal.gov) + PA-SAM-CHALLENGE2 30 (kenh@pobox.com) + PA-SAM-RESPONSE2 31 (kenh@pobox.com) + PA-EXTRA-TGT 41 Reserved extra TGT + TD-PKINIT-CMS-CERTIFICATES 101 CertificateSet from CMS + TD-KRB-PRINCIPAL 102 PrincipalName + TD-KRB-REALM 103 Realm + TD-TRUSTED-CERTIFIERS 104 from PKINIT + TD-CERTIFICATE-INDEX 105 from PKINIT + TD-APP-DEFINED-ERROR 106 application specific + TD-REQ-NONCE 107 INTEGER + TD-REQ-SEQ 108 INTEGER + PA-PAC-REQUEST 128 (jbrezak@exchange.microsoft.com) + + + + + + +Neuman, et al. Standards Track [Page 108] + +RFC 4120 Kerberos V5 July 2005 + + +7.5.3. Address Types + + Address Type Value + + IPv4 2 + Directional 3 + ChaosNet 5 + XNS 6 + ISO 7 + DECNET Phase IV 12 + AppleTalk DDP 16 + NetBios 20 + IPv6 24 + +7.5.4. Authorization Data Types + + Authorization Data Type Ad-type Value + + AD-IF-RELEVANT 1 + AD-INTENDED-FOR-SERVER 2 + AD-INTENDED-FOR-APPLICATION-CLASS 3 + AD-KDC-ISSUED 4 + AD-AND-OR 5 + AD-MANDATORY-TICKET-EXTENSIONS 6 + AD-IN-TICKET-EXTENSIONS 7 + AD-MANDATORY-FOR-KDC 8 + Reserved values 9-63 + OSF-DCE 64 + SESAME 65 + AD-OSF-DCE-PKI-CERTID 66 (hemsath@us.ibm.com) + AD-WIN2K-PAC 128 (jbrezak@exchange.microsoft.com) + AD-ETYPE-NEGOTIATION 129 (lzhu@windows.microsoft.com) + +7.5.5. Transited Encoding Types + + Transited Encoding Type Tr-type Value + + DOMAIN-X500-COMPRESS 1 + Reserved values All others + +7.5.6. Protocol Version Number + + Label Value Meaning or MIT Code + + pvno 5 Current Kerberos protocol version number + + + + + + +Neuman, et al. Standards Track [Page 109] + +RFC 4120 Kerberos V5 July 2005 + + +7.5.7. Kerberos Message Types + + Message Type Value Meaning + + KRB_AS_REQ 10 Request for initial authentication + KRB_AS_REP 11 Response to KRB_AS_REQ request + KRB_TGS_REQ 12 Request for authentication based on TGT + KRB_TGS_REP 13 Response to KRB_TGS_REQ request + KRB_AP_REQ 14 Application request to server + KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL + KRB_RESERVED16 16 Reserved for user-to-user krb_tgt_request + KRB_RESERVED17 17 Reserved for user-to-user krb_tgt_reply + KRB_SAFE 20 Safe (checksummed) application message + KRB_PRIV 21 Private (encrypted) application message + KRB_CRED 22 Private (encrypted) message to forward + credentials + KRB_ERROR 30 Error response + +7.5.8. Name Types + + Name Type Value Meaning + + KRB_NT_UNKNOWN 0 Name type not known + KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, + or for users + KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt) + KRB_NT_SRV_HST 3 Service with host name as instance + (telnet, rcommands) + KRB_NT_SRV_XHST 4 Service with host as remaining components + KRB_NT_UID 5 Unique ID + KRB_NT_X500_PRINCIPAL 6 Encoded X.509 Distinguished name [RFC2253] + KRB_NT_SMTP_NAME 7 Name in form of SMTP email name + (e.g., user@example.com) + KRB_NT_ENTERPRISE 10 Enterprise name; may be mapped to + principal name + +7.5.9. Error Codes + + Error Code Value Meaning + + KDC_ERR_NONE 0 No error + KDC_ERR_NAME_EXP 1 Client's entry in database + has expired + KDC_ERR_SERVICE_EXP 2 Server's entry in database + has expired + KDC_ERR_BAD_PVNO 3 Requested protocol version + number not supported + + + + +Neuman, et al. Standards Track [Page 110] + +RFC 4120 Kerberos V5 July 2005 + + + KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in + old master key + KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in + old master key + KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in + Kerberos database + KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in + Kerberos database + KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries + in database + KDC_ERR_NULL_KEY 9 The client or server has a + null key + KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for + postdating + KDC_ERR_NEVER_VALID 11 Requested starttime is + later than end time + KDC_ERR_POLICY 12 KDC policy rejects request + KDC_ERR_BADOPTION 13 KDC cannot accommodate + requested option + KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for + encryption type + KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for + checksum type + KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for + padata type + KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for + transited type + KDC_ERR_CLIENT_REVOKED 18 Clients credentials have + been revoked + KDC_ERR_SERVICE_REVOKED 19 Credentials for server have + been revoked + KDC_ERR_TGT_REVOKED 20 TGT has been revoked + KDC_ERR_CLIENT_NOTYET 21 Client not yet valid; try + again later + KDC_ERR_SERVICE_NOTYET 22 Server not yet valid; try + again later + KDC_ERR_KEY_EXPIRED 23 Password has expired; + change password to reset + KDC_ERR_PREAUTH_FAILED 24 Pre-authentication + information was invalid + KDC_ERR_PREAUTH_REQUIRED 25 Additional pre- + authentication required + KDC_ERR_SERVER_NOMATCH 26 Requested server and ticket + don't match + KDC_ERR_MUST_USE_USER2USER 27 Server principal valid for + user2user only + KDC_ERR_PATH_NOT_ACCEPTED 28 KDC Policy rejects + transited path + + + +Neuman, et al. Standards Track [Page 111] + +RFC 4120 Kerberos V5 July 2005 + + + KDC_ERR_SVC_UNAVAILABLE 29 A service is not available + KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on + decrypted field failed + KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired + KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid + KRB_AP_ERR_REPEAT 34 Request is a replay + KRB_AP_ERR_NOT_US 35 The ticket isn't for us + KRB_AP_ERR_BADMATCH 36 Ticket and authenticator + don't match + KRB_AP_ERR_SKEW 37 Clock skew too great + KRB_AP_ERR_BADADDR 38 Incorrect net address + KRB_AP_ERR_BADVERSION 39 Protocol version mismatch + KRB_AP_ERR_MSG_TYPE 40 Invalid msg type + KRB_AP_ERR_MODIFIED 41 Message stream modified + KRB_AP_ERR_BADORDER 42 Message out of order + KRB_AP_ERR_BADKEYVER 44 Specified version of key is + not available + KRB_AP_ERR_NOKEY 45 Service key not available + KRB_AP_ERR_MUT_FAIL 46 Mutual authentication + failed + KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction + KRB_AP_ERR_METHOD 48 Alternative authentication + method required + KRB_AP_ERR_BADSEQ 49 Incorrect sequence number + in message + KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of + checksum in message + KRB_AP_PATH_NOT_ACCEPTED 51 Policy rejects transited + path + KRB_ERR_RESPONSE_TOO_BIG 52 Response too big for UDP; + retry with TCP + KRB_ERR_GENERIC 60 Generic error (description + in e-text) + KRB_ERR_FIELD_TOOLONG 61 Field is too long for this + implementation + KDC_ERROR_CLIENT_NOT_TRUSTED 62 Reserved for PKINIT + KDC_ERROR_KDC_NOT_TRUSTED 63 Reserved for PKINIT + KDC_ERROR_INVALID_SIG 64 Reserved for PKINIT + KDC_ERR_KEY_TOO_WEAK 65 Reserved for PKINIT + KDC_ERR_CERTIFICATE_MISMATCH 66 Reserved for PKINIT + KRB_AP_ERR_NO_TGT 67 No TGT available to + validate USER-TO-USER + KDC_ERR_WRONG_REALM 68 Reserved for future use + KRB_AP_ERR_USER_TO_USER_REQUIRED 69 Ticket must be for + USER-TO-USER + KDC_ERR_CANT_VERIFY_CERTIFICATE 70 Reserved for PKINIT + KDC_ERR_INVALID_CERTIFICATE 71 Reserved for PKINIT + KDC_ERR_REVOKED_CERTIFICATE 72 Reserved for PKINIT + + + +Neuman, et al. Standards Track [Page 112] + +RFC 4120 Kerberos V5 July 2005 + + + KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 Reserved for PKINIT + KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 Reserved for PKINIT + KDC_ERR_CLIENT_NAME_MISMATCH 75 Reserved for PKINIT + KDC_ERR_KDC_NAME_MISMATCH 76 Reserved for PKINIT + +8. Interoperability Requirements + + Version 5 of the Kerberos protocol supports a myriad of options. + Among these are multiple encryption and checksum types; alternative + encoding schemes for the transited field; optional mechanisms for + pre-authentication; the handling of tickets with no addresses; + options for mutual authentication; user-to-user authentication; + support for proxies; the format of realm names; the handling of + authorization data; and forwarding, postdating, and renewing tickets. + + In order to ensure the interoperability of realms, it is necessary to + define a minimal configuration that must be supported by all + implementations. This minimal configuration is subject to change as + technology does. For example, if at some later date it is discovered + that one of the required encryption or checksum algorithms is not + secure, it will be replaced. + +8.1. Specification 2 + + This section defines the second specification of these options. + Implementations which are configured in this way can be said to + support Kerberos Version 5 Specification 2 (5.2). Specification 1 + (deprecated) may be found in RFC 1510. + + Transport + + TCP/IP and UDP/IP transport MUST be supported by clients and KDCs + claiming conformance to specification 2. + + Encryption and Checksum Methods + + The following encryption and checksum mechanisms MUST be + supported: + + Encryption: AES256-CTS-HMAC-SHA1-96 [RFC3962] + Checksums: HMAC-SHA1-96-AES256 [RFC3962] + + Implementations SHOULD support other mechanisms as well, but the + additional mechanisms may only be used when communicating with + principals known to also support them. The following mechanisms + from [RFC3961] and [RFC3962] SHOULD be supported: + + + + + +Neuman, et al. Standards Track [Page 113] + +RFC 4120 Kerberos V5 July 2005 + + + Encryption: AES128-CTS-HMAC-SHA1-96, DES-CBC-MD5, DES3-CBC-SHA1-KD + Checksums: DES-MD5, HMAC-SHA1-DES3-KD, HMAC-SHA1-96-AES128 + + Implementations MAY support other mechanisms as well, but the + additional mechanisms may only be used when communicating with + principals known to support them also. + + Implementation note: Earlier implementations of Kerberos generate + messages using the CRC-32 and RSA-MD5 checksum methods. For + interoperability with these earlier releases, implementors MAY + consider supporting these checksum methods but should carefully + analyze the security implications to limit the situations within + which these methods are accepted. + + Realm Names + + All implementations MUST understand hierarchical realms in both + the Internet Domain and the X.500 style. When a TGT for an + unknown realm is requested, the KDC MUST be able to determine the + names of the intermediate realms between the KDCs realm and the + requested realm. + + Transited Field Encoding + + DOMAIN-X500-COMPRESS (described in Section 3.3.3.2) MUST be + supported. Alternative encodings MAY be supported, but they may + only be used when that encoding is supported by ALL intermediate + realms. + + Pre-authentication Methods + + The TGS-REQ method MUST be supported. It is not used on the + initial request. The PA-ENC-TIMESTAMP method MUST be supported by + clients, but whether it is enabled by default MAY be determined on + a realm-by-realm basis. If the method is not used in the initial + request and the error KDC_ERR_PREAUTH_REQUIRED is returned + specifying PA-ENC-TIMESTAMP as an acceptable method, the client + SHOULD retry the initial request using the PA-ENC-TIMESTAMP pre- + authentication method. Servers need not support the PA-ENC- + TIMESTAMP method, but if it is not supported the server SHOULD + ignore the presence of PA-ENC-TIMESTAMP pre-authentication in a + request. + + The ETYPE-INFO2 method MUST be supported; this method is used to + communicate the set of supported encryption types, and + corresponding salt and string to key parameters. The ETYPE-INFO + method SHOULD be supported for interoperability with older + implementation. + + + +Neuman, et al. Standards Track [Page 114] + +RFC 4120 Kerberos V5 July 2005 + + + Mutual Authentication + + Mutual authentication (via the KRB_AP_REP message) MUST be + supported. + + Ticket Addresses and Flags + + All KDCs MUST pass through tickets that carry no addresses (i.e., + if a TGT contains no addresses, the KDC will return derivative + tickets). Implementations SHOULD default to requesting + addressless tickets, as this significantly increases + interoperability with network address translation. In some cases, + realms or application servers MAY require that tickets have an + address. + + Implementations SHOULD accept directional address type for the + KRB_SAFE and KRB_PRIV message and SHOULD include directional + addresses in these messages when other address types are not + available. + + Proxies and forwarded tickets MUST be supported. Individual + realms and application servers can set their own policy on when + such tickets will be accepted. + + All implementations MUST recognize renewable and postdated + tickets, but they need not actually implement them. If these + options are not supported, the starttime and endtime in the ticket + SHALL specify a ticket's entire useful life. When a postdated + ticket is decoded by a server, all implementations SHALL make the + presence of the postdated flag visible to the calling server. + + User-to-User Authentication + + Support for user-to-user authentication (via the ENC-TKT-IN-SKEY + KDC option) MUST be provided by implementations, but individual + realms MAY decide as a matter of policy to reject such requests on + a per-principal or realm-wide basis. + + Authorization Data + + Implementations MUST pass all authorization data subfields from + TGTs to any derivative tickets unless they are directed to + suppress a subfield as part of the definition of that registered + subfield type. (It is never incorrect to pass on a subfield, and + no registered subfield types presently specify suppression at the + KDC.) + + + + + +Neuman, et al. Standards Track [Page 115] + +RFC 4120 Kerberos V5 July 2005 + + + Implementations MUST make the contents of any authorization data + subfields available to the server when a ticket is used. + Implementations are not required to allow clients to specify the + contents of the authorization data fields. + + Constant Ranges + + All protocol constants are constrained to 32-bit (signed) values + unless further constrained by the protocol definition. This limit + is provided to allow implementations to make assumptions about the + maximum values that will be received for these constants. + Implementations receiving values outside this range MAY reject the + request, but they MUST recover cleanly. + +8.2. Recommended KDC Values + + Following is a list of recommended values for a KDC configuration. + + Minimum lifetime 5 minutes + Maximum renewable lifetime 1 week + Maximum ticket lifetime 1 day + Acceptable clock skew 5 minutes + Empty addresses Allowed + Proxiable, etc. Allowed + +9. IANA Considerations + + Section 7 of this document specifies protocol constants and other + defined values required for the interoperability of multiple + implementations. Until a subsequent RFC specifies otherwise, or the + Kerberos working group is shut down, allocations of additional + protocol constants and other defined values required for extensions + to the Kerberos protocol will be administered by the Kerberos working + group. Following the recommendations outlined in [RFC2434], guidance + is provided to the IANA as follows: + + "reserved" realm name types in Section 6.1 and "other" realm types + except those beginning with "X-" or "x-" will not be registered + without IETF standards action, at which point guidelines for further + assignment will be specified. Realm name types beginning with "X-" + or "x-" are for private use. + + For host address types described in Section 7.1, negative values are + for private use. Assignment of additional positive numbers is + subject to review by the Kerberos working group or other expert + review. + + + + + +Neuman, et al. Standards Track [Page 116] + +RFC 4120 Kerberos V5 July 2005 + + + Additional key usage numbers, as defined in Section 7.5.1, will be + assigned subject to review by the Kerberos working group or other + expert review. + + Additional preauthentication data type values, as defined in section + 7.5.2, will be assigned subject to review by the Kerberos working + group or other expert review. + + Additional authorization data types as defined in Section 7.5.4, will + be assigned subject to review by the Kerberos working group or other + expert review. Although it is anticipated that there may be + significant demand for private use types, provision is intentionally + not made for a private use portion of the namespace because conflicts + between privately assigned values could have detrimental security + implications. + + Additional transited encoding types, as defined in Section 7.5.5, + present special concerns for interoperability with existing + implementations. As such, such assignments will only be made by + standards action, except that the Kerberos working group or another + other working group with competent jurisdiction may make preliminary + assignments for documents that are moving through the standards + process. + + Additional Kerberos message types, as described in Section 7.5.7, + will be assigned subject to review by the Kerberos working group or + other expert review. + + Additional name types, as described in Section 7.5.8, will be + assigned subject to review by the Kerberos working group or other + expert review. + + Additional error codes described in Section 7.5.9 will be assigned + subject to review by the Kerberos working group or other expert + review. + +10. Security Considerations + + As an authentication service, Kerberos provides a means of verifying + the identity of principals on a network. By itself, Kerberos does + not provide authorization. Applications should not accept the + issuance of a service ticket by the Kerberos server as granting + authority to use the service, since such applications may become + vulnerable to the bypass of this authorization check in an + environment where they inter-operate with other KDCs or where other + options for application authentication are provided. + + + + + +Neuman, et al. Standards Track [Page 117] + +RFC 4120 Kerberos V5 July 2005 + + + Denial of service attacks are not solved with Kerberos. There are + places in the protocols where an intruder can prevent an application + from participating in the proper authentication steps. Because + authentication is a required step for the use of many services, + successful denial of service attacks on a Kerberos server might + result in the denial of other network services that rely on Kerberos + for authentication. Kerberos is vulnerable to many kinds of denial + of service attacks: those on the network, which would prevent clients + from contacting the KDC; those on the domain name system, which could + prevent a client from finding the IP address of the Kerberos server; + and those by overloading the Kerberos KDC itself with repeated + requests. + + Interoperability conflicts caused by incompatible character-set usage + (see 5.2.1) can result in denial of service for clients that utilize + character-sets in Kerberos strings other than those stored in the KDC + database. + + Authentication servers maintain a database of principals (i.e., users + and servers) and their secret keys. The security of the + authentication server machines is critical. The breach of security + of an authentication server will compromise the security of all + servers that rely upon the compromised KDC, and will compromise the + authentication of any principals registered in the realm of the + compromised KDC. + + Principals must keep their secret keys secret. If an intruder + somehow steals a principal's key, it will be able to masquerade as + that principal or impersonate any server to the legitimate principal. + + Password-guessing attacks are not solved by Kerberos. If a user + chooses a poor password, it is possible for an attacker to + successfully mount an off-line dictionary attack by repeatedly + attempting to decrypt, with successive entries from a dictionary, + messages obtained that are encrypted under a key derived from the + user's password. + + Unless pre-authentication options are required by the policy of a + realm, the KDC will not know whether a request for authentication + succeeds. An attacker can request a reply with credentials for any + principal. These credentials will likely not be of much use to the + attacker unless it knows the client's secret key, but the + availability of the response encrypted in the client's secret key + provides the attacker with ciphertext that may be used to mount brute + force or dictionary attacks to decrypt the credentials, by guessing + the user's password. For this reason it is strongly encouraged that + Kerberos realms require the use of pre-authentication. Even with + + + + +Neuman, et al. Standards Track [Page 118] + +RFC 4120 Kerberos V5 July 2005 + + + pre-authentication, attackers may try brute force or dictionary + attacks against credentials that are observed by eavesdropping on the + network. + + Because a client can request a ticket for any server principal and + can attempt a brute force or dictionary attack against the server + principal's key using that ticket, it is strongly encouraged that + keys be randomly generated (rather than generated from passwords) for + any principals that are usable as the target principal for a + KRB_TGS_REQ or KRB_AS_REQ messages. [RFC4086] + + Although the DES-CBC-MD5 encryption method and DES-MD5 checksum + methods are listed as SHOULD be implemented for backward + compatibility, the single DES encryption algorithm on which these are + based is weak, and stronger algorithms should be used whenever + possible. + + Each host on the network must have a clock that is loosely + synchronized to the time of the other hosts; this synchronization is + used to reduce the bookkeeping needs of application servers when they + do replay detection. The degree of "looseness" can be configured on + a per-server basis, but it is typically on the order of 5 minutes. + If the clocks are synchronized over the network, the clock + synchronization protocol MUST itself be secured from network + attackers. + + Principal identifiers must not recycled on a short-term basis. A + typical mode of access control will use access control lists (ACLs) + to grant permissions to particular principals. If a stale ACL entry + remains for a deleted principal and the principal identifier is + reused, the new principal will inherit rights specified in the stale + ACL entry. By not reusing principal identifiers, the danger of + inadvertent access is removed. + + Proper decryption of an KRB_AS_REP message from the KDC is not + sufficient for the host to verify the identity of the user; the user + and an attacker could cooperate to generate a KRB_AS_REP format + message that decrypts properly but is not from the proper KDC. To + authenticate a user logging on to a local system, the credentials + obtained in the AS exchange may first be used in a TGS exchange to + obtain credentials for a local server. Those credentials must then + be verified by a local server through successful completion of the + Client/Server exchange. + + Many RFC 1510-compliant implementations ignore unknown authorization + data elements. Depending on these implementations to honor + authorization data restrictions may create a security weakness. + + + + +Neuman, et al. Standards Track [Page 119] + +RFC 4120 Kerberos V5 July 2005 + + + Kerberos credentials contain clear-text information identifying the + principals to which they apply. If privacy of this information is + needed, this exchange should itself be encapsulated in a protocol + providing for confidentiality on the exchange of these credentials. + + Applications must take care to protect communications subsequent to + authentication, either by using the KRB_PRIV or KRB_SAFE messages as + appropriate, or by applying their own confidentiality or integrity + mechanisms on such communications. Completion of the KRB_AP_REQ and + KRB_AP_REP exchange without subsequent use of confidentiality and + integrity mechanisms provides only for authentication of the parties + to the communication and not confidentiality and integrity of the + subsequent communication. Applications applying confidentiality and + integrity protection mechanisms other than KRB_PRIV and KRB_SAFE must + make sure that the authentication step is appropriately linked with + the protected communication channel that is established by the + application. + + Unless the application server provides its own suitable means to + protect against replay (for example, a challenge-response sequence + initiated by the server after authentication, or use of a server- + generated encryption subkey), the server must utilize a replay cache + to remember any authenticator presented within the allowable clock + skew. All services sharing a key need to use the same replay cache. + If separate replay caches are used, then an authenticator used with + one such service could later be replayed to a different service with + the same service principal. + + If a server loses track of authenticators presented within the + allowable clock skew, it must reject all requests until the clock + skew interval has passed, providing assurance that any lost or + replayed authenticators will fall outside the allowable clock skew + and can no longer be successfully replayed. + + Implementations of Kerberos should not use untrusted directory + servers to determine the realm of a host. To allow this would allow + the compromise of the directory server to enable an attacker to + direct the client to accept authentication with the wrong principal + (i.e., one with a similar name, but in a realm with which the + legitimate host was not registered). + + Implementations of Kerberos must not use DNS to map one name to + another (canonicalize) in order to determine the host part of the + principal name with which one is to communicate. To allow this + canonicalization would allow a compromise of the DNS to result in a + client obtaining credentials and correctly authenticating to the + + + + + +Neuman, et al. Standards Track [Page 120] + +RFC 4120 Kerberos V5 July 2005 + + + wrong principal. Though the client will know who it is communicating + with, it will not be the principal with which it intended to + communicate. + + If the Kerberos server returns a TGT for a realm 'closer' than the + desired realm, the client may use local policy configuration to + verify that the authentication path used is an acceptable one. + Alternatively, a client may choose its own authentication path rather + than rely on the Kerberos server to select one. In either case, any + policy or configuration information used to choose or validate + authentication paths, whether by the Kerberos server or client, must + be obtained from a trusted source. + + 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 the user's, + application server's, or KDC's key is subsequently discovered. This + is because the session key used to encrypt such messages, when + transmitted over the network, is encrypted in the key of the + application server. It is also encrypted under the session key from + the user's TGT when it is returned to the user in the KRB_TGS_REP + message. The session key from the TGT is sent to the user in the + KRB_AS_REP message encrypted in the user's secret key and embedded in + the TGT, which was encrypted in the key of the KDC. Applications + 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. + +11. Acknowledgements + + This document is a revision to RFC 1510 which was co-authored with + John Kohl. The specification of the Kerberos protocol described in + this document is the result of many years of effort. Over this + period, many individuals have contributed to the definition of the + protocol and to the writing of the specification. Unfortunately, it + is not possible to list all contributors as authors of this document, + though there are many not listed who are authors in spirit, including + those who contributed text for parts of some sections, who + contributed to the design of parts of the protocol, and who + contributed significantly to the discussion of the protocol in the + IETF common authentication technology (CAT) and Kerberos working + groups. + + + + + + +Neuman, et al. Standards Track [Page 121] + +RFC 4120 Kerberos V5 July 2005 + + + Among those contributing to the development and specification of + Kerberos were Jeffrey Altman, John Brezak, Marc Colan, Johan + Danielsson, Don Davis, Doug Engert, Dan Geer, Paul Hill, John Kohl, + Marc Horowitz, Matt Hur, Jeffrey Hutzelman, Paul Leach, John Linn, + Ari Medvinsky, Sasha Medvinsky, Steve Miller, Jon Rochlis, Jerome + Saltzer, Jeffrey Schiller, Jennifer Steiner, Ralph Swick, Mike Swift, + Jonathan Trostle, Theodore Ts'o, Brian Tung, Jacques Vidrine, Assar + Westerlund, and Nicolas Williams. Many other members of MIT Project + Athena, the MIT networking group, and the Kerberos and CAT working + groups of the IETF contributed but are not listed. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Neuman, et al. Standards Track [Page 122] + +RFC 4120 Kerberos V5 July 2005 + + +A. ASN.1 module + +KerberosV5Spec2 { + iso(1) identified-organization(3) dod(6) internet(1) + security(5) kerberosV5(2) modules(4) krb5spec2(2) +} 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) +} + +Int32 ::= INTEGER (-2147483648..2147483647) + -- signed values representable in 32 bits + +UInt32 ::= INTEGER (0..4294967295) + -- unsigned 32 bit values + +Microseconds ::= INTEGER (0..999999) + -- microseconds + +KerberosString ::= GeneralString (IA5String) + +Realm ::= KerberosString + +PrincipalName ::= SEQUENCE { + name-type [0] Int32, + name-string [1] SEQUENCE OF KerberosString +} + +KerberosTime ::= GeneralizedTime -- with no fractional seconds + +HostAddress ::= SEQUENCE { + addr-type [0] Int32, + address [1] OCTET STRING +} + +-- NOTE: HostAddresses is always used as an OPTIONAL field and +-- should not be empty. +HostAddresses -- NOTE: subtly different from rfc1510, + + + +Neuman, et al. Standards Track [Page 123] + +RFC 4120 Kerberos V5 July 2005 + + + -- but has a value mapping and encodes the same + ::= SEQUENCE OF HostAddress + +-- NOTE: AuthorizationData is always used as an OPTIONAL field and +-- should not be empty. +AuthorizationData ::= SEQUENCE OF SEQUENCE { + ad-type [0] Int32, + ad-data [1] OCTET STRING +} + +PA-DATA ::= SEQUENCE { + -- NOTE: first tag is [1], not [0] + padata-type [1] Int32, + padata-value [2] OCTET STRING -- might be encoded AP-REQ +} + +KerberosFlags ::= BIT STRING (SIZE (32..MAX)) + -- minimum number of bits shall be sent, + -- but no fewer than 32 + +EncryptedData ::= SEQUENCE { + etype [0] Int32 -- EncryptionType --, + kvno [1] UInt32 OPTIONAL, + cipher [2] OCTET STRING -- ciphertext +} + +EncryptionKey ::= SEQUENCE { + keytype [0] Int32 -- actually encryption type --, + keyvalue [1] OCTET STRING +} + +Checksum ::= SEQUENCE { + cksumtype [0] Int32, + checksum [1] OCTET STRING +} + +Ticket ::= [APPLICATION 1] SEQUENCE { + tkt-vno [0] INTEGER (5), + realm [1] Realm, + sname [2] PrincipalName, + enc-part [3] EncryptedData -- EncTicketPart +} + +-- Encrypted part of ticket +EncTicketPart ::= [APPLICATION 3] SEQUENCE { + flags [0] TicketFlags, + key [1] EncryptionKey, + crealm [2] Realm, + + + +Neuman, et al. Standards Track [Page 124] + +RFC 4120 Kerberos V5 July 2005 + + + 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 +} + +-- encoded Transited field +TransitedEncoding ::= SEQUENCE { + tr-type [0] Int32 -- must be registered --, + contents [1] OCTET STRING +} + +TicketFlags ::= KerberosFlags + -- 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), +-- the following are new since 1510 + -- transited-policy-checked(12), + -- ok-as-delegate(13) + +AS-REQ ::= [APPLICATION 10] KDC-REQ + +TGS-REQ ::= [APPLICATION 12] KDC-REQ + +KDC-REQ ::= SEQUENCE { + -- NOTE: first tag is [1], not [0] + pvno [1] INTEGER (5) , + msg-type [2] INTEGER (10 -- AS -- | 12 -- TGS --), + padata [3] SEQUENCE OF PA-DATA OPTIONAL + -- NOTE: not empty --, + req-body [4] KDC-REQ-BODY +} + +KDC-REQ-BODY ::= SEQUENCE { + kdc-options [0] KDCOptions, + + + +Neuman, et al. Standards Track [Page 125] + +RFC 4120 Kerberos V5 July 2005 + + + 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, + rtime [6] KerberosTime OPTIONAL, + nonce [7] UInt32, + etype [8] SEQUENCE OF Int32 -- EncryptionType + -- in preference order --, + addresses [9] HostAddresses OPTIONAL, + enc-authorization-data [10] EncryptedData OPTIONAL + -- AuthorizationData --, + additional-tickets [11] SEQUENCE OF Ticket OPTIONAL + -- NOTE: not empty +} + +KDCOptions ::= KerberosFlags + -- reserved(0), + -- forwardable(1), + -- forwarded(2), + -- proxiable(3), + -- proxy(4), + -- allow-postdate(5), + -- postdated(6), + -- unused7(7), + -- renewable(8), + -- unused9(9), + -- unused10(10), + -- opt-hardware-auth(11), + -- unused12(12), + -- unused13(13), +-- 15 is reserved for canonicalize + -- unused15(15), +-- 26 was unused in 1510 + -- disable-transited-check(26), +-- + -- renewable-ok(27), + -- enc-tkt-in-skey(28), + -- renew(30), + -- validate(31) + +AS-REP ::= [APPLICATION 11] KDC-REP + +TGS-REP ::= [APPLICATION 13] KDC-REP + + + + +Neuman, et al. Standards Track [Page 126] + +RFC 4120 Kerberos V5 July 2005 + + +KDC-REP ::= SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (11 -- AS -- | 13 -- TGS --), + padata [2] SEQUENCE OF PA-DATA OPTIONAL + -- NOTE: not empty --, + crealm [3] Realm, + cname [4] PrincipalName, + ticket [5] Ticket, + enc-part [6] EncryptedData + -- EncASRepPart or EncTGSRepPart, + -- as appropriate +} + +EncASRepPart ::= [APPLICATION 25] EncKDCRepPart + +EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart + +EncKDCRepPart ::= SEQUENCE { + key [0] EncryptionKey, + last-req [1] LastReq, + nonce [2] UInt32, + 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 +} + +LastReq ::= SEQUENCE OF SEQUENCE { + lr-type [0] Int32, + lr-value [1] KerberosTime +} + +AP-REQ ::= [APPLICATION 14] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (14), + ap-options [2] APOptions, + ticket [3] Ticket, + authenticator [4] EncryptedData -- Authenticator +} + +APOptions ::= KerberosFlags + -- reserved(0), + -- use-session-key(1), + + + +Neuman, et al. Standards Track [Page 127] + +RFC 4120 Kerberos V5 July 2005 + + + -- mutual-required(2) + +-- Unencrypted authenticator +Authenticator ::= [APPLICATION 2] SEQUENCE { + authenticator-vno [0] INTEGER (5), + crealm [1] Realm, + cname [2] PrincipalName, + cksum [3] Checksum OPTIONAL, + cusec [4] Microseconds, + ctime [5] KerberosTime, + subkey [6] EncryptionKey OPTIONAL, + seq-number [7] UInt32 OPTIONAL, + authorization-data [8] AuthorizationData OPTIONAL +} + +AP-REP ::= [APPLICATION 15] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (15), + enc-part [2] EncryptedData -- EncAPRepPart +} + +EncAPRepPart ::= [APPLICATION 27] SEQUENCE { + ctime [0] KerberosTime, + cusec [1] Microseconds, + subkey [2] EncryptionKey OPTIONAL, + seq-number [3] UInt32 OPTIONAL +} + +KRB-SAFE ::= [APPLICATION 20] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (20), + safe-body [2] KRB-SAFE-BODY, + cksum [3] Checksum +} + +KRB-SAFE-BODY ::= SEQUENCE { + user-data [0] OCTET STRING, + timestamp [1] KerberosTime OPTIONAL, + usec [2] Microseconds OPTIONAL, + seq-number [3] UInt32 OPTIONAL, + s-address [4] HostAddress, + r-address [5] HostAddress OPTIONAL +} + +KRB-PRIV ::= [APPLICATION 21] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (21), + -- NOTE: there is no [2] tag + + + +Neuman, et al. Standards Track [Page 128] + +RFC 4120 Kerberos V5 July 2005 + + + enc-part [3] EncryptedData -- EncKrbPrivPart +} + +EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { + user-data [0] OCTET STRING, + timestamp [1] KerberosTime OPTIONAL, + usec [2] Microseconds OPTIONAL, + seq-number [3] UInt32 OPTIONAL, + s-address [4] HostAddress -- sender's addr --, + r-address [5] HostAddress OPTIONAL -- recip's addr +} + +KRB-CRED ::= [APPLICATION 22] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (22), + tickets [2] SEQUENCE OF Ticket, + enc-part [3] EncryptedData -- EncKrbCredPart +} + +EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { + ticket-info [0] SEQUENCE OF KrbCredInfo, + nonce [1] UInt32 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 +} + +KRB-ERROR ::= [APPLICATION 30] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (30), + ctime [2] KerberosTime OPTIONAL, + cusec [3] Microseconds OPTIONAL, + stime [4] KerberosTime, + + + +Neuman, et al. Standards Track [Page 129] + +RFC 4120 Kerberos V5 July 2005 + + + susec [5] Microseconds, + error-code [6] Int32, + crealm [7] Realm OPTIONAL, + cname [8] PrincipalName OPTIONAL, + realm [9] Realm -- service realm --, + sname [10] PrincipalName -- service name --, + e-text [11] KerberosString OPTIONAL, + e-data [12] OCTET STRING OPTIONAL +} + +METHOD-DATA ::= SEQUENCE OF PA-DATA + +TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { + data-type [0] Int32, + data-value [1] OCTET STRING OPTIONAL +} + +-- preauth stuff follows + +PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC + +PA-ENC-TS-ENC ::= SEQUENCE { + patimestamp [0] KerberosTime -- client's time --, + pausec [1] Microseconds OPTIONAL +} + +ETYPE-INFO-ENTRY ::= SEQUENCE { + etype [0] Int32, + salt [1] OCTET STRING OPTIONAL +} + +ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY + +ETYPE-INFO2-ENTRY ::= SEQUENCE { + etype [0] Int32, + salt [1] KerberosString OPTIONAL, + s2kparams [2] OCTET STRING OPTIONAL +} + +ETYPE-INFO2 ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY + +AD-IF-RELEVANT ::= AuthorizationData + +AD-KDCIssued ::= SEQUENCE { + ad-checksum [0] Checksum, + i-realm [1] Realm OPTIONAL, + i-sname [2] PrincipalName OPTIONAL, + elements [3] AuthorizationData + + + +Neuman, et al. Standards Track [Page 130] + +RFC 4120 Kerberos V5 July 2005 + + +} + +AD-AND-OR ::= SEQUENCE { + condition-count [0] Int32, + elements [1] AuthorizationData +} + +AD-MANDATORY-FOR-KDC ::= AuthorizationData + +END + +B. Changes since RFC 1510 + + This document replaces RFC 1510 and clarifies specification of items + that were not completely specified. Where changes to recommended + implementation choices were made, or where new options were added, + those changes are described within the document and listed in this + section. More significantly, "Specification 2" in Section 8 changes + the required encryption and checksum methods to bring them in line + with the best current practices and to deprecate methods that are no + longer considered sufficiently strong. + + Discussion was added to Section 1 regarding the ability to rely on + the KDC to check the transited field, and on the inclusion of a flag + in a ticket indicating that this check has occurred. This is a new + capability not present in RFC 1510. Pre-existing implementations may + ignore or not set this flag without negative security implications. + + The definition of the secret key says that in the case of a user the + key may be derived from a password. In RFC 1510, it said that the + key was derived from the password. This change was made to + accommodate situations where the user key might be stored on a + smart-card, or otherwise obtained independently of a password. + + The introduction mentions the use of public key cryptography for + initial authentication in Kerberos by reference. RFC 1510 did not + include such a reference. + + Section 1.3 was added to explain that while Kerberos provides + authentication of a named principal, it is still the responsibility + of the application to ensure that the authenticated name is the + entity with which the application wishes to communicate. + + Discussion of extensibility has been added to the introduction. + + Discussion of how extensibility affects ticket flags and KDC options + was added to the introduction of Section 2. No changes were made to + existing options and flags specified in RFC 1510, though some of the + + + +Neuman, et al. Standards Track [Page 131] + +RFC 4120 Kerberos V5 July 2005 + + + sections in the specification were renumbered, and text was revised + to make the description and intent of existing options clearer, + especially with respect to the ENC-TKT-IN-SKEY option (now section + 2.9.2) which is used for user-to-user authentication. The new option + and ticket flag transited policy checking (Section 2.7) was added. + + A warning regarding generation of session keys for application use + was added to Section 3, urging the inclusion of key entropy from the + KDC generated session key in the ticket. An example regarding use of + the sub-session key was added to Section 3.2.6. Descriptions of the + pa-etype-info, pa-etype-info2, and pa-pw-salt pre-authentication data + items were added. The recommendation for use of pre-authentication + was changed from "MAY" to "SHOULD" and a note was added regarding + known plaintext attacks. + + In RFC 1510, Section 4 described the database in the KDC. This + discussion was not necessary for interoperability and unnecessarily + constrained implementation. The old Section 4 was removed. + + The current Section 4 was formerly Section 6 on encryption and + checksum specifications. The major part of this section was brought + up to date to support new encryption methods, and moved to a separate + document. Those few remaining aspects of the encryption and checksum + specification specific to Kerberos are now specified in Section 4. + + Significant changes were made to the layout of Section 5 to clarify + the correct behavior for optional fields. Many of these changes were + made necessary because of improper ASN.1 description in the original + Kerberos specification which left the correct behavior + underspecified. Additionally, the wording in this section was + tightened wherever possible to ensure that implementations conforming + to this specification will be extensible with the addition of new + fields in future specifications. + + Text was added describing time_t=0 issues in the ASN.1. Text was + also added, clarifying issues with implementations treating omitted + optional integers as zero. Text was added clarifying behavior for + optional SEQUENCE or SEQUENCE OF that may be empty. Discussion was + added regarding sequence numbers and behavior of some + implementations, including "zero" behavior and negative numbers. A + compatibility note was added regarding the unconditional sending of + EncTGSRepPart regardless of the enclosing reply type. Minor changes + were made to the description of the HostAddresses type. Integer + types were constrained. KerberosString was defined as a + (significantly) constrained GeneralString. KerberosFlags was defined + to reflect existing implementation behavior that departs from the + + + + + +Neuman, et al. Standards Track [Page 132] + +RFC 4120 Kerberos V5 July 2005 + + + definition in RFC 1510. The transited-policy-checked(12) and the + ok-as-delegate(13) ticket flags were added. The disable-transited- + check(26) KDC option was added. + + Descriptions of commonly implemented PA-DATA were added to Section 5. + The description of KRB-SAFE has been updated to note the existing + implementation behavior of double-encoding. + + There were two definitions of METHOD-DATA in RFC 1510. The second + one, intended for use with KRB_AP_ERR_METHOD was removed leaving the + SEQUENCE OF PA-DATA definition. + + Section 7, naming constraints, from RFC 1510 was moved to Section 6. + + Words were added describing the convention that domain-based realm + names for newly-created realms should be specified as uppercase. + This recommendation does not make lowercase realm names illegal. + Words were added highlighting that the slash-separated components in + the X.500 style of realm names is consistent with existing RFC 1510 + based implementations, but that it conflicts with the general + recommendation of X.500 name representation specified in RFC 2253. + + Section 8, network transport, constants and defined values, from RFC + 1510 was moved to Section 7. Since RFC 1510, the definition of the + TCP transport for Kerberos messages was added, and the encryption and + checksum number assignments have been moved into a separate document. + + "Specification 2" in Section 8 of the current document changes the + required encryption and checksum methods to bring them in line with + the best current practices and to deprecate methods that are no + longer considered sufficiently strong. + + Two new sections, on IANA considerations and security considerations + were added. + + The pseudo-code has been removed from the appendix. The pseudo-code + was sometimes misinterpreted to limit implementation choices and in + RFC 1510, it was not always consistent with the words in the + specification. Effort was made to clear up any ambiguities in the + specification, rather than to rely on the pseudo-code. + + An appendix was added containing the complete ASN.1 module drawn from + the discussion in Section 5 of the current document. + +END NOTES + + (*TM) Project Athena, Athena, and Kerberos are trademarks of the + Massachusetts Institute of Technology (MIT). + + + +Neuman, et al. Standards Track [Page 133] + +RFC 4120 Kerberos V5 July 2005 + + +Normative References + + [RFC3961] Raeburn, K., "Encryption and Checksum + Specifications for Kerberos 5", RFC 3961, February + 2005. + + [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) + Encryption for Kerberos 5", RFC 3962, February + 2005. + + [ISO-646/ECMA-6] International Organization for Standardization, + "7-bit Coded Character Set for Information + Interchange", ISO/IEC 646:1991. + + [ISO-2022/ECMA-35] International Organization for Standardization, + "Character code structure and extension + techniques", ISO/IEC 2022:1994. + + [RFC1035] Mockapetris, P., "Domain names - implementation + and specification", STD 13, RFC 1035, November + 1987. + + [RFC2119] Bradner, S., "Key words for use in RFCs to + Indicate Requirement Levels", BCP 14, RFC 2119, + March 1997. + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for + Writing an IANA Considerations Section in RFCs", + BCP 26, RFC 2434, October 1998. + + [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS + RR for specifying the location of services (DNS + SRV)", RFC 2782, February 2000. + + [RFC2253] Wahl, M., Kille, S., and T. Howes, "Lightweight + Directory Access Protocol (v3): UTF-8 String + Representation of Distinguished Names", RFC 2253, + December 1997. + + [RFC3513] Hinden, R. and S. Deering, "Internet Protocol + Version 6 (IPv6) Addressing Architecture", RFC + 3513, April 2003. + + [X680] Abstract Syntax Notation One (ASN.1): + Specification of Basic Notation, ITU-T + Recommendation X.680 (1997) | ISO/IEC + International Standard 8824-1:1998. + + + + +Neuman, et al. Standards Track [Page 134] + +RFC 4120 Kerberos V5 July 2005 + + + [X690] ASN.1 encoding rules: Specification of Basic + Encoding Rules (BER), Canonical Encoding Rules + (CER) and Distinguished Encoding Rules (DER), + ITU-T Recommendation X.690 (1997)| ISO/IEC + International Standard 8825-1:1998. + +Informative References + + [ISO-8859] International Organization for Standardization, + "8-bit Single-byte Coded Graphic Character Sets -- + Latin Alphabet", ISO/IEC 8859. + + [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API + Mechanism", RFC 1964, June 1996. + + [DGT96] Don Davis, Daniel Geer, and Theodore Ts'o, + "Kerberos With Clocks Adrift: History, Protocols, + and Implementation", USENIX Computing Systems 9:1, + January 1996. + + [DS81] Dorothy E. Denning and Giovanni Maria Sacco, + "Time-stamps in Key Distribution Protocols," + Communications of the ACM, Vol. 24 (8), p. 533- + 536, August 1981. + + [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. + + [MNSS87] S. P. Miller, B. C. Neuman, J. I. Schiller, and J. + H. Saltzer, Section E.2.1: Kerberos Authentication + and Authorization System, M.I.T. Project Athena, + Cambridge, Massachusetts, December 21, 1987. + + [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. + + [Neu93] B. Clifford Neuman, "Proxy-Based Authorization and + Accounting for Distributed Systems," in + Proceedings of the 13th International Conference + on Distributed Computing Systems, Pittsburgh, PA, + May 1993. + + + + + +Neuman, et al. Standards Track [Page 135] + +RFC 4120 Kerberos V5 July 2005 + + + [NT94] B. Clifford Neuman and Theodore Y. Ts'o, "An + Authentication Service for Computer Networks," + IEEE Communications Magazine, Vol. 32 (9), p. 33- + 38, September 1994. + + [Pat92] J. Pato, Using Pre-Authentication to Avoid + Password Guessing Attacks, Open Software + Foundation DCE Request for Comments 26 (December + 1992. + + [RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network + Authentication Service (V5)", RFC 1510, September + 1993. + + [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, + RFC 4086, June 2005. + + [SNS88] J. G. Steiner, B. C. Neuman, and J. I. Schiller, + "Kerberos: An Authentication Service for Open + Network Systems," p. 191-202, Usenix Conference + Proceedings, Dallas, Texas, February 1988. + + [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The + Kerberos Version 5 Generic Security Service + Application Program Interface (GSS-API) Mechanism: + Version 2", RFC 4121, July 2005. + + + + + + + + + + + + + + + + + + + + + + + + +Neuman, et al. Standards Track [Page 136] + +RFC 4120 Kerberos V5 July 2005 + + +Authors' Addresses + + Clifford Neuman + Information Sciences Institute + University of Southern California + 4676 Admiralty Way + Marina del Rey, CA 90292, USA + + EMail: bcn@isi.edu + + + Tom Yu + Massachusetts Institute of Technology + 77 Massachusetts Avenue + Cambridge, MA 02139, USA + + EMail: tlyu@mit.edu + + + Sam Hartman + Massachusetts Institute of Technology + 77 Massachusetts Avenue + Cambridge, MA 02139, USA + + EMail: hartmans-ietf@mit.edu + + + Kenneth Raeburn + Massachusetts Institute of Technology + 77 Massachusetts Avenue + Cambridge, MA 02139, USA + + EMail: raeburn@mit.edu + + + + + + + + + + + + + + + + + + +Neuman, et al. Standards Track [Page 137] + +RFC 4120 Kerberos V5 July 2005 + + +Full 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 + + 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Neuman, et al. Standards Track [Page 138] + |