Skip to main content

5.5. Client/Server (CS) Message Specifications

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.

Last updated on