5.4. Specifications for the AS and TGS Exchanges
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.