WDIFF

draft-ietf-cat-kerberos-02.txt --> rfc1510.txt

INTERNET-DRAFT John

Network Working Group J. Kohl
B. Clifford
Request for Comments: 1510 Digital Equipment Corporation
C. Neuman
21 April
ISI
September 1993

The Kerberos Network Authentication Service (V5)

STATUS OF THIS MEMO

Status of this Memo

This document is RFC specifies an Internet Draft. Internet Drafts
are working documents of standards track protocol for the
Internet Engineering Task Force
(IETF), its Areas, community, and its Working Groups. Note that other
groups may also distribute working documents as Internet
Drafts.

Internet Drafts are draft documents valid requests discussion and suggestions for a maximum
of six months. Internet Drafts may be updated, replaced,
or obsoleted by other documents at any time. It is not
appropriate to use Internet Drafts as reference material or
to cite them other than as a "working draft" or "work in
progress."
improvements. Please check the I-D abstract listing contained in each
Internet Draft directory refer to learn the current edition of the "Internet
Official Protocol Standards" for the standardization state and status
of this
or any other Internet Draft. protocol. Distribution of this memo is unlimited. Please send comments to "krb-protocol@MIT.EDU."

ABSTRACT

Abstract

This document gives an overview and specification of Version 5 of the
protocol for the Kerberos network authenti-
cation authentication system. Version 4,
described elsewhere [1,2], is presently in production use at MIT's
Project Athena, and at other Internet sites.

OVERVIEW

Overview

Project Athena, Athena, Athena MUSE, Discuss, Hesiod, Kerberos,
Moira, and Zephyr are trademarks of the Massachusetts Institute of
Technology (MIT). No commercial use of these trademarks may be made
without prior written permission of MIT.

This INTERNET-DRAFT RFC describes the concepts and model upon which the Kerberos
network authentication system is based. It also specifies Version 5
of the Kerberos proto-
col. protocol.

The motivations, goals, assumptions, and rationale behind most design
decisions are treated cursorily; for Ver-
sion Version 4 they are fully
described in the Kerberos portion of
__________________________
Project Athena, Athena, Athena MUSE, Discuss, Hesiod,
Kerberos, Moira, and Zephyr are trademarks of the Mas-
sachusetts Institute of Technology (MIT). No commer-
cial use of these trademarks may be made without prior
written permission of MIT.

Overview - 1 - Expires 15 October 1993

Version 5 - Revision 5.2 the Athena Technical Plan [1].
The protocols are under review, and are not being submitted for
consideration as an Internet standard at this time. Comments are
encouraged. Requests for addition to an electronic mailing list for dis-
cussion
discussion of Kerberos, kerberos@MIT.EDU, may be addressed to
kerberos-request@MIT.EDU. This mailing list is gatewayed onto the
Usenet as the group comp.protocols.kerberos. Requests for further
information, including documents and code availability, may be sent
to info-kerberos@MIT.EDU.

BACKGROUND

Kohl & Neuman [Page 1]

RFC 1510 Kerberos September 1993

Background

The Kerberos model is based in part on Needham and Schroeder's
trusted third-party authentication protocol [3] and on modifications
suggested by Denning and Sacco [4]. 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 Ker-
beros. Kerberos.
Version 4 is publicly available, and has seen wide use across the
Internet.

Version 5 (described in this document) has evolved from Version 4
based on new requirements and desires for features not available in
Version 4. Details on the differences between Kerberos Versions 4
and 5 can be found in [5].

Table of Contents

1. Introduction

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 authentication by the host operating sys-
tem, without basing trust on host addresses, without requir-
ing physical security ....................................... 5
1.1. Cross-Realm Operation ............................ 7
1.2. Environmental assumptions ........................ 8
1.3. Glossary of all the hosts on the network, terms ................................ 9
2. Ticket flag uses and
under the assumption that packets traveling along the net-
work can be read, modified, requests ...................... 12
2.1. Initial and inserted at will[1]. Ker-
beros performs authentication under these conditions as a
trusted third-party authentication service by using conven-
tional (shared secret key[2]) cryptography.
__________________________
[1] Note, however, that many applications use Kerberos'
functions only upon the initiation pre-authenticated tickets ............ 12
2.2. Invalid tickets .................................. 12
2.3. Renewable tickets ................................ 12
2.4. Postdated tickets ................................ 13
2.5. Proxiable and proxy tickets ...................... 14
2.6. Forwardable tickets .............................. 15
2.7. Other KDC options ................................ 15
3. Message Exchanges .................................. 16
3.1. The Authentication Service Exchange .............. 16
3.1.1. Generation of KRB_AS_REQ message ............... 17
3.1.2. Receipt of KRB_AS_REQ message .................. 17
3.1.3. Generation of KRB_AS_REP message ............... 17
3.1.4. Generation of KRB_ERROR message ................ 19
3.1.5. Receipt of KRB_AS_REP message .................. 19
3.1.6. Receipt of KRB_ERROR message ................... 20
3.2. The Client/Server Authentication Exchange ........ 20
3.2.1. The KRB_AP_REQ message ......................... 20
3.2.2. Generation of a stream-based
network connection, and assume the absence KRB_AP_REQ message ............. 20
3.2.3. Receipt of KRB_AP_REQ message .................. 21
3.2.4. Generation of any ``hi-
jackers'' who might subvert such a connection. Such
use implicitly trusts the host addresses involved.

[2] Secret and private are often used interchangeably
in KRB_AP_REP message ............. 23
3.2.5. Receipt of KRB_AP_REP message .................. 23

Kohl & Neuman [Page 2]

RFC 1510 Kerberos September 1993

3.2.6. Using the literature. In our usage, it takes two (or
more) to share a secret, thus a shared DES encryption key is a
secret key. Something is only private when no one but

Section 1. - 2 - Expires 15 October 1993

Version 5 - Revision 5.2

