1KDC cookie format 2================= 3 4:rfc:`6113` section 5.2 specifies a pa-data type PA-FX-COOKIE, which 5clients are required to reflect back to the KDC during 6pre-authentication. The MIT krb5 KDC uses the following formats for 7cookies. 8 9 10Trivial cookie (version 0) 11-------------------------- 12 13If there is no pre-authentication mechanism state information to save, 14a trivial cookie containing the value "MIT" is used. A trivial cookie 15is needed to indicate that the conversation can continue. 16 17 18Secure cookie (version 1) 19------------------------- 20 21In release 1.14 and later, a secure cookie can be sent if there is any 22mechanism state to save for the next request. A secure cookie 23contains the concatenation of the following: 24 25* the four bytes "MIT1" 26* a four-byte big-endian kvno value 27* an :rfc:`3961` ciphertext 28 29The ciphertext is encrypted in the cookie key with key usage 30number 513. The cookie key is derived from a key in the local krbtgt 31principal entry for the realm (e.g. ``krbtgt/KRBTEST.COM@KRBTEST.COM`` 32if the request is to the ``KRBTEST.COM`` realm). The first krbtgt key 33for the indicated kvno value is combined with the client principal as 34follows:: 35 36 cookie-key <- random-to-key(PRF+(tgt-key, "COOKIE" | client-princ)) 37 38where **random-to-key** is the :rfc:`3961` random-to-key operation for 39the krbtgt key's encryption type, **PRF+** is defined in :rfc:`6113`, 40and ``|`` denotes concatenation. *client-princ* is the request client 41principal name with realm, marshalled according to :rfc:`1964` section 422.1.1. 43 44The plain text of the encrypted part of a cookie is the DER encoding 45of the following ASN.1 type:: 46 47 SecureCookie ::= SEQUENCE { 48 time INTEGER, 49 data SEQUENCE OF PA-DATA, 50 ... 51 } 52 53The time field represents the cookie creation time; for brevity, it is 54encoded as an integer giving the POSIX timestamp rather than as an 55ASN.1 GeneralizedTime value. The data field contains one element for 56each pre-authentication type which requires saved state. For 57mechanisms which have separate request and reply types, the request 58type is used; this allows the KDC to determine whether a cookie is 59relevant to a request by comparing the request pa-data types to the 60cookie data types. 61 62SPAKE cookie format (version 1) 63------------------------------- 64 65Inside the SecureCookie wrapper, a data value of type 151 contains 66state for SPAKE pre-authentication. This data is the concatenation of 67the following: 68 69* a two-byte big-endian version number with the value 1 70* a two-byte big-endian stage number 71* a four-byte big-endian group number 72* a four-byte big-endian length and data for the SPAKE value 73* a four-byte big-endian length and data for the transcript hash 74* zero or more second factor records, each consisting of: 75 - a four-byte big-endian second-factor type 76 - a four-byte big-endian length and data 77 78The stage value is 0 if the cookie was sent with a challenge message. 79Otherwise it is 1 for the first encdata message sent by the KDC during 80an exchange, 2 for the second, etc.. 81 82The group value indicates the group number used in the SPAKE challenge. 83 84For a stage-0 cookie, the SPAKE value is the KDC private key, 85represented in the scalar marshalling form of the group. For other 86cookies, the SPAKE value is the SPAKE result K, represented in the 87group element marshalling form. 88 89For a stage-0 cookie, the transcript hash is the intermediate hash 90after updating with the client support message (if one was sent) and 91challenge. For other cookies it is the final hash. 92 93For a stage-0 cookie, there may be any number of second-factor 94records, including none; a second-factor type need not create a state 95field if it does not need one, and no record is created for SF-NONE. 96For other cookies, there must be exactly one second-factor record 97corresponding to the factor type chosen by the client. 98