Subject: Section 3 (take 2) Kerberos Revisions for comment

From: Clifford Neuman <[email-masked]>
Date: Thu, 12 Oct 2000 23:17:06 -0700 (PDT)

Attached is section 3 with changes incorporated.  The changes were
mostly editorial in nature, with a some text added to clarify the
presentation regarding selection of encryption types, and with the
addition of some text provided by Ken Raeburn to make some of the text
regarding the application's use of a replay cache descriptive rather
than constraining.

To make it easier to track the current status of section, I have set
up a web page with points to the latest version of each section:

   http://www.isi.edu/people/bcn/krb-revisions/

Here is section 3.

Clifford Neuman
---
<H3>3.  Message Exchanges</H3>

The following sections describe the interactions between network
clients and servers and the messages involved in those exchanges.

<H3>3.1.  The Authentication Service Exchange</H3>

<PRE>
                          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
</PRE>

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<A HREF="#fn3.1">[3.1]</A>.
This exchange does not by itself provide any assurance of the the
identity of the user<A HREF="#fn3.2">[3.2]</A>.

<P>

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.

<P>

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.  

<P>

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.  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 may be used for pre-authentication as described in section
3.1.1.

<P>

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.  If
suitable preauthentication has occurred, an optional checksum may be
included in the KRB_ERROR message to prevent fabrication or
modification of the KRB_ERROR message.  When a checksum is not
present, the lack of integrity protection precludes the ability to
detect replays, fabrications, or modifications of the message, and the
client must not depend on information in the KRB_ERROR message for
security critical operations.

<H4>3.1.1.  Generation of KRB_AS_REQ message</H4>

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 name-canonicalization
or 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).  See section A.1 for
pseudocode.

<P>

The client prepares the KRB_AS_REQ message and sends it to the KDC.

<H4>3.1.2.  Receipt of KRB_AS_REQ message</H4>

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.

<H4>3.1.3.  Generation of KRB_AS_REP message</H4>

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 and if
an acceptable canonical name of the client is not known, then an error
message with a KDC_ERR_C_PRINCIPAL_UNKNOWN is returned.

<P>

If the request had the CANONICALIZE option set and if the AS finds the
canonical name for the client and it is in another realm, then an
error message with a KDC_ERR_WRONG_REALM error code and the cname and
crealm in the error message will contain the true client principal
name and realm.  In this case, since no key is shared with the client,
the response from the KDC is not integrity protected and the referral
can only be considered a hint; the validity of the referral is
validated upon successful completion of initial authentication with the
correct AS using the appropriate user key.

<P>

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_FAILED 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<A HREF="#fn3.3">[3.3]</A>.

<P>

When responding to an AS request, if there are multiple encryption
keys registered for a client in the Kerberos database (or if the key
registered supports multiple encryption types; e.g. DES3-CBC-SHA1 and
DES3-CBC-SHA1-KD), 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.

<P>

If the user's key was generated using an alternate string to key
function than that used by the selected encryption type, information
needed by the string to key function will be returned to the client in
the padata field of the KRB_AS_REP message using the PA-PW-SALT,
PA-AFS3-SALT, or similar pre-authentication typed values.  This does
not affect the encryption performed by the KDC since the key stored in
the principal database already has the string to key transformation
applied.

<P>

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.

<P>

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.

<P>

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:

<UL>
<LI>The expiration time (endtime) requested in the KRB_AS_REQ message.

<LI>The ticket's start time plus the maximum allowable lifetime
associated with the client principal from the authentication server's
database (see section 4).

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

<LI>The ticket's start time plus the maximum lifetime set by the
policy of the local realm.

</UL>

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).

<P>

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:

<UL>

<LI>Its requested value.

<LI>The start time of the ticket plus the minimum of the two maximum
renewable lifetimes associated with the principals' database entries.

<LI>The start time of the ticket  plus  the  maximum  renewable
lifetime set by the policy of the local realm.

</UL>

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.

<P>

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, and sends the
message to the client.  See section A.2 for pseudocode.

<H4>3.1.4.  Generation of KRB_ERROR message</H4>

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.

<H4>3.1.5.  Receipt of KRB_AS_REP message</H4>

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).  See section A.3 for pseudocode.

<P>

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.