The authentication process proceeds as follows: A
client sends a request to the authentication server (AS)
requesting "credentials" for a given server. ....................... 24
3.3. The AS
responds with these credentials, encrypted in Ticket-Granting Service (TGS) Exchange ....... 24
3.3.1. Generation of KRB_TGS_REQ message .............. 25
3.3.2. Receipt of KRB_TGS_REQ message ................. 26
3.3.3. Generation of KRB_TGS_REP message .............. 27
3.3.3.1. Encoding the client's
key. transited field ................. 29
3.3.4. Receipt of KRB_TGS_REP message ................. 31
3.4. The credentials consist KRB_SAFE Exchange ............................ 31
3.4.1. Generation of 1) a "ticket" for the
server and 2) a temporary encryption key (often called KRB_SAFE message ............... 31
3.4.2. Receipt of KRB_SAFE message .................... 32
3.5. The KRB_PRIV Exchange ............................ 33
3.5.1. Generation of a
"session key"). KRB_PRIV message ............... 33
3.5.2. Receipt of KRB_PRIV message .................... 33
3.6. The client transmits the ticket (which con-
tains the client's identity and KRB_CRED Exchange ............................ 34
3.6.1. Generation of a copy KRB_CRED message ............... 34
3.6.2. Receipt of the session key,
all encrypted in the server's key) to the server. KRB_CRED message .................... 34
4. The ses-
sion key (now shared by the client Kerberos Database .............................. 35
4.1. Database contents ................................ 35
4.2. Additional fields ................................ 36
4.3. Frequently Changing Fields ....................... 37
4.4. Site Constants ................................... 37
5. Message Specifications ............................. 38
5.1. ASN.1 Distinguished Encoding Representation ...... 38
5.2. ASN.1 Base Definitions ........................... 38
5.3. Tickets and server) is used to
authenticate Authenticators ....................... 42
5.3.1. Tickets ........................................ 42
5.3.2. Authenticators ................................. 47
5.4. Specifications for the client, AS 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.

The implementation consists of one or more authentica-
tion 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 TGS exchanges ...... 49
5.4.1. KRB_KDC_REQ definition ......................... 49
5.4.2. KRB_KDC_REP definition ......................... 56
5.5. Client/Server (CS) message specifications ........ 58
5.5.1. KRB_AP_REQ definition .......................... 58
5.5.2. KRB_AP_REP definition .......................... 60
5.5.3. Error message reply ............................ 61
5.6. KRB_SAFE message specification ................... 61
5.6.1. KRB_SAFE definition ............................ 61
5.7. KRB_PRIV message specification ................... 62
5.7.1. KRB_PRIV definition ............................ 62
5.8. KRB_CRED message specification ................... 63
5.8.1. KRB_CRED definition ............................ 63
5.9. Error message specification ...................... 65
5.9.1. KRB_ERROR definition ........................... 66
6. Encryption and implement the Kerberos pro-
tocol. In order to add authentication to its transactions, Checksum Specifications ............. 67
6.1. Encryption Specifications ........................ 68
6.2. Encryption Keys .................................. 71
6.3. Encryption Systems ............................... 71
6.3.1. The NULL Encryption System (null) .............. 71
6.3.2. DES in CBC mode with a typical network application adds one or two calls to the CRC-32 checksum (descbc-crc)71

Kohl & Neuman [Page 3]

RFC 1510 Kerberos library, which results September 1993

6.3.3. DES in the transmission of the
necessary messages to achieve authentication. CBC mode with an MD4 checksum (descbc-md4) 72
6.3.4. DES in CBC mode with an MD5 checksum (descbc-md5) 72
6.4. Checksums ........................................ 74
6.4.1. The Kerberos protocol consists of several sub-protocols
(or exchanges). There are two 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. CRC-32 Checksum (crc32) .................... 74
6.4.2. The client
sends the TGT to the TGS in the same manner as if it were
contacting any other application server which requires Ker-
beros credentials. RSA MD4 Checksum (rsa-md4) ................. 75
6.4.3. RSA MD4 Cryptographic Checksum Using DES
(rsa-md4-des) ......................................... 75
6.4.4. The reply is encrypted in the session
key from the TGT.

Once obtained, credentials may be used to verify the
identity RSA MD5 Checksum (rsa-md5) ................. 76
6.4.5. RSA MD5 Cryptographic Checksum Using DES
(rsa-md5-des) ......................................... 76
6.4.6. DES cipher-block chained checksum (des-mac)
6.4.7. RSA MD4 Cryptographic Checksum Using DES
alternative (rsa-md4-des-k) ........................... 77
6.4.8. DES cipher-block chained checksum alternative
(des-mac-k) ........................................... 77
7. Naming Constraints ................................. 78
7.1. Realm Names ...................................... 77
7.2. Principal Names .................................. 79
7.2.1. Name of the server principals in a transaction, to ensure the
integrity of ...................... 80
8. Constants and other defined values ................. 80
8.1. Host address types ............................... 80
8.2. KDC messages exchanged between them, or to preserve
privacy ..................................... 81
8.2.1. IP transport ................................... 81
8.2.2. OSI transport .................................. 82
8.2.3. Name of the messages. The application is free to choose
whatever protection may be necessary.

To verify TGS ................................ 82
8.3. Protocol constants and associated values ......... 82
9. Interoperability requirements ...................... 86
9.1. Specification 1 .................................. 86
9.2. Recommended KDC values ........................... 88
10. Acknowledgments ................................... 88
11. References ........................................ 89
12. Security Considerations ........................... 90
13. Authors' Addresses ................................ 90
A. Pseudo-code for protocol processing ................ 91
A.1. KRB_AS_REQ generation ............................ 91
A.2. KRB_AS_REQ verification and KRB_AS_REP generation 92
A.3. KRB_AS_REP verification .......................... 95
A.4. KRB_AS_REP and KRB_TGS_REP common checks ......... 96
A.5. KRB_TGS_REQ generation ........................... 97
A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation 98
A.7. KRB_TGS_REP verification ......................... 104
A.8. Authenticator generation ......................... 104
A.9. KRB_AP_REQ generation ............................ 105
A.10. KRB_AP_REQ verification ......................... 105
A.11. KRB_AP_REP generation ........................... 106
A.12. KRB_AP_REP verification ......................... 107
A.13. KRB_SAFE generation ............................. 107
A.14. KRB_SAFE verification ........................... 108

Kohl & Neuman [Page 4]

RFC 1510 Kerberos September 1993

A.15. KRB_SAFE and KRB_PRIV common checks ............. 108
A.16. KRB_PRIV generation ............................. 109
A.17. KRB_PRIV verification ........................... 110
A.18. KRB_CRED generation ............................. 110
A.19. KRB_CRED verification ........................... 111
A.20. KRB_ERROR generation ............................ 112

1. Introduction

Kerberos provides a means of verifying the identities of the principals in principals,
(e.g., a workstation user or a tran-
saction, network server) on an open
(unprotected) network. This is accomplished without relying on
authentication by the client transmits host operating system, without basing trust on
host addresses, without requiring physical security of all the ticket to hosts
on the server.
Since network, and under the ticket is sent "in assumption that packets traveling along
the clear" (parts of it are
encrypted, but this encryption doesn't thwart replay) network can be read, modified, and
__________________________
its owner knows it. Thus, in public key cryptosystems,
one has a public inserted at will. (Note,
however, that many applications use Kerberos' functions only upon the
initiation of a stream-based network connection, and assume the
absence of any "hijackers" who might subvert such a private connection. Such
use implicitly trusts the host addresses involved.) Kerberos
performs authentication under these conditions as a trusted third-
party authentication service by using conventional cryptography,
i.e., shared secret key.

Section 1. - 3 - Expires 15 October 1993

Version 5 (shared secret key - Revision 5.2

might be intercepted Secret and reused by an attacker, additional
information is sent to prove that the message was originated
by private are
often used interchangeably in the principal literature. In our usage, it takes
two (or more) to whom the ticket was issued. This infor-
mation (called the authenticator) share a secret, thus a shared DES key is a secret
key. Something is only private when no one but its owner knows it.
Thus, in public key cryptosystems, one has a public and a private
key.)

The authentication process proceeds as follows: A client sends a
request to the authentication server (AS) requesting "credentials"
for a given server. The AS responds with these credentials,
encrypted in the ses-
sion key, client's key. The credentials consist of 1) a
"ticket" for the server and includes 2) a timestamp. temporary encryption key (often
called a "session key"). The timestamp proves
that client transmits the message was recently generated ticket (which
contains the client's identity and is not a replay.
Encrypting copy of the authenticator session key, all
encrypted in the server's key) to the server. The session key proves that
it was generated (now
shared by a party possessing the session key.
Since no one except the requesting principal client and server) is used to authenticate 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 client,
and may optionally be used to authenticate the messages exchanged between princi-
pals can server. It may also
be guaranteed using used to encrypt further communication between the session two parties or
to exchange a separate sub-session key (passed in
the ticket and contained in the credentials). This approach
provides detection to be used to encrypt further
communication.

The implementation consists of both replay attacks one or more authentication servers
running on physically secure hosts. The authentication servers
maintain a database of principals (i.e., users and message stream
modification attacks. It is accomplished by generating servers) and
transmitting a collision-proof checksum (elsewhere called their
secret keys. Code libraries provide encryption and implement the
Kerberos protocol. In order to add authentication to its

Kohl & Neuman [Page 5]

RFC 1510 Kerberos September 1993

transactions, a
hash typical network application adds one or digest function) of two calls to
the client's message, keyed with Kerberos library, which results in the session key. Privacy and integrity transmission of the
necessary messages
exchanged between principals can be secured by encrypting
the data to be passed using the session key passed in the
ticket, and contained in the credentials. achieve authentication.

The authentication exchanges mentioned above require
read-only access to the Kerberos database. Sometimes, how-
ever, 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 consists of several sub-protocols (or
exchanges). There are two methods by which a client and can ask a third
Kerberos server, server for credentials. In the Kerberos Administration Server (KADM). first approach, the client
sends a cleartext request for a ticket for the desired server to the
AS. The administration protocol reply is not described sent encrypted in the client's secret key. Usually
this docu-
ment. There request is also a protocol for maintaining multiple
copies of the Kerberos database, but this a ticket-granting ticket (TGT) which can later be considered
an implementation detail and may vary
used with the ticket-granting server (TGS). In the second method,
the client sends a request to support different
database technologies.

1.1. Cross-Realm Operation the TGS. The client sends the TGT to
the TGS in the same manner as if it were contacting any other
application server which requires Kerberos protocol credentials. The reply is designed to operate across
organizational boundaries. A client
encrypted in one organization can the session key from the TGT.

Once obtained, credentials may be authenticated used to a server verify the identity of the
principals in another. Each organization
wishing to run a Kerberos server establishes its own
"realm". transaction, to ensure the integrity of messages
exchanged between them, or to preserve privacy of the messages. The name
application is free to choose whatever protection may be necessary.

To verify the identities of the realm principals in which a transaction, the
client transmits the ticket to the server. Since the ticket is
registered is part of sent
"in the client's name, clear" (parts of it are encrypted, but this encryption
doesn't thwart replay) and can might be used intercepted and reused by
the end-service an
attacker, additional information is sent to decide whether prove that the message
was originated by the principal to honor a request.

By establishing "inter-realm" keys, whom the administrators
of two realms can allow a client authenticated in the local
realm to use its authentication remotely[3]. The exchange
__________________________

[3] Of course, with appropriate permission ticket was issued. This
information (called the client
could arrange registration of a separately-named prin-
cipal in a remote realm, and engage authenticator) is encrypted in normal exchanges
with that realm's services. However, for even small

Section 1.1. - 4 - Expires 15 October 1993

Version 5 - Revision 5.2

of inter-realm keys (a separate key may be used for each
direction) registers the ticket-granting service of each
realm as session
key, and includes a principal in timestamp. The timestamp proves that the other realm. A client message
was recently generated and is then
able to obtain not a ticket-granting ticket for the remote
realm's ticket-granting service from its local realm. When
that ticket-granting ticket is used, replay. Encrypting the remote ticket-
granting service uses
authenticator in the inter-realm session key (which usually
differs from its own normal TGS key) to decrypt the ticket-
granting ticket, and is thus certain proves that it was issued generated by a
party possessing the client's own TGS. Tickets issued by session key. Since no one except the remote ticket-
granting service will indicate to requesting
principal and the end-service that server know the
client was authenticated from another realm.

A realm session key (it is said to communicate with another realm if never sent over
the two realms share an inter-realm key, or if network in the local
realm shares an inter-realm key with an intermediate realm
that communicates with clear) this guarantees the remote realm. An authentication
path is identity of the sequence client.

The integrity of intermediate realms that are tran-
sited in communicating from one realm to another.

Realms are typically 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 authen-
tication path to be easily constructed. If a hierarchical
organization is not used, it may be necessary to consult
some database in order to construct an authentication path messages exchanged between realms.

Although realms are typically hierarchical, intermedi-
ate realms may be bypassed to achieve cross-realm authenti-
cation through alternate authentication paths (these might principals can also
be established to make communication between two realms more
efficient). It is important for guaranteed using the end-service to know
which realms were transited when deciding how much faith to
place session key (passed in the authentication process. To facilitate this
decision, a field in each ticket contains the names of the
realms that were involved and
contained in authenticating the client.

1.2. Environmental assumptions

Kerberos imposes a few assumptions on the environment in
which it can properly function:

+ "Denial credentials). This approach provides detection of service"
both replay attacks are not solved 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 Ker-
beros. There are places in these protocols where an
intruder can prevent an application from participating
in the proper authentication steps. Detection session key. Privacy and
solution of such attacks (some integrity of which the
messages exchanged between principals can appear to be not-uncommon "normal" failure modes for secured by encrypting
the system)
is usually best left data to be passed using the human administrators and
__________________________
numbers of clients this becomes cumbersome, session key passed in the ticket, and more
automatic methods as described here are necessary.

Section 1.2. - 5 - Expires 15 October
contained in the credentials.

The authentication exchanges mentioned above require read-only access
to the Kerberos database. Sometimes, however, the entries in the

Kohl & Neuman [Page 6]

RFC 1510 Kerberos September 1993

Version 5 - Revision 5.2

users.

+ Principals

database must keep their secret keys secret. If an
intruder somehow steals a principal's key, it will be
able to masquerade modified, such as that principal when adding new principals or impersonate any
server to the legitimate principal.

+ "Password guessing" attacks are not solved by Kerberos.
If a user chooses
changing a poor password, it principal's key. This is possible for
an attacker to successfully mount an offline dictionary
attack by repeatedly attempting to decrypt, with suc-
cessive entries from done using a dictionary, messages obtained
which are encrypted under protocol between a key derived from the user's
password.

+ Each host on the network must have
client and a clock which is
"loosely synchronized" to third Kerberos server, the time Kerberos Administration
Server (KADM). The administration protocol is not described in this
document. There is also a protocol for maintaining multiple copies of
the other hosts; Kerberos database, but this synchronization is used can be considered an implementation
detail and may vary to reduce the bookkeeping
needs of application servers when they do replay detec-
tion. support different database technologies.

1.1. Cross-Realm Operation

The degree of "looseness" Kerberos protocol is designed to operate across organizational
boundaries. A client in one organization can be configured on authenticated to a
per-server basis. 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
server in another. Each organization wishing to
particular principals. If a stale ACL entry remains
for run a deleted principal and the principal identifier is
reused, Kerberos
server establishes its own "realm". The name of the new principal will inherit rights specified realm in the stale ACL entry. By not re-using principal
identifiers, the danger of inadvertent access which a
client is
removed.

1.3. Glossary of terms

Below registered is a list part of terms used throughout this document.

Authentication Verifying the claimed identity of a
principal.

Authentication headerA record containing a Ticket client's name, and an
Authenticator to can be presented used by
the end-service to decide whether to honor a
server as part of request.

By establishing "inter-realm" keys, the authentication
process.

Authentication path A sequence administrators of intermediate two realms tran-
sited
can allow a client authenticated in the authentication process when
communicating from one local realm to another.

Section 1.3. - 6 - Expires 15 October 1993

Version 5 - Revision 5.2

Authenticator A record containing information that can
be shown to have been recently generated
using the session key known only by use its
authentication remotely (Of course, with appropriate permission the
client and server.

Authorization The process could arrange registration of determining whether a
client may use separately-named principal in
a service, which objects
the client is allowed to access, remote realm, and the
type of access allowed for each.

Capability A token engage in normal exchanges with that grants the bearer permis-
sion to access an object or service. In
Kerberos, realm's
services. However, for even small numbers of clients this might be a ticket whose
use is restricted by the contents becomes
cumbersome, and more automatic methods as described here are
necessary). The exchange of the
authorization data field, but which
lists no network addresses, together
with the session inter-realm keys (a separate key necessary to use may be
used for each direction) registers the ticket.

Ciphertext The output of an encryption function.
Encryption transforms plaintext into
ciphertext.

Client A process that makes use of a network ticket-granting service on behalf of
each realm as a user. Note that principal in some cases a Server may itself be a
client of some the other server (e.g. a
print server may be a client of a file
server).

Credentials realm. A ticket plus the secret session key
necessary client is then able
to successfully use that
ticket in an authentication exchange.

KDC Key Distribution Center, obtain a network ser-
vice that supplies tickets and temporary
session keys; or an instance of that
service or the 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 for the Authentication Server
(or service). The remote realm's ticket-
granting service from its local realm. When that ticket-granting
ticket portion is sometimes referred to
as used, the remote ticket-granting server (or ser-
vice).

Section 1.3. - 7 - Expires 15 October 1993

Version 5 - Revision 5.2

Kerberos Aside from the 3-headed dog guarding
Hades, service uses the name given inter-
realm key (which usually differs from its own normal TGS key) to Project
Athena's authentication service,
decrypt the
protocol used by that service, or ticket-granting ticket, and is thus certain that it was
issued by the
code used client's own TGS. Tickets issued by the remote ticket-
granting service will indicate to implement the authentica-
tion service.

Plaintext The input end-service that the client was
authenticated from another realm.

A realm is said to communicate with another realm if the two realms
share an encryption function inter-realm key, or if the output local realm shares an inter-realm
key with an intermediate realm that communicates with the remote
realm. An authentication path is the sequence of a decryption function.
Decryption transforms ciphertext into
plaintext.

Principal A uniquely named client or server
instance intermediate realms
that participates are transited in a network
communication.

Principal identifierThe name used communicating from one realm to uniquely identify each
different principal.

Seal To encipher a record containing several
fields in such another.

Realms are typically organized hierarchically. Each realm shares a way that the fields
cannot be individually replaced without
either knowledge of the encryption
key
or leaving evidence of tampering.

Secret with its parent and a different key An encryption with each child. If an
inter-realm key is not directly shared by a principal
and the KDC, distributed outside the
bounds of the system, with a long life-
time. In two realms, the case of
hierarchical organization allows an authentication path to be easily
constructed. If a human user's
principal, the secret key hierarchical organization is derived
from a password.

Server A particular Principal which provides a
resource not used, it may be
necessary to network clients.

Service A resource provided consult some database in order to network clients;
often provided by more than one server
(for example, remote file service).

Session key A temporary encryption key used construct an

Kohl & Neuman [Page 7]

RFC 1510 Kerberos September 1993

authentication path between
two principals, with a lifetime limited realms.

Although realms are typically hierarchical, intermediate realms may
be bypassed to the duration of a single login "ses-
sion".

Sub-session key A temporary encryption key used achieve cross-realm authentication through alternate
authentication paths (these might be established to make
communication between

Section 1.3. - 8 - Expires 15 October 1993

Version 5 - Revision 5.2 two principals, selected and exchanged
by realms more efficient). It is important
for the principals using end-service to know which realms were transited when deciding
how much faith to place in the session key,
and with authentication process. To facilitate
this decision, a lifetime limited to field in each ticket contains the dura-
tion names of a single association.

Ticket A record the
realms that helps a client authenti-
cate itself to a server; it contains were involved in authenticating the
client's identity, a session key, client.

1.2. Environmental assumptions

Kerberos imposes a
timestamp, and other information, all
sealed using few assumptions on the server's secret key.
It only serves to authenticate a client
when presented along environment in which it can
properly function:

+ "Denial of service" attacks are not solved with a fresh
Authenticator.

2. Ticket flag uses Kerberos. There
are places in these protocols where an intruder intruder can
prevent an application from participating in the proper
authentication steps. Detection and requests

Each Kerberos ticket contains a set solution of such attacks
(some of flags which are used can appear to indicate various attributes of that ticket. Most flags
may be requested by a client when the ticket is obtained;
some are automatically turned on not-uncommon "normal" failure
modes for the system) is usually best left to the human
administrators and off by users.

+ Principals must keep their secret keys secret. If an intruder
somehow steals a Kerberos
server principal's key, it will be able to masquerade
as required. The following sections explain what that principal or impersonate any server to the
various flags mean, and gives examples of reasons legitimate
principal.

+ "Password guessing" attacks are not solved by Kerberos. If a
user chooses a poor password, it is possible for an attacker to use
such
successfully mount an offline dictionary attack by repeatedly
attempting to decrypt, with successive entries from a flag.

2.1. Initial and pre-authenticated tickets

The INITIAL flag indicates that
dictionary, messages obtained which are encrypted under a ticket was issued
using key
derived from the AS protocol and not issued based user's password.

+ Each host on the network must have a ticket-
granting ticket. Application servers that want clock which is "loosely
synchronized" to require the knowledge time 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 thus be assured that the client's
key was recently presented other hosts; this
synchronization is used to reduce the bookkeeping needs of
application client. servers when they do replay detection. The PRE-AUTHENT and HW-AUTHENT flags provide addition
information about the initial authentication, regardless degree
of
whether the current ticket was issued directly (in which
case INITIAL will also "looseness" can be set) or issued configured on the basis of a
ticket-granting ticket (in which case per-server basis. If the INITIAL flag is
clear, but the PRE-AUTHENT and HW-AUTHENT flags
clocks are carried
forward from synchronized over the ticket-granting ticket).

2.2. Invalid tickets

The INVALID flag indicates that a ticket is invalid.
Application servers must reject tickets which have this flag
set. A postdated ticket will usually be issued in this
form. Invalid tickets network, the clock
synchronization protocol must itself be validated by the KDC before
use, by presenting them to the KDC in secured from network
attackers.

+ Principal identifiers are not recycled on a TGS request with the
VALIDATE option specified. The KDC short-term basis. A
typical mode of access control will only validate tick-
ets after their starttime has passed. The validation is
required so that postdated tickets which have been stolen
before their starttime can be rendered permanently invalid

Section 2.2. - 9 - Expires 15 October 1993

Version 5 - Revision 5.2

(through a hot-list mechanism).

2.3. Renewable tickets

Applications may desire use access control lists
(ACLs) to hold tickets which can be
valid for long periods of time. However, this can expose
their credentials grant permissions to potential theft particular principals. If a

Kohl & Neuman [Page 8]

RFC 1510 Kerberos September 1993

stale ACL entry remains for equally long
periods, a deleted principal and those stolen credentials would be valid until the expiration time of
principal identifier is reused, the ticket(s). Simply using short-
lived tickets and obtaining new ones periodically would
require principal will inherit
rights specified in the client to have long-term access to its secret
key, an even greater risk. Renewable tickets can be used to
mitigate stale ACL entry. By not re-using
principal identifiers, the consequences danger of theft. Renewable tickets have
two "expiration times": the first inadvertent access is when the current
instance
removed.

1.3. Glossary of the ticket expires, and the second terms

Below 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 list of terms used throughout this document.

Authentication Verifying the KDC request. The KDC will issue claimed identity of a
new ticket with
principal.

Authentication header A record containing a new session key Ticket and an
Authenticator to be presented to a later expiration
time. All other fields
server as part of the ticket are left unmodified by
the renewal authentication
process. When

Authentication path A sequence of intermediate realms transited
in the latest permissible expiration
time arrives, 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 ticket expires permanently. At each
renewal, session key known only by the KDC
client and server.

Authorization The process of determining whether a
client may consult use a hot-list to determine if service, which objects
the
ticket had been reported stolen since its last renewal; it
will refuse client is allowed to renew such stolen tickets, access, and thus the
usable lifetime
type of stolen tickets is reduced.

The RENEWABLE flag in 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 normally only inter-
preted restricted 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 wish to disallow renewable tickets.

If a renewable ticket is not renewed by its expiration
time, contents of the KDC will not renew
authorization data field, but which
lists no network addresses, together
with the session key necessary to use
the ticket.

Kohl & Neuman [Page 9]

RFC 1510 Kerberos September 1993

Ciphertext The RENEWABLE flag
is reset by default, but 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 request it be set by
setting a client of a file
server).

Credentials A ticket plus the RENEWABLE option secret session key
necessary to successfully use that
ticket in an authentication exchange.

KDC Key Distribution Center, a network service
that supplies tickets and temporary
session keys; or an instance of that
service or the KRB_AS_REQ message. If host on which it runs.
The KDC services both initial ticket and
ticket-granting ticket requests. The
initial ticket portion is set, then the renew-till field in sometimes
referred to as the Authentication Server
(or service). The ticket-granting
ticket contains portion is sometimes referred to
as the time after which ticket-granting server (or service).

Kerberos Aside from 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 3-headed dog guarding
Hades, the name given to be valid at Project
Athena's authentication service, the time
protocol used by that service, or the batch job is ser-
viced. However, it is dangerous
code used 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 implement the KDC at job submission time, but authentication
service.

Plaintext The input to
leave them "dormant" until they are activated and validated
by a further request of an encryption function or
the KDC. If output of a ticket theft were
reported decryption function.
Decryption transforms ciphertext into
plaintext.

Principal A uniquely named client or server
instance that participates in the interim, the KDC would refuse to validate
the ticket, and the thief would be foiled.

Section 2.4. - 10 - Expires 15 October a network
communication.

Kohl & Neuman [Page 10]

RFC 1510 Kerberos September 1993

Version 5 - Revision 5.2

Principal identifier 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 name used to uniquely identify each
different principal.

Seal To encipher a
ticket-granting ticket record containing several
fields in order to issue such a postdated ticket
based on way that the presented ticket. It is reset by default; it
may fields
cannot be requested individually replaced without
either knowledge of the encryption key
or leaving evidence of tampering.

Secret key An encryption key shared by a client by setting principal
and the ALLOW-POSTDATE
option in KDC, distributed outside the KRB_AS_REQ message. This flag does not allow
a client to obtain a postdated ticket-granting ticket; post-
dated ticket-granting tickets can only by obtained by
requesting
bounds of the postdating in system, with a long lifetime.
In the KRB_AS_REQ message. The
life (endtime-starttime) case of a postdated ticket will be the
remaining life of the ticket-granting ticket at the time of
the request, unless human user's
principal, the RENEWABLE option secret key is also set, in
which case it can be the full life (endtime-starttime) of
the ticket-granting ticket. The KDC may limit how far in
the future derived
from a ticket may be postdated.

The POSTDATED flag indicates that password.

Server A particular Principal which provides a ticket has been
postdated. The application server can check the authtime
field in the ticket
resource to see when the original authentication
occurred. Some services may choose network clients.

Service A resource provided to reject postdated
tickets, or they may only accept them within 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 certain
period after the original authentication. When lifetime limited
to the KDC
issues duration of a POSTDATED ticket, it will also be marked as
INVALID, so that the application client must present single login "session".

Sub-session key A temporary encryption key used between
two principals, selected and exchanged
by the
ticket to principals using the KDC to be validated before use.

2.5. Proxiable session key,
and proxy tickets

At times it may be necessary for a principal to allow with a
service to perform an operation on its behalf. The service
must be able lifetime limited to take on the identity duration
of the client, but only
for a particular purpose. single association.

Ticket A principal can allow record that helps a service client authenticate
itself to take on the principal's identity for a particular purpose
by granting server; it contains the
client's identity, a proxy.

The PROXIABLE flag in session key, a ticket is normally only inter-
preted by
timestamp, and other information, all
sealed using the ticket-granting service. server's secret key.
It can be ignored by
application servers. When set, this flag tells the ticket-
granting server that it is OK only serves to issue a new ticket (but not authenticate a ticket-granting ticket) client
when presented along with a different network address
based on this ticket. This fresh
Authenticator.

Kohl & Neuman [Page 11]

RFC 1510 Kerberos September 1993

2. Ticket flag is uses and requests

Each Kerberos ticket contains a set of flags which are used to
indicate various attributes of that ticket. Most flags may be
requested by default.

This flag allows a client to pass a proxy to 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 gives
examples of reasons to perform use such a remote request on its behalf, e.g. flag.

2.1. Initial and pre-authenticated tickets

The INITIAL flag indicates that a print ser-
vice client can give ticket was issued using the print server AS
protocol and not issued based on a proxy ticket-granting ticket.
Application servers that want to access require the knowledge of a client's files on
secret key (e.g., a particular file server passwordchanging program) can insist that this
flag be set in order to
satisfy a print request.

In order any tickets they accept, and thus be assured that the
client's key was recently presented to complicate the use application client.

The PRE-AUTHENT and HW-AUTHENT flags provide addition information
about the initial authentication, regardless of stolen credentials,
Kerberos tickets are usually valid from only those network
addresses specifically included in whether the ticket[4]. For this
__________________________

[4] It is permissible to request current
ticket was issued directly (in which case INITIAL will also be set)
or issue tickets with

Section 2.5. - 11 - Expires 15 October 1993

Version 5 - Revision 5.2

reason, a client wishing to grant a proxy must request issued on the basis of a new ticket-granting ticket valid for (in which case the network address of
INITIAL flag is clear, but the service to be
granted PRE-AUTHENT and HW-AUTHENT flags are
carried forward from the proxy. ticket-granting ticket).

2.2. Invalid tickets

The PROXY INVALID flag is set in indicates that a ticket by the TGS when it
issues a proxy ticket. is invalid. Application
servers may check must reject tickets which have this flag and require additional authentication from the agent
presenting the proxy set. A postdated
ticket will usually be issued in order to provide an audit trail.

2.6. Forwardable this form. Invalid tickets

Authentication forwarding is an instance of the proxy
case where the service is granted complete use of the
client's identity. An example where it might must be used is
when a user logs in to a remote system and wants authentica-
tion
validated by the KDC before use, by presenting them to work from that system as if the login were local.

The FORWARDABLE flag KDC in a ticket is normally only
interpreted by
TGS request with the ticket-granting service. It can be
ignored by application servers. VALIDATE option specified. The FORWARDABLE flag KDC will only
validate tickets after their starttime has an
interpretation similar to passed. The validation is
required so that of the PROXIABLE flag, except
ticket-granting postdated tickets may also which have been stolen before
their starttime can be issued with different
network addresses. This flag is reset by default, but users rendered permanently invalid (through a hot-
list mechanism).

2.3. Renewable tickets

Applications may request that it desire to hold tickets which can be set by setting the FORWARDABLE option
in the AS request when they request valid for long
periods of time. However, this can expose their initial ticket-
granting ticket.

This flag allows credentials to
potential theft for authentication forwarding without
requiring equally long periods, and those stolen
credentials would be valid until the user to enter a password again. If expiration time of the flag
is not set, then authentication forwarding is not permitted,
but
ticket(s). Simply using shortlived tickets and obtaining new ones
periodically would require the same end result client to have long-term access to its
secret key, an even greater risk. Renewable tickets can still be achieved if used to
mitigate the user
engages in consequences of theft. Renewable tickets have two
"expiration times": the AS exchange with first is when the requested network
addresses current instance of the

Kohl & Neuman [Page 12]

RFC 1510 Kerberos September 1993

ticket expires, and supplies a password.

The FORWARDED flag the second is set by the TGS when a latest permissible value for an
individual expiration time. An application client
presents must periodically
(i.e., before it expires) present a renewable ticket to the KDC, with
the FORWARDABLE flag set and requests
it be RENEW option set by specifying in the FORWARDED KDC option request. The KDC will issue a new
ticket with a new session key and supply-
ing a set later expiration time. All other
fields 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 wish to process FORWARDED
tickets differently than non-FORWARDED tickets.

2.7. Other KDC options

There ticket are two additional options which may be set in a
client's request of left unmodified by the KDC. The RENEWABLE-OK option indi-
cates that renewal process.
When the latest permissible expiration time arrives, the client will accept a renewable ticket if
expires permanently. At each renewal, the KDC may consult a hot-list
to determine if the ticket with had been reported stolen since its last
renewal; it will refuse to renew such stolen tickets, and thus the requested life cannot otherwise be provided.
If
usable lifetime of stolen tickets is reduced.

The RENEWABLE flag in a ticket with is normally only interpreted by the requested life cannot
ticket-granting service (discussed below in section 3.3). It can
usually be provided, then
the KDC ignored by application servers. However, some
particularly careful application servers may issue wish to disallow
renewable tickets.

If a renewable ticket with a renew-till equal
__________________________
no network addresses specified, but we do is not recommend
it.

Section 2.7. - 12 - Expires 15 October 1993

Version 5 - Revision 5.2

to renewed by its expiration time, the KDC
will not renew the requested endtime. ticket. The value of the renew-till
field RENEWABLE flag is reset by default,
but a client may still request it be adjusted by site-determined limits or
limits imposed set by setting the individual principal or server.

The ENC-TKT-IN-SKEY RENEWABLE option
in the KRB_AS_REQ message. If it is honored only by set, then the
ticket-granting service. It indicates that renew-till field
in the to-be-issued ticket for contains the end server is to be encrypted in the session
key from time after which the additional ticket-granting ticket provided with
the request. See section 3.3.3 for specific details.

__________________________

[5] The password-changing request must may not be honored
unless
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 requester can provide time the old password (the
user's current secret key). Otherwise, batch job is serviced. However, it would is dangerous to
hold valid tickets in a batch queue, since they will be
possible for someone on-line
longer and more prone to walk up theft. Postdated tickets provide a way to an unattended ses-
sion
obtain these tickets from the KDC at job submission time, but to
leave them "dormant" until they are activated and change another user's password.
[6] To authenticate validated by a user logging on to
further request of the KDC. If a local sys-
tem, ticket theft were reported in the credentials obtained
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 AS exchange may
first
ticket-granting service. It can be used ignored by application servers.
This flag must be set in a TGS exchange ticket-granting ticket in order to obtain credentials
for issue a local server. Those credentials must then
postdated ticket based on the presented ticket. It is reset by
default; it may be
verified requested by a client by setting the local server through successful comple-
tion of ALLOW-
POSTDATE option in the Client/Server exchange.

Section 3.1. - 13 - Expires 15 October 1993

Version 5 - Revision 5.2

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 usually in-
itiated by message. This flag does not allow
a client when it wishes to obtain authentication
credentials for a given server but currently holds no
credentials. The client's secret key is used for encryption
and decryption. This exchange is typically used at postdated ticket-granting ticket; postdated
ticket-granting tickets can only by obtained by requesting the
postdating in the ini-
tiation KRB_AS_REQ message. The life (endtime-starttime)
of a login session, to obtain credentials for a
Ticket-Granting Server, which postdated ticket will subsequently be used to
obtain credentials for other servers (see section 3.3)
without requiring further use the remaining life of the client's secret key.
This exchange ticket-

Kohl & Neuman [Page 13]

RFC 1510 Kerberos September 1993

granting ticket at the time of the request, unless the RENEWABLE
option is also used to request credentials for ser-
vices set, in which must not case it can be mediated through the Ticket-Granting
Service, but rather require a principal's secret key, such
as the password-changing service[5]. This exchange does not
by itself provide any assurance full life (endtime-
starttime) of the ticket-granting ticket. The KDC may limit how far
in the identity of the
user[6]. future a ticket may be postdated.

The exchange consists of two messages: KRB_AS_REQ from POSTDATED flag indicates that a ticket has been postdated. The
application server can check the client authtime field in the ticket to Kerberos, and KRB_AS_REP or KRB_ERROR in
reply. The formats for these messages are described in sec-
tions 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 see
when the server for which it is
requesting credentials. The response, KRB_AS_REP, contains original authentication occurred. Some services may choose
to reject postdated tickets, or they may only accept them within a ticket for
certain period after the client to present to original authentication. When the server, and KDC issues
a ses-
sion key that POSTDATED ticket, it will also be shared by marked as INVALID, so that the
application client and must present the server.
The session key and additional information are encrypted in ticket to the client's secret key. The KRB_AS_REP message contains
information which can be used KDC to detect replays, be validated
before use.

2.5. Proxiable and to
associate proxy tickets

At times it with the message may be necessary for a principal to which it replies. Various
errors can occur; these are indicated by allow a service to
perform an error response
(KRB_ERROR) instead of the KRB_AS_REP response. The error
message is not encrypted. operation on its behalf. The KRB_ERROR message also con-
tains information which can service must be used able to associate it with take
on the
message identity of the client, but only for a particular purpose. A
principal can allow a service to which take on the principal's identity for
a particular purpose by granting it replies. a proxy.

The lack of encryption PROXIABLE flag in a ticket is normally only interpreted by the
KRB_ERROR message precludes
ticket-granting service. It can be ignored by application servers.
When set, this flag tells the ability to detect replays or
fabrications of such messages.

Section 3.1. - 14 - Expires 15 October 1993

Version 5 - Revision 5.2

In the normal case the authentication ticket-granting server does not
know whether the client that it is actually the principal named in
the request. It simply sends OK to
issue a reply without knowing or
caring whether they are the same. new ticket (but not a ticket-granting ticket) with a
different network address based on this ticket. This flag is acceptable
because nobody but the principal whose identity was given in
the set by
default.

This flag allows a client to pass a proxy to a server to perform a
remote request will be able on its behalf, e.g., a print service client can give
the print server a proxy to use access the reply. Its critical
information is encrypted client's files on a particular
file server in that principal's key. The ini-
tial request supports an optional field that can be used order to
pass additional information that might be needed for satisfy a print request.

In order to complicate the
initial exchange. This field may be used for pre-
authentication if desired, but use of stolen credentials, Kerberos
tickets are usually valid from only those network addresses
specifically included in the mechanism ticket (It is permissible to request or
issue tickets with no network addresses specified, but we do not
currently specified.

3.1.1. Generation of KRB_AS_REQ message

The
recommend it). For this reason, a client may specify wishing to grant a number proxy
must request a new ticket valid for the network address of options in the ini-
tial request. Among these options are whether pre-
authentication is
service to be performed; whether granted the requested
ticket proxy.

The PROXY flag 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 set 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; see sec-
tion 4). See section A.1 for pseudocode.

The client prepares the KRB_AS_REQ message and sends TGS when it
to issues a
proxy ticket. Application servers may check this flag and require
additional authentication from the KDC.

3.1.2. Receipt of KRB_AS_REQ message

If all goes well, processing agent presenting the KRB_AS_REQ message
will result proxy in
order to provide an audit trail.

Kohl & Neuman [Page 14]

RFC 1510 Kerberos September 1993

2.6. Forwardable tickets

Authentication forwarding is an instance of the creation proxy case where the
service is granted complete use of a ticket for the client client's identity. An example
where it might be used is when a user logs in to
present a remote system and
wants authentication to work from that system as if the server. login were
local.

The format for the FORWARDABLE flag in a ticket is
described in section 5.3.1. The contents of normally only interpreted by the ticket are
determined as follows.

3.1.3. Generation of KRB_AS_REP message
ticket-granting service. It can be ignored by application servers.
The authentication server looks up the client and
server principals named in the KRB_AS_REQ in its database,
extracting their respective keys. If required, the server
pre-authenticates the request, and if the pre-authentication
check fails, FORWARDABLE flag has an error message with interpretation similar to that of the code
KDC_ERR_PREAUTH_FAILED is returned. If the server cannot
accommodate the requested encryption type, an error message
with code KDC_ERR_ETYPE_NOSUPP is returned. Otherwise it
generates a "random" session key[7].
__________________________

[7] "Random" means that, among other things, it should
PROXIABLE flag, except ticket-granting tickets may also be impossible to guess the next session key based on
knowledge of past session keys. issued
with different network addresses. This can only be
achieved in a pseudo-random number generator if it flag is
based on cryptographic principles. It would reset by default, but
users may request that it be more

Section 3.1.3. - 15 - Expires 15 October 1993

Version 5 - Revision 5.2

If set by setting the requested start time is absent or indicates a
time FORWARDABLE option in
the past, then the start time of AS request when they request their initial ticket-granting
ticket.

This flag allows for authentication forwarding without requiring the ticket is set
user to the authentication server's current time. If it indicates enter a time in the future, but password again. If the POSTDATED option has flag is not been
specified, set, then the error KDC_ERR_CANNOT_POSTDATE
authentication forwarding is
returned. Otherwise not permitted, but the requested start time is checked
against same end result
can still be achieved if the policy of user engages in the local realm (the administrator
might decide to prohibit certain types or ranges of post-
dated tickets), and if acceptable, AS exchange with the ticket's start time
is set as
requested network addresses and the INVALID supplies a password.

The FORWARDED flag is set in by the new
ticket. The postdated TGS when a client presents a ticket must
with the FORWARDABLE flag set and requests it be validated before use set by
presenting it to specifying
the FORWARDED KDC after the start time has been
reached.

The expiration time of the ticket will be option and supplying a set to the minimum of addresses for the following:

+The expiration time (endtime) requested new
ticket. It is also set in all tickets issued based on tickets with
the KRB_AS_REQ
message.

+The ticket's start time plus FORWARDED flag set. Application servers may wish to process
FORWARDED tickets differently than non-FORWARDED tickets.

2.7. Other KDC options

There are two additional options which may be set in a client's
request of the maximum allowable lifetime
associated with KDC. The RENEWABLE-OK option indicates that the
client principal (the authentication
server's database includes will accept a renewable ticket if a maximum ticket lifetime field
in each principal's record; see section 4).

+The ticket's start time plus the maximum allowable lifetime
associated with the server principal.

+The ticket's start time plus the maximum lifetime set by
the policy of the local realm. requested
life cannot otherwise be provided. If a ticket with the requested expiration time minus
life cannot be provided, then the start time
(as determined above) is less than KDC may issue a site-determined minimum
lifetime, an error message renewable ticket
with code KDC_ERR_NEVER_VALID is
returned. If a renew-till equal to the the requested expiration time for endtime. The value of
the ticket
exceeds what was determined as above, and if renew-till field may still be adjusted by site-determined limits
or limits imposed by the
"RENEWABLE-OK" individual principal or server.

The ENC-TKT-IN-SKEY option was requested, then the "RENEWABLE"
flag is set in honored only by the new ticket, and ticket-granting
service. It indicates that the renew-till value to-be-issued ticket for the end
server is
set as if the "RENEWABLE" option were requested (the field
and option names are described fully to be encrypted in the session key from the additional
ticket-granting ticket provided with the request. See section 5.4.1).

__________________________
desirable to use a truly random number generator, such
as one based on measurements of random physical
phenomena.

Section 3.1.3. - 16 - Expires 15 October 3.3.3
for specific details.

Kohl & Neuman [Page 15]

RFC 1510 Kerberos September 1993

Version 5 - Revision 5.2

3. Message Exchanges

The following sections describe the RENEWABLE option has been requested 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 if 5.4.2
KRB_ERROR 5.9.1

The Authentication Service (AS) Exchange between the
RENEWABLE-OK option has been set client and the
Kerberos Authentication Server is usually initiated by a renewable ticket client when
it wishes to obtain authentication credentials for a given server but
currently holds no credentials. 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 issued, then the renew-till field is set used to the
minimum of:

+Its requested value.

+The start time obtain
credentials for other servers (see section 3.3) without requiring
further use of the ticket plus client's secret key. This exchange is also used
to request credentials for services which must not be mediated
through the minimum of Ticket-Granting Service, but rather require a principal's
secret key, such as the two
maximum renewable lifetimes associated with the principals'
database entries.

+The start time of password-changing service. (The password-
changing request must not be honored unless the ticket plus requester can provide
the maximum renewable
lifetime set old password (the user's current secret key). Otherwise, it
would be possible for someone to walk up to an unattended session and
change another user's password.) This exchange does not by the policy of the local realm.

The flags field itself
provide any assurance of the new ticket will have the follow-
ing options set if they have been requested and if the pol-
icy identity of the user. (To
authenticate a user logging on to a local realm allows: FORWARDABLE, MAY-POSTDATE,
POSTDATED, PROXIABLE, RENEWABLE. If system, the new ticket is post-
dated (the start time is credentials
obtained in the future), its INVALID flag
will also AS exchange may first be set.

If all used in a TGS exchange to
obtain credentials for a local server. Those credentials must then
be verified by the local server through successful completion of the above succeed,
Client/Server exchange.)

The exchange consists of two messages: KRB_AS_REQ from the server formats a client to
Kerberos, and KRB_AS_REP message (see section 5.4.2), copying the
addresses 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 into the caddr of request, the response,
placing any required pre-authentication data into client sends (in cleartext) its own identity and
the padata identity of the server for which it is requesting credentials.
The response, and encrypts KRB_AS_REP, contains a ticket for the ciphertext part in client to present
to the
client's server, and a session key using that will be shared by the requested encryption method, client
and
sends it to the client. See section A.2 for pseudocode.

3.1.4. Generation of KRB_ERROR server. The session key and additional information are
encrypted in the client's secret key. The KRB_AS_REP message

Several errors
contains information which can occur, be used to detect replays, and the Authentication Server
responds by returning an error message, KRB_ERROR, to the
client,

Kohl & Neuman [Page 16]

RFC 1510 Kerberos September 1993

associate it with the error-code and e-text fields set to
appropriate values. The error message contents and details to which it replies. Various errors
can occur; these are described in Section 5.9.1.

3.1.5. Receipt indicated by an error response (KRB_ERROR)
instead of KRB_AS_REP message

If the reply KRB_AS_REP response. The error 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 not
encrypted. The KRB_ERROR message also contains information which can
be used to derive associate it with the proper secret key message to decrypt the message. which it replies. The client
decrypts
lack of encryption in the encrypted part KRB_ERROR message precludes the ability to
detect replays or fabrications of such messages.

In the response using its secret
key, verifies that normal case the nonce in authentication server does not know whether
the encrypted part matches client is actually the nonce it supplied principal named in its request (to detect replays). the request. It also verifies that simply
sends a reply without knowing or caring whether they are the sname and srealm in same.
This is acceptable because nobody but the response
match those principal whose identity
was given in the request, and that request will be able to use the host address field
is also correct. It then stores the ticket, session key,
start and expiration times, and other reply. Its critical
information for later
use. is encrypted in that principal's key. The key-expiration initial
request supports an optional field from the encrypted part of that can be used to pass
additional information that might be needed for the response initial exchange.
This field may be checked to notify used for preauthentication if desired, but the user
mechanism is not currently specified.

3.1.1. Generation of impending
key expiration (the KRB_AS_REQ message

The client program could then suggest

Section 3.1.5. - 17 - Expires 15 October 1993

Version 5 - Revision 5.2

remedial action, such as may specify a password change). See section
A.3 for pseudocode.

Proper decryption number of options in the KRB_AS_REP message initial request.
Among these options are whether preauthentication is not suf-
ficient to verify be performed;
whether the identity 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 user; requested ticket expiration
date cannot be satisfied by a nonrenewable ticket (due to
configuration constraints; see section 4). See section A.1 for
pseudocode.

The client prepares the user KRB_AS_REQ message and an
attacker could cooperate sends it to generate a KRB_AS_REP format
message which decrypts properly but is not from the proper KDC.

3.1.2. Receipt of KRB_AS_REQ message

If all goes well, processing the host wishes to verify KRB_AS_REQ message will result in
the identity creation of a ticket for the user,
it must require the user client to present application credentials
which can be verified using a securely-stored secret key.
If those credentials can be verified, then the identity of to the user can be assured.

3.1.6. Receipt of KRB_ERROR message

If server.
The format for the reply message type ticket is KRB_ERROR, then described in section 5.3.1. The
contents of the client
interprets it as an error and performs whatever
application-specific tasks ticket are necessary to recover.

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 determined as follows.

3.1.3. Generation of KRB_AS_REP message

The client/server authentication (CS) exchange is used
by network applications to authenticate server looks up the client to the
server and vice versa. The client must have already
acquired credentials for server principals
named in the KRB_AS_REQ in its database, extracting their respective
keys. If required, the server using pre-authenticates the AS or TGS
exchange.

3.2.1. The KRB_AP_REQ message

The KRB_AP_REQ contains authentication information
which should be part of request, and if
the first message in an authenti-
cated transaction. It contains a ticket, pre-authentication check fails, an authenticator,
and some additional bookkeeping information (see section
5.5.1 for error message with the exact format). The ticket by itself code
KDC_ERR_PREAUTH_FAILED is insuf-
ficient to authenticate a client, since tickets are passed
across returned. If the network in cleartext[8], so server cannot accommodate
the authenticator requested encryption type, an error message with code

Kohl & Neuman [Page 17]

RFC 1510 Kerberos September 1993

KDC_ERR_ETYPE_NOSUPP is
used to prevent invalid replay of tickets by proving returned. Otherwise it generates a "random"
session key ("Random" means that, among other things, it should be
impossible to guess the
server that the client knows the next session key based on knowledge of the ticket
and thus is entitled to use it. The KRB_AP_REQ message is
referred to elsewhere as the "authentication header."

__________________________
[8] Tickets contain both an encrypted and unencrypted
portion, so cleartext here refers to the entire unit,
which past
session keys. This can only be copied from one message and replayed achieved in
another without any a pseudo-random number
generator if it is based on cryptographic skill.

Section 3.2.1. - 18 - Expires 15 October 1993

Version 5 - Revision 5.2

3.2.2. Generation of principles. It would be
more desirable to use a KRB_AP_REQ message

When truly random number generator, such as one
based on measurements of random physical phenomena.).

If the requested start time is absent or indicates a client wishes time in the
past, then the start time of the ticket is set to initiate the authentication to a
server,
server's current time. If it obtains (either through indicates a credentials cache, time in the
AS exchange, future, but the
POSTDATED option has not been specified, then the error
KDC_ERR_CANNOT_POSTDATE is returned. Otherwise the requested start
time is checked against the policy of the local realm (the
administrator might decide to prohibit certain types or ranges of
postdated tickets), and if acceptable, the TGS exchange) a ticket ticket's start time is set
as requested and session key
for the desired service. INVALID flag is set in the new ticket. The client may re-use any tickets
postdated ticket must be validated before use by presenting it holds until they expire. to the
KDC after the start time has been reached.

The client then constructs a
new Authenticator from expiration time of the ticket will be set to the system time, its name, and
optionally 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 minimum of the
following:

+The expiration time (endtime) requested in negotiations for a
session key unique to this particular session. Authentica-
tors may not be re-used and will be rejected if replayed to
a server[9]. 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 the KRB_AS_REQ
message.

+The ticket's start time plus the maximum allowable lifetime
associated with other
sequence numbers in use.

The client may indicate a requirement of mutual authen-
tication or the use of client principal (the authentication
server's database includes a session-key based maximum ticket by setting
the appropriate flag(s) in the ap-options lifetime field of the mes-
sage.

The Authenticator is encrypted
in each principal's record; see section 4).

+The ticket's start time plus the session key and
combined maximum allowable lifetime
associated with the ticket to form server principal.

+The ticket's start time plus the KRB_AP_REQ message
which is then sent to maximum lifetime set by
the end server along with any addi-
tional application-specific information. See section A.9
for pseudocode.

3.2.3. Receipt policy of KRB_AP_REQ message

Authentication is based on the server's current time of
day (clocks must be loosely synchronized), local realm.

If the authentica-
tor, and requested expiration time minus the ticket. Several errors are possible. If start time (as determined
above) is less than a site-determined minimum lifetime, an error occurs, the server
message with code KDC_ERR_NEVER_VALID is expected to reply to returned. If the client
with a KRB_ERROR message. This message may be encapsulated
in requested
expiration time for the application protocol ticket exceeds what was determined as above,
and if its "raw" form is not accept-
able 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 "RENEWABLE-OK" option was requested, then the message type "RENEWABLE"
flag is not KRB_AP_REQ, the
server returns the KRB_AP_ERR_MSG_TYPE error. If the key
version indicated by the Ticket set in the KRB_AP_REQ is not one
the server can use (e.g., it indicates an old key, new ticket, and the
server no longer possesses a copy of the old key), the
KRB_AP_ERR_BADKEYVER error renew-till value is returned. set as if
the "RENEWABLE" option were requested (the field and option names are
described fully in section 5.4.1). If the USE-
__________________________

[9] Note that this can make applications based on un-
reliable transports difficult to code correctly, RENEWABLE option has been
requested or if the
transport might deliver duplicated messages. In such
cases, RENEWABLE-OK option has been set and a new authenticator must renewable
ticket is to be generated for each
retry.

Section 3.2.3. - 19 - Expires 15 October 1993

Version 5 - Revision 5.2

SESSION-KEY flag issued, then the renew-till field is set in the ap-options field, it indi-
cates to the server that
minimum of:

Kohl & Neuman [Page 18]

RFC 1510 Kerberos September 1993

+Its requested value.

+The start time of the ticket is encrypted in the ses-
sion key from plus the server's ticket-granting ticket rather
than its secret key[10]. Since it is possible for minimum of the
server to be registered in multiple realms, two
maximum renewable lifetimes associated with different
keys in each, the srealm field in the unencrypted portion principals'
database entries.

+The start time of the ticket in plus the KRB_AP_REQ is used to specify which secret
key maximum renewable
lifetime set by the server should use to decrypt that ticket. policy of the local realm.

The
KRB_AP_ERR_NOKEY error code is returned if flags field of the server
doesn't new ticket will have the proper key to decipher following options set
if they have been requested and if the ticket.

The policy of the local realm
allows: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE.
If the new ticket is decrypted using postdated (the start time is in the version future), its
INVALID flag will also be set.

If all of the
server's key specified by the ticket. If above succeed, the decryption
routines detect server formats a modification KRB_AS_REP message
(see section 5.4.2), copying the addresses in the request into the
caddr of the ticket (each encryp-
tion system must provide safeguards to detect modified
ciphertext; see section 6), response, placing any required pre-authentication data
into the KRB_AP_ERR_BAD_INTEGRITY
error is returned (chances are good that different keys were
used to encrypt padata of the response, and decrypt).

The authenticator is decrypted using encrypts the session ciphertext part in
the client's key
extracted from using the decrypted ticket. If decryption shows requested encryption method, and sends it
to have been modified, the KRB_AP_ERR_BAD_INTEGRITY error is
returned. The name and realm client. See section A.2 for pseudocode.

3.1.4. Generation of KRB_ERROR message

Several errors can occur, and the client from Authentication Server responds by
returning an error message, KRB_ERROR, to the ticket
are compared against client, with the same
error-code and e-text fields set to appropriate values. The error
message contents and details are described in the authenticator. Section 5.9.1.

3.1.5. Receipt of KRB_AS_REP message

If they don't match, the KRB_AP_ERR_BADMATCH error is
returned (they might not match, for example, if reply message type is KRB_AS_REP, then the wrong
session key was used to encrypt client verifies
that the authenticator). The
addresses cname and crealm fields in the ticket (if any) are then searched for an
address matching the operating-system reported address cleartext portion of the client. If no
reply 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. what it requested. If any padata fields are present,
they may be used to derive the local (server) time and proper secret key to decrypt the
message. The client time in decrypts the
authenticator differ by more than encrypted part of the allowable clock skew
(e.g., 5 minutes), response
using its secret key, verifies that the KRB_AP_ERR_SKEW error is returned.
If nonce in the server name, along with encrypted part
matches the client name, time nonce it supplied in its request (to detect replays). It
also verifies that the sname and
microsecond fields from srealm in the Authenticator response match any
recently-seen such tuples, the KRB_AP_ERR_REPEAT error is
returned[11]. The server must remember any authenticator
presented within those
in the allowable clock skew, so request, and that a replay
attempt is guaranteed to fail. If a server loses track of
any authenticator presented within the allowable clock skew,
__________________________

[10] This host address field is used for user-to-user authentication as
described in [6].
[11] Note that also correct. It
then stores the rejection here is restricted to au-
thenticators ticket, session key, start and expiration times, and
other information for later use. The key-expiration field from the same principal
encrypted part of the response may be checked to notify the same
server. Other user of
impending key expiration (the client principals communicating with program could then suggest
remedial action, such as a password change). See section A.3 for
pseudocode.

Proper decryption of the
same server principal should KRB_AS_REP message is not be have their authen-
ticators rejected if the time and microsecond fields
happen sufficient to match some other client's authenticator.

Section 3.2.3. - 20 - Expires 15 October

Kohl & Neuman [Page 19]

RFC 1510 Kerberos September 1993

Version 5 - Revision 5.2

it must reject all requests until

verify the clock skew interval
has passed. This assures that any lost or re-played authen-
ticators will fall outside identity of the allowable clock skew user; the user and can
no longer be successfully replayed (If this is not done, an attacker could conceivably record the ticket and authentica-
tor sent over the network
cooperate to generate a server, then disable the
client's host, pose as KRB_AS_REP format message which decrypts
properly but is not from the disabled host, and replay proper KDC. If the
ticket and authenticator host wishes to subvert the authentication.).
If a sequence number is provided in
verify the authenticator, identity of the
server saves user, it for later use in processing KRB_SAFE and/or
KRB_PRIV messages. If a subkey is present, must require the server
either saves it for later use or uses it to help generate
its own choice for a subkey user to present
application credentials which can be returned in verified using a KRB_AP_REP
message.

The server computes securely-stored
secret key. If those credentials can be verified, then the age identity
of the ticket: local
(server) time minus the start time inside the Ticket. user can be assured.

3.1.6. Receipt of KRB_ERROR message

If the start time reply message type is later than KRB_ERROR, then the current time client interprets it
as an error and performs whatever application-specific tasks are
necessary to recover.

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 more than network
applications to authenticate the allowable clock skew client to the server and vice versa.
The client must have already acquired credentials for the server
using the AS or if TGS exchange.

3.2.1. The KRB_AP_REQ message

The KRB_AP_REQ contains authentication information which should be
part of the INVALID flag is set first message in
the an authenticated transaction. It
contains a ticket, an authenticator, and some additional bookkeeping
information (see section 5.5.1 for the KRB_AP_ERR_TKT_NYV error exact format). The ticket by
itself is returned. Oth-
erwise, if insufficient to authenticate a client, since tickets are
passed across the current time is later than end time by more
than network in cleartext(Tickets contain both an
encrypted and unencrypted portion, so cleartext here refers to the allowable clock skew,
entire unit, which can be copied from one message and replayed in
another without any cryptographic skill.), so the KRB_AP_ERR_TKT_EXPIRED
error authenticator is returned.

If all these checks succeed without an error,
used to prevent invalid replay of tickets by proving to the server is assured
that the client possesses knows the credentials session key of the principal named in the ticket and thus, the client
has been authenticated thus is
entitled to use it. The KRB_AP_REQ message is referred to elsewhere
as the server. See section A.10 for
pseudocode.

3.2.4. "authentication header."

3.2.2. Generation of a KRB_AP_REP KRB_AP_REQ message

Typically,

When 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 client wishes to
the KRB_AP_REQ. However, if mutual initiate authentication (not only
authenticating the client to the a server, but also the server
to it
obtains (either through a credentials cache, the client) is being performed, AS exchange, or the KRB_AP_REQ message
will have MUTUAL-REQUIRED set in its ap-options field, and

Kohl & Neuman [Page 20]

RFC 1510 Kerberos September 1993

TGS exchange) a
KRB_AP_REP message is required in response. As with ticket and session key for the
error message, this message desired service. The
client may be encapsulated in re-use any tickets it holds until they expire. The client
then constructs a new Authenticator from the
application protocol if its "raw" form is not acceptable to the application's protocol. The timestamp system time, its
name, and microsecond
field optionally an application specific checksum, an initial
sequence number to be used in the reply must KRB_SAFE or KRB_PRIV messages, and/or a
session subkey to be the client's timestamp and
microsecond field (as provided used in negotiations for a session key unique to
this particular session. Authenticators may not be re-used and will
be rejected if replayed to a server (Note that this can make
applications based on unreliable transports difficult to code
correctly, if the authenticator)[12].
__________________________

[12] transport might deliver duplicated messages. 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 mes-
sages are formatted in
such cases, a way that it is not possi-
ble to create the reply by judicious message surgery
(even in encrypted form) without knowledge of the ap-
propriate encryption keys.

Section 3.2.4. - 21 - Expires 15 October 1993

Version 5 - Revision 5.2

If a sequence number new authenticator must be generated for each retry.).
If a sequence number is to be included, it should be ran-
domly randomly chosen as described above for the authenticator. A
subkey
so that even after many messages have been exchanged it is not likely
to collide with other sequence numbers in use.

The client may be included if indicate a requirement of mutual authentication or the server desires to negotiate
use of a
different subkey. session-key based ticket by setting the appropriate flag(s)
in the ap-options field of the message.

The KRB_AP_REP message Authenticator is encrypted in the session key extracted from and combined with
the ticket. ticket to form the KRB_AP_REQ message which is then sent to the
end server along with any additional application-specific
information. See section A.11 A.9 for pseudocode.

3.2.5.

3.2.3. Receipt of KRB_AP_REP message

If a KRB_AP_REP KRB_AP_REQ message

Authentication is returned, based on the client uses server's current time of day (clocks
must be loosely synchronized), the session key from authenticator, and the credentials obtained for ticket.
Several errors are possible. If an error occurs, the
server[13] server is
expected to reply to decrypt the message, and verifies that the
timestamp and microsecond fields match those client with a KRB_ERROR message. This
message may be encapsulated in the Authen-
ticator it sent application protocol if its "raw"
form is not acceptable to the server. protocol. The format of error messages
is described in section 5.9.1.

The algorithm for verifying authentication information is as follows.
If they match, then the
client message type is assured that 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 genuine. The sequence
number and subkey (if present) are retained for later use.
See section A.12 for pseudocode.

3.2.6. Using the encryption key

After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, not one the client and server share an encryption key which can be
used by use (e.g., it indicates
an old key, and the application. The "true session key" to be used
for KRB_PRIV, KRB_SAFE, or other application-specific uses
may be chosen by server no longer possesses a copy of the application based on old
key), the subkeys KRB_AP_ERR_BADKEYVER error is returned. If the USE-
SESSION-KEY flag is set in the
KRB_AP_REP message and ap-options field, it indicates to the authenticator[14]. In some
cases,
server that the ticket is encrypted in the use of this session key will from the
server's ticket-granting ticket rather than its secret key (This is
used for user-to-user authentication as described in [6]). Since it
is possible for the server to be implicit registered in multiple realms, with
different keys in each, the
protocol; srealm field in others the method unencrypted portion
of use must be chosen from a
several alternatives. We leave the protocol negotiations of
how 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

Kohl & Neuman [Page 21]

RFC 1510 Kerberos September 1993

error code is returned if the server doesn't have the proper key (e.g. selecting an encryption or check-
sum type) to
decipher the application programmer; ticket.

The ticket is decrypted using the Kerberos proto-
col does not constrain version of the implementation options.

With both server's key
specified by the one-way and mutual authentication
exchanges, ticket. If the peers should take care not decryption routines detect a
modification of the ticket (each encryption system must provide
safeguards to send sensitive
information to each other without proper assurances. In
particular, applications detect modified ciphertext; see section 6), the
KRB_AP_ERR_BAD_INTEGRITY error is returned (chances are good that require privacy or integrity
should use
different keys were used to encrypt and decrypt).

The authenticator is decrypted using the KRB_AP_REP or KRB_ERROR responses session key extracted from
the
server to client to assure both client and server of their
peer's identity. decrypted ticket. If an application protocol requires
privacy of its messages, decryption shows it can use to have been modified,
the KRB_PRIV message
(section 3.5). KRB_AP_ERR_BAD_INTEGRITY error is returned. The KRB_SAFE message (section 3.4) can be
__________________________

[13] Note that for encrypting name and realm
of the KRB_AP_REP message, client from the sub-session key ticket are compared against the same fields in
the authenticator. If they don't match, the KRB_AP_ERR_BADMATCH
error is returned (they might not used, even match, for example, if present the wrong
session key was used to encrypt the authenticator). The addresses in
the
Authenticator.
[14] Implementations ticket (if any) are then searched for an address matching the
operating-system reported address of the protocol may wish to pro-
vide routines to choose subkeys based client. If no match is
found or the server insists on session keys
and random numbers ticket addresses but none are present
in the ticket, the KRB_AP_ERR_BADADDR error is returned.

If the local (server) time and to orchestrate a negotiated key
to be returned the client time in the KRB_AP_REP message.

Section 3.2.6. - 22 - Expires 15 October 1993

Version authenticator
differ by more than the allowable clock skew (e.g., 5 - Revision 5.2

used to assure 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 minutes), the Kerberos
Ticket-Granting Server
KRB_AP_ERR_SKEW error is initiated by a client when it
wishes to obtain authentication credentials for a given
server (which might be registered in a remote realm), when
it wishes to renew or validate an existing ticket, or when
it wishes to obtain a proxy ticket. In the first case, the
client must already have acquired a ticket for returned. If the Ticket-
Granting Service using server name, along with
the AS exchange (the ticket-granting
ticket is usually obtained when a client initially authenti-
cates to name, time and microsecond fields from the system, Authenticator
match any recently-seen such as when a user logs in). The mes-
sage format for tuples, the TGS exchange KRB_AP_ERR_REPEAT error is almost identical to
returned (Note that
for the AS exchange. The primary difference rejection here is that encryp-
tion and decryption in restricted to
authenticators from the TGS exchange does same principal to the same server. Other
client principals communicating with the same server principal should
not take place
under be have their authenticators rejected if the time and microsecond
fields happen to match some other client's key. Instead, the session key from authenticator.). The
server must remember any authenticator presented within the
ticket-granting ticket or renewable ticket, or sub-session
key from an Authenticator is used. As allowable
clock skew, so that a replay attempt is guaranteed to fail. If a
server loses track of any authenticator presented within the case for
allowable clock skew, it must reject all
application servers, expired tickets are not accepted by requests until the
TGS, so once a renewable clock
skew interval has passed. This assures that any lost or ticket-granting ticket 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 re-played
authenticators will fall outside the client to allowable clock skew and can no
longer be successfully replayed (If this is not done, an attacker
could conceivably record the Kerberos Ticket-
Granting Server, ticket and a reply (KRB_TGS_REP or KRB_ERROR).
The KRB_TGS_REQ message includes information authenticating authenticator sent over the client plus
network to a request for credentials. The authentica-
tion information consists of the authentication header
(KRB_AP_REQ) which includes server, then disable the client's previously obtained
ticket-granting, renewable, or invalid ticket. In host, pose as the
disabled host, and replay the
ticket-granting ticket and proxy cases, authenticator to subvert the request may
include one or more of: a list of network addresses,
authentication.). If a col-
lection of typed authorization data to be sealed sequence number is provided in the
ticket
authenticator, the server saves it for authorization later use by in processing
KRB_SAFE and/or KRB_PRIV messages. If a subkey is present, the application server, or
additional tickets (the
server either saves it for later use of which are described later).
The TGS reply (KRB_TGS_REP) contains the requested creden-
tials, encrypted or uses it to help generate its
own choice for a subkey to be returned in a KRB_AP_REP message.

Kohl & Neuman [Page 22]

RFC 1510 Kerberos September 1993

The server computes the session key from age of the ticket-granting
ticket or renewable ticket, or if present, in ticket: local (server) time minus
the sub-
session key from start time inside the Authenticator (part of Ticket. If the authentica-
tion header). The KRB_ERROR message contains an start time 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 code
and text explaining what went wrong. The KRB_ERROR message is not encrypted. The KRB_TGS_REP message contains informa-
tion which can be used to detect replays, and to associate

Section 3.3. - 23 - Expires 15 October 1993

Version 5 - Revision 5.2

it with
returned. Otherwise, if the message to which it replies. The KRB_ERROR mes-
sage also contains information which can be used to associ-
ate it with current time is later than end time by
more than the message to which it replies, but allowable clock skew, the lack 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
encryption the principal named in
the KRB_ERROR message precludes ticket and thus, the ability client has been authenticated to
detect replays or fabrications of such messages.

3.3.1. the server.
See section A.10 for pseudocode.

3.2.4. Generation of KRB_TGS_REQ a KRB_AP_REP message

Before sending

Typically, a client's request to the ticket-granting ser-
vice, will include both the client must determine authentication
information and its initial request in which realm the applica-
tion server is registered[15]. If same message, and the client does
server need not
already possess a ticket-granting ticket for explicitly reply to the appropriate
realm, then one must be obtained. This is first attempted
by requesting a ticket-granting ticket for KRB_AP_REQ. However, if
mutual authentication (not only authenticating the destination
realm from client to the
server, but also the local Kerberos server (using to the KRB_TGS_REQ client) is being performed, the
KRB_AP_REQ message recursively). The Kerberos server may return will have MUTUAL-REQUIRED set in its ap-options
field, and a TGT
for the desired realm KRB_AP_REP message is required in which case one can proceed. Alter-
natively, response. As with the Kerberos server
error message, this message may return a TGT for a realm
which be encapsulated in the application
protocol if its "raw" form is "closer" not acceptable to the desired realm (further along the
standard hierarchical path), application's
protocol. The timestamp and microsecond field used in which case this step the reply must
be
repeated with a Kerberos server in the realm specified client's timestamp and microsecond field (as provided in the returned TGT. If neither are returned, then
authenticator). [Note: In the request
must be retried with a Kerberos server for a realm higher version 4 protocol, the
timestamp in the hierarchy. reply was the client's timestamp plus one. This request will itself require is
not necessary in version 5 because version 5 messages are formatted
in such a ticket-
granting ticket for way that it is not possible to create the higher realm which must be obtained reply by recursively applying these directions.

Once the client obtains a ticket-granting ticket for
judicious message surgery (even in encrypted form) without knowledge
of the appropriate realm, encryption keys.] If a sequence number is to be
included, it determines which Kerberos servers
serve that realm, and contacts one. The list might should be
obtained through a configuration file or network service; as
long randomly chosen as described above for the secret keys exchanged by realms are kept secret,
only denial of service results from a false Kerberos server.

As in the AS exchange, the client
authenticator. A subkey may specify a number
of options in be included if the KRB_TGS_REQ message. server desires to
negotiate a different subkey. 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 KRB_AP_REP message is encrypted in
the KRB_AS_REQ message along with several
optional fields: session key extracted from the enc-authorization-data field ticket. See section A.11 for
__________________________

[15] This can be accomplished in several ways. It
might be known beforehand (since the realm is part
pseudocode.

3.2.5. Receipt of
the principal identifier), or it might be stored in KRB_AP_REP message

If a
nameserver. Presently, however, this information KRB_AP_REP message is
obtained returned, the client uses the session key
from a configuration file. If the realm to be
used is credentials obtained from a nameserver, there is a danger
of being spoofed if for the nameservice providing server (Note that for
encrypting the realm
name KRB_AP_REP message, the sub-session key is not authenticated. This might result in the
use of a realm which has been compromised, and would
result used,
even if present in an attacker's ability to compromise the au-
thentication of the application server Authenticator.) to decrypt the client.

Section 3.3.1. - 24 - Expires 15 October 1993

Version 5 - Revision 5.2

application server use message, and additional tickets required by
some options.

In preparing the authentication header,
verifies that the client can
select a sub-session key under which timestamp and microsecond fields match those in the response from
Authenticator it sent to the
Kerberos server will be encrypted[16]. server. If they match, then the sub-session
key client
is not specified, the session key from the ticket-
granting ticket will be used. If assured that the enc-authorization-data server is present, it must be encrypted in the sub-session key, if
present, from the authenticator portion of the authentica-
tion header, or if not present in the session key from the
ticket-granting ticket.

Once prepared, the message is sent to a Kerberos server genuine. The sequence number and subkey
(if present) are retained for the destination realm. later use. See section A.5 A.12 for

Kohl & Neuman [Page 23]

RFC 1510 Kerberos September 1993

pseudocode.

3.3.2. Receipt of KRB_TGS_REQ message

The KRB_TGS_REQ message is processed in a manner simi-
lar to

3.2.6. Using the KRB_AS_REQ message, but there are many additional
checks to be performed. First, encryption key

After the Kerberos KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and
server must
determine share an encryption key which server can be used by the accompanying ticket is application.
The "true session key" to be used for KRB_PRIV, KRB_SAFE, or other
application-specific uses may be chosen by the application based on
the subkeys in the KRB_AP_REP message and it
must select the appropriate key authenticator
(Implementations of the protocol may wish to decrypt it. For provide routines to
choose subkeys based on session keys and random numbers and to
orchestrate a normal
KRB_TGS_REQ message, it will negotiated key to be for returned in the ticket granting ser-
vice, and KRB_AP_REP
message.). In some cases, the TGS's use of this session key will be used. If
implicit in the TGT was issued
by another realm, then protocol; in others the appropriate inter-realm key method of use must be used. If the accompanying ticket is not chosen
from a ticket grant-
ing ticket for several alternatives. We leave the current realm, but is for protocol negotiations of
how to use the key (e.g., selecting an application
server in encryption or checksum type)
to the current realm, application programmer; the RENEW, VALIDATE, or PROXY
options are specified in Kerberos protocol does not
constrain the request, implementation options.

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 or KRB_ERROR responses
from the server for
which to 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 assure 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 ticket is requested is client and the Kerberos Ticket-Granting
Server is initiated by a client when it wishes to obtain
authentication credentials for a given server named (which might be
registered in the
accompanying a remote realm), when it wishes to renew or validate an
existing ticket, then or when it wishes to obtain a proxy ticket. In the KDC will decrypt
first case, the client must already have acquired a ticket in for the authentication header
Ticket-Granting Service using the key of the server for
which it was issued. If no AS exchange (the ticket-granting
ticket can be found in is usually obtained when a client initially authenticates to
the
padata field, system, such as when a user logs in). The message format for the KDC_ERR_PADATA_TYPE_NOSUPP error
TGS exchange is
returned.

Once the accompanying ticket has been decrypted, almost identical to that for the
user-supplied checksum AS exchange. The
primary difference is that encryption and decryption in the Authenticator must be verified
against the contents of TGS

Kohl & Neuman [Page 24]

RFC 1510 Kerberos September 1993

exchange does not take place under the request, and client's key. Instead, the message
rejected if
session key from the checksums do not match (with an error code
of KRB_AP_ERR_MODIFIED) ticket-granting ticket or if the checksum is not keyed renewable ticket, or
not collision-proof (with
sub-session key from an error code of
KRB_AP_ERR_INAPP_CKSUM). If the checksum type Authenticator is not sup-
ported, the KDC_ERR_SUMTYPE_NOSUPP error used. As is returned. If the authorization-data are present, they case for
all application servers, expired tickets are decrypted using
the sub-session key from not accepted by the Authenticator.
__________________________

[16] If TGS,
so once a renewable or ticket-granting ticket expires, the client selects a sub-session key, care
must
be taken use a separate exchange to ensure the randomness obtain valid tickets.

The TGS exchange consists of the selected sub-
session key. One approach would be to generate a ran-
dom number and XOR it with the session key two messages: A request (KRB_TGS_REQ)
from the
ticket-granting ticket.

Section 3.3.2. - 25 - Expires 15 October 1993

Version 5 - Revision 5.2

If any of the decryptions indicate failed integrity
checks, client to the KRB_AP_ERR_BAD_INTEGRITY error is returned.

3.3.3. Generation of KRB_TGS_REP message Kerberos Ticket-Granting Server, and a reply
(KRB_TGS_REP or KRB_ERROR). The KRB_TGS_REP KRB_TGS_REQ message shares its format with includes
information authenticating 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 client plus a ticket request for the requested
server. credentials.
The Kerberos database is queried to retrieve authentication information consists of the
record for the requested server (including the key with authentication header
(KRB_AP_REQ) which includes the client's previously obtained ticket-
granting, renewable, or invalid ticket. In the ticket-granting
ticket will be encrypted). If and proxy cases, the request is for may include one or more of: a ticket granting ticket for
list of network addresses, a remote realm, and if no key
is shared with the requested realm, then the Kerberos server
will select the realm "closest" collection of typed authorization data
to the requested realm with
which it does share a key, and use that realm instead. This
is the only case where the response from the KDC will be sealed in the ticket for
a different server than that requested authorization use by the client.

By default, the address field, the client's name and
realm, the list of transited realms, the time application
server, or additional tickets (the use of initial
authentication, the expiration time, and which are described later).
The TGS reply (KRB_TGS_REP) contains the authorization
data of requested credentials,
encrypted in the newly-issued ticket will be copied session key from the ticket-granting ticket (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 ticket, or if present, in the request specifies an endtime, then subsession key from the endtime
Authenticator (part of the new ticket authentication header). The KRB_ERROR
message contains an error code and text explaining what went wrong.
The KRB_ERROR message is set not encrypted. The KRB_TGS_REP message
contains information which can be used to the minimum of (a) that request,
(b) the endtime from the TGT, detect replays, and (c) the starttime of to
associate it with the
TGT plus message to which it replies. The KRB_ERROR
message also contains information which can be used to associate it
with the minimum message to which it replies, but the lack of encryption in
the maximum life for KRB_ERROR message precludes the ability to detect replays or
fabrications of such messages.

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 and the maximum life for is registered
[Note: This can be accomplished in several ways. It might be known
beforehand (since the local realm (the maximum
life for is part of the requesting principal was already applied when
the TGT was issued). identifier), or
it might be stored in a nameserver. Presently, however, this
information is obtained from a configuration file. If the new ticket is realm to
be used is obtained from a renewal,
then the endtime above nameserver, there is replaced by the minimum a danger of (a) being
spoofed if the
value of nameservice providing the renew_till field of realm name is not
authenticated. This might result in the ticket use of a realm which has
been compromised, and (b) the
starttime for the new ticket plus would result in an attacker's ability to
compromise the life (endtime-
starttime) authentication of the old ticket.

If application server to the FORWARDED option has been requested, then
client.]. If the
resulting client does not already possess a ticket-granting
ticket will contain for the addresses specified appropriate realm, then one must be obtained. This is
first attempted by requesting a ticket-granting ticket for the
client. This option will only be honored if
destination realm from the FORWARDABLE
flag is set in local Kerberos server (using the TGT.

Kohl & Neuman [Page 25]

RFC 1510 Kerberos September 1993

KRB_TGS_REQ message recursively). The PROXY option is similar; the
resulting ticket will contain the addresses specified by the
client. It will be honored only if Kerberos server may return a
TGT for the PROXIABLE flag desired realm in which case one can proceed.
Alternatively, the Kerberos server may return a TGT is set. The PROXY option will not be honored on
requests for additional ticket-granting tickets.

If the requested start time is absent or indicates a
time in the past, then the start time of the ticket realm which
is set "closer" to the authentication server's current time. If it

Section 3.3.3. - 26 - Expires 15 October 1993

Version 5 - Revision 5.2

indicates desired realm (further along the standard
hierarchical path), in which case this step must be repeated with a time
Kerberos server in the future, but the POSTDATED option has
not been realm specified or the MAY-POSTDATE flag is not set in the TGT, returned TGT. If
neither are returned, then the error KDC_ERR_CANNOT_POSTDATE is returned.
Otherwise, if request must be retried with a
Kerberos server for a realm higher in the hierarchy. This request
will itself require a ticket-granting ticket has the MAY-
POSTDATE flag set, then for the resulting ticket will higher realm
which must be post-
dated and the requested starttime is checked against the
policy of obtained by recursively applying these directions.

Once the local realm. If acceptable, client obtains a ticket-granting ticket for the ticket's start
time is set as requested, appropriate
realm, it determines which Kerberos servers serve that realm, and the INVALID flag is set.
contacts one. The
postdated ticket must list might be validated before use by presenting
it to the KDC after the starttime has been reached. How-
ever, in no case may the starttime, endtime, obtained through a configuration file
or renew-till
time network service; as long as the secret keys exchanged by realms
are kept secret, only denial of service results from a newly-issued postdated ticket extend beyond false Kerberos
server.

As in the
renew-till time AS exchange, the client may specify a number of options in
the ticket-granting ticket.

If KRB_TGS_REQ message. The client prepares the ENC-TKT-IN-SKEY option has been specified and KRB_TGS_REQ
message, providing an
additional ticket has been included in authentication header as an element of the request,
padata field, and including the KDC
will decrypt same fields as used in the additional ticket using KRB_AS_REQ
message along with several optional fields: the key enc-authorization-
data field for the application server to which the additional ticket was issued use and verify
that it is a ticket-granting ticket. If the name of the
requested server is missing from the request, additional tickets required
by some options.

In preparing the name of authentication header, the client in the additional ticket will be used. Otherwise can select a sub-
session key under which the name of response from the requested Kerberos server will be compared to the
name of
encrypted (If the client in selects a sub-session key, care must be
taken to ensure the additional ticket and if dif-
ferent, randomness of the request will selected subsession key. One
approach would be rejected. If the request
succeeds, to generate a random number and XOR it with the
session key from the additional ticket will be
used to encrypt ticket-granting ticket.). If the new ticket that sub-session key
is issued instead of
using not specified, the session key of the server for which from the new ticket-granting ticket
will be
used[17]. used. If the name of the server enc-authorization-data is present, it must be
encrypted in the ticket that is
presented to sub-session key, if present, from the KDC as part authenticator
portion of the authentication header is header, or if not that of present in the
session key from the ticket-granting server itself, and ticket.

Once prepared, the message is sent to a Kerberos server for the
destination realm. See section A.5 for pseudocode.

3.3.2. Receipt of KRB_TGS_REQ message

The KRB_TGS_REQ message is registered processed in a manner similar to the realm of
KRB_AS_REQ message, but there are many additional checks to be
performed. First, the KDC, If Kerberos server must determine which server
the RENEW
option accompanying ticket is requested, then for and it must select the KDC appropriate key
to decrypt it. For a normal KRB_TGS_REQ message, it will verify that the
RENEWABLE flag is set in be for the

Kohl & Neuman [Page 26]

RFC 1510 Kerberos September 1993

ticket granting service, and that the renew_till
time is still in TGS's key will be used. If the future. TGT
was issued by another realm, then the appropriate inter-realm key
must be used. If the VALIDATE option accompanying ticket is
rqeuested, not a ticket granting
ticket for the KDC will check that current realm, but is for an application server in the starttime has passed
current realm, the RENEW, VALIDATE, or PROXY options are specified in
the request, and the INVALID flag server for which a ticket is set. If the PROXY option requested is
requested, the
server named in the accompanying ticket, then the KDC will check that decrypt
the PROXIABLE flag
is set ticket in the ticket. authentication header using the key of the server
for which it was issued. If no ticket can be found in the tests succeed, padata
field, the KDC will
issue the appropriate new ticket.

Whenever a request KDC_ERR_PADATA_TYPE_NOSUPP error is made to the ticket-granting
server, returned.

Once the presented ticket(s) is(are) checked against a
hot-list of tickets which have accompanying ticket has been canceled. This hot-list
might decrypted, the user-supplied
checksum in the Authenticator must be implemented by storing a range verified against the contents
of issue dates for
"suspect tickets"; the request, and the message rejected if a presented ticket had the checksums do not
match (with an authtime in
__________________________

[17] This allows easy implementation of user-to-user
authentication [6], which uses ticket-granting ticket
session keys in lieu error code of secret server keys in situa-
tions where such secret keys could be easily comprom-
ised.

Section 3.3.3. - 27 - Expires 15 October 1993

Version 5 - Revision 5.2

that range, it would be rejected. In this way, a stolen
ticket-granting ticket or renewable ticket cannot be used to
gain additional tickets (renewals KRB_AP_ERR_MODIFIED) or otherwise) once the
theft has been reported. Any normal ticket obtained before
it was reported stolen will still be valid (because they
require no interaction with if the KDC), but only until their
normal expiration time.

The ciphertext part checksum
is not keyed or not collision-proof (with an error code of
KRB_AP_ERR_INAPP_CKSUM). If the response in checksum type is not supported, the KRB_TGS_REP
message
KDC_ERR_SUMTYPE_NOSUPP error is encrypted in returned. If the authorization-data
are present, they are decrypted using the sub-session key from the Authen-
ticator, if present, or
Authenticator.

If any of the session key key from decryptions indicate failed integrity checks, the
ticket-granting ticket. It
KRB_AP_ERR_BAD_INTEGRITY error is not encrypted using returned.

3.3.3. Generation of KRB_TGS_REP message

The KRB_TGS_REP message shares its format with 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 KRB_AS_REP
(KRB_KDC_REP), but with the client's
database record, and that record is not needed its type field set to satisfy a
request based on a ticket-granting ticket. See KRB_TGS_REP. The
detailed specification is in section A.6 5.4.2.

The response will include a ticket for pseudocode.

3.3.3.1. Encoding the transited field

If the identity of the server in the TGT that requested server. The
Kerberos database is
presented queried to retrieve the KDC as part of the authentication header is
that of the ticket-granting service, but the TGT was issued
from another realm, record for the KDC will look up requested
server (including the inter-realm key
shared with that realm and use that key to decrypt which the
ticket. ticket will be encrypted).
If the request is for a ticket granting ticket for a remote realm,
and if no key is valid, shared with the requested realm, then the KDC< Kerberos
server will honor select the request, subject realm "closest" to the constraints outlined above in requested realm with
which it does share a key, and use that realm instead. This is the section describing
only case where the AS exchange. The realm part of response from the client's identity KDC will be taken from for a different
server than that requested by the ticket-granting
ticket. The client.

By default, the address field, the client's name and realm, the list
of transited realms, the realm that issued time of initial authentication, the ticket-
granting ticket will be added to
expiration time, and the transited field authorization data of the newly-issued
ticket to will be issued. This is accomplished by reading the
transited field copied from the ticket-granting ticket (which (TGT) or
renewable ticket. If the transited field needs to be updated, but
the transited type is
treated as not supported, the KDC_ERR_TRTYPE_NOSUPP error
is returned.

Kohl & Neuman [Page 27]

RFC 1510 Kerberos September 1993

If the request specifies an unordered set endtime, then the endtime of realm names), adding the new
realm
ticket is set to the set, then constructing and writing out its
encoded (shorthand) form (this may involve a rearrangement minimum of the existing encoding).

Note (a) that request, (b) the ticket-granting service does not add endtime
from the
name TGT, and (c) the starttime of its own realm. Instead, its responsibility is to
add the name TGT plus the minimum of
the previous realm. This prevents a mali-
cious Kerberos maximum life for the application server from intentionally leaving out its own
name (it could, however, omit other realms' names).

The names of neither and the maximum life for
the local realm nor (the maximum life for the
principal's realm are to be included in requesting principal was
already applied when the transited field.
They appear elsewhere in TGT was issued). If the new ticket and both are known is to
have taken part in authenticating the principal. Since the
endpoints are not included, both local and single-hop
inter-realm authentication result in be
a transited field that
is empty.

Because renewal, then the name of each realm transited endtime above is added to

Section 3.3.3.1. - 28 - Expires 15 October 1993

Version 5 - Revision 5.2

this field, it might potentially be very long. To decrease replaced by the length minimum of this field, its contents are encoded. The
initially supported encoding is optimized for (a)
the normal
case value of inter-realm communication: a hierarchical arrange-
ment the renew_till field 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, ticket and if they are part (b) the starttime
for the new ticket plus the life (endtimestarttime) of a realm
name, they must 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 quoted honored if the FORWARDABLE flag is set in the transited field by preced-
ing them with a "\".

A realm name ending with a "." TGT. The PROXY
option is interpreted as being
prepended to similar; 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 resulting ticket will contain the addresses
specified by the client. It will be honored only if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-
points, that they would the PROXIABLE
flag in the TGT is set. The PROXY option will not be included in this field, and
we would have:

"EDU,MIT.,WASHINGTON.EDU"

A realm name beginning with honored on
requests for additional ticket-granting tickets.

If the requested start time is absent or indicates a "/" time in the
past, then the start time of the ticket is interpreted as being
appended set to the previous realm[18]. authentication
server's current time. If it is to stand by
itself, then it should be preceded by indicates a space (" "). For
example, we can encode traversal of /COM/HP/APOLLO, /COM/HP,
/COM, and /COM/DEC as:

"/COM,/HP,/APOLLO, /COM/DEC".

Like time in the example above, if /COM/HP/APOLLO and /COM/DEC are
endpoints, they they would future, but the
POSTDATED option has not be included in this field,
and we would have:

"/COM,/HP"

A null subfield preceding been specified or following a "," indicates
that all realms between the previous realm and MAY-POSTDATE flag is
not set in the next
realm have been traversed[19]. Thus, "," means that all
__________________________

[18] For TGT, then the purpose of appending, error KDC_ERR_CANNOT_POSTDATE is
returned. Otherwise, if the realm preceding ticket-granting ticket has the first listed realm is considered to
MAYPOSTDATE flag set, then the resulting ticket will be postdated and
the null
realm ("").
[19] For requested starttime is checked against the purpose policy of interpreting null subfields, the client's realm is considered to precede those in local
realm. If acceptable, the transited field, ticket's start time is set as requested,
and the server's realm INVALID flag is con-
sidered set. The postdated ticket must be validated
before use by presenting it to follow them.

Section 3.3.3.1. - 29 - Expires 15 October 1993

Version 5 - Revision 5.2

realms along the path between the client and KDC after the server have starttime has been traversed. ",EDU, /COM," means that that all realms
from
reached. However, in no case may the client's realm up to EDU (in starttime, endtime, or renew-
till time of a domain style hierar-
chy) have newly-issued postdated ticket extend beyond the
renew-till time of the ticket-granting ticket.

If the ENC-TKT-IN-SKEY option has been traversed, specified and that everything from /COM down
to the server's realm in an X.500 style additional
ticket has also been
traversed. This could occur if the EDU realm included in one hierar-
chy shares an inter-realm the request, the KDC will decrypt the
additional ticket using the key directly with for the /COM realm
in another hierarchy.

3.3.4. Receipt of KRB_TGS_REP message

When the KRB_TGS_REP is received by server to which the client,
additional ticket was issued and verify that it is pro-
cessed in a ticket-granting
ticket. If the same manner as name of the KRB_AS_REP processing
described above. The primary difference requested server is that missing from the cipher-
text part of
request, the response must be decrypted using name of the ses-
sion key from client in the ticket-granting additional ticket rather than the
client's secret key. See section A.7 for pseudocode.

3.4. The KRB_SAFE Exchange

The KRB_SAFE message may will be used by clients requiring
used. Otherwise the ability to detect modifications name of messages they
exchange. It achieves this by including a keyed collision-
proof checksum the requested server will be compared to
the name of the user data client in the additional ticket and some control informa-
tion. The checksum is keyed with an encryption key (usually if different, the last key negotiated via subkeys, or
request will be rejected. If the request succeeds, the session key if
no negotiation has occured).

3.4.1. Generation of a KRB_SAFE message

When an application wishes to send a KRB_SAFE message, it
collects its data and
from the appropriate control information
and computes a checksum over them. The checksum algorithm
should additional ticket will be some sort of keyed one-way hash function (such as
the RSA-MD5-DES checksum algorithm specified in section
6.4.5, or used to encrypt the DES MAC), generated new ticket
that is issued instead of using the sub-session key
if present, or the session key. Different algorithms may be
selected by changing the checksum type in of the message.
Unkeyed or non-collision-proof checksums are not suitable
for this use.

The control information server for which the KRB_SAFE message
includes both a timestamp and a sequence number. The
designer
new ticket will be used (This allows easy implementation of an application using the KRB_SAFE message must
choose at least one user-to-
user authentication [6], which uses ticket-granting ticket session
keys in lieu of the two mechanisms. This choice
should secret server keys in situations where such secret

Kohl & Neuman [Page 28]

RFC 1510 Kerberos September 1993

keys could be based on easily compromised.).

If the needs name of the application protocol.

Sequence numbers are useful when all messages sent will
be received by one's peer. Connection state server in the ticket that is presently
required presented to maintain the session key, so maintaining KDC
as part of the
next sequence number should authentication header is not present an additional prob-
lem.

If that of the application protocol ticket-
granting server itself, and the server is expected to tolerate

Section 3.4.1. - 30 - Expires 15 October 1993

Version 5 - Revision 5.2

lost messages without them being resent, registered in the use realm of
the
timestamp is KDC, If the appropriate replay detection mechanism.
Using timestamps RENEW option is also requested, then the appropriate mechanism for
multi-cast protocols where all of one's peers share a common
sub-session key, but some messages KDC will be sent to a subset
of one's peers.

After computing the checksum, verify
that the client then transmits RENEWABLE flag is set in the information ticket and checksum to that the recipient renew_till
time is still 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. future. If any error occurs, an error code is
reported for use by the application.

The message VALIDATE option is first checked by verifying that the pro-
tocol version and type fields match rqeuested,
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 KDC will check that the checksum used is a collision-
proof keyed checksum, starttime has passed and if it the INVALID flag
is not, a
KRB_AP_ERR_INAPP_CKSUM error set. If the PROXY option is generated. The recipient
verifies requested, then the KDC will check
that the operating system's report of PROXIABLE flag is set in the sender's
address matches ticket. If the sender's address in tests succeed,
the message, and (if KDC will issue the appropriate new ticket.

Whenever a recipient address request is specified or made to the recipient requires ticket-granting server, the
presented ticket(s) is(are) checked against a hot-list of tickets
which have been canceled. This hot-list might be implemented by
storing a range of issue dates for "suspect tickets"; if a presented
ticket had an address) authtime in that one of range, it would be rejected. In this
way, a stolen ticket-granting ticket or renewable ticket cannot be
used to gain additional tickets (renewals or otherwise) once the recipient's addresses appears as
theft has been reported. Any normal ticket obtained before it was
reported stolen will still be valid (because they require no
interaction with the recipient's address KDC), but only until their normal expiration
time.

The ciphertext part of the response in the message. A failed match for
either case generates a KRB_AP_ERR_BADADDR error. Then KRB_TGS_REP message is
encrypted in the
timestamp and usec and/or sub-session key from the sequence number fields are
checked. If timestamp and usec are expected and not Authenticator, if present,
or they are present but not current, the
KRB_AP_ERR_SKEW error session key key from the ticket-granting ticket. It is generated. If not
encrypted using the server name,
along with client's secret key. Furthermore, the client name, time client's
key's expiration date and microsecond fields from
the Authenticator match any recently-seen such tuples, the
KRB_AP_ERR_REPEAT error is generated. If an incorrect
sequence number is included, or a sequence key version number is
expected but not present, fields are left out
since these values are stored along with the KRB_AP_ERR_BADORDER error is
generated. If neither a timestamp client's database
record, and usec or a sequence
number that record is present, not needed to satisfy a KRB_AP_ERR_MODIFIED error is generated.
Finally, request based on a
ticket-granting ticket. See section A.6 for pseudocode.

3.3.3.1. Encoding the checksum is computed over transited field

If the data and control
information, and if it doesn't match identity of the received checksum,
a KRB_AP_ERR_MODIFIED error server in the TGT that is generated.

If all presented to the checks succeed, KDC
as part of the application authentication header is assured that of the message ticket-granting
service, but the TGT was generated by its peer issued from another realm, the KDC will look
up the inter-realm key shared with that realm and was not modi-
fied 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 transit.

3.5. The KRB_PRIV Exchange the section
describing the AS exchange. The KRB_PRIV message may realm part of the client's identity
will be used by clients requiring
confidentiality and taken from the ability to detect modifications ticket-granting ticket. The name of
exchanged messages. It achieves this by encrypting the

Section 3.5. - 31 - Expires 15 October 1993

Version 5 - Revision 5.2

messages and adding control information.

3.5.1. Generation realm
that issued the ticket-granting ticket will be added to the transited
field of a KRB_PRIV message

When an application wishes the ticket to send a KRB_PRIV message, it
collects its data and be issued. This is accomplished by reading
the appropriate control information
(specified in section 5.7.1) and encrypts them under transited field from the ticket-granting ticket (which is treated
as an
encryption key (usually unordered set of realm names), adding the last key negotiated via subkeys,
or new realm to the session key if no negotiation has occured). As part set,

Kohl & Neuman [Page 29]

RFC 1510 Kerberos September 1993

then constructing and writing out its encoded (shorthand) form (this
may involve a rearrangement of the control information, existing encoding).

Note that the client must choose ticket-granting service does not add the name of its
own realm. Instead, its responsibility is to use
either a timestamp or add the name of the
previous realm. This prevents a sequence number (or both); see malicious Kerberos server from
intentionally leaving out its own name (it could, however, omit other
realms' names).

The names of neither the
discussion in section 3.4.1 for guidelines on which to use.
After local realm nor the user data and control information principal's realm are encrypted, to
be included in the client transmits transited field. They appear elsewhere in the ciphertext
ticket and some "envelope"
information both are known to have taken part in authenticating the recipient.

3.5.2. Receipt of KRB_PRIV message

When an application receives a KRB_PRIV message, it verifies
it as follows. If any error occurs, an error code is
reported for use by the application.

The message is first checked by verifying that the pro-
tocol version and type fields match the current version and
KRB_PRIV, respectively. A mismatch generates a
KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The
application then decrypts
principal. Since the ciphertext endpoints are not included, both local and processes the
resultant plaintext. If decryption shows the data to have
been modified,
single-hop inter-realm authentication result in a KRB_AP_ERR_BAD_INTEGRITY error is gen-
erated. The recipient verifies transited field
that is empty.

Because the operating system's
report name of the sender's address matches the sender's address
in the message, and (if a recipient address each realm transited is specified or added to this field,
it might potentially be very long. To decrease the recipient requires an address) that one length of the
recipient's addresses appears as the recipient's address in
the message. A failed match this
field, its contents are encoded. The initially supported encoding is
optimized for either the normal case generates of inter-realm communication: a
KRB_AP_ERR_BADADDR error. Then the timestamp and usec
and/or
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 sequence number fields transited field are checked. If timestamp separated by a ",". The ",",
"\", trailing "."s, and usec leading spaces (" ") are expected special characters,
and not present, or if they are present
but not current, the KRB_AP_ERR_SKEW error is generated. If
the server name, along with the client part of a realm name, time and
microsecond fields from they must be quoted in the Authenticator match any
recently-seen such tuples, the KRB_AP_ERR_REPEAT error is
generated. If an incorrect sequence number is included, or
a sequence number is expected but not present, the
KRB_AP_ERR_BADORDER error is generated. If neither a time-
stamp and usec or
transited field by preceding them with a sequence number is present, "\".

A realm name ending with a
KRB_AP_ERR_MODIFIED error "." is generated.

If all the checks succeed, interpreted as being prepended to
the application previous realm. For example, we can assume
the message was generated by its peer, encode traversal of EDU,
MIT.EDU, ATHENA.MIT.EDU, WASHINGTON.EDU, and was securely
transmitted (without intruders able to see the unencrypted
contents).

Section 3.5.2. - 32 - Expires 15 October 1993

Version 5 - Revision 5.2

3.6. The KRB_CRED Exchange

The KRB_CRED message may CS.WASHINGTON.EDU as:

"EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.".

Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were endpoints,
that they would not be used by clients requiring
the ability to send Kerberos credentials from one host to
another. It achieves included in this by sending the tickets together
with encrypted data containing the session keys field, and other
information associated we would have:

"EDU,MIT.,WASHINGTON.EDU"

A realm name beginning with the tickets.

3.6.1. Generation of a KRB_CRED message

When an application wishes to send a KRB_CRED message it
first (using the KRB_TGS exchange) obtains credentials to be
sent to the remote host. It then constructs a KRB_CRED mes-
sage using the ticket or tickets so obtained, placing the
session key needed "/" is interpreted as being appended to use each ticket in
the key field of previous realm (For the corresponding KrbCredInfo sequence purpose of appending, the encrypted part
of realm preceding
the first listed realm is considered to be the KRB_CRED message.

Other information associated with each ticket and
obtained during the KRB_TGS exchange null realm ("")). If
it is also placed in the
corresponding KrbCredInfo sequence in the encrypted part of
the KRB_CRED message. The current time and, if specifically
required to stand by the application the nonce, s-address, and r-
address fields, are placed in the encrypted part of the
KRB_CRED message which is itself, then encrypted under an encryption
key previosuly exchanged in the KRB_AP exchange (usually the
last key negotiated via subkeys, or the session key if no
negotiation has occured).

3.6.2. Receipt of KRB_CRED message

When an application receives a KRB_CRED message, it verifies
it. If any error occurs, an error code is reported for use
by the application. The message is verified should be preceded by checking
that the protocol version a space ("
"). For example, we can encode traversal of /COM/HP/APOLLO, /COM/HP,
/COM, and type fields match /COM/DEC as:

"/COM,/HP,/APOLLO, /COM/DEC".

Kohl & Neuman [Page 30]

RFC 1510 Kerberos September 1993

Like the current
version example above, if /COM/HP/APOLLO and KRB_CRED, respectively. /COM/DEC are endpoints,
they they would not be included in this field, and we would have:

"/COM,/HP"

A mismatch generates a
KRB_AP_ERR_BADVERSION null subfield preceding or KRB_AP_ERR_MSG_TYPE error. The
application then decrypts following a "," indicates that all
realms between the ciphertext previous realm and processes the
resultant plaintext. If decryption shows the data to next realm have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is gen-
erated.

If present or required, the recipient verifies that
traversed (For the
operating system's report purpose of interpreting null subfields, the sender's address matches
the sender's address
client's realm is considered to precede those in the message, transited field,
and that one of the
recipient's addresses appears as server's realm is considered to follow them.). Thus, ","
means that all realms along the recipient's address in path between the message. A failed match for either case generates a
KRB_AP_ERR_BADADDR error. The timestamp client and usec fields
(and the nonce field if required) are checked next. If
server have been traversed. ",EDU, /COM," means that that all realms
from the
timestamp client's realm up to EDU (in a domain style hierarchy) have
been traversed, and usec are not present, or they are present but
not current, that everything from /COM down to the KRB_AP_ERR_SKEW error is generated.

If all server's
realm in an X.500 style has also been traversed. This could occur if
the checks succeed, EDU realm in one hierarchy shares an inter-realm key directly
with the application stores each /COM realm in another hierarchy.

3.3.4. Receipt of KRB_TGS_REP message

When the new tickets in its ticket cache together with KRB_TGS_REP is received by the

Section 3.6.2. - 33 - Expires 15 October 1993

Version 5 - Revision 5.2

session key and other information client, it is processed in
the corresponding
KrbCredInfo sequence from same manner as the encrypted KRB_AS_REP processing described above. The
primary difference is that the ciphertext part of the KRB_CRED
message.

4. The Kerberos Database

The Kerberos server response must have access to a database contain-
ing the principal identifiers and secret keys of principals
to
be authenticated[20].

4.1. Database contents

A database entry should contain at least decrypted using the following
fields:

Field Value

name Principal's identif-
ier session key Principal's from the ticket-granting ticket
rather than the client's secret key
p_kvno Principal's key version
max_life Maximum lifetime for Tickets
max_renewable_life Maximum total lifetime key. See section A.7 for renewable Tickets pseudocode.

3.4. The name field is an encoding 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 collisionproof checksum of the principal's identifier. user data and some
control information. The key field contains checksum is keyed with an encryption key. This key is
(usually the
principal's secret key. (The last key can be encrypted before
storage under a Kerberos "master key" to protect it in case
the database is compromised but negotiated via subkeys, or the master session key is not. In
that case, if
no negotiation has occured).

3.4.1. Generation of a KRB_SAFE message

When an extra field must be added application wishes to indicate send a KRB_SAFE message, it collects
its data and the mas-
ter key version used, see below.) appropriate control information and computes a
checksum over them. The p_kvno field is checksum algorithm should be some sort of
keyed one-way hash function (such as the RSA-MD5-DES checksum
algorithm specified in section 6.4.5, or the DES MAC), generated
using the sub-session key version number of if present, or the principal's secret session key. The
max_life field contains Different
algorithms may be selected by changing the maximum allowable lifetime (end-
time - starttime) for any Ticket issued for this principal.
The max_renewable_life field contains checksum type in the maximum allowable
total lifetime for any renewable Ticket issued
message. Unkeyed or non-collision-proof checksums are not suitable
for this
principal. (See section 3.1 use.

The control information for the KRB_SAFE message includes both a description

Kohl & Neuman [Page 31]

RFC 1510 Kerberos September 1993

timestamp and a sequence number. The designer of how these
lifetimes are used in determining an application
using the lifetime KRB_SAFE message must choose at least one of a given
Ticket.)

A server may provide KDC service to several realms, as
long as the database representation provides a mechanism to
distinguish between principal records with identifiers which
differ only in two
mechanisms. This choice should be based on the realm name.
__________________________

[20] The implementation needs of the Kerberos server need not
combine the database and the server on the same
machine; it
application protocol.

Sequence numbers are useful when all messages sent will be received
by one's peer. Connection state is feasible presently required to store maintain
the principal database
in, say, a network name service, as long as session key, so maintaining the entries
stored therein are protected from disclosure to and
modification by unauthorized parties. However, we
recommend against such strategies, as they can make
system management and threat analysis quite complex.

Section 4.1. - 34 - Expires 15 October 1993

Version 5 - Revision 5.2

When next sequence number should not
present an application server's key changes, if additional problem.

If the change application protocol is routine (i.e. not expected to tolerate lost messages
without them being resent, the result of disclosure use of the old
key), timestamp is the old key should be retained by
appropriate replay detection mechanism. Using timestamps is also the server until
appropriate mechanism for multi-cast protocols where all
tickets that had been issued using that key have expired.
Because of this, it is possible for several keys to be
active for one's
peers share a single principal. Ciphertext encrypted in common sub-session key, but some messages will be sent
to a
principal's key is always tagged with the version subset of one's peers.

After computing the key
that was used for encryption, checksum, the client then transmits the
information and checksum to help the recipient find in the
proper key for decryption. message format
specified in section 5.6.1.

3.4.2. Receipt of KRB_SAFE message

When more than one key an application receives a KRB_SAFE message, it verifies it as
follows. If any error occurs, an error code is active reported for a particular prin-
cipal, the principal will have more than one record in use by
the
Kerberos database. application.

The keys and key version numbers will
differ between the records (the rest of message is first checked by verifying that the protocol version
and type fields may or
may not be match the same). Whenever Kerberos issues current version and KRB_SAFE, respectively.
A mismatch generates a ticket, KRB_AP_ERR_BADVERSION or
responds to a request for initial authentication, the most
recent key (known by KRB_AP_ERR_MSG_TYPE
error. The application verifies that the Kerberos server) will be checksum used for
encryption. This is the key with the highest key version
number.

4.2. Additional fields

Project Athena's KDC implementation uses additional fields
in its database:

Field Value

K_kvno Kerberos' key version
expiration Expiration date for entry
attributes Bit field of attributes
mod_date Timestamp of last modification
mod_name Modifying principal's identifier a
collisionproof keyed checksum, and if it is not, a
KRB_AP_ERR_INAPP_CKSUM error is generated. The K_kvno field indicates recipient verifies
that the key version operating system's report of the Kerberos
master key under which sender's address matches
the principal's secret key sender's address in the message, and (if a recipient address is
encrypted.

After an entry's expiration date has passed,
specified or the KDC
will return recipient requires an error to any client attempting to gain tick-
ets address) that one of the
recipient's addresses appears as or for the principal. (A database may want to main-
tain two expiration dates: one recipient's address in the
message. A failed match for either case generates a
KRB_AP_ERR_BADADDR error. Then the principal, timestamp and one
for usec and/or the principal's current key. This allows password aging
to work independently of
sequence number fields are checked. If timestamp and usec are
expected and not present, or they are present but not current, the principal's expiration date.
However, due to
KRB_AP_ERR_SKEW error is generated. If the limited space in server name, along with
the responses, client name, time and microsecond fields from the KDC
must combine Authenticator
match any recently-seen such tuples, the key expiration and principal expiration
date into a single value called "key_exp", which KRB_AP_ERR_REPEAT error is used as
generated. If an incorrect sequence number is included, or a hint to
sequence number is expected but not present, the user to take administrative action.)

The attributes field KRB_AP_ERR_BADORDER
error is generated. If neither a bitfield used to govern timestamp and usec or a sequence
number is present, a KRB_AP_ERR_MODIFIED error is generated.

Kohl & Neuman [Page 32]

RFC 1510 Kerberos September 1993

Finally, the
operations involving checksum is computed over the principal. This field might be
useful in conjunction with user registration procedures, for
site-specific policy implementations (Project Athena
currently uses data and control
information, and if it for their user registration process

Section 4.2. - 35 - Expires 15 October 1993

Version 5 - Revision 5.2

controlled by the system-wide database service, Moira [7]),.
or to identify doesn't match the "string to key" conversion algorithm used
for received checksum, a principal's key[21]. Other bits are used to indicate
that certain ticket options should not be allowed in tickets
encrypted under a principal's key (one bit each): Disallow
issuing postdated tickets, disallow issuing forwardable
tickets, disallow issuing tickets based on TGT authentica-
tion, disallow issuing renewable tickets, disallow issuing
proxiable tickets, and disallow issuing tickets for which
the principal
KRB_AP_ERR_MODIFIED error is generated.

If all the server.

The mod_date field contains checks succeed, the time of last modifica-
tion of application is assured that the entry,
message was generated by its peer and the mod_name field contains the name
of the principal which last was not modified the entry.

4.3. Frequently Changing Fields

Some KDC implementations in transit.

3.5. The KRB_PRIV Exchange

The KRB_PRIV message may wish be used by clients requiring confidentiality
and the ability to maintain detect modifications of exchanged messages. It
achieves this by encrypting the last
time that messages and adding control
information.

3.5.1. Generation of a request was made by KRB_PRIV message

When an application wishes to send a particular principal.
Information that might be maintained includes KRB_PRIV message, it collects
its data and the time of appropriate control information (specified in
section 5.7.1) and encrypts them under an encryption key (usually the
last request, key negotiated via subkeys, or the time session key if no negotiation
has occured). As part of the last request for a
ticket-granting ticket, the time of control information, the last client must
choose to use of either a
ticket-granting ticket, timestamp or other times. This information
can then be returned to a sequence number (or both); see
the user discussion in the last-req field (see section 5.2).

Other frequently changing information that can be main-
tained is the latest expiration time 3.4.1 for any tickets that
have been issued using each key. This field would be used
to indicate how long old keys must remain valid guidelines on which to allow use.
After the
continued use of outstanding tickets.

4.4. Site Constants

The KDC implementation should have user data and control information are encrypted, the following confi-
gurable constants or options, to allow an administrator to
make client
transmits the ciphertext and enforce policy decisions:

+ The minimum supported lifetime (used some "envelope" information to determine whether the KDC_ERR_NEVER_VALID error should be returned). This
constant should reflect reasonable expectations
recipient.

3.5.2. Receipt of
round-trip time to KRB_PRIV message

When an application receives a KRB_PRIV message, it verifies it as
follows. If any error occurs, an error code is reported for use by
the KDC, encryption/decryption time,
and processing time application.

The message is first checked by verifying that the client protocol version
and target server, type fields match the current version and
it should allow for KRB_PRIV, respectively.
A mismatch generates a minimum "useful" lifetime.

+ KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE
error. The maximum allowable total (renewable) lifetime of application then decrypts the ciphertext and processes
the resultant plaintext. If decryption shows the data to have been
modified, a
ticket (renew_till - starttime).

+ KRB_AP_ERR_BAD_INTEGRITY error is generated. The maximum allowable lifetime
recipient verifies that the operating system's report of the sender's
address matches the sender's address in the message, and (if a ticket (endtime -
starttime).
__________________________

[21] See
recipient address is specified or the discussion recipient requires an address)
that one of the padata field recipient's addresses appears as the recipient's
address in section
5.4.2 the message. A failed match for details on why this can be useful.

Section 4.4. - 36 - Expires 15 October 1993

Version 5 - Revision 5.2

+ Whether to allow the issue of tickets with empty address
fields (including either case generates a
KRB_AP_ERR_BADADDR error. Then the ability to specify that such tick-
ets may only be issued if timestamp and usec and/or the request specifies some
authorization_data).

+ Whether proxiable, forwardable, renewable or post-datable
tickets
sequence number fields are to be issued.

5. Message Specifications

The following sections describe the exact contents checked. If timestamp and
encoding of protocol messages usec are
expected and objects. The ASN.1 base
definitions not present, or they are presented in the first subsection. The
remaining subsections specify present but not current, the protocol objects (tickets
and authenticators) and messages. Specification of encryp-
tion and checksum techniques, and
KRB_AP_ERR_SKEW error is generated. If the fields related to
them, appear in section 6.

5.1. ASN.1 Distinguished Encoding Representation

All uses of ASN.1 in server name, along with

Kohl & Neuman [Page 33]

RFC 1510 Kerberos shall use the Dis-
tinguished Encoding Representation of the data elements as
described in September 1993

the X.509 specification, section 8.7 [8].

5.2. ASN.1 Base Definitions

The following ASN.1 base definitions are used in client name, time and microsecond fields from the
rest of this section. Note that since Authenticator
match any recently-seen such tuples, the underscore char-
acter (_) KRB_AP_ERR_REPEAT error is
generated. If an incorrect sequence number is included, or a
sequence number is expected but not permitted in ASN.1 names, present, the hyphen (-) KRB_AP_ERR_BADORDER
error is
used in its place for generated. If neither a timestamp and usec or a sequence
number is present, a KRB_AP_ERR_MODIFIED error is generated.

If all the purposes of ASN.1 names.

Realm ::= GeneralString
PrincipalName ::= SEQUENCE {
name-type[0] INTEGER,
name-string[1] SEQUENCE OF GeneralString
}

Kerberos realms are encoded as GeneralStrings. Realms shall
not contain a character with checks succeed, the code 0 (the ASCII NUL).
Most realms will usually consist of several components
separated application can assume the message was
generated by periods (.), in its peer, and was securely transmitted (without
intruders able to see the style of Internet Domain
Names, or separated unencrypted contents).

3.6. The KRB_CRED Exchange

The KRB_CRED message may be used by slashes (/) in clients requiring the style of X.500
names. Acceptable forms for realm names are specified in
section 7. A PrincipalName is a typed sequence of com-
ponents consisting of ability to
send Kerberos credentials from one host to another. It achieves this
by sending the following sub-fields:

name-type This field specifies tickets together with encrypted data containing the type
session keys and other information associated with the tickets.

3.6.1. Generation of name that fol-
lows. Pre-defined values for this field are
specified in section 7.2. The name-type should be
treated as a hint. Ignoring KRB_CRED message

When an application wishes to send a KRB_CRED message it first (using
the name type, no two
names can KRB_TGS exchange) obtains credentials to be sent to the same (i.e. at least one of remote
host. It then constructs a KRB_CRED message using the
components, ticket or
tickets so obtained, placing the realm, must be different).

Section 5.2. - 37 - Expires 15 October 1993

Version 5 - Revision 5.2

This constraint may be eliminated session key needed to use each
ticket in the future.

name-stringThis key field encodes a of the corresponding KrbCredInfo sequence of components that
form a name,
the encrypted part of the the KRB_CRED message.

Other information associated with each component encoded as a General-
String. Taken together, a PrincipalName ticket and a
Realm form a principal identifier. Most Princi-
palNames will have only a few components (typi-
cally one or two).

KerberosTime ::= GeneralizedTime
-- Specifying UTC time zone (Z)

The timestamps used obtained during the
KRB_TGS exchange is also placed in Kerberos are encoded as General-
izedTimes. An encoding shall specify the UTC time zone (Z)
and shall not include any fractional portions corresponding KrbCredInfo
sequence in the encrypted part of the
seconds. It further shall not include any separators.
Example: KRB_CRED message. The only valid format for UTC current
time 6 minutes, 27
seconds after 9 pm on 6 November 1985 is 19851106210627Z.

HostAddress ::= SEQUENCE {
addr-type[0] INTEGER,
address[1] OCTET STRING
}

HostAddresses ::= SEQUENCE OF SEQUENCE {
addr-type[0] INTEGER,
address[1] OCTET STRING
}

The host adddress encodings consists of two fields:

addr-type This field specifies and, if specifically required by the type of address that
follows. Pre-defined values for this field application the nonce, s-
address, and raddress fields, are
specified placed in section 8.1.

address This field encodes a single address of type addr-
type.

The two forms differ slightly. HostAddress contains exactly
one address; HostAddresses contains a sequence of possibly
many addresses.

AuthorizationData ::= SEQUENCE OF SEQUENCE {
ad-type[0] INTEGER,
ad-data[1] OCTET STRING
}

ad-data This field contains authorization data to be
interpreted according to the value encrypted part of the

Section 5.2. - 38 - Expires 15 October 1993

Version 5 - Revision 5.2

corresponding ad-type field.

ad-type This field specifies the format for the ad-data
subfield. All negative values are reserved for
local use. Non-negative values are reserved for
registered use.

APOptions ::= BIT STRING {
reserved(0),
use-session-key(1),
mutual-required(2)
}

TicketFlags ::= BIT STRING {
reserved(0),
forwardable(1),
forwarded(2),
proxiable(3),
proxy(4),
may-postdate(5),
postdated(6),
invalid(7),
renewable(8),
initial(9),
pre-authent(10),
hw-authent(11)
}

KDCOptions ::= BIT STRING {
reserved(0),
forwardable(1),
forwarded(2),
proxiable(3),
proxy(4),
allow-postdate(5),
postdated(6),
unused7(7),
renewable(8),
unused9(9),
unused10(10),
unused11(11),
renewable-ok(27),
enc-tkt-in-skey(28),
renew(30),
validate(31)
}

LastReq ::= SEQUENCE OF SEQUENCE {
lr-type[0] INTEGER,
lr-value[1] KerberosTime
}

Section 5.2. - 39 - Expires 15 October 1993

Version 5 - Revision 5.2

lr-type This field indicates how the following lr-value
field
KRB_CRED message which is to be interpreted. Negative values indi-
cate that the information pertains only to then encrypted under an encryption key
previosuly exchanged in the
responding server. Non-negative values pertain to
all servers for KRB_AP exchange (usually the realm.

If last key
negotiated via subkeys, or the lr-type field is zero (0), then session key if no informa-
tion negotiation has
occured).

3.6.2. Receipt of KRB_CRED message

When an application receives a KRB_CRED message, it verifies it. If
any error occurs, an error code is conveyed reported for use by the lr-value subfield. If the
absolute value of the lr-type field
application. The message is one (1),
then verified by checking that the lr-value subfield is protocol
version and type fields match the time of last
initial request for current version and KRB_CRED,
respectively. A mismatch generates a TGT. If it is two (2), KRB_AP_ERR_BADVERSION or
KRB_AP_ERR_MSG_TYPE error. The application then decrypts the lr-value subfield is
ciphertext and processes the time of last initial
request. resultant plaintext. If it is three (3), then the lr-value
subfield is decryption shows
the time of issue for the newest
ticket-granting ticket used. If it data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is four (4),
then
generated.

Kohl & Neuman [Page 34]

RFC 1510 Kerberos September 1993

If present or required, the lr-value subfield is recipient verifies that the time operating
system's report of the last
renewal. sender's address matches the sender's address
in the message, and that one of the recipient's addresses appears as
the recipient's address in the message. A failed match for either
case generates a KRB_AP_ERR_BADADDR error. The timestamp and usec
fields (and the nonce field if required) are checked next. If it is five (5), then the lr-value
subfield
timestamp and usec are not present, or they are present but not
current, the KRB_AP_ERR_SKEW error is generated.

If all the time checks succeed, the application stores each of last request (of any
type).

lr-value This field contains the time new
tickets in its ticket cache together with the session key and other
information in the corresponding KrbCredInfo sequence from the
encrypted part of the last request. KRB_CRED message.

4. The time Kerberos Database

The Kerberos server must be interpreted according have access to a database containing the con-
tents
principal identifiers and secret keys of principals to be
authenticated (The implementation of the accompanying lr-type subfield.

See section 6 for Kerberos server need not
combine the definitions of Checksum, Check-
sumType, EncryptedData, EncryptionKey, EncryptionType, and
KeyType.

5.3. Tickets database and Authenticators

This section describes the format and encryption param-
eters for tickets and authenticators. When a ticket or
authenticator is included in a protocol message server on the same machine; it is
treated as an opaque object.

5.3.1. Tickets

A ticket is a record that helps a client authenticate
feasible to a service. A Ticket contains store the principal database in, say, a network name
service, as long as the entries stored therein are protected from
disclosure to and modification by unauthorized parties. However, we
recommend against such strategies, as they can make system management
and threat analysis quite complex.).

4.1. Database contents

A database entry should contain at least the following information:

Section 5.3.1. - 40 - Expires 15 October 1993

Version 5 - Revision 5.2

transited[4] TransitedEncoding,
authtime[5] KerberosTime,
starttime[6] KerberosTime OPTIONAL,
endtime[7] KerberosTime,
renew-till[8] KerberosTime OPTIONAL,
caddr[9] HostAddresses OPTIONAL,
authorization-data[10] AuthorizationData OPTIONAL
}
-- encoded Transited field
TransitedEncoding ::= SEQUENCE {
tr-type[0] INTEGER, -- must be registered
contents[1] OCTET STRING
} fields:

Field Value

name Principal's identifier
key Principal's secret key
p_kvno Principal's key version
max_life Maximum lifetime for Tickets
max_renewable_life Maximum total lifetime for renewable
Tickets

The name field is an encoding of EncTicketPart is encrypted in the principal's identifier. The key shared
by Kerberos and
field contains an encryption key. This key is the end server (the server's principal's secret key).
See section 6 for
key. (The key can be encrypted before storage under a Kerberos
"master key" to protect it in case the format of database is compromised but
the ciphertext.

tkt-vno This master key is not. In that case, an extra field specifies must be added to
indicate the master key version number for used, see below.) The p_kvno field is
the
ticket format. This document describes key version number 5.

realm This of the principal's secret key. The max_life
field specifies contains the realm that maximum allowable lifetime (endtime - starttime)
for any Ticket issued a
ticket. It also serves to identify for this principal. The max_renewable_life

Kohl & Neuman [Page 35]

RFC 1510 Kerberos September 1993

field contains the realm part maximum allowable total lifetime for any renewable
Ticket issued for this principal. (See section 3.1 for a description
of how these lifetimes are used in determining the server's principal identifier. Since lifetime of a
Kerberos
given Ticket.)

A server can may provide KDC service to several realms, as long as the
database representation provides a mechanism to distinguish between
principal records with identifiers which differ only issue tickets for servers
within its realm, in the two will always be identi-
cal.

sname This field specifies realm
name.

When an application server's key changes, if the name part change is routine
(i.e., not the result of disclosure of the server's
identity.

enc-part This field holds old key), the encrypted encoding old key
should be retained by the server until all tickets that had been
issued using that key have expired. Because of this, it is possible
for several keys to be active for a single principal. Ciphertext
encrypted in a principal's key is always tagged with the
EncTicketPart sequence.

flags This field indicates which version of various options were
used or requested when
the ticket key that was issued. It used for encryption, to help the recipient find the
proper key for decryption.

When more than one key is active for a bit-field, where particular principal, the selected options are
indicated by
principal will have more than one record in the bit being set (1), Kerberos database.
The keys and key version numbers will differ between the records (the
rest of the
unselected options and reserved fields being reset
(0). Bit 0 is may or may not be the same). Whenever Kerberos
issues a ticket, or responds to a request for initial authentication,
the most significant bit. The
encoding of recent key (known by the bits Kerberos server) will be used for
encryption. This is specified in section 5.2.
The flags are described in more detail above in
section 2. The meanings of the flags are:

Bit(s) Name Description

0 RESERVED Reserved key with the highest key version number.

4.2. Additional fields

Project Athena's KDC implementation uses additional fields in its
database:

Field Value

K_kvno Kerberos' key version
expiration Expiration date for future expansion entry
attributes Bit field of this
field.

Section 5.3.1. - 41 - Expires 15 October 1993

Version 5 - Revision 5.2

1 FORWARDABLE attributes
mod_date Timestamp of last modification
mod_name Modifying principal's identifier

The FORWARDABLE flag is normally only
interpreted by K_kvno field indicates the TGS, and can be
ignored by end servers. When set, this
flag tells key version of the ticket-granting server
that it Kerberos master key
under which the principal's secret key is OK encrypted.

After an entry's expiration date has passed, the KDC will return an
error to issue a new ticket-
granting ticket with a different network
address based on any client attempting to gain tickets as or for the presented ticket.

2 FORWARDED When set, this flag indicates that
principal. (A database may want to maintain two expiration dates:
one for the
ticket has either been forwarded or was
issued based on authentication involving
a forwarded ticket-granting ticket.

3 PROXIABLE The PROXIABLE flag is normally only
interpreted by the TGS, principal, and can be
ignored by end servers. The PROXIABLE
flag has an interpretation identical one for the principal's current key. This
allows password aging to
that work independently of the FORWARDABLE flag, except
that principal's

Kohl & Neuman [Page 36]

RFC 1510 Kerberos September 1993

expiration date. However, due to the PROXIABLE flag tells limited space in the
ticket-granting server that only non-
ticket-granting tickets may be issued
with different network addresses.

4 PROXY When set, this flag indicates that responses,
the KDC must combine the key expiration and principal expiration date
into a
ticket single value called "key_exp", which is used as a proxy.

5 MAY-POSTDATE hint to the
user to take administrative action.)

The MAY-POSTDATE flag attributes field is normally only
interpreted by a bitfield used to govern the TGS, and can operations
involving the principal. This field might be
ignored useful in conjunction
with user registration procedures, for site-specific policy
implementations (Project Athena currently uses it for their user
registration process controlled by end servers. This flag tells the ticket-granting server that system-wide database service,
Moira [7]), or to identify the "string to key" conversion algorithm
used for a post-
dated ticket may be issued based principal's key. (See the discussion of the padata field
in section 5.4.2 for details on why this
ticket-granting ticket.

6 POSTDATED This flag indicates that this ticket has
been postdated. The end-service can
check the authtime field be useful.) Other bits
are used to see when the
original authentication occurred.

