RFC 4120
The Kerberos Network Authentication Service (V5)
Pages: 138
Proposed Standard
→ Errata
Obsoletes: 1510
Updated by: 4537 5021 5896 6111 6112 6113 6649 6806 7751 8062 8129 8429 8553
Proposed Standard
→ Errata
Obsoletes: 1510
Updated by: 4537 5021 5896 6111 6112 6113 6649 6806 7751 8062 8129 8429 8553
Part 4 of 6 – Pages 73 to 100
5.4. Specifications for the AS and TGS Exchanges
This section specifies the format of the messages used in the exchange between the client and the Kerberos server. The format of possible error messages appears in Section 5.9.1.5.4.1. KRB_KDC_REQ Definition
The KRB_KDC_REQ message has no application tag number of its own. Instead, it is incorporated into either KRB_AS_REQ or KRB_TGS_REQ, each of which has an application tag, depending on whether the request is for an initial ticket or an additional ticket. In either case, the message is sent from the client to the KDC to request credentials for a service.
The message fields are as follows:
AS-REQ ::= [APPLICATION 10] KDC-REQ
TGS-REQ ::= [APPLICATION 12] KDC-REQ
KDC-REQ ::= SEQUENCE {
-- NOTE: first tag is [1], not [0]
pvno [1] INTEGER (5) ,
msg-type [2] INTEGER (10 -- AS -- | 12 -- TGS --),
padata [3] SEQUENCE OF PA-DATA OPTIONAL
-- NOTE: not empty --,
req-body [4] KDC-REQ-BODY
}
KDC-REQ-BODY ::= SEQUENCE {
kdc-options [0] KDCOptions,
cname [1] PrincipalName OPTIONAL
-- Used only in AS-REQ --,
realm [2] Realm
-- Server's realm
-- Also client's in AS-REQ --,
sname [3] PrincipalName OPTIONAL,
from [4] KerberosTime OPTIONAL,
till [5] KerberosTime,
rtime [6] KerberosTime OPTIONAL,
nonce [7] UInt32,
etype [8] SEQUENCE OF Int32 -- EncryptionType
-- in preference order --,
addresses [9] HostAddresses OPTIONAL,
enc-authorization-data [10] EncryptedData OPTIONAL
-- AuthorizationData --,
additional-tickets [11] SEQUENCE OF Ticket OPTIONAL
-- NOTE: not empty
}
KDCOptions ::= KerberosFlags
-- reserved(0),
-- forwardable(1),
-- forwarded(2),
-- proxiable(3),
-- proxy(4),
-- allow-postdate(5),
-- postdated(6),
-- unused7(7),
-- renewable(8),
-- unused9(9),
-- unused10(10),
-- opt-hardware-auth(11),
-- unused12(12),
-- unused13(13),
-- 15 is reserved for canonicalize
-- unused15(15),
-- 26 was unused in 1510
-- disable-transited-check(26),
--
-- renewable-ok(27),
-- enc-tkt-in-skey(28),
-- renew(30),
-- validate(31)
The fields in this message are as follows:
pvno
This field is included in each message, and specifies the protocol
version number. This document specifies protocol version 5.
msg-type
This field indicates the type of a protocol message. It will
almost always be the same as the application identifier associated
with a message. It is included to make the identifier more
readily accessible to the application. For the KDC-REQ message,
this type will be KRB_AS_REQ or KRB_TGS_REQ.
padata
Contains pre-authentication data. Requests for additional tickets
(KRB_TGS_REQ) MUST contain a padata of PA-TGS-REQ.
The padata (pre-authentication data) field contains a sequence of
authentication information that may be needed before credentials
can be issued or decrypted.
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 cases, 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 simply to copy the options field to the flags field.
There are various checks that must be made before an option is
honored 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 as
follows:
Bits Name Description
0 RESERVED Reserved for future expansion of
this field.
1 FORWARDABLE The FORWARDABLE option indicates
that the ticket to be issued is to
have its forwardable flag set. It
may only be set on the initial
request, or in a subsequent request
if the TGT 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 TGT 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 a
subsequent request if the TGT 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
TGT 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 TGT 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 TGT 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 RESERVED 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 TGT 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 RESERVED Reserved for PK-Cross.
10 RESERVED Reserved for future use.
11 RESERVED Reserved for opt-hardware-auth.
12-25 RESERVED Reserved for future use.
26 DISABLE-TRANSITED-CHECK By default the KDC will check the
transited field of a TGT against the
policy of the local realm before it
will issue derivative tickets based
on the TGT. If this flag is set in
the request, checking of the
transited field is disabled.
Tickets issued without the
performance of this check will be
noted by the reset (0) value of the
TRANSITED-POLICY-CHECKED flag,
indicating to the application server
that the transited field must be
checked locally. KDCs are
encouraged but not required to honor
the DISABLE-TRANSITED-CHECK option.
This flag is new since RFC 1510.
27 RENEWABLE-OK The RENEWABLE-OK option indicates
that a renewable ticket will be
acceptable if a ticket with the
requested life cannot otherwise be
provided, in which case a renewable
ticket may be issued with a renew-
till equal to 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 TGT 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 otherwise be 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. The sname may only be absent when the ENC-TKT-IN-
SKEY option is specified. If the sname is 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
TGT (both the Authenticator and TGT come from the padata field in
the KRB_TGS_REQ). The key usage value used when encrypting is 5
if a sub-session key is used, or 4 if the session key is used.
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 starttime for the requested ticket. If this
field is omitted, then the KDC SHOULD use the current time
instead.
till
This field contains the expiration date requested by the client in
a ticket request. It is not optional, but if the requested
endtime is "19700101000000Z", the requested ticket is to have the
maximum endtime permitted according to KDC policy. Implementation
note: This special timestamp corresponds to a UNIX time_t value of
zero on most systems.
rtime
This field is the requested renew-till time sent from a client to
the KDC in a ticket request. It is optional.
nonce
This field is part of the KDC request and response. It is
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 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 it
is optionally included in requests for additional tickets from the
ticket-granting server. It specifies the addresses from which the
requested ticket is to be valid. Normally it includes the
addresses for the client's host. If a proxy is requested, this
field will contain other addresses. The contents of this field
are usually copied by the KDC into the caddr field of the
resulting ticket.
additional-tickets
Additional tickets MAY be optionally included in a request to the
ticket-granting server. If the ENC-TKT-IN-SKEY option has been
specified, then the session key from the additional ticket will be
used in place of the server's key to encrypt the new ticket. When
the ENC-TKT-IN-SKEY option is used for user-to-user
authentication, this additional ticket MAY be a TGT issued by the
local realm or an inter-realm TGT issued for the current KDC's
realm by a remote KDC. If more than one option that requires
additional tickets has been specified, then the additional tickets
are used in the order specified by the ordering of the options
bits (see kdc-options, above).
The application tag number will be either ten (10) or twelve (12) depending on whether the request is for an initial ticket (AS-REQ) or for an additional ticket (TGS-REQ). The optional fields (addresses, authorization-data, and additional- tickets) are only included if necessary to perform the operation specified in the kdc-options field. Note 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; if it is absent, the ciphertext is encrypted in the session key from the TGT 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 (5), msg-type [1] INTEGER (11 -- AS -- | 13 -- TGS --), padata [2] SEQUENCE OF PA-DATA OPTIONAL -- NOTE: not empty --, crealm [3] Realm, cname [4] PrincipalName, ticket [5] Ticket, enc-part [6] EncryptedData -- EncASRepPart or EncTGSRepPart, -- as appropriate } EncASRepPart ::= [APPLICATION 25] EncKDCRepPart
EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart
EncKDCRepPart ::= SEQUENCE {
key [0] EncryptionKey,
last-req [1] LastReq,
nonce [2] UInt32,
key-expiration [3] KerberosTime OPTIONAL,
flags [4] TicketFlags,
authtime [5] KerberosTime,
starttime [6] KerberosTime OPTIONAL,
endtime [7] KerberosTime,
renew-till [8] KerberosTime OPTIONAL,
srealm [9] Realm,
sname [10] PrincipalName,
caddr [11] HostAddresses OPTIONAL
}
LastReq ::= SEQUENCE OF SEQUENCE {
lr-type [0] Int32,
lr-value [1] KerberosTime
}
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 it is to encode an alternate "salt" string to be used with
a string-to-key algorithm. This ability is useful for easing
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 salt
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.
ticket
The newly-issued ticket, from Section 5.3.
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 key usage value for encrypting this field is 3 in an AS-REP
message, using the client's long-term key or another key selected
via pre-authentication mechanisms. In a TGS-REP message, the key
usage value is 8 if the TGS session key is used, or 9 if a TGS
authenticator subkey is used.
Compatibility note: Some implementations unconditionally send an
encrypted EncTGSRepPart (application tag number 26) in this field
regardless of whether the reply is a AS-REP or a TGS-REP. In the
interest of compatibility, implementors MAY relax the check on the
tag number of the decrypted ENC-PART.
key
This field is the same as described for the ticket in Section 5.3.
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 TGT
was made, or the last time that a request based on a TGT 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 in to timesharing systems.
lr-type
This field indicates how the following lr-value field is to be
interpreted. Negative values indicate that the information
pertains only to the responding server. Non-negative values
pertain to all servers for the realm.
If the lr-type field is zero (0), then no information is conveyed
by the lr-value subfield. If the absolute value of the lr-type
field is one (1), then the lr-value subfield is the time of last
initial request for a TGT. If it is two (2), then the lr-value
subfield is the time of last initial request. If it is three (3),
then the lr-value subfield is the time of issue for the newest TGT
used. If it is four (4), then the lr-value subfield is the time
of the last renewal. If it is five (5), then the lr-value
subfield is the time of last request (of any type). If it is (6),
then the lr-value subfield is the time when the password will
expire. If it is (7), then the lr-value subfield is the time when
the account will expire.
lr-value
This field contains the time of the last request. The time MUST
be interpreted according to the contents of the accompanying lr-
type subfield.
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. If present, it SHOULD be set to the earlier of the
user's key expiration and account expiration. The use of this
field is deprecated, and the last-req field SHOULD be used to
convey this information instead. 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 has to be
retrieved from the KDC database. It is up to the application
client (usually the login program) to take appropriate action
(such as notifying the user) if the expiration time is imminent.
flags, authtime, starttime, endtime, renew-till and caddr
These fields are duplicates of those found in the encrypted
portion of the attached ticket (see Section 5.3), provided so the
client MAY verify that they match the intended request and in
order 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 TGT. 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 TGT.
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 (5),
msg-type [1] INTEGER (14),
ap-options [2] APOptions,
ticket [3] Ticket,
authenticator [4] EncryptedData -- Authenticator
}
APOptions ::= KerberosFlags
-- 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 by being reset (0).
The encoding of the bits is specified in Section 5.2. The
meanings of the options are as follows:
Bit(s) Name Description
0 reserved Reserved for future expansion of this field.
1 use-session-key The USE-SESSION-KEY option indicates that
the ticket the client is presenting to a
server is encrypted in the session key from
the server's TGT. When this option is not
specified, the ticket is encrypted in the
server's secret key.
2 mutual-required The MUTUAL-REQUIRED option tells the server
that the client requires mutual
authentication, and that it must respond
with a KRB_AP_REP message.
3-31 reserved Reserved for future use.
ticket
This field is a ticket authenticating the client to the server.
authenticator
This contains the encrypted authenticator, which includes the
client's choice of a subkey.
The encrypted authenticator is included in the AP-REQ; it certifies
to a server that the sender has recent knowledge of the encryption
key in the accompanying ticket, to help the server detect replays.
It also assists in the selection of a "true session key" to use with
the particular session. The DER encoding of the following is
encrypted in the ticket's session key, with a key usage value of 11
in normal application exchanges, or 7 when used as the PA-TGS-REQ
PA-DATA field of a TGS-REQ exchange (see Section 5.4.1):
-- Unencrypted authenticator
Authenticator ::= [APPLICATION 2] SEQUENCE {
authenticator-vno [0] INTEGER (5),
crealm [1] Realm,
cname [2] PrincipalName,
cksum [3] Checksum OPTIONAL,
cusec [4] Microseconds,
ctime [5] KerberosTime,
subkey [6] EncryptionKey OPTIONAL,
seq-number [7] UInt32 OPTIONAL,
authorization-data [8] AuthorizationData OPTIONAL
}
authenticator-vno
This field specifies the version number for the format of the
authenticator. This document specifies version 5.
crealm and cname
These fields are the same as those described for the ticket in
section 5.3.
cksum
This field contains a checksum of the application data that
accompanies the KRB_AP_REQ, computed using a key usage value of 10
in normal application exchanges, or 6 when used in the TGS-REQ
PA-TGS-REQ AP-DATA field.
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 to
be used to protect this specific application session. Unless an
application specifies otherwise, if this field is left out, the
session key from the ticket will be used.
seq-number
This optional field includes the initial sequence number to be
used by the KRB_PRIV or KRB_SAFE messages when sequence numbers
are used to detect replays. (It may also be used by application
specific messages.) When included in the authenticator, this
field specifies the initial sequence number for messages from the
client to the server. When included in the AP-REP message, the
initial sequence number is that for messages from the server to
the client. When used in KRB_PRIV or KRB_SAFE messages, it is
incremented by one after each message is sent. Sequence numbers
fall in the range 0 through 2^32 - 1 and wrap to zero following
the value 2^32 - 1.
For sequence numbers to support the detection of replays
adequately, 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. In the event that more than 2^32 messages are to be
generated in a series of KRB_PRIV or KRB_SAFE messages, rekeying
SHOULD be performed before sequence numbers are reused with the
same encryption key.
Implmentation note: Historically, some implementations transmit
signed twos-complement numbers for sequence numbers. In the
interests of compatibility, implementations MAY accept the
equivalent negative number where a positive number greater than
2^31 - 1 is expected.
Implementation note: As noted before, some implementations omit
the optional sequence number when its value would be zero.
Implementations MAY accept an omitted sequence number when
expecting a value of zero, and SHOULD NOT transmit an
Authenticator with a initial sequence number of zero.
authorization-data
This field is the same as described for the ticket in Section 5.3.
It is optional and will only appear when additional restrictions
are to be placed on the use of a ticket, beyond those carried in
the ticket itself.
5.5.2. KRB_AP_REP Definition
The KRB_AP_REP message contains the Kerberos protocol version number, the message type, and an encrypted time-stamp. The message is sent in response to an application request (KRB_AP_REQ) for which the mutual authentication option has been selected in the ap-options field. AP-REP ::= [APPLICATION 15] SEQUENCE { pvno [0] INTEGER (5), msg-type [1] INTEGER (15), enc-part [2] EncryptedData -- EncAPRepPart } EncAPRepPart ::= [APPLICATION 27] SEQUENCE { ctime [0] KerberosTime, cusec [1] Microseconds, subkey [2] EncryptionKey OPTIONAL, seq-number [3] UInt32 OPTIONAL } The encoded EncAPRepPart is encrypted in the shared session key of the ticket. The optional subkey field can be used in an application-arranged negotiation to choose a per association session key. pvno and msg-type These fields are described above in Section 5.4.1. msg-type is KRB_AP_REP. enc-part This field is described above in Section 5.4.2. It is computed with a key usage value of 12. 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 that 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 the latter is also left out, the session key from the ticket will be used.
seq-number
This field is described above in Section 5.3.2.
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 last encryption key negotiated via subkeys,
or with the session key if no negotiation has occurred. The message
fields are as follows:
KRB-SAFE ::= [APPLICATION 20] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (20),
safe-body [2] KRB-SAFE-BODY,
cksum [3] Checksum
}
KRB-SAFE-BODY ::= SEQUENCE {
user-data [0] OCTET STRING,
timestamp [1] KerberosTime OPTIONAL,
usec [2] Microseconds OPTIONAL,
seq-number [3] UInt32 OPTIONAL,
s-address [4] HostAddress,
r-address [5] HostAddress OPTIONAL
}
pvno and msg-type
These fields are described above in Section 5.4.1. msg-type is
KRB_SAFE.
safe-body
This field is a placeholder for the body of the KRB-SAFE message.
cksum
This field contains the checksum of the application data, computed
with a key usage value of 15.
The checksum is computed over the encoding of the KRB-SAFE
sequence. First, the cksum is set to a type zero, zero-length
value, and the checksum is computed over the encoding of the KRB-
SAFE sequence. Then the checksum is set to the result of that
computation. Finally, the KRB-SAFE sequence is encoded again.
This method, although different than the one specified in RFC
1510, corresponds to existing practice.
user-data
This field is part of the KRB_SAFE and KRB_PRIV messages, and
contains the application-specific data that is being passed from
the sender to the recipient.
timestamp
This field is part of the KRB_SAFE and KRB_PRIV messages. Its
contents are the current time as known by the sender of the
message. By checking the timestamp, the recipient of the message
is able to make sure that it was recently generated, and is not a
replay.
usec
This field is part of the KRB_SAFE and KRB_PRIV headers. It
contains the microsecond part of the timestamp.
seq-number
This field is described above in Section 5.3.2.
s-address
Sender's address.
This field specifies the address in use by the sender of the
message.
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 that 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 send a message to its peer securely and privately. 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 as follows: KRB-PRIV ::= [APPLICATION 21] SEQUENCE { pvno [0] INTEGER (5), msg-type [1] INTEGER (21), -- NOTE: there is no [2] tag enc-part [3] EncryptedData -- EncKrbPrivPart } EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { user-data [0] OCTET STRING, timestamp [1] KerberosTime OPTIONAL, usec [2] Microseconds OPTIONAL, seq-number [3] UInt32 OPTIONAL, s-address [4] HostAddress -- sender's addr --, r-address [5] HostAddress OPTIONAL -- recip's addr } 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, with a key usage value of 13. This encrypted encoding is used for the enc-part field of the KRB-PRIV message. 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 encrypted under an encryption key previously exchanged or transferred alongside the KRB_CRED message. The message fields are as follows: KRB-CRED ::= [APPLICATION 22] SEQUENCE { pvno [0] INTEGER (5), msg-type [1] INTEGER (22), tickets [2] SEQUENCE OF Ticket, enc-part [3] EncryptedData -- EncKrbCredPart } EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { ticket-info [0] SEQUENCE OF KrbCredInfo, nonce [1] UInt32 OPTIONAL, timestamp [2] KerberosTime OPTIONAL, usec [3] Microseconds OPTIONAL, s-address [4] HostAddress OPTIONAL, r-address [5] HostAddress OPTIONAL } 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 by the sender and the
intended recipient, with a key usage value of 14. This encrypted
encoding is used for the enc-part field of the KRB-CRED message.
Implementation note: Implementations of certain applications, most
notably certain implementations of the Kerberos GSS-API mechanism,
do not separately encrypt the contents of the EncKrbCredPart of
the KRB-CRED message when sending it. In the case of those GSS-
API mechanisms, this is not a security vulnerability, as the
entire KRB-CRED message is itself embedded in an encrypted
message.
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 reused.
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 5.2.9.
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 values.
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 because the KRB_ERROR message is not integrity protected,
it is quite possible for an intruder to synthesize or modify it. 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 (5),
msg-type [1] INTEGER (30),
ctime [2] KerberosTime OPTIONAL,
cusec [3] Microseconds OPTIONAL,
stime [4] KerberosTime,
susec [5] Microseconds,
error-code [6] Int32,
crealm [7] Realm OPTIONAL,
cname [8] PrincipalName OPTIONAL,
realm [9] Realm -- service realm --,
sname [10] PrincipalName -- service name --,
e-text [11] KerberosString 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 and cusec
These fields are described above in Section 5.5.2. If the values
for these fields are known to the entity generating the error (as
they would be if the KRB-ERROR is generated in reply to, e.g., a
failed authentication service request), they should be populated
in the KRB-ERROR. If the values are not available, these fields
can be omitted.
stime
This field contains the current time on the server. It is of type
KerberosTime.
susec
This field contains the microsecond part of the server's
timestamp. Its value ranges from 0 to 999999. It appears along
with stime. The two fields are used in conjunction to specify a
reasonably accurate timestamp.
error-code
This field contains the error code returned by Kerberos or the
server when a request fails. To interpret the value of this field
see the list of error codes in Section 7.5.9. Implementations are
encouraged to provide for national language support in the display
of error messages.
crealm, and cname
These fields are described above in Section 5.3. When the entity
generating the error knows these values, they should be populated
in the KRB-ERROR. If the values are not known, the crealm and
cname fields SHOULD be omitted.
realm and sname
These fields are described above in Section 5.3.
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
For error codes defined in this document other than
KDC_ERR_PREAUTH_REQUIRED, the format and contents of the e-data field
are implementation-defined. Similarly, for future error codes, the
format and contents of the e-data field are implementation-defined
unless specified otherwise. Whether defined by the implementation or
in a future document, the e-data field MAY take the form of TYPED-
DATA:
TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
data-type [0] Int32,
data-value [1] OCTET STRING OPTIONAL
}
5.10. Application Tag Numbers
The following table lists the application class tag numbers used by
various data types defined in this section.
Tag Number(s) Type Name Comments
0 unused
1 Ticket PDU
2 Authenticator non-PDU
3 EncTicketPart non-PDU
4-9 unused
10 AS-REQ PDU
11 AS-REP PDU
12 TGS-REQ PDU
13 TGS-REP PDU
14 AP-REQ PDU 15 AP-REP PDU 16 RESERVED16 TGT-REQ (for user-to-user) 17 RESERVED17 TGT-REP (for user-to-user) 18-19 unused 20 KRB-SAFE PDU 21 KRB-PRIV PDU 22 KRB-CRED PDU 23-24 unused 25 EncASRepPart non-PDU 26 EncTGSRepPart non-PDU 27 EncApRepPart non-PDU 28 EncKrbPrivPart non-PDU 29 EncKrbCredPart non-PDU 30 KRB-ERROR PDU The ASN.1 types marked above as "PDU" (Protocol Data Unit) are the only ASN.1 types intended as top-level types of the Kerberos protocol, and are the only types that may be used as elements in another protocol that makes use of Kerberos.6. Naming Constraints
6.1. Realm Names
Although realm names are encoded as GeneralStrings and technically a realm can select any name it chooses, interoperability across realm boundaries requires agreement on how realm names are to be assigned, and what information they imply. To enforce these conventions, each realm MUST conform to the conventions itself, and it MUST require that any realms with which inter-realm keys are shared also conform to the conventions and require the same from its neighbors.
Kerberos realm names are case sensitive. Realm names that differ
only in the case of the characters are not equivalent. There are
presently three styles of realm names: domain, X500, and other.
Examples of each style follow:
domain: ATHENA.MIT.EDU
X500: C=US/O=OSF
other: NAMETYPE:rest/of.name=without-restrictions
Domain style realm names MUST look like domain names: they consist of
components separated by periods (.) and they contain neither colons
(:) nor slashes (/). Though domain names themselves are case
insensitive, in order for realms to match, the case must match as
well. When establishing a new realm name based on an internet domain
name it is recommended by convention that the characters be converted
to uppercase.
X.500 names contain an equals sign (=) and cannot contain a colon (:)
before the equals sign. The realm names for X.500 names will be
string representations of the names with components separated by
slashes. Leading and trailing slashes will not be included. Note
that the slash separator is consistent with Kerberos implementations
based on RFC 1510, but it is different from the separator recommended
in RFC 2253.
Names that fall into the other category MUST begin with a prefix that
contains no equals sign (=) or period (.), and the prefix MUST be
followed by a colon (:) and the rest of the name. All prefixes
expect those beginning with used. Presently none are assigned.
The reserved category includes strings that do not fall into the
first three categories. All names in this category are reserved. It
is unlikely that names will be assigned to this category unless there
is a very strong argument for not using the 'other' category.
These rules guarantee that there will be no conflicts between the
various name styles. The following additional constraints apply to
the assignment of realm names in the domain and X.500 categories:
either the name of a realm for the domain or X.500 formats must be
used by the organization owning (to whom it was assigned) an Internet
domain name or X.500 name, or, in the case that no such names are
registered, authority to use a realm name MAY be derived from the
authority of the parent realm. For example, if there is no domain
name for E40.MIT.EDU, then the administrator of the MIT.EDU realm can
authorize the creation of a realm with that name.
This is acceptable because the organization to which the parent is
assigned is presumably the organization authorized to assign names to
its children in the X.500 and domain name systems as well. If the parent assigns a realm name without also registering it in the domain name or X.500 hierarchy, it is the parent's responsibility to make sure that in the future there will not exist a name identical to the realm name of the child unless it is assigned to the same entity as the realm name.6.2. Principal Names
As was the case for realm names, conventions are needed to ensure that all agree on what information is implied by a principal name. The name-type field that is part of the principal name indicates the kind of information implied by the name. The name-type SHOULD be treated only as a hint to interpreting the meaning of a name. It is not significant when checking for equivalence. Principal names that differ only in the name-type identify the same principal. The name type does not partition the name space. Ignoring the name type, no two names can be the same (i.e., at least one of the components, or the realm, MUST be different). The following name types are defined: Name Type Value Meaning NT-UNKNOWN 0 Name type not known NT-PRINCIPAL 1 Just the name of the principal as in DCE, or for users NT-SRV-INST 2 Service and other unique instance (krbtgt) NT-SRV-HST 3 Service with host name as instance (telnet, rcommands) NT-SRV-XHST 4 Service with host as remaining components NT-UID 5 Unique ID NT-X500-PRINCIPAL 6 Encoded X.509 Distinguished name [RFC2253] NT-SMTP-NAME 7 Name in form of SMTP email name (e.g., user@example.com) NT-ENTERPRISE 10 Enterprise name - may be mapped to principal name When a name implies no information other than its uniqueness at a particular time, the name type PRINCIPAL SHOULD be used. The principal name type SHOULD be used for users, and it might also be used for a unique server. If the name is a unique machine-generated ID that is guaranteed never to be reassigned, then the name type of UID SHOULD be used. (Note that it is generally a bad idea to reassign names of any type since stale entries might remain in access control lists.) If the first component of a name identifies a service and the remaining components identify an instance of the service in a server-specified manner, then the name type of SRV-INST SHOULD be
used. An example of this name type is the Kerberos ticket-granting service whose name has a first component of krbtgt and a second component identifying the realm for which the ticket is valid. If the first component of a name identifies a service and there is a single component following the service name identifying the instance as the host on which the server is running, then the name type SRV-HST SHOULD be used. This type is typically used for Internet services such as telnet and the Berkeley R commands. If the separate components of the host name appear as successive components following the name of the service, then the name type SRV-XHST SHOULD be used. This type might be used to identify servers on hosts with X.500 names, where the slash (/) might otherwise be ambiguous. A name type of NT-X500-PRINCIPAL SHOULD be used when a name from an X.509 certificate is translated into a Kerberos name. The encoding of the X.509 name as a Kerberos principal shall conform to the encoding rules specified in RFC 2253. A name type of SMTP allows a name to be of a form that resembles an SMTP email name. This name, including an "@" and a domain name, is used as the one component of the principal name. A name type of UNKNOWN SHOULD be used when the form of the name is not known. When comparing names, a name of type UNKNOWN will match principals authenticated with names of any type. A principal authenticated with a name of type UNKNOWN, however, will only match other names of type UNKNOWN. Names of any type with an initial component of 'krbtgt' are reserved for the Kerberos ticket-granting service. See Section 7.3 for the form of such names.6.2.1. Name of Server Principals
The principal identifier for a server on a host will generally be composed of two parts: (1) the realm of the KDC with which the server is registered, and (2) a two-component name of type NT-SRV-HST, if the host name is an Internet domain name, or a multi-component name of type NT-SRV-XHST, if the name of the host is of a form (such as X.500) that allows slash (/) separators. The first component of the two- or multi-component name will identify the service, and the latter components will identify the host. Where the name of the host is not case sensitive (for example, with Internet domain names) the name of the host MUST be lowercase. If specified by the application protocol for services such as telnet and the Berkeley R commands that run with system privileges, the first component MAY be the string 'host' instead of a service-specific identifier.