1/30/24, 4:46 PM
`
`ietf.org/rfc/rfc4120.txt
`
`Network Working Group
`Request for Comments: 4120
`Obsoletes: 1510
`Category: Standards Track
`
`C. Neuman
`USC-ISI
`T. Yu
`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
`
`RFC 4120
`
`Kerberos V5
`
`[Page 1]
`
`July 2005
`
`Table of Contents
`
`https://www.ietf.org/rfc/rfc4120.txt
`
`1/119
`
`APPL-1033
`APPLE INC./Page 1 of 119
`
`

`

`ietf.org/rfc/rfc4120.txt
`1/30/24, 4:46 PM
` 1. Introduction ....................................................5
` 1.1. The Kerberos Protocol ......................................6
` 1.2. Cross-Realm Operation ......................................8
` 1.3. Choosing a Principal with Which to Communicate .............9
` 1.4. Authorization .............................................10
` 1.5. Extending Kerberos without Breaking Interoperability ......11
` 1.5.1. Compatibility with RFC 1510 ........................11
` 1.5.2. Sending Extensible Messages ........................12
` 1.6. Environmental Assumptions .................................12
` 1.7. Glossary of Terms .........................................13
` 2. Ticket Flag Uses and Requests ..................................16
` 2.1. Initial, Pre-authenticated, and
` Hardware-Authenticated Tickets ............................17
` 2.2. Invalid Tickets ...........................................17
` 2.3. Renewable Tickets .........................................17
` 2.4. Postdated Tickets .........................................18
` 2.5. Proxiable and Proxy Tickets ...............................19
` 2.6. Forwardable Tickets .......................................19
` 2.7. Transited Policy Checking .................................20
` 2.8. OK as Delegate ............................................21
` 2.9. Other KDC Options .........................................21
` 2.9.1. Renewable-OK .......................................21
` 2.9.2. ENC-TKT-IN-SKEY ....................................22
` 2.9.3. Passwordless Hardware Authentication ...............22
` 3. Message Exchanges ..............................................22
` 3.1. The Authentication Service Exchange .......................22
` 3.1.1. Generation of KRB_AS_REQ Message ...................24
` 3.1.2. Receipt of KRB_AS_REQ Message ......................24
` 3.1.3. Generation of KRB_AS_REP Message ...................24
` 3.1.4. Generation of KRB_ERROR Message ....................27
` 3.1.5. Receipt of KRB_AS_REP Message ......................27
` 3.1.6. Receipt of KRB_ERROR Message .......................28
` 3.2. The Client/Server Authentication Exchange .................29
` 3.2.1. The KRB_AP_REQ Message .............................29
` 3.2.2. Generation of a KRB_AP_REQ Message .................29
` 3.2.3. Receipt of KRB_AP_REQ Message ......................30
` 3.2.4. Generation of a KRB_AP_REP Message .................33
` 3.2.5. Receipt of KRB_AP_REP Message ......................33
` 3.2.6. Using the Encryption Key ...........................33
` 3.3. The Ticket-Granting Service (TGS) Exchange ................34
` 3.3.1. Generation of KRB_TGS_REQ Message ..................35
` 3.3.2. Receipt of KRB_TGS_REQ Message .....................37
` 3.3.3. Generation of KRB_TGS_REP Message ..................38
` 3.3.4. Receipt of KRB_TGS_REP Message .....................42
`
`Neuman, et al. Standards Track [Page 2]
`
`RFC 4120 Kerberos V5 July 2005
`
` 3.4. The KRB_SAFE Exchange .....................................42
` 3.4.1. Generation of a KRB_SAFE Message ...................42
` 3.4.2. Receipt of KRB_SAFE Message ........................43
` 3.5. The KRB_PRIV Exchange .....................................44
` 3.5.1. Generation of a KRB_PRIV Message ...................44
` 3.5.2. Receipt of KRB_PRIV Message ........................44
` 3.6. The KRB_CRED Exchange .....................................45
` 3.6.1. Generation of a KRB_CRED Message ...................45
` 3.6.2. Receipt of KRB_CRED Message ........................46
` 3.7. User-to-User Authentication Exchanges .....................47
` 4. Encryption and Checksum Specifications .........................48
`
`https://www.ietf.org/rfc/rfc4120.txt
`
`2/119
`
`APPL-1033
`APPLE INC./Page 2 of 119
`
`

`