7 INVALID This flag indicates indicate that a certain ticket is
invalid, and it must options should not be validated by the
KDC before use. Application servers
must reject
allowed in tickets encrypted under a principal's key (one bit each):
Disallow issuing postdated tickets, disallow issuing forwardable
tickets, disallow issuing tickets based on TGT authentication,
disallow issuing renewable tickets, disallow issuing proxiable
tickets, and disallow issuing tickets for which have this flag
set.

8 RENEWABLE The RENEWABLE flag the principal is normally only
interpreted by the TGS,
server.

The mod_date field contains the time of last modification of the
entry, and can usually
be ignored by end servers (some particu-
larly careful servers the mod_name field contains the name of the principal
which last modified the entry.

4.3. Frequently Changing Fields

Some KDC implementations may wish to disal-
low renewable tickets). A renewable
ticket can be used to obtain a replace-
ment ticket maintain the last time that expires at a later
date.

Section 5.3.1. - 42 - Expires 15 October 1993

Version 5 - Revision 5.2

9 INITIAL This flag indicates that this ticket
request was
issued using the AS protocol, and not
issued based on made by a ticket-granting
ticket.

10 PRE-AUTHENT This flag indicates particular principal. Information that during initial
authentication, the client was authenti-
cated by might
be maintained includes the KDC before a ticket was
issued. The strength time of the pre-
authentication method is not indicated,
but is acceptable to last request, the KDC.

