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] Realm,
sname[2] PrincipalName,
enc-part[3] EncryptedData
}
-- Encrypted part of ticket
EncTicketPart ::= [APPLICATION 3] SEQUENCE {
flags[0] TicketFlags,
key[1] EncryptionKey,
crealm[2] Realm,
cname[3] PrincipalName,
transited[4] TransitedEncoding,
authtime[5] KerberosTime,
starttime[6] KerberosTime OPTIONAL,
endtime[7] KerberosTime,
renew-till[8] KerberosTime OPTIONAL,
caddr[9] HostAddresses OPTIONAL,
authorization-data[10] AuthorizationData OPTIONAL
}
-- encoded Transited field
TransitedEncoding ::= SEQUENCE {
tr-type[0] INTEGER, -- must be registered
contents[1] OCTET STRING
}
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 the name part of the server's
identity.
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). Bit 0 is the most significant bit. The
encoding of the bits is specified in section 5.2. The
flags are described in more detail above in section 2. The
meanings of the flags are:
Bit(s) Name Description
0 RESERVED Reserved 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 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 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
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 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
can check the authtime field to see
when the original authentication
occurred.
7 INVALID This flag indicates that a ticket is
invalid, and it must be validated by
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
(some particularly careful servers
may wish to disallow renewable
tickets). A renewable ticket can be
used to obtain a replacement ticket
that expires at a later date.
9 INITIAL This flag indicates that this ticket
was issued 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
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
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-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.
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.1 for details on how
this field encodes the traversed realms.
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 (It is NOT recommended that this time
value be used to adjust the workstation's clock since the
workstation cannot reliably determine that such a
KRB_AS_REP actually came from the proper KDC in a timely
manner.).
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.
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.
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. The data in this field are specific to the end
service. It is expected that 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 subfields, 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.
It is interesting to note that 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 [9] for some suggested
uses of this field.
The authorization-data field is optional and does not have
to be included in a ticket.
5.3.2. Authenticators
An authenticator is a record sent with a ticket to a server to
certify the client's knowledge of the encryption key in the ticket,
to help the server detect replays, and to help choose a "true session
key" to use with the particular session. 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] INTEGER,
ctime[5] KerberosTime,
subkey[6] EncryptionKey OPTIONAL,
seq-number[7] INTEGER 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.
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 exchange
between the client and the Kerberos server. The 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 of its own. Instead, its type is
one of KRB_AS_REQ or KRB_TGS_REQ 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 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] SEQUENCE OF PA-DATA OPTIONAL,
req-body[4] KDC-REQ-BODY
}
PA-DATA ::= SEQUENCE {
padata-type[1] INTEGER,
padata-value[2] OCTET STRING,
-- might be encoded AP-REQ
}
KDC-REQ-BODY ::= SEQUENCE {
kdc-options[0] KDCOptions,
cname[1] PrincipalName OPTIONAL,
-- Used only in AS-REQ
realm[2] Realm, -- Server's realm
-- Also client's in AS-REQ
sname[3] PrincipalName OPTIONAL,
from[4] KerberosTime OPTIONAL,
till[5] KerberosTime,
rtime[6] KerberosTime OPTIONAL,
nonce[7] INTEGER,
etype[8] SEQUENCE OF INTEGER, -- EncryptionType,
-- in preference order
addresses[9] HostAddresses OPTIONAL,
enc-authorization-data[10] EncryptedData OPTIONAL,
-- Encrypted AuthorizationData encoding
additional-tickets[11] SEQUENCE OF Ticket OPTIONAL
}
The fields in this message are:
pvno This field is included in each message, and 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 The padata (pre-authentication data) field contains a of
authentication information which may be needed before
credentials can be issued or decrypted. In the case of
requests for additional tickets (KRB_TGS_REQ), this field
will include an element with padata-type of PA-TGS-REQ and
data of an authentication header (ticket-granting ticket
and authenticator). The checksum in the authenticator
(which must be collisionproof) is to be computed over the
KDC-REQ-BODY encoding. In most requests for initial
authentication (KRB_AS_REQ) and most replies (KDC-REP), the
padata field will be left out.
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. This is accomplished with a
padata field with padata-type equal to PA-ENC-TIMESTAMP and
padata-value defined as follows:
padata-type ::= PA-ENC-TIMESTAMP
padata-value ::= EncryptedData -- PA-ENC-TS-ENC
PA-ENC-TS-ENC ::= SEQUENCE {
patimestamp[0] KerberosTime, -- client's time
pausec[1] INTEGER OPTIONAL
}
with patimestamp containing the client's time and pausec
containing 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
sequence, encrypted using the client's secret key.
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
"smartcards" with Kerberos. The details of such extensions
are beyond the scope of this specification. See [10] for
additional uses of this field.
padata-type The padata-type element of the padata field 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.
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.
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:
Bit(s) 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 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 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 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 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.
5 ALLOW-POSTDATE The ALLOW-POSTDATE option indicates
that the ticket to be issued is to
have its MAY-POSTDATE flag set. It
may only be set on the initial
request, or in a subsequent request if
the ticket-granting ticket on which it
is based 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 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 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-26 RESERVED Reserved for future use.
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, 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.
28 ENC-TKT-IN-SKEY This option is used only by the
ticket-granting service. The ENC-
TKT-IN-SKEY option indicates 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
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, 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.
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.
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.
till This field contains the expiration date requested by the
client in a ticket request.
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 gen erated
randomly, but if the correct time is known, it may suffice
(Note, however, that if the time is used as the nonce, one
must make sure that the workstation time is monotonically
increasing. If the time is ever reset backwards, there is
a small, but finite, probability that a nonce will be
reused.).
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. 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 code 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.
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.
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] SEQUENCE OF PA-DATA OPTIONAL,
crealm[3] Realm,
cname[4] PrincipalName,
ticket[5] Ticket,
enc-part[6] EncryptedData
}
EncASRepPart ::= [APPLICATION 25[25]] EncKDCRepPart
EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart
EncKDCRepPart ::= SEQUENCE {
key[0] EncryptionKey,
last-req[1] LastReq,
nonce[2] INTEGER,
key-expiration[3] KerberosTime OPTIONAL,
flags[4] TicketFlags,
authtime[5] KerberosTime,
starttime[6] KerberosTime OPTIONAL,
endtime[7] KerberosTime,
renew-till[8] KerberosTime OPTIONAL,
srealm[9] Realm,
sname[10] PrincipalName,
caddr[11] HostAddresses OPTIONAL
}
NOTE: In EncASRepPart, the application code in the encrypted
part of a message provides an additional check that
the message was decrypted properly.
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.
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.
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
expira tion 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] APOptions,
ticket[3] Ticket,
authenticator[4] EncryptedData
}
APOptions ::= BIT STRING {
reserved(0),
use-session-key(1),
mutual-required(2)
}
pvno and msg-type These fields are described above in section 5.4.1.
msg-type is KRB_AP_REQ.
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-KEYThe USE-SESSION-KEY option indicates
that the ticket the client is
presenting to a server 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-REQUIREDThe MUTUAL-REQUIRED option tells the
server 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 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 timestamp. The message is sent in
in response to an application request (KRB_AP_REQ) where the mutual
authentication option has been selected in the ap-options field.
AP-REP ::= [APPLICATION 15] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
enc-part[2] EncryptedData
}
EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
ctime[0] KerberosTime,
cusec[1] INTEGER,
subkey[2] EncryptionKey OPTIONAL,
seq-number[3] INTEGER OPTIONAL
}
NOTE: in EncAPRepPart, the application code in the encrypted part of
a message provides an additional check that the message was decrypted
properly.
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_AP_REP.
enc-part This field is described above in section 5.4.2.
ctime This field contains the current time on the client's host.
cusec This field contains the microsecond part of the client's
timestamp.
subkey This field contains 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, the session key from
the ticket will be used.
5.5.3. Error message reply
If an error occurs while processing the application request, the
KRB_ERROR message will be sent in response. See section 5.9.1 for
the format of the error message. The cname and 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).
5.6.1. KRB_SAFE definition
The KRB_SAFE message contains user data along with a collision-proof
checksum keyed with the session key. The message fields are:
KRB-SAFE ::= [APPLICATION 20] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
safe-body[2] KRB-SAFE-BODY,
cksum[3] Checksum
}
KRB-SAFE-BODY ::= SEQUENCE {
user-data[0] OCTET STRING,
timestamp[1] KerberosTime OPTIONAL,
usec[2] INTEGER OPTIONAL,
seq-number[3] INTEGER OPTIONAL,
s-address[4] HostAddress,
r-address[5] HostAddress OPTIONAL
}
pvno and msg-type These fields are described above in section 5.4.1.
msg-type is KRB_SAFE.
safe-body This field is a placeholder for the body of the KRB-SAFE
message. It is to be encoded separately and then have the
checksum computed over it, for use in the cksum field.
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-BODY
sequence.
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 This field specifies the address in use by the sender of
the message.
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.
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] EncryptedData
}
EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE {
user-data[0] OCTET STRING,
timestamp[1] KerberosTime OPTIONAL,
usec[2] INTEGER OPTIONAL,
seq-number[3] INTEGER OPTIONAL,
s-address[4] HostAddress, -- sender's addr
r-address[5] HostAddress OPTIONAL
-- recip's addr
}
NOTE: In EncKrbPrivPart, the application code in the encrypted part
of a message provides an additional check that the message was
decrypted properly.
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 (If supported by the
encryption method in use, an initialization vector may be
passed to the encryption procedure, in order to achieve
proper cipher chaining. The initialization vector might
come from the last block of the ciphertext from the
previous KRB_PRIV message, but it is the application's
choice whether or not to use such an initialization vector.
If left out, the default initialization vector for the
encryption algorithm will be used.). 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.
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 encryped under an
encryption key previously exchanged. The message fields are:
KRB-CRED ::= [APPLICATION 22] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER, -- KRB_CRED
tickets[2] SEQUENCE OF Ticket,
enc-part[3] EncryptedData
}
EncKrbCredPart ::= [APPLICATION 29] SEQUENCE {
ticket-info[0] SEQUENCE OF KrbCredInfo,
nonce[1] INTEGER OPTIONAL,
timestamp[2] KerberosTime OPTIONAL,
usec[3] INTEGER OPTIONAL,
s-address[4] HostAddress OPTIONAL,
r-address[5] HostAddress OPTIONAL
}
KrbCredInfo ::= SEQUENCE {
key[0] EncryptionKey,
prealm[1] Realm OPTIONAL,
pname[2] PrincipalName OPTIONAL,
flags[3] TicketFlags OPTIONAL,
authtime[4] KerberosTime OPTIONAL,
starttime[5] KerberosTime OPTIONAL,
endtime[6] KerberosTime OPTIONAL
renew-till[7] KerberosTime OPTIONAL,
srealm[8] Realm OPTIONAL,
sname[9] PrincipalName OPTIONAL,
caddr[10] HostAddresses OPTIONAL
}
pvno and msg-type These fields are described above 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.
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 mes sage 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 not protected by any
encryption, it is quite possible for an intruder to synthesize or
modify such a message. In particular, this means that 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.
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] KerberosTime OPTIONAL,
cusec[3] INTEGER OPTIONAL,
stime[4] KerberosTime,
susec[5] INTEGER,
error-code[6] INTEGER,
crealm[7] Realm OPTIONAL,
cname[8] PrincipalName OPTIONAL,
realm[9] Realm, -- Correct realm
sname[10] PrincipalName, -- Correct name
e-text[11] GeneralString OPTIONAL,
e-data[12] OCTET STRING OPTIONAL
}
pvno and msg-type These fields are described above 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 999. 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 the errorcode is KDC_ERR_PREAUTH_REQUIRED, then
the e-data field will contain an encoding of a sequence of
padata fields, each corresponding to an acceptable pre-
authentication method and optionally containing data for
the method:
METHOD-DATA ::= SEQUENCE of PA-DATA
If the error-code is KRB_AP_ERR_METHOD, then the e-data field will
contain an encoding of the following sequence:
METHOD-DATA ::= SEQUENCE {
method-type[0] INTEGER,
method-data[1] OCTET STRING OPTIONAL
}
method-type will indicate the required alternate method; method-data
will contain any required additional information.
6. Encryption and Checksum Specifications
The Kerberos protocols described in this document are designed to use
stream encryption ciphers, which can be simulated using commonly
available block encryption ciphers, such as the Data Encryption
Standard [11], in conjunction with block chaining and checksum
methods [12]. 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.
The Kerberos protocols generally assume that the encryption used is
secure from cryptanalysis; however, in some cases, the order of
fields in the encrypted portions of messages are arranged to minimize
the effects of poorly chosen keys. It is still important to choose
good keys. If keys are derived from user-typed passwords, those
passwords need to be well chosen to make brute force attacks more
difficult. Poorly chosen keys still make easy targets for intruders.