RFC 4120: The Kerberos Network Authentication Service (V5)
Errata Exist
Updated by: 4537 6649 , PROPOSED STANDARD
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 20051 . IntroductionNT94] 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 20051.1 . The Kerberos ProtocolRFC4121]. 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 2005Neuman, et al. Standards Track [Page 7]
RFC 4120 Kerberos V5 July 20051.2 . Cross-Realm OperationNeuman, et al. Standards Track [Page 8]
RFC 4120 Kerberos V5 July 20051.3 . Choosing a Principal with Which to CommunicateSection 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-partyNeuman, et al. Standards Track [Page 9]
RFC 4120 Kerberos V5 July 20051.4 . AuthorizationNeu93], 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 2005RFC 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 Messages1.6 . Environmental AssumptionsNeuman, et al. Standards Track [Page 12]
RFC 4120 Kerberos V5 July 20051.7 . Glossary of TermsNeuman, et al. Standards Track [Page 13]
RFC 4120 Kerberos V5 July 2005Neuman, et al. Standards Track [Page 14]
RFC 4120 Kerberos V5 July 2005Neuman, et al. Standards Track [Page 15]
RFC 4120 Kerberos V5 July 20052 . Ticket Flag Uses and RequestsRFC 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 2005Section 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 TicketsNeuman, et al. Standards Track [Page 18]
RFC 4120 Kerberos V5 July 20052.5 . Proxiable and Proxy Tickets2.6 . Forwardable TicketsNeuman, et al. Standards Track [Page 19]
RFC 4120 Kerberos V5 July 20052.7 . Transited Policy CheckingNeuman, et al. Standards Track [Page 20]
RFC 4120 Kerberos V5 July 20052.9.2 . ENC-TKT-IN-SKEYSection 3.3.3 for specific details. 2.9.3 . Passwordless Hardware Authentication3 . Message Exchanges3.1 . The Authentication Service ExchangeSection 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 20055.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 20053.1.1 . Generation of KRB_AS_REQ Message3.1.2 . Receipt of KRB_AS_REQ MessageSection 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 MessageNeuman, et al. Standards Track [Page 24]
RFC 4120 Kerberos V5 July 2005RFC4086] 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 2005Neuman, et al. Standards Track [Page 26]
RFC 4120 Kerberos V5 July 2005Section 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 MessageSection 5.9.1. 3.1.5 . Receipt of KRB_AS_REP MessageNeuman, et al. Standards Track [Page 27]
RFC 4120 Kerberos V5 July 2005DGT96]. 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 MessageNeuman, et al. Standards Track [Page 28]
RFC 4120 Kerberos V5 July 20053.2 . The Client/Server Authentication Exchange3.2.1 . The KRB_AP_REQ MessageSection 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 MessageNeuman, et al. Standards Track [Page 29]
RFC 4120 Kerberos V5 July 2005section 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 MessageSection 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), theNeuman, et al. Standards Track [Page 30]
RFC 4120 Kerberos V5 July 2005Neuman, et al. Standards Track [Page 31]
RFC 4120 Kerberos V5 July 2005Neuman, et al. Standards Track [Page 32]
RFC 4120 Kerberos V5 July 20053.2.4 . Generation of a KRB_AP_REP Message3.2.5 . Receipt of KRB_AP_REP Message3.2.6 . Using the Encryption KeyNeuman, et al. Standards Track [Page 33]
RFC 4120 Kerberos V5 July 2005section 3.5). The KRB_SAFE message (Section 3.4) can be used to ensure integrity. 3.3 . The Ticket-Granting Service (TGS) ExchangeSection 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'sNeuman, et al. Standards Track [Page 34]
RFC 4120 Kerberos V5 July 2005Section 3.1 apply to the TGS exchange. 3.3.1 . Generation of KRB_TGS_REQ MessageNeuman, et al. Standards Track [Page 35]
RFC 4120 Kerberos V5 July 2005Section 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 20053.3.2 . Receipt of KRB_TGS_REQ MessageNeuman, et al. Standards Track [Page 37]
RFC 4120 Kerberos V5 July 2005Section 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 MessageSection 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 addressesNeuman, et al. Standards Track [Page 38]
RFC 4120 Kerberos V5 July 2005Section 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 flagNeuman, et al. Standards Track [Page 39]
RFC 4120 Kerberos V5 July 20053.3.3.1 . Checking for Revoked Tickets3.3.3.2 . Encoding the Transited FieldNeuman, et al. Standards Track [Page 40]
RFC 4120 Kerberos V5 July 2005Neuman, et al. Standards Track [Page 41]
RFC 4120 Kerberos V5 July 20053.3.4 . Receipt of KRB_TGS_REP Message3.4 . The KRB_SAFE Exchange3.4.1 . Generation of a KRB_SAFE MessageNeuman, et al. Standards Track [Page 42]
RFC 4120 Kerberos V5 July 2005Section 5.6.1. 3.4.2 . Receipt of KRB_SAFE MessageSection 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 20053.5 . The KRB_PRIV Exchange3.5.1 . Generation of a KRB_PRIV MessageSection 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 MessageNeuman, et al. Standards Track [Page 44]
RFC 4120 Kerberos V5 July 2005Section 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 Exchange3.6.1 . Generation of a KRB_CRED MessageNeuman, et al. Standards Track [Page 45]
RFC 4120 Kerberos V5 July 20053.6.2 . Receipt of KRB_CRED MessageNeuman, et al. Standards Track [Page 46]
RFC 4120 Kerberos V5 July 20053.7 . User-to-User Authentication ExchangesNeuman, et al. Standards Track [Page 47]
RFC 4120 Kerberos V5 July 2005Section 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 SpecificationsRFC3961] 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 2005Section 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 theNeuman, et al. Standards Track [Page 49]
RFC 4120 Kerberos V5 July 20055 . Message SpecificationsAppendix 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 2005RFC1510] 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.15.1.1 . ASN.1 Distinguished Encoding RulesX690]. Some implementations (believed primarily to be those derived from DCE 1.1 and earlier) are known to use the more general Basic EncodingNeuman, et al. Standards Track [Page 51]
RFC 4120 Kerberos V5 July 20055.1.2 . Optional Integer Fields5.1.3 . Empty SEQUENCE OF Types5.1.4 . Unrecognized Tag NumbersNeuman, et al. Standards Track [Page 52]
RFC 4120 Kerberos V5 July 20055.1.5 . Tag Numbers Greater Than 305.2 . Basic Kerberos Types5.2.1 . KerberosStringRFC 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 2005Neuman, et al. Standards Track [Page 54]
RFC 4120 Kerberos V5 July 20055.2.2 . Realm and PrincipalNameSection 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 . KerberosTime5.2.4 . Constrained Integer TypesNeuman, et al. Standards Track [Page 55]
RFC 4120 Kerberos V5 July 2005RFC 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 HostAddressesrfc1510, -- 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 20055.2.6 . AuthorizationDataNeuman, et al. Standards Track [Page 57]
RFC 4120 Kerberos V5 July 20055.2.6.3 . AND-ORNeuman, et al. Standards Track [Page 59]
RFC 4120 Kerberos V5 July 2005Pat92] for additional uses of this field. 5.2.7.1 . PA-TGS-REQ5.2.7.2 . Encrypted Timestamp Pre-authenticationNeuman, et al. Standards Track [Page 61]
RFC 4120 Kerberos V5 July 2005RFC 1510, but many implementations support it. 5.2.7.3 . PA-PW-SALTRFC 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-INFONeuman, et al. Standards Track [Page 62]
RFC 4120 Kerberos V5 July 2005RFC 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-INFO2Section 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 2005RFC 1510. 5.2.8 . KerberosFlagsRFC 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 20055.2.9 . Cryptosystem-Related TypesRFC3961] 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 2005Section 4 for a brief description of the use of encryption and checksums in Kerberos. 5.3 . TicketsNeuman, et al. Standards Track [Page 66]
RFC 4120 Kerberos V5 July 2005Neuman, et al. Standards Track [Page 67]
RFC 4120 Kerberos V5 July 2005Neuman, et al. Standards Track [Page 68]
RFC 4120 Kerberos V5 July 2005Neuman, et al. Standards Track [Page 69]
RFC 4120 Kerberos V5 July 2005RFC 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 theNeuman, et al. Standards Track [Page 70]
RFC 4120 Kerberos V5 July 2005RFC 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 wideNeuman, et al. Standards Track [Page 71]
RFC 4120 Kerberos V5 July 2005Neuman, et al. Standards Track [Page 72]
RFC 4120 Kerberos V5 July 2005Section 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 ExchangesSection 5.9.1. 5.4.1 . KRB_KDC_REQ DefinitionNeuman, et al. Standards Track [Page 73]
RFC 4120 Kerberos V5 July 2005Neuman, et al. Standards Track [Page 74]
RFC 4120 Kerberos V5 July 2005Neuman, et al. Standards Track [Page 75]
RFC 4120 Kerberos V5 July 2005Section 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 theNeuman, et al. Standards Track [Page 76]
RFC 4120 Kerberos V5 July 2005Neuman, et al. Standards Track [Page 77]
RFC 4120 Kerberos V5 July 2005RFC 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 padataNeuman, et al. Standards Track [Page 78]
RFC 4120 Kerberos V5 July 2005section 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 2005Neuman, et al. Standards Track [Page 80]
RFC 4120 Kerberos V5 July 20055.4.2 . KRB_KDC_REP DefinitionNeuman, et al. Standards Track [Page 81]
RFC 4120 Kerberos V5 July 2005Section 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 2005Section 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 2005Section 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 Specifications5.5.1 . KRB_AP_REQ DefinitionNeuman, et al. Standards Track [Page 84]
RFC 4120 Kerberos V5 July 2005Section 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 2005Section 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 2005Section 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 20055.5.2 . KRB_AP_REP DefinitionSection 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 2005Section 5.3.2. 5.5.3 . Error Message ReplySection 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 Specification5.6.1 . KRB_SAFE definitionSection 5.4.1. msg-type is KRB_SAFE.Neuman, et al. Standards Track [Page 89]
RFC 4120 Kerberos V5 July 2005RFC 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 20055.7 . KRB_PRIV Message Specification5.7.1 . KRB_PRIV DefinitionSection 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 2005Section 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 20055.9 . Error Message Specification5.9.1 . KRB_ERROR DefinitionNeuman, et al. Standards Track [Page 94]
RFC 4120 Kerberos V5 July 2005Section 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 20055.10 . Application Tag NumbersNeuman, et al. Standards Track [Page 96]
RFC 4120 Kerberos V5 July 20056 . Naming Constraints6.1 . Realm NamesNeuman, et al. Standards Track [Page 97]
RFC 4120 Kerberos V5 July 2005RFC 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 toNeuman, et al. Standards Track [Page 98]
RFC 4120 Kerberos V5 July 20056.2 . Principal NamesRFC2253] NT-SMTP-NAME 7 Name in form of SMTP email name (e.g., [email protected]) 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 beNeuman, et al. Standards Track [Page 99]
RFC 4120 Kerberos V5 July 2005RFC 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 PrincipalsNeuman, et al. Standards Track [Page 100]
RFC 4120 Kerberos V5 July 20057 . Constants and Other Defined Values7.1 . Host Address TypesRFC3513] 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 20057.2 . KDC Messaging: IP Transports7.2.1 . UDP/IP transportNeuman, et al. Standards Track [Page 102]
RFC 4120 Kerberos V5 July 20057.2.2 . TCP/IP TransportRFC 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 sendNeuman, et al. Standards Track [Page 103]
RFC 4120 Kerberos V5 July 20057.2.3 . KDC Discovery on IP NetworksRFC1035] for storing KDC location information. 7.2.3.1 . DNS vs. Kerberos: Case Sensitivity of Realm NamesNeuman, et al. Standards Track [Page 104]
RFC 4120 Kerberos V5 July 20057.2.3.2 . Specifying KDC Location Information with DNS SRV recordsRFC2782]. 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 Networks7.3 . Name of the TGSNeuman, et al. Standards Track [Page 105]
RFC 4120 Kerberos V5 July 20057.4 . OID Arc for KerberosV5RFC 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 [email protected]. 7.5 . Protocol Constants and Associated Values7.5.1 . Key Usage NumbersRFC3961] 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 20057.5.2 . PreAuthentication Data TypesNeuman, et al. Standards Track [Page 108]
RFC 4120 Kerberos V5 July 20057.5.7 . Kerberos Message Types7.5.8 . Name TypesRFC2253] KRB_NT_SMTP_NAME 7 Name in form of SMTP email name (e.g., [email protected]) KRB_NT_ENTERPRISE 10 Enterprise name; may be mapped to principal name 7.5.9 . Error CodesNeuman, et al. Standards Track [Page 110]
RFC 4120 Kerberos V5 July 2005Neuman, et al. Standards Track [Page 111]
RFC 4120 Kerberos V5 July 2005Neuman, et al. Standards Track [Page 112]
RFC 4120 Kerberos V5 July 20058 . Interoperability Requirements8.1 . Specification 2RFC 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 2005Section 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 2005Neuman, et al. Standards Track [Page 115]
RFC 4120 Kerberos V5 July 20058.2 . Recommended KDC Values9 . IANA ConsiderationsSection 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 2005Section 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 ConsiderationsNeuman, et al. Standards Track [Page 117]
RFC 4120 Kerberos V5 July 2005Neuman, et al. Standards Track [Page 118]
RFC 4120 Kerberos V5 July 2005RFC4086] 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 2005Neuman, et al. Standards Track [Page 120]
RFC 4120 Kerberos V5 July 200511 . AcknowledgementsRFC 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 2005Neuman, et al. Standards Track [Page 122]
RFC 4120 Kerberos V5 July 2005A . ASN.1 moduleRFC 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 2005Neuman, et al. Standards Track [Page 124]
RFC 4120 Kerberos V5 July 2005Neuman, et al. Standards Track [Page 125]
RFC 4120 Kerberos V5 July 2005Neuman, et al. Standards Track [Page 126]
RFC 4120 Kerberos V5 July 2005Neuman, et al. Standards Track [Page 127]
RFC 4120 Kerberos V5 July 2005Neuman, et al. Standards Track [Page 128]
RFC 4120 Kerberos V5 July 2005Neuman, et al. Standards Track [Page 129]
RFC 4120 Kerberos V5 July 2005Neuman, et al. Standards Track [Page 130]
RFC 4120 Kerberos V5 July 2005B . Changes since RFC 1510 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 theNeuman, et al. Standards Track [Page 131]
RFC 4120 Kerberos V5 July 2005section 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 theNeuman, et al. Standards Track [Page 132]
RFC 4120 Kerberos V5 July 2005RFC 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 2005X690] 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 2005NT94] 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 2005Neuman, et al. Standards Track [Page 137]
RFC 4120 Kerberos V5 July 2005BCP 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- [email protected]. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Neuman, et al. Standards Track [Page 138]
![Toni Kroos là ai? [ sự thật về tiểu sử đầy đủ Toni Kroos ]](https://evbn.org/wp-content/uploads/New-Project-6635-1671934592.jpg)