11 HW-AUTHENT This flag indicates that time of the protocol
employed
last request for initial authentication
required a ticket-granting ticket, the time of the last use
of hardware expected to a ticket-granting ticket, or other times. This information can
then be possessed solely by the named client.
The hardware authentication method is
selected by returned to the KDC and the strength of user in the method last-req field (see section 5.2).

Other frequently changing information that can be maintained is not indicated.

12-31 RESERVED Reserved the
latest expiration time for future use.

key any tickets that have been issued using
each key. This field exists in the ticket and the KDC
response and is would be used to pass the session key from
Kerberos indicate how long old keys
must remain valid to allow the application server and continued use of outstanding tickets.

4.4. Site Constants

The KDC implementation should have the client. following configurable
constants or options, to allow an administrator to make and enforce
policy decisions:

+ The field's encoding is described in section 6.2.

crealm This field contains minimum supported lifetime (used to determine whether the name
KDC_ERR_NEVER_VALID error should be returned). This constant
should reflect reasonable expectations of round-trip time to the realm in which

Kohl & Neuman [Page 37]

RFC 1510 Kerberos September 1993

KDC, encryption/decryption time, and processing time by the client is registered
and in which initial
authentication took place.

cname This field contains the name part target server, and it should allow for a minimum "useful"
lifetime.