<H4>3.1.6.  Receipt of KRB_ERROR message</H4>

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.  If the client set the CANONICALIZE option and a
KDC_ERR_WRONG_REALM error was returned, the AS request should be
retried to the realm and client principal name specified in the error
message crealm and cname field respectively.

<H3>3.2. The Client/Server Authentication Exchange</H3>

<PRE>
                             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
</PRE>

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.

<H4>3.2.1.  The KRB_AP_REQ message</H4>

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<A HREF="#fn3.4">[3.4]</A>, 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.'

<H4>3.2.2.  Generation of a KRB_AP_REQ message</H4>

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<A
HREF="#fn3.5">[3.5]</A>.  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.

<P>

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.

<P>

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.
See section A.9 for pseudocode.

<H4>3.2.3.  Receipt of KRB_AP_REQ message</H4>

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.

<P>

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 <A
HREF="#fn3.6">[3.6]</A>.

<P>

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.

<P>

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).

<P>

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 (they might not match, for example, if the wrong session key
was used to encrypt the authenticator).  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.

<P>

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
<A HREF="#fn3.7">[3.7]</A>.  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<A HREF="#fn3.8">[3.8]</A>.

<P>

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.

<P>

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.

<P>

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.

<P>

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.
See section A.10 for pseudocode.

<P>

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.

<H4>3.2.4.  Generation of a KRB_AP_REP message</H4>

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)<A HREF="#fn3.9">[3.9]</A>.  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.  See section A.11 for pseudocode.

<H4>3.2.5.  Receipt of KRB_AP_REP message</H4>

If a KRB_AP_REP message is returned, the client uses the session key
from the credentials obtained for the server<A HREF="#fn3.10">[3.10]</A> 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.  See section A.12
for pseudocode.

<H4>3.2.6.  Using the encryption key</H4>

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<A HREF="#fn3.11">[3.11]</A>.
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.

<P>

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.  

<P>

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.

<P>

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.

<H3>3.3.  The Ticket-Granting Service (TGS) Exchange</H3>

<PRE>
                          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
</PRE>

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.

<P>

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, but except when an optional checksum is included in the
KRB_ERROR message, it is not possible to detect replays or
fabrications of such messages.

<H4>3.3.1.  Generation of KRB_TGS_REQ message</H4>

Before sending a request to the ticket-granting service, the client
must determine in which realm the application server is believed to be
registered<A HREF="#fn3.12">[3.12]</A>.  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).

<P>

If the client does not know the realm of the service or the true
service principal name, then the CANONICALIZE option must be used in
the request. This will cause the TGS to locate the service principal
based on the target service name in the ticket and return the service
principal name in the response.  This function allows the KDC to
inform the user of the registered Kerberos principal name and
registered KDC for a server that may have more than one host name or
whose registered realm can not be determined from the name of the
host, but it is not to be used to locate the application server.

<P>
If the server name determined by a TGS supporting name
canonicalization is with a remote KDC, then the response will include
the principal name determined by the KDC, and will include a TGT for
the remote realm or a realm 'closer' to the realm with which the
server principal is registered.  In this case, the canonicalization
request must be repeated with a Kerberos server in the realm specified
in the returned TGT.  If neither are returned, then the request may be
retried with a Kerberos server for a realm higher in the hierarchy.
This request will itself require a ticket-granting ticket for the
higher realm which must be obtained by recursively applying these
directions.

<P>

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.

<P>

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.

<P>

In preparing the authentication header, the client can select a
sub-session key under which the response from the Kerberos server will
be encrypted<A HREF="#fn3.13">[3.13]</A>.  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.

<P>

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

<H4>3.3.2.  Receipt of KRB_TGS_REQ message</H4>

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.

<P>

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.

<P>

If any of the decryptions indicate failed integrity checks, the
KRB_AP_ERR_BAD_INTEGRITY error is returned.  If the CANONICALIZE
option is set in the KRB_TGS_REQ, then the requested service name might
not be the true principal name or the service might not be in the TGS
realm and the correct name must be determined.

<H4>3.3.3.  Generation of KRB_TGS_REP message</H4>

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.

<P>

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 CANONICALIZE option is set, the TGS
may return a ticket containing the server name of the true service
principal. 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.

<P>

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.

<P>

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.

<P>

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.