`ietf.org/rfc/rfc4120.txt
`1/30/24, 4:46 PM
` 5. Message Specifications .........................................50
` 5.1. Specific Compatibility Notes on ASN.1 .....................51
` 5.1.1. ASN.1 Distinguished Encoding Rules .................51
` 5.1.2. Optional Integer Fields ............................52
` 5.1.3. Empty SEQUENCE OF Types ............................52
` 5.1.4. Unrecognized Tag Numbers ...........................52
` 5.1.5. Tag Numbers Greater Than 30 ........................53
` 5.2. Basic Kerberos Types ......................................53
` 5.2.1. KerberosString .....................................53
` 5.2.2. Realm and PrincipalName ............................55
` 5.2.3. KerberosTime .......................................55
` 5.2.4. Constrained Integer Types ..........................55
` 5.2.5. HostAddress and HostAddresses ......................56
` 5.2.6. AuthorizationData ..................................57
` 5.2.7. PA-DATA ............................................60
` 5.2.8. KerberosFlags ......................................64
` 5.2.9. Cryptosystem-Related Types .........................65
` 5.3. Tickets ...................................................66
` 5.4. Specifications for the AS and TGS Exchanges ...............73
` 5.4.1. KRB_KDC_REQ Definition .............................73
` 5.4.2. KRB_KDC_REP Definition .............................81
` 5.5. Client/Server (CS) Message Specifications .................84
` 5.5.1. KRB_AP_REQ Definition ..............................84
` 5.5.2. KRB_AP_REP Definition ..............................88
` 5.5.3. Error Message Reply ................................89
` 5.6. KRB_SAFE Message Specification ............................89
` 5.6.1. KRB_SAFE definition ................................89
` 5.7. KRB_PRIV Message Specification ............................91
` 5.7.1. KRB_PRIV Definition ................................91
` 5.8. KRB_CRED Message Specification ............................92
` 5.8.1. KRB_CRED Definition ................................92
` 5.9. Error Message Specification ...............................94
` 5.9.1. KRB_ERROR Definition ...............................94
` 5.10. Application Tag Numbers ..................................96
`
`Neuman, et al. Standards Track [Page 3]
`
`RFC 4120 Kerberos V5 July 2005
`
` 6. Naming Constraints .............................................97
` 6.1. Realm Names ...............................................97
` 6.2. Principal Names .......................................... 99
` 6.2.1. Name of Server Principals .........................100
` 7. Constants and Other Defined Values ............................101
` 7.1. Host Address Types .......................................101
` 7.2. KDC Messaging: IP Transports .............................102
` 7.2.1. UDP/IP transport ..................................102
` 7.2.2. TCP/IP Transport ..................................103
` 7.2.3. KDC Discovery on IP Networks ......................104
` 7.3. Name of the TGS ..........................................105
` 7.4. OID Arc for KerberosV5 ...................................106
` 7.5. Protocol Constants and Associated Values .................106
` 7.5.1. Key Usage Numbers .................................106
` 7.5.2. PreAuthentication Data Types ......................108
` 7.5.3. Address Types .....................................109
` 7.5.4. Authorization Data Types ..........................109
` 7.5.5. Transited Encoding Types ..........................109
` 7.5.6. Protocol Version Number ...........................109
` 7.5.7. Kerberos Message Types ............................110
`
`https://www.ietf.org/rfc/rfc4120.txt
`
`3/119
`
`APPL-1033
`APPLE INC./Page 3 of 119
`
`