+ The maximum allowable total (renewable) lifetime of a ticket
(renew_till - starttime).

+ The maximum allowable lifetime of a ticket (endtime - starttime).

+ Whether to allow the client's
principal identifier.

transited This field lists the names issue of tickets with empty address fields
(including the Kerberos realms ability to specify that took part in authenticating such tickets may only be
issued if the user request specifies some authorization_data).

+ Whether proxiable, forwardable, renewable or post-datable tickets
are to whom
this ticket was be issued. It does not specify the
order in which the realms were transited. See
section 3.3.3.1 for details on how this field
encodes the traversed realms.

authtime This field indicates the time of initial authenti-
cation for the named principal. It is

5. Message Specifications

The following sections describe the time exact contents and encoding of
issue for the original ticket on which this ticket
is based. It is included
protocol messages and objects. The ASN.1 base definitions are
presented in the ticket to provide
additional information to first subsection. The remaining subsections specify
the end service, protocol objects (tickets and to
provide the necessary information for implementa-
tion authenticators) and messages.
Specification of a `hot list' service at encryption and checksum techniques, and the KDC. An end
service that is particularly paranoid could refuse

Section 5.3.1. - 43 - Expires 15 October 1993

Version 5 - Revision 5.2 fields
related to accept tickets for which the initial authenti-
cation occurred "too far" them, appear in the past.

This field is also returned as part section 6.

5.1. ASN.1 Distinguished Encoding Representation

All uses of ASN.1 in Kerberos shall use the
response from the KDC. When returned as part Distinguished Encoding
Representation of the response to initial authentication
(KRB_AS_REP), this is the current time on the Ker-
beros server[22].

starttime This field data elements as described in the ticket specifies the time after
which the ticket is valid. Together with endtime,
this field specifies X.509
specification, section 8.7 [8].

5.2. ASN.1 Base Definitions

The following ASN.1 base definitions are used in the life rest of this
section. Note that since the ticket. If
it underscore character (_) is absent from not
permitted in ASN.1 names, the ticket, hyphen (-) is used in its value should be
treated as that of the authtime field.

endtime This field contains the time after which the
ticket will not be honored (its expiration time).
Note that individual services may place their own
limits on for the life
purposes of a ticket and may reject
tickets which have ASN.1 names.

Realm ::= GeneralString
PrincipalName ::= SEQUENCE {
name-type[0] INTEGER,
name-string[1] SEQUENCE OF GeneralString
}

Kerberos realms are encoded as GeneralStrings. Realms shall not yet expired. As such, this
is really an upper bound on the expiration time
for
contain a character with the ticket.

renew-tillThis field is only present code 0 (the ASCII NUL). Most realms
will usually consist of several components separated by periods (.),
in tickets that have the RENEWABLE flag set style of Internet Domain Names, or separated by slashes (/) in

Kohl & Neuman [Page 38]

RFC 1510 Kerberos September 1993

the flags field. It
indicates the maximum endtime that may be included style of X.500 names. Acceptable forms for realm names are
specified in section 7. A PrincipalName is a renewal. It can be thought typed sequence of
components consisting of as the abso-
lute expiration time for the ticket, including all
renewals.

caddr following sub-fields:

name-type This field specifies the type of name that follows.
Pre-defined values for this field are
specified in section 7.2. The name-type should be
treated as a ticket contains zero (if omitted)
or more (if present) host addresses. These are
the addresses from which hint. Ignoring the ticket can be used.
If there are name type, no addresses, the ticket two
names can be used
from any location. The decision by the KDC to
issue same (i.e., at least one of the
components, or by the end server to accept zero-address
tickets is a policy decision and is left to the
Kerberos and end-service administrators; they realm, must be different).
This constraint may
refuse to issue or accept such tickets. The sug-
gested and default policy, however, is be eliminated in the future.

name-string This field encodes a sequence of components that such
tickets
form a name, each component encoded as a General
String. Taken together, a PrincipalName and a Realm
form a principal identifier. Most PrincipalNames
will have only be issued a few components (typically one or accepted when addi-
tional information that can be two).

KerberosTime ::= GeneralizedTime
-- Specifying UTC time zone (Z)

The timestamps used to restrict in Kerberos are encoded as GeneralizedTimes. An
encoding shall specify the use UTC time zone (Z) and shall not include
any fractional portions of the ticket is included in the
authorization_data field. Such a ticket is a
__________________________

[22] seconds. It is NOT recommended that this further shall not include
any separators. Example: The only valid format for UTC time value be used
to adjust the workstation's clock since 6
minutes, 27 seconds after 9 pm on 6 November 1985 is 19851106210627Z.

HostAddress ::= SEQUENCE {
addr-type[0] INTEGER,
address[1] OCTET STRING
}

HostAddresses ::= SEQUENCE OF SEQUENCE {
addr-type[0] INTEGER,
address[1] OCTET STRING
}

The host adddress encodings consists of two fields:

addr-type This field specifies the workstation
cannot reliably determine type of address that such a KRB_AS_REP actu-
ally came from the proper KDC in a timely manner.

Section 5.3.1. - 44 - Expires 15 October 1993

Version 5 - Revision 5.2

capability.

Network addresses
follows. Pre-defined values for this field are included
specified in the ticket to
make it harder for an attacker to use stolen
credentials. Because the session key is not sent
over the network in cleartext, credentials can't
be stolen simply by listening to the network; an
attacker has to gain access to the session key
(perhaps through operating system security
breaches or a careless user's unattended session)
to make use of stolen tickets.

It is important to note that the network section 8.1.

address
from which a connection is received cannot be
reliably determined. Even if it could be, an
attacker who has compromised the client's worksta-
tion could use the credentials from there.
Including the network addresses only makes it more
difficult, not impossible, for an attacker to walk
off with stolen credentials and then use them from This field encodes a "safe" location.

authorization-data single address of type addr-type.

The authorization-data two forms differ slightly. HostAddress contains exactly one

Kohl & Neuman [Page 39]

RFC 1510 Kerberos September 1993

address; HostAddresses contains a sequence of possibly many
addresses.

AuthorizationData ::= SEQUENCE OF SEQUENCE {
ad-type[0] INTEGER,
ad-data[1] OCTET STRING
}

ad-data This field is used to pass contains authorization data from the principal on whose
behalf a ticket was issued to the application ser-
vice. If no authorization data is included, this
field will be left out. The data in this field
are specific
interpreted according to the end service. It is expected
that the field will contain the names value of service
specific objects, and the rights to those objects.
The format for this
corresponding ad-type field.

ad-type This field is described in section
5.2. Although Kerberos is not concerned with specifies the format of the contents of for the subfields, it does
carry type information (ad-type).

By using ad-data
subfield. All negative values are reserved for
local use. Non-negative values are reserved for
registered use.

APOptions ::= BIT STRING {
reserved(0),
use-session-key(1),
mutual-required(2)
}

TicketFlags ::= BIT STRING {
reserved(0),
forwardable(1),
forwarded(2),
proxiable(3),
proxy(4),
may-postdate(5),
postdated(6),
invalid(7),
renewable(8),
initial(9),
pre-authent(10),
hw-authent(11)
}

KDCOptions ::= BIT STRING {
reserved(0),
forwardable(1),
forwarded(2),
proxiable(3),
proxy(4),
allow-postdate(5),
postdated(6),

Kohl & Neuman [Page 40]

RFC 1510 Kerberos September 1993

unused7(7),
renewable(8),
unused9(9),
unused10(10),
unused11(11),
renewable-ok(27),
enc-tkt-in-skey(28),
renew(30),
validate(31)
}

LastReq ::= SEQUENCE OF SEQUENCE {
lr-type[0] INTEGER,
lr-value[1] KerberosTime
}

lr-type This field indicates how the authorization_data field, a principal
is able to issue a proxy that following lr-value
field is valid for a
specific purpose. For example, a client wishing
to print a file can obtain a file server proxy to be passed interpreted. Negative values indicate
that the information pertains only to the print
responding server. By specifying the
name of the file in Non-negative values pertain to
all servers for the authorization_data field, realm.

If the file server knows that lr-type field is zero (0), then no information
is conveyed by the print server can
only use lr-value subfield. If the client's rights when accessing
absolute value of the
particular file to be printed.

It lr-type field is interesting to note that if one specifies (1),
then the authorization-data field lr-value subfield is the time of last
initial request for a proxy and leaves TGT. If it is two (2), then
the host addresses blank, lr-value subfield is the resulting ticket and
session key can be treated as a capability. See
[9] for some suggested uses time of this field.

The authorization-data field is optional and does

Section 5.3.1. - 45 - Expires 15 October 1993

Version 5 - Revision 5.2

not have to be included in a ticket.

5.3.2. Authenticators

An authenticator last initial
request. If it is a record sent with a ticket to a
server to certify three (3), then the client's knowledge lr-value
subfield is the time of issue for the encryption
key in newest
ticket-granting ticket used. If it is four (4),
then the ticket, to help lr-value subfield is the server detect replays, and to
help choose a "true session key" to use with time of the particular
session. The encoding last
renewal. If it is encrypted in the ticket's session
key shared by five (5), then the client and lr-value
subfield is the server:

-- Unencrypted authenticator
Authenticator ::= [APPLICATION 2] SEQUENCE {
authenticator-vno[0] INTEGER,
crealm[1] Realm,
cname[2] PrincipalName,
cksum[3] Checksum OPTIONAL,
cusec[4] INTEGER,
ctime[5] KerberosTime,
subkey[6] EncryptionKey OPTIONAL,
seq-number[7] INTEGER OPTIONAL,
authorization-data[8] AuthorizationData OPTIONAL
}

authenticator-vno time of last request (of any
type).

lr-value This field specifies contains the version number for time of the
format last request.
The time must be interpreted according to the contents
of the authenticator. This document speci-
fies version 5.

crealm accompanying lr-type subfield.

See section 6 for the definitions of Checksum, ChecksumType,
EncryptedData, EncryptionKey, EncryptionType, and cname
These fields are KeyType.

Kohl & Neuman [Page 41]

RFC 1510 Kerberos September 1993

5.3. Tickets and Authenticators

This section describes the same as those described format and encryption parameters for
the
tickets and authenticators. When a ticket or authenticator is
included in section a protocol message it is treated as an opaque object.

5.3.1.

cksum This field contains Tickets

A ticket is a checksum of the the applica-
tion data record that accompanies the KRB_AP_REQ.

cusec This field contains the microsecond part of the
client's timestamp. Its value (before encryption)
ranges from 0 to 999999. It often appears along
with ctime. The two fields are used together helps a client authenticate to
specify a reasonably accurate timestamp.

ctime This field service.
A Ticket contains the current time on the
client's host.

subkey This following information:

Ticket ::= [APPLICATION 1] SEQUENCE {
tkt-vno[0] INTEGER,
realm[1] Realm,
sname[2] PrincipalName,
enc-part[3] EncryptedData
}
-- Encrypted part of ticket
EncTicketPart ::= [APPLICATION 3] SEQUENCE {
flags[0] TicketFlags,
key[1] EncryptionKey,
crealm[2] Realm,
cname[3] PrincipalName,
transited[4] TransitedEncoding,
authtime[5] KerberosTime,
starttime[6] KerberosTime OPTIONAL,
endtime[7] KerberosTime,
renew-till[8] KerberosTime OPTIONAL,
caddr[9] HostAddresses OPTIONAL,
authorization-data[10] AuthorizationData OPTIONAL
}
-- encoded Transited field contains the client's choice for an
encryption key which is to
TransitedEncoding ::= SEQUENCE {
tr-type[0] INTEGER, -- must be used to protect this
specific application session. Unless an

Section 5.3.2. - 46 - Expires 15 October 1993

Version 5 - Revision 5.2

application specifies otherwise, if this field registered
contents[1] OCTET STRING
}

The encoding of EncTicketPart is
left out encrypted in the session key from the ticket will be
used.

seq-numberThis optional field includes the initial sequence
number to be used shared by
Kerberos and the KRB_PRIV or KRB_SAFE mes-
sages when sequence numbers are used to detect
replays (It may also be used by application
specific messages). When included in end server (the server's secret key). See section 6
for the authen-
ticator this format of the ciphertext.

tkt-vno This field specifies the initial sequence version number for messages from the client ticket
format. This document describes version number 5.

realm This field specifies the realm that issued a ticket. It
also serves to identify the server.
When included in the AP-REP message, the initial
sequence number is that for messages from realm part of the server's
principal identifier. Since a Kerberos server to the client. When used in KRB_PRIV or
KRB_SAFE messages, it is incremented by one after
each message is sent.

For sequence numbers to adequately support can only
issue tickets for servers within its realm, the
detection of replays they should be non-repeating,
even across connection boundaries. The initial
sequence number should two will

Kohl & Neuman [Page 42]

RFC 1510 Kerberos September 1993

always be random and uniformly
distributed across identical.

sname This field specifies the full space name part of possible
sequence numbers, so that it cannot be guessed by
an attacker and so that it and the successive
sequence numbers do not repeat other sequences.

authorization-data server's
identity.

enc-part This field is holds the same as described for encrypted encoding of the
EncTicketPart sequence.

flags This field indicates which of various options were used or
requested when the ticket
in section 5.3.1. was issued. It is optional and will only
appear when additional restrictions are to be
placed on the use of a ticket, beyond those car-
ried in bit-field,
where the ticket itself.

5.4. Specifications for selected options are indicated by the AS bit being
set (1), and TGS exchanges

This section specifies the format of the messages used
in exchange between the client unselected options and reserved fields
being reset (0). Bit 0 is the Kerberos server. most significant bit. The
format
encoding of possible error messages appears the bits is specified in section 5.9.1.

5.4.1. KRB_KDC_REQ definition 5.2. The KRB_KDC_REQ message has no type
flags are described in more detail above in section 2. The
meanings of its own.
Instead, its type is one the flags are:

Bit(s) Name Description

0 RESERVED Reserved for future expansion of KRB_AS_REQ or KRB_TGS_REQ
depending on whether this
field.

1 FORWARDABLE The FORWARDABLE flag is normally only
interpreted by the request TGS, and can be
ignored by end servers. When set,
this flag tells the ticket-granting
server that it is for an initial OK to issue a new
ticket- granting ticket or
an additional with a
different network address based on
the presented ticket. In either case,

2 FORWARDED When set, this flag indicates that
the message ticket has either been forwarded
or was issued based on authentication
involving a forwarded ticket-granting
ticket.

3 PROXIABLE The PROXIABLE flag is sent
from normally only
interpreted by the client TGS, and can be
ignored by end servers. The PROXIABLE
flag has an interpretation identical
to that of the Authentication Server to request
credentials for a service.

The message fields are:

AS-REQ ::= [APPLICATION 10] KDC-REQ
TGS-REQ ::= [APPLICATION 12] KDC-REQ

Section 5.4.1. - 47 - Expires 15 October FORWARDABLE flag,
except that the PROXIABLE flag tells
the ticket-granting server that only
non- ticket-granting tickets may be
issued with different network
addresses.

Kohl & Neuman [Page 43]

RFC 1510 Kerberos September 1993

Version

4 PROXY When set, this flag indicates that a
ticket is a proxy.

5 - Revision 5.2

KDC-REQ ::= SEQUENCE {
pvno[1] INTEGER,
msg-type[2] INTEGER,
padata[3] SEQUENCE OF PA-DATA OPTIONAL,
req-body[4] KDC-REQ-BODY
}

PA-DATA ::= SEQUENCE {
padata-type[1] INTEGER,
padata-value[2] OCTET STRING,
-- might be encoded AP-REQ
}

KDC-REQ-BODY ::= SEQUENCE {
kdc-options[0] KDCOptions,
cname[1] PrincipalName OPTIONAL,
-- Used MAY-POSTDATE The MAY-POSTDATE flag is normally
only in AS-REQ
realm[2] Realm, -- Server's realm
-- Also client's in AS-REQ
sname[3] PrincipalName OPTIONAL,
from[4] KerberosTime OPTIONAL,
till[5] KerberosTime,
rtime[6] KerberosTime OPTIONAL,
nonce[7] INTEGER,
etype[8] SEQUENCE OF INTEGER, -- EncryptionType,
-- in preference order
addresses[9] HostAddresses OPTIONAL,
enc-authorization-data[10] EncryptedData OPTIONAL,
-- Encrypted AuthorizationData encoding
additional-tickets[11] SEQUENCE OF Ticket OPTIONAL
}

The fields in this message are:

pvno This field is included in each message, and speci-
fies interpreted by the protocol version number. This document
specifies protocol version 5.

msg-type TGS, and can
be ignored by end servers. This field indicates flag
tells the type of ticket-granting server that
a protocol mes-
sage. It will almost always post- dated ticket may be issued
based on this ticket-granting ticket.

6 POSTDATED This flag indicates that this ticket
has been postdated. The end-service
can check the same as authtime field to see
when the
application identifier associated with original authentication
occurred.

7 INVALID This flag indicates that a message.
It ticket is included to make the identifier more readily
accessible to the application. For
invalid, and it must be validated by
the KDC-REQ
message, KDC before use. Application
servers must reject tickets which
have this type will be KRB_AS_REQ or
KRB_TGS_REQ.

padata flag set.

8 RENEWABLE The padata (pre-authentication data) field con-
tains a sequence of authentication information
which may RENEWABLE flag is normally only
interpreted by the TGS, and can
usually be needed before credentials ignored by end servers
(some particularly careful servers
may wish to disallow renewable
tickets). A renewable ticket can be
used to obtain a replacement ticket
that expires at a later date.

9 INITIAL This flag indicates that this ticket
was issued or decrypted. In using the case of requests for
additional tickets (KRB_TGS_REQ), this field will

Section 5.4.1. - 48 - Expires 15 October 1993

Version 5 - Revision 5.2

include an element with padata-type of PA-TGS-REQ AS protocol, and data of an authentication header (ticket-
granting
not issued based on a ticket-granting
ticket.

10 PRE-AUTHENT This flag indicates that during
initial authentication, the client
was authenticated by the KDC before a
ticket and authenticator). was issued. The checksum
in strength of
the authenticator (which must be collision-
proof) preauthentication method is not
indicated, but is acceptable to be computed over the KDC-REQ-BODY
encoding. In most requests
KDC.

11 HW-AUTHENT This flag indicates that the protocol
employed for initial authenti-
cation (KRB_AS_REQ) and most replies (KDC-REP), authentication
required the padata field will use of hardware expected
to be left out.

This field may also contain information needed possessed solely by
certain extensions to the named

Kohl & Neuman [Page 44]

RFC 1510 Kerberos protocol. For
example, it might be used to initially verify September 1993

client. The hardware authentication
method is selected by the
identity KDC and the
strength of a client before any response the method is
returned. not
indicated.

12-31 RESERVED Reserved for future use.

key This is accomplished with a padata field with padata-type equal to PA-ENC-TIMESTAMP exists in the ticket and padata-value defined as follows:

padata-type ::= PA-ENC-TIMESTAMP
padata-value ::= EncryptedData -- PA-ENC-TS-ENC

PA-ENC-TS-ENC ::= SEQUENCE {
patimestamp[0] KerberosTime, -- client's time
pausec[1] INTEGER OPTIONAL
}

with patimestamp containing the client's time KDC response and
pausec containing is
used to pass the microseconds which may be
omitted if a client will not generate more than
one request per second. The ciphertext (padata-
value) consists of session key from Kerberos to the PA-ENC-TS-ENC sequence,
encrypted using
application server and the client's secret key. client. The padata field's encoding is
described in section 6.2.

crealm This field can also contain information
needed to help the KDC or contains the client select name of the
key needed for generating or decrypting realm in which the
response.
client is registered and in which initial authentication
took place.

cname This form field contains the name part of the padata is useful for
supporting client's principal
identifier.

transited This field lists the use of certain "smartcards" with
Kerberos. The details names of such extensions are
beyond the scope of Kerberos realms that took
part in authenticating the user to whom this specification. ticket was
issued. It does not specify the order in which the realms
were transited. See [10] section 3.3.3.1 for additional uses of details on how
this field.

padata-type
The padata-type element of the padata field indi-
cates the way that the padata-value element is to
be interpreted. Negative values of padata-type
are reserved for unregistered use; non-negative
values are used for a registered interpretation of encodes the element type.

req-body traversed realms.

authtime This field is a placeholder delimiting indicates the extent time of initial authentication for
the remaining fields. If a checksum named principal. It is to be
calculated over the request, it is calculated over
an encoding time of issue for the KDC-REQ-BODY sequence
original ticket on which this ticket is

Section 5.4.1. - 49 - Expires 15 October 1993

Version 5 - Revision 5.2

enclosed within the req-body field.

kdc-options
This field appears based. It is
included in the KRB_AS_REQ and
KRB_TGS_REQ requests ticket to provide additional information to
the KDC end service, and indicates the
flags that the client wants set on the tickets as
well as other information that is to modify provide the
behavior necessary information
for implementation of a `hot list' service at the KDC. Where appropriate, the name
of an option may be the same as the flag An
end service that is
set by that option. Although in most case, particularly paranoid could refuse to
accept tickets for which the
bit initial authentication
occurred "too far" in the options past.

