RFC 1510
The Kerberos Network Authentication Service (V5)
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. The following sections specify the encryption and checksum mechanisms currently defined for Kerberos. The encodings, chaining, and padding requirements for each are described. For encryption methods, it is often desirable to place random information (often referred to as a confounder) at the start of the message. The requirements for a confounder are specified with each encryption mechanism. Some encryption systems use a block-chaining method to improve the the security characteristics of the ciphertext. However, these chaining methods often don't provide an integrity check upon decryption. Such systems (such as DES in CBC mode) must be augmented with a checksum of the plaintext which can be verified at decryption and used to detect any tampering or damage. Such checksums should be good at detecting burst errors in the input. If any damage is detected, the decryption routine is expected to return an error indicating the failure of an integrity check. Each encryption type is expected to provide and verify an appropriate checksum. The specification of each encryption method sets out its checksum requirements. Finally, where a key is to be derived from a user's password, an algorithm for converting the password to a key of the appropriate type is included. It is desirable for the string to key function to be one-way, and for the mapping to be different in different realms. This is important because users who are registered in more than one realm will often use the same password in each, and it is desirable that an attacker compromising the Kerberos server in one realm not obtain or derive the user's key in another. For a discussion of the integrity characteristics of the candidate encryption and checksum methods considered for Kerberos, the the reader is referred to [13]. 6.1. Encryption Specifications The following ASN.1 definition describes all encrypted messages. The enc-part field which appears in the unencrypted part of messages in
section 5 is a sequence consisting of an encryption type, an optional
key version number, and the ciphertext.
EncryptedData ::= SEQUENCE {
etype[0] INTEGER, -- EncryptionType
kvno[1] INTEGER OPTIONAL,
cipher[2] OCTET STRING -- ciphertext
}
etype This field identifies which encryption algorithm was used
to encipher the cipher. Detailed specifications for
selected encryption types appear later in this section.
kvno This field contains the version number of the key under
which data is encrypted. It is only present in messages
encrypted under long lasting keys, such as principals'
secret keys.
cipher This field contains the enciphered text, encoded as an
OCTET STRING.
The cipher field is generated by applying the specified encryption
algorithm to data composed of the message and algorithm-specific
inputs. Encryption mechanisms defined for use with Kerberos must
take sufficient measures to guarantee the integrity of the plaintext,
and we recommend they also take measures to protect against
precomputed dictionary attacks. If the encryption algorithm is not
itself capable of doing so, the protections can often be enhanced by
adding a checksum and a confounder.
The suggested format for the data to be encrypted includes a
confounder, a checksum, the encoded plaintext, and any necessary
padding. The msg-seq field contains the part of the protocol message
described in section 5 which is to be encrypted. The confounder,
checksum, and padding are all untagged and untyped, and their length
is exactly sufficient to hold the appropriate item. The type and
length is implicit and specified by the particular encryption type
being used (etype). The format for the data to be encrypted is
described in the following diagram:
+-----------+----------+-------------+-----+
|confounder | check | msg-seq | pad |
+-----------+----------+-------------+-----+
The format cannot be described in ASN.1, but for those who prefer an
ASN.1-like notation:
CipherText ::= ENCRYPTED SEQUENCE {
confounder[0] UNTAGGED OCTET STRING(conf_length) OPTIONAL,
check[1] UNTAGGED OCTET STRING(checksum_length) OPTIONAL,
msg-seq[2] MsgSequence,
pad UNTAGGED OCTET STRING(pad_length) OPTIONAL
}
In the above specification, UNTAGGED OCTET STRING(length) is the
notation for an octet string with its tag and length removed. It is
not a valid ASN.1 type. The tag bits and length must be removed from
the confounder since the purpose of the confounder is so that the
message starts with random data, but the tag and its length are
fixed. For other fields, the length and tag would be redundant if
they were included because they are specified by the encryption type.
One generates a random confounder of the appropriate length, placing
it in confounder; zeroes out check; calculates the appropriate
checksum over confounder, check, and msg-seq, placing the result in
check; adds the necessary padding; then encrypts using the specified
encryption type and the appropriate key.
Unless otherwise specified, a definition of an encryption algorithm
that specifies a checksum, a length for the confounder field, or an
octet boundary for padding uses this ciphertext format (The ordering
of the fields in the CipherText is important. Additionally, messages
encoded in this format must include a length as part of the msg-seq
field. This allows the recipient to verify that the message has not
been truncated. Without a length, an attacker could use a chosen
plaintext attack to generate a message which could be truncated,
while leaving the checksum intact. Note that if the msg-seq is an
encoding of an ASN.1 SEQUENCE or OCTET STRING, then the length is
part of that encoding.). Those fields which are not specified will be
omitted.
In the interest of allowing all implementations using a particular
encryption type to communicate with all others using that type, the
specification of an encryption type defines any checksum that is
needed as part of the encryption process. If an alternative checksum
is to be used, a new encryption type must be defined.
Some cryptosystems require additional information beyond the key and
the data to be encrypted. For example, DES, when used in cipher-
block-chaining mode, requires an initialization vector. If required,
the description for each encryption type must specify the source of
such additional information.
6.2. Encryption Keys The sequence below shows the encoding of an encryption key: EncryptionKey ::= SEQUENCE { keytype[0] INTEGER, keyvalue[1] OCTET STRING } keytype This field specifies the type of encryption key that follows in the keyvalue field. It will almost always correspond to the encryption algorithm used to generate the EncryptedData, though more than one algorithm may use the same type of key (the mapping is many to one). This might happen, for example, if the encryption algorithm uses an alternate checksum algorithm for an integrity check, or a different chaining mechanism. keyvalue This field contains the key itself, encoded as an octet string. All negative values for the encryption key type are reserved for local use. All non-negative values are reserved for officially assigned type fields and interpretations. 6.3. Encryption Systems 6.3.1. The NULL Encryption System (null) If no encryption is in use, the encryption system is said to be the NULL encryption system. In the NULL encryption system there is no checksum, confounder or padding. The ciphertext is simply the plaintext. The NULL Key is used by the null encryption system and is zero octets in length, with keytype zero (0). 6.3.2. DES in CBC mode with a CRC-32 checksum (des-cbc-crc) The des-cbc-crc encryption mode encrypts information under the Data Encryption Standard [11] using the cipher block chaining mode [12]. A CRC-32 checksum (described in ISO 3309 [14]) is applied to the confounder and message sequence (msg-seq) and placed in the cksum field. DES blocks are 8 bytes. As a result, the data to be encrypted (the concatenation of confounder, checksum, and message) must be padded to an 8 byte boundary before encryption. The details of the encryption of this data are identical to those for the des- cbc-md5 encryption mode. Note that, since the CRC-32 checksum is not collisionproof, an
attacker could use a probabilistic chosenplaintext attack to generate a valid message even if a confounder is used [13]. The use of collision-proof checksums is recommended for environments where such attacks represent a significant threat. The use of the CRC-32 as the checksum for ticket or authenticator is no longer mandated as an interoperability requirement for Kerberos Version 5 Specification 1 (See section 9.1 for specific details). 6.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4) The des-cbc-md4 encryption mode encrypts information under the Data Encryption Standard [11] using the cipher block chaining mode [12]. An MD4 checksum (described in [15]) is applied to the confounder and message sequence (msg-seq) and placed in the cksum field. DES blocks are 8 bytes. As a result, the data to be encrypted (the concatenation of confounder, checksum, and message) must be padded to an 8 byte boundary before encryption. The details of the encryption of this data are identical to those for the descbc-md5 encryption mode. 6.3.4. DES in CBC mode with an MD5 checksum (des-cbc-md5) The des-cbc-md5 encryption mode encrypts information under the Data Encryption Standard [11] using the cipher block chaining mode [12]. An MD5 checksum (described in [16]) is applied to the confounder and message sequence (msg-seq) and placed in the cksum field. DES blocks are 8 bytes. As a result, the data to be encrypted (the concatenation of confounder, checksum, and message) must be padded to an 8 byte boundary before encryption. Plaintext and DES ciphtertext are encoded as 8-octet blocks which are concatenated to make the 64-bit inputs for the DES algorithms. The first octet supplies the 8 most significant bits (with the octet's MSbit used as the DES input block's MSbit, etc.), the second octet the next 8 bits, ..., and the eighth octet supplies the 8 least significant bits. Encryption under DES using cipher block chaining requires an additional input in the form of an initialization vector. Unless otherwise specified, zero should be used as the initialization vector. Kerberos' use of DES requires an 8-octet confounder. The DES specifications identify some "weak" and "semiweak" keys; those keys shall not be used for encrypting messages for use in Kerberos. Additionally, because of the way that keys are derived for the encryption of checksums, keys shall not be used that yield "weak" or "semi-weak" keys when eXclusive-ORed with the constant F0F0F0F0F0F0F0F0.
A DES key is 8 octets of data, with keytype one (1). This consists
of 56 bits of key, and 8 parity bits (one per octet). The key is
encoded as a series of 8 octets written in MSB-first order. The bits
within the key are also encoded in MSB order. For example, if the
encryption key is:
(B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) where
B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the
parity bits, the first octet of the key would be B1,B2,...,B7,P1
(with B1 as the MSbit). [See the FIPS 81 introduction for
reference.]
To generate a DES key from a text string (password), the text string
normally must have the realm and each component of the principal's
name appended(In some cases, it may be necessary to use a different
"mix-in" string for compatibility reasons; see the discussion of
padata in section 5.4.2.), then padded with ASCII nulls to an 8 byte
boundary. This string is then fan-folded and eXclusive-ORed with
itself to form an 8 byte DES key. The parity is corrected on the
key, and it is used to generate a DES CBC checksum on the initial
string (with the realm and name appended). Next, parity is corrected
on the CBC checksum. If the result matches a "weak" or "semiweak"
key as described in the DES specification, it is eXclusive-ORed with
the constant 00000000000000F0. Finally, the result is returned as
the key. Pseudocode follows:
string_to_key(string,realm,name) {
odd = 1;
s = string + realm;
for(each component in name) {
s = s + component;
}
tempkey = NULL;
pad(s); /* with nulls to 8 byte boundary */
for(8byteblock in s) {
if(odd == 0) {
odd = 1;
reverse(8byteblock)
}
else odd = 0;
tempkey = tempkey XOR 8byteblock;
}
fixparity(tempkey);
key = DES-CBC-check(s,tempkey);
fixparity(key);
if(is_weak_key_key(key))
key = key XOR 0xF0;
return(key);
}
(next page on part 4)