`

`ietf.org/rfc/rfc4120.txt
`1/30/24, 4:46 PM
` 7.5.8. Name Types ........................................110
` 7.5.9. Error Codes .......................................110
` 8. Interoperability Requirements .................................113
` 8.1. Specification 2 ..........................................113
` 8.2. Recommended KDC Values ...................................116
` 9. IANA Considerations ...........................................116
` 10. Security Considerations ......................................117
` 11. Acknowledgements .............................................121
` A. ASN.1 Module ..................................................123
` B. Changes since RFC 1510 ........................................131
` Normative References .............................................134
` Informative References ...........................................135
`
`Neuman, et al. Standards Track [Page 4]
`
`RFC 4120 Kerberos V5 July 2005
`
`1. Introduction
`
` This document describes the concepts and model upon which the
` Kerberos network authentication system is based. It also specifies
` Version 5 of the Kerberos protocol. The motivations, goals,
` assumptions, and rationale behind most design decisions are treated
` cursorily; they are more fully described in a paper available in IEEE
` communications [NT94] and earlier in the Kerberos portion of the
` Athena Technical Plan [MNSS87].
`
` This document is not intended to describe Kerberos to the end user,
` system administrator, or application developer. Higher-level papers
` describing Version 5 of the Kerberos system [NT94] and documenting
` version 4 [SNS88] are available elsewhere.
`
` The Kerberos model is based in part on Needham and Schroeder's
` trusted third-party authentication protocol [NS78] and on
` modifications suggested by Denning and Sacco [DS81]. The original
` design and implementation of Kerberos Versions 1 through 4 was the
` work of two former Project Athena staff members, Steve Miller of
` Digital Equipment Corporation and Clifford Neuman (now at the
` Information Sciences Institute of the University of Southern
` California), along with Jerome Saltzer, Technical Director of Project
` Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other
` members of Project Athena have also contributed to the work on
` Kerberos.
`
` Version 5 of the Kerberos protocol (described in this document) has
` evolved because of new requirements and desires for features not
`
`https://www.ietf.org/rfc/rfc4120.txt
`
`4/119
`
`APPL-1033
`APPLE INC./Page 4 of 119
`
`

`

`ietf.org/rfc/rfc4120.txt
`1/30/24, 4:46 PM
` available in Version 4. The design of Version 5 was led by Clifford
` Neuman and John Kohl with much input from the community. The
` development of the MIT reference implementation was led at MIT by
` John Kohl and Theodore Ts'o, with help and contributed code from many
` others. Since RFC 1510 was issued, many individuals have proposed
` extensions and revisions to the protocol. This document reflects
` some of these proposals. Where such changes involved significant
` effort, the document cites the contribution of the proposer.
`
` Reference implementations of both Version 4 and Version 5 of Kerberos
` are publicly available, and commercial implementations have been
` developed and are widely used. Details on the differences between
` Versions 4 and 5 can be found in [KNT94].
`
` The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
` "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
` document are to be interpreted as described in [RFC2119].
`
`Neuman, et al. Standards Track [Page 5]
`
`RFC 4120 Kerberos V5 July 2005
`
`1.1. The Kerberos Protocol
`
` Kerberos provides a means of verifying the identities of principals,
` (e.g., a workstation user or a network server) on an open
` (unprotected) network. This is accomplished without relying on
` assertions by the host operating system, without basing trust on host
` addresses, without requiring physical security of all the hosts on
` the network, and under the assumption that packets traveling along
` the network can be read, modified, and inserted at will. Kerberos
` performs authentication under these conditions as a trusted third-
` party authentication service by using conventional (shared secret
` key) cryptography. Extensions to Kerberos (outside the scope of this
` document) can provide for the use of public key cryptography during
` certain phases of the authentication protocol. Such extensions
` support Kerberos authentication for users registered with public key
` certification authorities and provide certain benefits of public key
` cryptography in situations where they are needed.
`
` The basic Kerberos authentication process proceeds as follows: A
` client sends a request to the authentication server (AS) for
` "credentials" for a given server. The AS responds with these
` credentials, encrypted in the client's key. The credentials consist
` of a "ticket" for the server and a temporary encryption key (often
` called a "session key"). The client transmits the ticket (which
` contains the client's identity and a copy of the session key, all
` encrypted in the server's key) to the server. The session key (now
` shared by the client and server) is used to authenticate the client
` and may optionally be used to authenticate the server. It may also
` be used to encrypt further communication between the two parties or
` to exchange a separate sub-session key to be used to encrypt further
` communication. Note that many applications use Kerberos' functions
` only upon the initiation of a stream-based network connection.
` Unless an application performs encryption or integrity protection for
` the data stream, the identity verification applies only to the
` initiation of the connection, and it does not guarantee that
` subsequent messages on the connection originate from the same
` principal.
`
`https://www.ietf.org/rfc/rfc4120.txt
`
`5/119
`
`APPL-1033
`APPLE INC./Page 5 of 119
`
`

`