This field will be is also returned as part of the same response from
the KDC. When returned as that
in part of the flags field, response to initial
authentication (KRB_AS_REP), this is not guaranteed, so it the current time on
the Kerberos server (It is not acceptable NOT recommended that this time
value be used to simply copy adjust the options field
to workstation's clock since the flags field. There are various checks
workstation cannot reliably determine that
must be made before honoring an option anyway.

The kdc_options field is such a bit-field, where
KRB_AS_REP actually came from the
selected options are indicated by proper KDC in a timely
manner.).

starttime This field in the bit being
set (1), and ticket specifies the unselected options and reserved
fields being reset (0). The encoding of time after which the bits
ticket is specified in section 5.2. The options are
described in more detail above in section 2. The
meanings of valid. Together with endtime, this field
specifies the options are:

Bit(s)Name Description

0 RESERVED Reserved for future expansion life of this
field.

1 FORWARDABLE The FORWARDABLE option indicates that the ticket to be issued ticket. If it is to have absent from
the ticket, its
forwardable flag set. It may only value should be
set on the initial request, or in a sub-
sequent request if treated as that of the ticket-granting
ticket on

Kohl & Neuman [Page 45]

RFC 1510 Kerberos September 1993

authtime field.

endtime This field contains the time after which it is based is also for-
wardable.

