KDC cookie format

RFC 6113 section 5.2 specifies a pa-data type PA-FX-COOKIE, which clients are required to reflect back to the KDC during pre-authentication. The MIT krb5 KDC uses the following formats for cookies.

Trivial cookie (version 0)

If there is no pre-authentication mechanism state information to save, a trivial cookie containing the value “MIT” is used. A trivial cookie is needed to indicate that the conversation can continue.

Secure cookie (version 1)

In release 1.14 and later, a secure cookie can be sent if there is any mechanism state to save for the next request. A secure cookie contains the concatenation of the following:

• the four bytes “MIT1”

• a four-byte big-endian kvno value

• an RFC 3961 ciphertext

The ciphertext is encrypted in the cookie key with key usage number 513. The cookie key is derived from a key in the local krbtgt principal entry for the realm (e.g. krbtgt/KRBTEST.COM@KRBTEST.COM if the request is to the KRBTEST.COM realm). The first krbtgt key for the indicated kvno value is combined with the client principal as follows:

cookie-key <- random-to-key(PRF+(tgt-key, "COOKIE" | client-princ))

where random-to-key is the RFC 3961 random-to-key operation for the krbtgt key’s encryption type, PRF+ is defined in RFC 6113, and | denotes concatenation. client-princ is the request client principal name with realm, marshalled according to RFC 1964 section 2.1.1.

The plain text of the encrypted part of a cookie is the DER encoding of the following ASN.1 type:

SecureCookie ::= SEQUENCE {
    time     INTEGER,
    data     SEQUENCE OF PA-DATA,
    ...
}

The time field represents the cookie creation time; for brevity, it is encoded as an integer giving the POSIX timestamp rather than as an ASN.1 GeneralizedTime value. The data field contains one element for each pre-authentication type which requires saved state. For mechanisms which have separate request and reply types, the request type is used; this allows the KDC to determine whether a cookie is relevant to a request by comparing the request pa-data types to the cookie data types.

SPAKE cookie format (version 1)

Inside the SecureCookie wrapper, a data value of type 151 contains state for SPAKE pre-authentication. This data is the concatenation of the following:

• a two-byte big-endian version number with the value 1

• a two-byte big-endian stage number

• a four-byte big-endian group number

• a four-byte big-endian length and data for the SPAKE value

• a four-byte big-endian length and data for the transcript hash

• zero or more second factor records, each consisting of: - a four-byte big-endian second-factor type - a four-byte big-endian length and data

The stage value is 0 if the cookie was sent with a challenge message. Otherwise it is 1 for the first encdata message sent by the KDC during an exchange, 2 for the second, etc..

The group value indicates the group number used in the SPAKE challenge.

For a stage-0 cookie, the SPAKE value is the KDC private key, represented in the scalar marshalling form of the group. For other cookies, the SPAKE value is the SPAKE result K, represented in the group element marshalling form.

For a stage-0 cookie, the transcript hash is the intermediate hash after updating with the client support message (if one was sent) and challenge. For other cookies it is the final hash.

For a stage-0 cookie, there may be any number of second-factor records, including none; a second-factor type need not create a state field if it does not need one, and no record is created for SF-NONE. For other cookies, there must be exactly one second-factor record corresponding to the factor type chosen by the client.