`ietf.org/rfc/rfc4120.txt
`1/30/24, 4:46 PM
` Implementation of the basic protocol consists of one or more
` authentication servers running on physically secure hosts. The
` authentication servers maintain a database of principals (i.e., users
` and servers) and their secret keys. Code libraries provide
` encryption and implement the Kerberos protocol. In order to add
` authentication to its transactions, a typical network application
` adds calls to the Kerberos library directly or through the Generic
` Security Services Application Programming Interface (GSS-API)
` described in a separate document [RFC4121]. These calls result in
` the transmission of the messages necessary to achieve authentication.
`
`Neuman, et al. Standards Track [Page 6]
`
`RFC 4120 Kerberos V5 July 2005
`
` The Kerberos protocol consists of several sub-protocols (or
` exchanges). There are two basic methods by which a client can ask a
` Kerberos server for credentials. In the first approach, the client
` sends a cleartext request for a ticket for the desired server to the
` AS. The reply is sent encrypted in the client's secret key. Usually
` this request is for a ticket-granting ticket (TGT), which can later
` be used with the ticket-granting server (TGS). In the second method,
` the client sends a request to the TGS. The client uses the TGT to
` authenticate itself to the TGS in the same manner as if it were
` contacting any other application server that requires Kerberos
` authentication. The reply is encrypted in the session key from the
` TGT. Though the protocol specification describes the AS and the TGS
` as separate servers, in practice they are implemented as different
` protocol entry points within a single Kerberos server.
`
` Once obtained, credentials may be used to verify the identity of the
` principals in a transaction, to ensure the integrity of messages
` exchanged between them, or to preserve privacy of the messages. The
` application is free to choose whatever protection may be necessary.
`
` To verify the identities of the principals in a transaction, the
` client transmits the ticket to the application server. Because the
` ticket is sent "in the clear" (parts of it are encrypted, but this
` encryption doesn't thwart replay) and might be intercepted and reused
` by an attacker, additional information is sent to prove that the
` message originated with the principal to whom the ticket was issued.
` This information (called the authenticator) is encrypted in the
` session key and includes a timestamp. The timestamp proves that the
` message was recently generated and is not a replay. Encrypting the
` authenticator in the session key proves that it was generated by a
` party possessing the session key. Since no one except the requesting
` principal and the server know the session key (it is never sent over
` the network in the clear), this guarantees the identity of the
` client.
`
` The integrity of the messages exchanged between principals can also
` be guaranteed by using the session key (passed in the ticket and
` contained in the credentials). This approach provides detection of
` both replay attacks and message stream modification attacks. It is
` accomplished by generating and transmitting a collision-proof
` checksum (elsewhere called a hash or digest function) of the client's
` message, keyed with the session key. Privacy and integrity of the
` messages exchanged between principals can be secured by encrypting
` the data to be passed by using the session key contained in the
` ticket or the sub-session key found in the authenticator.
`
`https://www.ietf.org/rfc/rfc4120.txt
`
`6/119
`
`APPL-1033
`APPLE INC./Page 6 of 119
`
`

`

`1/30/24, 4:46 PM
`
`ietf.org/rfc/rfc4120.txt
`
`Neuman, et al. Standards Track [Page 7]
`
`RFC 4120 Kerberos V5 July 2005
`
` The authentication exchanges mentioned above require read-only access
` to the Kerberos database. Sometimes, however, the entries in the
` database must be modified, such as when adding new principals or
` changing a principal's key. This is done using a protocol between a
` client and a third Kerberos server, the Kerberos Administration
` Server (KADM). There is also a protocol for maintaining multiple
` copies of the Kerberos database. Neither of these protocols are
` described in this document.
`
`1.2. Cross-Realm Operation
`
` The Kerberos protocol is designed to operate across organizational
` boundaries. A client in one organization can be authenticated to a
` server in another. Each organization wishing to run a Kerberos
` server establishes its own "realm". The name of the realm in which a
` client is registered is part of the client's name and can be used by
` the end-service to decide whether to honor a request.
`
` By establishing "inter-realm" keys, the administrators of two realms
` can allow a client authenticated in the local realm to prove its
` identity to servers in other realms. The exchange of inter-realm
` keys (a separate key may be used for each direction) registers the
` ticket-granting service of each realm as a principal in the other
` realm. A client is then able to obtain a TGT for the remote realm's
` ticket-granting service from its local realm. When that TGT is used,
` the remote ticket-granting service uses the inter-realm key (which
` usually differs from its own normal TGS key) to decrypt the TGT; thus
` it is certain that the ticket was issued by the client's own TGS.
` Tickets issued by the remote ticket-granting service will indicate to
` the end-service that the client was authenticated from another realm.
`
` Without cross-realm operation, and with appropriate permission, the
` client can arrange registration of a separately-named principal in a
` remote realm and engage in normal exchanges with that realm's
` services. However, for even small numbers of clients this becomes
` cumbersome, and more automatic methods as described here are
` necessary.
`
` A realm is said to communicate with another realm if the two realms
` share an inter-realm key, or if the local realm shares an inter-realm
` key with an intermediate realm that communicates with the remote
` realm. An authentication path is the sequence of intermediate realms
` that are transited in communicating from one realm to another.
`
` Realms may be organized hierarchically. Each realm shares a key with
` its parent and a different key with each child. If an inter-realm
` key is not directly shared by two realms, the hierarchical
` organization allows an authentication path to be easily constructed.
`
`Neuman, et al. Standards Track [Page 8]
`
`RFC 4120 Kerberos V5 July 2005
`
`https://www.ietf.org/rfc/rfc4120.txt
`
`7/119
`
`APPL-1033
`APPLE INC./Page 7 of 119
`
`

`

`ietf.org/rfc/rfc4120.txt
`1/30/24, 4:46 PM
` If a hierarchical organization is not used, it may be necessary to
` consult a database in order to construct an authentication path
` between realms.
`
` Although realms are typically hierarchical, intermediate realms may
` be bypassed to achieve cross-realm authentication through alternate
` authentication paths. (These might be established to make
` communication between two realms more efficient.) It is important
` for the end-service to know which realms were transited when deciding
` how much faith to place in the authentication process. To facilitate
` this decision, a field in each ticket contains the names of the
` realms that were involved in authenticating the client.
`
` The application server is ultimately responsible for accepting or
` rejecting authentication and SHOULD check the transited field. The
` application server may choose to rely on the Key Distribution Center
` (KDC) for the application server's realm to check the transited
` field. The application server's KDC will set the
` TRANSITED-POLICY-CHECKED flag in this case. The KDCs for
` intermediate realms may also check the transited field as they issue
` TGTs for other realms, but they are encouraged not to do so. A
` client may request that the KDCs not check the transited field by
` setting the DISABLE-TRANSITED-CHECK flag. KDCs SHOULD honor this
` flag.
`
`1.3. Choosing a Principal with Which to Communicate
`
` The Kerberos protocol provides the means for verifying (subject to
` the assumptions in Section 1.6) that the entity with which one
` communicates is the same entity that was registered with the KDC
` using the claimed identity (principal name). It is still necessary
` to determine whether that identity corresponds to the entity with
` which one intends to communicate.
`
` When appropriate data has been exchanged in advance, the application
` may perform this determination syntactically based on the application
` protocol specification, information provided by the user, and
` configuration files. For example, the server principal name
` (including realm) for a telnet server might be derived from the
` user-specified host name (from the telnet command line), the "host/"
` prefix specified in the application protocol specification, and a
` mapping to a Kerberos realm derived syntactically from the domain
` part of the specified hostname and information from the local
` Kerberos realms database.
`
` One can also rely on trusted third parties to make this
` determination, but only when the data obtained from the third party
` is suitably integrity-protected while resident on the third-party
`
`Neuman, et al. Standards Track [Page 9]
`
`RFC 4120 Kerberos V5 July 2005
`
` server and when transmitted. Thus, for example, one should not rely
` on an unprotected DNS record to map a host alias to the primary name
` of a server, accepting the primary name as the party that one intends
` to contact, since an attacker can modify the mapping and impersonate
` the party.
`
` Implementations of Kerberos and protocols based on Kerberos MUST NOT
` use insecure DNS queries to canonicalize the hostname components of
` the service principal names (i.e., they MUST NOT use insecure DNS
`
`https://www.ietf.org/rfc/rfc4120.txt
`
`8/119
`
`APPL-1033
`APPLE INC./Page 8 of 119
`
`

`

`ietf.org/rfc/rfc4120.txt
`1/30/24, 4:46 PM
` queries to map one name to another to determine the host part of the
` principal name with which one is to communicate). In an environment
` without secure name service, application authors MAY append a
` statically configured domain name to unqualified hostnames before
` passing the name to the security mechanisms, but they should do no
` more than that. Secure name service facilities, if available, might
` be trusted for hostname canonicalization, but such canonicalization
` by the client SHOULD NOT be required by KDC implementations.
`
` Implementation note: Many current implementations do some degree of
` canonicalization of the provided service name, often using DNS even
` though it creates security problems. However, there is no
` consistency among implementations as to whether the service name is
` case folded to lowercase or whether reverse resolution is used. To
` maximize interoperability and security, applications SHOULD provide
` security mechanisms with names that result from folding the user-
` entered name to lowercase without performing any other modifications
` or canonicalization.
`
`1.4. Authorization
`
` As an authentication service, Kerberos provides a means of verifying
` the identity of principals on a network. Authentication is usually
` useful primarily as a first step in the process of authorization,
` determining whether a client may use a service, which objects the
` client is allowed to access, and the type of access allowed for each.
` Kerberos does not, by itself, provide authorization. Possession of a
` client ticket for a service provides only for authentication of the
` client to that service, and in the absence of a separate
` authorization procedure, an application should not consider it to
` authorize the use of that service.
`
` Separate authorization methods MAY be implemented as application-
` specific access control functions and may utilize files on the
` application server, on separately issued authorization credentials
` such as those based on proxies [Neu93], or on other authorization
` services. Separately authenticated authorization credentials MAY be
` embedded in a ticket's authorization data when encapsulated by the
` KDC-issued authorization data element.
`
`Neuman, et al. Standards Track [Page 10]
`
`RFC 4120 Kerberos V5 July 2005
`
` Applications should not accept the mere issuance of a service ticket
` by the Kerberos server (even by a modified Kerberos server) as
` granting authority to use the service, since such applications may
` become vulnerable to the bypass of this authorization check in an
` environment where other options for application authentication are
` provided, or if they interoperate with other KDCs.
`
`1.5. Extending Kerberos without Breaking Interoperability
`
` As the deployed base of Kerberos implementations grows, extending
` Kerberos becomes more important. Unfortunately, some extensions to
` the existing Kerberos protocol create interoperability issues because
` of uncertainty regarding the treatment of certain extensibility
` options by some implementations. This section includes guidelines
` that will enable future implementations to maintain interoperability.
`
` Kerberos provides a general mechanism for protocol extensibility.
` Some protocol messages contain typed holes -- sub-messages that
`
`https://www.ietf.org/rfc/rfc4120.txt
`
`9/119
`
`APPL-1033
`APPLE INC./Page 9 of 119
`
`

`

`ietf.org/rfc/rfc4120.txt
`1/30/24, 4:46 PM
` contain an octet-string along with an integer that defines how to
` interpret the octet-string. The integer types are registered
` centrally, but they can be used both for vendor extensions and for
` extensions standardized through the IETF.
`
` In this document, the word "extension" refers to extension by
` defining a new type to insert into an existing typed hole in a
` protocol message. It does not refer to extension by addition of new
` fields to ASN.1 types, unless the text explicitly indicates
` otherwise.
`
`1.5.1. Compatibility with RFC 1510
`
` Note that existing Kerberos message formats cannot readily be
` extended by adding fields to the ASN.1 types. Sending additional
` fields often results in the entire message being discarded without an
` error indication. Future versions of this specification will provide
` guidelines to ensure that ASN.1 fields can be added without creating
` an interoperability problem.
`
` In the meantime, all new or modified implementations of Kerberos that
` receive an unknown message extension SHOULD preserve the encoding of
` the extension but otherwise ignore its presence. Recipients MUST NOT
` decline a request simply because an extension is present.
`
` There is one exception to this rule. If an unknown authorization
` data element type is received by a server other than the ticket-
` granting service either in an AP-REQ or in a ticket contained in an
` AP-REQ, then authentication MUST fail. One of the primary uses of
` authorization data is to restrict the use of the ticket. If the
`
`Neuman, et al. Standards Track [Page 11]
`
`RFC 4120 Kerberos V5 July 2005
`
` service cannot determine whether the restriction applies to that
` service, then a security weakness may result if the ticket can be
` used for that service. Authorization elements that are optional
` SHOULD be enclosed in the AD-IF-RELEVANT element.
`
` The ticket-granting service MUST ignore but propagate to derivative
` tickets any unknown authorization data types, unless those data types
` are embedded in a MANDATORY-FOR-KDC element, in which case the
` request will be rejected. This behavior is appropriate because
` requiring that the ticket-granting service understand unknown
` authorization data types would require that KDC software be upgraded
` to understand new application-level restrictions before applications
`