2 FORWARDED The FORWARDED option is only specified
in a request to the ticket-granting
server and ticket will only
not be honored if (its expiration time). Note that individual
services may place their own limits on the
ticket-granting life of a ticket in the request
has its FORWARDABLE bit set. This
option indicates that
and may reject tickets which have not yet expired. As
such, this is a request
for forwarding. The address(es) of really an upper bound on the
host from which expiration time
for the resulting ticket ticket.

renew-till This field is
to be valid are included only present in the
addresses field of the request.

Section 5.4.1. - 50 - Expires 15 October 1993

Version 5 - Revision 5.2

3 PROXIABLE The PROXIABLE option indicates tickets that the
ticket to be issued is to have its prox-
iable the
RENEWABLE flag set. It may only be set on
the initial request, or in a subsequent
request if the ticket-granting ticket on
which it is based is also proxiable.

4 PROXY The PROXY option flags field. It indicates the
maximum endtime that this is
a request for a proxy. This option will
only may be honored if the ticket-granting
ticket included in the request has its PROXIABLE
bit set. The address(es) a renewal. It can
be thought of as the absolute expiration time for the
ticket, including all renewals.

caddr This field in a ticket contains zero (if omitted) or more
(if present) host addresses. These are the addresses from
which the resulting ticket is to can be
valid used. If there are included in no addresses,
the addresses
field of the request.

5 ALLOW-POSTDATE ticket can be used from any location. The ALLOW-POSTDATE option indicates that decision
by the ticket KDC to be issued issue or by the end server to accept zero-
address tickets is a policy decision and is left to have its
MAY-POSTDATE flag set. It may only be
set on the initial request,
Kerberos and end-service administrators; they may refuse to
issue or in a sub-
sequent request if the ticket-granting
ticket on which it is based also has its
MAY-POSTDATE flag set.

6 POSTDATED accept such tickets. The POSTDATED option indicates that this suggested and default
policy, however, is a request for a postdated ticket.
This option that such tickets will only be honored if the
ticket-granting ticket on which it is
based has its MAY-POSTDATE flag set.
The resulting ticket will also have its
INVALID flag set, and issued
or accepted when additional information that flag may can be
reset by a subsequent request used to
restrict the KDC
after use of the starttime ticket is included in the
authorization_data field. Such a ticket has
been reached.

7 UNUSED This option is presently unused.

8 RENEWABLE The RENEWABLE option indicates that a capability.

Network addresses are included in the ticket to be issued is make it
harder for an attacker to have its
RENEWABLE flag set. It may only be set
on the initial request, or when the
ticket-granting ticket on which use stolen credentials. Because
the
request is based is also renewable. If
this option session key is requested, then not sent over the rtime
field network in cleartext,
credentials can't be stolen simply by listening to the request contains
network; an attacker has to gain access to the
desired absolute expiration time for the
ticket.

9-26 RESERVED Reserved for future use.

Section 5.4.1. - 51 - Expires 15 October 1993

Version 5 - Revision 5.2

27 RENEWABLE-OK The RENEWABLE-OK option indicates session key
(perhaps through operating system security breaches or a
careless user's unattended session) to make use of stolen
tickets.

It is important to note that the network address from which
a
renewable ticket will connection is received cannot be acceptable reliably determined.
Even if a
ticket with it could be, an attacker who has compromised the requested life cannot
otherwise be provided. If a ticket with
client's workstation could use the requested life cannot be provided, credentials from there.
Including the network addresses only makes it more
difficult, not impossible, for an attacker to walk off with
stolen credentials and then use them from a "safe"
location.

Kohl & Neuman [Page 46]

RFC 1510 Kerberos September 1993

authorization-data The authorization-data field is used to pass
authorization data from the principal on whose behalf a renewable
ticket may be was issued
with a renew-till equal to the the
requested endtime. The value of the
renew-till application service. If no
authorization data is included, this field may still will be limited by
local limits, or limits selected by the
individual principal or server.

28 ENC-TKT-IN-SKEYThis option is used only by left
out. The data in this field are specific to the ticket-
granting end
service. The ENC-TKT-IN-SKEY
option indicates It is expected that the ticket for field will contain the
end server is
names of service specific objects, and the rights to be encrypted those
objects. The format for this field is described in section
5.2. Although Kerberos is not concerned with the
session key from format of
the additional ticket-
granting ticket provided.

29 RESERVED Reserved for future use.

30 RENEW This option is used only by contents of the ticket-
granting service. The RENEW option
indicates that subfields, it does carry type
information (ad-type).

By using the present request authorization_data field, a principal is
for able
to issue a renewal. The ticket provided proxy that is
encrypted in the secret key valid for the
server on which it is valid. This
option will only be honored if the
ticket a specific purpose. For
example, a client wishing to be renewed has its RENEWABLE
flag set and if the time in its renew-
till field has not passed. The ticket print a file can obtain a file
server proxy to be renewed is passed in to the padata
field as part print server. By
specifying the name of the authentication
header.

31 VALIDATE This option is used only by file in the ticket-
granting service. The VALIDATE option
indicates authorization_data
field, the file server knows that the request is to vali-
date a postdated ticket. It will print server can only
be honored if the ticket presented is
postdated, presently has its INVALID
flag set, and would be otherwise usable
at this time. A ticket cannot be vali-
dated before its starttime. The ticket
presented for validation is encrypted in
use the key of client's rights when accessing the server for which it is
valid and particular file
to be printed.

It is passed in interesting to note that if one specifies the padata
authorization-data field
as part of the authentication header.

cname a proxy and sname
These fields are leaves the same as those described for host
addresses blank, the resulting ticket in section 5.3.1. sname may only and session key can
be

Section 5.4.1. - 52 - Expires 15 October 1993

Version 5 - Revision 5.2

absent when the ENC-TKT-IN-SKEY option is speci-
fied. If absent, the name of the server is taken
from the name of the client in the ticket passed treated as additional-tickets.

enc-authorization-data a capability. See [9] for some suggested
uses of this field.

The enc-authorization-data, if present (and it can
only authorization-data field is optional and does not have
to be present included in the TGS_REQ form), a ticket.

5.3.2. Authenticators

An authenticator is an encod-
ing of a record sent with a ticket to a server to
certify the desired authorization-data encrypted
under client's knowledge of the sub-session encryption key if present in the
Authenticator, or alternatively from ticket,
to help the server detect replays, and to help choose a "true session
key
key" to use with the particular session. The encoding is encrypted
in the ticket-granting ticket, both from ticket's session key shared by the
padata field in client and the KRB_AP_REQ.

realm server:

Kohl & Neuman [Page 47]

RFC 1510 Kerberos September 1993

authorization-data[8] AuthorizationData OPTIONAL
}

authenticator-vno This field specifies the realm part version number for the
format of the
server's principal identifier. In authenticator. This document specifies
version 5.

crealm and cname These fields are the AS
exchange, this is also same as those described for the realm part
ticket in section 5.3.1.

cksum This field contains a checksum of the
client's principal identifier.

from the application data
that accompanies the KRB_AP_REQ.

cusec This field is included in contains the KRB_AS_REQ and
KRB_TGS_REQ ticket requests when microsecond part of the requested
ticket is client's
timestamp. Its value (before encryption) ranges from 0 to be postdated.
999999. It specifies often appears along with ctime. The two fields
are used together to specify a reasonably accurate
timestamp.

ctime This field contains the
desired start current time for on the requested ticket.

till client's host.

subkey This field contains the expiration date requested
by the client in a ticket request.

rtime This client's choice for an encryption
key which is to be used to protect this specific
application session. Unless an application specifies
otherwise, if this field is left out the requested renew-till time sent session key from a client to
the KDC in a ticket request. It
is optional.

nonce will be used.

seq-number This optional field is part of includes the KDC request and
response. It it intended to hold a random initial sequence number
generated
to be used by the client. If the same number is KRB_PRIV or KRB_SAFE messages when
sequence numbers are used to detect replays (It may also be
used by application specific messages). When included in
the encrypted response authenticator this field specifies the initial sequence
number for messages from the KDC,
it provides evidence that client to the response is fresh
and has not been replayed by an attacker. Nonces
must never be re-used. Ideally, it should be gen-
erated randomly, but if server. When
included in the correct time is known,
it may suffice[23].
__________________________

[23] Note, however, that if AP-REP message, the time initial sequence number
is used as the
nonce, one must make sure that for messages from the workstation time is
monotonically increasing. If server to the time client. When
used in KRB_PRIV or KRB_SAFE messages, it is ever reset
backwards, there incremented by
one after each message is a small, but finite, probability
that a nonce will sent.

For sequence numbers to adequately support the detection of
replays they should be reused.

Section 5.4.1. - 53 - Expires 15 October 1993

Version 5 - Revision 5.2

etype This field specifies non-repeating, even across
connection boundaries. The initial sequence number should
be random and uniformly distributed across the desired encryption algo-
rithm to full space
of possible sequence numbers, so that it cannot be used in guessed
by an attacker and so that it and the response.

addresses successive sequence
numbers do not repeat other sequences.

Kohl & Neuman [Page 48]

RFC 1510 Kerberos September 1993

authorization-data This field is included in the initial request for
tickets, and optionally included in requests same as described for
additional tickets from the ticket-granting
server. It specifies the addresses from which the
requested ticket
in section 5.3.1. It is to be valid. Normally it
includes the addresses for the client's host. If
a proxy is requested, this field optional and will contain
other addresses. The contents of this field only appear when
additional restrictions are
usually copied by the KDC into to be placed on the caddr field use of
the resulting ticket.

additional-tickets
Additional tickets may be optionally included in a
request to
ticket, beyond those carried in the ticket-granting server. If ticket itself.

5.4. Specifications for the
ENC-TKT-IN-SKEY option has been specified, then AS and TGS exchanges

This section specifies the session key from format of the additional ticket will be messages used in place of the server's key to encrypt exchange
between the
new ticket. If more than one option which
requires additional tickets has been specified,
then client and the additional tickets are used in the order
specified by the ordering Kerberos server. The format of the options bits (see
kdc-options, above). possible
error messages appears in section 5.9.1.

5.4.1. KRB_KDC_REQ definition

The application code will be either ten (10) KRB_KDC_REQ message has no type of its own. Instead, its type is
one of KRB_AS_REQ or twelve
(12) KRB_TGS_REQ depending on whether the request is
for an initial ticket (AS-REQ) or for an additional ticket (TGS-REQ).

The optional fields (addresses, authorization-data and
additional-tickets) are only included if necessary to per-
form the operation specified in the kdc-options field.

It should be noted that in KRB_TGS_REQ, the protocol
version number appears twice and two different message types
appear: the KRB_TGS_REQ message contains these fields as
does the authentication header (KRB_AP_REQ) that is passed
in ticket. In either case, the padata field.

5.4.2. KRB_KDC_REP definition

The KRB_KDC_REP
message format is used for the reply sent from the KDC for either an initial (AS) client to the Authentication Server to
request or a subse-
quent (TGS) request. There is no message type credentials for
KRB_KDC_REP. Instead, the type will be either KRB_AS_REP or
KRB_TGS_REP. a service.

The key used to encrypt the ciphertext part of
the reply depends on the message type. For KRB_AS_REP, the
ciphertext is encrypted fields are:

AS-REQ ::= [APPLICATION 10] KDC-REQ
TGS-REQ ::= [APPLICATION 12] KDC-REQ

KDC-REQ ::= SEQUENCE {
pvno[1] INTEGER,
msg-type[2] INTEGER,
padata[3] SEQUENCE OF PA-DATA OPTIONAL,
req-body[4] KDC-REQ-BODY
}

PA-DATA ::= SEQUENCE {
padata-type[1] INTEGER,
padata-value[2] OCTET STRING,
-- might be encoded AP-REQ
}

KDC-REQ-BODY ::= SEQUENCE {
kdc-options[0] KDCOptions,
cname[1] PrincipalName OPTIONAL,
-- Used only in the client's secret key, and the AS-REQ
realm[2] Realm, -- Server's realm
-- Also client's key version number is included in the key version
number for the encrypted data. For KRB_TGS_REP, the

Section 5.4.2. - 54 - Expires 15 October 1993

Version 5 - Revision 5.2

ciphertext is encrypted in the sub-session key from the
Authenticator, or if absent, the session key from the
ticket-granting ticket used in the request. In that case,
no version number will be present in the EncryptedData
sequence.

The KRB_KDC_REP message contains the following fields:

AS-REP ::= [APPLICATION 11] KDC-REP
TGS-REP ::= [APPLICATION 13] KDC-REP

KDC-REP ::= SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
padata[2] SEQUENCE OF PA-DATA OPTIONAL,
crealm[3] Realm,
cname[4] PrincipalName,
ticket[5] Ticket,
enc-part[6] EncryptedData
}

EncASRepPart ::= [APPLICATION 25[25]] EncKDCRepPart
EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart

EncKDCRepPart ::= SEQUENCE {
key[0] EncryptionKey,
last-req[1] LastReq,
nonce[2] INTEGER,
key-expiration[3] KerberosTime AS-REQ
sname[3] PrincipalName OPTIONAL,
flags[4] TicketFlags,
authtime[5] KerberosTime,
starttime[6]
from[4] KerberosTime OPTIONAL,
endtime[7]
till[5] KerberosTime,
renew-till[8]
rtime[6] KerberosTime OPTIONAL,
srealm[9] Realm,
sname[10] PrincipalName,
caddr[11]
nonce[7] INTEGER,

Kohl & Neuman [Page 49]

RFC 1510 Kerberos September 1993

etype[8] SEQUENCE OF INTEGER, -- EncryptionType,
-- in preference order
addresses[9] HostAddresses OPTIONAL,
enc-authorization-data[10] EncryptedData OPTIONAL,
-- Encrypted AuthorizationData encoding
additional-tickets[11] SEQUENCE OF Ticket OPTIONAL
}

pvno and msg-type
These

The fields are described above in section 5.4.1.
msg-type is either KRB_AS_REP or KRB_TGS_REP.

padata this message are:

pvno This field is described in detail included in section
5.4.1. One possible use for this each message, and specifies the
protocol version number. This document specifies protocol
version 5.

msg-type This field is to
encode an alternate "mix-in" string to be used
__________________________

[25] An application code in indicates the encrypted part type of a
message provides an additional check that protocol message. It
will almost always be the message
was decrypted properly.

Section 5.4.2. - 55 - Expires 15 October 1993

Version 5 - Revision 5.2 same as the application
identifier associated with a string-to-key algorithm (such as is
described in section 6.3.2). This ability message. It is use-
ful to ease transitions if a realm name needs included to
change (e.g. when a company is acquired); in such
a case all existing password-derived entries in
the KDC database would be flagged as needing a
special mix-in string until
make the next password
change.

crealm, cname, srealm and sname
These fields are identifier more readily accessible to the same as those described for
application. For the ticket in section 5.3.1.

ticket KDC-REQ message, this type will be
KRB_AS_REQ or KRB_TGS_REQ.

padata The newly-issued ticket, from section 5.3.1.

enc-part This padata (pre-authentication data) field is contains a place holder for the ciphertext
and related of
authentication information that forms which may be needed before
credentials can be issued or decrypted. In the encrypted
part of a message. The description case of the
encrypted part
requests for additional tickets (KRB_TGS_REQ), this field
will include an element with padata-type of the message follows each appear-
ance PA-TGS-REQ and
data of this field. an authentication header (ticket-granting ticket
and authenticator). The encrypted part is encoded
as described checksum in section 6.1.

key This field the authenticator
(which must be collisionproof) is to be computed over the same as described
KDC-REQ-BODY encoding. In most requests for initial
authentication (KRB_AS_REQ) and most replies (KDC-REP), the ticket
in section 5.3.1.

last-req
padata field will be left out.

This field is returned may also contain information needed by certain
extensions to the KDC and specifies Kerberos protocol. For example, it might
be used to initially verify the time(s) identity of the last request by a principal.
Depending on what information client before
any response is available, this
might be the last time that a request for returned. This is accomplished with a
ticket-granting ticket was made, or
padata field with padata-type equal to PA-ENC-TIMESTAMP and
padata-value defined as follows:

padata-type ::= PA-ENC-TIMESTAMP
padata-value ::= EncryptedData -- PA-ENC-TS-ENC

PA-ENC-TS-ENC ::= SEQUENCE {
patimestamp[0] KerberosTime, -- client's time
pausec[1] INTEGER OPTIONAL
}

Kohl & Neuman [Page 50]

RFC 1510 Kerberos September 1993

with patimestamp containing the last client's time
that and pausec
containing the microseconds which may be omitted if a
client will not generate more than one request based on a ticket-granting ticket
was successful. It also might cover all servers
for a realm, or just per second.
The ciphertext (padata-value) consists of the particular server. Some
implementations may display this PA-ENC-TS-ENC
sequence, encrypted using the client's secret key.

The padata field can also contain information needed to
help the user to aid in discovering unauthorized use of
one's identity. It is similar in spirit to KDC or the
last login time displayed when logging into
timesharing systems.

nonce client select the key needed for
generating or decrypting the response. This field form of the
padata is described above in section 5.4.1.

key-expiration useful for supporting the use of certain
"smartcards" with Kerberos. The key-expiration field is part details of such extensions
are beyond the response
from scope of this specification. See [10] for
additional uses of this field.

padata-type The padata-type element of the KDC and specifies padata field indicates the time
way that the
client's secret key padata-value element is due to expire. The expira-
tion might be the result interpreted.
Negative values of password aging or an
account expiration. This field will usually be

Section 5.4.2. - 56 - Expires 15 October 1993

Version 5 - Revision 5.2

left out padata-type are reserved for
unregistered use; non-negative values are used for a
registered interpretation of the TGS reply since the response to
the TGS request element type.

req-body This field is encrypted in a session key and
no client information need be retrieved from placeholder delimiting the
KDC database. It extent of the
remaining fields. If a checksum is up to be calculated over
the application client
(usually request, it is calculated over an encoding of the login program) to take appropriate
action (such as notifying KDC-
REQ-BODY sequence which is enclosed within the user) if req-body
field.

kdc-options This field appears in the expira-
tion time is imminent.

flags, authtime, starttime, endtime, renew-till KRB_AS_REQ and caddr
These fields are duplicates of those found in KRB_TGS_REQ
requests to the
encrypted portion of KDC and indicates the attached ticket (see sec-
tion 5.3.1), provided so flags that the client may verify
they match
wants set on the intended request and tickets as well as other information that
is to assist in
proper ticket caching. If modify the message is behavior of type
KRB_TGS_REP, the caddr field will only be filled
in if the request was for a proxy or forwarded
ticket, or if KDC. Where appropriate,
the user is substituting a subset name of an option may be the addresses from the ticket granting ticket. If same as the client-requested addresses are not present or
not used, then flag that is
set by that option. Although in most case, the addresses contained bit in the
ticket
options field will be the same as those included that in the
ticket-granting ticket.

5.5. Client/Server (CS) message specifications

This section specifies the format of the messages used
for the authentication of the client flags field,
this is not guaranteed, so it is not acceptable to simply
copy the application
server.

5.5.1. KRB_AP_REQ definition

The KRB_AP_REQ message contains the Kerberos protocol
version number, the message type KRB_AP_REQ, an options field to indicate any options in use, and the ticket and
authenticator themselves. The KRB_AP_REQ message is often
referred to as the "authentication header".

AP-REQ ::= [APPLICATION 14] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
ap-options[2] APOptions,
ticket[3] Ticket,
authenticator[4] EncryptedData
}

APOptions ::= BIT STRING {
reserved(0),
use-session-key(1),
mutual-required(2)
}

Section 5.5.1. - 57 - Expires 15 October 1993

Version 5 - Revision 5.2

pvno and msg-type
These fields flags field. There are described above in section 5.4.1.
msg-type is KRB_AP_REQ.

ap-optionsThis
various checks that must be made before honoring an option
anyway.

The kdc_options field appears in the application request
(KRB_AP_REQ) and affects the way the request is
processed. It is a bit-field, where the selected
options are indicated by the bit being set (1), and the
unselected options and reserved fields being reset (0).
The encoding of the bits is specified in section 5.2. The
options are described in more detail above in section 2.
The meanings of the options are:

Bit(s)Name

Kohl & Neuman [Page 51]

RFC 1510 Kerberos September 1993

Bit(s) Name Description

0 RESERVED Reserved for future expansion of this
field.

1 USE-SESSION-KEYThe USE-SESSION-KEY FORWARDABLE The FORWARDABLE option indicates that
the ticket the client to be issued is presenting to have its
forwardable flag set. It may only be
set on the initial request, or in a server
subsequent request if the ticket-
granting ticket on which it is encrypted based
is also forwardable.

2 FORWARDED The FORWARDED option is only specified
in a request to the session
key from the server's ticket-granting
ticket. When this option is not speci-
fied,
server and will only be honored if the
ticket-granting ticket is encrypted in the
server's secret key.

2 MUTUAL-REQUIREDThe MUTUAL-REQUIRED request
has its FORWARDABLE bit set. This
option tells the
server that the client requires mutual
authentication, and indicates that it must respond
with a KRB_AP_REP message.

3-31 RESERVED Reserved for future use.

ticket This field this is a ticket authenticating the client
to the server.

authenticator
This contains
request for forwarding. The
address(es) of the authenticator, host from which includes the client's choice of a subkey. Its encoding
resulting ticket is
described to be valid are
included in section 5.3.2.

5.5.2. KRB_AP_REP definition

The KRB_AP_REP message contains the Kerberos protocol
version number, addresses field of the message type, and an encrypted time-
stamp.
request.

3 PROXIABLE The message PROXIABLE option indicates that
the ticket to be issued is sent in in response to an application have its
proxiable flag set. It may only be set
on the initial request, or in a
subsequent request (KRB_AP_REQ) where if the mutual authentication ticket-
granting ticket on which it is based
is also proxiable.

4 PROXY The PROXY option
has been selected indicates that this
is a request for a proxy. This option
will only be honored if the ticket-
granting ticket in the ap-options field.

__________________________

Section 5.5.2. - 58 - Expires 15 October 1993

Version 5 - Revision 5.2

AP-REP ::= [APPLICATION 15] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
enc-part[2] EncryptedData
}

EncAPRepPart ::= [APPLICATION 27[27]] SEQUENCE {
ctime[0] KerberosTime,
cusec[1] INTEGER,
subkey[2] EncryptionKey OPTIONAL,
seq-number[3] INTEGER OPTIONAL
} request has its
PROXIABLE bit set. The encoded EncAPRepPart address(es) of
the host from which the resulting
ticket is encrypted to be valid are included in
the shared session
key addresses field of the ticket. request.

5 ALLOW-POSTDATE The optional subkey field can ALLOW-POSTDATE option indicates
that the ticket to be used in
an application-arranged negotiation issued is to choose a per associa-
tion session key.

pvno and msg-type
These fields are described above
have its MAY-POSTDATE flag set. It
may only be set on the initial
request, or in section 5.4.1.
msg-type a subsequent request if

Kohl & Neuman [Page 52]

RFC 1510 Kerberos September 1993

the ticket-granting ticket on which it
is KRB_AP_REP.

enc-part This field based also has its MAY-POSTDATE
flag set.

6 POSTDATED The POSTDATED option indicates that
this is described above in section 5.4.2.

ctime a request for a postdated
ticket. This field contains option will only be
honored if the current time ticket-granting ticket
on which it is based has its MAY-
POSTDATE flag set. The resulting
ticket will also have its INVALID flag
set, and that flag may be reset by a
subsequent request to the
client's host.

cusec This field contains KDC after
the microsecond part of starttime in the
client's timestamp.

subkey ticket has been
reached.

7 UNUSED This field contains an encryption key which option is presently unused.

8 RENEWABLE The RENEWABLE option indicates that
the ticket to be used issued is to protect this specific application ses-
sion. See section 3.2.6 for specifics have its
RENEWABLE flag set. It may only be
set on how this
field the initial request, or when
the ticket-granting ticket on which
the request is used to negotiate a key. Unless an
application specifies otherwise, if based is also
renewable. If this field option is
left out,
requested, then the sub-session key from rtime field in the authentica-
tor, or if also left out,
request contains the session key from desired absolute
expiration time for the ticket.

9-26 RESERVED Reserved for future use.

27 RENEWABLE-OK The RENEWABLE-OK option indicates that
a renewable ticket will be used.

5.5.3. Error message reply

If an error occurs while processing the application
__________________________
[27] An application code in the encrypted part of acceptable
if a
message provides an additional check that ticket with the message
was decrypted properly.

Section 5.5.3. - 59 - Expires 15 October 1993

Version 5 - Revision 5.2

request, requested life
cannot otherwise be provided. If a
ticket with the KRB_ERROR message will requested life cannot
be sent in response.
See section 5.9.1 for provided, then a renewable ticket
may be issued with a renew-till equal
to the format of the error message. requested endtime. The
cname and crealm fields
value of the renew-till field may
still be left out if limited by local limits, or
limits selected by the server cannot
determine their appropriate values from individual
principal or server.

28 ENC-TKT-IN-SKEY This option is used only by the corresponding
KRB_AP_REQ message. If
ticket-granting service. The ENC-
TKT-IN-SKEY option indicates that the authenticator was decipherable,
ticket for the ctime and cusec fields will contain end server is to be

Kohl & Neuman [Page 53]

RFC 1510 Kerberos September 1993

encrypted in the values session key from it.

5.6. KRB_SAFE message specification

This section specifies the format of a message that can
be
additional ticket-granting ticket
provided.

29 RESERVED Reserved for future use.

