view Side-By-Side changes
INTERNET-DRAFT Clifford Neuman
John Kohl
Theodore Ts'o
Tom Yu
Sam Hartman
Ken Raeburn
February 22,
Jeffrey Altman
September 9, 2002
Expires 22 August, 2002 9 March, 2003
The Kerberos Network Authentication Service (V5)
draft-ietf-krb-wg-kerberos-clarifications-00.txt
draft-ietf-krb-wg-kerberos-clarifications-01.txt
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
The distribution of this memo is unlimited. It is filed as
draft-ietf-krb-wg-kerberos-clarifications-00.txt,
draft-ietf-krb-wg-kerberos-clarifications-01.txt, and expires August 22,
2002. 9 March
2003. Please send comments to: ietf-krb-wg@anl.gov
<mailto:ietf-krb-wg@anl.gov>
ABSTRACT
This document provides an overview and specification of Version 5 of the
Kerberos protocol, and updates RFC1510 to clarify aspects of the
protocol and its intended use that require more detailed or clearer
explanation than was provided in RFC1510. This document is intended to
provide a detailed description of the protocol, suitable for
implementation, together with descriptions of the appropriate use of
protocol messages and fields within those messages.
This document contains a subset of the changes considered and discussed
in the Kerberos working group and is intended as an interim description
of Kerberos. Additional changes to the Kerberos protocol have been
proposed and will appear in a subsequent extensions document.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
This document is not intended to describe Kerberos to the end user,
system administrator, or application developer. Higher level papers
describing Version 5 of the Kerberos system [NT94] and documenting
version 4 [SNS88], are available elsewhere.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
OVERVIEW
This INTERNET-DRAFT describes the concepts and model upon which the
Kerberos network authentication system is based. It also specifies
Version 5 of the Kerberos protocol.
The motivations, goals, assumptions, and rationale behind most design
decisions are treated cursorily; they are more fully described in a
paper available in IEEE communications [NT94] and earlier in the
Kerberos portion of the Athena Technical Plan [MNSS87]. The protocols
have been a proposed standard and are being considered for advancement
for draft standard through the IETF standard process. Comments are
encouraged on the presentation, but only minor refinements to the
protocol as implemented or extensions that fit within current protocol
framework will be considered at this time.
Requests for addition to an electronic mailing list for discussion of
Kerberos, kerberos@MIT.EDU, may be addressed to kerberos-request@MIT.EDU. kerberos-request@MIT.EDU
<mailto: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.
info-kerberos@MIT.EDU <mailto:info-kerberos@MIT.EDU>.
BACKGROUND
The Kerberos model is based in part on Needham and Schroeder's trusted
third-party authentication protocol [NS78] and on modifications
suggested by Denning and Sacco [DS81]. The original design and
implementation of Kerberos Versions 1 through 4 was the work of two
former Project Athena staff members, Steve Miller of Digital Equipment
Corporation and Clifford Neuman (now at the Information Sciences
Institute of the University of Southern California), along with Jerome
Saltzer, Technical Director of Project Athena, and Jeffrey Schiller, MIT
Campus Network Manager. Many other members of Project Athena have also
contributed to the work on Kerberos.
Version 5 of the Kerberos protocol (described in this document) has
evolved from Version 4 based on new requirements and desires for
features not available in Version 4. The design of Version 5 of the
Kerberos protocol was led by Clifford Neuman and John Kohl with much
input from the community. The development of the MIT reference
implementation was led at MIT by John Kohl and Theodore T'so, with help
and contributed code from many others. Since RFC1510 was issued,
extensions and revisions to the protocol have been proposed by many
individuals. Some of these proposals are reflected in this document.
Where such changes involved significant effort, the document cites the
contribution of the proposer.
Reference implementations of both version 4 and version 5 of Kerberos
are publicly available and commercial implementations have been
developed and are widely used. Details on the differences between
Kerberos Versions 4 and 5 can be found in [KNT92].
draft-ietf-krb-wg-kerberos-clarifications-00
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 22 August 2002 9 March 2003
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 assertions by the host
operating system, without basing trust on host addresses, without
requiring physical security of all the hosts on the network, and under
the assumption that packets traveling along the network can be read,
modified, and inserted at
will[1.1]. will[1.1] <#fn1.1>. Kerberos performs
authentication under these conditions as a trusted third-party
authentication service by using conventional (shared secret key [1.2]) [1.2]
<#fn1.2>) cryptography. Kerberos extensions (outside the scope of this
document) can provide for the use of public key cryptography during
certain phases of the authentication protocol [@RFCE: if PKINIT advances
concurrently include reference to the RFC here]. Such extensions support
Kerberos authentication for users registered with public key
certification authorities and provide certain benefits of public key
cryptography in situations where they are needed.
The basic Kerberos authentication process proceeds as follows: A client
sends a request to the authentication server (AS) requesting
"credentials" for a given server. The AS responds with these
credentials, encrypted in the client's key. The credentials consist of a
"ticket" for the server and a temporary encryption key (often called a
"session key"). The client transmits the ticket (which contains the
client's identity and a copy of the session key, all encrypted in the
server's key) to the server. The session key (now shared by the client
and server) is used to authenticate the client, and may optionally be
used to authenticate the server. It may also be used to encrypt further
communication between the two parties or to exchange a separate
sub-session key to be used to encrypt further communication.
Implementation of the basic protocol consists of one or more
authentication servers running on physically secure hosts. The
authentication servers maintain a database of principals (i.e., users
and servers) and their secret keys. Code libraries provide encryption
and implement the Kerberos protocol. In order to add authentication to
its transactions, a typical network application adds one or two calls to
the Kerberos library directly or through the Generic Security Services
Application Programming Interface, GSSAPI, described in separate
document [ref to GSSAPI RFC]. These calls result in the transmission of
the necessary messages to achieve authentication.
The Kerberos protocol consists of several sub-protocols (or exchanges).
There are two basic methods by which a client can ask a Kerberos server
for credentials. In the first approach, the client sends a cleartext
request for a ticket for the desired server to the AS. The reply is sent
encrypted in the client's secret key. Usually this request is for a
ticket-granting ticket (TGT) which can later be used with the
ticket-granting server (TGS). In the second method, the client sends a
request to the TGS. The client uses the TGT to authenticate itself to
the TGS in the same manner as if it were contacting any other
application server that requires Kerberos authentication. The reply is
encrypted in the session key from the TGT. Though the protocol
specification describes the AS and the TGS as separate servers, they are
implemented in practice as different protocol entry points within a
single Kerberos server.
draft-ietf-krb-wg-kerberos-clarifications-00
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 22 August 2002 9 March 2003
Once obtained, credentials may be used to verify the identity of the
principals in a transaction, to ensure the integrity of messages
exchanged between them, or to preserve privacy of the messages. The
application is free to choose whatever protection may be necessary.
To verify the identities of the principals in a transaction, the client
transmits the ticket to the application server. Since the ticket is sent
"in the clear" (parts of it are encrypted, but this encryption doesn't
thwart replay) and might be intercepted and reused by an attacker,
additional information is sent to prove that the message originated with
the principal to whom the ticket was issued. This information (called
the authenticator) is encrypted in the session key, and includes a
timestamp. The timestamp proves that the message was recently generated
and is not a replay. Encrypting the authenticator in the session key
proves that it was generated by a party possessing the session key.
Since no one except the requesting principal and the server know the
session key (it is never sent over the network in the clear) this
guarantees the identity of the client.
The integrity of the messages exchanged between principals can also be
guaranteed using the session key (passed in the ticket and contained in
the credentials). This approach provides detection of both replay
attacks and message stream modification attacks. It is accomplished by
generating and transmitting a collision-proof checksum (elsewhere called
a hash or digest function) of the client's message, keyed with the
session key. Privacy and integrity of the messages exchanged between
principals can be secured by encrypting the data to be passed using the
session key contained in the ticket or the sub-session key found in the
authenticator.
The authentication exchanges mentioned above require read-only access to
the Kerberos database. Sometimes, however, the entries in the database
must be modified, such as when adding new principals or changing a
principal's key. This is done using a protocol between a client and a
third Kerberos server, the Kerberos Administration Server (KADM). There
is also a protocol for maintaining multiple copies of the Kerberos
database. Neither of these protocols are described in this document.
1.1. Cross-realm operation
The Kerberos protocol is designed to operate across organizational
boundaries. A client in one organization can be authenticated to a
server in another. Each organization wishing to run a Kerberos server
establishes its own "realm". The name of the realm in which a client is
registered is part of the client's name, and can be used by the
end-service to decide whether to honor a request.
By establishing "inter-realm" keys, the administrators of two realms can
allow a client authenticated in the local realm to prove its identity to
servers in other realms[1.3]. realms[1.3] <#fn1.3>. The exchange of inter-realm keys
(a separate key may be used for each direction) registers the
ticket-granting service of each realm as a principal in the other realm.
A client is then able to obtain a ticket-granting ticket for the remote
realm's ticket-granting service from its local realm. When that
ticket-granting ticket is used, the remote ticket-granting service uses
the inter-realm key (which usually differs from its own normal TGS key)
to decrypt the ticket-granting ticket, and is thus certain that it was
issued by the client's own TGS. Tickets issued by the remote
ticket-granting service will indicate to the end-service that the client
was authenticated from another realm.
draft-ietf-krb-wg-kerberos-clarifications-00
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 22 August 2002 9 March 2003
A realm is said to communicate with another realm if the two realms
share an inter-realm key, or if the local realm shares an inter-realm
key with an intermediate realm that communicates with the remote realm.
An authentication path is the sequence of intermediate realms that are
transited in communicating from one realm to another.
Realms 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 authentication path to be easily constructed. If a
hierarchical organization is not used, it may be necessary to consult a
database in order to construct an authentication path between realms.
Although realms are typically hierarchical, intermediate realms may be
bypassed to achieve cross-realm authentication through alternate
authentication paths (these might be established to make communication
between two realms more efficient). It is important for the end-service
to know which realms were transited when deciding how much faith to
place in the authentication process. To facilitate this decision, a
field in each ticket contains the names of the realms that were involved
in authenticating the client.
The application server is ultimately responsible for accepting or
rejecting authentication and should check the transited field. The
application server may choose to rely on the KDC for the application
server's realm to check the transited field. The application server's
KDC will set the TRANSITED-POLICY-CHECKED flag in this case. The KDC's
for intermediate realms may also check the transited field as they issue
ticket-granting-tickets for other realms, but they are encouraged not to
do so. A client may request that the KDC's not check the transited field
by setting the DISABLE-TRANSITED-CHECK flag. KDC's are encouraged but
not required to honor this flag.
1.2. Choosing a principal with which to communicate
The Kerberos protocol provides the means for verifying (subject to the
assumptions in 1.4) that the entity with which one communicates is the
same entity that was registered with the KDC using the claimed identity
(principal name). It is still necessary to determine whether that
identity corresponds to the entity with which one intends to communicate.
When appropriate data has been exchanged in advance, this determination
may be performed syntactically by the application based on the
application protocol specification, information provided by the user,
and configuration files. For example, the server principal name
(including realm) for a telnet server might be derived from the user
specified host name (from the telnet command line), the "host/" prefix
specified in the application protocol specification, and a mapping to a
Kerberos realm derived syntactically from the domain part of the
specified hostname and information from the local Kerberos realms database.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
One can also rely on trusted third parties to make this determination,
but only when the data obtained from the third party is suitably
integrity protected wile resident on the third party server and when
transmitted. Thus, for example, one should not rely on an unprotected
domain name system record to map a host alias to the primary name of a
server, accepting the primary name as the party one intends to contact,
since an attacker can modify the mapping and impersonate the party with
which one intended to communicate.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
1.3. Authorization
As an authentication service, Kerberos provides a means of verifying the
identity of principals on a network. Authentication is usually useful
primarily as a first step in the process of authorization, determining
whether a client may use a service, which objects the client is allowed
to access, and the type of access allowed for each. Kerberos does not,
by itself, provide authorization. Possession of a client ticket for a
service provides only for authentication of the client to that service,
and in the absence of a separate authorization procedure, it should not
be considered by an application as authorizing the use of that service.
Such separate authorization methods may be implemented as application
specific access control functions and may utilize files on the
application server, or on separately issued authorization credentials
such as those based on proxies [Neu93], or on other authorization
services. Separately authenticated authorization credentials may be
embedded in a tickets authorization data when encapsulated by the
kdc-issued authorization data element.
Applications should not accept the mere issuance of a service ticket by
the Kerberos server (even by a modified Kerberos server) as granting
authority to use the service, since such applications may become
vulnerable to the bypass of this authorization check in an environment
if they interoperate with other KDCs or where other options for
application authentication (e.g. the PKTAPP proposal) are provided.
[Section 1.4 is replaced in the extensions document <krbext1.4-1.html>]
1.4. Extending Kerberos Without Breaking Interoperability
As the deployed base of Kerberos implementations grows, extending
Kerberos becomes more important. Unfortunately some extensions to the
existing Kerberos protocol create interoperability issues because of
uncertainty regarding the treatment of certain extensibility options by
some implementations. This section includes guidelines that will enable
future implementations to maintain interoperability.
Kerberos provides a general mechanism for protocol extensibility. Some
protocol messages contain typed holes -- sub-messages that contain an
octet-string along with an integer that defines how to interpret the
octet-string. The integer types are registered centrally, but can be
used both for vendor extensions and for extensions standardized through
the IETF.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
1.4.1. Compatibility with RFC 1510
It is important to note that existing Kerberos message formats can not
be readily extended by adding fields to the ASN.1 types. Sending
additional fields often results in the entire message being discarded
without an error indication. Future versions of this specification will
provide guidelines to ensure that ASN.1 fields can be added without
creating an interoperability problem.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
In the meantime, all new or modified implementations of Kerberos that
receive an unknown message extension should preserve the encoding of the
extension but otherwise ignore the presence of the extension. Recipients
MUST NOT decline a request simply because an extension is present.
There is one exception to this rule. If an unknown authorization data
element type is received by a server other than the ticket granting
service either in an AP-REQ or in a ticket contained in an AP-REQ, then
authentication SHOULD fail. Authorization One of the primary uses of authorization
data is intended to restrict the use of the ticket. If the service cannot
determine whether the restriction applies to that service then a
security weakness may result if the ticket can be used for that service.
Authorization elements that are optional can should be enclosed in the
AD-IF-RELEVANT element.
The ticket granting service must ignore but propagate to derivative
tickets any unknown authorization data types, unless those data types
are embedded in a MANDATORY-FOR-KDC element, in which case the request
will be rejected. This behavior is appropriate because requiring that
the ticket granting service understand unknown authorization data types
would require that KDC software be upgraded to understand new
application-level restrictions before applications used these
restrictions, decreasing the utility of authorization data as a
mechanism for restricting the use of tickets. No security problem is
created because services to which the tickets are issued will verify the
authorization data.
Implementation note: Many RFC 1510 implementations ignore unknown
authorization data elements. Depending on these implementations to honor
authorization data restrictions may create a security weakness.
1.4.2. Sending Extensible Messages
Care must be taken to ensure that old implementations can understand
messages sent to them even if they do not understand an extension that
is used. Unless the sender knows an extension is supported, the
extension cannot change the semantics of the core message or previously
defined extensions.
For example, an extension including key information necessary to decrypt
the encrypted part of a KDC-REP could only be used in situations where
the recipient was known to support the extension. Thus when designing
such extensions it is important to provide a way for the recipient to
notify the sender of support for the extension. For example in the case
of an extension that changes the KDC-REP reply key, the client could
indicate support for the extension by including a padata element in the
AS-REQ sequence. The KDC should only use the extension if this padata
element is present in the AS-REQ. Even if policy requires the use of the
extension, it is better to return an error indicating that the extension
is required than to use the extension when the recipient may not support
it; debugging why implementations do not interoperate is easier when
errors are returned.
draft-ietf-krb-wg-kerberos-clarifications-00
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 22 August 2002 9 March 2003
1.6. Environmental assumptions
Kerberos imposes a few assumptions on the environment in which it can
properly function:
* "Denial of service" attacks are not solved with Kerberos. There
are places in the protocols where an intruder can prevent an
application from participating in the proper authentication steps.
Detection and solution of such attacks (some of which can appear
to be not-uncommon "normal" failure modes for the system) is
usually best left to the human administrators and users.
* Principals must keep their secret keys secret. If an intruder
somehow steals a principal's key, it will be able to masquerade as
that principal or impersonate any server to the legitimate principal.
* "Password guessing" attacks are not solved by Kerberos. If a user
chooses a poor password, it is possible for an attacker to
successfully mount an offline dictionary attack by repeatedly
attempting to decrypt, with successive entries from a dictionary,
messages obtained which are encrypted under a key derived from the
user's password.
* Each host on the network must have a clock which is "loosely
synchronized" to the time of the other hosts; this synchronization
is used to reduce the bookkeeping needs of application servers
when they do replay detection. The degree of "looseness" can be
configured on a per-server basis, but is typically on the order of
5 minutes. If the clocks are synchronized over the network, the
clock synchronization protocol must itself be secured from network
attackers.
* Principal identifiers are not recycled on a short-term basis. A
typical mode of access control will use access control lists
(ACLs) to grant permissions to particular principals. If a stale
ACL entry remains for a deleted principal and the principal
identifier is reused, the new principal will inherit rights
specified in the stale ACL entry. By not re-using principal
identifiers, the danger of inadvertent access is removed.
1.7. Glossary of terms
Below is a list of terms used throughout this document.
Authentication
Verifying the claimed identity of a principal. Authentication header
A record containing a Ticket and an Authenticator to be presented to
a server as part of the authentication process.
Authentication path
A sequence of intermediate realms transited in the authentication
process when communicating from one realm to another.
Authenticator
A record containing information that can be shown to have been
recently generated using the session key known only by the client
and server.
Authorization
The process of determining whether a client may use a service, which
objects the client is allowed to access, and the type of access
allowed for each.
draft-ietf-krb-wg-kerberos-clarifications-00
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 22 August 2002 9 March 2003
Capability
A token that grants the bearer permission to access an object or
service. In Kerberos, this might be a ticket whose use is restricted
by the contents of the authorization data field, but which lists no
network addresses, together with the session key necessary to use
the ticket.
Ciphertext
The output of an encryption function. Encryption transforms
plaintext into ciphertext.
Client
A process that makes use of a network service on behalf of a user.
Note that in some cases a Server may itself be a client of some
other server (e.g. a print server may be a client of a file server).
Credentials
A ticket plus the secret session key necessary to 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 host
on which it runs. The KDC services both initial ticket and
ticket-granting ticket requests. The initial ticket portion is
sometimes referred to as the Authentication Server (or service). The
ticket-granting ticket portion is sometimes referred to as the
ticket-granting server (or service).
Kerberos
Aside from the 3-headed dog guarding Hades, the name given to
Project Athena's authentication service, the protocol used by that
service, or the code used to implement the authentication service.
Plaintext
The input to an encryption function or the output of a decryption
function. Decryption transforms ciphertext into plaintext.
Principal
A named client or server entity that participates in a network
communication, with one name that is considered canonical.
Principal identifier
The canonical name used to uniquely identify each different principal. Seal
To encipher a record containing several fields in such a way that
the fields cannot be individually replaced without either knowledge
of the encryption key or leaving evidence of tampering.
Secret key
An encryption key shared by a principal and the KDC, distributed
outside the bounds of the system, with a long lifetime. In the case
of a human user's principal, the secret key may be derived from a
password.
Server
A particular Principal which provides a resource to network clients.
The server is sometimes referred to as the Application Server.
Service
A resource provided to network clients; often provided by more than
one server (for example, remote file service).
Session key
A temporary encryption key used between two principals, with a
lifetime limited to the duration of a single login "session".
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
Sub-session key
A temporary encryption key used between two principals, selected and
exchanged by the principals using the session key, and with a
lifetime limited to the duration of a single association.
Ticket
A record that helps a client authenticate itself to a server; it
contains the client's identity, a session key, a timestamp, and
other information, all sealed using the server's secret key. It only
serves to authenticate a client when presented along with a fresh
Authenticator.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
2. Ticket flag uses and requests
Each Kerberos ticket contains a set of flags which are used to indicate
attributes of that ticket. Most flags may be requested by a client when
the ticket is obtained; some are automatically turned on and off by a
Kerberos server as required. The following sections explain what the
various flags mean and give examples of reasons to use them. With the
exception of the ANONYMOUS and INVALID flags clients MUST ignore ticket
flags that are not recognized. KDCs MUST ignore KDC options that are not
recognized. Some implementations of RFC 1510 are known to reject unknown
KDC options, so clients may need to resend a request without KDC new
options absent if the request was rejected when sent with option added
since RFC 1510.
Since new KDCs will ignore unknown options, clients MUST confirm that
the ticket returned by the KDC meets their needs. For example, as
discussed in section 2.8, a client requiring anonymous communication
needs to make sure that the ticket is actually anonymous. A KDC that
prohibits issuing of anonymous tickets or that does not understand the
anonymous option would not return an anonymous ticket.
Note that it is not in general possible to determine whether an option
was not honored because it was not understood or because it was rejected
either through configuration or policy. When adding a new option to the
Kerberos protocol, designers should consider whether the distinction is
important for their option. In cases where it is, a mechanism for the
KDC to return an indication that the option was understood but rejected
needs to be provided in the specification of the option. Often in such
cases, the mechanism needs to be broad enough to permit an error or
reason to be returned.
2.1. Initial, pre-authenticated, and hardware authenticated tickets
The INITIAL flag indicates that a ticket was issued using the AS
protocol and not issued based on a ticket-granting ticket. Application
servers that want to require the demonstrated knowledge of a client's
secret key (e.g. a password-changing program) can insist that this flag
be set in any tickets they accept, and thus be assured that the client's
key was recently presented to the application client.
The PRE-AUTHENT and HW-AUTHENT flags provide additional information
about the initial authentication, regardless of whether the current
ticket was issued directly (in which case INITIAL will also be set) or
issued on the basis of a ticket-granting ticket (in which case the
INITIAL flag is clear, but the PRE-AUTHENT and HW-AUTHENT flags are
carried forward from the ticket-granting ticket).
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
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 must be validated by the
KDC before use, by presenting them to the KDC in a TGS request with the
VALIDATE option specified. The KDC will only validate tickets after
their starttime has passed. The validation is required so that postdated
tickets which have been stolen before their starttime can be rendered
permanently invalid (through a hot-list mechanism) (see section 3.3.3.1).
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
2.3. Renewable tickets
Applications may desire to hold tickets which can be valid for long
periods of time. However, this can expose their credentials to potential
theft for equally long periods, and those stolen credentials would be
valid until the expiration time of the ticket(s). Simply using
short-lived tickets and obtaining new ones periodically would require
the client to have long-term access to its secret key, an even greater
risk. Renewable tickets can be used to mitigate the consequences of
theft. Renewable tickets have two "expiration times": the first is when
the current instance of the ticket expires, and the second is the latest
permissible value for an individual expiration time. An application
client must periodically (i.e. before it expires) present a renewable
ticket to the KDC, with the RENEW option set in the KDC request. The KDC
will issue a new ticket with a new session key and a later expiration
time. All other fields of the ticket are left unmodified by the renewal
process. When the latest permissible expiration time arrives, the ticket
expires permanently. At each renewal, the KDC may consult a hot-list to
determine if the ticket had been reported stolen since its last renewal;
it will refuse to renew such stolen tickets, and thus the usable
lifetime of stolen tickets is reduced.
The RENEWABLE flag in a ticket is normally only interpreted by the
ticket-granting service (discussed below in section 3.3). It can usually
be ignored by application servers. However, some particularly careful
application servers may wish to disallow renewable tickets.
If a renewable ticket is not renewed by its expiration time, the KDC
will not renew the ticket. The RENEWABLE flag is reset by default, but a
client may request it be set by setting the RENEWABLE option in the
KRB_AS_REQ message. If it is set, then the renew-till field in the
ticket contains the time after which the ticket may not be renewed.
2.4. Postdated tickets
Applications may occasionally need to obtain tickets for use much later,
e.g. a batch submission system would need tickets to be valid at the
time the batch job is serviced. However, it is dangerous to hold valid
tickets in a batch queue, since they will be on-line longer and more
prone to theft. Postdated tickets provide a way to obtain these tickets
from the KDC at job submission time, but to leave them "dormant" until
they are activated and validated by a further request of the KDC. If a
ticket theft were reported in the interim, the KDC would refuse to
validate the ticket, and the thief would be foiled.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
The MAY-POSTDATE flag in a ticket is normally only interpreted by the
ticket-granting service. It can be ignored by application servers. This
flag must be set in a ticket-granting ticket in order to issue a
postdated ticket based on the presented ticket. It is reset by default;
it may be requested by a client by setting the ALLOW-POSTDATE option in
the KRB_AS_REQ message. This flag does not allow a client to obtain a
postdated ticket-granting ticket; postdated ticket-granting tickets can
only by obtained by requesting the postdating in the KRB_AS_REQ message.
The life (endtime-starttime) of a postdated ticket will be the remaining
life of the ticket-granting ticket at the time of the request, unless
the RENEWABLE option is also set, in which case it can be the full life
(endtime-starttime) of the ticket-granting ticket. The KDC may limit how
far in the future a ticket may be postdated.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
The POSTDATED flag indicates that a ticket has been postdated. The
application server can check the authtime field in the ticket to see
when the original authentication occurred. Some services may choose to
reject postdated tickets, or they may only accept them within a certain
period after the original authentication. When the KDC issues a
POSTDATED ticket, it will also be marked as INVALID, so that the
application client must present the ticket to the KDC to be validated
before use.
2.5. Proxiable and proxy tickets
At times it may be necessary for a principal to allow a service to
perform an operation on its behalf. The service must be able to take on
the identity of the client, but only for a particular purpose. A
principal can allow a service to take on the principal's identity for a
particular purpose by granting it a proxy.
The process of granting a proxy using the proxy and proxiable flags is
used to provide credentials for use with specific services. Though
conceptually also a proxy, user's wishing to delegate their identity for
ANY purpose must use the ticket forwarding mechanism described in the
next section to forward a ticket granting ticket.
The PROXIABLE flag in a ticket is normally only interpreted by the
ticket-granting service. It can be ignored by application servers. When
set, this flag tells the ticket-granting server that it is OK to issue a
new ticket (but not a ticket-granting ticket) with a different network
address based on this ticket. This flag is set if requested by the
client on initial authentication. By default, the client will request
that it be set when requesting a ticket granting ticket, and reset when
requesting any other ticket.
This flag allows a client to pass a proxy to a server to perform a
remote request on its behalf, e.g. a print service client can give the
print server a proxy to access the client's files on a particular file
server in order to satisfy a print request.
In order to complicate the use of stolen credentials, Kerberos tickets
are usually valid from only those network addresses specifically
included in the
ticket[2.1]. ticket[2.1] <#fn2.1>. When granting a proxy, the client
must specify the new network address from which the proxy is to be used,
or indicate that the proxy is to be issued for use from any address.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
The PROXY flag is set in a ticket by the TGS when it issues a proxy
ticket. Application servers may check this flag and at their option they
may require additional authentication from the agent presenting the
proxy in order to provide an audit trail.
2.6. Forwardable tickets
Authentication forwarding is an instance of a proxy where the service
granted is complete use of the client's identity. An example where it
might be used is when a user logs in to a remote system and wants
authentication to work from that system as if the login were local.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
The FORWARDABLE flag in a ticket is normally only interpreted by the
ticket-granting service. It can be ignored by application servers. The
FORWARDABLE flag has an interpretation similar to that of the PROXIABLE
flag, except ticket-granting tickets may also be issued with different
network addresses. This flag is reset by default, but users may request
that it be set by setting the FORWARDABLE option in the AS request when
they request their initial ticket-granting ticket.
This flag allows for authentication forwarding without requiring the
user to enter a password again. If the flag is not set, then
authentication forwarding is not permitted, but the same result can
still be achieved if the user engages in the AS exchange specifying the
requested network addresses and supplies a password.
The FORWARDED flag is set by the TGS when a client presents a ticket
with the FORWARDABLE flag set and requests a forwarded ticket by
specifying the FORWARDED KDC option and supplying a set of addresses for
the new ticket. It is also set in all tickets issued based on tickets
with the FORWARDED flag set. Application servers may choose to process
FORWARDED tickets differently than non-FORWARDED tickets.
2.7 Transited Policy Checking
In Kerberos, the application server is ultimately responsible for
accepting or rejecting authentication and should check that only
suitably trusted
KDC's KDCs are relied upon to authenticate a principal. The
transited field in the ticket identifies which KDC's KDCs were involved in the
authentication process and an application server would normally check
this field. If any of these are untrusted to authenticate the indicated
client principal (probably determined by a realm-based policy), the
authentication attempt must be rejected. The presence of trusted KDCs in
this list does not provide any guarantee; an untrusted KDC may have
fabricated the list.
While the end server ultimately decides whether authentication is valid,
the KDC for the end server's realm may apply a realm specific policy for
validating the transited field and accepting credentials for cross-realm
authentication. When the KDC applies such checks and accepts such
cross-realm authentication it will set the TRANSITED-POLICY-CHECKED flag
in the service tickets it issues based on the cross-realm TGT. A client
may request that the KDC's KDCs not check the transited field by setting the
DISABLE-TRANSITED-CHECK flag. KDC's KDCs are encouraged but not required to
honor this flag.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
2.8 Anonymous Tickets
When policy allows, a KDC may issue anonymous tickets for the purpose of
enabling encrypted communication between a client and server without
identifying the client to the server. Such anonymous tickets are issued
with a generic principal name configured on the KDC (e.g. "anonymous@")
and will have the ANONYMOUS flag set. A server accepting such a ticket
may assume that subsequent requests using the same ticket and session
key originate from the same user. Requests with the same username but
different tickets are likely to originate from different users. Users
request anonymous ticket by setting the REQUEST-ANONYMOUS option in an
AS or TGS request.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
If a client requires anonymous communication then the client should
check to make sure that the resulting ticket is actually anonymous. A
KDC that does not understand the anonymous-requested flag will not
return an error, but will instead return a normal ticket.
2.9. Other KDC options
There are three additional options which may be set in a client's
request of the KDC.
2.9.1 Renewable-OK
The RENEWABLE-OK option indicates that the client will accept a
renewable ticket if a ticket with the requested life cannot otherwise be
provided. If a ticket with the requested life cannot be provided, then
the KDC may issue a renewable ticket with a renew-till equal to the the
requested endtime. The value of the renew-till field may still be
adjusted by site-determined limits or limits imposed by the individual
principal or server.
2.9.2 ENC-TKT-IN-SKEY
In its basic form the Kerberos protocol supports authentication in a
client server setting and is not well suited to authentication in a
peer-to-peer environment because the long term key of the user does not
remain on the workstation after initial login. Authentication of such
peers may be supported by Kerberos in its user-to-user variant. The
ENC-TKT-IN-SKEY option supports user-to-user authentication by allowing
the KDC to issue a service ticket encrypted using the session key from
another ticket granting ticket issued to another user. The
ENC-TKT-IN-SKEY option is honored only by the ticket-granting service.
It indicates that the ticket to be issued for the end server is to be
encrypted in the session key from the additional second ticket-granting
ticket provided with the request. See section 3.3.3 for specific details.
draft-ietf-krb-wg-kerberos-clarifications-00
2.9.4 Passwordless Hardware Authentication
The OPT-HARDWARE-AUTH option indicates that the client wishes to use
some form of hardware authentication instead of or in addition to the
client's password or other long-lived encryption key. OPT-HARDWARE-AUTH
is honored only by the authentication service. If supported and allowed
by policy, the KDC will return an errorcode KDC_ERR_PREAUTH_REQUIRED and
include the required METHOD-DATA to perform such authentication.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 22 August 2002 9 March 2003
3. Message Exchanges
The following sections describe the interactions between network clients
and servers and the messages involved in those exchanges.
[Insert paragraph for extensions <krbext3-1.html>]
3.1. The Authentication Service Exchange
Summary
Message direction Message type Section
1. Client to Kerberos KRB_AS_REQ 5.4.1
2. Kerberos to client KRB_AS_REP or 5.4.2
KRB_ERROR 5.9.1
The Authentication Service (AS) Exchange between the client and the
Kerberos Authentication Server is initiated by a client when it wishes
to obtain authentication credentials for a given server but currently
holds no credentials. In its basic form, the client's secret key is used
for encryption and decryption. This exchange is typically used at the
initiation of a login session to obtain credentials for a
Ticket-Granting Server which will subsequently be used to obtain
credentials for other servers (see section 3.3) without requiring
further use of the client's secret key. This exchange is also used to
request credentials for services which must not be mediated through the
Ticket-Granting Service, but rather require a principal's secret key,
such as the password-changing service[3.1]. service[3.1] <#fn3.1>. This exchange does
not by itself provide any assurance of the the identity of the
user[3.2]. user[3.2]
<#fn3.2>.
The exchange consists of two messages: KRB_AS_REQ from the client to
Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these
messages are described in sections 5.4.1, 5.4.2, and 5.9.1.
In the request, the client sends (in cleartext) its own identity and the
identity of the server for which it is requesting credentials. The
response, KRB_AS_REP, contains a ticket for the client to present to the
server, and a session key that will be shared by the client and the
server. The session key and additional information are encrypted in the
client's secret key. The KRB_AS_REP message contains information which
can be used to detect replays, and to associate it with the message to
which it replies. [Insert sentence for extensions <krbext3.1-1.html>]
Without pre-authentication, the authentication server does not know
whether the client is actually the principal named in the request. It
simply sends a reply without knowing or caring whether they are the
same. This is acceptable because nobody but the principal whose identity
was given in the request will be able to use the reply. Its critical
information is encrypted in that principal's key. However, an attacker
can send a KRB_AS_REQ message to get known plaintext in order to attack
the principal's key. Especially if the key is based on a password, this
may create a security exposure. So, the initial request supports an
optional field that can be used to pass additional information that
might be needed for the initial exchange. This field should be used for
pre-authentication as described in section 3.1.1.
draft-ietf-krb-wg-kerberos-clarifications-00
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 22 August 2002 9 March 2003
Various errors can occur; these are indicated by an error response
(KRB_ERROR) instead of the KRB_AS_REP response. The error message is not
encrypted. The KRB_ERROR message contains information which can be used
to associate it with the message to which it replies. [This rest of this
paragraph is replaced in revisions <krbext3.1b-1.html>] The contents of
the KRB_ERROR message are not integrity-protected. As such, the client
cannot detect replays, fabrications or modifications. A solution to this
problem will be included in a future version of the protocol.
3.1.1. Generation of KRB_AS_REQ message
The client may specify a number of options in the initial request. Among
these options are whether pre-authentication is to be performed; whether
the requested ticket is to be renewable, proxiable, or forwardable;
whether it should be postdated or allow postdating of derivative
tickets; whether the client requests an anonymous ticket; and whether a
renewable ticket will be accepted in lieu of a non-renewable ticket if
the requested ticket expiration date cannot be satisfied by a
non-renewable ticket (due to configuration constraints; see section 4). constraints).
The client prepares the KRB_AS_REQ message and sends it to the KDC.
[Insert the linked text in extensions <krbext3.1.1-1.html>]
3.1.2. Receipt of KRB_AS_REQ message
If all goes well, processing the KRB_AS_REQ message will result in the
creation of a ticket for the client to present to the server. The format
for the ticket is described in section 5.3.1. The contents of the ticket
are determined as follows.
Because Kerberos can run over unreliable transports such as UDP, the KDC
MUST be prepared to retransmit responses in case they are lost. If a KDC
receives a request identical to one it has recently successfully
processed, the KDC MUST respond with an KRB_AS_REP message rather than a
replay error. In order to reduce ciphertext given to a potential
attacker, KDCs MAY wish to send an the same response generated when the
request was first handled. KDCs MUST obey this replay behavior even if
the actual transport in use is reliable.
3.1.3. Generation of KRB_AS_REP message
The authentication server looks up the client and server principals
named in the KRB_AS_REQ in its database, extracting their respective
keys. If the requested client principal named in the request is not
known because it doesn't exist in the KDC's principal database, then an
error message with a KDC_ERR_C_PRINCIPAL_UNKNOWN is returned.
If required, the server pre-authenticates the request, and if the
pre-authentication check fails, an error message with the code
KDC_ERR_PREAUTH_FAILED is returned. If pre-authentication is required,
but was not present in the request, an error message with the code
KDC_ERR_PREAUTH_REQUIRED is returned and the PA-ETYPE-INFO
pre-authentication field will be included in the KRB-ERROR message. If
the server cannot accommodate an encryption type requested by the
client, an error message with code KDC_ERR_ETYPE_NOSUPP is returned.
Otherwise the KDC generates a 'random' session key[3.3]. key[3.3] <#fn3.3>.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
When responding to an AS request, if there are multiple encryption keys
registered for a client in the Kerberos database , then the etype field
from the AS request is used by the KDC to select the encryption method
to be used to protect the encrypted part of the KRB_AS_REP message which
is sent to the client. If there is more than one supported strong
encryption type in the etype list, the first valid etype for which an
encryption key is available is used. The encryption method used to
protect the encrypted part of the KRB_TGS_REP message is the keytype of
the session key found in the ticket granting ticket presented in the
KRB_TGS_REQ.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
When the user's key is generated from a password or pass phrase, the
string-to-key function for the particular encryption key type is used,
as specified in [KCRYPTO]. The salt value and additional parameters for
the string-to-key function have default values (specified by section 6
and by the encryption mechanism specification, respectively) that may be
overridden by preauthentication data (PA-PW-SALT, PA-AFS3-SALT,
PA-ETYPE-INFO, PA-S2K-PARAMS, etc). Since the KDC is presumed to store a
copy of the resulting key only, these values should not be changed for
password-based keys except when changing the principal's key.
It is not possible to reliably generate a user's key given a pass phrase
without contacting the KDC, since it will not be known whether alternate
salt or parameter values are required.
When the etype field is present in a KDC request, whether an AS or TGS
request, the KDC will attempt to assign the type of the random session
key from the list of methods in the etype field. The KDC will select the
appropriate type using the list of methods provided together with
information from the Kerberos database indicating acceptable encryption
methods for the application server. The KDC will not issue tickets with
a weak session key encryption type.
If the requested start time is absent, indicates a time in the past, or
is within the window of acceptable clock skew for the KDC and the
POSTDATE option has not been specified, then the start time of the
ticket is set to the authentication server's current time. If it
indicates a time in the future beyond the acceptable clock skew, but the
POSTDATED option has not been specified then the error
KDC_ERR_CANNOT_POSTDATE is returned. Otherwise the requested 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 ticket's start time is set as requested and the
INVALID flag is set in the new ticket. The postdated ticket must be
validated before use by presenting it to the KDC after the start time
has been reached.
The expiration time of the ticket will be set to the earlier of the
requested endtime and a time determined by local policy, possibly
determined using realm or principal specific factors. For example, the
expiration time may be set to the minimum of the following:
* The expiration time (endtime) requested in the KRB_AS_REQ message.
* The ticket's start time plus the maximum allowable lifetime
associated with the client principal from the authentication
server's database
(see section 4). database.
* 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.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
If the requested expiration time minus the start time (as determined
above) is less than a site-determined minimum lifetime, an error message
with code KDC_ERR_NEVER_VALID is returned. If the requested expiration
time for the ticket exceeds what was determined as above, and if the
'RENEWABLE-OK' option was requested, then the 'RENEWABLE' flag is set in
the new ticket, and the renew-till value is set as if the 'RENEWABLE'
option were requested (the field and option names are described fully in
section 5.4.1).
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
If the RENEWABLE option has been requested or if the RENEWABLE-OK option
has been set and a renewable ticket is to be issued, then the renew-till
field is set to the minimum of:
* Its requested value.
* The start time of the ticket plus the minimum of the two maximum
renewable lifetimes associated with the principals' database entries.
* The start time of the ticket plus the maximum renewable lifetime
set by the policy of the local realm.
The flags field of the new ticket will have the following options set if
they have been requested and if the policy of the local realm allows:
FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE, ANONYMOUS.
If the new ticket is post-dated (the start time is in the future), its
INVALID flag will also be set.
If all of the above succeed, the server will encrypt ciphertext part of
the ticket using the encryption key extracted from the server
principal's record in the Kerberos database using the encryption type
associated with the server principal's key (this choice is NOT affected
by the etype field in the request). It then formats a KRB_AS_REP message
(see section 5.4.2), copying the addresses in the request into the caddr
of the response, placing any required pre-authentication data into the
padata of the response, and encrypts the ciphertext part in the client's
key using an acceptable encryption method requested in the etype field
of the request, or in some key specified by pre-authentication
mechanisms being used.
3.1.4. Generation of KRB_ERROR message
Several errors can occur, and the Authentication Server responds by
returning an error message, KRB_ERROR, to the client, with the
error-code, e-text, and optional e-cksum fields set to appropriate
values. The error message contents and details are described in Section
5.9.1.
3.1.5. Receipt of KRB_AS_REP message
If the reply message type is KRB_AS_REP, then the client verifies that
the cname and crealm fields in the cleartext portion of the reply match
what it requested. If any padata fields are present, they may be used to
derive the proper secret key to decrypt the message. The client decrypts
the encrypted part of the response using its secret key, verifies that
the nonce in the encrypted part matches the nonce it supplied in its
request (to detect replays). It also verifies that the sname and srealm
in the response match those in the request (or are otherwise expected
values), and that the host address field is also correct. It then stores
the ticket, session key, start and expiration times, and other
information for later use. The key-expiration field from the encrypted
part of the response may be checked to notify the user of impending key
expiration (the client program could then suggest remedial action, such
as a password change).
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
Proper decryption of the KRB_AS_REP message is not sufficient for the
host to verify the identity of the user; the user and an attacker could
cooperate to generate a KRB_AS_REP format message which decrypts
properly but is not from the proper KDC. If the host wishes to verify
the identity of the user, it must require the user to present
application credentials which can be verified using a securely-stored
secret key for the host. If those credentials can be verified, then the
identity of the user can be assured.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
3.1.6. Receipt of KRB_ERROR message
If the reply message type is KRB_ERROR, then the client interprets it as
an error and performs whatever application-specific tasks are necessary
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 network
applications to authenticate the client to the server and vice versa.
The client must have already acquired credentials for the server using
the AS or TGS exchange.
3.2.1. The KRB_AP_REQ message
The KRB_AP_REQ contains authentication information which should be part
of the first message in an authenticated transaction. It contains a
ticket, an authenticator, and some additional bookkeeping information
(see section 5.5.1 for the exact format). The ticket by itself is
insufficient to authenticate a client, since tickets are passed across
the network in
cleartext[3.4], cleartext[3.4] <#fn3.4>, so the authenticator is used to
prevent invalid replay of tickets by proving to the server that the
client knows the session key of the ticket and thus is entitled to use
the ticket. The KRB_AP_REQ message is referred to elsewhere as the
'authentication header.'
3.2.2. Generation of a KRB_AP_REQ message
When a client wishes to initiate authentication to a server, it obtains
(either through a credentials cache, the AS exchange, or the TGS
exchange) a ticket and session key for the desired service. The client
may re-use any tickets it holds until they expire. To use a ticket the
client constructs a new Authenticator from the 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 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[3.5]. server[3.5] <#fn3.5>. If a sequence number is
to be included, it should be randomly chosen so that even after many
messages have been exchanged it is not likely to collide with other
sequence numbers in use.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
The client may indicate a requirement of mutual authentication or the
use of a session-key based ticket by setting the appropriate flag(s) in
the ap-options field of the message.
The Authenticator is encrypted in the session key and combined with the
ticket to form the KRB_AP_REQ message which is then sent to the end
server along with any additional application-specific information.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
[Insert paragraph for extensions <krbext3.2.2-1.html>]
3.2.3. Receipt of KRB_AP_REQ message
Authentication is based on the server's current time of day (clocks must
be loosely synchronized), the authenticator, and the ticket. Several
errors are possible. If an error occurs, the server is expected to reply
to the client with a KRB_ERROR message. This message may be encapsulated
in the application protocol if its 'raw' form is not acceptable to the
protocol. The format of error messages is described in section 5.9.1.
The algorithm for verifying authentication information is as follows. If
the message type is not KRB_AP_REQ, the server returns the
KRB_AP_ERR_MSG_TYPE error. If the key version indicated by the Ticket in
the KRB_AP_REQ is not one the server can use (e.g., it indicates an old
key, and the server no longer possesses a copy of the old key), the
KRB_AP_ERR_BADKEYVER error is returned. If the USE-SESSION-KEY flag is
set in the ap-options field, it indicates to the server that the ticket
is encrypted in the session key from the server's ticket-granting ticket
rather than its secret key [3.6]. [3.6] <#fn3.6>.
Since it is possible for the server to be registered in multiple realms,
with different keys in each, the srealm field in the unencrypted portion
of the ticket in the KRB_AP_REQ is used to specify which secret key the
server should use to decrypt that ticket. The KRB_AP_ERR_NOKEY error
code is returned if the server doesn't have the proper key to decipher
the ticket.
The ticket is decrypted using the version of the server's key specified
by the ticket. If the decryption routines detect a modification of the
ticket (each encryption system must provide safeguards to detect
modified ciphertext; see section 6), the KRB_AP_ERR_BAD_INTEGRITY error
is returned (chances are good that different keys were used to encrypt
and decrypt).
The authenticator is decrypted using the session key extracted from the
decrypted ticket. If decryption shows it to have been modified, the
KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of the
client from the ticket are compared against the same fields in the
authenticator. If they don't match, the KRB_AP_ERR_BADMATCH error is
returned; this normally is caused by a client error or attempted attack.
The addresses in the ticket (if any) are then searched for an address
matching the operating-system reported address of the client. If no
match is found or the server insists on ticket addresses but none are
present in the ticket, the KRB_AP_ERR_BADADDR error is returned. If the
local (server) time and the client time in the authenticator differ by
more than the allowable clock skew (e.g., 5 minutes), the
KRB_AP_ERR_SKEW error is returned.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
Unless the application server provides its own suitable means to protect
against replay (for example, a challenge-response sequence initiated by
the server after authentication, or use of a server-generated encryption
subkey), the server must utilize a replay cache to remember any
authenticator presented within the allowable clock skew. Careful
analysis of the application protocol and implementation is recommended
before eliminating this cache. The replay cache will store the server
name, along with the client name, time and microsecond fields from the
recently-seen authenticators and if a matching tuple is found, the
KRB_AP_ERR_REPEAT error is returned [3.7]. [3.7] <#fn3.7>. If a server loses
track of authenticators presented within the allowable clock skew, it
must reject all requests until the clock skew interval has passed,
providing assurance that any lost or re-played authenticators will fall
outside the allowable clock skew and can no longer be successfully replayed[3.8].
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
replayed[3.8] <#fn3.8>.
If a sequence number is provided in the authenticator, the server saves
it for later use in processing KRB_SAFE and/or KRB_PRIV messages. If a
subkey is present, the server either saves it for later use or uses it
to help generate its own choice for a subkey to be returned in a
KRB_AP_REP message.
If multiple servers (for example, different services on one machine, or
a single service implemented on multiple machines) share a service
principal (a practice we do not recommend in general, but acknowledge
will be used in some cases), they should also share this replay cache,
or the application protocol should be designed so as to eliminate the
need for it. Note that this applies to all of the services, if any of
the application protocols does not have replay protection built in; an
authenticator used with such a service could later be replayed to a
different service with the same service principal but no replay
protection, if the former doesn't record the authenticator information
in the common replay cache.
The server computes the age of the ticket: local (server) time minus the
start time inside the Ticket. If the 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 is returned.
Otherwise, if the current time is later than end time by more than the
allowable clock skew, the KRB_AP_ERR_TKT_EXPIRED error is returned.
If all these checks succeed without an error, the server is assured that
the client possesses the credentials of the principal named in the
ticket and thus, the client has been authenticated to the server.
Passing these checks provides only authentication of the named
principal; it does not imply authorization to use the named service.
Applications must make a separate authorization decisions based upon the
authenticated name of the user, the requested operation, local access
control information such as that contained in a .k5login or .k5users
file, and possibly a separate distributed authorization service.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
3.2.4. Generation of a KRB_AP_REP message
Typically, a client's request will include both the authentication
information and its initial request in the same message, and the server
need not explicitly reply to the KRB_AP_REQ. However, if mutual
authentication (not only authenticating the client to the server, but
also the server to the client) is being performed, the KRB_AP_REQ
message will have MUTUAL-REQUIRED set in its ap-options field, and a
KRB_AP_REP message is required in response. As with the error message,
this message may be encapsulated in the application protocol if its
"raw" form is not acceptable to the application's protocol. The
timestamp and microsecond field used in the reply must be the client's
timestamp and microsecond field (as provided in the authenticator)[3.9]. authenticator)[3.9]
<#fn3.9>. If a sequence number is to be included, it should be randomly
chosen as described above for the authenticator. A subkey may be
included if the server desires to negotiate a different subkey. The
KRB_AP_REP message is encrypted in the session key extracted from the
ticket.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
[Insert paragraph for extensions <krbext3.2.4-1.html>]
3.2.5. Receipt of KRB_AP_REP message
If a KRB_AP_REP message is returned, the client uses the session key
from the credentials obtained for the server[3.10] <#fn3.10> to decrypt
the message, and verifies that the timestamp and microsecond fields
match those in the Authenticator it sent to the server. If they match,
then the client is assured that the server is genuine. The sequence
number and subkey (if present) are retained for later use.
3.2.6. Using the encryption key
[This seems inconsistent with crypto-architecture; we should look at
before publication.]
After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and
server share an encryption key which can be used by the application. In
some cases, the use of this session key will be implicit in the
protocol; in others the method of use must be chosen from several
alternatives. The '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 session key from the ticket and subkeys in the KRB_AP_REP
message and the authenticator[3.11]. authenticator[3.11] <#fn3.11>. To mitigate the effect of
failures in random number generation on the client it is strongly
encouraged that any key derived by an application for subsequent use
include the full key entropy derived from the KDC generated session key
carried in the ticket. We leave the protocol negotiations of how to use
the key (e.g. selecting an encryption or checksum type) to the
application programmer; the Kerberos protocol does not constrain the
implementation options, but an example of how this might be done follows.
One way that an application may choose to negotiate a key to be used for
subsequent integrity and privacy protection is for the client to propose
a key in the subkey field of the authenticator. The server can then
choose a key using the proposed key from the client as input, returning
the new subkey in the subkey field of the application reply. This key
could then be used for subsequent communication.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
To make this example more concrete, if the communication patterns of an
application dictates the use of encryption modes of operation
incompatible with the encryption system used for the authenticator, then
a key compatible with the required encryption system may be generated by
either the client, the server, or collaboratively by both and exchanged
using the subkey field. This generation might involve the use of a
random number as a pre-key, initially generated by either party, which
could then be encrypted using the session key from the ticket, and the
result exchanged and used for subsequent encryption. By encrypting the
pre-key with the session key from the ticket, randomness from the KDC
generated key is assured of being present in the negotiated key.
Application developers must be careful however, to use a means of
introducing this entropy that does not allow an attacker to learn the
session key from the ticket if it learns the key generated and used for
subsequent communication. The reader should note that this is only an
example, and that an analysis of the particular cryptosystem to be used,
must be made before deciding how to generate values for the subkey
fields, and the key to be used for subsequent communication.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
With both the one-way and mutual authentication exchanges, the peers
should take care not to send sensitive information to each other without
proper assurances. In particular, applications that require privacy or
integrity should use the KRB_AP_REP response from the server to 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 client and the Kerberos Ticket-Granting
Server 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 the Ticket-Granting Service using the
AS exchange (the ticket-granting ticket is usually obtained when a
client initially authenticates to the system, such as when a user logs
in). The message format for the TGS exchange is almost identical to that
for the AS exchange. The primary difference is that encryption and
decryption in the TGS exchange does not take place under the client's
key. Instead, the session key from the ticket-granting ticket or
renewable ticket, or sub-session key from an Authenticator is used. As
is the case for all application servers, expired tickets are not
accepted by the TGS, so once a renewable or ticket-granting ticket
expires, the client must use a separate exchange to obtain valid tickets.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
The TGS exchange consists of two messages: A request (KRB_TGS_REQ) from
the client to the Kerberos Ticket-Granting Server, and a reply
(KRB_TGS_REP or KRB_ERROR). The KRB_TGS_REQ message includes information
authenticating the client plus a request for credentials. The
authentication information consists of the authentication header
(KRB_AP_REQ) which includes the client's previously obtained
ticket-granting, renewable, or invalid ticket. In the ticket-granting
ticket and proxy cases, the request may include one or more of: a list
of network addresses, a collection of typed authorization data to be
sealed in the ticket for authorization use by the application server, or
additional tickets (the use of which are described later). The TGS reply
(KRB_TGS_REP) contains the requested credentials, encrypted in the
session key from the ticket-granting ticket or renewable ticket, or if
present, in the sub-session key from the Authenticator (part of the
authentication header). The KRB_ERROR message contains an error code and
text explaining what went wrong. The KRB_ERROR message is not encrypted.
The KRB_TGS_REP message contains information which can be used to detect
replays, and to associate it with the message to which it replies. The
KRB_ERROR message also contains information which can be used to
associate it with the message to which it replies. The same comments
about integrity protection of KRB_ERROR messages mentioned in section
3.1 apply to the TGS exchange.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
3.3.1. Generation of KRB_TGS_REQ message
Before sending a request to the ticket-granting service, the client must
determine in which realm the application server is believed to be
registered[3.12].
registered[3.12] <#fn3.12>. If the client knows the service principal
name and realm and it does not already possess a ticket-granting ticket
for the appropriate realm, then one must be obtained. This is first
attempted by requesting a ticket-granting ticket for the destination
realm from a Kerberos server for which the client possesses a
ticket-granting ticket (using the KRB_TGS_REQ message recursively). The
Kerberos server may return a TGT for the desired realm in which case one
can proceed. Alternatively, the Kerberos server may return a TGT for a
realm which is 'closer' to the desired realm (further along the standard
hierarchical path between the client's realm and the requested realm
server's realm).
Once the client obtains a ticket-granting ticket for the appropriate
realm, it determines which Kerberos servers serve that realm, and
contacts one. The list might be obtained through a configuration file or
network service or it may be generated from the name of the realm; as
long as the secret keys exchanged by realms are kept secret, only denial
of service results from using a false Kerberos server.
As in the AS exchange, the client may specify a number of options in the
KRB_TGS_REQ message. The client prepares the KRB_TGS_REQ message,
providing an authentication header as an element of the padata field,
and including the same fields as used in the KRB_AS_REQ message along
with several optional fields: the enc-authorization-data field for
application server use and additional tickets required by some options.
In preparing the authentication header, the client can select a
sub-session key under which the response from the Kerberos server will
be
encrypted[3.13]. encrypted[3.13] <#fn3.13>. If the sub-session key is not specified,
the session key from the ticket-granting ticket will be used. If the
enc-authorization-data is present, it must be encrypted in the
sub-session key, if present, from the authenticator portion of the
authentication header, or if not present, using the session key from the
ticket-granting ticket.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
Once prepared, the message is sent to a Kerberos server for the
destination realm.
3.3.2. Receipt of KRB_TGS_REQ message
The KRB_TGS_REQ message is processed in a manner similar to the
KRB_AS_REQ message, but there are many additional checks to be
performed. First, the Kerberos server must determine which server the
accompanying ticket is for and it must select the appropriate key to
decrypt it. For a normal KRB_TGS_REQ message, it will be for the ticket
granting service, and the TGS's key will be used. If the TGT was issued
by another realm, then the appropriate inter-realm key must be used. If
the accompanying ticket is not a ticket granting ticket for the current
realm, but is for an application server in the current realm, the RENEW,
VALIDATE, or PROXY options are specified in the request, and the server
for which a ticket is requested is the server named in the accompanying
ticket, then the KDC will decrypt the ticket in the authentication
header using the key of the server for which it was issued. If no ticket
can be found in the padata field, the KDC_ERR_PADATA_TYPE_NOSUPP error
is returned.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
Once the accompanying ticket has been decrypted, the user-supplied
checksum in the Authenticator must be verified against the contents of
the request, and the message rejected if the checksums do not match
(with an error code of KRB_AP_ERR_MODIFIED) or if the checksum is not
keyed or not collision-proof (with an error code of
KRB_AP_ERR_INAPP_CKSUM). If the checksum type is not supported, the
KDC_ERR_SUMTYPE_NOSUPP error is returned. If the authorization-data are
present, they are decrypted using the sub-session key from the
Authenticator.
If any of the decryptions indicate failed integrity checks, the
KRB_AP_ERR_BAD_INTEGRITY error is returned.
3.3.3. Generation of
As discussed in section 3.1.2, the KDC MUST send a valid KRB_TGS_REP
message
The KRB_TGS_REP if it receives a KRB_TGS_REQ message shares its format with identical to one it has
recently processed. However, if the KRB_AS_REP (KRB_KDC_REP), authenticator is a replay, but with its the
rest of the request is not identical, then the KDC SHOULD return
KRB_AP_ERR_REPEAT.
3.3.3. Generation of KRB_TGS_REP message
The KRB_TGS_REP message shares its format with the KRB_AS_REP
(KRB_KDC_REP), but with its type field set to KRB_TGS_REP. The detailed
specification is in section 5.4.2.
The response will include a ticket for the requested server or for a
ticket granting server of an intermediate KDC to be contacted to obtain
the requested ticket. The Kerberos database is queried to retrieve the
record for the appropriate server (including the key with which the
ticket will be encrypted). If the request is for a ticket granting
ticket for a remote realm, and if no key is shared with the requested
realm, then the Kerberos server will select the realm 'closest' to the
requested realm with which it does share a key, and use that realm
instead. If the requested server cannot be found in the TGS database,
then a TGT for another trusted realm may be returned instead of a ticket
for the service. This TGT is a referral mechanism to cause the client to
retry the request to the realm of the TGT. These are the only cases
where the response for the KDC will be for a different server than that
requested by the client.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
By default, the address field, the client's name and realm, the list of
transited realms, the time of initial authentication, the expiration
time, and the authorization data of the newly-issued ticket will be
copied from the 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 the request specifies an endtime, then the endtime of the new ticket
is set to the minimum of (a) that request, (b) the endtime from the TGT,
and (c) the starttime of the TGT plus the minimum of the maximum life
for the application server and the maximum life for the local realm (the
maximum life for the requesting principal was already applied when the
TGT was issued). If the new ticket is to be a renewal, then the endtime
above is replaced by the minimum of (a) the value of the renew_till
field of the ticket and (b) the starttime for the new ticket plus the
life (endtime-starttime) of the old ticket.
If the FORWARDED option has been requested, then the resulting ticket
will contain the addresses specified by the client. This option will
only be honored if the FORWARDABLE flag is set in the TGT. The PROXY
option is similar; the resulting ticket will contain the addresses
specified by the client. It will be honored only if the PROXIABLE flag
in the TGT is set. The PROXY option will not be honored on requests for
additional ticket-granting tickets.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
If the requested start time is absent, indicates a time in the past, or
is within the window of acceptable clock skew for the KDC and the
POSTDATE option has not been specified, then the start time of the
ticket is set to the authentication server's current time. If it
indicates a time in the future beyond the acceptable clock skew, but the
POSTDATED option has not been specified or the MAY-POSTDATE flag is not
set in the TGT, then the error KDC_ERR_CANNOT_POSTDATE is returned.
Otherwise, if the ticket-granting ticket has the MAY-POSTDATE flag set,
then the resulting ticket will be postdated and the requested starttime
is checked against the policy of the local realm. If acceptable, the
ticket's start time is set as requested, and the INVALID flag is set.
The postdated ticket must be validated before use by presenting it to
the KDC after the starttime has been reached. However, in no case may
the starttime, endtime, or renew-till time of a newly-issued postdated
ticket extend beyond the renew-till time of the ticket-granting ticket.
If the ENC-TKT-IN-SKEY option has been specified and an additional
ticket has been included in the request, the KDC will decrypt the
additional ticket using the key for the server to which the additional
ticket was issued and verify that it is a ticket-granting ticket. If the
name of the requested server is missing from the request, the name of
the client in the additional ticket will be used. Otherwise the name of
the requested server will be compared to the name of the client in the
additional ticket and if different, the request will be rejected. If the
request succeeds, the session key from the additional ticket will be
used to encrypt the new ticket that is issued instead of using the key
of the server for which the new ticket will be used.
If the name of the server in the ticket that is presented to the KDC as
part of the authentication header is not that of the ticket-granting
server itself, the server is registered in the realm of the KDC, and the
RENEW option is requested, then the KDC will verify that the RENEWABLE
flag is set in the ticket, that the INVALID flag is not set in the
ticket, and that the renew_till time is still in the future. If the
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
VALIDATE option is requested, the KDC will check that the starttime has
passed and the INVALID flag is set. If the PROXY option is requested,
then the KDC will check that the PROXIABLE flag is set in the ticket. If
the tests succeed, and the ticket passes the hotlist check described in
the next section, the KDC will issue the appropriate new ticket.
The ciphertext part of the response in the KRB_TGS_REP message is
encrypted in the sub-session key from the Authenticator, if present, or
the session key key from the ticket-granting ticket. It is not encrypted
using the client's secret key. Furthermore, the client's key's
expiration date and the key version number fields are left out since
these values are stored along with the client's database record, and
that record is not needed to satisfy a request based on a
ticket-granting ticket.
3.3.3.1. Checking for revoked tickets
Whenever a request is made to the ticket-granting server, the presented
ticket(s) is(are) checked against a hot-list of tickets which have been
canceled. This hot-list might be implemented by storing a range of issue
timestamps for 'suspect tickets'; if a presented ticket had an authtime
in that range, it would be rejected. In this way, a stolen
ticket-granting
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002 ticket or renewable ticket cannot be used to gain
additional tickets (renewals or otherwise) once the theft has been
reported to the KDC for the realm in which the server resides. Any
normal ticket obtained before it was reported stolen will still be valid
(because they require no interaction with the KDC), but only until their
normal expiration time. If TGT's have been issued for cross-realm
authentication, use of the cross-realm TGT will not be affected unless
the hot-list is propagated to the KDC's for the realms for which such
cross-realm tickets were issued.
3.3.3.2. Encoding the transited field
If the identity of the server in the TGT that is presented to the KDC as
part of the authentication header is that of the ticket-granting
service, but the TGT was issued from another realm, the KDC will look up
the inter-realm key shared with that realm and use that key to decrypt
the ticket. If the ticket is valid, then the KDC will honor the request,
subject to the constraints outlined above in the section describing the
AS exchange. The realm part of the client's identity will be taken from
the ticket-granting ticket. The name of the realm that issued the
ticket-granting ticket ticket, if it is not the realm of the client principal,
will be added to the transited field of the ticket to be issued. This is
accomplished by reading the transited field from the ticket-granting
ticket (which is treated as an unordered set of realm names), adding the
new realm to the set, then constructing and writing out its encoded
(shorthand) form (this may involve a rearrangement of the existing
encoding).
Note that the ticket-granting service does not add the name of its own
realm. Instead, its responsibility is to add the name of the previous
realm. This prevents a malicious Kerberos server from intentionally
leaving out its own name (it could, however, omit other realms' names).
The names of neither the local realm nor the principal's realm are to be
included in the transited field. They appear elsewhere in the ticket and
both are known to have taken part in authenticating the principal. Since
the endpoints are not included, both local and single-hop inter-realm
authentication result in a transited field that is empty.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
Because the name of each realm transited is added to this field, it
might potentially be very long. To decrease the length of this field,
its contents are encoded. The initially supported encoding is optimized
for the normal case of inter-realm communication: a hierarchical
arrangement of realms using either domain or X.500 style realm names.
This encoding (called DOMAIN-X500-COMPRESS) is now described.
Realm names in the transited field are separated by a ",". The ",", "\",
trailing "."s, and leading spaces (" ") are special characters, and if
they are part of a realm name, they must be quoted in the transited
field by preceding them with a "\".
A realm name ending with a "." is interpreted as being prepended to the
previous realm. For example, we can encode traversal of EDU, MIT.EDU,
ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as:
"EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.".
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points, that
they would not be included in this field, and we would have:
"EDU,MIT.,WASHINGTON.EDU"
A realm name beginning with a "/" is interpreted as being appended to
the previous realm[18]. If it is to stand by itself, then it should be
preceded by a space (" "). For example, we can encode traversal of
/COM/HP/APOLLO, /COM/HP, /COM, and /COM/DEC as:
"/COM,/HP,/APOLLO, /COM/DEC".
Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints,
they they would not be included in this field, and we would have:
"/COM,/HP"
A null subfield preceding or following a "," indicates that all realms
between the previous realm and the next realm have been traversed[19].
Thus, "," means that all realms along the path between the client and
the server have been traversed. ",EDU, /COM," means that that all realms
from the client's realm up to EDU (in a domain style hierarchy) have
been traversed, and that everything from /COM down to the server's realm
in an X.500 style has also been traversed. This could occur if the EDU
realm in one hierarchy shares an inter-realm key directly with the /COM
realm in another hierarchy.
3.3.4. Receipt of KRB_TGS_REP message
When the KRB_TGS_REP is received by the client, it is processed in the
same manner as the KRB_AS_REP processing described above. The primary
difference is that the ciphertext part of the response must be decrypted
using the session key from the ticket-granting ticket rather than the
client's secret key. The server name returned in the reply is the true
principal name of the service.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
3.4. The KRB_SAFE Exchange
The KRB_SAFE message may be used by clients requiring the ability to
detect modifications of messages they exchange. It achieves this by
including a keyed collision-proof checksum of the user data and some
control information. The checksum is keyed with an encryption key
(usually the last key negotiated via subkeys, or the session key if no
negotiation has occurred).
3.4.1. Generation of a KRB_SAFE message
When an application wishes to send a KRB_SAFE message, it collects its
data and the appropriate control information and computes a checksum
over them. The checksum algorithm should be the keyed checksum mandated
to be implemented along with the crypto system used for the sub-session
or session key. The checksum is generated using the sub-session key if
present, or the session key. Some implementations use a different
checksum algorithm for KRB_SAFE messages but doing so in a interoperable
manner is impossible. Implementations should accept any checksum
algorithm they implement that both has adequate security and that has
keys compatible with the sub-session or session key. Unkeyed or
non-collision-proof checksums are not suitable for this use.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
The control information for the KRB_SAFE message includes both a
timestamp and a sequence number. The designer of an application using
the KRB_SAFE message must choose at least one of the two mechanisms.
This choice should be based on the needs of the application protocol.
Sequence numbers are useful when all messages sent will be received by
one's peer. Connection state is presently required to maintain the
session key, so maintaining the next sequence number should not present
an additional problem.
If the application protocol is expected to tolerate lost messages
without them being resent, the use of the timestamp is the appropriate
replay detection mechanism. Using timestamps is also the appropriate
mechanism for multi-cast protocols where all of one's peers share a
common sub-session key, but some messages will be sent to a subset of
one's peers.
After computing the checksum, the client then transmits the information
and checksum to the recipient in the message format specified in section
5.6.1.
3.4.2. Receipt of KRB_SAFE message
When an application receives a KRB_SAFE message, it verifies it as
follows. If any error occurs, an error code is reported for use by the
application.
The message is first checked by verifying that the protocol version and
type fields match the current version and KRB_SAFE, respectively. A
mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error.
The application verifies that the checksum used is a collision-proof
keyed checksum that uses keys compatible with the sub-session or session
key as appropriate, and if it is not, a KRB_AP_ERR_INAPP_CKSUM error is
generated.
If the The sender's address was MUST be included in the control information,
information; the recipient verifies that the operating system's report
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
of the sender's address matches the sender's address in the message, and
(if a recipient address is specified or the recipient requires an
address) that one of the recipient's addresses appears as the
recipient's address in the message. To work with network address
translation, senders MAY wish to use the directional address type
specified in section 8.1 for the sender address and not include
recipient addresses. A failed match for either case generates a
KRB_AP_ERR_BADADDR error. Then the timestamp and usec and/or the
sequence number fields are checked. If timestamp and usec are expected
and not present, or they are present but not current, the
KRB_AP_ERR_SKEW error is generated. If the server name, along with the
client name, time and microsecond fields from the Authenticator match
any recently-seen (sent or received[20] ) 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 a sequence number is present, a KRB_AP_ERR_MODIFIED error is
generated. Finally, the checksum is computed over the data and control
information, and if it doesn't match the received checksum, a
KRB_AP_ERR_MODIFIED error is generated.
If all the checks succeed, the application is assured that the message
was generated by its peer and was not modified in transit.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
3.5. The KRB_PRIV Exchange
The KRB_PRIV message may be used by clients requiring confidentiality
and the ability to detect modifications of exchanged messages. It
achieves this by encrypting the messages and adding control information.
3.5.1. Generation of a KRB_PRIV message
When an application wishes to send a KRB_PRIV message, it collects its
data and the appropriate control information (specified in section
5.7.1) and encrypts them under an encryption key (usually the last key
negotiated via subkeys, or the session key if no negotiation has
occurred). As part of the control information, the client must choose to
use either a timestamp or a sequence number (or both); see the
discussion in section 3.4.1 for guidelines on which to use. After the
user data and control information are encrypted, the client transmits
the ciphertext and some 'envelope' information to the recipient.
3.5.2. Receipt of KRB_PRIV message
When an application receives a KRB_PRIV message, it verifies it as
follows. If any error occurs, an error code is reported for use by the
application.
The message is first checked by verifying that the protocol version and
type fields match the current version and KRB_PRIV, respectively. A
mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error.
The application then decrypts the ciphertext and processes the resultant
plaintext. If decryption shows the data to have been modified, a
KRB_AP_ERR_BAD_INTEGRITY error is generated. If the The sender's address was MUST
be included in the control information, information; the recipient verifies that the
operating system's report of the sender's address matches the sender's
address in the message, and (if a recipient address is specified or the
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
recipient requires an address) 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. To work with network
address translation, implementations MAY wish to use the directional
address type defined in section 8.1 for the sender address and include
no recipient address. Then the timestamp and usec and/or the sequence
number fields are checked. If timestamp and usec are expected and not
present, or they are present but not current, the KRB_AP_ERR_SKEW error
is generated. If the server name, along with the client name, time and
microsecond fields from the Authenticator match any 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 a sequence number is present, a
KRB_AP_ERR_MODIFIED error is generated.
If all the checks succeed, the application can assume the message was
generated by its peer, and was securely transmitted (without intruders
able to see the unencrypted contents).
3.6. The KRB_CRED Exchange
The KRB_CRED message may be used by clients requiring the ability to
send Kerberos credentials from one host to another. It achieves this by
sending the tickets together with encrypted data containing the session
keys and other information associated with the tickets.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
3.6.1. Generation of a KRB_CRED message
When an application wishes to send a KRB_CRED message it first (using
the KRB_TGS exchange) obtains credentials to be sent to the remote host.
It then constructs a KRB_CRED message using the ticket or tickets so
obtained, placing the session key needed to use each ticket in the key
field of the corresponding KrbCredInfo sequence of the encrypted part of
the the KRB_CRED message.
Other information associated with each ticket and obtained during the
KRB_TGS exchange is also placed in the corresponding KrbCredInfo
sequence in the encrypted part of the KRB_CRED message. The current time
and, if specifically required by the application the nonce, s-address,
and r-address fields, are placed in the encrypted part of the KRB_CRED
message which is then encrypted under an encryption key previously
exchanged in the KRB_AP exchange (usually the last key negotiated via
subkeys, or the session key if no negotiation has occurred).
Implementation note: [ Regarding When constructing a KRB_CRED message for inclusion
in a GSSAPI initial context token, the MIT implementation of Kerberos
will not encrypt the KRB_CRED message if the session key is a DES or
tripple DES key. For interoperability with MIT, the Microsoft
implementation will not encrypt the KRB_CRED in a GSSAPI token if it is
using a DES session key. Starting at version 1.2.5, MIT Kerberos can
receive and decode either encrypted or unencrypted KRB_CRED messages go here. We
need to make sure we understand what tokens in
the GSSAPI exchange. The Heimdal implementation of Kerberos can also
accept either encrypted or unencrypted KRB_CRED messages. Since the
KRB_CRED message in a GSSAPI token is encrypted in the authenticator,
the MIT behavior does and reconcile with Microsoft.] not present a security problem, although it is a
violation of the Kerberos specification.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
3.6.2. Receipt of KRB_CRED message
When an application receives a KRB_CRED message, it verifies it. If any
error occurs, an error code is reported for use by the application. The
message is verified by checking that the protocol version and type
fields match the current version and KRB_CRED, respectively. A mismatch
generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The
application then decrypts the ciphertext and processes the resultant
plaintext. If decryption shows the data to have been modified, a
KRB_AP_ERR_BAD_INTEGRITY error is generated.
If present or required, the recipient verifies MAY verify that the operating
system's report of the sender's address matches the sender's address in
the message, and that one of the recipient's addresses appears as the
recipient's address in the message. The address check does not provide
any added security, since the address if present has already been
checked in the KRB_AP_REQ message and there is not any benefit to be
gained by an attacker in reflecting a KRB_CRED message back to its
originator. Thus, the recipient MAY wish to ignore the address even if
present in order to work better in NAT environments. A failed match for
either case generates a KRB_AP_ERR_BADADDR error. The Recipients MAY wish to
skip the address check as the KRB_CRED message cannot generally be
reflected back toThe timestamp and usec fields (and the nonce field if
required) are checked next. If the timestamp and usec are not present,
or they are present but not current, the KRB_AP_ERR_SKEW error is
generated.
If all the checks succeed, the application stores each of the new
tickets in its ticket cache together with the session key and other
information in the corresponding KrbCredInfo sequence from the encrypted
part of the KRB_CRED message.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
4. SECTION HAS BEEN DELETED
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
5. Message Specifications
NOTE: This section is awaiting update. It is the old text from the Salt Lake
version. It has not been updated and made uniform with the single The ASN.1
Module in Appenix A. Appendix A collected here should be considered the authoritative
component of identical to the current state contents of the draft until this section is update.
Appendix A.
NOTE: We are continuing to work on changes to message format extensibility
as discussed at the London meeting. We believe the general form discussed The semantics described here should also not conflict with those
in
London will continue to be a useful strategy for pursuing this goal. We
expect to have additional information by the Salt Lake City meeting. TODO:
TypedData section 3, though that still needs to be looked at carefully, particularly with regard to
TD-APP-DEFINED-ERROR, etc. Some significant changes from 1510 to here have
been written up; more proofreading is needed. - tlyu checking.
The Kerberos protocol is defined here in terms of Abstract Syntax
Notation One (ASN.1), which provides a syntax for specifying both the
abstract layout of protocol messages as well as their encodings.
Implementors not utilizing an existing ASN.1 compiler or support library
are cautioned to thoroughly understand the actual ASN.1 specification to
ensure correct implementation behavior, as there is more complexity in
the notation than is immediately obvious, and some tutorials and guides
to ASN.1 are misleading or erroneous.
Note that in several places, there have been changes here from RFC 1510
that change the abstract types. This is in part to address widespread
assumptions that various implementations have made, in some cases unintentionally
violating
resulting in unintentional violations of the ASN.1 standard in various ways. standard. These will
be clearly flagged when they occur. The changes to differences between the abstract
types in RFC 1510 and abstract types in this document can cause
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
incompatible encodings to be emitted when certain encoding rules, e.g.
the Packed Encoding Rules (PER) (PER), are used. This theoretical
incompatibility should not be relevant for Kerberos, since Kerberos
explicitly specifies the use of the Distinguished Encoding Rules (DER). This
It might be an issue for protocols wishing to use Kerberos types with
other encoding rules. (This practice is not recommended.) With very few
exceptions (most notably the usages of BIT STRING), the encodings
emitted by the DER, which are the only encodings permitted by this document
and by RFC 1510, DER remain identical.
The type definitions identical between the types defined in RFC
1510 and the types defined in this document.
The type definitions in this section assume an ASN.1 module definition
of the following form:
Kerberos5 {
iso (1), org(3), dod(6), internet(1), security(5),
iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
} DEFINITIONS ::= BEGIN
-- rest of definitions here
END
This specifies an explicit non-automatic that the tagging context for the ASN.1 type
definitions. module will be explicit
and non-automatic.
Note that in some other publications [RFC1510] [RFC1964], the "dod"
portion of the object identifier is erroneously specified as having the
value "5".
draft-ietf-krb-wg-kerberos-clarifications-00 In the case of RFC 1964, use of the "correct" OID value would
result in a change in the wire protocol; therefore, it remains unchanged
for now.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 22 August 2002 9 March 2003
Note that elsewhere in this document, nomenclature for various message
types is inconsistent, but seems to largely follow C language
conventions, including use of underscore (_) characters and all-caps
spelling of names intended to be numeric constants. Also, in some
places, identifiers (especially ones refering to constants) are written
in all-caps in order to distinguish them from surrounding explanatory text.
The ASN.1 notation does not permit underscores in identifiers, so in
actual ASN.1 definitions, underscores are replaced with hyphens (-).
Additionally, structure member names and defined values in ASN.1 must
begin with a lowercase letter, while type names must begin with an
uppercase letter.
5.1. Specific Compatibility Notes on ASN.1
For compatibility purposes, implementors should heed the following
specific notes regarding the use of ASN.1 in Kerberos. These notes do
not describe a
non-standard deviations from standard usage of ASN.1, but rather ASN.1. The purpose of
these notes is to instead describe some historical quirks and
non-compliance of various implementations, as well as historical
ambiguities, which, while being valid ASN.1, can lead to confusion
during implementation.
5.1.1. ASN.1 Distinguished Encoding Rules
The encoding of Kerberos protocol messages shall obey the Distinguished
Encoding Rules (DER) of ASN.1 as described in X.690 (1997). Some
implementations (believed to be primarly ones derived from DCE 1.1 and
earlier) are known to use the more general Basic Encoding Rules (BER);
in particular, these implementations send indefinite encodings of
lengths. Implementations may accept such encodings in the interests of
backwards compatibility, though implementors are warned that decoding
fully-general BER is fraught with peril.
5.1.2. Optional Integer Fields in ASN.1 Sequences
Some implementations behave as if certain default values are equivalent to
omission of do not internally distinguish between an omitted
optional value. Implementations should handle this case
gracefully. For example, the seq-number field in an Authenticator is
optional, but some implementations use an internal integer value and a transmitted value of zero to indicate
that zero. The places in
the field protocol where this is to be relevant include various microseconds fields,
nonces, and sequence numbers. Implementations should treat omitted upon encoding. [While it is possible to use
the DEFAULT qualifier for the ASN.1 notation of
optional integer values as having been transmitted with a SEQUENCE member in order
to mandate this behavior, the result would be that the member would be
mandatory to omit if the value intended is that specified by the DEFAULT
keyword. This limits the possible semantics of zero,
if the protocol.] application is expecting this.
5.1.3. Zero-length SEQUENCE Types
There are places in the protocol where a message contains a SEQUENCE OF
type as an optional member, or a SEQUENCE type where all members are
optional. This can result in an encoding that contains an a zero-length
SEQUENCE or SEQUENCE OF encoding. In general, implementations Implementations should not send
zero-length SEQUENCE OF or SEQUENCE encodings that are marked OPTIONAL,
but should accept them. [XXX there may be cases where them as being equivalent to an empty SEQUENCE type has
useful semantics, though]
draft-ietf-krb-wg-kerberos-clarifications-00 omitted OPTIONAL type.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 22 August 2002 9 March 2003
5.1.4. Unrecognized Tag Numbers
Future revisions to this protocol may include new message types with
different APPLICATION class tag numbers. Such revisions should protect
older implementations by only sending the message types to parties that
are known to understand them, e.g. by means of a flag bit set by the
receiver in a preceding request. In the interest of robust error
handling, implementations should gracefully handle receiving a message
with an unrecognized tag anyway, and return an error message if
appropriate.
5.1.5. Tag Numbers Greater Than 30
A naive implementation of a DER ASN.1 decoder may experience problems
with ASN.1 tag numbers greater than 30, due to such tag numbers being
encoded using more than one byte. Future revisions of this protocol may
utilize tag numbers greater than 30, and implementations should be
prepared to gracefully return an error, if appropriate, if they do not
recognize the tag.
5.2. Basic Kerberos Types
This section defines a number of basic types that are potentially used
in multiple Kerberos protocol messages.
5.2.1. KerberosString
[XXX The following paragraphs may need some editing, or maybe they want
to live in a footnote]
[XXX Note that this duplicates much of the contents of jaltman's draft]
The original specification of the Kerberos protocol in RFC 1510 uses
GeneralString in numerous places for human-readable string data.
Historical implementations of Kerberos cannot utilize the full power of
GeneralString. This ASN.1 type requires the use of designation and
invocation escape sequences as specified in ISO 2022 to switch character
sets, and the default character set that is designated for G0 is
basically US ASCII, which mostly works. In practice, many
implementations end up treating GeneralStrings as if they were strings
of whatever character set the implementation defaults to, without regard
for correct usage of character set designation escape sequences.
Also, DER prohibits the invocation of character sets into any but the G0
and C0 sets, which seems to outright prohibit the encoding of characters
with the high bit set. Unfortunately, this seems to have the side effect
of prohibiting the transmission of Latin-1 characters or any other
characters that belong to a 96-character set, since it is prohibited to
invoke them into G0. Some inconclusive discussion has taken place within
the ASN.1 community on this subject. For now, we must assume that the
ASN.1 specification of GeneralString as currently published is
fundamentally flawed in several ways.
One method of resolving these myriad difficulties is to constrain the
use of GeneralString to only include IA5String, which is essentially the
US-ASCII. US-ASCII control characters should in general not be used in
KerberosString, except for cases such as newlines in lengthy error
messages.
draft-ietf-krb-wg-kerberos-clarifications-00
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 22 August 2002 9 March 2003
The new (since RFC 1510) type KerberosString, defined below, is a CHOICE
containing a
GeneralString that is constrained to only contain characters in
IA5String (which are US-ASCII). Note that the ASN.1 standard does not
permit the use of escape sequences to change the character sets while
encoding an IA5String.
KerberosString ::= CHOICE {
general GeneralString (IA5String),
...
}
This CHOICE is extensible, so that when an interoperable solution for
internationalization is chosen, it will be easier to specify the changed
types. In the future, changes to this protocol that allow for extensions to
this CHOICE will be specified so that the transmitting party has some way of
knowing whether the receiving party can accept the chosen alternative of the
CHOICE. (IA5String)
Implementations may choose to accept GeneralString values that contain
characters other than those permitted by IA5String, but they should be
aware that character set designation codes will likely be absent, and
that the encoding should probably be treated as locale-specific in
almost every way. Implementations may also choose to emit GeneralString
values that are beyond those permitted by IA5String, but should be aware
that doing so is extraordinarily risky from an interoperability
perspective.
Some existing implementations use GeneralString to encode unescaped
locale-specific characters. This is in violation of the ASN.1 standard.
Most of these implementations encode US-ASCII in the left-hand half, so
as long the implementation transmits only US-ASCII, the ASN.1 standard
is not violated in this regard. As soon as such an implementation
encodes unescaped locale-specific characters with the high bit set, it
violates the ASN.1 standard.
Other implementations have been known to use GeneralString to contain a
UTF-8 encoding. This also violates the ASN.1 standard, since UTF-8 is a
different encoding, not a 94 or 96 character "G" set as defined by ISO
2022. It is believed that these implementations do not even use the ISO
2022 escape sequence to change the character encoding. Even if
implementations were to announce the change of encoding by using that
escape sequence, the ASN.1 standard prohibits the use of any escape
sequences other than those used to designate/invoke "G" or "C" sets
allowed by GeneralString.
Future revisions to this protocol will almost certainly allow for a more
interoperable representation of principal names, probably including
UTF8String.
Note that both applying a new constraint to a previously unconstrained type
and replacing a type with a CHOICE containing that type constitute creations
constitutes creation of a new ASN.1 types. type. In the case here, this particular case, the
change here does not result in a changed encoding under DER. Also, note that various text in the ASN.1
standard actually suggests the strategy of replacing a type with a CHOICE
containing that type for certain deprecated types, even though this creates
a new type.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
5.2.2. Realm and PrincipalName
Realm ::= KerberosString
PrincipalName ::= SEQUENCE {
name-type[0]
name-type [0] Int32,
name-string[1]
name-string [1] SEQUENCE OF KerberosString
}
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
Kerberos realm names are encoded as KerberosStrings. Realms shall not
contain a character with the code 0 (the ASCII NUL). Most realms will
usually consist of several components separated by periods (.), in the
style of Internet Domain Names, or separated by slashes (/) in the style
of X.500 names. Acceptable forms for realm names are specified in
section 7. A PrincipalName is a typed sequence of components consisting
of the 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 hint. Ignoring the name type, no two names
can be the same (i.e. at least one of the components, or the realm,
must be different). This constraint may be eliminated in the future.
name-string
This field encodes a sequence of components that form a name, each
component encoded as a KerberosString. Taken together, a
PrincipalName and a Realm form a principal identifier. Most
PrincipalNames will have only a few components (typically one or two).
5.2.3. KerberosTime
KerberosTime ::= GeneralizedTime -- with no fractional seconds
The timestamps used in Kerberos are encoded as GeneralizedTimes. A
KerberosTime value shall not include any fractional portions of the
seconds. As required by the DER, it further shall not include any
separators, and it shall specify the UTC time zone (Z). Example: The
only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6
November 1985 is 19851106210627Z.
5.2.4. Constrained Integer types
Some integer members of types should be constrained to values
representable in 32 bits, for compatibility with reasonable
implementation limits.
Int32 ::= INTEGER (-2147483648..2147483647)
-- signed values representable in 32 bits
UInt32 :: = ::= INTEGER (0..4294967295)
-- unsigned 32 bit values
Microseconds ::= INTEGER (0..99999) (0..999999)
-- microseconds
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
While this results in changes to the abstract types from the RFC 1510
version, the encoding in DER should be unaltered. Historical
implementations were typically limited to 32-bit integer values anyway,
and assigned numbers should fall in the space of integer values
representable in 32 bits in order to promote interoperability anyway.
There are some members of messages types that are still defined as
unconstrained INTEGER types, but many of these have a (non-ASN.1)
constraint applied in the descriptive text. There are specific cases
where more discussion needs to occur regarding possible constraints,
such as for the nonce fields in various messages.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
There are several integer fields in messages that are constrained to
fixed values.
pvno
also TKT-VNO or AUTHENTICATOR-VNO, this recurring field is always
the constant integer 5. There is no easy way to make this field into
a useful protocol version number, so its value is fixed.
msg-type
this integer field usually is identical to the application tag
number of the containing message type.
5.2.5. HostAddress and HostAddresses
HostAddress ::= SEQUENCE {
addr-type[0]
addr-type [0] Int32,
address[1]
address [1] OCTET STRING
}
-- XXX HostAddresses is always used as an OPTIONAL field and can be
-- zero-length.
HostAddresses -- XXX subtly different from rfc1510,
-- but has a value mapping and encodes the same
::= SEQUENCE OF HostAddress
The host address encodings consists of two fields:
addr-type
This field specifies the type of address that follows. Pre-defined
values for this field are specified 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.
5.2.6. AuthorizationData
-- XXX AuthorizationData is always used as an OPTIONAL field and can
-- be zero-length.
AuthorizationData ::= SEQUENCE OF SEQUENCE {
ad-type[0]
ad-type [0] Int32,
ad-data[1]
ad-data [1] OCTET STRING
}
ad-data
This field contains authorization data to be interpreted according
to the value of the corresponding ad-type field.
ad-type
This field specifies the format for the ad-data subfield. All
negative values are reserved for local use. Non-negative values are
reserved for registered use.
Each sequence of type and data is referred to as an authorization
element. Elements may be application specific, however, there is a
common set of recursive elements that should be understood by all
implementations. These elements contain other elements embedded within
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
them, and the interpretation of the encapsulating element determines
which of the embedded elements must be interpreted, and which may be
ignored. Definitions for these common elements may be found in Appendix B.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
B <#ap_adata>.
5.2.7. PA-DATA
Historically, PA-DATA have been known as "pre-authentication data",
meaning that they were used to augment the initial authentication with
the KDC. Since that time, they have also been used as a typed hole with
which to extend protocol exchanges with the KDC.
PA-DATA ::= SEQUENCE {
padata-type[1] Int32,
padata-value[2]
padata-type [1] Int32 -- first tag is [1], not [0] --,
padata-value [2] OCTET STRING -- might be encoded AP-REQ
}
padata-type
indicates the way that the padata-value element is to be
interpreted. Negative values of padata-type are reserved for
unregistered use; non-negative values are used for a registered
interpretation of the element type.
padata-value
Usually contains the DER encoding of another type; the padata-type
field identifies which type is encoded here.
padata-type name contents of padata-value
1 pa-tgs-req DER encoding of AP-REQ
2 pa-enc-timestamp DER encoding of PA-ENC-TIMESTAMP
3 pa-pw-salt salt (not ASN.1 encoded)
10 pa-etype-info DER encoding of PA-ETYPE-INFO
20 pa-use-specified-kvno DER encoding of INTEGER
[XXX -- the following paragraph needs discussion, as does the general
concept of authenticating the cleartext pieces of the protocol]
This field may also contain information needed by certain extensions to
the Kerberos protocol. For example, it might be used to initially verify
the identity of a client before any response is returned. When this field is
used to
[XXX -- The following paragraph is subject to change pending the outcome
of discussions concerning authenticated cleartext]
When this field is used to authenticate or pre-authenticate a request,
it should contain a keyed checksum over the KDC-REQ-BODY to bind the
pre-authentication data to rest of the request. The KDC, as a matter of
policy, may decide whether to honor a KDC-REQ which includes any
pre-authentication data that does not contain the checksum field.
It may also be used by the client to specify the version of a key that
is being used for accompanying preauthentication, and/or which should be
used to encrypt the reply from the KDC. [XXX the following paragraph
should apply perhaps to PA-DATA in general]
The padata field can also contain information needed to help the KDC or
the client select the key needed for generating or decrypting the
response. This form of the padata is useful for supporting the use of
certain token cards with Kerberos. The details of such extensions are
specified in separate documents. See [Pat92] for additional uses of this
field.
draft-ietf-krb-wg-kerberos-clarifications-00
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 22 August 2002 9 March 2003
5.2.7.1. PA-TGS-REQ
In the case of requests for additional tickets (KRB_TGS_REQ),
padata-value will contain an encoded AP-REQ. The checksum in the
authenticator (which must be collision-proof) is to be computed over the
KDC-REQ-BODY encoding.
5.2.7.2. Encrypted Timestamp Pre-authentication
There are pre-authentication types that may be used to pre-authenticate
a client by means of an encrypted timestamp. The original PA-ENC-TIMESTAMP
does not contain a checksum of the KDC-REQ-BODY, while the PA-ENC-TIMESTAMP2
does.
PA-ENC-TIMESTAMP ::= EncryptedData -- encrypted PA-ENC-TS-ENC
PA-ENC-TS-ENC ::= SEQUENCE {
patimestamp[0] KerberosTime, -- client's time
pausec[1] Microseconds OPTIONAL
}
-- XXX maybe remove ENC-TIMESTAMP2 for now?
PA-ENC-TIMESTAMP2 ::= EncryptedData -- encrypted PA-ENC-TS2-ENC
PA-ENC-TS2-ENC ::= SEQUENCE {
patimestamp[0] KerberosTime,
patimestamp [0] KerberosTime -- client's time
pausec[1] --,
pausec [1] Microseconds OPTIONAL,
pachecksum[2] Checksum OPTIONAL
-- keyed checksum of KDC-REQ-BODY
}
Patimestamp contains the client's time, and pausec contains the
microseconds, which may be omitted if a client will not generate more
than one request per second. The ciphertext (padata-value) consists of
the PA-ENC-TS-ENC or PA-ENC-TS2-ENC encoding, encrypted using the client's secret key.
This preauthentication type was not present in RFC 1510, but many
implementations support it.
5.2.7.3. PA-PW-SALT
The padata-value for this preauthentication type contains the salt for
the string-to-key to be used by the client to obtain the key for
decrypting the encrypted part of an AS-REP message. Unfortunately, for
historical reasons, the character set to be used is unspecified and
probably locale-specific.
This preauthentication type was not present in RFC 1510, but many
implementations support it. It is necessary in any case where the salt
for the string-to-key algorithm is not the default.
In the trivial example, a zero-length salt string is very commonplace
for realms that have converted their principal databases from Kerberos 4.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
5.2.7.4. PA-ETYPE-INFO
The ETYPE-INFO preauthentication type is sent by the KDC in a KRB-ERROR
indicating a requirement for additional preauthentication. It is usually
used to notify a client of which key to use for the encryption of an
encrypted timestamp for the purposes of sending a PA-ENC-TIMESTAMP
preauthentication value.
ETYPE-INFO-ENTRY ::= SEQUENCE {
etype[0] INTEGER,
salt[1]
etype [0] Int32,
salt [1] OCTET STRING OPTIONAL
}
ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
The salt, like that of PA-PW-SALT, is also completely unspecified with
respect to character set and is probably locale-specific.
[XXX -- not clear whether ETYPE-INFO or PW-SALT should take precedence
if they conflict]
This preauthentication type was not present in RFC 1510, but many
implementations that support encrypted timestamps for preauthentication
need to support ETYPE-INFO as well.
5.2.7.5. PA-USE-SPECIFIED-KVNO
The KDC should only accept and abide by the value of the use-specified-kvno
preauthentication data field when the specified key is still valid and until
use of a new key is confirmed. This situation is likely to occur primarily
during the period during which an updated key is propagating to other KDC's
in a realm.
5.2.8. KerberosFlags
For several message types, a specific constrained bit string type,
KerberosFlags, is used.
KerberosFlags ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits
-- shall be sent, but no fewer than 32
Compatibility note: the following paragraphs describe a change from the
RFC1510 description of bit strings that would result in incompatility in
the case of an implementation that strictly conformed to ASN.1 DER and
RFC1510.
ASN.1 bit strings have multiple uses. The simplest use of a bit string
is to contain a vector of bits, with no particular meaning attached to
individual bits. This vector of bits is not necessarily a multiple of
eight bits long. The use in Kerberos of a bit string as a compact
boolean vector wherein each element has a distinct meaning poses some
problems. The natural notation for a compact boolean vector is the ASN.1
"NamedBit" notation, and the DER require that encodings of a bit string
using "NamedBit" notation exclude any trailing zero bits. This
truncation is easy to neglect, especially given C language
implementations that may naturally choose to store boolean vectors as 32
bit integers.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
For example, if the notation for KDCOptions were to include the
"NamedBit" notation, as in RFC 1510, and a KDCOptions value to be
encoded had only the "forwardable" (bit number one) bit set, the DER
encoding must only include two bits: the first reserved bit ("reserved",
bit number zero, value zero) and the one-valued bit (bit number one) for
"forwardable".
Most existing implementations of Kerberos unconditionally send 32 bits
on the wire when encoding bit strings used as boolean vectors. This
behavior violates the ASN.1 syntax used for flag values in RFC 1510, but
occurs on such a widely installed base that the protocol description is
being modified to accomodate it.
Consequently, this document removes the "NamedBit" notations for
individual bits, relegating them to comments. The size constraint on the
KerberosFlags type requires that at least 32 bits be encoded at all
times, though a lenient implementation may choose to accept fewer than
32 bits and to treat the missing bits as set to zero.
Currently, no uses of KerberosFlags specify more than 32 bits worth of
flags, although future revisions of this document may do so. When more
than 32 bits are to be transmitted in a KerberosFlags value, future
revisions to this document will likely specify that the smallest number
of bits needed to encode the highest-numbered one-valued bit should be
sent. This is somewhat similar to the DER encoding of a bit string that
is declared with the "NamedBit" notation.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
5.2.9. Cryptosystem-related Types
Many Kerberos protocol messages contain an EncryptedData as a container
for arbitrary encrypted data, which is often the encrypted encoding of
another data type. Fields within EncryptedData assist the recipient in
selecting a key with which to decrypt the enclosed data.
EncryptedData ::= SEQUENCE {
etype[0] Int32,
etype [0] Int32 -- EncryptionType
kvno[1] INTEGER --,
kvno [1] UInt32 OPTIONAL,
cipher[2]
cipher [2] OCTET STRING -- ciphertext
}
etype
This field identifies which encryption algorithm was used to
encipher the cipher. Detailed specifications for selected encryption
types appear in section 6. kvno
This field contains the version number of the key under which data
is encrypted. It is only present in messages encrypted under long
lasting keys, such as principals' secret keys. cipher
This field contains the enciphered text, encoded as an OCTET STRING.
The EncryptionKey type is the means by which cryptographic keys used for
encryption are transfered.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
EncryptionKey ::= SEQUENCE {
keytype[0] Int32,
keytype [0] Int32 -- actually encryption type
keyvalue[1] --,
keyvalue [1] OCTET STRING
}
keytype
This field specifies the encryption type of the encryption key that
follows in the keyvalue field. While its name is "keytype", it
actually specifies an encryption type. Previously, multiple
cryptosystems that performed encryption differently but were capable
of using keys with the same characteristics were permitted to share
an assigned number to designate the type of key; this usage is now
deprecated. keyvalue
This field contains the key itself, encoded as an octet string.
All negative values for the encryption key type are reserved for
local use. All non-negative values are reserved for officially
assigned type fields and interpretations.
Messages containing cleartext data to be authenticated will usually do
so by using a member of type Checksum. Most instances of Checksum use a
keyed hash, though exceptions will be noted.
Checksum ::= SEQUENCE {
cksumtype[0]
cksumtype [0] Int32,
checksum[1]
checksum [1] OCTET STRING
}
cksumtype
This field indicates the algorithm used to generate the accompanying
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
checksum. checksum
This field contains the checksum itself, encoded as an octet string.
Detailed specification of selected checksum types appear in section
6. Negative values for the checksum type are reserved for local use.
All non-negative values are reserved for officially assigned type
fields and interpretations.
5.3. Tickets and Authenticators
This section describes the format and encryption parameters for tickets
and authenticators. When a ticket or authenticator is included in a
protocol message it is treated as an opaque object.
5.3.1. Tickets A ticket is a record
that helps a client authenticate to a service. A Ticket contains the
following information:
Ticket ::= [APPLICATION 1] SEQUENCE {
tkt-vno[0] INTEGER,
realm[1]
tkt-vno [0] INTEGER (5),
realm [1] Realm,
sname[2]
sname [2] PrincipalName,
enc-part[3]
enc-part [3] EncryptedData --EncTicketPart -- EncTicketPart
}
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
-- Encrypted part of ticket
EncTicketPart ::= [APPLICATION 3] SEQUENCE {
flags[0]
flags [0] TicketFlags,
key[1]
key [1] EncryptionKey,
crealm[2]
crealm [2] Realm,
cname[3]
cname [3] PrincipalName,
transited[4]
transited [4] TransitedEncoding,
authtime[5]
authtime [5] KerberosTime,
starttime[6]
starttime [6] KerberosTime OPTIONAL,
endtime[7]
endtime [7] KerberosTime,
renew-till[8]
renew-till [8] KerberosTime OPTIONAL,
caddr[9]
caddr [9] HostAddresses OPTIONAL,
authorization-data[10]
authorization-data [10] AuthorizationData OPTIONAL
}
-- encoded Transited field
TransitedEncoding ::= SEQUENCE {
tr-type[0] Int32,
tr-type [0] Int32 -- must be registered
contents[1] --,
contents [1] OCTET STRING
}
TicketFlags ::= KerberosFlags
-- reserved(0),
-- forwardable(1),
-- forwarded(2),
-- proxiable(3),
-- proxy(4),
-- may-postdate(5),
-- postdated(6),
-- invalid(7),
-- renewable(8),
-- initial(9),
-- pre-authent(10),
-- hw-authent(11),
-- the following are new since 1510; maybe remove from krb-clarifications?
-- transited-policy-checked(12),
-- ok-as-delegate(13)
-- anonymous(14)
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
The encoding of EncTicketPart is encrypted in the key shared by Kerberos
and the end server (the server's secret key). See section 6 for the
format of the ciphertext.
tkt-vno
This field specifies the version number for the ticket format. This
document describes version number 5.
realm
This field specifies the realm that issued a ticket. It also serves
to identify the realm part of the server's principal identifier.
Since a Kerberos server can only issue tickets for servers within
its realm, the two will always be identical.
sname
This field specifies all components of the name part of the server's
identity, including those parts that identify a specific instance of
a service.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
enc-part
This field holds the encrypted encoding of the EncTicketPart sequence.
flags
This field indicates which of various options were used or requested
when the ticket was issued. 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). [XXX X.690 ref and
notes on pitfalls?] The meanings of the flags are:
Bit(s) Name Description
0 reserved Reserved for future expansion of this field.
1 forwardable The FORWARDABLE flag is normally only interpreted by
the TGS, and can be ignored by end servers. When set, this
1 forwardable flag
tells the ticket-granting server that it is OK to issue a new
ticket-granting ticket with a different network address based on the
presented ticket.
2 forwarded When set, this flag indicates that the ticket has either
been forwarded or
2 forwarded was issued based on authentication involving a
forwarded ticket-granting ticket.
3 proxiable The PROXIABLE flag is normally only interpreted by the
TGS, and can be ignored by end servers. The PROXIABLE flag has an
interpretation identical
3 proxiable to that of the 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.
4 proxy When set, this flag indicates that a ticket is a proxy.
5 may-postdate The MAY-POSTDATE flag is normally only interpreted by
the TGS, and can be
5 may-postdate ignored by end servers. This flag tells the
ticket-granting server that a 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
6 postdated can check the authtime field to see when the
original authentication occurred.
draft-ietf-krb-wg-kerberos-clarifications-00
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 22 August 2002 9 March 2003
7 invalid This flag indicates that a ticket is invalid, and it must
be validated by
7 invalid the KDC before use. Application servers must reject
tickets which have this flag set.
8 renewable The RENEWABLE flag is normally only interpreted by the
TGS, and can usually be ignored by end servers
8 renewable (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
9 initial was issued using the
AS protocol, and 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
10 pre-authent
ticket was issued. The strength of the preauthentication method is
not indicated, but is acceptable to the KDC.
11 hw-authent This flag indicates that the protocol employed for
initial authentication required the use of hardware expected
11 hw-authent to be
possessed solely by the named client. The hardware authentication
method is selected by the KDC and the strength of the method is not
indicated.
12 transited- policy-checked This flag indicates that the KDC for
the realm has checked the transited field against a realm defined
policy for trusted certifiers. If this flag is reset (0), then the
application server must check the transited field itself, and if
unable to do so it must reject the authentication. If the flag
12 transited- is
set (1) then the application server
policy-checked may skip its own validation of
the transited field, relying on the validation performed by the KDC.
At its option the application server may still apply its own
validation based on a separate policy for acceptance.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
This flag is new since RFC 1510.
13 ok-as-delegate This flag indicates that the server (not the
client) specified in the ticket has been determined by policy of the
realm to be a suitable recipient of delegation. A client can use the
presence of this flag to help it make a decision whether to delegate
credentials (either grant a proxy or a forwarded ticket granting
ticket) to
13 ok-as-delegate this server. The client is free to ignore the value of
this flag. When setting this flag, an administrator should consider
the Security and placement of the server on which the service will
run, as well as whether the service requires the use of delegated
credentials.
This flag is new since RFC 1510.
This flag indicates that the principal
named in the ticket is a generic
principal for the realm and does not
identify the individual using the
ticket. The purpose of the ticket is
only to securely distribute a session
key, and not to identify the user.
14 anonymous Subsequent requests using the same
ticket and session may be considered
as originating from the same user, but
requests with the same username but a
different ticket are likely to
originate from different users.
This flag is new since RFC 1510.
15-31
14-31 reserved Reserved for future use.
key
This field exists in the ticket and the KDC response and is used to
pass the session key from Kerberos to the application server and the
client. The field's encoding is described in section 6.2.
crealm
This field contains the name of the realm in which the client is
registered and in which initial authentication took place.
cname
This field contains the name part of the client's principal identifier.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
transited
This field lists the names of the Kerberos realms that took part in
authenticating the user to whom this ticket was issued. It does not
specify the order in which the realms were transited. See section
3.3.3.2 for details on how this field encodes the traversed realms.
When the names of CA's are to be embedded in the transited field (as
specified for some extensions to the protocol), the X.500 names of
the CA's should be mapped into items in the transited field using
the mapping defined by RFC2253.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
authtime
This field indicates the time of initial authentication for the
named principal. It is the time of issue for the original ticket on
which this ticket is based. It is included in the ticket to provide
additional information to the end service, and to provide the
necessary information for implementation of a `hot list' service at
the KDC. An end service that is particularly paranoid could refuse
to accept tickets for which the initial authentication occurred "too
far" in the past. This field is also returned as part of the
response from the KDC. When returned as part of the response to
initial authentication (KRB_AS_REP), this is the current time on the
Kerberos server[24].
starttime
This field in the ticket specifies the time after which the ticket
is valid. Together with endtime, this field specifies the life of
the ticket. If it is absent from the ticket, 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 the life of a ticket and may reject
tickets which have not yet expired. As such, this is really an upper
bound on the expiration time for the ticket.
renew-till
This field is only present in tickets that have the RENEWABLE flag
set in the flags field. It indicates the maximum endtime that may be
included in a renewal. It can be thought of as the absolute
expiration time for the ticket, including all renewals.
caddr
This field in a ticket contains zero (if omitted) or more (if
present) host addresses. These are the addresses from which the
ticket can be used. If there are no addresses, the ticket can be
used from any location. The decision by the KDC to issue or by the
end server to accept zero-address tickets is a policy decision and
is left to the Kerberos and end-service administrators; they may
refuse to issue or accept such tickets. The suggested and default
policy, however, is that such tickets will only be issued or
accepted when additional information that can be used to restrict
the use of the ticket is included in the authorization_data field.
Such a ticket is a capability.
Network addresses are included in the ticket to make it harder for
an attacker to use stolen credentials. Because the session key is
not sent over the network in cleartext, credentials can't be stolen
simply by listening to the network; an attacker has to gain access
to the session key (perhaps through operating system security
breaches or a careless user's unattended session) to make use of
stolen tickets.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
It is important to note that the network address from which a
connection is received cannot be reliably determined. Even if it
could be, an attacker who has compromised the client's workstation
could use the credentials from there. Including the network
addresses only makes it more difficult, not impossible, for an
attacker to walk off with stolen credentials and then use them from
a "safe" location.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
authorization-data
The authorization-data field is used to pass authorization data from
the principal on whose behalf a ticket was issued to the application
service. If no authorization data is included, this field will be
left out. Experience has shown that the name of this field is
confusing, and that a better name for this field would be
restrictions. Unfortunately, it is not possible to change the name
of this field at this time.
This field contains restrictions on any authority obtained on the
basis of authentication using the ticket. It is possible for any
principal in posession of credentials to add entries to the
authorization data field since these entries further restrict what
can be done with the ticket. Such additions can be made by
specifying the additional entries when a new ticket is obtained
during the TGS exchange, or they may be added during chained
delegation using the authorization data field of the authenticator.
Because entries may be added to this field by the holder of
credentials, except when an entry is separately authenticated by
encapsulation in the kdc-issued element, it is not allowable for the
presence of an entry in the authorization data field of a ticket to
amplify the privileges one would obtain from using a ticket.
The data in this field may be specific to the end service; the field
will contain the names of service specific objects, and the rights
to those objects. The format for this field is described in section
5.2. Although Kerberos is not concerned with the format of the
contents of the sub-fields, it does carry type information (ad-type).
By using the authorization_data field, a principal is able to issue
a proxy that is valid for a specific purpose. For example, a client
wishing to print a file can obtain a file server proxy to be passed
to the print server. By specifying the name of the file in the
authorization_data field, the file server knows that the print
server can only use the client's rights when accessing the
particular file to be printed.
A separate service providing authorization or certifying group
membership may be built using the authorization-data field. In this
case, the entity granting authorization (not the authorized entity),
may obtain a ticket in its own name (e.g. the ticket is issued in
the name of a privilege server), and this entity adds restrictions
on its own authority and delegates the restricted authority through
a proxy to the client. The client would then present this
authorization credential to the application server separately from
the authentication exchange. Alternatively, such authorization
credentials may be embedded in the ticket authenticating the
authorized entity, when the authorization is separately
authenticated using the kdc-issued authorization data element (see
B.4).
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
Similarly, if one specifies the authorization-data field of a proxy
and leaves the host addresses blank, the resulting ticket and
session key can be treated as a capability. See [Neu93] for some
suggested uses of this field.
The authorization-data field is optional and does not have to be
included in a ticket.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
5.3.2. Authenticators
An authenticator is a record sent with a ticket to a server to certify
5.4. Specifications for the
client's knowledge AS and TGS exchanges
This section specifies the format of the encryption key messages used in the ticket, to help exchange
between the server
detect replays, client and to help choose a "true session key" to use with the
particular session. Kerberos server. The encoding is encrypted in the ticket's session key
shared by the client and the server:
-- Unencrypted authenticator
Authenticator ::= [APPLICATION 2] SEQUENCE {
authenticator-vno[0] INTEGER,
crealm[1] Realm,
cname[2] PrincipalName,
cksum[3] Checksum OPTIONAL,
cusec[4] Microseconds,
ctime[5] KerberosTime,
subkey[6] EncryptionKey OPTIONAL,
seq-number[7] UInt32 OPTIONAL,
authorization-data[8] AuthorizationData OPTIONAL
}
authenticator-vno
This field specifies the version number for the format of the
authenticator. This document specifies version 5.
crealm and cname
These fields are the same as those described for the ticket in section
5.3.1.
cksum
This field contains a checksum of the the application data 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 to specify a
reasonably accurate timestamp.
ctime
This field contains the current time on the client's host.
subkey
This field contains the 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 session
key from the ticket will be used.
seq-number
This optional field includes the initial sequence number to be used by
the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to
detect replays (It may also be used by application specific messages).
When included in the authenticator this field specifies the initial
sequence number for messages from the client to the server. When
included in the AP-REP message, the initial sequence number is that for
messages from the server to the client. When used in KRB_PRIV or
KRB_SAFE messages, it is incremented by one after each message is sent.
Sequence numbers fall in the range of 0 through 2^32 - 1 and wrap to
zero following the value 2^32 - 1.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
For sequence numbers to adequately support the detection of replays
they should be non-repeating, even across connection boundaries. The
initial sequence number should be random and uniformly distributed
across the full space of possible sequence numbers, so that it cannot
be guessed by an attacker and so that it and the successive sequence
numbers do not repeat other sequences.
authorization-data
This field is the same as described for the ticket in section 5.3.1. It
is optional and will only appear when additional restrictions are to be
placed on the use of a ticket, beyond those carried in the ticket
itself.
5.4. Specifications for the AS and TGS exchanges
This section specifies the format of the messages used in the exchange
between the client and the Kerberos server. The format of possible error
messages appears format of possible error
messages appears in section 5.9.1.
5.4.1. KRB_KDC_REQ definition
The KRB_KDC_REQ message has no type application tag number of its own.
Instead, its type it is incorporated into one of KRB_AS_REQ or KRB_TGS_REQ KRB_TGS_REQ, which
each have an application tag, depending on whether the request is for an
initial ticket or an additional ticket. In either case, the message is
sent from the client to the Authentication Server KDC to request credentials for a service.
The message 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]
pvno [1] INTEGER (5) -- first tag is [1], not [0] --,
msg-type [2] INTEGER (10 -- AS -- | 12 -- TGS --),
padata [3] SEQUENCE OF PA-DATA OPTIONAL,
req-body[4] OPTIONAL
-- XXX may be zero-length --,
req-body [4] KDC-REQ-BODY
}
KDC-REQ-BODY ::= SEQUENCE {
kdc-options[0]
kdc-options [0] KDCOptions,
cname[1]
cname [1] PrincipalName OPTIONAL, OPTIONAL
-- Used only in AS-REQ
realm[2] Realm, --,
realm [2] Realm
-- Server's realm
-- Also client's in AS-REQ
sname[3] --,
sname [3] PrincipalName OPTIONAL,
from[4]
from [4] KerberosTime OPTIONAL,
till[5]
till [5] KerberosTime,
rtime[6]
rtime [6] KerberosTime OPTIONAL,
nonce[7] INTEGER,
etype[8]
nonce [7] UInt32,
etype [8] SEQUENCE OF Int32, Int32 -- EncryptionType, EncryptionType
-- in preference order
addresses[9] --,
addresses [9] HostAddresses OPTIONAL,
enc-authorization-data[10]
enc-authorization-data [10] EncryptedData OPTIONAL, -- Encrypted AuthorizationData
-- encoding
additional-tickets[11] --,
additional-tickets [11] SEQUENCE OF Ticket OPTIONAL
-- XXX may be zero-length
}
draft-ietf-krb-wg-kerberos-clarifications-00
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 22 August 2002 9 March 2003
KDCOptions ::= KerberosFlags
-- reserved(0),
-- forwardable(1),
-- forwarded(2),
-- proxiable(3),
-- proxy(4),
-- allow-postdate(5),
-- postdated(6),
-- unused7(7),
-- renewable(8),
-- unused9(9),
-- unused10(10),
-- unused11(11),
-- unused12(12),
-- unused13(13),
-- requestanonymous(14),
-- canonicalize(15), 26 was unused in 1510
-- disable-transited-check(26),
--
-- renewable-ok(27),
-- enc-tkt-in-skey(28),
-- renew(30),
-- validate(31)
The fields in this message are:
pvno
This field is included in each message, and specifies the protocol
version number. This document specifies protocol version 5.
msg-type
This field indicates the type of a protocol message. It will almost
always be the same as the application identifier associated with a
message. It is included to make the identifier more readily
accessible to the application. For the KDC-REQ message, this type
will be KRB_AS_REQ or KRB_TGS_REQ.
padata
Contains pre-authentication data. Requests for additional tickets
(KRB_TGS_REQ) must contain a padata of PA-TGS-REQ.
The padata (pre-authentication data) field contains a sequence of
authentication information which may be needed before credentials
can be issued or decrypted. In most requests for initial
authentication (KRB_AS_REQ) and most replies (KDC-REP), the padata
field will be left out.
req-body
This field is a placeholder delimiting the extent of the remaining
fields. If a checksum is to be calculated over the request, it is
calculated over an encoding of the KDC-REQ-BODY sequence which is
enclosed within the req-body field.
kdc-options
This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to the
KDC and indicates the flags that the client wants set on the tickets
as well as other information that is to modify the behavior of the
KDC. Where appropriate, the name of an option may be the same as the
flag that is set by that option. Although in most case, the bit in
the options field will be the same as that in the flags field, this
is not guaranteed, so it is not acceptable to simply copy the
options field to the flags field. There are various checks that must
be made before honoring an option anyway.
draft-ietf-krb-wg-kerberos-clarifications-00
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 22 August 2002 9 March 2003
The kdc_options field is a bit-field, where the selected options are
indicated by the bit being set (1), and the unselected options and
reserved fields being reset (0). The encoding of the bits is
specified in section 5.2. The options are described in more detail
above in section 2. The meanings of the options are:
Bits Name Description
0 RESERVED Reserved for future expansion of this field.
1 FORWARDABLE The FORWARDABLE option indicates that the ticket to be
issued is to have its forwardable flag set. It
1 FORWARDABLE 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 forwardable.
2 FORWARDED The FORWARDED option is only specified in a request to
the ticket-granting server and will only be honored if the
ticket-granting ticket in the request has its
2 FORWARDED FORWARDABLE bit set.
This option indicates that this is a request for forwarding. The
address(es) of the host from which the resulting ticket is to be
valid are included in the addresses field of the request.
3 PROXIABLE The PROXIABLE option indicates that the ticket to be
issued is to have its proxiable flag set. It may only
3 PROXIABLE 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 indicates that this is a request for a
proxy. This option will only be honored if the ticket-granting
ticket in the
4 PROXY request has its PROXIABLE bit set. The address(es) of
the host from which the resulting ticket is to be valid are included
in the addresses field of the request.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
5 ALLOW-POSTDATE The ALLOW-POSTDATE option indicates that the ticket
to be issued is to have its MAY-POSTDATE flag set. It
5 ALLOW-POSTDATE may only be
set on the initial request, or in a subsequent request if the
ticket-granting ticket on which it is based also has its
MAY-POSTDATE flag set.
6 POSTDATED The POSTDATED option indicates that this is a request
for a postdated ticket. This option will only be honored if the
ticket-granting ticket on which it is based has its
6 POSTDATED MAY-POSTDATE
flag set. The resulting ticket will also have its INVALID flag set,
and that flag may be reset by a subsequent request to the KDC after
the starttime in the ticket has been reached.
7 UNUSED This option is presently unused.
8 RENEWABLE The RENEWABLE option indicates that the ticket to be
issued is to have its RENEWABLE flag set. It may only be set on the
initial request, or when the ticket-granting ticket on
8 RENEWABLE which the
request is based is also renewable. If this option is requested,
then the rtime field in the request contains the desired absolute
expiration time for the ticket.
9 RESERVED Reserved for PK-Cross
10-13 UNUSED These options are presently unused.
The REQUEST-ANONYMOUS option
indicates that the ticket to be
issued is not to identify the user
to which it was issued. Instead, the
principal identifier is to be
generic, as specified by the policy
of the realm (e.g. usually
anonymous@realm). The purpose of the
14 REQUEST-ANONYMOUS ticket is only to securely
distribute a session key, and not to
identify the user. The ANONYMOUS
flag on the ticket to be returned
should be set. If the local realms
policy does not permit anonymous
credentials, the request is to be
rejected.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
This flag is new since RFC 1510
The CANONICALIZE option indicates
that the client will accept the
return of a true server name instead
of the name specified in the
request. In addition the client will
be able to process any TGT referrals
that will direct the client to
another realm to locate the
15 CANONICALIZE requested server. If a KDC does not
support name- canonicalization, the
option is ignored and the
appropriate
KDC_ERR_C_PRINCIPAL_UNKNOWN or
KDC_ERR_S_PRINCIPAL_UNKNOWN error is
returned. [JBrezak]
This flag is new since RFC 1510
16-25
14-25 RESERVED Reserved for future use.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
26 DISABLE-TRANSITED-CHECK By default the KDC will check the
transited field of a ticket-granting-ticket against the policy of
the local realm before it will issue derivative tickets based on the
ticket granting ticket. If this flag is set in the request, checking
of the transited field is disabled. Tickets issued without the
26 DISABLE-TRANSITED-CHECK
performance of this check will be noted by the reset (0) value of
the TRANSITED-POLICY-CHECKED flag, indicating to the application
server that the tranisted field must be checked locally. KDC's are
encouraged but not required to honor the DISABLE-TRANSITED-CHECK
option.
This flag is new since RFC 1510
27 RENEWABLE-OK The RENEWABLE-OK option indicates that a renewable
ticket will be acceptable if a ticket with the requested life cannot
otherwise be provided. If a ticket with the requested life cannot be
provided,
27 RENEWABLE-OK then a renewable ticket may be issued with a renew-till
equal to the the requested endtime. The value of the renew-till
field may still be limited by local limits, or limits selected by
the individual principal or server.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
28 ENC-TKT-IN-SKEY This option is used only by the ticket-granting
service. The ENC-TKT-IN-SKEY option indicates
28 ENC-TKT-IN-SKEY that the ticket for
the end server is to be encrypted in the session key from the
additional ticket-granting ticket provided.
29 RESERVED Reserved for future use.
30 RENEW This option is used only by the ticket-granting service.
The RENEW option indicates that the present request is for a
renewal. The ticket provided is encrypted in the secret key for the
server on which it is
30 RENEW valid. This option will only be honored if the
ticket to be renewed has its RENEWABLE flag set and if the time in
its renew-till field has not passed. The ticket to be renewed is
passed in the padata field as part of the authentication header.
31 VALIDATE This option is used only by the ticket-granting service.
The VALIDATE option indicates that the request is to validate a
postdated ticket. It will only be honored if the ticket presented is
postdated, presently has its INVALID flag set,
31 VALIDATE and would be
otherwise usable at this time. A ticket cannot be validated before
its starttime. The ticket presented for validation is encrypted in
the key of the server for which it is valid and is passed in the
padata field as part of the authentication header.
cname and sname
These fields are the same as those described for the ticket in
section 5.3.1. sname may only be absent when the ENC-TKT-IN-SKEY
option is specified. If absent, the name of the server is taken from
the name of the client in the ticket passed as additional-tickets.
enc-authorization-data
The enc-authorization-data, if present (and it can only be present
in the TGS_REQ form), is an encoding of the desired
authorization-data encrypted under the sub-session key if present in
the Authenticator, or alternatively from the session key in the
ticket-granting ticket, both from the padata field in the KRB_AP_REQ.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
realm
This field specifies the realm part of the server's principal
identifier. In the AS exchange, this is also the realm part of the
client's principal identifier. If the CANONICALIZE option is set,
the realm is used as a hint to the KDC for its database lookup.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
from
This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket
requests when the requested ticket is to be postdated. It specifies
the desired start time for the requested ticket. If this field is
omitted then the KDC should use the current time instead.
till
This field contains the expiration date requested by the client in a
ticket request. [XXX This was optional in kerberos-revisions, but
required in 1510. we should make it required and specify semantics for
19700101000000Z] It is optional and not optional, but if omitted the requested endtime is
"19700101000000Z", the requested ticket is to have the maximum
endtime permitted according to KDC policy for the
parties for. This special
timestamp corresponds to the authentication exchange as limited by expiration date a UNIX time_t value of
the ticket granting ticket or other preauthentication credentials. zero on most systems.
rtime
This field is the requested renew-till time sent from a client to
the KDC in a ticket request. It is optional.
nonce
This field is part of the KDC request and response. It it intended
to hold a random number generated by the client. If the same number
is included in the encrypted response from the KDC, it provides
evidence that the response is fresh and has not been replayed by an
attacker. Nonces must never be re-used. Ideally, it should be
generated randomly, but if the correct time is known, it may
suffice[25].
etype
This field specifies the desired encryption algorithm to be used in
the response.
addresses
This field is included in the initial request for tickets, and
optionally included in requests for additional tickets from the
ticket-granting server. It specifies the addresses from which the
requested ticket is to be valid. Normally it includes the addresses
for the client's host. If a proxy is requested, this field will
contain other addresses. The contents of this field are usually
copied by the KDC into the caddr field of the resulting ticket.
additional-tickets
Additional tickets may be optionally included in a request to the
ticket-granting server. If the ENC-TKT-IN-SKEY option has been
specified, then the session key from the additional ticket will be
used in place of the server's key to encrypt the new ticket. When
the ENC-TKT-IN-SKEY option is used for user-to-user authentication,
this addional ticket may be a TGT issued by the local realm or an
inter-realm TGT issued for the current KDC's realm by a remote KDC.
If more than one option which requires additional tickets has been
specified, then the additional tickets are used in the order
specified by the ordering of the options bits (see kdc-options, above).
The application tag number will be either ten (10) or twelve (12)
depending on whether the request is for an initial ticket (AS-REQ) or
for an additional ticket (TGS-REQ).
The optional fields (addresses, authorization-data and
additional-tickets) are only included if necessary to perform the
operation specified in the kdc-options field.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
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 the padata field.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
5.4.2. KRB_KDC_REP definition
The KRB_KDC_REP message format is used for the reply from the KDC for
either an initial (AS) request or a subsequent (TGS) request. There is
no message type for KRB_KDC_REP. Instead, the type will be either
KRB_AS_REP or KRB_TGS_REP. The key used to encrypt the ciphertext part
of the reply depends on the message type. For KRB_AS_REP, the ciphertext
is encrypted in the client's secret key, and the client's key version
number is included in the key version number for the encrypted data. For
KRB_TGS_REP, the ciphertext is encrypted in the sub-session key from the
Authenticator, 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]
pvno [0] INTEGER (5),
msg-type [1] INTEGER (11 -- AS -- | 13 -- TGS --),
padata [2] SEQUENCE OF PA-DATA OPTIONAL,
crealm[3] OPTIONAL
-- XXX may be zero length --,
crealm [3] Realm,
cname[4]
cname [4] PrincipalName,
ticket[5]
ticket [5] Ticket,
enc-part[6]
enc-part [6] EncryptedData
-- EncASREpPart EncASRepPart or EncTGSReoOart EncTGSRepPart,
-- as appropriate
}
EncASRepPart ::= [APPLICATION 25] EncKDCRepPart -- note [27]
EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart
EncKDCRepPart ::= SEQUENCE {
key[0]
key [0] EncryptionKey,
last-req[1]
last-req [1] LastReq,
nonce[2] INTEGER,
key-expiration[3]
nonce [2] UInt32,
key-expiration [3] KerberosTime OPTIONAL,
flags[4]
flags [4] TicketFlags,
authtime[5]
authtime [5] KerberosTime,
starttime[6]
starttime [6] KerberosTime OPTIONAL,
endtime[7]
endtime [7] KerberosTime,
renew-till[8]
renew-till [8] KerberosTime OPTIONAL,
srealm[9]
srealm [9] Realm,
sname[10]
sname [10] PrincipalName,
caddr[11]
caddr [11] HostAddresses OPTIONAL
}
LastReq ::= SEQUENCE OF SEQUENCE {
lr-type[0]
lr-type [0] Int32,
lr-value[1]
lr-value [1] KerberosTime
}
draft-ietf-krb-wg-kerberos-clarifications-00
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 22 August 2002 9 March 2003
pvno and msg-type
These fields are described above in section 5.4.1. msg-type is
either KRB_AS_REP or KRB_TGS_REP.
padata
This field is described in detail in section 5.4.1. One possible use
for this field is to encode an alternate "mix-in" string to be used
with a string-to-key algorithm (such as is 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 KDC database would be
flagged as needing a special mix-in string until the next password
change.
crealm, cname, srealm and sname
These fields are the same as those described for the ticket in
section 5.3.1.
ticket
The newly-issued ticket, from section 5.3.1. enc-part
This field is a place holder for the ciphertext and related
information that forms the encrypted part of a message. The
description of the encrypted part of the message follows each
appearance of this field. The encrypted part is encoded as described
in section 6.1.
Compatibility note: Some implementations unconditionally send an
encrypted EncTGSRepPart (application tag number 26) in this field
regardless of whether the reply is a AS-REP or a TGS-REP. In the
interests of compatibility, implementors may wish to relax the check
on the tag number of the decrypted ENC-PART.
key
This field is the same as described for the ticket in section 5.3.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 might be the last time that a request for a
ticket-granting ticket was made, or the last time that a request
based on a ticket-granting ticket was successful. It also might
cover all servers for a realm, or just the particular server. Some
implementations may display this information to the user to aid in
discovering unauthorized use of one's identity. It is similar in
spirit to the last login time displayed when logging into
timesharing systems.
lr-type
This field indicates how the following lr-value field is to be
interpreted. Negative values indicate that the information pertains
only to the responding server. Non-negative values pertain to all
servers for the realm.
If the lr-type field is zero (0), then no information is conveyed by
the lr-value subfield. If the absolute value of the lr-type field is
one (1), then the lr-value subfield is the time of last initial
request for a TGT. If it is two (2), then the lr-value subfield is
the time of last initial request. If it is three (3), then the
lr-value subfield is the time of issue for the newest
ticket-granting ticket used. If it is four (4), then the lr-value
subfield is the time of the last renewal. If it is five (5), then
the lr-value subfield is the time of last request (of any type). If
it is (6), then the lr-value subfield is the time when the password
will expire.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
lr-value
This field contains the time of the last request. the time must be
interpreted according to the contents of the accompanying lr-type
subfield.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
nonce
This field is described above in section 5.4.1.
key-expiration
The key-expiration field is part of the response from the KDC and
specifies the time that the client's secret key is due to expire.
The expiration might be the result of password aging or an account
expiration. This field will usually be left out of the TGS reply
since the response to the TGS request is encrypted in a session key
and no client information need be retrieved from the KDC database.
It is up to the application client (usually the login program) to
take appropriate action (such as notifying the user) if the
expiration time is imminent.
flags, authtime, starttime, endtime, renew-till and caddr
These fields are duplicates of those found in the encrypted portion
of the attached ticket (see section 5.3.1), provided so the client
may verify they match the intended request and to assist in proper
ticket caching. If the message is of type KRB_TGS_REP, the caddr
field will only be filled in if the request was for a proxy or
forwarded ticket, or if the user is substituting a subset of the
addresses from the ticket granting ticket. If the client-requested
addresses are not present or not used, then the addresses contained
in the ticket will be the same as those included in the
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 to the application server.
5.5.1. KRB_AP_REQ definition
The KRB_AP_REQ message contains the Kerberos protocol version number,
the message type KRB_AP_REQ, an options field to indicate any options in
use, and the ticket and authenticator themselves. The KRB_AP_REQ message
is often referred to as the 'authentication header'.
AP-REQ ::= [APPLICATION 14] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
ap-options[2]
pvno [0] INTEGER (5),
msg-type [1] INTEGER (14),
ap-options [2] APOptions,
ticket[3]
ticket [3] Ticket,
authenticator[4]
authenticator [4] EncryptedData -- Authenticator from 5.3.2
}
APOptions ::= KerberosFlags
-- reserved(0),
-- use-session-key(1),
-- mutual-required(2)
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
pvno and msg-type
These fields are described above in section 5.4.1. msg-type is
KRB_AP_REQ.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002 ap-options
This field appears in the application request (KRB_AP_REQ) and
affects the way the request is processed. It is a bit-field, where
the selected options are indicated by the bit being set (1), and the
unselected options and reserved fields being reset (0). The encoding
of the bits is specified in section 5.2. The meanings of the options
are:
Bit(s) Name Description
0 reserved Reserved for future expansion of this field.
1 use-session-key The USE-SESSION-KEY option indicates that the
ticket the client is presenting to a server
1 use-session-key is encrypted in the
session key from the server's ticket-granting ticket. When this
option is not specified, the ticket is encrypted in the server's
secret key.
2 mutual-required The MUTUAL-REQUIRED option tells the server
2 mutual-required that
the client requires mutual authentication, and that it must respond
with a KRB_AP_REP message.
3-31 reserved Reserved for future use.
ticket
This field is a ticket authenticating the client to the server.
authenticator
This contains the encrypted authenticator, which includes the
client's choice of a subkey. Its encoding is described in section 5.3.2.
5.5.2. KRB_AP_REP definition
The KRB_AP_REP message contains the Kerberos protocol version number, the
message type, and an encrypted time- stamp. The message authenticator is sent in included in
response the AP-REQ; it certifies to an application request (KRB_AP_REQ) where a
server that the mutual
authentication option sender has been selected in the ap-options field.
AP-REP ::= [APPLICATION 15] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
enc-part[2] EncryptedData recent knowledge of the encryption key in the
accompanying ticket, to help the server detect replays. It also assists
in the selection of a "true session key" to use with the particular
session. The DER encoding of the following is encrypted in the ticket's
session key:
-- EncAPRepPart
}
EncAPRepPart Unencrypted authenticator
Authenticator ::= [APPLICATION 27] 2] SEQUENCE { -- note [29]
ctime[0] KerberosTime,
cusec[1]
authenticator-vno [0] INTEGER (5),
crealm [1] Realm,
cname [2] PrincipalName,
cksum [3] Checksum OPTIONAL,
cusec [4] Microseconds,
subkey[2]
ctime [5] KerberosTime,
subkey [6] EncryptionKey OPTIONAL,
seq-number[3]
seq-number [7] UInt32 OPTIONAL,
authorization-data [8] AuthorizationData OPTIONAL
}
The encoded EncAPRepPart is encrypted in
authenticator-vno
This field specifies the shared session key version number for the format of the
ticket. The optional subkey field can be used in an application-arranged
negotiation to choose a per association session key.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
pvno
authenticator. This document specifies version 5. crealm and msg-type cname
These fields are the same as those described above in section 5.4.1. msg-type is
KRB_AP_REP.
enc-part
This field is described above for the ticket in
section 5.4.2.
ctime 5.3.1.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
cksum
This field contains a checksum of the current time on the client's host. application data 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 to
specify a reasonably accurate timestamp.
ctime
This field contains the current time on the client's host. subkey
This field contains the client's choice for an encryption key which
is to be used to protect this specific application session. See section 3.2.6 for specifics on
how this field is used to negotiate a key. Unless
an application specifies otherwise, if this field is left out, the sub-session key
from the authenticator, or if also left out, out the
session key from the ticket will be used.
seq-number
This optional field is described above in section 5.3.2.
5.5.3. Error message reply
If an error occurs while processing the application request, includes the KRB_ERROR
message will initial sequence number to be sent in response. See section 5.9.1 for the format of used
by the
error message. The cname and crealm fields KRB_PRIV or KRB_SAFE messages when sequence numbers are used
to detect replays (It may also be left out if used by application specific
messages). When included in the server
cannot determine their appropriate values authenticator this field specifies
the initial sequence number for messages from the corresponding KRB_AP_REQ
message. If client to the authenticator was decipherable,
server. When included in the ctime and cusec fields
will contain AP-REP message, the values initial sequence
number is that for messages from it.
5.6. KRB_SAFE message specification
This section specifies the format of a message that can be used by either
side (client or server) of an application to send a tamper-proof message server to
its peer. It presumes that a session key has previously been exchanged (for
example, by using the KRB_AP_REQ/KRB_AP_REP messages).
There are two client. When used
in KRB_PRIV or KRB_SAFE messages; the KRB-SAFE message messages, it is the incremented by one specified
in RFC 1510. The KRB-SAFE2 after
each message is new with this document, and shares a
number of fields with sent. Sequence numbers fall in the old KRB-SAFE message.
5.6.1. KRB_SAFE definition
The KRB_SAFE message contains user data along with a collision-proof
checksum keyed with range of 0
through 2^32 - 1 and wrap to zero following the last encryption key negotiated via subkeys, or value 2^32 - 1.
For sequence numbers to adequately support the
session key if no negotiation has occurred. detection of replays
they should be non-repeating, even across connection boundaries. The
initial sequence number should be random and uniformly distributed
across the full space of possible sequence numbers, so that it
cannot be guessed by an attacker and so that it and the successive
sequence numbers do not repeat other sequences.
Implmentation note: historically, some implementations transmit
signed twos-complement numbers for sequence numbers. In the
interests of compatibility, implementations may accept the
equivalent negative number where a positive number greater than 2^31
- 1 is expected.
Implementation note: as noted before, some implementations omit the
optional sequence number when its value would be zero.
Implementations may accept an omitted sequence number when expecting
a value of zero, and should not transmit an Authenticator with a
sequence number of zero.
authorization-data
This field is the same as described for the ticket in section 5.3.1.
It is optional and will only appear when additional restrictions are
to be placed on the use of a ticket, beyond those carried in the
ticket itself.
5.5.2. KRB_AP_REP definition
The KRB_AP_REP message fields are:
KRB-SAFE contains the Kerberos protocol version number,
the message type, and an encrypted time- stamp. The message is sent in
response to an application request (KRB_AP_REQ) where the mutual
authentication option has been selected in the ap-options field.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
AP-REP ::= [APPLICATION 20] 15] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
safe-body[2] KRB-SAFE-BODY,
cksum[3] Checksum
pvno [0] INTEGER (5),
msg-type [1] INTEGER (15),
enc-part [2] EncryptedData -- EncAPRepPart
}
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
KRB-SAFE-BODY
EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
user-data[0] OCTET STRING,
timestamp[1] KerberosTime OPTIONAL,
usec[2] Microseconds
ctime [0] KerberosTime,
cusec [1] Microseconds,
subkey [2] EncryptionKey OPTIONAL,
seq-number[3]
seq-number [3] UInt32 OPTIONAL,
s-address[4] HostAddress,
r-address[5] HostAddress OPTIONAL
}
The encoded EncAPRepPart is encrypted in the shared session key of the
ticket. The optional subkey field can be used in an application-arranged
negotiation to choose a per association session key.
pvno and msg-type
These fields are described above in section 5.4.1. msg-type is KRB_SAFE
or KRB_SAFE2, respectively, for the KRB-SAFE and KRB-SAFE2 messages.
safe-body
KRB_AP_REP.
enc-part
This field is a placeholder for described above in section 5.4.2.
ctime
This field contains the body of current time on the KRB-SAFE message.
cksum client's host.
cusec
This field contains the checksum microsecond part of the client's
timestamp.
subkey
This field contains an encryption key which is to be used to protect
this specific application data. Checksum
details are described in session. See section 6.4.
The checksum is computed over the encoding of the KRB-SAFE sequence.
First, the cksum 3.2.6 for specifics
on how this field is set used to negotiate a type zero, zero-length value and the
checksum key. Unless an application
specifies otherwise, if this field is computed over the encoding of the KRB-SAFE sequence, then left out, the checksum is set to sub-session key
from the result of that computation, and finally authenticator, or if also left out, the
KRB-SAFE sequence is encoded again. This method, while different than session key from
the one specified in RFC 1510, corresponds to existing practice.
user-data ticket will be used.
seq-number
This field is part of the KRB_SAFE and KRB_PRIV messages and contain described above in section 5.3.2.
5.5.3. Error message reply
If an error occurs while processing the application specific data that is being passed from request, the sender to
KRB_ERROR message will be sent in response. See section 5.9.1 for the recipient.
timestamp
This field is part
format of the KRB_SAFE error message. The cname and KRB_PRIV crealm fields may be left out
if the server cannot determine their appropriate values from the
corresponding KRB_AP_REQ message. If the authenticator was decipherable,
the ctime and cusec fields will contain the values from it.
5.6. KRB_SAFE message specification
This section specifies the format of a message that can be used by
either side (client or server) of an application to send a tamper-proof
message to its peer. It presumes that a session key has previously been
exchanged (for example, by using the KRB_AP_REQ/KRB_AP_REP messages).
There are two KRB_SAFE messages; the KRB-SAFE message is the one
specified in RFC 1510. The KRB-SAFE2 message is new with this document,
and shares a number of fields with the old KRB-SAFE message.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
5.6.1. KRB_SAFE definition
The KRB_SAFE message contains user data along with a collision-proof
checksum keyed with the last encryption key negotiated via subkeys, or
the session key if no negotiation has occurred. The message fields are:
KRB-SAFE ::= [APPLICATION 20] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (20),
safe-body [2] KRB-SAFE-BODY,
cksum [3] Checksum
}
KRB-SAFE-BODY ::= SEQUENCE {
user-data [0] OCTET STRING,
timestamp [1] KerberosTime OPTIONAL,
usec [2] Microseconds OPTIONAL,
seq-number [3] UInt32 OPTIONAL,
s-address [4] HostAddress,
r-address [5] HostAddress OPTIONAL
}
pvno and msg-type
These fields are described above in section 5.4.1. msg-type is
KRB_SAFE or KRB_SAFE2, respectively, for the KRB-SAFE and KRB-SAFE2
messages.
safe-body
This field is a placeholder for the body of the KRB-SAFE message.
cksum
This field contains the checksum of the application data. Checksum
details are described in section 6.4.
The checksum is computed over the encoding of the KRB-SAFE sequence.
First, the cksum is set to a type zero, zero-length value and the
checksum is computed over the encoding of the KRB-SAFE sequence,
then the checksum is set to the result of that computation, and
finally the KRB-SAFE sequence is encoded again. This method, while
different than the one specified in RFC 1510, corresponds to
existing practice.
user-data
This field is part of the KRB_SAFE and KRB_PRIV messages and contain
the application specific data that is being passed from the sender
to the recipient.
timestamp
This field is part of the KRB_SAFE and KRB_PRIV messages. Its
contents are the current time as known by the sender of the message.
By checking the timestamp, the recipient of the message is able to
make sure that it was recently generated, and is not a replay.
usec
This field is part of the KRB_SAFE and KRB_PRIV headers. It contains
the microsecond part of the timestamp.
seq-number
This field is described above in section 5.3.2.
s-address
Sender's address.
This field specifies the address in use by the sender of the
message. It may be omitted if not required by the application protocol.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
r-address
This field specifies the address in use by the recipient of the
message. It may be omitted for some uses (such as broadcast
protocols), but the recipient may arbitrarily reject such messages.
This field, along with s-address, can be used to help detect
messages which have been incorrectly or maliciously delivered to the
wrong recipient.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
5.7. KRB_PRIV message specification
This section specifies the format of a message that can be used by
either side (client or server) of an application to securely and
privately send a message to its peer. It presumes that a session key has
previously been exchanged (for example, by using the
KRB_AP_REQ/KRB_AP_REP messages).
5.7.1. KRB_PRIV definition
The KRB_PRIV message contains user data encrypted in the Session Key.
The message fields are:
KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
enc-part[3]
pvno [0] INTEGER (5),
msg-type [1] INTEGER (21),
-- there is no [2] tag
enc-part [3] EncryptedData -- EncKrbPrivPart
}
EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { --note [31]
user-data[0]
user-data [0] OCTET STRING,
timestamp[1]
timestamp [1] KerberosTime OPTIONAL,
usec[2]
usec [2] Microseconds OPTIONAL,
seq-number[3]
seq-number [3] UInt32 OPTIONAL,
s-address[4] HostAddress,
s-address [4] HostAddress -- sender's addr
r-address[5] --,
r-address [5] HostAddress OPTIONAL -- recip's addr
}
pvno and msg-type
These fields are described above in section 5.4.1. msg-type is
KRB_PRIV.
enc-part
This field holds an encoding of the EncKrbPrivPart sequence
encrypted under the session key[32]. This encrypted encoding is used
for the enc-part field of the KRB-PRIV message. See section 6 for
the format of 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 is described above in section 5.3.2.
5.8. KRB_CRED message specification
This section specifies the format of a message that can be used to send
Kerberos credentials from one principal to another. It is presented here
to encourage a common mechanism to be used by applications when
forwarding tickets or providing proxies to subordinate servers. It
presumes that a session key has already been exchanged perhaps by using
the KRB_AP_REQ/KRB_AP_REP messages.
draft-ietf-krb-wg-kerberos-clarifications-00
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 22 August 2002 9 March 2003
5.8.1. KRB_CRED definition
The KRB_CRED message contains a sequence of tickets to be sent and
information needed to use the tickets, including the session key from
each. The information needed to use the tickets is encrypted under an
encryption key previously exchanged or transferred alongside the
KRB_CRED message. The message fields are:
KRB-CRED ::= [APPLICATION 22] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER, -- KRB_CRED
tickets[2]
pvno [0] INTEGER (5),
msg-type [1] INTEGER (22),
tickets [2] SEQUENCE OF Ticket,
enc-part[3]
enc-part [3] EncryptedData -- EncKrbCredPart
}
EncKrbCredPart ::= [APPLICATION 29] SEQUENCE {
ticket-info[0]
ticket-info [0] SEQUENCE OF KrbCredInfo,
nonce[1] INTEGER
nonce [1] UInt32 OPTIONAL,
timestamp[2]
timestamp [2] KerberosTime OPTIONAL,
usec[3]
usec [3] Microseconds OPTIONAL,
s-address[4]
s-address [4] HostAddress OPTIONAL,
r-address[5]
r-address [5] HostAddress OPTIONAL
}
KrbCredInfo ::= SEQUENCE {
key[0]
key [0] EncryptionKey,
prealm[1]
prealm [1] Realm OPTIONAL,
pname[2]
pname [2] PrincipalName OPTIONAL,
flags[3]
flags [3] TicketFlags OPTIONAL,
authtime[4]
authtime [4] KerberosTime OPTIONAL,
starttime[5]
starttime [5] KerberosTime OPTIONAL,
endtime[6]
endtime [6] KerberosTime OPTIONAL
renew-till[7] OPTIONAL,
renew-till [7] KerberosTime OPTIONAL,
srealm[8]
srealm [8] Realm OPTIONAL,
sname[9]
sname [9] PrincipalName OPTIONAL,
caddr[10]
caddr [10] HostAddresses OPTIONAL
}
pvno and msg-type
These fields are described above in section 5.4.1. msg-type is
KRB_CRED.
tickets
These are the tickets obtained from the KDC specifically for use by
the intended recipient. Successive tickets are paired with the
corresponding KrbCredInfo sequence from the enc-part of the KRB-CRED
message.
enc-part
This field holds an encoding of the EncKrbCredPart sequence
encrypted under the session key shared between the sender and the
intended recipient. This encrypted encoding is used for the enc-part
field of the KRB-CRED message. See section 6 for the format of the
ciphertext.
draft-ietf-krb-wg-kerberos-clarifications-00
Implementation note: implementations of certain applications, most
notably of the Kerberos GSS-API mechanism, do not encrypt the
KRB-CRED message when sending it. In the case of the GSS-API
mechanism, this is not a security vulnerability, as the KRB-CRED
message itself is itself encrypted inside an Authenticator.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 22 August 2002 9 March 2003
nonce
If practical, an application may require the inclusion of a nonce
generated by the recipient of the message. If the same value is
included as the nonce in the message, it provides evidence that the
message is fresh and has not been replayed by an attacker. A nonce
must never be re-used; it should be generated randomly by the
recipient of the message and provided to the sender of the message
in an application specific manner.
timestamp and usec
These fields specify the time that the KRB-CRED message was
generated. The time is used to provide assurance that the message is
fresh.
s-address and r-address
These fields are described above in section 5.6.1. They are used
optionally to provide additional assurance of the integrity of the
KRB-CRED message.
key
This field exists in the corresponding ticket passed by the KRB-CRED
message and is used to pass the session key from the sender to the
intended recipient. The field's encoding is described in section 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
The name and realm of the delegated principal identity.
flags, authtime, starttime, endtime, renew-till, srealm, sname, and caddr
These fields contain the values of the corresponding fields from the
ticket found in the ticket field. Descriptions of the fields are
identical to the descriptions in the KDC-REP message.
5.9. Error message specification
This section specifies the format for the KRB_ERROR message. The fields
included in the message are intended to return as much information as
possible about an error. It is not expected that all the information
required by the fields will be available for all types of errors. If the
appropriate information is not available when the message is composed,
the corresponding field will be left out of the message.
Note that since the KRB_ERROR message is only optionally not integrity protected, it is
quite possible for an intruder to synthesize or modify such a message.
In particular, this means that unless appropriate integrity
protection mechanisms have been applied to the KRB_ERROR message, the client should not use any fields in
this message for security-critical purposes, such as setting a system
clock or generating a fresh authenticator. The message can be useful,
however, for advising a user on the reason for some failure.
draft-ietf-krb-wg-kerberos-clarifications-00
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 22 August 2002 9 March 2003
5.9.1. KRB_ERROR definition
The KRB_ERROR message consists of the following fields:
KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
ctime[2]
pvno [0] INTEGER (5),
msg-type [1] INTEGER (30),
ctime [2] KerberosTime OPTIONAL,
cusec[3]
cusec [3] Microseconds OPTIONAL,
stime[4]
stime [4] KerberosTime,
susec[5]
susec [5] Microseconds,
error-code[6]
error-code [6] Int32,
crealm[7]
crealm [7] Realm OPTIONAL,
cname[8]
cname [8] PrincipalName OPTIONAL,
realm[9] Realm,
realm [9] Realm -- Correct realm
sname[10] PrincipalName, --,
sname [10] PrincipalName -- Correct name
e-text[11] --,
e-text [11] KerberosString OPTIONAL,
e-data[12]
e-data [12] OCTET STRING OPTIONAL
}
pvno and msg-type
These fields are described above in section 5.4.1. msg-type is
KRB_ERROR.
ctime
This field is described above in section 5.4.1.
cusec
This field is described above in section 5.5.2.
stime
This field contains the current time on the server. It is of type
KerberosTime.
susec
This field contains the microsecond part of the server's timestamp.
Its value ranges from 0 to 999999. It appears along with stime. The
two fields are used in conjunction to specify a reasonably accurate
timestamp.
error-code
This field contains the error code returned by Kerberos or the
server when a request fails. To interpret the value of this field
see the list of error codes in section 8. Implementations are
encouraged to provide for national language support in the display
of error messages.
crealm, cname, srealm and sname
These fields are described above in section 5.3.1. e-text
This field contains additional text to help explain the error code
associated with the failed request (for example, it might include a
principal name which was unknown).
e-data
This field contains additional data about the error for use by the
application to help it recover from or handle the error. If present,
this field will contain the encoding of a sequence of TypedData
(TYPED-DATA below), unless the
errorcode is KDC_ERR_PREAUTH_REQUIRED,
in which case it then the e-data field will
contain the an encoding of a sequence of of padata
fields (METHOD-DATA below), fields, each
corresponding to an acceptable
pre-authentication pre- authentication method and
optionally containing data for the method:
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
TYPED-DATA ::= SEQUENCE of TypedData
METHOD-DATA ::= SEQUENCE of PA-DATA
TypedData ::= SEQUENCE {
data-type[0] Int32,
data-value[1] OCTET STRING OPTIONAL
}
Note that the padata-type field in the PA-DATA structure and the
data-type field in the TypedData structure share a common range of
allocated values which are coordinated to avoid conflicts. One Kerberos
error message, KDC_ERR_PREAUTH_REQUIRED, embeds elements of type
PA-DATA, while all other error messages embed TypedData.
While preauthentication methods of type PA-DATA should be encapsulated
within a TypedData element of type TD-PADATA, for compatibility with
old clients, the KDC should include OF PA-DATA types below 22 directly as
method-data. All new implementations interpreting the METHOD-DATA field
for the KDC_ERR_PREAUTH_REQUIRED message must accept a type of
TD-PADATA, extract the typed data field and interpret the use any
elements encapsulated in the TD-PADATA elements as if they were present
in the METHOD-DATA sequence.
Unless otherwise specified, unrecognized TypedData elements within the
KRB-ERROR message MAY be ignored by implementations that do not support
them. Note that all TypedData MAY be bound to the KRB-ERROR message via
the checksum field.
An application may use the TD-APP-DEFINED-ERROR typed data type for
data carried in a Kerberos error message that is specific to the
application. TD-APP-SPECIFIC must set the data-type value of TypedData
to TD-APP-SPECIFIC and the data-value field to
AppSpecificTypedData as follows:
AppSpecificTypedData ::= SEQUENCE {
oid[0] OPTIONAL OBJECT IDENTIFIER,
-- identifies the application
data-value[1] OCTET STRING
-- application
-- specific data
}
o The TD-REQ-NONCE TypedData MAY be used to bind a KRB-ERROR to a
KDC-REQ. The data-value is an INTEGER that is equivalent to the
nonce in a KDC-REQ.
o The TD-REQ-SEQ TypedData MAY be used for binding a KRB-ERROR to
the sequence number from an authenticator. The data-value is an
INTEGER, and it is identical to sequence number sent in the
authenticator.
o The data-value for TD-KRB-PRINCIPAL is the Kerberos-defined
PrincipalName. The data-value for TD-KRB-REALM is the
Kerberos-defined Realm. These TypedData types MAY be used to
indicate principal and realm name when appropriate.
draft-ietf-krb-wg-kerberos-clarifications-00
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 22 August 2002 9 March 2003
5.10. Application Tag Numbers
The following table lists the application class tag numbers used by
various data types defined in this section.
Tag Number(s) Type Name Comments
0 unused
1 Ticket
2 Authenticator
3 EncTicketPart
4-10 unused
10 AS-REQ
11 AS-REP
12 TGS-REQ
13 TGS-REP
14 AP-REQ
15 AP-REP
16 TGT-REQ
17-19 unused
20 KRB-SAFE
21 KRB-PRIV
22 KRB-PRIV
23-24 unused
25 EncASRepPart
26 EncTGSRepPart
27 EncApRepPart
28 EncKrbPrivPart
29 EncKrbCredPart
30 KRB-ERROR
draft-ietf-krb-wg-kerberos-clarifications-00
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 22 August 2002 9 March 2003
6. Encryption and Checksum Specifications
To do:
* Re-synchronize the key usage value list with any changes Tom
makes to the message definitions. KRB-ERROR checksum, for
example, and any new message types.
See end notes for other issues.
-- Ken 2002-01-02
The Kerberos protocols described in this document are designed to
encrypt blocks of arbitrary sizes, using stream or block encryption
ciphers. Encryption is used to prove the identities of the network
entities participating in message exchanges. The Key Distribution Center
for each realm is trusted by all principals registered in that realm to
store a secret key in confidence. Proof of knowledge of this secret key
is used to verify the authenticity of a principal.
The KDC uses the principal's secret key (in the AS exchange) or a shared
session key (in the TGS exchange) to encrypt responses to ticket
requests; the ability to obtain the secret key or session key implies
the knowledge of the appropriate keys and the identity of the KDC. The
ability of a principal to decrypt the KDC response and present a Ticket
and a properly formed Authenticator (generated with the session key from
the KDC response) to a service verifies the identity of the principal;
likewise the ability of the service to extract the session key from the
Ticket and prove its knowledge thereof in a response verifies the
identity of the service.
[KCRYPTO] defines a framework for defining encryption and checksum
mechanisms for use with Kerberos. It also defines several such
mechanisms, and more may be added in future updates to that document.
The string-to-key operation provided by [KCRYPTO] is used to produce a
long-term key for a principal (generally for a user). The default salt
string, if none is provided via preauthentication data, is the
concatenation of the principal's realm and name components, in order,
with no separators. Unless otherwise indicated, the default
string-to-key opaque parameter set as defined in [KCRYPTO] is used.
The encryption, decryption, and checksum operations used in this
document use the corresponding encryption, decryption, and get_mic
operations described in [KCRYPTO], with implicit "specific key"
generation using the key usage values outlined in section 6.1. Unless
otherwise indicated, no chaining of cipher state is done from one
encryption operation to another.
The EncryptedData object's "etype" and "cipher" fields are the
encryption mechanism type number and encryption operation output. The
EncryptionKey object's "keytype" and "keyvalue" fields are the
encryption mechanism type number and protocol key representation. The
Checksum object's "cksumtype" and "checksum" fields are the checksum
mechanism type number and get_mic operation output.
draft-ietf-krb-wg-kerberos-clarifications-00
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 22 August 2002 9 March 2003
6.1. Key Usage Values
The encryption and checksum specifications in [KCRYPTO] require as input
a "key usage number", to alter the encryption key used in any specific
message, to make certain types of cryptographic attack more difficult.
This is a list of key usage number definitions and reserved ranges,
including values for all places keys are used in the Kerberos protocol
and associated section numbers.
1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the client
key (section 5.4.1)
2. AS-REP Ticket and TGS-REP Ticket (includes TGS session key or
application session key), encrypted with the service key (section 5.4.2)
3. AS-REP encrypted part (includes TGS session key or application
session key), encrypted with the client key (section 5.4.2)
4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the TGS
session key (section 5.4.1)
5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the TGS
authenticator subkey (section 5.4.1)
6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed with the
TGS session key (sections 5.3.2, 5.4.1)
7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes TGS
authenticator subkey), encrypted with the TGS session key (section 5.3.2)
8. TGS-REP encrypted part (includes application session key), encrypted
with the TGS session key (section 5.4.2)
9. TGS-REP encrypted part (includes application session key), encrypted
with the TGS authenticator subkey (section 5.4.2)
10. AP-REQ Authenticator cksum, keyed with the application session key
(section 5.3.2)
11. AP-REQ Authenticator (includes application authenticator subkey),
encrypted with the application session key (section 5.3.2)
12. AP-REP encrypted part (includes application session subkey),
encrypted with the application session key (section 5.5.2)
13. KRB-PRIV encrypted part, encrypted with a key chosen by the
application (section 5.7.1)
14. KRB-CRED encrypted part, encrypted with a key chosen by the
application (section 5.6.1)
15. KRB-SAFE cksum, keyed with a key chosen by the application (section
5.8.1)
18. KRB-ERROR checksum (e-cksum in section 5.9.1)
19. AD-KDCIssued checksum (ad-checksum in appendix B.4)
20. Checksum for Mandatory Ticket Extensions (appendix B.6)
21. Checksum in Authorization Data in Ticket Extensions (appendix B.7)
22-24. Reserved for use in GSSAPI mechanisms derived from RFC 1964.
(raeburn/MIT)
25-511. Reserved for future use in Kerberos and related protocols.
512-1023. Reserved for uses internal to a Kerberos implementation. [6.1]
A few of these key usages need a little clarification. A service which
receives an AP-REQ has no way to know if the enclosed Ticket was part of
an AS-REP or TGS-REP. Therefore, key usage 2 must always be used for
generating a Ticket, whether it is in response to an AS-REQ or TGS-REQ.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
Key usage values between 1024 and 2047 (inclusive) are reserved for
application use. Applications should use even values for encryption and
odd values for checksums within this range.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
There might exist other documents which define protocols in terms of the
RFC1510 encryption types or checksum types. Such documents would not
know about key usages. In order that these specifications continue to be
meaningful until they are updated, key usages 1024 and 1025 must be used
to derive keys for encryption and checksums, respectively.[6.2] New
protocols defined in terms of the Kerberos encryption and checksum types
should use their own key usage values. Key usages are unsigned 32 bit
integers; zero is not permitted. Usage numbers may be registered with
IANA to avoid conflicts.
6.2. Implementation Notes
While we don't recommend it, undoubtedly some application protocols will
continue to use the key data directly, even if only in some of the
currently existing protocol specifications. An implementation intended
to support general Kerberos applications may therefore need to make the
key data available, as well as the attributes and operations described
in [KCRYPTO].
[6.3]
draft-ietf-krb-wg-kerberos-clarifications-00
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 22 August 2002 9 March 2003
7. Naming Constraints
7.1. Realm Names
Although realm names are encoded as GeneralStrings and although a realm
can technically select any name it chooses, interoperability across
realm boundaries requires agreement on how realm names are to be
assigned, and what information they imply.
To enforce these conventions, each realm must conform to the conventions
itself, and it must require that any realms with which inter-realm keys
are shared also conform to the conventions and require the same from its
neighbors.
Kerberos realm names are case sensitive. Realm names that differ only in
the case of the characters are not equivalent. There are presently four
styles of realm names: domain, X500, other, and reserved. Examples of
each style follow:
domain: ATHENA.MIT.EDU (example)
X500: C=US/O=OSF (example)
other: NAMETYPE:rest/of.name=without-restrictions (example)
reserved: reserved, but will not conflict with above
Domain syle realm names must look like domain names: they consist of
components separated by periods (.) and they contain neither colons (:)
nor slashes (/). Though domain names themselves are case insensitive, in
order for realms to match, the case must match as well. When
establishing a new realm name based on an internet domain name it is
recommended by convention that the characters be converted to upper case.
X.500 names contain an equal (=) and cannot contain a colon (:) before
the equal. The realm names for X.500 names will be string
representations of the names with components separated by slashes.
Leading and trailing slashes will not be included. Note that the slash
separator is consistent with Kerberos implementations based on RFC1510,
but it is different from the separator recommended in RFC2253.
Names that fall into the other category must begin with a prefix that
contains no equal (=) or period (.) and the prefix must be followed by a
colon (:) and the rest of the name. All prefixes must be assigned before
they may be used. Presently none are assigned.
The reserved category includes strings which do not fall into the first
three categories. All names in this category are reserved. It is
unlikely that names will be assigned to this category unless there is a
very strong argument for not using the 'other' category.
These rules guarantee that there will be no conflicts between the
various name styles. The following additional constraints apply to the
assignment of realm names in the domain and X.500 categories: the name
of a realm for the domain or X.500 formats must either be used by the
organization owning (to whom it was assigned) an Internet domain name or
X.500 name, or in the case that no such names are registered, authority
to use a realm name may be derived from the authority of the parent
realm. For example, if there is no domain name for E40.MIT.EDU, then the
administrator of the MIT.EDU realm can authorize the creation of a realm
with that name.
draft-ietf-krb-wg-kerberos-clarifications-00
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 22 August 2002 9 March 2003
This is acceptable because the organization to which the parent is
assigned is presumably the organization authorized to assign names to
its children in the X.500 and domain name systems as well. If the parent
assigns a realm name without also registering it in the domain name or
X.500 hierarchy, it is the parent's responsibility to make sure that
there will not in the future exist a name identical to the realm name of
the child unless it is assigned to the same entity as the realm name.
7.2. Principal Names
As was the case for realm names, conventions are needed to ensure that
all agree on what information is implied by a principal name. The
name-type field that is part of the principal name indicates the kind of
information implied by the name. The name-type should be treated only as
a hint to interpreting the meaning of a name. It is not significant when
checking for equivalence. Principal names that differ only in the
name-type identify the same principal. The name type does not partition
the name space. Ignoring the name type, no two names can be the same
(i.e. at least one of the components, or the realm, must be different).
The following name types are defined:
name-type value meaning
NT-UNKNOWN 0 Name type not known
NT-PRINCIPAL 1 General principal name (e.g. username, or DCE principal)
NT-SRV-INST 2 Service and other unique instance (krbtgt)
NT-SRV-HST 3 Service with host name as instance (telnet, rcommands)
NT-SRV-XHST 4 Service with slash-separated host name components
NT-UID 5 Unique ID
NT-X500-PRINCIPAL 6 Encoded X.509 Distingished name [RFC 1779]
NT-SMTP-NAME 7 Name in form of SMTP email name (e.g. user@foo.com)
NT-ENTERPRISE 10 Enterprise name - may be mapped to principal name
When a name implies no information other than its uniqueness at a
particular time the name type PRINCIPAL should be used. The principal
name type should be used for users, and it might also be used for a
unique server. If the name is a unique machine generated ID that is
guaranteed never to be reassigned then the name type of UID should be
used (note that it is generally a bad idea to reassign names of any type
since stale entries might remain in access control lists).
If the first component of a name identifies a service and the remaining
components identify an instance of the service in a server specified
manner, then the name type of SRV-INST should be used. An example of
this name type is the Kerberos ticket-granting service whose name has a
first component of krbtgt and a second component identifying the realm
for which the ticket is valid.
If instance is a single component following the service name and the
instance identifies the host on which the server is running, then the
name type SRV-HST should be used. This type is typically used for
Internet services such as telnet and the Berkeley R commands. If the
separate components of the host name appear as successive components
following the name of the service, then the name type SRV-XHST should be
used. This type might be used to identify servers on hosts with X.500
names where the slash (/) might otherwise be ambiguous.
draft-ietf-krb-wg-kerberos-clarifications-00
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 22 August 2002 9 March 2003
A name type of NT-X500-PRINCIPAL should be used when a name from an
X.509 certificate is translated into a Kerberos name. The encoding of
the X.509 name as a Kerberos principal shall conform to the encoding
rules specified in RFC 2253.
A name type of SMTP allows a name to be of a form that resembles a SMTP
email name. This name, including an "@" and a domain name, is used as
the one component of the principal name.
A name type of UNKNOWN should be used when the form of the name is not
known. When comparing names, a name of type UNKNOWN will match
principals authenticated with names of any type. A principal
authenticated with a name of type UNKNOWN, however, will only match
other names of type UNKNOWN.
Names of any type with an initial component of 'krbtgt' are reserved for
the Kerberos ticket granting service. See section 8.2.3 8.2.4 for the form of
such names.
7.2.1. Name of server principals
The principal identifier for a server on a host will generally be
composed of two parts: (1) the realm of the KDC with which the server is
registered, and (2) a two-component name of type NT-SRV-HST if the host
name is an Internet domain name or a multi-component name of type
NT-SRV-XHST if the name of the host is of a form such as X.500 that
allows slash (/) separators. The first component of the two- or
multi-component name will identify the service and the latter components
will identify the host. Where the name of the host is not case sensitive
(for example, with Internet domain names) the name of the host must be
lower case. If specified by the application protocol for services such
as telnet and the Berkeley R commands which run with system privileges,
the first component may be the string 'host' instead of a service
specific identifier. When a host has an official name and one or more
aliases and the official name can be reliably determined, the official
name of the host should be used when constructing the name of the server
principal.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
8. Constants and other defined values
8.1. Host address types
All negative values for the host address type are reserved for local
use. All non-negative values are reserved for officially assigned type
fields and interpretations.
The values of the types for the following addresses are chosen to match
the defined address family constants in the Berkeley Standard
Distributions of Unix. They can be found in with symbolic names AF_xxx
(where xxx is an abbreviation of the address family name).
Internet (IPv4) Addresses
Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in
MSB order. The IPv4 loopback address should not appear in a Kerberos
packet. The type of IPv4 addresses is two (2).
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
Internet (IPv6) Addresses [Westerlund]
IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB order.
The type of IPv6 addresses is twenty-four (24). [RFC2373]. The following
addresses (see [RFC1884]) MUST not appear in any Kerberos packet:
* the Unspecified Address
* the Loopback Address
* Link-Local addresses
IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2.
DECnet Phase IV addresses
DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order.
The type of DECnet Phase IV addresses is twelve (12).
Netbios addresses
Netbios addresses are 16-octet addresses typically composed of 1 to 15
characters, trailing blank (ascii char 20) filled, with a 16th octet of
0x0. The type of Netbios addresses is 20 (0x14).
8.2. KDC
Directional Addresses
In many environments, including the sender address in KRB_SAFE and
KRB_PRIV messages
8.2.1. UDP/IP is undesirable because the addresses may be changed in
transport
When contacting a Kerberos server (KDC) for a KRB_KDC_REQ request using UDP
IP transport, by network address translators. However, if these addresses
are removed, the client shall send messages may be subject to a UDP datagram containing only an
encoding of the request reflection attack in which
a message is reflected back to the KDC at the port its originator. The directional address
type provides a way to avoid transport addresses and IP reflection attacks.
Directional addresses are encoded as four byte unsigned integers in
network byte order. If the message is originated by the party sending
the original KRB_AP_REQ message, then an address identified
using kdc discovery [separate document]. of 0 should be used. If
the message is originated by the party to whom that KRB_AP_REQ was sent,
then the address 1 should be used. Applications involving multiple
parties can specify the use of other addresses.
Directional addresses MUST only be used for the sender address field in
the KRB_SAFE or KRB_PRIV messages. They MUST NOT be used as a ticket
address or in a KRB_AP_REQ message. This port will usually address type SHOULD only be
used in situations where the sending party knows that the receiving
party supports the address type. This generally means that directional
addresses may only be used when the application protocol requires their
support. Directional addresses are type XX (0xXX).
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
8.2. KDC messaging
8.2.1 IP Transports
Kerberos defines two IP transport mechanisms for communication between
clients and servers: UDP/IP and TCP/IP.
8.2.1.1. UDP/IP transport
Kerberos servers (KDCs) supporting IP transports MUST accept UDP
requests and SHOULD listen for such requests on port 88
(decimal). (decimal) unless
specifically configured to listen on an alternative UDP port. Alternate
ports MAY be used when running multiple KDCs for multiple realms on the
same host.
Kerberos clients supporting IP transports SHOULD (XXX or is this a
MUST?) the sending of UDP requests. Clients SHOULD use KDC discovery
[8.2.1.3] to identify the IP address and port to which they will send
their request.
When contacting a KDC for a KRB_KDC_REQ request using UDP/IP transport,
the client shall send a UDP datagram containing only an encoding of the
request to the KDC. The KDC will respond with a reply datagram
containing only an encoding of the reply message (either a KRB_ERROR or a
8a KRB_KDC_REP) to the sending port at the sender's IP address. Kerberos servers supporting IP
transport must accept UDP requests and should listen on port 88 (decimal)
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
unless specifically configured to listed on an alternative UDP port. The
response to a request made through UDP/IP transport must also use UDP/IP
transport. If the response can not be handled using UDP (for example
because it is too large), the KDC must return an error forcing the
client to retry the request using the TCP transport.
8.2.2.
8.2.1.2. TCP/IP transport [Westerlund,Danielsson]
Kerberos servers (KDC's) must (KDCs) supporting IP transports MUST accept TCP
requests and should SHOULD listen for such requests on port 88 (decimal) unless
specifically configured to listen on a
different an alternate TCP port. Alternate
ports MAY be used when running multiple KDCs for multiple realms on the
same host.
Clients must support the sending of TCP requests, but may choose to
intially try a request using the UDP transport. Clients should SHOULD use
kdc KDC
discovery [separate document] [8.2.1.3] to identify the IP address and port to which they
will send a their request.
Implementation note: Most existing implementations will send requests Some extensions to
port 88 (decimal), so it the Kerberos protocol will not
succeed if any client or KDC not supporting the TCP transport is strongly recommended that realms
involved. Implementations of RFC 1510 were not be
configured required to use other than the standard port (88 decimal) for the support
TCP/IP transports.
[XXX as discussed we believe that the
Kerberos server. consensus was to allow multiple
requests over a single TCP connection between a client and KDC.]
When the KRB_KDC_REQ message is sent to the KDC over a TCP stream, a new
connection will be established for each authentication exchange (request and
response). The KRB_KDC_REP the
response (KRB_KDC_REP or KRB_ERROR message will message) MUST be returned to the
client on the same TCP stream that was established for the request. The
response to a request made through TCP/IP transport must also use TCP/IP
transport. Implementors should note that some extensions to the Kerberos
protocol will not work if any implementation not supporting the TCP
transport is involved (client or KDC). New implementations are required to
support the TCP transport on both server and the client. The
KDC may close the TCP stream after sending a response, but may leave the
stream open for a reasonable period of time if it expects a followup - followup.
Care must be taken in which case it may close the stream at any time if
resource constraints or other factors make it desirable to do so. Care must
be taken in managing TCP/IP connections with managing TCP/IP connections on the KDC to prevent
denial of service attacks based on the number of open TCP/IP connections with connections.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
The client must be prepared to have the stream closed by the KDC that
remain open. If at
anytime after the receipt of a response. A stream closure should not be
treated as a fatal error. Instead, if multiple exchanges with the KDC are needed for required
(e.g., certain forms of preauthentication, multiple TCP connections may be required. preauthentication) the client should establish a
new connection when it is ready to send subsequent messages. A client
may close the stream after receiving a response, and should close the
stream if it does not expect to send followup messages.
The client must be prepared to
have the stream closed by the KDC at anytime, in which case it must simply
connect again when it is ready to send subsequent messages.
The first four octets of the TCP stream used to transmit the request
request will encode in network byte order the length of the request
(KRB_KDC_REQ), and the length will be followed by the request itself.
The response will similarly be preceded by a 4 octet encoding in network
byte order of the length of the KRB_KDC_REP or the KRB_ERROR message and
will be followed by the KRB_KDC_REP or the KRB_ERROR response. If the
sign bit is set on the integer represented by the first 4 octets, then
the next 4 octets will be read, extending the length of the field by
another 4 octets (less the sign bit of the additional four octets which
is reserved for future expansion and which at present must be zero).
draft-ietf-krb-wg-kerberos-clarifications-00
8.2.1.3 KDC Discovery on IP Networks
Kerberos client implementations must provide a means for the client to
determine the location of the Kerberos Key Distribution Centers (KDCs).
Traditionally, Kerberos implementations have stored such configuration
information in a file on each client machine. Experience has shown this
method of storing configuration information presents problems with
out-of-date information and scaling problems, especially when using
cross-realm authentication. This section describes a method for using
the Domain Name System [RFC 1035] for storing KDC location information.
8.2.1.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names
In Kerberos, realm names are case sensitive. While it is strongly
encouraged that all realm names be all upper case this recommendation
has not been adopted by all sites. Some sites use all lower case names
and other use mixed case. DNS on the other hand is case insensitive for
queries. Since "MYREALM", "myrealm", and "MyRealm" are all different it
is necessary that only one of the possible combinations of upper and
lower case characters be used. This restriction may be lifted in the
future as the DNS naming scheme is expanded to support non-ASCII names.
8.2.1.3.2. Specifying KDC Location information with DNS SRV
records
KDC location information is to be stored using the DNS SRV RR [RFC
2052]. The format of this RR is as follows:
Service.Proto.Realm TTL Class SRV Priority Weight Port Target
The Service name for Kerberos is always "_kerberos".
The Proto can be one of "_udp", "_tcp". If these SRV records are to be
used, both "_udp" and "_tcp" records MUST be specified for all KDC
deployments.
The Realm is the Kerberos realm that this record corresponds to.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 22 August 2002
8.2.3. 9 March 2003
TTL, Class, SRV, Priority, Weight, and Target have the standard meaning
as defined in RFC 2052.
As per RFC 2052 the Port number used for "_udp" and "_tcp" SRV records
SHOULD be the value assigned to "kerberos" by the Internet Assigned
Number Authority: 88 (decimal) unless the KDC is configured to listen on
an alternate TCP port.
Implementation note: Many existing client implementations do not support
KDC Discovery and are configured to send requests to the IANA assigned
port (88 decimal), so it is strongly recommended that KDCs be configured
to listen on that port.
8.2.1.3.3. Example DNS SRV records specifying KDC location
information
These are DNS records for a Kerberos realm ASDF.COM. It has two Ker
beros servers, kdc1.asdf.com and kdc2.asdf.com. Queries should be
directed to kdc1.asdf.com first as per the specified priority. Weights
are not used in these records.
_kerberos._udp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com.
_kerberos._udp.ASDF.COM. IN SRV 1 0 88 kdc2.asdf.com.
_kerberos._tcp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com.
_kerberos._tcp.ASDF.COM. IN SRV 1 0 88 kdc2.asdf.com.
8.2.2. OSI transport
During authentication of an OSI client to an OSI server, the mutual
authentication of an OSI server to an OSI client, the transfer of
credentials from an OSI client to an OSI server, or during exchange of
private or integrity checked messages, Kerberos protocol messages may be
treated as opaque objects and the type of the authentication mechanism
will be:
OBJECT IDENTIFIER ::= {iso (1), org(3), dod(6),internet(1), security(5),kerberosv5(2)}
Depending on the situation, the opaque object will be an authentication
header (KRB_AP_REQ), an authentication reply (KRB_AP_REP), a safe
message (KRB_SAFE), a private message (KRB_PRIV), or a credentials
message (KRB_CRED). The opaque data contains an application code as
specified in the ASN.1 description for each message. The application
code may be used by Kerberos to determine the message type.
8.2.4.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
8.3. Name of the TGS
The principal identifier of the ticket-granting service shall be
composed of three parts: (1) the realm of the KDC issuing the TGS ticket
(2) a two-part name of type NT-SRV-INST, with the first part "krbtgt"
and the second part the name of the realm which will accept the
ticket-granting ticket. For example, a ticket-granting ticket issued by
the ATHENA.MIT.EDU realm to be used to get tickets from the
ATHENA.MIT.EDU KDC has a principal identifier of "ATHENA.MIT.EDU"
(realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A ticket-granting ticket
issued by the ATHENA.MIT.EDU realm to be used to get tickets from the
MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU" (realm),
("krbtgt", "MIT.EDU") (name).
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
8.3.
8.4. Protocol constants and associated values
The following tables list constants used in the protocol and define
their meanings. Ranges are specified in the "specification" section that
limit the values of constants for which values are defined here. This
allows implementations to make assumptions about the maximum values that
will be received for these constants. Implementation receiving values
outside the range specified in the "specification" section may reject
the request, but they must recover cleanly.
padata and data types padata-type value comment
PA-TGS-REQ 1
PA-ENC-TIMESTAMP 2
PA-PW-SALT 3
[reserved] 4
PA-ENC-UNIX-TIME 5 (depricated)
PA-SANDIA-SECUREID 6
PA-SESAME 7
PA-OSF-DCE 8
PA-CYBERSAFE-SECUREID 9
PA-AFS3-SALT 10
PA-ETYPE-INFO 11
PA-SAM-CHALLENGE 12 (sam/otp)
PA-SAM-RESPONSE 13 (sam/otp)
PA-PK-AS-REQ 14 (pkinit)
PA-PK-AS-REP 15 (pkinit)
PA-USE-SPECIFIED-KVNO 20
PA-SAM-REDIRECT 21 (sam/otp)
PA-GET-FROM-TYPED-DATA 22 (embedded in typed data)
TD-PADATA 22 (embeds padata)
PA-SAM-ETYPE-INFO 23 (sam/otp)
PA-ALT-PRINC 24 (crawdad@fnal.gov)
PA-SAM-CHALLENGE2 30 (kenh@pobox.com)
PA-SAM-RESPONSE2 31 (kenh@pobox.com)
TD-PKINIT-CMS-CERTIFICATES 101 CertificateSet from CMS
TD-KRB-PRINCIPAL 102 PrincipalName (see Sec.5.9.1)
TD-KRB-REALM 103 Realm (see Sec.5.9.1)
TD-TRUSTED-CERTIFIERS 104 from PKINIT
TD-CERTIFICATE-INDEX 105 from PKINIT
TD-APP-DEFINED-ERROR 106 application specific (see Sec.5.9.1)
TD-REQ-NONCE 107 INTEGER (see Sec.5.9.1)
TD-REQ-SEQ 108 INTEGER (see Sec.5.9.1)
PA-PAC-REQUEST 128 (jbrezak@exchange.microsoft.com)
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
Address type value
IPV4 2
ChaosNet 5
XNS 6
ISO 7
DECNET Phase IV 12
AppleTalk DDP 16
NetBios 20
IPV6 24
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
authorization data type ad-type value
AD-IF-RELEVANT 1
AD-INTENDED-FOR-SERVER 2
AD-INTENDED-FOR-APPLICATION-CLASS 3
AD-KDC-ISSUED 4
AD-OR 5
AD-MANDATORY-TICKET-EXTENSIONS 6
AD-IN-TICKET-EXTENSIONS 7
AD-MANDATORY-FOR-KDC 8
reserved values 8-63 9-63
OSF-DCE 64
SESAME 65
AD-OSF-DCE-PKI-CERTID 66 (hemsath@us.ibm.com)
AD-WIN2K-PAC 128 (jbrezak@exchange.microsoft.com)
Ticket Extension Types
TE-TYPE-NULL 0 Null ticket extension
TE-TYPE-EXTERNAL-ADATA 1 Integrity protected authorization data
[reserved] 2 TE-TYPE-PKCROSS-KDC (I have reservations)
TE-TYPE-PKCROSS-CLIENT 3 PKCROSS cross realm key ticket
TE-TYPE-CYBERSAFE-EXT 4 Assigned to CyberSafe Corp
[reserved] 5 TE-TYPE-DEST-HOST (I have reservations)
transited encoding type tr-type value
DOMAIN-X500-COMPRESS 1
reserved values all others
Label Value Meaning or MIT code
pvno 5 current Kerberos protocol version number
message types (Will be updated to match section 5)
KRB_AS_REQ 10 Request for initial authentication
KRB_AS_REP 11 Response to KRB_AS_REQ request
KRB_TGS_REQ 12 Request for authentication based on TGT
KRB_TGS_REP 13 Response to KRB_TGS_REQ request
KRB_AP_REQ 14 application request to server
KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL
KRB_SAFE 20 Safe (checksummed) application message
KRB_PRIV 21 Private (encrypted) application message
KRB_CRED 22 Private (encrypted) message to forward credentials
KRB_ERROR 30 Error response
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
name types
KRB_NT_UNKNOWN 0 Name type not known
KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or for users
KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt)
KRB_NT_SRV_HST 3 Service with host name as instance (telnet, rcommands)
KRB_NT_SRV_XHST 4 Service with host as remaining components
KRB_NT_UID 5 Unique ID
KRB_NT_X500_PRINCIPAL 6 Encoded X.509 Distingished name [RFC 2253]
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
error codes
KDC_ERR_NONE 0 No error
KDC_ERR_NAME_EXP 1 Client's entry in database has expired
KDC_ERR_SERVICE_EXP 2 Server's entry in database has expired
KDC_ERR_BAD_PVNO 3 Requested protocol version number not supported
KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old master key
KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old master key
KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos database
KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos database
KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in database
KDC_ERR_NULL_KEY 9 The client or server has a null key
KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating
KDC_ERR_NEVER_VALID 11 Requested start time is later than end time
KDC_ERR_POLICY 12 KDC policy rejects request
KDC_ERR_BADOPTION 13 KDC cannot accommodate requested option
KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption type
KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type
KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type
KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type
KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been revoked
KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been revoked
KDC_ERR_TGT_REVOKED 20 TGT has been revoked
KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again later
KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again later
KDC_ERR_KEY_EXPIRED 23 Password has expired - change password to reset
KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information was invalid
KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authenticationrequired [40]
KDC_ERR_SERVER_NOMATCH 26 Requested server and ticket don't match
KDC_ERR_MUST_USE_USER2USER 27 Server principal valid for user2user only
KDC_ERR_PATH_NOT_ACCPETED 28 KDC Policy rejects transited path
KDC_ERR_SVC_UNAVAILABLE 29 A service is not available
KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field failed
KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired
KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid
KRB_AP_ERR_REPEAT 34 Request is a replay
KRB_AP_ERR_NOT_US 35 The ticket isn't for us
KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match
KRB_AP_ERR_SKEW 37 Clock skew too great
KRB_AP_ERR_BADADDR 38 Incorrect net address
KRB_AP_ERR_BADVERSION 39 Protocol version mismatch
KRB_AP_ERR_MSG_TYPE 40 Invalid msg type
KRB_AP_ERR_MODIFIED 41 Message stream modified
KRB_AP_ERR_BADORDER 42 Message out of order
KRB_AP_ERR_BADKEYVER 44 Specified version of key is not available
KRB_AP_ERR_NOKEY 45 Service key not available
KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed
KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction
KRB_AP_ERR_METHOD 48 Alternative authentication method required
KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in message
KRB_AP_PATH_NOT_ACCEPTED 51 Policy rejects transited path
KRB_ERR_RESPONSE_TOO_BIG 52 Response too big for UDP, retry with TCP
KRB_ERR_GENERIC 60 Generic error (description in e-text)
KRB_ERR_FIELD_TOOLONG 61 Field is too long for this implementation
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
KDC_ERROR_CLIENT_NOT_TRUSTED 62 (pkinit)
KDC_ERROR_KDC_NOT_TRUSTED 63 (pkinit)
KDC_ERROR_INVALID_SIG 64 (pkinit)
KDC_ERR_KEY_TOO_WEAK 65 (pkinit)
KDC_ERR_CERTIFICATE_MISMATCH 66 (pkinit)
KRB_AP_ERR_NO_TGT 67 (user-to-user)
KDC_ERR_WRONG_REALM 68 (user-to-user)
KRB_AP_ERR_USER_TO_USER_REQUIRED 69 (user-to-user)
KDC_ERR_CANT_VERIFY_CERTIFICATE 70 (pkinit)
KDC_ERR_INVALID_CERTIFICATE 71 (pkinit)
KDC_ERR_REVOKED_CERTIFICATE 72 (pkinit)
KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 (pkinit)
KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 (pkinit)
KDC_ERR_CLIENT_NAME_MISMATCH 75 (pkinit)
KDC_ERR_KDC_NAME_MISMATCH 76 (pkinit)
draft-ietf-krb-wg-kerberos-clarifications-00
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 22 August 2002 9 March 2003
9. Interoperability requirements
Version 5 of the Kerberos protocol supports a myriad of options. Among
these are multiple encryption and checksum types, alternative encoding
schemes for the transited field, optional mechanisms for
pre-authentication, the handling of tickets with no addresses, options
for mutual authentication, user to user authentication, support for
proxies, forwarding, postdating, and renewing tickets, the format of
realm names, and the handling of authorization data.
In order to ensure the interoperability of realms, it is necessary to
define a minimal configuration which must be supported by all
implementations. This minimal configuration is subject to change as
technology does. For example, if at some later date it is discovered
that one of the required encryption or checksum algorithms is not
secure, it will be replaced.
9.1. Specification 2
This section defines the second specification of these options.
Implementations which are configured in this way can be said to support
Kerberos Version 5 Specification 2 (5.1). Specification 1 (deprecated)
may be found in RFC1510.
Transport
TCP/IP and UDP/IP transport must be supported by clients and KDCs
claiming conformance to specification 2.
Encryption and checksum methods
The following encryption and checksum mechanisms must be supported.
Implementations may support other mechanisms as well, but the additional
mechanisms may only be used when communicating with principals known to
also support them: This list is to be determined and should correspond
to section 6.
Encryption: DES-CBC-MD5, DES3-CBC-SHA1-KD, RIJNDAEL(decide identifier)
Checksums: CRC-32, DES-MAC, DES-MAC-K, DES-MD5, HMAC-SHA1-DES3-KD
Realm Names
All implementations must understand hierarchical realms in both the
Internet Domain and the X.500 style. When a ticket granting ticket for
an unknown realm is requested, the KDC must be able to determine the
names of the intermediate realms between the KDCs realm and the
requested realm.
Transited field encoding
DOMAIN-X500-COMPRESS (described in section 3.3.3.2) must be supported.
Alternative encodings may be supported, but they may be used only when
that encoding is supported by ALL intermediate realms.
draft-ietf-krb-wg-kerberos-clarifications-00
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 22 August 2002 9 March 2003
Pre-authentication methods
The TGS-REQ method must be supported. The TGS-REQ method is not used on
the initial request. The PA-ENC-TIMESTAMP method must be supported by
clients but whether it is enabled by default may be determined on a
realm by realm basis. If not used in the initial request and the error
KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC-TIMESTAMP as an
acceptable method, the client should retry the initial request using the
PA-ENC-TIMESTAMP preauthentication method. Servers need not support the
PA-ENC-TIMESTAMP method, but if not supported the server should ignore
the presence of PA-ENC-TIMESTAMP pre-authentication in a request.
Mutual authentication
Mutual authentication (via the KRB_AP_REP message) must be supported.
Ticket addresses and flags
All KDC's must pass through tickets that carry no addresses (i.e. if a
TGT contains no addresses, the KDC will return derivative tickets), but
each realm may set its own policy for issuing such tickets, and each
application server will set its own policy with respect to accepting them.
Proxies and forwarded tickets must be supported. Individual realms and
application servers can set their own policy on when such tickets will
be accepted.
All implementations must recognize renewable and postdated tickets, but
need not actually implement them. If these options are not supported,
the starttime and endtime in the ticket shall specify a ticket's entire
useful life. When a postdated ticket is decoded by a server, all
implementations shall make the presence of the postdated flag visible to
the calling server.
User-to-user authentication
Support for user to user authentication (via the ENC-TKT-IN-SKEY KDC
option) must be provided by implementations, but individual realms may
decide as a matter of policy to reject such requests on a per-principal
or realm-wide basis.
Authorization data
Implementations must pass all authorization data subfields from
ticket-granting tickets to any derivative tickets unless directed to
suppress a subfield as part of the definition of that registered
subfield type (it is never incorrect to pass on a subfield, and no
registered subfield types presently specify suppression at the KDC).
Implementations must make the contents of any authorization data
subfields available to the server when a ticket is used. Implementations
are not required to allow clients to specify the contents of the
authorization data fields.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
Constant ranges
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
All protocol constants are constrained to 32 bit (signed) values unless
further constrained by the protocol definition. This limit is provided
to allow implementations to make assumptions about the maximum values
that will be received for these constants. Implementation receiving
values outside this range may reject the request, but they must recover
cleanly.
9.2. Recommended KDC values
Following is a list of recommended values for a KDC implementation,
based on the list of suggested configuration constants (see section 4.4).
minimum lifetime 5 minutes
maximum renewable lifetime 1 week
maximum ticket lifetime 1 day
empty addresses only when suitable restrictions appear
in authorization data
proxiable, etc. Allowed.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
10. IANA considerations
Maybe set up an appendix
Appendix with all the tables that IANA will need to start maintaining?
* cryptosystem registration
* usage number registration
11. ACKNOWLEDGEMENTS
T.B.S.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
12. REFERENCES
[Blumenthal96]
Blumenthal, U., "A Better Key Schedule for DES-Like Ciphers",
Proceedings of PRAGOCRYPT '96, 1996. [Bellare98]
Bellare, M., Desai, A., Pointcheval, D., Rogaway, P., "Relations
Among Notions of Security for Public-Key Encryption Schemes".
Extended abstract published in Advances in Cryptology- Crypto 98
Proceedings, Lecture Notes in Computer Science Vol. 1462, H.
Krawcyzk ed., Springer-Verlag, 1998. [DES77]
National Bureau of Standards, U.S. Department of Commerce, "Data
Encryption Standard," Federal Information Processing Standards
Publication 46, Washington, DC (1977). [DESM80]
National Bureau of Standards, U.S. Department of Com- merce, "DES
Modes of Operation," Federal Information Processing Standards
Publication 81, Springfield, VA (December 1980). [Dolev91]
Dolev, D., Dwork, C., Naor, M., "Non-malleable cryptography",
Proceedings of the 23rd Annual Symposium on Theory of Computing,
ACM, 1991. [DS81]
Dorothy E. Denning and Giovanni Maria Sacco, "Time- stamps in Key
Distribution Protocols," Communications of the ACM, Vol. 24(8), pp.
533-536 (August 1981). [DS90]
Don Davis and Ralph Swick, "Workstation Services and Kerberos
Authentication at Project Athena," Technical Memorandum TM-424, MIT
Laboratory for Computer Science (February 1990). [Horowitz96]
Horowitz, M., "Key Derivation for Authentication, Integrity, and
Privacy", draft-horowitz-key-derivation-02.txt, August 1998. [HorowitzB96]
Horowitz, M., "Key Derivation for Kerberos V5", draft-
horowitz-kerb-key-derivation-01.txt, September 1998. [IS3309]
International Organization for Standardization, "ISO Information
Processing Systems - Data Communication - High-Level Data Link
Control Procedure - Frame Struc- ture," IS 3309 (October 1984). 3rd
Edition. [KBC96]
H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed- Hashing for
Message Authentication," Working Draft
draft-ietf-ipsec-hmac-md5-01.txt, (August 1996). [KNT92]
John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The
Evolution of the Kerberos Authentication Service," in an IEEE
Computer Society Text soon to be published (June 1992). [Krawczyk96]
Krawczyk, H., Bellare, and M., Canetti, R., "HMAC: Keyed-Hashing for
Message Authentication", draft-ietf-ipsec-hmac- md5-01.txt, August,
1996.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002 [LGDSR87]
P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E. Som- merfeld, and
K. Raeburn, Section E.1: Service Manage- ment System, M.I.T. Project
Athena, Cambridge, Mas- sachusetts (1987). [MD4-92]
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
R. Rivest, "The MD4 Message Digest Algorithm," RFC 1320, MIT
Laboratory for Computer Science (April 1992). [MD5-92]
R. Rivest, "The MD5 Message Digest Algorithm," RFC 1321, MIT
Laboratory for Computer Science (April 1992). [MNSS87]
S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. Saltzer,
Section E.2.1: Kerberos Authentication and Authorization System,
M.I.T. Project Athena, Cambridge, Massachusetts (December 21, 1987).
[Neu93]
B. Clifford Neuman, "Proxy-Based Authorization and Accounting for
Distributed Systems," in Proceedings of the 13th International
Conference on Distributed Com- puting Systems, Pittsburgh, PA (May,
1993). [NS78]
Roger M. Needham and Michael D. Schroeder, "Using Encryption for
Authentication in Large Networks of Com- puters," Communications of
the ACM, Vol. 21(12), pp. 993-999 (December, 1978). [NT94]
B. Clifford Neuman and Theodore Y. Ts'o, "An Authenti- cation
Service for Computer Networks," IEEE Communica- tions Magazine, Vol.
32(9), pp. 33-38 (September 1994). [Pat92].
J. Pato, Using Pre-Authentication to Avoid Password Guessing
Attacks, Open Software Foundation DCE Request for Comments 26
(December 1992). [SG92]
Stuart G. Stubblebine and Virgil D. Gligor, "On Message Integrity in
Cryptographic Protocols," in Proceedings of the IEEE Symposium on
Research in Security and Privacy, Oakland, California (May 1992). [SNS88]
J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Ker- beros: An
Authentication Service for Open Network Sys- tems," pp. 191-202 in
Usenix Conference Proceedings, Dallas, Texas (February, 1988). [X509-88]
CCITT, Recommendation X.509: The Directory Authentica- tion
Framework, December 1988.
draft-ietf-krb-wg-kerberos-clarifications-00
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 22 August 2002
[TM] Project Athena, Athena, and Kerberos are trademarks of the
Massachusetts Institute of Technology (MIT). No commercial use of these
trademarks may be made without prior written permission of MIT.
[1.1] Note, however, that many applications use Kerberos' functions only
upon the initiation of a stream-based network connection. Unless an
application subsequently provides integrity protection for the data stream,
the identity verification applies only to the initiation of the connection,
and does not guarantee that subsequent messages on the connection originate
from the same principal.
[1.2] Secret and private are often used interchangeably in the literature.
In our usage, it takes two (or more) to 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.
[1.3] Of course, with appropriate permission the client could arrange
registration of a separately-named principal in a remote realm, and engage 9 March 2003
A. ASN.1 module
Kerberos5 {
iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
} DEFINITIONS ::= BEGIN
Int32 ::= INTEGER (-2147483648..2147483647)
-- signed values representable in normal exchanges with that realm's services. However, for even small
numbers of clients this becomes cumbersome, and more automatic methods as
described here are necessary.
[2.1] Though it is permissible to request or issue tickets 32 bits
UInt32 ::= INTEGER (0..4294967295)
-- unsigned 32 bit values
Microseconds ::= INTEGER (0..999999)
-- microseconds
KerberosString ::= GeneralString (IA5String)
Realm ::= KerberosString
PrincipalName ::= SEQUENCE {
name-type [0] Int32,
name-string [1] SEQUENCE OF KerberosString
}
KerberosTime ::= GeneralizedTime
-- with no network
addresses specified.
[2.2] It fractional seconds
HostAddress ::= SEQUENCE {
addr-type [0] Int32,
address [1] OCTET STRING
}
-- XXX HostAddresses is important that the KDC be sent the name as typed by the user,
and not only the canonical form of the name. If the domain name system was always used to find the canonical name on the client side, the mapping is
vulnerable. [3.1] The password-changing request must not be honored unless
the requester can provide the old password (the user's current secret key).
Otherwise, it would be possible for someone to walk up to as an unattended
session OPTIONAL field and change another user's password.
[3.2] To authenticate a user logging on to a local system, the credentials
obtained in the AS exchange may first be used in a TGS exchange to obtain
credentials for a local server. Those credentials must then be verified by a
local server through successful completion of the Client/Server exchange.
[3.3] "Random" means that, among other things, it should be impossible to
guess the next session key based on knowledge of past session keys. This can
only be achieved in a pseudo-random number generator if it is based on
cryptographic principles. It
-- zero-length.
HostAddresses ::= SEQUENCE OF HostAddress -- XXX subtly different from 1510
-- but encodes the same
-- XXX AuthorizationData is more desirable to use a truly random number
generator, such always used as one based on measurements of random physical phenomena.
[3.4] Tickets contain both an encrypted OPTIONAL field and unencrypted portion, so
cleartext here refers to the entire unit, which can
-- be copied from one
message and replayed in another without any cryptographic skill.
[3.5] Note that this can make applications based on unreliable transports
difficult to code correctly. If the transport might deliver duplicated
messages, either a new authenticator must be generated for each retry, or
the application server must match requests and replies and replay the zero-length.
AuthorizationData ::= SEQUENCE OF SEQUENCE {
ad-type [0] Int32,
ad-data [1] OCTET STRING
}
PA-DATA ::= SEQUENCE {
padata-type [1] Int32 -- first
reply in response to a detected duplicate.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
[3.6] This allows easy implementation of user-to-user authentication [8],
which uses ticket-granting ticket session keys in lieu of secret server keys
in situations where such secret keys could be easily compromised.
[3.7]Note also that the rejection here tag is restricted to authenticators from
the same principal to the same server. Other client principals communicating
with the same server principal should [1], not [0] --,
padata-value [2] OCTET STRING -- might be have their authenticators
rejected if the time and microsecond fields happen to match some other
client's authenticator.
[3.8] If this is not done, an attacker could subvert the authentication by
recording the ticket and authenticator sent over the network to a server and
replaying them following an event that caused the server to lose track encoded AP-REQ
}
KerberosFlags ::= BIT STRING (SIZE (32..MAX)) -- minimum number of
recently seen authenticators.
[3.9] In the Kerberos version 4 protocol, the timestamp in the reply was the
client's timestamp plus one. This is not necessary in version 5 because
version 5 messages are formatted in such a way that it is not possible to
create the reply by judicious message surgery (even in bits
-- shall be sent, but no fewer than 32
EncryptedData1510 ::= SEQUENCE {
etype [0] Int32 -- EncryptionType --,
kvno [1] UInt32 OPTIONAL,
cipher [2] OCTET STRING -- ciphertext
}
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
EncryptedData {Type, UInt32:KeyUsages} ::= SEQUENCE {
etype [0] Int32 -- EncryptionType --,
kvno [1] UInt32 OPTIONAL,
cipher [2] OCTET STRING (CONSTRAINED BY {
-- must be encrypted form)
without knowledge DER encoding of the appropriate encryption keys.
[3.10] Note that for encrypting the KRB_AP_REP message, the sub-session -- Type,
-- with key
is not used, even if present in the Authenticator.
[3.11] Implementations usage being one of the protocol may wish to provide routines to
choose subkeys based on session keys and random numbers and to generate a
negotiated -- UInt32:KeyUsages
})
}
EncryptionKey ::= SEQUENCE {
keytype [0] Int32 -- actually encryption type --,
keyvalue [1] OCTET STRING
}
Checksum {UInt32:KeyUsages} ::= SEQUENCE {
cksumtype [0] Int32,
checksum [1] OCTET STRING (CONSTRAINED BY {
-- with key to be returned in the KRB_AP_REP message.
[3.12]This can be accomplished in several ways. It might be known beforehand
(since the realm is part of the principal identifier), it might be stored in
a nameserver, or it might be obtained from a configuration file. If the
realm to be used is obtained from a nameserver, there is a danger of usage being
spoofed if the nameservice providing the realm name is not authenticated.
This might result in the use one of a realm which has been compromised, and
would result in an attacker's ability to compromise the authentication of
the application server to the client.
[3.13] If the client selects a sub-session key, care must be taken to ensure
the randomness of the selected sub-session key. One approach would be to
generate a random number and XOR it with the session key from the
ticket-granting ticket.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
[6.1] For example, a pseudo-random number generator may be seeded with a
session key, but to protect the original key from any accidental weakness in
the PRNG, use possibly-known data encrypted or checksummed using the key
rather than using the -- UInt32:KeyUsages
})
}
-- key directly. Usage usage numbers in this reserved range
should help avoid accidentally seeding the PRNG with a value also computed
and perhaps exposed to an attacker elsewhere.
[6.2] Of course, this does not
apply to protocols that do their own encryption independent of this
framework, directly using the key resulting from the Kerberos authentication
exchange.
[6.3] Perhaps one of the more common reasons for directly
performing encryption is direct control over the negotiation and to select a
"sufficiently strong" encryption algorithm (whatever that means in the
context of a given application). While Kerberos directly provides no
facility for negotiating encryption types between the application client and
server, there are other means for accomplishing similar goals. For example,
requesting only "strong" session key types from the KDC, and assuming that
the type actually returned by the KDC will be understood and supported by
the application server.
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
A. ASN.1 module
Note: This module is currently not aligned with Section 5. This will be
addressed in a future revision. The Pseudocode appendix has been dropped.
This appendix is replacing the pseudocode as appendix A.
Kerberos5 {
iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
} DEFINITIONS
keyuse-pa-enc-ts Int32 ::= BEGIN 1
keyuse-Ticket Int32 ::= INTEGER (-2147483648..2147483647)
-- signed values representable in 32 bits
UInt32 2
keyuse-EncASRepPart Int32 ::= INTEGER (0..4294967295)
-- unsigned 32 bit values
Microseconds 3
keyuse-TGSReqAuthData-sesskey Int32 ::= INTEGER (0..999999)
-- microseconds
KerberosString 4
keyuse-TGSReqAuthData-subkey Int32 ::= GeneralString (IA5String)
Realm 5
keyuse-pa-TGSReq-cksum Int32 ::= KerberosString
PrincipalName 6
keyuse-pa-TGSReq-authenticator Int32 ::= 7
keyuse-EncTGSRepPart-sesskey Int32 ::= 8
keyuse-EncTGSRepPart-subkey Int32 ::= 9
keyuse-APReq-cksum Int32 ::= 10
keyuse-APReq-authenticator Int32 ::= 11
keyuse-EncAPRepPart Int32 ::= 12
keyuse-EncKrbPrivPart Int32 ::= 13
keyuse-EncKrbCredPart Int32 ::= 14
keyuse-KrbSafe-cksum Int32 ::= 15
Ticket ::= [APPLICATION 1] SEQUENCE {
name-type
tkt-vno [0] Int32,
name-string INTEGER (5),
realm [1] SEQUENCE OF KerberosString Realm,
sname [2] PrincipalName,
enc-part [3] EncryptedData {EncTicketPart, {keyuse-Ticket}}
}
KerberosTime ::= GeneralizedTime
-- with no fractional seconds
HostAddress Encrypted part of ticket
EncTicketPart ::= [APPLICATION 3] SEQUENCE {
addr-type
flags [0] Int32,
address TicketFlags,
key [1] OCTET STRING
}
-- XXX HostAddresses is always used as an OPTIONAL field and can be
-- zero-length. 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 -- XXX subtly different from rfc1510,
-- but has a value mapping and encodes the same
::= SEQUENCE OF HostAddress
-- XXX OPTIONAL,
authorization-data [10] AuthorizationData is always used as an OPTIONAL field and can
}
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
-- be zero-length.
AuthorizationData encoded Transited field
TransitedEncoding ::= SEQUENCE OF SEQUENCE {
ad-type
tr-type [0] Int32,
ad-data Int32 -- must be registered --,
contents [1] OCTET STRING
}
PA-DATA
TicketFlags ::= SEQUENCE {
padata-type [1] Int32 -- first tag is [1], not [0] --,
padata-value [2] OCTET STRING -- might be encoded AP-REQ
}
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
KerberosFlags ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits
-- shall be sent, but no fewer than 32
EncryptedData ::= SEQUENCE {
etype [0] Int32 -- EncryptionType --,
kvno [1] UInt32 OPTIONAL,
cipher [2] OCTET STRING -- ciphertext
}
EncryptionKey ::= SEQUENCE {
keytype [0] Int32 -- actually encryption type --,
keyvalue [1] OCTET STRING
}
Checksum ::= SEQUENCE {
cksumtype [0] Int32,
checksum [1] OCTET STRING
}
Ticket ::= [APPLICATION 1] SEQUENCE {
tkt-vno [0] INTEGER (5),
realm [1] Realm,
sname [2] PrincipalName,
enc-part [3] EncryptedData -- EncTicketPart
}
-- Encrypted part of ticket
EncTicketPart ::= [APPLICATION 3] SEQUENCE {
flags [0] TicketFlags,
key [1] EncryptionKey,
crealm [2] Realm,
cname [3] PrincipalName,
transited [4] TransitedEncoding,
authtime [5] KerberosTime,
starttime [6] KerberosTime OPTIONAL,
endtime [7] KerberosTime,
renew-till [8] KerberosTime OPTIONAL,
caddr [9] HostAddresses OPTIONAL,
authorization-data [10] AuthorizationData OPTIONAL
}
-- encoded Transited field
TransitedEncoding ::= SEQUENCE {
tr-type [0] Int32 -- must be registered --,
contents [1] OCTET STRING
}
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
TicketFlags ::= KerberosFlags KerberosFlags
-- reserved(0),
-- forwardable(1),
-- forwarded(2),
-- proxiable(3),
-- proxy(4),
-- may-postdate(5),
-- postdated(6),
-- invalid(7),
-- renewable(8),
-- initial(9),
-- pre-authent(10),
-- hw-authent(11),
-- the following are new since 1510; maybe remove from krb-clarifications?
-- transited-policy-checked(12),
-- ok-as-delegate(13),
-- anonymous(14),
-- cksummed-ticket(15)
AS-REQ ::= [APPLICATION 10] KDC-REQ {10}
TGS-REQ ::= [APPLICATION 12] KDC-REQ {12}
KDC-REQ {INTEGER:tagnum} ::= [APPLICATION tagnum] SEQUENCE {
pvno [1] INTEGER (5) -- first tag is [1], not [0] --,
msg-type [2] INTEGER (10 -- AS -- | 12 -- TGS --), (tagnum),
padata [3] SEQUENCE OF PA-DATA OPTIONAL -- XXX may be zero-length --,
req-body [4] KDC-REQ-BODY
}
KDC-REQ-BODY ::= SEQUENCE {
kdc-options [0] KDCOptions,
cname [1] PrincipalName OPTIONAL
-- Used only in AS-REQ --,
realm [2] Realm
-- Server's realm
-- Also client's in AS-REQ --,
sname [3] PrincipalName OPTIONAL,
from [4] KerberosTime OPTIONAL,
till [5] KerberosTime,
rtime [6] KerberosTime OPTIONAL,
nonce [7] UInt32,
etype [8] SEQUENCE OF Int32 -- EncryptionType
-- in preference order --,
addresses [9] HostAddresses OPTIONAL,
enc-authorization-data [10] EncryptedData -- AuthorizationData --, {
AuthorizationData,
{ keyuse-TGSReqAuthData-sesskey
| keyuse-TGSReqAuthData-subkey }
} OPTIONAL,
additional-tickets [11] SEQUENCE OF Ticket OPTIONAL -- XXX may be zero-length
}
draft-ietf-krb-wg-kerberos-clarifications-00
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 22 August 2002 9 March 2003
KDCOptions ::= KerberosFlags
-- reserved(0),
-- forwardable(1),
-- forwarded(2),
-- proxiable(3),
-- proxy(4),
-- allow-postdate(5),
-- postdated(6),
-- unused7(7),
-- renewable(8),
-- unused9(9),
-- unused10(10),
-- unused11(11),
-- unused12(12),
-- unused13(13),
-- 14 through 26 were unused in 1510
-- requestanonymous(14),
-- canonicalize(15),
-- disable-transited-check(26),
--
-- renewable-ok(27),
-- enc-tkt-in-skey(28),
-- renew(30),
-- validate(31)
AS-REP ::= [APPLICATION 11] KDC-REP {11, EncASRepPart, {keyuse-EncASRepPart}}
TGS-REP ::= [APPLICATION 13] KDC-REP {13, EncTGSRepPart,
{ keyuse-EncTGSRepPart-sesskey
| keyuse-EncTGSRepPart-subkey }}
KDC-REP {INTEGER:tagnum,
TypeToEncrypt,
UInt32:KeyUsages} ::= [APPLICATION tagnum] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (11 -- AS -- | 13 -- TGS --), (tagnum),
padata [2] SEQUENCE OF PA-DATA OPTIONAL -- XXX may be zero length --,
crealm [3] Realm,
cname [4] PrincipalName,
ticket [5] Ticket,
enc-part [6] EncryptedData
-- EncASRepPart or EncTGSRepPart,
-- as appropriate {TypeToEncrypt, KeyUsages}
}
EncASRepPart ::= [APPLICATION 25] EncKDCRepPart
EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
EncKDCRepPart ::= SEQUENCE {
key [0] EncryptionKey,
last-req [1] LastReq,
nonce [2] UInt32,
key-expiration [3] KerberosTime OPTIONAL,
flags [4] TicketFlags,
authtime [5] KerberosTime,
starttime [6] KerberosTime OPTIONAL,
endtime [7] KerberosTime,
renew-till [8] KerberosTime OPTIONAL,
srealm [9] Realm,
sname [10] PrincipalName,
caddr [11] HostAddresses OPTIONAL
}
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
LastReq ::= SEQUENCE OF SEQUENCE {
lr-type [0] Int32,
lr-value [1] KerberosTime
}
AP-REQ ::= [APPLICATION 14] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (14),
ap-options [2] APOptions,
ticket [3] Ticket,
authenticator [4] EncryptedData -- Authenticator {Authenticator,
{ keyuse-pa-TGSReq-authenticator
| keyuse-APReq-authenticator }}
}
APOptions ::= KerberosFlags
-- reserved(0),
-- use-session-key(1),
-- mutual-required(2)
-- Unencrypted authenticator
Authenticator ::= [APPLICATION 2] SEQUENCE {
authenticator-vno [0] INTEGER (5),
crealm [1] Realm,
cname [2] PrincipalName,
cksum [3] Checksum {{
keyuse-pa-TGSReq-cksum
| keyuse-APReq-cksum
}} OPTIONAL,
cusec [4] Microseconds,
ctime [5] KerberosTime,
subkey [6] EncryptionKey OPTIONAL,
seq-number [7] UInt32 OPTIONAL,
authorization-data [8] AuthorizationData OPTIONAL
}
AP-REP ::= [APPLICATION 15] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (15),
enc-part [2] EncryptedData -- EncAPRepPart {EncAPRepPart,
{ keyuse-EncAPRepPart }}
}
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
ctime [0] KerberosTime,
cusec [1] Microseconds,
subkey [2] EncryptionKey OPTIONAL,
seq-number [3] UInt32 OPTIONAL
}
KRB-SAFE ::= [APPLICATION 20] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (20),
safe-body [2] KRB-SAFE-BODY,
cksum [3] Checksum {{keyuse-KrbSafe-cksum}}
}
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
KRB-SAFE-BODY ::= SEQUENCE {
user-data [0] OCTET STRING,
timestamp [1] KerberosTime OPTIONAL,
usec [2] Microseconds OPTIONAL,
seq-number [3] UInt32 OPTIONAL,
s-address [4] HostAddress,
r-address [5] HostAddress OPTIONAL
}
KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (21), (21) -- there is no [2] tag --,
enc-part [3] EncryptedData -- EncKrbPrivPart {EncKrbPrivPart,
{keyuse-EncKrbPrivPart}}
}
EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE {
user-data [0] OCTET STRING,
timestamp [1] KerberosTime OPTIONAL,
usec [2] Microseconds OPTIONAL,
seq-number [3] UInt32 OPTIONAL,
s-address [4] HostAddress -- sender's addr --,
r-address [5] HostAddress OPTIONAL -- recip's addr
}
KRB-CRED ::= [APPLICATION 22] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (22),
tickets [2] SEQUENCE OF Ticket,
enc-part [3] EncryptedData -- EncKrbCredPart {EncKrbCredPart,
{keyuse-EncKrbCredPart}}
}
EncKrbCredPart ::= [APPLICATION 29] SEQUENCE {
ticket-info [0] SEQUENCE OF KrbCredInfo,
nonce [1] UInt32 OPTIONAL,
timestamp [2] KerberosTime OPTIONAL,
usec [3] Microseconds OPTIONAL,
s-address [4] HostAddress OPTIONAL,
r-address [5] HostAddress OPTIONAL
}
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
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
}
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (30),
ctime [2] KerberosTime OPTIONAL,
cusec [3] Microseconds OPTIONAL,
stime [4] KerberosTime,
susec [5] Microseconds,
error-code [6] Int32,
crealm [7] Realm OPTIONAL,
cname [8] PrincipalName OPTIONAL,
realm [9] Realm -- Correct realm --,
sname [10] PrincipalName -- Correct name --,
e-text [11] KerberosString OPTIONAL,
e-data [12] OCTET STRING OPTIONAL
}
-- preauth stuff follows
PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC {PA-ENC-TS-ENC, {keyuse-pa-enc-ts}}
PA-ENC-TS-ENC ::= SEQUENCE {
patimestamp [0] KerberosTime -- client's time --,
pausec [1] Microseconds OPTIONAL
}
ETYPE-INFO-ENTRY
-- remove PA-ENC-TIMESTAMP2?
PA-ENC-TIMESTAMP2 ::= EncryptedData -- encrypted PA-ENC-TS2-ENC
PA-ENC-TS2-ENC ::= SEQUENCE {
etype
patimestamp [0] Int32,
salt KerberosTime -- client's time --,
pausec [1] OCTET STRING Microseconds OPTIONAL,
pachecksum [2] Checksum {{}} OPTIONAL
-- keyed checksum of KDC-REQ-BODY
}
ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY
END
draft-ietf-krb-wg-kerberos-clarifications-00
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 22 August 2002 9 March 2003
B. Definition of common authorization data elements
This appendix contains the definitions definitions of basic authorization data
elements that must be understood by all implementations. These common
authorization data elements are recursivly defined, meaning the ad-data
for these types will itself contain a sequence of authorization data
whose interpretation is affected by the encapsulating element. Depending
on the meaning of the encapsulating element, the encapsulated elements
may be ignored, might be interpreted as issued directly by the KDC, or
they might be stored in a separate plaintext part of the ticket. The
types of the encapsulating elements are specified as part of the
Kerberos specification because the behavior based on these values should
be understood across implementations whereas other elements need only be
understood by the applications which they affect.
Authorization data elements are considered critical if present in a
ticket or authenticator. Unless encapsulated in a known authorization
data element amending the criticality of the elements it contains, if an
unknown authorization data element type is received by a server either
in an AP-REQ or in a ticket contained in an AP-REQ, then authentication
SHOULD fail. Authorization data is intended to restrict the use of a
ticket. If the service cannot determine whether the restriction applies
to that service then a security weakness may result if the ticket can be
used for that service. Authorization elements that are optional can be
enclosed in AD-IF-RELEVANT element.
In the definitions that follow, the value of the ad-type for the element
will be specified in the subsection number, and the value of the ad-data
will be as shown in the ASN.1 structure that follows the subsection
heading.
B.1. If relevant
AD-IF-RELEVANT AuthorizationData
AD elements encapsulated within the if-relevant element are intended for
interpretation only by application servers that understand the
particular ad-type of the embedded element. Application servers that do
not understand the type of an element embedded within the if-relevant
element may ignore the uninterpretable element. This element promotes
interoperability across implementations which may have local extensions
for authorization.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
B.4. KDC Issued
AD-KDCIssued SEQUENCE {
ad-checksum[0] Checksum,
i-realm[1] Realm OPTIONAL,
i-sname[2] PrincipalName OPTIONAL,
elements[3] AuthorizationData.
}
ad-checksum
A checksum over the elements field using a cryptographic checksum
method that is identical to the checksum used to protect the ticket
itself (i.e. using the same hash function and the same encryption
algorithm used to encrypt the ticket) and using a key derived from
the same key used to protect the ticket. i-realm, i-sname
The name of the issuing principal if different from the KDC itself.
This field would be used when the KDC can verify the authenticity of
elements signed by the issuing principal and it allows this KDC to
notify the application server of the validity of those elements. elements
A sequence of authorization data elements issued by the KDC.
The KDC-issued ad-data field is intended to provide a means for Kerberos
principal credentials to embed within themselves privilege attributes
and other mechanisms for positive authorization, amplifying the
priveleges of the principal beyond what can be done using a credentials
without such an a-data element.
This can not be provided without this element because the definition of
the authorization-data field allows elements to be added at will by the
bearer of a TGT at the time that they request service tickets and
elements may also be added to a delegated ticket by inclusion in the
authenticator.
For KDC-issued elements this is prevented because the elements are
signed by the KDC by including a checksum encrypted using the server's
key (the same key used to encrypt the ticket - or a key derived from
that key). Elements encapsulated with in the KDC-issued element will be
ignored by the application server if this "signature" is not present.
Further, elements encapsulated within this element from a ticket
granting ticket may be interpreted by the KDC, and used as a basis
according to policy for including new signed elements within derivative
tickets, but they will not be copied to a derivative ticket directly. If
they are copied directly to a derivative ticket by a KDC that is not
aware of this element, the signature will not be correct for the
application ticket elements, and the field will be ignored by the
application server.
This element and the elements it encapulates may be safely ignored by
applications, application servers, and KDCs that do not implement this
element.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
B.5. And-Or
AD-AND-OR SEQUENCE {
condition-count[0] INTEGER,
elements[1] AuthorizationData
}
When restrictive AD elements are encapsulated within the and-or element
are encountered, only the number specified in condition-count of the
encapsulated conditions must be met in order to satisfy this element.
This element may be used to implement an "or" operation by setting the
condition-count field to 1, and it may specify an "and" operation by
setting the condition count to the number of embedded elements.
Application servers that do not implement this element must reject
tickets that contain authorization data elements of this type.
B.8. If relevant
AD-MANDATORY-FOR-KDC AuthorizationData
AD elements encapsulated within the mandatory-for-kdc element are to be
interpreted by the KDC. KDC's that do not understand the type of an
element embedded within the if-relevant element must reject the request.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
Commentary
Section 1: The preamble and introduction does not define the protocol,
mention is made in the introduction regarding the ability to rely on the
KDC to check the transited field, and on the inclusion of a flag in a
ticket indicating that this check has occurred. This is a new capability
not present in RFC1510. Pre-existing implementation may ignore or not
set this flag without negative security implications.
The definition of the secret key says that in the case of a user the key
may be derived from a password. In 1510, it said that the key was
derived from the password. This change was made to accommodate
situations where the user key might be stored on a smart-card, or
otherwise obtained independent of a password.
The introduction also mentions the use of public key for initial
authentication in Kerberos by reference. RFC1510 did not include such a
reference.
Section 1.2 was added to explain that while Kerberos provides
authentication of a named principal, it is still the responsibility of
the application to ensure that the authenticated name is the entity with
which the application wishes to communicate.
Discussion of extensibility has been added to the introduction. Section
2: No changes were made to existing options and flags specified in
RFC1510, though some of the sections in the specification were
renumbered, and text was revised to make the description and intent of
existing options clearer, especially with respect to the ENC-TKT-IN-SKEY
option (now section 2.9.3) which is used for user-to-user authentication.
New options and ticket flags added since RFC1510 include transited
policy checking (section 2.7), anonymous tickets (section 2.8) and name
canonicalization (section 2.9.1).
Section 2.9.1: Name canonicalization was added since RFC 1510. In the
penultimate revision, it covered client name canonicalization as well.
Name canonicalization was then removed and set aside for a separate
document. Section 2.9.2 and .3 were renumbered to .1 and .2.
Discussion of how extensibility affects ticket flags and KDC options was
added to the introduction. Section 3: Added mention of the optional
checksum field in the KRB-ERROR message. Added mention of name
canonicalization and anonymous tickets in exposition on KDC options.
Mention of the name canonicalization case is included in the description
of the KDC reply (3.1.3). A warning regarding generation of session keys
for application use was added, urging the inclusion of key entropy from
the KDC generated session key in the ticket. An example regarding use of
the subsession key was added to section 3.2.6. Descriptions of the
pa-etype-info, and pa-pw-salt preauthentication data items were added.
Changed may preauthenticate to should preauthenticate and included note
about known plaintext attacks.
Removed text about keys that support multiple encryption types. The
crypto draft doesn't really define things that way and it is out of
scope for the protocol spec anyway.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
Section 5: Ticket flags and KDC options were added to support the new
functions described elsewhere in this document. The encoding of the
options flags are now described to be no less than 32 bits, and the
smallest number of bits beyond 32 needed to encode any set bits. It also
describes the encoding of the bitstring as using "unnamed" bits.
Definition of the PA-USE-SPECIFIED-KVNO preauthentication data field was
added.
In the KRB-ERROR message, the e-data field was generalized for use in
other than the KDC_ERR_PREAUTH_REQUIRED error. The TypedData structure
was defined. Type tags for TypedData are defined in the same sequence as
the PA-DATA type space to avoid confusion with the use of the PA-DATA
namespace previously used for the e-data field for the
KDC_ERR_PREAUTH_REQUIRED error.
Also for possible discussion is the question of whether implementations
are required to save the original encoding of any part of a message that
might possibly be resent to another party. This is the TicketExtensions
case, but may turn out to be more general.
Section 8: Commentary: Words were added describing the convention that
domain based realm names for newly created realms should be specified as
upper case. This recommendation does not make lower case realm names
illegal. Words were added highlighting that the slash separated
components in the X500 style of realm names is consistent with existing
RFC1510 based implementations, but that it conflicts with the general
recommendation of X.500 name representation specified in RFC2253.
Section 8: Since RFC1510, the definition of the TCP transport for
Kerberos messages was added, and the encryption and checksum number
assignments have been moved out into a separate document.
Regarding the suggestion of weakening the requirement for use of port 88
for cases where the port can be looked up elsewhere - I did not
incorporate this suggestion because cross realm authentication requires
the ability to contact the appropriate KDC, and unless ALL
implementations of Kerberos include support for finding such alternate
port numbers, use of such KDC's would be non-interoperable. (Of course,
we do not yet have a single required mechanism for determining the KDC's
network address.) Section 9: Requirements for supporting
DES3-CBC-SHA1-KD encryption and HMAC-SHA1-DES3-KD checksums were added.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
[TM] Project Athena, Athena, and Kerberos are trademarks of the
Massachusetts Institute of Technology (MIT). No commercial use of these
trademarks may be made without prior written permission of MIT.
[1.1] Note, however, that many applications use Kerberos' functions only
upon the initiation of basic authorization data elements
that must be understood by all implementations. These common authorization a stream-based network connection. Unless an
application subsequently provides integrity protection for the data elements are recursivly defined, meaning
stream, the ad-data for these types
will itself contain a sequence identity verification applies only to the initiation of authorization data whose interpretation is
affected by the encapsulating element. Depending
connection, and does not guarantee that subsequent messages on the meaning of
connection originate from the
encapsulating element, same principal.
[1.2] Secret and private are often used interchangeably in the encapsulated elements may be ignored, might be
interpreted as issued directly by
literature. In our usage, it takes two (or more) to 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.
[1.3] Of course, with appropriate permission the KDC, or they might be stored client could arrange
registration of a separately-named principal in a
separate plaintext part remote realm, and
engage in normal exchanges with that realm's services. However, for even
small numbers of clients this becomes cumbersome, and more automatic
methods as described here are necessary.
[2.1] Though it is permissible to request or issue tickets with no
network addresses specified.
[2.2] It is important that the ticket. The types of KDC be sent the encapsulating
elements are specified name as part typed by the
user, and not only the canonical form of the Kerberos specification because name. If the
behavior based domain name
system was used to find the canonical name on these values should the client side, the
mapping is vulnerable. [3.1] The password-changing request must not be understood across implementations
whereas other elements need only
honored unless the requester can provide the old password (the user's
current secret key). Otherwise, it would be understood by possible for someone to walk
up to an unattended session and change another user's password.
[3.2] To authenticate a user logging on to a local system, the applications which
they affect.
Authorization data elements are considered critical if present
credentials obtained in a ticket
or authenticator. Unless encapsulated the AS exchange may first be used in a known authorization data element
amending the criticality TGS
exchange to obtain credentials for a local server. Those credentials
must then be verified by a local server through successful completion of
the elements Client/Server exchange.
[3.3] "Random" means that, among other things, it contains, should be impossible
to guess the next session key based on knowledge of past session keys.
This can only be achieved in a pseudo-random number generator if an unknown
authorization data element type it is received by
based on cryptographic principles. It is more desirable to use a server either in truly
random number generator, such as one based on measurements of random
physical phenomena.
[3.4] Tickets contain both an AP-REQ
or in a ticket contained encrypted and unencrypted portion, so
cleartext here refers to the entire unit, which can be copied from one
message and replayed in an AP-REQ, then authentication SHOULD fail.
Authorization data is intended another without any cryptographic skill.
[3.5] Note that this can make applications based on unreliable
transports difficult to restrict code correctly. If the use of transport might deliver
duplicated messages, either a ticket. If new authenticator must be generated for
each retry, or the
service cannot determine whether application server must match requests and replies
and replay the restriction applies first reply in response to that service
then a security weakness may result if the detected duplicate.
[3.6] This allows easy implementation of user-to-user authentication
[8], which uses ticket-granting ticket can session keys in lieu of secret
server keys in situations where such secret keys could be used for that
service. Authorization elements easily
compromised.
draft-ietf-krb-wg-kerberos-clarifications-01 Expires 9 March 2003
[3.7]Note also that are optional can be enclosed in
AD-IF-RELEVANT element.
In the definitions that follow, rejection here is restricted to authenticators
from the value of same principal to the ad-type for same server. Other client principals
communicating with the element
will same server principal should not be specified in have their
authenticators rejected if the subsection number, time and the value of the ad-data
will be as shown in the ASN.1 structure that follows the subsection heading.
B.1. microsecond fields happen to
match some other client's authenticator.
[3.8] If relevant
AD-IF-RELEVANT AuthorizationData
AD elements encapsulated within this is not done, an attacker could subvert the if-relevant element are intended for
interpretation only authentication
by application servers that understand recording the particular
ad-type of ticket and authenticator sent over the embedded element. Application servers network to a
server and replaying them following an event that do not understand caused the type server to
lose track of an element embedded within recently seen authenticators.
[3.9] In the if-relevant element may ignore Kerberos version 4 protocol, the uninterpretable element. This element promotes interoperability across
implementations which may have local extensions for authorization.
B.4. KDC Issued
AD-KDCIssued SEQUENCE {
ad-checksum[0] Checksum,
i-realm[1] Realm OPTIONAL,
i-sname[2] PrincipalName OPTIONAL,
elements[3] AuthorizationData.
}
draft-ietf-krb-wg-kerberos-clarifications-00 Expires 22 August 2002
ad-checksum
A checksum over timestamp in the elements field using reply was
the client's timestamp plus one. This is not necessary in version 5
because version 5 messages are formatted in such a cryptographic checksum
method way that it is identical not
possible to create the checksum used to protect reply by judicious message surgery (even in
encrypted form) without knowledge of the ticket
itself (i.e. using appropriate encryption keys.
[3.10] Note that for encrypting the same hash function and KRB_AP_REP message, the same encryption
algorithm used to encrypt sub-session
key is not used, even if present in the ticket) Authenticator.
[3.11] Implementations of the protocol may wish to provide routines to
choose subkeys based on session keys and using random numbers and to generate
a negotiated key derived from the
same key used to protect be returned in the ticket.
i-realm, i-sname
The name KRB_AP_REP message.
[3.12]This can be accomplished in several ways. It might be known
beforehand (since the realm is part of the issuing principal if different identifier), it
might be stored in a nameserver, or it might be obtained from a
configuration file. If the KDC itself.
This field would realm to be used when is obtained from a
nameserver, there is a danger of being spoofed if the KDC can verify nameservice
providing the authenticity of
elements signed by realm name is not authenticated. This might result in the issuing principal
use of a realm which has been compromised, and it allows this KDC would result in an
attacker's ability to
notify compromise the authentication of the application
server of to the validity of those elements.
elements
A sequence of authorization data elements issued by client.
[3.13] If the KDC.
The KDC-issued ad-data field is intended to provide client selects a means for Kerberos
principal credentials sub-session key, care must be taken to embed within themselves privilege attributes and
other mechanisms for positive authorization, amplifying
ensure the priveleges randomness of the principal beyond what can selected sub-session key. One approach
would be done using to generate a credentials without such an
a-data element.
This can not be provided without this element because the definition of random number and XOR it with the
authorization-data field allows elements to be added at will by session key
from the bearer
of ticket-granting ticket.
[6.1] For example, a TGT at the time that they request service tickets and elements pseudo-random number generator may also be added to seeded with a delegated ticket by inclusion in the authenticator.
For KDC-issued elements this is prevented because
session key, but to protect the elements are signed by original key from any accidental
weakness in the KDC by including a checksum PRNG, use possibly-known data encrypted or checksummed
using the server's key (the same key used to encrypt rather than using the ticket - or a key derived from that key). Elements
encapsulated with directly. Usage numbers in the KDC-issued element will be ignored by the
application server if this "signature" is not present. Further, elements
encapsulated within this element from a ticket granting ticket may be
interpreted by
reserved range should help avoid accidentally seeding the KDC, and used as PRNG with a basis according
value also computed and perhaps exposed to policy for
including new signed elements within derivative tickets, but they will an attacker elsewhere.
[6.2] Of course, this does not
be copied to a derivative ticket directly. If they are copied directly apply to a
derivative ticket by a KDC protocols that is not aware do their own
encryption independent of this element, framework, directly using the signature
will not be correct for key
resulting from the application ticket elements, and Kerberos authentication exchange.
[6.3] Perhaps one of the field will
be ignored by more common reasons for directly performing
encryption is direct control over the application server.
This element negotiation and to select a
"sufficiently strong" encryption algorithm (whatever that means in the
context of a given application). While Kerberos directly provides no
facility for negotiating encryption types between the elements it encapulates may be safely ignored by
applications, application servers, client
and KDCs that do not implement this
element.
B.5. And-Or
AD-AND-OR SEQUENCE {
condition-count[0] INTEGER,
elements[1] AuthorizationData
}
When restrictive AD elements are encapsulated within the and-or element server, there are
encountered, other means for accomplishing similar goals. For
example, requesting only "strong" session key types from the number specified in condition-count of KDC, and
assuming that the
encapsulated conditions must be met in order to satisfy this element. This
element may be used to implement an "or" operation type actually returned by setting the
condition-count field to 1, KDC will be understood
and it may specify an "and" operation supported by setting
the condition count to the number of embedded elements. Application servers
that do not implement this element must reject tickets that contain
authorization data elements of this type. application server.
----