<P>

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.

<P>

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.

<P>

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 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.

<P>

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.  See section A.6 for pseudocode.

<H5>3.3.3.1.  Checking for revoked tickets</H5>

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 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.

<P>

<H5>3.3.3.2.  Encoding the transited field</H5>

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 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).

<P>

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).

<P>

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.

<P>

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.

<P>

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 "\".

<P>

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:

<PRE>
     "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.".
</PRE>

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:

<PRE>
     "EDU,MIT.,WASHINGTON.EDU"
</PRE>

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:

<PRE>
     "/COM,/HP,/APOLLO, /COM/DEC".
</PRE>

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:

<PRE>
     "/COM,/HP"
</PRE>

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.

<H4>3.3.4.  Receipt of KRB_TGS_REP message</H4>

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. See section A.7 for
pseudocode.

<H3>3.4.  The KRB_SAFE Exchange</H3>

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).

<H4>3.4.1.  Generation of a KRB_SAFE message</H4>

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 a keyed one-way hash
function (such as the RSA- MD5-DES checksum algorithm specified in
section 6.4.5, or the DES MAC), generated using the sub-session key if
present, or the session key.  Different algorithms may be selected by
changing the checksum type in the message.  Unkeyed or
non-collision-proof checksums are not suitable for this use.

<P>

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.

<P>

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.

<P>

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.

<P>

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.

<H4>3.4.2.  Receipt of KRB_SAFE message</H4>

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.

<P>

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, and if it is not, a
KRB_AP_ERR_INAPP_CKSUM error is generated.  If the sender's address
was included in the control 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 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.  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.

<P>

If all the checks succeed, the application is assured that the message
was generated by its peer and was not modified in transit.

<H3>3.5.  The KRB_PRIV Exchange</H3>

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.

<H4>3.5.1.  Generation of a KRB_PRIV message</H4>

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.

<H4>3.5.2.  Receipt of KRB_PRIV message</H4>

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.

<P>

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
sender's address was included in the control 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 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.  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.

<P>

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).

<H3>3.6.  The KRB_CRED Exchange</H3>

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.

<H4>3.6.1.  Generation of a KRB_CRED message</H4>

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.

<P>

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).

<H4>3.6.2.  Receipt of KRB_CRED message</H4>

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.

<P>

If present or required, the recipient verifies 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.  A failed match for either
case generates a KRB_AP_ERR_BADADDR error.  The timestamp and usec
fields (and the nonce field if required) are checked next.  If the
timestamp and usec are not present, or they are present but not
current, the KRB_AP_ERR_SKEW error is generated.

<P>

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.

<HR>

<A NAME="fn3.1">[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 an unattended session and change another user's password. <P>

<A NAME="fn3.2">[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. <P>

<A NAME="fn3.3">[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 is more
desirable to use a truly random number generator, such as one based on
measurements of random physical phenomena. <P>

<A NAME="fn3.4">[3.4] Tickets contain both an encrypted and unencrypted
portion, so cleartext here refers to the entire unit, which can be
copied from one message and replayed in another without any
cryptographic skill.<P>

<A NAME="fn3.5">[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 first reply in response to a
detected duplicate.  <P>

<A NAME="fn3.6">[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. <P>

<A NAME="fn3.7">[3.7]Note also that the rejection here is restricted to authenticators from
the same principal to the same server.  Other client principals
communicating with the same server principal should not be have their
authenticators rejected if the time and microsecond fields happen to
match some other client's authenticator.<P>

<A NAME="fn3.8">[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 of recently seen authenticators.<P>

<A NAME="fn3.9">[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 encrypted form) without knowledge of the
appropriate encryption keys. <P>

<A NAME="fn3.10">[3.10] Note that for encrypting the KRB_AP_REP message,
the sub-session key is not used, even if present in the
Authenticator. <P>

<A NAME="fn3.11">[3.11] Implementations of the protocol may wish to
provide routines to choose subkeys based on session keys and random
numbers and to generate a negotiated key to be returned in the
KRB_AP_REP message.<P>

<A NAME="fn3.12">[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 being spoofed if the
nameservice providing the realm name is not authenticated.  This
might result in the use 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. <P>

<A NAME="fn3.13">[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.<P>

<HR>

<H1>Commentary</H1>

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.