30 RENEW This option is used only by either side (client or server) of an application
to send a tamper-proof message to its peer. It presumes
that a session key has previously been exchanged (for exam-
ple, by using the KRB_AP_REQ/KRB_AP_REP messages).

5.6.1. KRB_SAFE definition
ticket-granting service. The KRB_SAFE message contains user data along with a
collision-proof checksum keyed with RENEW
option indicates that the session key. present
request is for a renewal. The
message fields are:

KRB-SAFE ::= [APPLICATION 20] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
safe-body[2] KRB-SAFE-BODY,
cksum[3] Checksum
}

KRB-SAFE-BODY ::= SEQUENCE {
user-data[0] OCTET STRING,
timestamp[1] KerberosTime OPTIONAL,
usec[2] INTEGER OPTIONAL,
seq-number[3] INTEGER OPTIONAL,
s-address[4] HostAddress,
r-address[5] HostAddress OPTIONAL
}

pvno and msg-type
These fields are described above in section 5.4.1.
msg-type is KRB_SAFE.

safe-body This field ticket
provided is a placeholder for encrypted in the body of secret
key for the
KRB-SAFE message. It server on which it is
valid. This option will only be
honored if the ticket to be encoded separately renewed
has its RENEWABLE flag set and then have if the checksum computed over it, for
use
time in the cksum field.

cksum This its renew till field contains the checksum of the applica-
tion data. Checksum details are described in sec-
tion 6.4. has not
passed. The checksum ticket to be renewed is computed over
passed in the

Section 5.6.1. - 60 - Expires 15 October 1993

Version 5 - Revision 5.2

encoding padata field as part of
the KRB-SAFE-BODY sequence.

user-data authentication header.

31 VALIDATE This field option is part of used only by the KRB_SAFE and KRB_PRIV
messages
ticket-granting service. The VALIDATE
option indicates that the request is
to validate a postdated ticket. It
will only be honored if the ticket
presented is postdated, presently has
its INVALID flag set, and contain would be
otherwise usable at this time. A
ticket cannot be validated before its
starttime. The ticket presented for
validation is encrypted in the application specific data
that key of
the server for which it is valid and
is being passed from the sender to in the reci-
pient.

timestamp This padata field is as part
of the KRB_SAFE authentication header.

cname and KRB_PRIV
messages. Its contents sname These fields are the current time same as
known by the sender of those described for the message. By checking
ticket in section 5.3.1. sname may only be absent when the timestamp,
ENC-TKT-IN-SKEY option is specified. If absent, the recipient name
of the message server is
able to make sure that taken from the name of the client in the
ticket passed as additional-tickets.

enc-authorization-data The enc-authorization-data, if present (and it was recently generated,
and is not a replay.

usec This field
can only be present in the TGS_REQ form), is part an encoding of
the KRB_SAFE and KRB_PRIV
headers. It contains desired authorization-data encrypted under the microsecond part of sub-
session key if present in the
timestamp.

seq-number
This Authenticator, or
alternatively from the session key in the ticket-granting
ticket, both from the padata field is described above in section 5.3.2.

s-address the KRB_AP_REQ.

Kohl & Neuman [Page 54]

RFC 1510 Kerberos September 1993

realm This field specifies the address in use by realm part of the
sender server's
principal identifier. In the AS exchange, this is also the
realm part of the message.

r-address client's principal identifier.

from This field specifies the address is included in use by the
recipient of KRB_AS_REQ and KRB_TGS_REQ
ticket requests when the message. It may requested ticket is to be omitted
postdated. It specifies the desired start time for
some uses (such as broadcast protocols), but the
recipient may arbitrarily reject such messages.
requested ticket.

till This field along with s-address can be used to
help detect messages which have been incorrectly
or maliciously delivered to contains the wrong recipient.

5.7. KRB_PRIV message specification expiration date requested by the
client in a ticket request.

rtime This section specifies field is the format of requested renew-till time sent from a message that can
be used by either side (client or server) of an application
client to securely and privately send the KDC in a message to its peer. ticket request. It
presumes that is optional.

nonce This field is part of the KDC request and response. It it
intended to hold a session key has previously been exchanged
(for example, random number generated by using the KRB_AP_REQ/KRB_AP_REP messages).

5.7.1. KRB_PRIV definition

The KRB_PRIV message contains user data encrypted in client.
If the Session Key. The message fields are:

__________________________

[29] An application code same number is included in the encrypted part of a
message response
from the KDC, it provides an additional check evidence that the message

Section 5.7.1. - 61 - Expires 15 October 1993

Version 5 - Revision 5.2

KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
enc-part[3] EncryptedData
}

EncKrbPrivPart ::= [APPLICATION 28[29]] SEQUENCE {
user-data[0] OCTET STRING,
timestamp[1] KerberosTime OPTIONAL,
usec[2] INTEGER OPTIONAL,
seq-number[3] INTEGER OPTIONAL,
s-address[4] HostAddress, -- sender's addr
r-address[5] HostAddress OPTIONAL -- recip's addr
}

pvno and msg-type
These fields are described above in section 5.4.1.
msg-type response is KRB_PRIV.

enc-part This field holds
fresh and has not been replayed by an encoding of attacker. Nonces
must never be re-used. Ideally, it should be gen erated
randomly, but if the EncKrbPrivPart
sequence encrypted under correct time is known, it may suffice
(Note, however, that if the session key[30].
This encrypted encoding time is used for the enc-part
field of as the KRB-PRIV message. See section 6 for nonce, one
must make sure that the format of workstation time is monotonically
increasing. If the ciphertext.

user-data, timestamp, usec, s-address and r-address
These fields are described above in section 5.6.1.

seq-number
This field time is described above in section 5.3.2.

5.8. KRB_CRED message specification ever reset backwards, there is
a small, but finite, probability that a nonce will be
reused.).

etype This section field specifies the format of a message that can desired encryption algorithm to be
used to send Kerberos credentials from one principal to
another. It is presented here to encourage a common
__________________________
was decrypted properly.

[30] If supported by in the encryption method response.

addresses This field is included in use, an
initialization vector may be passed to the encryption
procedure, initial request for tickets,
and optionally included in order to achieve proper cipher chaining.
The initialization vector might come requests for additional tickets
from the last
block of ticket-granting server. It specifies the ciphertext
addresses from which the previous KRB_PRIV mes-
sage, but it requested ticket is the application's choice whether or not to use such an initialization vector. If left out, be valid.
Normally it includes the
default initialization vector addresses for the encryption algo-
rithm will be used.

Section 5.8. - 62 - Expires 15 October 1993

Version 5 - Revision 5.2

mechanism to be used by applications when forwarding tickets
or providing proxies to subordinate servers. It presumes
that client's host.
If a session key has already been exchanged perhaps proxy is requested, this field will contain other
addresses. The contents of this field are usually copied
by
using the KRB_AP_REQ/KRB_AP_REP messages.

5.8.1. KRB_CRED definition

The KRB_CRED message contains a sequence KDC into the caddr field of the resulting ticket.

additional-tickets Additional tickets to may be sent and information needed optionally included in a
request to use the tickets, including ticket-granting server. If the ENC-TKT-IN-
SKEY option has been specified, then the session key from each. The information needed to use
the tickets is encryped under an encryption key previously
exchanged. The message fields are:

KRB-CRED ::= [APPLICATION 22] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER, -- KRB_CRED
tickets[2] SEQUENCE OF Ticket,
enc-part[3] EncryptedData
}

EncKrbCredPart ::= [APPLICATION 29] SEQUENCE {
ticket-info[0] SEQUENCE OF KrbCredInfo,
nonce[1] INTEGER OPTIONAL,
timestamp[2] KerberosTime OPTIONAL,
usec[3] INTEGER OPTIONAL,
s-address[4] HostAddress OPTIONAL,
r-address[5] HostAddress OPTIONAL
}

KrbCredInfo ::= SEQUENCE {
key[0] EncryptionKey,
prealm[1] Realm OPTIONAL,
pname[2] PrincipalName OPTIONAL,
flags[3] TicketFlags OPTIONAL,
authtime[4] KerberosTime OPTIONAL,
starttime[5] KerberosTime OPTIONAL,
endtime[6] KerberosTime OPTIONAL
renew-till[7] KerberosTime OPTIONAL,
srealm[8] Realm OPTIONAL,
sname[9] PrincipalName OPTIONAL,
caddr[10] HostAddresses OPTIONAL
}

pvno and msg-type
These fields are described above additional ticket will be used in section 5.4.1.
msg-type is KRB_CRED.

tickets
These are place of the tickets obtained from server's
key to encrypt the KDC

Section 5.8.1. - 63 - Expires 15 October 1993

Version 5 - Revision 5.2

specifically for use by new ticket. If more than one option
which requires additional tickets has been specified, then
the intended recipient.
Successive additional tickets are paired with the correspond-
ing KrbCredInfo sequence from used in the enc-part of order specified by
the
KRB-CRED message.

enc-part This field holds an encoding ordering of the EncKrbCredPart
sequence encrypted under the session key shared
between the sender and options bits (see kdc-options, above).

Kohl & Neuman [Page 55]

RFC 1510 Kerberos September 1993

The application code will be either ten (10) or twelve (12) depending
on whether the intended recipient.
This encrypted encoding request is used for the enc-part
field of the KRB-CRED message. See section 6 an initial ticket (AS-REQ) or for an
additional ticket (TGS-REQ).

The optional fields (addresses, authorization-data and additional-
tickets) are only included if necessary to perform the format of operation
specified in the ciphertext.

nonce If practical, an application may require the
inclusion of a nonce generated by the recipient of kdc-options field.

It should be noted that in KRB_TGS_REQ, the message. If protocol version number
appears twice and two different message types appear: the same value is included KRB_TGS_REQ
message contains these fields as does the
nonce in the message, it provides evidence authentication header
(KRB_AP_REQ) that is passed in the padata field.

5.4.2. KRB_KDC_REP definition

The KRB_KDC_REP message format is fresh and has not been replayed by
an attacker. A nonce must never be re-used; it
should be generated randomly by used for the recipient of reply from the KDC for
either an initial (AS) request or a subsequent (TGS) request. There
is no message and provided type for KRB_KDC_REP. Instead, the type will be either
KRB_AS_REP or KRB_TGS_REP. The key used to encrypt the sender ciphertext
part of the mes-
sage in an application specific manner.

timestamp and usec

These fields specify the time that reply depends on the KRB-CRED message was generated. The time is used to pro-
vide assurance that type. For KRB_AS_REP, the message
ciphertext is fresh.

s-address and r-address
These fields are described above encrypted in section 5.6.1.
They are used optionally to provide additional
assurance of the integrity of client's secret key, and the KRB-CRED mes-
sage. client's
key This field exists version number is included in the corresponding ticket
passed by key version number for the KRB-CRED message and
encrypted data. For KRB_TGS_REP, the ciphertext is used to pass encrypted in the
sub-session key from the Authenticator, or if absent, the session key
from the sender to ticket-granting ticket used in the intended
recipient. The field's encoding is described request. In that case,
no version number will be present in
section 6.2.

The following fields are optional. If present, they
can be associated with the credentials in the remote ticket
file. If left out, then it is assumed that the recipient of the credentials already knows their value.

prealm and pname EncryptedData sequence.

The name and realm of KRB_KDC_REP message contains the delegated principal
identity.

Section 5.8.1. - 64 - Expires 15 October following fields:

AS-REP ::= [APPLICATION 11] KDC-REP
TGS-REP ::= [APPLICATION 13] KDC-REP

KDC-REP ::= SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
padata[2] SEQUENCE OF PA-DATA OPTIONAL,
crealm[3] Realm,
cname[4] PrincipalName,
ticket[5] Ticket,
enc-part[6] EncryptedData
}

EncASRepPart ::= [APPLICATION 25[25]] EncKDCRepPart
EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart

EncKDCRepPart ::= SEQUENCE {
key[0] EncryptionKey,
last-req[1] LastReq,

Kohl & Neuman [Page 56]

RFC 1510 Kerberos September 1993

Version 5 - Revision 5.2

flags, authtime, starttime, endtime, renew-till, srealm,
sname, and caddr
These fields contain the values of the correspond-
ing fields from

nonce[2] INTEGER,
key-expiration[3] KerberosTime OPTIONAL,
flags[4] TicketFlags,
authtime[5] KerberosTime,
starttime[6] KerberosTime OPTIONAL,
endtime[7] KerberosTime,
renew-till[8] KerberosTime OPTIONAL,
srealm[9] Realm,
sname[10] PrincipalName,
caddr[11] HostAddresses OPTIONAL
}

NOTE: In EncASRepPart, the ticket found application code in the ticket
field. Descriptions encrypted
part of a message provides an additional check that
the message was decrypted properly.

pvno and msg-type These fields are identical
to the descriptions described above in the KDC-REP message.

5.9. Error message specification section 5.4.1.
msg-type is either KRB_AS_REP or KRB_TGS_REP.

padata This field is described in detail in section specifies the format 5.4.1. One
possible use for the KRB_ERROR
message. The fields included in the message are intended this field is to
return as much information as possible about encode an error. It alternate
"mix-in" string to be used with a string-to-key algorithm
(such as is not expected that described in section 6.3.2). This ability is
useful to ease transitions if a realm name needs to change
(e.g., when a company is acquired); in such a case all
existing password-derived entries in the information required by KDC database would
be flagged as needing a special mix-in string until the
next password change.

crealm, cname, srealm and sname These fields will be available are the same as those
described for all types of errors. If the
appropriate information ticket in section 5.3.1.

ticket The newly-issued ticket, from section 5.3.1.

enc-part This field is not available when a place holder for the message is
composed, ciphertext and related
information that forms the corresponding field will be left out encrypted part of the a message.

Note that since
The description of the encrypted part of the KRB_ERROR message
follows each appearance of this field. The encrypted part
is not protected
by any encryption, it encoded as described in section 6.1.

key This field is quite possible the same as described for an intruder to
synthesize or modify such a message. In particular, this
means that the client should not use any fields ticket in
section 5.3.1.

last-req This field is returned by the KDC and specifies the time(s)
of the last request by a principal. Depending on what
information is available, this mes-
sage might be the last time that
a request for security-critical purposes, such as setting a sys-
tem clock ticket-granting ticket was made, or generating the
last time that a fresh authenticator. The message
can be useful, however, request based on a ticket-granting ticket

Kohl & Neuman [Page 57]

RFC 1510 Kerberos September 1993

was successful. It also might cover all servers for advising a user on the reason
for some failure.

5.9.1. KRB_ERROR definition

The KRB_ERROR message consists of
realm, or just the following fields:

KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
ctime[2] KerberosTime OPTIONAL,
cusec[3] INTEGER OPTIONAL,
stime[4] KerberosTime,
susec[5] INTEGER,
error-code[6] INTEGER,
crealm[7] Realm OPTIONAL,
cname[8] PrincipalName OPTIONAL,
realm[9] Realm, -- Correct realm
sname[10] PrincipalName, -- Correct name
e-text[11] GeneralString OPTIONAL,
e-data[12] OCTET STRING OPTIONAL
}

pvno and msg-type
These fields are described above particular server. Some implementations
may display this information to the user to aid in section 5.4.1.
msg-type
discovering unauthorized use of one's identity. It is KRB_ERROR.

Section 5.9.1. - 65 - Expires 15 October 1993

Version 5 - Revision 5.2

ctime
similar in spirit to the last login time displayed when
logging into timesharing systems.

nonce This field is described above in section 5.4.1.

cusec This

key-expiration The key-expiration field is described above in section 5.5.2.

stime This field contains part of the response from
the KDC and specifies the current time on that the
server. It client's secret key
is due to expire. The expiration might be the result of type KerberosTime.

susec
password aging or an account expiration. This field contains the microsecond part will
usually be left out of the
server's timestamp. Its value ranges from 0 TGS reply since the response to
999. It appears along with stime. The two fields
are used
the TGS request is encrypted in conjunction to specify a reasonably
accurate timestamp.

error-codeThis field contains the error code returned by
Kerberos or session key and no client
information need be retrieved from the server when a request fails. To
interpret KDC database. It is
up to the value of this field see application client (usually the list of
error codes in section 8. Implementations are
encouraged login program) to provide for national language sup-
port in
take appropriate action (such as notifying the display of error messages.

crealm, cname, srealm user) if the
expira tion time is imminent.

flags, authtime, starttime, endtime, renew-till and sname caddr These
fields are described above duplicates of those found in the encrypted
portion of the attached ticket (see section 5.3.1.

e-text This field contains additional text to help
explain 5.3.1),
provided so the error code associated with client may verify they match the failed intended
request (for example, it might include a principal
name which was unknown).

e-data This and to assist in proper ticket caching. If the
message is of type KRB_TGS_REP, the caddr field contains additional data about will only
be filled in if the
error request was for use by a proxy or forwarded
ticket, or if the application to help it
recover user is substituting a subset of the
addresses from or handle the error. ticket granting ticket. If the error-
code is KDC_ERR_PREAUTH_REQUIRED, client-
requested addresses are not present or not used, then the e-data
field
addresses contained in the ticket will contain an encoding of a sequence be the same as those
included in the ticket-granting ticket.

5.5. Client/Server (CS) message specifications

This section specifies the format of
padata fields, each corresponding to an acceptable
pre-authentication method and optionally contain-
ing data the messages used for the method:

METHOD-DATA ::= SEQUENCE
authentication of PA-DATA

If the error-code is KRB_AP_ERR_METHOD, then client to the
e-data field will contain application server.

5.5.1. KRB_AP_REQ definition

The KRB_AP_REQ message contains the Kerberos protocol version number,
the message type KRB_AP_REQ, an encoding of options field to indicate any options
in use, and the fol-
lowing sequence:

METHOD-DATA ticket and authenticator themselves. The KRB_AP_REQ
message is often referred to as the "authentication header".

AP-REQ ::= [APPLICATION 14] SEQUENCE {
method-type[0]
pvno[0] INTEGER,

Section 5.9.1. - 66 - Expires 15 October
msg-type[1] INTEGER,

Kohl & Neuman [Page 58]

RFC 1510 Kerberos September 1993

Version 5 - Revision 5.2

method-data[1] OCTET

ap-options[2] APOptions,
ticket[3] Ticket,
authenticator[4] EncryptedData
}

APOptions ::= BIT STRING OPTIONAL {
reserved(0),
use-session-key(1),
mutual-required(2)
}

method-type will indicate the required alternate
method; method-data will contain any required
additional information.

6. Encryption

pvno and Checksum Specifications

The Kerberos protocols msg-type These fields are described above in this document are
designed to use stream encryption ciphers, which can be
simulated using commonly available block encryption ciphers,
such as the Data Encryption Standard [11], section 5.4.1.
msg-type is KRB_AP_REQ.

ap-options This field appears in conjunction
with block chaining the application request (KRB_AP_REQ)
and checksum methods [12]. Encryption affects the way the request is used to prove processed. It is a
bit-field, where the identities of selected options are indicated by the network entities par-
ticipating in message exchanges.
bit being set (1), and the unselected options and reserved
fields being reset (0). The Key Distribution
Center for each realm encoding of the bits is trusted by all principals
registered in that realm to store a secret key
specified in confi-
dence. Proof section 5.2. The meanings of knowledge the options are:

Bit(s) Name Description

0 RESERVED Reserved for future expansion of
this secret key field.

1 USE-SESSION-KEYThe USE-SESSION-KEY option indicates
that the ticket the client is used
presenting to
verify the authenticity of a principal.

The KDC uses the principal's secret key (in server is encrypted in
the AS
exchange) or a shared session key (in from the TGS exchange) to
encrypt responses to ticket requests; server's
ticket-granting ticket. When this
option is not specified, the ability to obtain ticket is
encrypted in the server's secret key or session key implies the knowledge of the
appropriate keys and the identity of key.

2 MUTUAL-REQUIREDThe MUTUAL-REQUIRED option tells the KDC. The ability
of a principal to decrypt
server that the KDC response client requires mutual
authentication, and present that it must
respond with a
Ticket and KRB_AP_REP message.

3-31 RESERVED Reserved for future use.

ticket This field is a properly formed Authenticator (generated with
the session key from ticket authenticating the KDC response) client to a service verifies the identity of
server.

authenticator This contains the principal; likewise authenticator, which includes the ability
client's choice of a subkey. Its encoding is described in
section 5.3.2.

Kohl & Neuman [Page 59]

RFC 1510 Kerberos September 1993

5.5.2. KRB_AP_REP definition

The KRB_AP_REP message contains the
service to extract the session key from Kerberos protocol version number,
the Ticket message type, and prove
its knowledge thereof an encrypted timestamp. The message is sent in
in a response verifies the identity of to an application request (KRB_AP_REQ) where the service.

The Kerberos protocols generally assume that mutual
authentication option has been selected in the
encryption used is secure from cryptanalysis; however, ap-options field.

AP-REP ::= [APPLICATION 15] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
enc-part[2] EncryptedData
}

EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
ctime[0] KerberosTime,
cusec[1] INTEGER,
subkey[2] EncryptionKey OPTIONAL,
seq-number[3] INTEGER OPTIONAL
}

NOTE: in
some cases, EncAPRepPart, the order of fields application code in the encrypted portions part of
messages are arranged to minimize
a message provides an additional check that the effects of poorly
chosen keys. It message was decrypted
properly.

The encoded EncAPRepPart is still important to choose good keys. If
keys are derived from user-typed passwords, those passwords
need to be well chosen to make brute force attacks more dif-
ficult. Poorly chosen keys still make easy targets for
intruders.

The following sections specify the encryption and
checksum mechanisms currently defined for Kerberos. The
encodings, chaining, and padding requirements for each are
described. For encryption methods, it is often desirable to
place random information (often referred to as a confounder)
at encrypted in the start shared session key of
the message. ticket. The requirements for optional subkey field can be used in an
application-arranged negotiation to choose a con-
founder per association session
key.

pvno and msg-type These fields are specified with each encryption mechanism.

Section 6. - 67 - Expires 15 October 1993

Version 5 - Revision 5.2

Some encryption systems use a block-chaining method to
improve described above in section 5.4.1.
msg-type is KRB_AP_REP.

enc-part This field is described above in section 5.4.2.

ctime This field contains the current time on the security characteristics of client's host.

cusec This field contains the ciphertext.
However, these chaining methods often don't provide an
integrity check upon decryption. Such systems (such as DES
in CBC mode) must be augmented with a checksum microsecond part of the plain-
text client's
timestamp.

subkey This field contains an encryption key which can is to be verified at decryption and used
to detect
any tampering or damage. Such checksums should be good at
detecting burst errors in the input. If any damage is
detected, the decryption routine protect this specific application session. See section
3.2.6 for specifics on how this field is expected used to return negotiate
a key. Unless an
error indicating the failure of an integrity check. Each
encryption type is expected to provide and verify an
appropriate checksum. The specification of each encryption
method sets out its checksum requirements.

Finally, where a key application specifies otherwise, if this
field is to be derived from a user's
password, an algorithm for converting left out, the password to a sub-session key
of from the appropriate type is included. It is desirable for
authenticator, or if also left out, the string to session key function to from
the ticket will be one-way, and for used.

Kohl & Neuman [Page 60]

RFC 1510 Kerberos September 1993

5.5.3. Error message reply

If an error occurs while processing the map-
ping to application request, the
KRB_ERROR message will be different in different realms. This is important
because users who are registered sent in more than one realm will
often use response. See section 5.9.1 for
the same password in each, format of the error message. The cname and it is desirable
that an attacker compromising crealm fields may be
left out if the Kerberos server in one
realm not obtain or derive cannot determine their appropriate values from
the user's key in another.

For an discussion of corresponding KRB_AP_REQ message. If the integrity characteristics of authenticator was
decipherable, the candidate encryption ctime and checksum methods considered for
Kerberos, the cusec fields will contain the reader is referred to [13].

6.1. Encryption Specifications

The following ASN.1 definition describes all encrypted
messages. The enc-part field which appears in values from
it.

5.6. KRB_SAFE message specification

This section specifies the unen-
crypted part format of messages in section 5 is a sequence consist-
ing message that can be used by
either side (client or server) of an encryption type, an optional key version number,
and application to send a tamper-
proof message to its peer. It presumes that a session key has
previously been exchanged (for example, by using the ciphertext.

EncryptedData
KRB_AP_REQ/KRB_AP_REP messages).

5.6.1. KRB_SAFE definition

The KRB_SAFE message contains user data along with a collision-proof
checksum keyed with the session key. The message fields are:

KRB-SAFE ::= [APPLICATION 20] SEQUENCE {
etype[0]
pvno[0] INTEGER, -- EncryptionType
kvno[1]
msg-type[1] INTEGER,
safe-body[2] KRB-SAFE-BODY,
cksum[3] Checksum
}

KRB-SAFE-BODY ::= SEQUENCE {
user-data[0] OCTET STRING,
timestamp[1] KerberosTime OPTIONAL,
usec[2] INTEGER OPTIONAL,
cipher[2] OCTET STRING -- ciphertext
seq-number[3] INTEGER OPTIONAL,
s-address[4] HostAddress,
r-address[5] HostAddress OPTIONAL
}

etype

pvno and msg-type These fields are described above in section 5.4.1.
msg-type is KRB_SAFE.

safe-body This field identifies which encryption algorithm
was used is a placeholder for the body of the KRB-SAFE
message. It is to encipher be encoded separately and then have the cipher. Detailed specif-
ications
checksum computed over it, for selected encryption types appear
later use in this section.

kvno the cksum field.

cksum This field contains the version number checksum of the key
under which data is encrypted. It is only present application data.
Checksum details are described in messages encrypted under long lasting keys,
such as principals' secret keys.

Section 6.1. - 68 - Expires 15 October section 6.4. The

Kohl & Neuman [Page 61]

RFC 1510 Kerberos September 1993

Version 5 - Revision 5.2

cipher

checksum is computed over the encoding of the KRB-SAFE-BODY
sequence.

user-data This field contains is part of the enciphered text, encoded
as an OCTET STRING.

The cipher field KRB_SAFE and KRB_PRIV messages
and contain the application specific data that is generated by applying being
passed from the specified
encryption algorithm sender to data composed the recipient.

timestamp This field is part of the message