RFC 4120 - The Kerberos Network Authentication Service (V5)
(Formats: TXT)
Network Working Group C. Neuman
Request for Comments: 4120 USC-ISI
Obsoletes: 1510 T. Yu
Category: Standards Track S. Hartman
K. Raeburn
MIT
July 2005
|
The Kerberos Network Authentication Service (V5)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document provides an overview and specification of Version 5 of
the Kerberos protocol, and it obsoletes RFC 1510 to clarify aspects
of the protocol and its intended use that require more detailed or
clearer explanation than was provided in RFC 1510. This document is
intended to provide a detailed description of the protocol, suitable
for implementation, together with descriptions of the appropriate use
of protocol messages and fields within those messages.
Neuman, et al. Standards Track [Page 1]
RFC 4120 Kerberos V5 July 2005
Table of Contents
1. Introduction ....................................................5
1.1. The Kerberos Protocol ......................................6
1.2. Cross-Realm Operation ......................................8
1.3. Choosing a Principal with Which to Communicate .............9
1.4. Authorization .............................................10
1.5. Extending Kerberos without Breaking Interoperability ......11
1.5.1. Compatibility with RFC 1510 ........................11
1.5.2. Sending Extensible Messages ........................12
1.6. Environmental Assumptions .................................12
1.7. Glossary of Terms .........................................13
2. Ticket Flag Uses and Requests ..................................16
2.1. Initial, Pre-authenticated, and
Hardware-Authenticated Tickets ............................17
2.2. Invalid Tickets ...........................................17
2.3. Renewable Tickets .........................................17
2.4. Postdated Tickets .........................................18
2.5. Proxiable and Proxy Tickets ...............................19
2.6. Forwardable Tickets .......................................19
2.7. Transited Policy Checking .................................20
2.8. OK as Delegate ............................................21
2.9. Other KDC Options .........................................21
2.9.1. Renewable-OK .......................................21
2.9.2. ENC-TKT-IN-SKEY ....................................22
2.9.3. Passwordless Hardware Authentication ...............22
3. Message Exchanges ..............................................22
3.1. The Authentication Service Exchange .......................22
3.1.1. Generation of KRB_AS_REQ Message ...................24
3.1.2. Receipt of KRB_AS_REQ Message ......................24
3.1.3. Generation of KRB_AS_REP Message ...................24
3.1.4. Generation of KRB_ERROR Message ....................27
3.1.5. Receipt of KRB_AS_REP Message ......................27
3.1.6. Receipt of KRB_ERROR Message .......................28
3.2. The Client/Server Authentication Exchange .................29
3.2.1. The KRB_AP_REQ Message .............................29
3.2.2. Generation of a KRB_AP_REQ Message .................29
3.2.3. Receipt of KRB_AP_REQ Message ......................30
3.2.4. Generation of a KRB_AP_REP Message .................33
3.2.5. Receipt of KRB_AP_REP Message ......................33
3.2.6. Using the Encryption Key ...........................33
3.3. The Ticket-Granting Service (TGS) Exchange ................34
3.3.1. Generation of KRB_TGS_REQ Message ..................35
3.3.2. Receipt of KRB_TGS_REQ Message .....................37
3.3.3. Generation of KRB_TGS_REP Message ..................38
3.3.4. Receipt of KRB_TGS_REP Message .....................42
Neuman, et al. Standards Track [Page 2]
RFC 4120 Kerberos V5 July 2005
3.4. The KRB_SAFE Exchange .....................................42
3.4.1. Generation of a KRB_SAFE Message ...................42
3.4.2. Receipt of KRB_SAFE Message ........................43
3.5. The KRB_PRIV Exchange .....................................44
3.5.1. Generation of a KRB_PRIV Message ...................44
3.5.2. Receipt of KRB_PRIV Message ........................44
3.6. The KRB_CRED Exchange .....................................45
3.6.1. Generation of a KRB_CRED Message ...................45
3.6.2. Receipt of KRB_CRED Message ........................46
3.7. User-to-User Authentication Exchanges .....................47
4. Encryption and Checksum Specifications .........................48
5. Message Specifications .........................................50
5.1. Specific Compatibility Notes on ASN.1 .....................51
5.1.1. ASN.1 Distinguished Encoding Rules .................51
5.1.2. Optional Integer Fields ............................52
5.1.3. Empty SEQUENCE OF Types ............................52
5.1.4. Unrecognized Tag Numbers ...........................52
5.1.5. Tag Numbers Greater Than 30 ........................53
5.2. Basic Kerberos Types ......................................53
5.2.1. KerberosString .....................................53
5.2.2. Realm and PrincipalName ............................55
5.2.3. KerberosTime .......................................55
5.2.4. Constrained Integer Types ..........................55
5.2.5. HostAddress and HostAddresses ......................56
5.2.6. AuthorizationData ..................................57
5.2.7. PA-DATA ............................................60
5.2.8. KerberosFlags ......................................64
5.2.9. Cryptosystem-Related Types .........................65
5.3. Tickets ...................................................66
5.4. Specifications for the AS and TGS Exchanges ...............73
5.4.1. KRB_KDC_REQ Definition .............................73
5.4.2. KRB_KDC_REP Definition .............................81
5.5. Client/Server (CS) Message Specifications .................84
5.5.1. KRB_AP_REQ Definition ..............................84
5.5.2. KRB_AP_REP Definition ..............................88
5.5.3. Error Message Reply ................................89
5.6. KRB_SAFE Message Specification ............................89
5.6.1. KRB_SAFE definition ................................89
5.7. KRB_PRIV Message Specification ............................91
5.7.1. KRB_PRIV Definition ................................91
5.8. KRB_CRED Message Specification ............................92
5.8.1. KRB_CRED Definition ................................92
5.9. Error Message Specification ...............................94
5.9.1. KRB_ERROR Definition ...............................94
5.10. Application Tag Numbers ..................................96
Neuman, et al. Standards Track [Page 3]
RFC 4120 Kerberos V5 July 2005
6. Naming Constraints .............................................97
6.1. Realm Names ...............................................97
6.2. Principal Names .......................................... 99
6.2.1. Name of Server Principals .........................100
7. Constants and Other Defined Values ............................101
7.1. Host Address Types .......................................101
7.2. KDC Messaging: IP Transports .............................102
7.2.1. UDP/IP transport ..................................102
7.2.2. TCP/IP Transport ..................................103
7.2.3. KDC Discovery on IP Networks ......................104
7.3. Name of the TGS ..........................................105
7.4. OID Arc for KerberosV5 ...................................106
7.5. Protocol Constants and Associated Values .................106
7.5.1. Key Usage Numbers .................................106
7.5.2. PreAuthentication Data Types ......................108
7.5.3. Address Types .....................................109
7.5.4. Authorization Data Types ..........................109
7.5.5. Transited Encoding Types ..........................109
7.5.6. Protocol Version Number ...........................109
7.5.7. Kerberos Message Types ............................110
7.5.8. Name Types ........................................110
7.5.9. Error Codes .......................................110
8. Interoperability Requirements .................................113
8.1. Specification 2 ..........................................113
8.2. Recommended KDC Values ...................................116
9. IANA Considerations ...........................................116
10. Security Considerations ......................................117
11. Acknowledgements .............................................121
A. ASN.1 Module ..................................................123
B. Changes since RFC 1510 ........................................131
Normative References .............................................134
Informative References ...........................................135
Neuman, et al. Standards Track [Page 4]
RFC 4120 Kerberos V5 July 2005
1. Introduction
This document describes the concepts and model upon which the
Kerberos network authentication system is based. It also specifies
Version 5 of the Kerberos protocol. The motivations, goals,
assumptions, and rationale behind most design decisions are treated
cursorily; they are more fully described in a paper available in IEEE
communications [NT94] and earlier in the Kerberos portion of the
Athena Technical Plan [MNSS87].
This document is not intended to describe Kerberos to the end user,
system administrator, or application developer. Higher-level papers
describing Version 5 of the Kerberos system [NT94] and documenting
version 4 [SNS88] are available elsewhere.
The Kerberos model is based in part on Needham and Schroeder's
trusted third-party authentication protocol [NS78] and on
modifications suggested by Denning and Sacco [DS81]. The original
design and implementation of Kerberos Versions 1 through 4 was the
work of two former Project Athena staff members, Steve Miller of
Digital Equipment Corporation and Clifford Neuman (now at the
Information Sciences Institute of the University of Southern
California), along with Jerome Saltzer, Technical Director of Project
Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other
members of Project Athena have also contributed to the work on
Kerberos.
Version 5 of the Kerberos protocol (described in this document) has
evolved because of new requirements and desires for features not
available in Version 4. The design of Version 5 was led by Clifford
Neuman and John Kohl with much input from the community. The
development of the MIT reference implementation was led at MIT by
John Kohl and Theodore Ts'o, with help and contributed code from many
others. Since RFC 1510 was issued, many individuals have proposed
extensions and revisions to the protocol. This document reflects
some of these proposals. Where such changes involved significant
effort, the document cites the contribution of the proposer.
Reference implementations of both Version 4 and Version 5 of Kerberos
are publicly available, and commercial implementations have been
developed and are widely used. Details on the differences between
Versions 4 and 5 can be found in [KNT94].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Neuman, et al. Standards Track [Page 5]
RFC 4120 Kerberos V5 July 2005
1.1. The Kerberos Protocol
Kerberos provides a means of verifying the identities of principals,
(e.g., a workstation user or a network server) on an open
(unprotected) network. This is accomplished without relying on
assertions by the host operating system, without basing trust on host
addresses, without requiring physical security of all the hosts on
the network, and under the assumption that packets traveling along
the network can be read, modified, and inserted at will. Kerberos
performs authentication under these conditions as a trusted third-
party authentication service by using conventional (shared secret
key) cryptography. Extensions to Kerberos (outside the scope of this
document) can provide for the use of public key cryptography during
certain phases of the authentication protocol. Such extensions
support Kerberos authentication for users registered with public key
certification authorities and provide certain benefits of public key
cryptography in situations where they are needed.
The basic Kerberos authentication process proceeds as follows: A
client sends a request to the authentication server (AS) for
"credentials" for a given server. The AS responds with these
credentials, encrypted in the client's key. The credentials consist
of a "ticket" for the server and a temporary encryption key (often
called a "session key"). The client transmits the ticket (which
contains the client's identity and a copy of the session key, all
encrypted in the server's key) to the server. The session key (now
shared by the client and server) is used to authenticate the client
and may optionally be used to authenticate the server. It may also
be used to encrypt further communication between the two parties or
to exchange a separate sub-session key to be used to encrypt further
communication. Note that many applications use Kerberos' functions
only upon the initiation of a stream-based network connection.
Unless an application performs encryption or integrity protection for
the data stream, the identity verification applies only to the
initiation of the connection, and it does not guarantee that
subsequent messages on the connection originate from the same
principal.
Implementation of the basic protocol consists of one or more
authentication servers running on physically secure hosts. The
authentication servers maintain a database of principals (i.e., users
and servers) and their secret keys. Code libraries provide
encryption and implement the Kerberos protocol. In order to add
authentication to its transactions, a typical network application
adds calls to the Kerberos library directly or through the Generic
Security Services Application Programming Interface (GSS-API)
described in a separate document [RFC4121]. These calls result in
the transmission of the messages necessary to achieve authentication.
Neuman, et al. Standards Track [Page 6]
RFC 4120 Kerberos V5 July 2005
The Kerberos protocol consists of several sub-protocols (or
exchanges). There are two basic methods by which a client can ask a
Kerberos server for credentials. In the first approach, the client
sends a cleartext request for a ticket for the desired server to the
AS. The reply is sent encrypted in the client's secret key. Usually
this request is for a ticket-granting ticket (TGT), which can later
be used with the ticket-granting server (TGS). In the second method,
the client sends a request to the TGS. The client uses the TGT to
authenticate itself to the TGS in the same manner as if it were
contacting any other application server that requires Kerberos
authentication. The reply is encrypted in the session key from the
TGT. Though the protocol specification describes the AS and the TGS
as separate servers, in practice they are implemented as different
protocol entry points within a single Kerberos server.
Once obtained, credentials may be used to verify the identity of the
principals in a transaction, to ensure the integrity of messages
exchanged between them, or to preserve privacy of the messages. The
application is free to choose whatever protection may be necessary.
To verify the identities of the principals in a transaction, the
client transmits the ticket to the application server. Because the
ticket is sent "in the clear" (parts of it are encrypted, but this
encryption doesn't thwart replay) and might be intercepted and reused
by an attacker, additional information is sent to prove that the
message originated with the principal to whom the ticket was issued.
This information (called the authenticator) is encrypted in the
session key and includes a timestamp. The timestamp proves that the
message was recently generated and is not a replay. Encrypting the
authenticator in the session key proves that it was generated by a
party possessing the session key. Since no one except the requesting
principal and the server know the session key (it is never sent over
the network in the clear), this guarantees the identity of the
client.
The integrity of the messages exchanged between principals can also
be guaranteed by using the session key (passed in the ticket and
contained in the credentials). This approach provides detection of
both replay attacks and message stream modification attacks. It is
accomplished by generating and transmitting a collision-proof
checksum (elsewhere called a hash or digest function) of the client's
message, keyed with the session key. Privacy and integrity of the
messages exchanged between principals can be secured by encrypting
the data to be passed by using the session key contained in the
ticket or the sub-session key found in the authenticator.
Neuman, et al. Standards Track [Page 7]
RFC 4120 Kerberos V5 July 2005
The authentication exchanges mentioned above require read-only access
to the Kerberos database. Sometimes, however, the entries in the
database must be modified, such as when adding new principals or
changing a principal's key. This is done using a protocol between a
client and a third Kerberos server, the Kerberos Administration
Server (KADM). There is also a protocol for maintaining multiple
copies of the Kerberos database. Neither of these protocols are
described in this document.
1.2. Cross-Realm Operation
The Kerberos protocol is designed to operate across organizational
boundaries. A client in one organization can be authenticated to a
server in another. Each organization wishing to run a Kerberos
server establishes its own "realm". The name of the realm in which a
client is registered is part of the client's name and can be used by
the end-service to decide whether to honor a request.
By establishing "inter-realm" keys, the administrators of two realms
can allow a client authenticated in the local realm to prove its
identity to servers in other realms. The exchange of inter-realm
keys (a separate key may be used for each direction) registers the
ticket-granting service of each realm as a principal in the other
realm. A client is then able to obtain a TGT for the remote realm's
ticket-granting service from its local realm. When that TGT is used,
the remote ticket-granting service uses the inter-realm key (which
usually differs from its own normal TGS key) to decrypt the TGT; thus
it is certain that the ticket was issued by the client's own TGS.
Tickets issued by the remote ticket-granting service will indicate to
the end-service that the client was authenticated from another realm.
Without cross-realm operation, and with appropriate permission, the
client can arrange registration of a separately-named principal in a
remote realm and engage in normal exchanges with that realm's
services. However, for even small numbers of clients this becomes
cumbersome, and more automatic methods as described here are
necessary.
A realm is said to communicate with another realm if the two realms
share an inter-realm key, or if the local realm shares an inter-realm
key with an intermediate realm that communicates with the remote
realm. An authentication path is the sequence of intermediate realms
that are transited in communicating from one realm to another.
Realms may be organized hierarchically. Each realm shares a key with
its parent and a different key with each child. If an inter-realm
key is not directly shared by two realms, the hierarchical
organization allows an authentication path to be easily constructed.
Neuman, et al. Standards Track [Page 8]
RFC 4120 Kerberos V5 July 2005
If a hierarchical organization is not used, it may be necessary to
consult a database in order to construct an authentication path
between realms.
Although realms are typically hierarchical, intermediate realms may
be bypassed to achieve cross-realm authentication through alternate
authentication paths. (These might be established to make
communication between two realms more efficient.) It is important
for the end-service to know which realms were transited when deciding
how much faith to place in the authentication process. To facilitate
this decision, a field in each ticket contains the names of the
realms that were involved in authenticating the client.
The application server is ultimately responsible for accepting or
rejecting authentication and SHOULD check the transited field. The
application server may choose to rely on the Key Distribution Center
(KDC) for the application server's realm to check the transited
field. The application server's KDC will set the
TRANSITED-POLICY-CHECKED flag in this case. The KDCs for
intermediate realms may also check the transited field as they issue
TGTs for other realms, but they are encouraged not to do so. A
client may request that the KDCs not check the transited field by
setting the DISABLE-TRANSITED-CHECK flag. KDCs SHOULD honor this
flag.
1.3. Choosing a Principal with Which to Communicate
The Kerberos protocol provides the means for verifying (subject to
the assumptions in Section 1.6) that the entity with which one
communicates is the same entity that was registered with the KDC
using the claimed identity (principal name). It is still necessary
to determine whether that identity corresponds to the entity with
which one intends to communicate.
When appropriate data has been exchanged in advance, the application
may perform this determination syntactically based on the application
protocol specification, information provided by the user, and
configuration files. For example, the server principal name
(including realm) for a telnet server might be derived from the
user-specified host name (from the telnet command line), the "host/"
prefix specified in the application protocol specification, and a
mapping to a Kerberos realm derived syntactically from the domain
part of the specified hostname and information from the local
Kerberos realms database.
One can also rely on trusted third parties to make this
determination, but only when the data obtained from the third party
is suitably integrity-protected while resident on the third-party
Neuman, et al. Standards Track [Page 9]
RFC 4120 Kerberos V5 July 2005
server and when transmitted. Thus, for example, one should not rely
on an unprotected DNS record to map a host alias to the primary name
of a server, accepting the primary name as the party that one intends
to contact, since an attacker can modify the mapping and impersonate
the party.
Implementations of Kerberos and protocols based on Kerberos MUST NOT
use insecure DNS queries to canonicalize the hostname components of
the service principal names (i.e., they MUST NOT use insecure DNS
queries to map one name to another to determine the host part of the
principal name with which one is to communicate). In an environment
without secure name service, application authors MAY append a
statically configured domain name to unqualified hostnames before
passing the name to the security mechanisms, but they should do no
more than that. Secure name service facilities, if available, might
be trusted for hostname canonicalization, but such canonicalization
by the client SHOULD NOT be required by KDC implementations.
Implementation note: Many current implementations do some degree of
canonicalization of the provided service name, often using DNS even
though it creates security problems. However, there is no
consistency among implementations as to whether the service name is
case folded to lowercase or whether reverse resolution is used. To
maximize interoperability and security, applications SHOULD provide
security mechanisms with names that result from folding the user-
entered name to lowercase without performing any other modifications
or canonicalization.
1.4. Authorization
As an authentication service, Kerberos provides a means of verifying
the identity of principals on a network. Authentication is usually
useful primarily as a first step in the process of authorization,
determining whether a client may use a service, which objects the
client is allowed to access, and the type of access allowed for each.
Kerberos does not, by itself, provide authorization. Possession of a
client ticket for a service provides only for authentication of the
client to that service, and in the absence of a separate
authorization procedure, an application should not consider it to
authorize the use of that service.
Separate authorization methods MAY be implemented as application-
specific access control functions and may utilize files on the
application server, on separately issued authorization credentials
such as those based on proxies [Neu93], or on other authorization
services. Separately authenticated authorization credentials MAY be
embedded in a ticket's authorization data when encapsulated by the
KDC-issued authorization data element.
Neuman, et al. Standards Track [Page 10]
RFC 4120 Kerberos V5 July 2005
Applications should not accept the mere issuance of a service ticket
by the Kerberos server (even by a modified Kerberos server) as
granting authority to use the service, since such applications may
become vulnerable to the bypass of this authorization check in an
environment where other options for application authentication are
provided, or if they interoperate with other KDCs.
1.5. Extending Kerberos without Breaking Interoperability
As the deployed base of Kerberos implementations grows, extending
Kerberos becomes more important. Unfortunately, some extensions to
the existing Kerberos protocol create interoperability issues because
of uncertainty regarding the treatment of certain extensibility
options by some implementations. This section includes guidelines
that will enable future implementations to maintain interoperability.
Kerberos provides a general mechanism for protocol extensibility.
Some protocol messages contain typed holes -- sub-messages that
contain an octet-string along with an integer that defines how to
interpret the octet-string. The integer types are registered
centrally, but they can be used both for vendor extensions and for
extensions standardized through the IETF.
In this document, the word "extension" refers to extension by
defining a new type to insert into an existing typed hole in a
protocol message. It does not refer to extension by addition of new
fields to ASN.1 types, unless the text explicitly indicates
otherwise.
1.5.1. Compatibility with RFC 1510
Note that existing Kerberos message formats cannot readily be
extended by adding fields to the ASN.1 types. Sending additional
fields often results in the entire message being discarded without an
error indication. Future versions of this specification will provide
guidelines to ensure that ASN.1 fields can be added without creating
an interoperability problem.
In the meantime, all new or modified implementations of Kerberos that
receive an unknown message extension SHOULD preserve the encoding of
the extension but otherwise ignore its presence. Recipients MUST NOT
decline a request simply because an extension is present.
There is one exception to this rule. If an unknown authorization
data element type is received by a server other than the ticket-
granting service either in an AP-REQ or in a ticket contained in an
AP-REQ, then authentication MUST fail. One of the primary uses of
authorization data is to restrict the use of the ticket. If the
Neuman, et al. Standards Track [Page 11]
RFC 4120 Kerberos V5 July 2005
service cannot determine whether the restriction applies to that
service, then a security weakness may result if the ticket can be
used for that service. Authorization elements that are optional
SHOULD be enclosed in the AD-IF-RELEVANT element.
The ticket-granting service MUST ignore but propagate to derivative
tickets any unknown authorization data types, unless those data types
are embedded in a MANDATORY-FOR-KDC element, in which case the
request will be rejected. This behavior is appropriate because
requiring that the ticket-granting service understand unknown
authorization data types would require that KDC software be upgraded
to understand new application-level restrictions before applications
used these restrictions, decreasing the utility of authorization data
as a mechanism for restricting the use of tickets. No security
problem is created because services to which the tickets are issued
will verify the authorization data.
Implementation note: Many RFC 1510 implementations ignore unknown
authorization data elements. Depending on these implementations to
honor authorization data restrictions may create a security weakness.
1.5.2. Sending Extensible Messages
Care must be taken to ensure that old implementations can understand
messages sent to them, even if they do not understand an extension
that is used. Unless the sender knows that an extension is
supported, the extension cannot change the semantics of the core
message or previously defined extensions.
For example, an extension including key information necessary to
decrypt the encrypted part of a KDC-REP could only be used in
situations where the recipient was known to support the extension.
Thus when designing such extensions it is important to provide a way
for the recipient to notify the sender of support for the extension.
For example in the case of an extension that changes the KDC-REP
reply key, the client could indicate support for the extension by
including a padata element in the AS-REQ sequence. The KDC should
only use the extension if this padata element is present in the
AS-REQ. Even if policy requires the use of the extension, it is
better to return an error indicating that the extension is required
than to use the extension when the recipient may not support it.
Debugging implementations that do not interoperate is easier when
errors are returned.
1.6. Environmental Assumptions
Kerberos imposes a few assumptions on the environment in which it can
properly function, including the following:
Neuman, et al. Standards Track [Page 12]
RFC 4120 Kerberos V5 July 2005
* "Denial of service" attacks are not solved with Kerberos. There
are places in the protocols where an intruder can prevent an
application from participating in the proper authentication steps.
Detection and solution of such attacks (some of which can appear
to be not-uncommon "normal" failure modes for the system) are
usually best left to the human administrators and users.
* Principals MUST keep their secret keys secret. If an intruder
somehow steals a principal's key, it will be able to masquerade as
that principal or to impersonate any server to the legitimate
principal.
* "Password guessing" attacks are not solved by Kerberos. If a user
chooses a poor password, it is possible for an attacker to
successfully mount an offline dictionary attack by repeatedly
attempting to decrypt, with successive entries from a dictionary,
messages obtained which are encrypted under a key derived from the
user's password.
* Each host on the network MUST have a clock which is "loosely
synchronized" to the time of the other hosts; this synchronization
is used to reduce the bookkeeping needs of application servers
when they do replay detection. The degree of "looseness" can be
configured on a per-server basis, but it is typically on the order
of 5 minutes. If the clocks are synchronized over the network,
the clock synchronization protocol MUST itself be secured from
network attackers.
* Principal identifiers are not recycled on a short-term basis. A
typical mode of access control will use access control lists
(ACLs) to grant permissions to particular principals. If a stale
ACL entry remains for a deleted principal and the principal
identifier is reused, the new principal will inherit rights
specified in the stale ACL entry. By not re-using principal
identifiers, the danger of inadvertent access is removed.
1.7. Glossary of Terms
Below is a list of terms used throughout this document.
Authentication
Verifying the claimed identity of a principal.
Authentication header
A record containing a Ticket and an Authenticator to be presented
to a server as part of the authentication process.
Neuman, et al. Standards Track [Page 13]
RFC 4120 Kerberos V5 July 2005
Authentication path
A sequence of intermediate realms transited in the authentication
process when communicating from one realm to another.
Authenticator
A record containing information that can be shown to have been
recently generated using the session key known only by the client
and server.
Authorization
The process of determining whether a client may use a service,
which objects the client is allowed to access, and the type of
access allowed for each.
Capability
A token that grants the bearer permission to access an object or
service. In Kerberos, this might be a ticket whose use is
restricted by the contents of the authorization data field, but
which lists no network addresses, together with the session key
necessary to use the ticket.
Ciphertext
The output of an encryption function. Encryption transforms
plaintext into ciphertext.
Client
A process that makes use of a network service on behalf of a user.
Note that in some cases a Server may itself be a client of some
other server (e.g., a print server may be a client of a file
server).
Credentials
A ticket plus the secret session key necessary to use that ticket
successfully in an authentication exchange.
Encryption Type (etype)
When associated with encrypted data, an encryption type identifies
the algorithm used to encrypt the data and is used to select the
appropriate algorithm for decrypting the data. Encryption type
tags are communicated in other messages to enumerate algorithms
that are desired, supported, preferred, or allowed to be used for
encryption of data between parties. This preference is combined
with local information and policy to select an algorithm to be
used.
KDC
Key Distribution Center. A network service that supplies tickets
and temporary session keys; or an instance of that service or the
Neuman, et al. Standards Track [Page 14]
RFC 4120 Kerberos V5 July 2005
host on which it runs. The KDC services both initial ticket and
ticket-granting ticket requests. The initial ticket portion is
sometimes referred to as the Authentication Server (or service).
The ticket-granting ticket portion is sometimes referred to as the
ticket-granting server (or service).
Kerberos
The name given to the Project Athena's authentication service, the
protocol used by that service, or the code used to implement the
authentication service. The name is adopted from the three-headed
dog that guards Hades.
Key Version Number (kvno)
A tag associated with encrypted data identifies which key was used
for encryption when a long-lived key associated with a principal
changes over time. It is used during the transition to a new key
so that the party decrypting a message can tell whether the data
was encrypted with the old or the new key.
Plaintext
The input to an encryption function or the output of a decryption
function. Decryption transforms ciphertext into plaintext.
Principal
A named client or server entity that participates in a network
communication, with one name that is considered canonical.
Principal identifier
The canonical name used to identify each different principal
uniquely.
Seal
To encipher a record containing several fields in such a way that
the fields cannot be individually replaced without knowledge of
the encryption key or leaving evidence of tampering.
Secret key
An encryption key shared by a principal and the KDC, distributed
outside the bounds of the system, with a long lifetime. In the
case of a human user's principal, the secret key MAY be derived
from a password.
Server
A particular Principal that provides a resource to network
clients. The server is sometimes referred to as the Application
Server.
Neuman, et al. Standards Track [Page 15]
RFC 4120 Kerberos V5 July 2005
Service
A resource provided to network clients; often provided by more
than one server (for example, remote file service).
Session key
A temporary encryption key used between two principals, with a
lifetime limited to the duration of a single login "session". In
the Kerberos system, a session key is generated by the KDC. The
session key is distinct from the sub-session key, described next.
Sub-session key
A temporary encryption key used between two principals, selected
and exchanged by the principals using the session key, and with a
lifetime limited to the duration of a single association. The
sub-session key is also referred to as the subkey.
Ticket
A record that helps a client authenticate itself to a server; it
contains the client's identity, a session key, a timestamp, and
other information, all sealed using the server's secret key. It
only serves to authenticate a client when presented along with a
fresh Authenticator.
2. Ticket Flag Uses and Requests
Each Kerberos ticket contains a set of flags that are used to
indicate attributes of that ticket. Most flags may be requested by a
client when the ticket is obtained; some are automatically turned on
and off by a Kerberos server as required. The following sections
explain what the various flags mean and give examples of reasons to
use them. With the exception of the INVALID flag, clients MUST
ignore ticket flags that are not recognized. KDCs MUST ignore KDC
options that are not recognized. Some implementations of RFC 1510
are known to reject unknown KDC options, so clients may need to
resend a request without new KDC options if the request was rejected
when sent with options added since RFC 1510. Because new KDCs will
ignore unknown options, clients MUST confirm that the ticket returned
by the KDC meets their needs.
Note that it is not, in general, possible to determine whether an
option was not honored because it was not understood or because it
was rejected through either configuration or policy. When adding a
new option to the Kerberos protocol, designers should consider
whether the distinction is important for their option. If it is, a
mechanism for the KDC to return an indication that the option was
understood but rejected needs to be provided in the specification of
the option. Often in such cases, the mechanism needs to be broad
enough to permit an error or reason to be returned.
Neuman, et al. Standards Track [Page 16]
RFC 4120 Kerberos V5 July 2005
2.1. Initial, Pre-authenticated, and Hardware-Authenticated Tickets
The INITIAL flag indicates that a ticket was issued using the AS
protocol, rather than issued based on a TGT. Application servers
that want to require the demonstrated knowledge of a client's secret
key (e.g., a password-changing program) can insist that this flag be
set in any tickets they accept, and can thus be assured that the
client's key was recently presented to the authentication server.
The PRE-AUTHENT and HW-AUTHENT flags provide additional information
about the initial authentication, regardless of whether the current
ticket was issued directly (in which case INITIAL will also be set)
or issued on the basis of a TGT (in which case the INITIAL flag is
clear, but the PRE-AUTHENT and HW-AUTHENT flags are carried forward
from the TGT).
2.2. Invalid Tickets
The INVALID flag indicates that a ticket is invalid. Application
servers MUST reject tickets that have this flag set. A postdated
ticket will be issued in this form. Invalid tickets MUST be
validated by the KDC before use, by being presented to the KDC in a
TGS request with the VALIDATE option specified. The KDC will only
validate tickets after their starttime has passed. The validation is
required so that postdated tickets that have been stolen before their
starttime can be rendered permanently invalid (through a hot-list
mechanism) (see Section 3.3.3.1).
2.3. Renewable Tickets
Applications may desire to hold tickets that can be valid for long
periods of time. However, this can expose their credentials to
potential theft for equally long periods, and those stolen
credentials would be valid until the expiration time of the
ticket(s). Simply using short-lived tickets and obtaining new ones
periodically would require the client to have long-term access to its
secret key, an even greater risk. Renewable tickets can be used to
mitigate the consequences of theft. Renewable tickets have two
"expiration times": the first is when the current instance of the
ticket expires, and the second is the latest permissible value for an
individual expiration time. An application client must periodically
(i.e., before it expires) present a renewable ticket to the KDC, with
the RENEW option set in the KDC request. The KDC will issue a new
ticket with a new session key and a later expiration time. All other
fields of the ticket are left unmodified by the renewal process.
When the latest permissible expiration time arrives, the ticket
expires permanently. At each renewal, the KDC MAY consult a hot-list
to determine whether the ticket had been reported stolen since its
Neuman, et al. Standards Track [Page 17]
RFC 4120 Kerberos V5 July 2005
last renewal; it will refuse to renew stolen tickets, and thus the
usable lifetime of stolen tickets is reduced.
The RENEWABLE flag in a ticket is normally only interpreted by the
ticket-granting service (discussed below in Section 3.3). It can
usually be ignored by application servers. However, some
particularly careful application servers MAY disallow renewable
tickets.
If a renewable ticket is not renewed by its expiration time, the KDC
will not renew the ticket. The RENEWABLE flag is reset by default,
but a client MAY request it be set by setting the RENEWABLE option in
the KRB_AS_REQ message. If it is set, then the renew-till field in
the ticket contains the time after which the ticket may not be
renewed.
2.4. Postdated Tickets
Applications may occasionally need to obtain tickets for use much
later; e.g., a batch submission system would need tickets to be valid
at the time the batch job is serviced. However, it is dangerous to
hold valid tickets in a batch queue, since they will be on-line
longer and more prone to theft. Postdated tickets provide a way to
obtain these tickets from the KDC at job submission time, but to
leave them "dormant" until they are activated and validated by a
further request of the KDC. If a ticket theft were reported in the
interim, the KDC would refuse to validate the ticket, and the thief
would be foiled.
The MAY-POSTDATE flag in a ticket is normally only interpreted by the
ticket-granting service. It can be ignored by application servers.
This flag MUST be set in a TGT in order to issue a postdated ticket
based on the presented ticket. It is reset by default; a client MAY
request it by setting the ALLOW-POSTDATE option in the KRB_AS_REQ
message. This flag does not allow a client to obtain a postdated
TGT; postdated TGTs can only be obtained by requesting the postdating
in the KRB_AS_REQ message. The life (endtime-starttime) of a
postdated ticket will be the remaining life of the TGT at the time of
the request, unless the RENEWABLE option is also set, in which case
it can be the full life (endtime-starttime) of the TGT. The KDC MAY
limit how far in the future a ticket may be postdated.
The POSTDATED flag indicates that a ticket has been postdated. The
application server can check the authtime field in the ticket to see
when the original authentication occurred. Some services MAY choose
to reject postdated tickets, or they may only accept them within a
certain period after the original authentication. When the KDC
issues a POSTDATED ticket, it will also be marked as INVALID, so that
Neuman, et al. Standards Track [Page 18]
RFC 4120 Kerberos V5 July 2005
the application client MUST present the ticket to the KDC to be
validated before use.
2.5. Proxiable and Proxy Tickets
At times it may be necessary for a principal to allow a service to
perform an operation on its behalf. The service must be able to take
on the identity of the client, but only for a particular purpose. A
principal can allow a service to do this by granting it a proxy.
The process of granting a proxy by using the proxy and proxiable
flags is used to provide credentials for use with specific services.
Though conceptually also a proxy, users wishing to delegate their
identity in a form usable for all purposes MUST use the ticket
forwarding mechanism described in the next section to forward a TGT.
The PROXIABLE flag in a ticket is normally only interpreted by the
ticket-granting service. It can be ignored by application servers.
When set, this flag tells the ticket-granting server that it is OK to
issue a new ticket (but not a TGT) with a different network address
based on this ticket. This flag is set if requested by the client on
initial authentication. By default, the client will request that it
be set when requesting a TGT, and that it be reset when requesting
any other ticket.
This flag allows a client to pass a proxy to a server to perform a
remote request on its behalf (e.g., a print service client can give
the print server a proxy to access the client's files on a particular
file server in order to satisfy a print request).
In order to complicate the use of stolen credentials, Kerberos
tickets are often valid only from those network addresses
specifically included in the ticket, but it is permissible as a
policy option to allow requests and to issue tickets with no network
addresses specified. When granting a proxy, the client MUST specify
the new network address from which the proxy is to be used or
indicate that the proxy is to be issued for use from any address.
The PROXY flag is set in a ticket by the TGS when it issues a proxy
ticket. Application servers MAY check this flag; and at their option
they MAY require additional authentication from the agent presenting
the proxy in order to provide an audit trail.
2.6. Forwardable Tickets
Authentication forwarding is an instance of a proxy where the service
that is granted is complete use of the client's identity. An example
of where it might be used is when a user logs in to a remote system
Neuman, et al. Standards Track [Page 19]
RFC 4120 Kerberos V5 July 2005
and wants authentication to work from that system as if the login
were local.
The FORWARDABLE flag in a ticket is normally only interpreted by the
ticket-granting service. It can be ignored by application servers.
The FORWARDABLE flag has an interpretation similar to that of the
PROXIABLE flag, except TGTs may also be issued with different network
addresses. This flag is reset by default, but users MAY request that
it be set by setting the FORWARDABLE option in the AS request when
they request their initial TGT.
This flag allows for authentication forwarding without requiring the
user to enter a password again. If the flag is not set, then
authentication forwarding is not permitted, but the same result can
still be achieved if the user engages in the AS exchange, specifies
the requested network addresses, and supplies a password.
The FORWARDED flag is set by the TGS when a client presents a ticket
with the FORWARDABLE flag set and requests a forwarded ticket by
specifying the FORWARDED KDC option and supplying a set of addresses
for the new ticket. It is also set in all tickets issued based on
tickets with the FORWARDED flag set. Application servers may choose
to process FORWARDED tickets differently than non-FORWARDED tickets.
If addressless tickets are forwarded from one system to another,
clients SHOULD still use this option to obtain a new TGT in order to
have different session keys on the different systems.
2.7. Transited Policy Checking
In Kerberos, the application server is ultimately responsible for
accepting or rejecting authentication, and it SHOULD check that only
suitably trusted KDCs are relied upon to authenticate a principal.
The transited field in the ticket identifies which realms (and thus
which KDCs) were involved in the authentication process, and an
application server would normally check this field. If any of these
are untrusted to authenticate the indicated client principal
(probably determined by a realm-based policy), the authentication
attempt MUST be rejected. The presence of trusted KDCs in this list
does not provide any guarantee; an untrusted KDC may have fabricated
the list.
Although the end server ultimately decides whether authentication is
valid, the KDC for the end server's realm MAY apply a realm-specific
policy for validating the transited field and accepting credentials
for cross-realm authentication. When the KDC applies such checks and
accepts such cross-realm authentication, it will set the
TRANSITED-POLICY-CHECKED flag in the service tickets it issues based
Neuman, et al. Standards Track [Page 20]
RFC 4120 Kerberos V5 July 2005
on the cross-realm TGT. A client MAY request that the KDCs not check
the transited field by setting the DISABLE-TRANSITED-CHECK flag.
KDCs are encouraged but not required to honor this flag.
Application servers MUST either do the transited-realm checks
themselves or reject cross-realm tickets without
TRANSITED-POLICY-CHECKED set.
2.8. OK as Delegate
For some applications, a client may need to delegate authority to a
server to act on its behalf in contacting other services. This
requires that the client forward credentials to an intermediate
server. The ability for a client to obtain a service ticket to a
server conveys no information to the client about whether the server
should be trusted to accept delegated credentials. The
OK-AS-DELEGATE provides a way for a KDC to communicate local realm
policy to a client regarding whether an intermediate server is
trusted to accept such credentials.
The copy of the ticket flags in the encrypted part of the KDC reply
may have the OK-AS-DELEGATE flag set to indicate to the client that
the server specified in the ticket has been determined by the policy
of the realm to be a suitable recipient of delegation. A client can
use the presence of this flag to help it decide whether to delegate
credentials (grant either a proxy or a forwarded TGT) to this server.
It is acceptable to ignore the value of this flag. When setting this
flag, an administrator should consider the security and placement of
the server on which the service will run, as well as whether the
service requires the use of delegated credentials.
2.9. Other KDC Options
There are three additional options that MAY be set in a client's
request of the KDC.
2.9.1. Renewable-OK
The RENEWABLE-OK option indicates that the client will accept a
renewable ticket if a ticket with the requested life cannot otherwise
be provided. If a ticket with the requested life cannot be provided,
then the KDC MAY issue a renewable ticket with a renew-till equal to
the requested endtime. The value of the renew-till field MAY still
be adjusted by site-determined limits or limits imposed by the
individual principal or server.
Neuman, et al. Standards Track [Page 21]
RFC 4120 Kerberos V5 July 2005
2.9.2. ENC-TKT-IN-SKEY
In its basic form, the Kerberos protocol supports authentication in a
client-server setting and is not well suited to authentication in a
peer-to-peer environment because the long-term key of the user does
not remain on the workstation after initial login. Authentication of
such peers may be supported by Kerberos in its user-to-user variant.
The ENC-TKT-IN-SKEY option supports user-to-user authentication by
allowing the KDC to issue a service ticket encrypted using the
session key from another TGT issued to another user. The
ENC-TKT-IN-SKEY option is honored only by the ticket-granting
service. It indicates that the ticket to be issued for the end
server is to be encrypted in the session key from the additional
second TGT provided with the request. See Section 3.3.3 for specific
details.
2.9.3. Passwordless Hardware Authentication
The OPT-HARDWARE-AUTH option indicates that the client wishes to use
some form of hardware authentication instead of or in addition to the
client's password or other long-lived encryption key.
OPT-HARDWARE-AUTH is honored only by the authentication service. If
supported and allowed by policy, the KDC will return an error code of
KDC_ERR_PREAUTH_REQUIRED and include the required METHOD-DATA to
perform such authentication.
3. Message Exchanges
The following sections describe the interactions between network
clients and servers and the messages involved in those exchanges.
3.1. The Authentication Service Exchange
Summary
Message direction Message type Section
1. Client to Kerberos KRB_AS_REQ 5.4.1
2. Kerberos to client KRB_AS_REP or 5.4.2
KRB_ERROR 5.9.1
The Authentication Service (AS) Exchange between the client and the
Kerberos Authentication Server is initiated by a client when it
wishes to obtain authentication credentials for a given server but
currently holds no credentials. In its basic form, the client's
secret key is used for encryption and decryption. This exchange is
typically used at the initiation of a login session to obtain
credentials for a Ticket-Granting Server, which will subsequently be
used to obtain credentials for other servers (see Section 3.3)
Neuman, et al. Standards Track [Page 22]
RFC 4120 Kerberos V5 July 2005
without requiring further use of the client's secret key. This
exchange is also used to request credentials for services that must
not be mediated through the Ticket-Granting Service, but rather
require knowledge of a principal's secret key, such as the password-
changing service (the password-changing service denies requests
unless the requester can demonstrate knowledge of the user's old
password; requiring this knowledge prevents unauthorized password
changes by someone walking up to an unattended session).
This exchange does not by itself provide any assurance of the
identity of the user. To authenticate a user logging on to a local
system, the credentials obtained in the AS exchange may first be used
in a TGS exchange to obtain credentials for a local server; those
credentials must then be verified by a local server through
successful completion of the Client/Server exchange.
The AS exchange consists of two messages: KRB_AS_REQ from the client
to Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for
these messages are described in Sections 5.4.1, 5.4.2, and 5.9.1.
In the request, the client sends (in cleartext) its own identity and
the identity of the server for which it is requesting credentials,
other information about the credentials it is requesting, and a
randomly generated nonce, which can be used to detect replays and to
associate replies with the matching requests. This nonce MUST be
generated randomly by the client and remembered for checking against
the nonce in the expected reply. The response, KRB_AS_REP, contains
a ticket for the client to present to the server, and a session key
that will be shared by the client and the server. The session key
and additional information are encrypted in the client's secret key.
The encrypted part of the KRB_AS_REP message also contains the nonce
that MUST be matched with the nonce from the KRB_AS_REQ message.
Without pre-authentication, the authentication server does not know
whether the client is actually the principal named in the request.
It simply sends a reply without knowing or caring whether they are
the same. This is acceptable because nobody but the principal whose
identity was given in the request will be able to use the reply. Its
critical information is encrypted in that principal's key. However,
an attacker can send a KRB_AS_REQ message to get known plaintext in
order to attack the principal's key. Especially if the key is based
on a password, this may create a security exposure. So the initial
request supports an optional field that can be used to pass
additional information that might be needed for the initial exchange.
This field SHOULD be used for pre-authentication as described in
sections 3.1.1 and 5.2.7.
Neuman, et al. Standards Track [Page 23]
RFC 4120 Kerberos V5 July 2005
Various errors can occur; these are indicated by an error response
(KRB_ERROR) instead of the KRB_AS_REP response. The error message is
not encrypted. The KRB_ERROR message contains information that can
be used to associate it with the message to which it replies. The
contents of the KRB_ERROR message are not integrity-protected. As
such, the client cannot detect replays, fabrications, or
modifications. A solution to this problem will be included in a
future version of the protocol.
3.1.1. Generation of KRB_AS_REQ Message
The client may specify a number of options in the initial request.
Among these options are whether pre-authentication is to be
performed; whether the requested ticket is to be renewable,
proxiable, or forwardable; whether it should be postdated or allow
postdating of derivative tickets; and whether a renewable ticket will
be accepted in lieu of a non-renewable ticket if the requested ticket
expiration date cannot be satisfied by a non-renewable ticket (due to
configuration constraints).
The client prepares the KRB_AS_REQ message and sends it to the KDC.
3.1.2. Receipt of KRB_AS_REQ Message
If all goes well, processing the KRB_AS_REQ message will result in
the creation of a ticket for the client to present to the server.
The format for the ticket is described in Section 5.3.
Because Kerberos can run over unreliable transports such as UDP, the
KDC MUST be prepared to retransmit responses in case they are lost.
If a KDC receives a request identical to one it has recently
processed successfully, the KDC MUST respond with a KRB_AS_REP
message rather than a replay error. In order to reduce ciphertext
given to a potential attacker, KDCs MAY send the same response
generated when the request was first handled. KDCs MUST obey this
replay behavior even if the actual transport in use is reliable.
3.1.3. Generation of KRB_AS_REP Message
The authentication server looks up the client and server principals
named in the KRB_AS_REQ in its database, extracting their respective
keys. If the requested client principal named in the request is
unknown because it doesn't exist in the KDC's principal database,
then an error message with a KDC_ERR_C_PRINCIPAL_UNKNOWN is returned.
If required to do so, the server pre-authenticates the request, and
if the pre-authentication check fails, an error message with the code
KDC_ERR_PREAUTH_FAILED is returned. If pre-authentication is
Neuman, et al. Standards Track [Page 24]
RFC 4120 Kerberos V5 July 2005
required, but was not present in the request, an error message with
the code KDC_ERR_PREAUTH_REQUIRED is returned, and a METHOD-DATA
object will be stored in the e-data field of the KRB-ERROR message to
specify which pre-authentication mechanisms are acceptable. Usually
this will include PA-ETYPE-INFO and/or PA-ETYPE-INFO2 elements as
described below. If the server cannot accommodate any encryption
type requested by the client, an error message with code
KDC_ERR_ETYPE_NOSUPP is returned. Otherwise, the KDC generates a
'random' session key, meaning that, among other things, it should be
impossible to guess the next session key based on knowledge of past
session keys. Although this can be achieved in a pseudo-random
number generator if it is based on cryptographic principles, it is
more desirable to use a truly random number generator, such as one
based on measurements of random physical phenomena. See [RFC4086]
for an in-depth discussion of randomness.
In response to an AS request, if there are multiple encryption keys
registered for a client in the Kerberos database, then the etype
field from the AS request is used by the KDC to select the encryption
method to be used to protect the encrypted part of the KRB_AS_REP
message that is sent to the client. If there is more than one
supported strong encryption type in the etype list, the KDC SHOULD
use the first valid strong etype for which an encryption key is
available.
When the user's key is generated from a password or pass phrase, the
string-to-key function for the particular encryption key type is
used, as specified in [RFC3961]. The salt value and additional
parameters for the string-to-key function have default values
(specified by Section 4 and by the encryption mechanism
specification, respectively) that may be overridden by
pre-authentication data (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO,
PA-ETYPE-INFO2, etc). Since the KDC is presumed to store a copy of
the resulting key only, these values should not be changed for
password-based keys except when changing the principal's key.
When the AS server is to include pre-authentication data in a
KRB-ERROR or in an AS-REP, it MUST use PA-ETYPE-INFO2, not PA-ETYPE-
INFO, if the etype field of the client's AS-REQ lists at least one
"newer" encryption type. Otherwise (when the etype field of the
client's AS-REQ does not list any "newer" encryption types), it MUST
send both PA-ETYPE-INFO2 and PA-ETYPE-INFO (both with an entry for
each enctype). A "newer" enctype is any enctype first officially
specified concurrently with or subsequent to the issue of this RFC.
The enctypes DES, 3DES, or RC4 and any defined in [RFC1510] are not
"newer" enctypes.
Neuman, et al. Standards Track [Page 25]
RFC 4120 Kerberos V5 July 2005
It is not possible to generate a user's key reliably given a pass
phrase without contacting the KDC, since it will not be known whether
alternate salt or parameter values are required.
The KDC will attempt to assign the type of the random session key
from the list of methods in the etype field. The KDC will select the
appropriate type using the list of methods provided and information
from the Kerberos database indicating acceptable encryption methods
for the application server. The KDC will not issue tickets with a
weak session key encryption type.
If the requested starttime is absent, indicates a time in the past,
or is within the window of acceptable clock skew for the KDC and the
POSTDATE option has not been specified, then the starttime of the
ticket is set to the authentication server's current time. If it
indicates a time in the future beyond the acceptable clock skew, but
the POSTDATED option has not been specified, then the error
KDC_ERR_CANNOT_POSTDATE is returned. Otherwise the requested
starttime is checked against the policy of the local realm (the
administrator might decide to prohibit certain types or ranges of
postdated tickets), and if the ticket's starttime is acceptable, it
is set as requested, and the INVALID flag is set in the new ticket.
The postdated ticket MUST be validated before use by presenting it to
the KDC after the starttime has been reached.
The expiration time of the ticket will be set to the earlier of the
requested endtime and a time determined by local policy, possibly by
using realm- or principal-specific factors. For example, the
expiration time MAY be set to the earliest of the following:
* The expiration time (endtime) requested in the KRB_AS_REQ
message.
* The ticket's starttime plus the maximum allowable lifetime
associated with the client principal from the authentication
server's database.
* The ticket's starttime plus the maximum allowable lifetime
associated with the server principal.
* The ticket's starttime plus the maximum lifetime set by the
policy of the local realm.
If the requested expiration time minus the starttime (as determined
above) is less than a site-determined minimum lifetime, an error
message with code KDC_ERR_NEVER_VALID is returned. If the requested
expiration time for the ticket exceeds what was determined as above,
and if the 'RENEWABLE-OK' option was requested, then the 'RENEWABLE'
Neuman, et al. Standards Track [Page 26]
RFC 4120 Kerberos V5 July 2005
flag is set in the new ticket, and the renew-till value is set as if
the 'RENEWABLE' option were requested (the field and option names are
described fully in Section 5.4.1).
If the RENEWABLE option has been requested or if the RENEWABLE-OK
option has been set and a renewable ticket is to be issued, then the
renew-till field MAY be set to the earliest of:
* Its requested value.
* The starttime of the ticket plus the minimum of the two maximum
renewable lifetimes associated with the principals' database
entries.
* The starttime of the ticket plus the maximum renewable lifetime
set by the policy of the local realm.
The flags field of the new ticket will have the following options set
if they have been requested and if the policy of the local realm
allows: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE.
If the new ticket is postdated (the starttime is in the future), its
INVALID flag will also be set.
If all of the above succeed, the server will encrypt the ciphertext
part of the ticket using the encryption key extracted from the server
principal's record in the Kerberos database using the encryption type
associated with the server principal's key. (This choice is NOT
affected by the etype field in the request.) It then formats a
KRB_AS_REP message (see Section 5.4.2), copying the addresses in the
request into the caddr of the response, placing any required pre-
authentication data into the padata of the response, and encrypts the
ciphertext part in the client's key using an acceptable encryption
method requested in the etype field of the request, or in some key
specified by pre-authentication mechanisms being used.
3.1.4. Generation of KRB_ERROR Message
Several errors can occur, and the Authentication Server responds by
returning an error message, KRB_ERROR, to the client, with the
error-code and e-text fields set to appropriate values. The error
message contents and details are described in Section 5.9.1.
3.1.5. Receipt of KRB_AS_REP Message
If the reply message type is KRB_AS_REP, then the client verifies
that the cname and crealm fields in the cleartext portion of the
reply match what it requested. If any padata fields are present,
they may be used to derive the proper secret key to decrypt the
Neuman, et al. Standards Track [Page 27]
RFC 4120 Kerberos V5 July 2005
message. The client decrypts the encrypted part of the response
using its secret key and verifies that the nonce in the encrypted
part matches the nonce it supplied in its request (to detect
replays). It also verifies that the sname and srealm in the response
match those in the request (or are otherwise expected values), and
that the host address field is also correct. It then stores the
ticket, session key, start and expiration times, and other
information for later use. The last-req field (and the deprecated
key-expiration field) from the encrypted part of the response MAY be
checked to notify the user of impending key expiration. This enables
the client program to suggest remedial action, such as a password
change.
Upon validation of the KRB_AS_REP message (by checking the returned
nonce against that sent in the KRB_AS_REQ message), the client knows
that the current time on the KDC is that read from the authtime field
of the encrypted part of the reply. The client can optionally use
this value for clock synchronization in subsequent messages by
recording with the ticket the difference (offset) between the
authtime value and the local clock. This offset can then be used by
the same user to adjust the time read from the system clock when
generating messages [DGT96].
This technique MUST be used when adjusting for clock skew instead of
directly changing the system clock, because the KDC reply is only
authenticated to the user whose secret key was used, but not to the
system or workstation. If the clock were adjusted, an attacker
colluding with a user logging into a workstation could agree on a
password, resulting in a KDC reply that would be correctly validated
even though it did not originate from a KDC trusted by the
workstation.
Proper decryption of the KRB_AS_REP message is not sufficient for the
host to verify the identity of the user; the user and an attacker
could cooperate to generate a KRB_AS_REP format message that decrypts
properly but is not from the proper KDC. If the host wishes to
verify the identity of the user, it MUST require the user to present
application credentials that can be verified using a securely-stored
secret key for the host. If those credentials can be verified, then
the identity of the user can be assured.
3.1.6. Receipt of KRB_ERROR Message
If the reply message type is KRB_ERROR, then the client interprets it
as an error and performs whatever application-specific tasks are
necessary for recovery.
Neuman, et al. Standards Track [Page 28]
RFC 4120 Kerberos V5 July 2005
3.2. The Client/Server Authentication Exchange
Summary
Message direction Message type Section
Client to Application server KRB_AP_REQ 5.5.1
[optional] Application server to client KRB_AP_REP or 5.5.2
KRB_ERROR 5.9.1
The client/server authentication (CS) exchange is used by network
applications to authenticate the client to the server and vice versa.
The client MUST have already acquired credentials for the server
using the AS or TGS exchange.
3.2.1. The KRB_AP_REQ Message
The KRB_AP_REQ contains authentication information that SHOULD be
part of the first message in an authenticated transaction. It
contains a ticket, an authenticator, and some additional bookkeeping
information (see Section 5.5.1 for the exact format). The ticket by
itself is insufficient to authenticate a client, since tickets are
passed across the network in cleartext (tickets contain both an
encrypted and unencrypted portion, so cleartext here refers to the
entire unit, which can be copied from one message and replayed in
another without any cryptographic skill). The authenticator is used
to prevent invalid replay of tickets by proving to the server that
the client knows the session key of the ticket and thus is entitled
to use the ticket. The KRB_AP_REQ message is referred to elsewhere
as the 'authentication header'.
3.2.2. Generation of a KRB_AP_REQ Message
When a client wishes to initiate authentication to a server, it
obtains (either through a credentials cache, the AS exchange, or the
TGS exchange) a ticket and session key for the desired service. The
client MAY re-use any tickets it holds until they expire. To use a
ticket, the client constructs a new Authenticator from the system
time and its name, and optionally from an application-specific
checksum, an initial sequence number to be used in KRB_SAFE or
KRB_PRIV messages, and/or a session subkey to be used in negotiations
for a session key unique to this particular session. Authenticators
MUST NOT be re-used and SHOULD be rejected if replayed to a server.
Note that this can make applications based on unreliable transports
difficult to code correctly. If the transport might deliver
duplicated messages, either a new authenticator MUST be generated for
each retry, or the application server MUST match requests and replies
and replay the first reply in response to a detected duplicate.
Neuman, et al. Standards Track [Page 29]
RFC 4120 Kerberos V5 July 2005
If a sequence number is to be included, it SHOULD be randomly chosen
so that even after many messages have been exchanged it is not likely
to collide with other sequence numbers in use.
The client MAY indicate a requirement of mutual authentication or the
use of a session-key based ticket (for user-to-user authentication,
see section 3.7) by setting the appropriate flag(s) in the ap-options
field of the message.
The Authenticator is encrypted in the session key and combined with
the ticket to form the KRB_AP_REQ message, which is then sent to the
end server along with any additional application-specific
information.
3.2.3. Receipt of KRB_AP_REQ Message
Authentication is based on the server's current time of day (clocks
MUST be loosely synchronized), the authenticator, and the ticket.
Several errors are possible. If an error occurs, the server is
expected to reply to the client with a KRB_ERROR message. This
message MAY be encapsulated in the application protocol if its raw
form is not acceptable to the protocol. The format of error messages
is described in Section 5.9.1.
The algorithm for verifying authentication information is as follows.
If the message type is not KRB_AP_REQ, the server returns the
KRB_AP_ERR_MSG_TYPE error. If the key version indicated by the
Ticket in the KRB_AP_REQ is not one the server can use (e.g., it
indicates an old key, and the server no longer possesses a copy of
the old key), the KRB_AP_ERR_BADKEYVER error is returned. If the
USE-SESSION-KEY flag is set in the ap-options field, it indicates to
the server that user-to-user authentication is in use, and that the
ticket is encrypted in the session key from the server's TGT rather
than in the server's secret key. See Section 3.7 for a more complete
description of the effect of user-to-user authentication on all
messages in the Kerberos protocol.
Because it is possible for the server to be registered in multiple
realms, with different keys in each, the srealm field in the
unencrypted portion of the ticket in the KRB_AP_REQ is used to
specify which secret key the server should use to decrypt that
ticket. The KRB_AP_ERR_NOKEY error code is returned if the server
doesn't have the proper key to decipher the ticket.
The ticket is decrypted using the version of the server's key
specified by the ticket. If the decryption routines detect a
modification of the ticket (each encryption system MUST provide
safeguards to detect modified ciphertext), the
Neuman, et al. Standards Track [Page 30]
RFC 4120 Kerberos V5 July 2005
KRB_AP_ERR_BAD_INTEGRITY error is returned (chances are good that
different keys were used to encrypt and decrypt).
The authenticator is decrypted using the session key extracted from
the decrypted ticket. If decryption shows that is has been modified,
the KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm
of the client from the ticket are compared against the same fields in
the authenticator. If they don't match, the KRB_AP_ERR_BADMATCH
error is returned; normally this is caused by a client error or an
attempted attack. The addresses in the ticket (if any) are then
searched for an address matching the operating-system reported
address of the client. If no match is found or the server insists on
ticket addresses but none are present in the ticket, the
KRB_AP_ERR_BADADDR error is returned. If the local (server) time and
the client time in the authenticator differ by more than the
allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW error is
returned.
Unless the application server provides its own suitable means to
protect against replay (for example, a challenge-response sequence
initiated by the server after authentication, or use of a server-
generated encryption subkey), the server MUST utilize a replay cache
to remember any authenticator presented within the allowable clock
skew. Careful analysis of the application protocol and
implementation is recommended before eliminating this cache. The
replay cache will store at least the server name, along with the
client name, time, and microsecond fields from the recently-seen
authenticators, and if a matching tuple is found, the
KRB_AP_ERR_REPEAT error is returned. Note that the rejection here is
restricted to authenticators from the same principal to the same
server. Other client principals communicating with the same server
principal should not have their authenticators rejected if the time
and microsecond fields happen to match some other client's
authenticator.
If a server loses track of authenticators presented within the
allowable clock skew, it MUST reject all requests until the clock
skew interval has passed, providing assurance that any lost or
replayed authenticators will fall outside the allowable clock skew
and can no longer be successfully replayed. If this were not done,
an attacker could subvert the authentication by recording the ticket
and authenticator sent over the network to a server and replaying
them following an event that caused the server to lose track of
recently seen authenticators.
Implementation note: If a client generates multiple requests to the
KDC with the same timestamp, including the microsecond field, all but
the first of the requests received will be rejected as replays. This
Neuman, et al. Standards Track [Page 31]
RFC 4120 Kerberos V5 July 2005
might happen, for example, if the resolution of the client's clock is
too coarse. Client implementations SHOULD ensure that the timestamps
are not reused, possibly by incrementing the microseconds field in
the time stamp when the clock returns the same time for multiple
requests.
If multiple servers (for example, different services on one machine,
or a single service implemented on multiple machines) share a service
principal (a practice that we do not recommend in general, but that
we acknowledge will be used in some cases), either they MUST share
this replay cache, or the application protocol MUST be designed so as
to eliminate the need for it. Note that this applies to all of the
services. If any of the application protocols does not have replay
protection built in, an authenticator used with such a service could
later be replayed to a different service with the same service
principal but no replay protection, if the former doesn't record the
authenticator information in the common replay cache.
If a sequence number is provided in the authenticator, the server
saves it for later use in processing KRB_SAFE and/or KRB_PRIV
messages. If a subkey is present, the server either saves it for
later use or uses it to help generate its own choice for a subkey to
be returned in a KRB_AP_REP message.
The server computes the age of the ticket: local (server) time minus
the starttime inside the Ticket. If the starttime is later than the
current time by more than the allowable clock skew, or if the INVALID
flag is set in the ticket, the KRB_AP_ERR_TKT_NYV error is returned.
Otherwise, if the current time is later than end time by more than
the allowable clock skew, the KRB_AP_ERR_TKT_EXPIRED error is
returned.
If all these checks succeed without an error, the server is assured
that the client possesses the credentials of the principal named in
the ticket, and thus, that the client has been authenticated to the
server.
Passing these checks provides only authentication of the named
principal; it does not imply authorization to use the named service.
Applications MUST make a separate authorization decision based upon
the authenticated name of the user, the requested operation, local
access control information such as that contained in a .k5login or
.k5users file, and possibly a separate distributed authorization
service.
Neuman, et al. Standards Track [Page 32]
RFC 4120 Kerberos V5 July 2005
3.2.4. Generation of a KRB_AP_REP Message
Typically, a client's request will include both the authentication
information and its initial request in the same message, and the
server need not explicitly reply to the KRB_AP_REQ. However, if
mutual authentication (authenticating not only the client to the
server, but also the server to the client) is being performed, the
KRB_AP_REQ message will have MUTUAL-REQUIRED set in its ap-options
field, and a KRB_AP_REP message is required in response. As with the
error message, this message MAY be encapsulated in the application
protocol if its "raw" form is not acceptable to the application's
protocol. The timestamp and microsecond field used in the reply MUST
be the client's timestamp and microsecond field (as provided in the
authenticator). If a sequence number is to be included, it SHOULD be
randomly chosen as described above for the authenticator. A subkey
MAY be included if the server desires to negotiate a different
subkey. The KRB_AP_REP message is encrypted in the session key
extracted from the ticket.
Note that in the Kerberos Version 4 protocol, the timestamp in the
reply was the client's timestamp plus one. This is not necessary in
Version 5 because Version 5 messages are formatted in such a way that
it is not possible to create the reply by judicious message surgery
(even in encrypted form) without knowledge of the appropriate
encryption keys.
3.2.5. Receipt of KRB_AP_REP Message
If a KRB_AP_REP message is returned, the client uses the session key
from the credentials obtained for the server to decrypt the message
and verifies that the timestamp and microsecond fields match those in
the Authenticator it sent to the server. If they match, then the
client is assured that the server is genuine. The sequence number
and subkey (if present) are retained for later use. (Note that for
encrypting the KRB_AP_REP message, the sub-session key is not used,
even if it is present in the Authentication.)
3.2.6. Using the Encryption Key
After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and
server share an encryption key that can be used by the application.
In some cases, the use of this session key will be implicit in the
protocol; in others the method of use must be chosen from several
alternatives. The application MAY choose the actual encryption key
to be used for KRB_PRIV, KRB_SAFE, or other application-specific uses
based on the session key from the ticket and subkeys in the
KRB_AP_REP message and the authenticator. Implementations of the
protocol MAY provide routines to choose subkeys based on session keys
Neuman, et al. Standards Track [Page 33]
RFC 4120 Kerberos V5 July 2005
and random numbers and to generate a negotiated key to be returned in
the KRB_AP_REP message.
To mitigate the effect of failures in random number generation on the
client, it is strongly encouraged that any key derived by an
application for subsequent use include the full key entropy derived
from the KDC-generated session key carried in the ticket. We leave
the protocol negotiations of how to use the key (e.g., for selecting
an encryption or checksum type) to the application programmer. The
Kerberos protocol does not constrain the implementation options, but
an example of how this might be done follows.
One way that an application may choose to negotiate a key to be used
for subsequent integrity and privacy protection is for the client to
propose a key in the subkey field of the authenticator. The server
can then choose a key using the key proposed by the client as input,
returning the new subkey in the subkey field of the application
reply. This key could then be used for subsequent communication.
With both the one-way and mutual authentication exchanges, the peers
should take care not to send sensitive information to each other
without proper assurances. In particular, applications that require
privacy or integrity SHOULD use the KRB_AP_REP response from the
server to the client to assure both client and server of their peer's
identity. If an application protocol requires privacy of its
messages, it can use the KRB_PRIV message (section 3.5). The
KRB_SAFE message (Section 3.4) can be used to ensure integrity.
3.3. The Ticket-Granting Service (TGS) Exchange
Summary
Message direction Message type Section
1. Client to Kerberos KRB_TGS_REQ 5.4.1
2. Kerberos to client KRB_TGS_REP or 5.4.2
KRB_ERROR 5.9.1
The TGS exchange between a client and the Kerberos TGS is initiated
by a client when it seeks to obtain authentication credentials for a
given server (which might be registered in a remote realm), when it
seeks to renew or validate an existing ticket, or when it seeks to
obtain a proxy ticket. In the first case, the client must already
have acquired a ticket for the Ticket-Granting Service using the AS
exchange (the TGT is usually obtained when a client initially
authenticates to the system, such as when a user logs in). The
message format for the TGS exchange is almost identical to that for
the AS exchange. The primary difference is that encryption and
decryption in the TGS exchange does not take place under the client's
Neuman, et al. Standards Track [Page 34]
RFC 4120 Kerberos V5 July 2005
key. Instead, the session key from the TGT or renewable ticket, or
sub-session key from an Authenticator is used. As is the case for
all application servers, expired tickets are not accepted by the TGS,
so once a renewable or TGT expires, the client must use a separate
exchange to obtain valid tickets.
The TGS exchange consists of two messages: a request (KRB_TGS_REQ)
from the client to the Kerberos Ticket-Granting Server, and a reply
(KRB_TGS_REP or KRB_ERROR). The KRB_TGS_REQ message includes
information authenticating the client plus a request for credentials.
The authentication information consists of the authentication header
(KRB_AP_REQ), which includes the client's previously obtained
ticket-granting, renewable, or invalid ticket. In the TGT and proxy
cases, the request MAY include one or more of the following: a list
of network addresses, a collection of typed authorization data to be
sealed in the ticket for authorization use by the application server,
or additional tickets (the use of which are described later). The
TGS reply (KRB_TGS_REP) contains the requested credentials, encrypted
in the session key from the TGT or renewable ticket, or, if present,
in the sub-session key from the Authenticator (part of the
authentication header). The KRB_ERROR message contains an error code
and text explaining what went wrong. The KRB_ERROR message is not
encrypted. The KRB_TGS_REP message contains information that can be
used to detect replays, and to associate it with the message to which
it replies. The KRB_ERROR message also contains information that can
be used to associate it with the message to which it replies. The
same comments about integrity protection of KRB_ERROR messages
mentioned in Section 3.1 apply to the TGS exchange.
3.3.1. Generation of KRB_TGS_REQ Message
Before sending a request to the ticket-granting service, the client
MUST determine in which realm the application server is believed to
be registered. This can be accomplished in several ways. It might
be known beforehand (since the realm is part of the principal
identifier), it might be stored in a nameserver, or it might be
obtained from a configuration file. If the realm to be used is
obtained from a nameserver, there is a danger of being spoofed if the
nameservice providing the realm name is not authenticated. This
might result in the use of a realm that has been compromised, which
would result in an attacker's ability to compromise the
authentication of the application server to the client.
If the client knows the service principal name and realm and it does
not already possess a TGT for the appropriate realm, then one must be
obtained. This is first attempted by requesting a TGT for the
destination realm from a Kerberos server for which the client
possesses a TGT (by using the KRB_TGS_REQ message recursively). The
Neuman, et al. Standards Track [Page 35]
RFC 4120 Kerberos V5 July 2005
Kerberos server MAY return a TGT for the desired realm, in which case
one can proceed. Alternatively, the Kerberos server MAY return a TGT
for a realm that is 'closer' to the desired realm (further along the
standard hierarchical path between the client's realm and the
requested realm server's realm). Note that in this case
misconfiguration of the Kerberos servers may cause loops in the
resulting authentication path, which the client should be careful to
detect and avoid.
If the Kerberos server returns a TGT for a realm 'closer' than the
desired realm, the client MAY use local policy configuration to
verify that the authentication path used is an acceptable one.
Alternatively, a client MAY choose its own authentication path,
rather than rely on the Kerberos server to select one. In either
case, any policy or configuration information used to choose or
validate authentication paths, whether by the Kerberos server or by
the client, MUST be obtained from a trusted source.
When a client obtains a TGT that is 'closer' to the destination
realm, the client MAY cache this ticket and reuse it in future
KRB-TGS exchanges with services in the 'closer' realm. However, if
the client were to obtain a TGT for the 'closer' realm by starting at
the initial KDC rather than as part of obtaining another ticket, then
a shorter path to the 'closer' realm might be used. This shorter
path may be desirable because fewer intermediate KDCs would know the
session key of the ticket involved. For this reason, clients SHOULD
evaluate whether they trust the realms transited in obtaining the
'closer' ticket when making a decision to use the ticket in future.
Once the client obtains a TGT for the appropriate realm, it
determines which Kerberos servers serve that realm and contacts one
of them. The list might be obtained through a configuration file or
network service, or it MAY be generated from the name of the realm.
As long as the secret keys exchanged by realms are kept secret, only
denial of service results from using a false Kerberos server.
As in the AS exchange, the client MAY specify a number of options in
the KRB_TGS_REQ message. One of these options is the ENC-TKT-IN-SKEY
option used for user-to-user authentication. An overview of user-
to-user authentication can be found in Section 3.7. When generating
the KRB_TGS_REQ message, this option indicates that the client is
including a TGT obtained from the application server in the
additional tickets field of the request and that the KDC SHOULD
encrypt the ticket for the application server using the session key
from this additional ticket, instead of a server key from the
principal database.
Neuman, et al. Standards Track [Page 36]
RFC 4120 Kerberos V5 July 2005
The client prepares the KRB_TGS_REQ message, providing an
authentication header as an element of the padata field, and
including the same fields as used in the KRB_AS_REQ message along
with several optional fields: the enc-authorizatfion-data field for
application server use and additional tickets required by some
options.
In preparing the authentication header, the client can select a sub-
session key under which the response from the Kerberos server will be
encrypted. If the client selects a sub-session key, care must be
taken to ensure the randomness of the selected sub-session key.
If the sub-session key is not specified, the session key from the TGT
will be used. If the enc-authorization-data is present, it MUST be
encrypted in the sub-session key, if present, from the authenticator
portion of the authentication header, or, if not present, by using
the session key from the TGT.
Once prepared, the message is sent to a Kerberos server for the
destination realm.
3.3.2. Receipt of KRB_TGS_REQ Message
The KRB_TGS_REQ message is processed in a manner similar to the
KRB_AS_REQ message, but there are many additional checks to be
performed. First, the Kerberos server MUST determine which server
the accompanying ticket is for, and it MUST select the appropriate
key to decrypt it. For a normal KRB_TGS_REQ message, it will be for
the ticket-granting service, and the TGS's key will be used. If the
TGT was issued by another realm, then the appropriate inter-realm key
MUST be used. If (a) the accompanying ticket is not a TGT for the
current realm, but is for an application server in the current realm,
(b) the RENEW, VALIDATE, or PROXY options are specified in the
request, and (c) the server for which a ticket is requested is the
server named in the accompanying ticket, then the KDC will decrypt
the ticket in the authentication header using the key of the server
for which it was issued. If no ticket can be found in the padata
field, the KDC_ERR_PADATA_TYPE_NOSUPP error is returned.
Once the accompanying ticket has been decrypted, the user-supplied
checksum in the Authenticator MUST be verified against the contents
of the request, and the message MUST be rejected if the checksums do
not match (with an error code of KRB_AP_ERR_MODIFIED) or if the
checksum is not collision-proof (with an error code of
KRB_AP_ERR_INAPP_CKSUM). If the checksum type is not supported, the
KDC_ERR_SUMTYPE_NOSUPP error is returned. If the authorization-data
are present, they are decrypted using the sub-session key from the
Authenticator.
Neuman, et al. Standards Track [Page 37]
RFC 4120 Kerberos V5 July 2005
If any of the decryptions indicate failed integrity checks, the
KRB_AP_ERR_BAD_INTEGRITY error is returned.
As discussed in Section 3.1.2, the KDC MUST send a valid KRB_TGS_REP
message if it receives a KRB_TGS_REQ message identical to one it has
recently processed. However, if the authenticator is a replay, but
the rest of the request is not identical, then the KDC SHOULD return
KRB_AP_ERR_REPEAT.
3.3.3. Generation of KRB_TGS_REP Message
The KRB_TGS_REP message shares its format with the KRB_AS_REP
(KRB_KDC_REP), but with its type field set to KRB_TGS_REP. The
detailed specification is in Section 5.4.2.
The response will include a ticket for the requested server or for a
ticket granting server of an intermediate KDC to be contacted to
obtain the requested ticket. The Kerberos database is queried to
retrieve the record for the appropriate server (including the key
with which the ticket will be encrypted). If the request is for a
TGT for a remote realm, and if no key is shared with the requested
realm, then the Kerberos server will select the realm 'closest' to
the requested realm with which it does share a key and use that realm
instead. This is the only case where the response for the KDC will
be for a different server than that requested by the client.
By default, the address field, the client's name and realm, the list
of transited realms, the time of initial authentication, the
expiration time, and the authorization data of the newly-issued
ticket will be copied from the TGT or renewable ticket. If the
transited field needs to be updated, but the transited type is not
supported, the KDC_ERR_TRTYPE_NOSUPP error is returned.
If the request specifies an endtime, then the endtime of the new
ticket is set to the minimum of (a) that request, (b) the endtime
from the TGT, and (c) the starttime of the TGT plus the minimum of
the maximum life for the application server and the maximum life for
the local realm (the maximum life for the requesting principal was
already applied when the TGT was issued). If the new ticket is to be
a renewal, then the endtime above is replaced by the minimum of (a)
the value of the renew_till field of the ticket and (b) the starttime
for the new ticket plus the life (endtime-starttime) of the old
ticket.
If the FORWARDED option has been requested, then the resulting ticket
will contain the addresses specified by the client. This option will
only be honored if the FORWARDABLE flag is set in the TGT. The PROXY
option is similar; the resulting ticket will contain the addresses
Neuman, et al. Standards Track [Page 38]
RFC 4120 Kerberos V5 July 2005
specified by the client. It will be honored only if the PROXIABLE
flag in the TGT is set. The PROXY option will not be honored on
requests for additional TGTs.
If the requested starttime is absent, indicates a time in the past,
or is within the window of acceptable clock skew for the KDC and the
POSTDATE option has not been specified, then the starttime of the
ticket is set to the authentication server's current time. If it
indicates a time in the future beyond the acceptable clock skew, but
the POSTDATED option has not been specified or the MAY-POSTDATE flag
is not set in the TGT, then the error KDC_ERR_CANNOT_POSTDATE is
returned. Otherwise, if the TGT has the MAY-POSTDATE flag set, then
the resulting ticket will be postdated, and the requested starttime
is checked against the policy of the local realm. If acceptable, the
ticket's starttime is set as requested, and the INVALID flag is set.
The postdated ticket MUST be validated before use by presenting it to
the KDC after the starttime has been reached. However, in no case
may the starttime, endtime, or renew-till time of a newly-issued
postdated ticket extend beyond the renew-till time of the TGT.
If the ENC-TKT-IN-SKEY option has been specified and an additional
ticket has been included in the request, it indicates that the client
is using user-to-user authentication to prove its identity to a
server that does not have access to a persistent key. Section 3.7
describes the effect of this option on the entire Kerberos protocol.
When generating the KRB_TGS_REP message, this option in the
KRB_TGS_REQ message tells the KDC to decrypt the additional ticket
using the key for the server to which the additional ticket was
issued and to verify that it is a TGT. If the name of the requested
server is missing from the request, the name of the client in the
additional ticket will be used. Otherwise, the name of the requested
server will be compared to the name of the client in the additional
ticket. If it is different, the request will be rejected. If the
request succeeds, the session key from the additional ticket will be
used to encrypt the new ticket that is issued instead of using the
key of the server for which the new ticket will be used.
If (a) the name of the server in the ticket that is presented to the
KDC as part of the authentication header is not that of the TGS
itself, (b) the server is registered in the realm of the KDC, and (c)
the RENEW option is requested, then the KDC will verify that the
RENEWABLE flag is set in the ticket, that the INVALID flag is not set
in the ticket, and that the renew_till time is still in the future.
If the VALIDATE option is requested, the KDC will check that the
starttime has passed and that the INVALID flag is set. If the PROXY
option is requested, then the KDC will check that the PROXIABLE flag
Neuman, et al. Standards Track [Page 39]
RFC 4120 Kerberos V5 July 2005
is set in the ticket. If the tests succeed and the ticket passes the
hotlist check described in the next section, the KDC will issue the
appropriate new ticket.
The ciphertext part of the response in the KRB_TGS_REP message is
encrypted in the sub-session key from the Authenticator, if present,
or in the session key from the TGT. It is not encrypted using the
client's secret key. Furthermore, the client's key's expiration date
and the key version number fields are left out since these values are
stored along with the client's database record, and that record is
not needed to satisfy a request based on a TGT.
3.3.3.1. Checking for Revoked Tickets
Whenever a request is made to the ticket-granting server, the
presented ticket(s) is (are) checked against a hot-list of tickets
that have been canceled. This hot-list might be implemented by
storing a range of issue timestamps for 'suspect tickets'; if a
presented ticket had an authtime in that range, it would be rejected.
In this way, a stolen TGT or renewable ticket cannot be used to gain
additional tickets (renewals or otherwise) once the theft has been
reported to the KDC for the realm in which the server resides. Any
normal ticket obtained before it was reported stolen will still be
valid (because tickets require no interaction with the KDC), but only
until its normal expiration time. If TGTs have been issued for
cross-realm authentication, use of the cross-realm TGT will not be
affected unless the hot-list is propagated to the KDCs for the realms
for which such cross-realm tickets were issued.
3.3.3.2. Encoding the Transited Field
If the identity of the server in the TGT that is presented to the KDC
as part of the authentication header is that of the ticket-granting
service, but the TGT was issued from another realm, the KDC will look
up the inter-realm key shared with that realm and use that key to
decrypt the ticket. If the ticket is valid, then the KDC will honor
the request, subject to the constraints outlined above in the section
describing the AS exchange. The realm part of the client's identity
will be taken from the TGT. The name of the realm that issued the
TGT, if it is not the realm of the client principal, will be added to
the transited field of the ticket to be issued. This is accomplished
by reading the transited field from the TGT (which is treated as an
unordered set of realm names), adding the new realm to the set, and
then constructing and writing out its encoded (shorthand) form (this
may involve a rearrangement of the existing encoding).
Note that the ticket-granting service does not add the name of its
own realm. Instead, its responsibility is to add the name of the
Neuman, et al. Standards Track [Page 40]
RFC 4120 Kerberos V5 July 2005
previous realm. This prevents a malicious Kerberos server from
intentionally leaving out its own name (it could, however, omit other
realms' names).
The names of neither the local realm nor the principal's realm are to
be included in the transited field. They appear elsewhere in the
ticket and both are known to have taken part in authenticating the
principal. Because the endpoints are not included, both local and
single-hop inter-realm authentication result in a transited field
that is empty.
Because this field has the name of each transited realm added to it,
it might potentially be very long. To decrease the length of this
field, its contents are encoded. The initially supported encoding is
optimized for the normal case of inter-realm communication: a
hierarchical arrangement of realms using either domain or X.500 style
realm names. This encoding (called DOMAIN-X500-COMPRESS) is now
described.
Realm names in the transited field are separated by a ",". The ",",
"\", trailing "."s, and leading spaces (" ") are special characters,
and if they are part of a realm name, they MUST be quoted in the
transited field by preceding them with a "\".
A realm name ending with a "." is interpreted as being prepended to
the previous realm. For example, we can encode traversal of EDU,
MIT.EDU, ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as:
"EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.".
Note that if either ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were
endpoints, they would not be included in this field, and we would
have:
"EDU,MIT.,WASHINGTON.EDU"
A realm name beginning with a "/" is interpreted as being appended to
the previous realm. For the purpose of appending, the realm
preceding the first listed realm is considered the null realm ("").
If a realm name beginning with a "/" is to stand by itself, then it
SHOULD be preceded by a space (" "). For example, we can encode
traversal of /COM/HP/APOLLO, /COM/HP, /COM, and /COM/DEC as:
"/COM,/HP,/APOLLO, /COM/DEC".
As in the example above, if /COM/HP/APOLLO and /COM/DEC were
endpoints, they would not be included in this field, and we would
have:
Neuman, et al. Standards Track [Page 41]
RFC 4120 Kerberos V5 July 2005
"/COM,/HP"
A null subfield preceding or following a "," indicates that all
realms between the previous realm and the next realm have been
traversed. For the purpose of interpreting null subfields, the
client's realm is considered to precede those in the transited field,
and the server's realm is considered to follow them. Thus, "," means
that all realms along the path between the client and the server have
been traversed. ",EDU, /COM," means that all realms from the
client's realm up to EDU (in a domain style hierarchy) have been
traversed, and that everything from /COM down to the server's realm
in an X.500 style has also been traversed. This could occur if the
EDU realm in one hierarchy shares an inter-realm key directly with
the /COM realm in another hierarchy.
3.3.4. Receipt of KRB_TGS_REP Message
When the KRB_TGS_REP is received by the client, it is processed in
the same manner as the KRB_AS_REP processing described above. The
primary difference is that the ciphertext part of the response must
be decrypted using the sub-session key from the Authenticator, if it
was specified in the request, or the session key from the TGT, rather
than the client's secret key. The server name returned in the reply
is the true principal name of the service.
3.4. The KRB_SAFE Exchange
The KRB_SAFE message MAY be used by clients requiring the ability to
detect modifications of messages they exchange. It achieves this by
including a keyed collision-proof checksum of the user data and some
control information. The checksum is keyed with an encryption key
(usually the last key negotiated via subkeys, or the session key if
no negotiation has occurred).
3.4.1. Generation of a KRB_SAFE Message
When an application wishes to send a KRB_SAFE message, it collects
its data and the appropriate control information and computes a
checksum over them. The checksum algorithm should be the keyed
checksum mandated to be implemented along with the crypto system used
for the sub-session or session key. The checksum is generated using
the sub-session key, if present, or the session key. Some
implementations use a different checksum algorithm for the KRB_SAFE
messages, but doing so in an interoperable manner is not always
possible.
The control information for the KRB_SAFE message includes both a
timestamp and a sequence number. The designer of an application
Neuman, et al. Standards Track [Page 42]
RFC 4120 Kerberos V5 July 2005
using the KRB_SAFE message MUST choose at least one of the two
mechanisms. This choice SHOULD be based on the needs of the
application protocol.
Sequence numbers are useful when all messages sent will be received
by one's peer. Connection state is presently required to maintain
the session key, so maintaining the next sequence number should not
present an additional problem.
If the application protocol is expected to tolerate lost messages
without their being resent, the use of the timestamp is the
appropriate replay detection mechanism. Using timestamps is also the
appropriate mechanism for multi-cast protocols in which all of one's
peers share a common sub-session key, but some messages will be sent
to a subset of one's peers.
After computing the checksum, the client then transmits the
information and checksum to the recipient in the message format
specified in Section 5.6.1.
3.4.2. Receipt of KRB_SAFE Message
When an application receives a KRB_SAFE message, it verifies it as
follows. If any error occurs, an error code is reported for use by
the application.
The message is first checked by verifying that the protocol version
and type fields match the current version and KRB_SAFE, respectively.
A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE
error. The application verifies that the checksum used is a
collision-proof keyed checksum that uses keys compatible with the
sub-session or session key as appropriate (or with the application
key derived from the session or sub-session keys). If it is not, a
KRB_AP_ERR_INAPP_CKSUM error is generated. The sender's address MUST
be included in the control information; |
