From: Sam Hartman Date: Sat, 21 Oct 2006 20:12:52 +0000 (+0000) Subject: Update protocol rfcs to the versions we actually implement X-Git-Tag: krb5-1.6-alpha1~32 X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=c1c08a16cde35a876a8c7fd36470cc7a1f2536c3;p=krb5.git Update protocol rfcs to the versions we actually implement git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@18730 dc483132-0cff-0310-8789-dd5450dbe970 --- diff --git a/doc/krb5-protocol/3-des.txt b/doc/krb5-protocol/3-des.txt deleted file mode 100644 index ce6484547..000000000 --- a/doc/krb5-protocol/3-des.txt +++ /dev/null @@ -1,81 +0,0 @@ -For inclusion into RFC 1510 ---------------------------- -The assigned encryption type designating the use of triple DES is 5. - -The assigned checksum type designating the use of encrypting and MD5 -checksum with triple DES keys is 9. - -Triple DES is implemented using three DES keys. An Electronic CodeBook -encryption (3-DES ECB) is done by doing a DES ECB encryption of an eight -octet data block with the first DES key, performing a DES ECB decryption -of the resulting data block with the second key and performing a DES ECB -encryption of the result with the third key. - -The encryption of a data stream in Cipher Block Chaining mode is -accomplished by eXclusive-ORing each eight-octet data block with the -cipher computed from the previous data block, and then performing a -3-DES ECB encryption. The first data block is eXclusive-ORed with an -initial vector, which is commonly zero prior to performing the 3-DES -ECB. - -The string-to-key algorithm that is used for converting a user's -password into a 3-DES key is a one-way function, evenly distributing the -user's input in the resulting key. The user's input is appended with -the salt information (typically the realm name), and 168-folded to -produce three DES keys sans parity. The 168 bits are then expanded to -include odd parity, for use within the DES routines. If any of the keys -are weak or semi-weak, they are strengthened by eXclusive-ORing the -questionable key with the constant 00000000000000F0. The three DES keys -are then used to encrypt themselves in 3-DES CBC mode with a zero -initial vector. This result is once again encrypted using the same keys -and key schedule and an initial vector of the last eight octets. The -result is then parity adjusted. If the final result yields weak or -semi-weak keys, they are also strengthened in the same manner as the -input keys. - -The n-fold operation used by the string-to-key algorithm -replicates the input bit array X until its length is the least common -multiple of n bits and the length of X. Before each replication, the -input is circularly rotated to the right by 13 bit positions. The -successive n-bit chunks of the resulting bit array are then added -together with end-around carry to yield a n-bit result. The first bit -position in the arrays is treated as the most significant bit. - - - -Glossary --------- -n-fold - To n-fold a bit array X into n bits, replicate the input value to a length - that is the least common multiple of n bits and the length of X. Before - each successive repetition, circularly rotate the input X to the right by - 13 bit positions. The successive n-bit chunks are added together (where - the first bit is the most significant bit) with end-around carry (that is, - adding the carry result from the most significant bits to the least - significant bits) to yield a n-bit result. - -Triple-DES ECB mode: - - Three DES keys are used in turn to perform a DES ECB encryption of an - eight-octet data block with the first key, followed by a DES ECB - decryption of the resulting data block with the second key, followed - by a DES ECB encryption of the resulting data block with the last key. - -Triple-DES CBC mode: - An input data stream is padded on the right by zeroes to an eight-octet - boundary. The first eight octet block is eXclusive-ORed with an initial - vector eight-octet block. This result is triple-DES ECB encrypted with - three DES keys. Subsequent eight-octet data blocks are eXclusive-ORed - with the cipher text produced from the 3-DES ECB encryption of the previous - block and then the data block is 3-DES ECB encrypted with the same DES keys. - -Triple-DES String to key computation: - The input string (appended with any salt data) is 168-folded into a 21 octet - (168 bit) string. Each successive set of 7 octets is treated as a DES key - sans parity. The DES keys are then adjusted to include parity by computing - a parity bit for each successive seven bits to form eight octets. - The resulting DES keys including parity are then used to encrypt themselves - using Triple-DES CBC encryption with a zero initial vector. The result - is then adjusted for parity to produce three valid DES keys. Each key is - checked for weakness, and if it is determined to be weak or semi-weak, the - first octet of each weak key is eXclusive-ORed with the value 0xF0. diff --git a/doc/krb5-protocol/draft-jaganathan-rc4-hmac-03.txt b/doc/krb5-protocol/draft-jaganathan-rc4-hmac-03.txt new file mode 100755 index 000000000..1304ae2bc --- /dev/null +++ b/doc/krb5-protocol/draft-jaganathan-rc4-hmac-03.txt @@ -0,0 +1,1013 @@ + + + +Internet Engineering Task Force K. Jaganathan +Internet-Draft L. Zhu +Intended status: Informational J. Brezak +Expires: January 31, 2007 Microsoft Corporation + July 30, 2006 + + + The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows + draft-jaganathan-rc4-hmac-03.txt + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on January 31, 2007. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + The Microsoft Windows 2000 implementation of Kerberos introduces a + new encryption type based on the RC4 encryption algorithm and using + an MD5 HMAC for checksum. This is offered as an alternative to using + the existing DES based encryption types. + + The RC4-HMAC encryption types are used to ease upgrade of existing + Windows NT environments, provide strong crypto (128-bit key lengths), + + + +Jaganathan, et al. Expires January 31, 2007 [Page 1] + +Internet-Draft RC4-HMAC July 2006 + + + and provide exportable (meet United States government export + restriction requirements) encryption. This document describes the + implementation of those encryption types. + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Key Generation . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Basic Operations . . . . . . . . . . . . . . . . . . . . . . . 4 + 4. Checksum Types . . . . . . . . . . . . . . . . . . . . . . . . 6 + 5. Encryption Types . . . . . . . . . . . . . . . . . . . . . . . 6 + 6. Key Strength Negotiation . . . . . . . . . . . . . . . . . . . 8 + 7. GSSAPI Kerberos V5 Mechanism Type . . . . . . . . . . . . . . 8 + 7.1. Mechanism Specific Changes . . . . . . . . . . . . . . . . 8 + 7.2. GSSAPI MIC Semantics . . . . . . . . . . . . . . . . . . . 10 + 7.3. GSSAPI WRAP Semantics . . . . . . . . . . . . . . . . . . 12 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 + Intellectual Property and Copyright Statements . . . . . . . . . . 18 + + + + + + + + + + + + + + + + + + + + + + + + + + +Jaganathan, et al. Expires January 31, 2007 [Page 2] + +Internet-Draft RC4-HMAC July 2006 + + +1. Introduction + + The Microsoft Windows 2000 implementation of Kerberos contains new + encryption and checksum types for two reasons: for export reasons + early in the development process, 56 bit DES encryption could not be + exported, and because upon upgrade from Windows NT 4.0 to Windows + 2000, accounts will not have the appropriate DES keying material to + do the standard DES encryption. Furthermore, 3DES is not available + for export, and there was a desire to use a single flavor of + encryption in the product for both US and international products. + + As a result, there are two new encryption types and one new checksum + type introduced in Microsoft Windows 2000. + + Note that these cryptosystems aren't intended to be complete, + general-purpose Kerberos encryption or checksum systems as defined in + [RFC3961]: there is no one-one mapping between the operations in this + documents and the primitives described in [RFC3961]. + + +2. Key Generation + + On upgrade from existing Windows NT domains, the user accounts would + not have a DES based key available to enable the use of DES base + encryption types specified in [RFC4120] [RFC3961]. The key used for + RC4-HMAC is the same as the existing Windows NT key (NT Password + Hash) for compatibility reasons. Once the account password is + changed, the DES based keys are created and maintained. Once the DES + keys are available DES based encryption types can be used with + Kerberos. + + The RC4-HMAC String to key function is defined as follow: + + String2Key(password) + + K = MD4(UNICODE(password)) + + The RC4-HMAC keys are generated by using the Windows UNICODE version + of the password. Each Windows UNICODE character is encoded in + little-endian format of 2 octets each. Then performing an MD4 + [RFC1320] hash operation on just the UNICODE characters of the + password (not including the terminating zero octets). + + For an account with a password of "foo", this String2Key("foo") will + return: + + 0xac, 0x8e, 0x65, 0x7f, 0x83, 0xdf, 0x82, 0xbe, + 0xea, 0x5d, 0x43, 0xbd, 0xaf, 0x78, 0x00, 0xcc + + + +Jaganathan, et al. Expires January 31, 2007 [Page 3] + +Internet-Draft RC4-HMAC July 2006 + + +3. Basic Operations + + The MD5 HMAC function is defined in [RFC2104]. It is used in this + encryption type for checksum operations. Refer to [RFC2104] for + details on its operation. In this document this function is referred + to as HMAC(Key, Data) returning the checksum using the specified key + on the data. + + The basic MD5 hash operation is used in this encryption type and + defined in [RFC1321]. In this document this function is referred to + as MD5(Data) returning the checksum of the data. + + RC4 is a stream cipher licensed by RSA Data Security . In this + document the function is referred to as RC4(Key, Data) returning the + encrypted data using the specified key on the data. + + These encryption types use key derivation. With each message, the + message type (T) is used as a component of the keying material. This + table summarizes the different key derivation values used in the + various operations. Note that these differ from the key derivations + used in other Kerberos encryption types. T = the message type, + encoded as a little-endian four byte integer. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jaganathan, et al. Expires January 31, 2007 [Page 4] + +Internet-Draft RC4-HMAC July 2006 + + + 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with + the client key (T=1) + 2. AS-REP Ticket and TGS-REP Ticket (includes TGS session key + or application session key), encrypted with the service key + (T=2) + 3. AS-REP encrypted part (includes TGS session key or + application session key), encrypted with the client key (T=8) + 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the + TGS session key (T=4) + 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the + TGS authenticator subkey (T=5) + 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, + keyed with the TGS session key (T=6) + 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes + TGS authenticator subkey), encrypted with the TGS session key + T=7) + 8. TGS-REP encrypted part (includes application session key), + encrypted with the TGS session key (T=8) + 9. TGS-REP encrypted part (includes application session key), + encrypted with the TGS authenticator subkey (T=8) + 10. AP-REQ Authenticator cksum, keyed with the application + session key (T=10) + 11. AP-REQ Authenticator (includes application authenticator + subkey), encrypted with the application session key (T=11) + 12. AP-REP encrypted part (includes application session + subkey), encrypted with the application session key (T=12) + 13. KRB-PRIV encrypted part, encrypted with a key chosen by + the application. Also for data encrypted with GSS Wrap (T=13) + 14. KRB-CRED encrypted part, encrypted with a key chosen by + the application (T=14) + 15. KRB-SAFE cksum, keyed with a key chosen by the + application. Also for data signed in GSS MIC (T=15) + + Relative to RFC-1964 key uses: + + T = 0 in the generation of sequence number for the MIC token + T = 0 in the generation of sequence number for the WRAP token + T = 0 in the generation of encrypted data for the WRAPPED token + + All strings in this document are ASCII unless otherwise specified. + The lengths of ASCII encoded character strings include the trailing + terminator character (0). The concat(a,b,c,...) function will return + the logical concatenation (left to right) of the values of the + arguments. The nonce(n) function returns a pseudo-random number of + "n" octets. + + + + + + +Jaganathan, et al. Expires January 31, 2007 [Page 5] + +Internet-Draft RC4-HMAC July 2006 + + +4. Checksum Types + + There is one checksum type used in this encryption type. The + Kerberos constant for this type is: + + #define KERB_CHECKSUM_HMAC_MD5 (-138) + + The function is defined as follows: + + K - is the Key + T - the message type, encoded as a little-endian four byte integer + + CHKSUM(K, T, data) + + Ksign = HMAC(K, "signaturekey") //includes zero octet at end + tmp = MD5(concat(T, data)) + CHKSUM = HMAC(Ksign, tmp) + + +5. Encryption Types + + There are two encryption types used in these encryption types. The + Kerberos constants for these types are: + + #define KERB_ETYPE_RC4_HMAC 23 + #define KERB_ETYPE_RC4_HMAC_EXP 24 + + The basic encryption function is defined as follow: + + T = the message type, encoded as a little-endian four byte integer. + + OCTET L40[14] = "fortybits"; + + The header field on the encrypted data in KDC messages is: + + typedef struct _RC4_MDx_HEADER { + OCTET Checksum[16]; + OCTET Confounder[8]; + } RC4_MDx_HEADER, *PRC4_MDx_HEADER; + + + ENCRYPT (K, export, T, data) + { + struct EDATA { + struct HEADER { + OCTET Checksum[16]; + OCTET Confounder[8]; + } Header; + + + +Jaganathan, et al. Expires January 31, 2007 [Page 6] + +Internet-Draft RC4-HMAC July 2006 + + + OCTET Data[0]; + } edata; + + if (export){ + *((DWORD *)(L40+10)) = T; + HMAC (K, L40, 10 + 4, K1); + } + else + { + HMAC (K, &T, 4, K1); + } + memcpy (K2, K1, 16); + if (export) memset (K1+7, 0xAB, 9); + + nonce (edata.Confounder, 8); + memcpy (edata.Data, data); + + edata.Checksum = HMAC (K2, edata); + K3 = HMAC (K1, edata.Checksum); + + RC4 (K3, edata.Confounder); + RC4 (K3, data.Data); + } + + DECRYPT (K, export, T, edata) + { + // edata looks like + struct EDATA { + struct HEADER { + OCTET Checksum[16]; + OCTET Confounder[8]; + } Header; + OCTET Data[0]; + } edata; + + if (export){ + *((DWORD *)(L40+10)) = T; + HMAC (K, L40, 14, K1); + } + else + { + HMAC (K, &T, 4, K1); + } + memcpy (K2, K1, 16); + if (export) memset (K1+7, 0xAB, 9); + + K3 = HMAC (K1, edata.Checksum); + + + + +Jaganathan, et al. Expires January 31, 2007 [Page 7] + +Internet-Draft RC4-HMAC July 2006 + + + RC4 (K3, edata.Confounder); + RC4 (K3, edata.Data); + + + // verify generated and received checksums + checksum = HMAC (K2, concat(edata.Confounder, edata.Data)); + if (checksum != edata.Checksum) + printf("CHECKSUM ERROR !!!!!!\n"); + } + + The KDC message is encrypted using the ENCRYPT function not including + the Checksum in the RC4_MDx_HEADER. + + The character constant "fortybits" evolved from the time when a 40- + bit key length was all that was exportable from the United States. + It is now used to recognize that the key length is of "exportable" + length. In this description, the key size is actually 56-bits. + + The pseudo-random operation [RFC3961] for both enctypes above is + defined as follows: + + pseudo-random(K, S) = HMAC-SHA1(K, S) + + where K is the protocol key and S is the input octet string. HMAC- + SHA1 is defined in [RFC2104] and the output of HMAC-SHA1 is the 20- + octet digest. + + +6. Key Strength Negotiation + + A Kerberos client and server can negotiate over key length if they + are using mutual authentication. If the client is unable to perform + full strength encryption, it may propose a key in the "subkey" field + of the authenticator, using a weaker encryption type. The server + must then either return the same key or suggest its own key in the + subkey field of the AP reply message. The key used to encrypt data + is derived from the key returned by the server. If the client is + able to perform strong encryption but the server is not, it may + propose a subkey in the AP reply without first being sent a subkey in + the authenticator. + + +7. GSSAPI Kerberos V5 Mechanism Type + +7.1. Mechanism Specific Changes + + The GSSAPI per-message tokens also require new checksum and + encryption types. The GSS-API per-message tokens are adapted to + + + +Jaganathan, et al. Expires January 31, 2007 [Page 8] + +Internet-Draft RC4-HMAC July 2006 + + + support these new encryption types. See [RFC1964] Section 1.2.2. + + The only support quality of protection is: + + #define GSS_KRB5_INTEG_C_QOP_DEFAULT 0x0 + + When using this RC4 based encryption type, the sequence number is + always sent in big-endian rather than little-endian order. + + The Windows 2000 implementation also defines new GSSAPI flags in the + initial token passed when initializing a security context. These + flags are passed in the checksum field of the authenticator. See + [RFC1964] Section 1.1.1. + + GSS_C_DCE_STYLE - This flag was added for use with Microsoft's + implementation of DCE RPC, which initially expected three legs of + authentication. Setting this flag causes an extra AP reply to be + sent from the client back to the server after receiving the server's + AP reply. In addition, the context negotiation tokens do not have + GSSAPI per message tokens - they are raw AP messages that do not + include object identifiers. + + #define GSS_C_DCE_STYLE 0x1000 + + GSS_C_IDENTIFY_FLAG - This flag allows the client to indicate to the + server that it should only allow the server application to identify + the client by name and ID, but not to impersonate the client. + + #define GSS_C_IDENTIFY_FLAG 0x2000 + + GSS_C_EXTENDED_ERROR_FLAG - Setting this flag indicates that the + client wants to be informed of extended error information. In + particular, Windows 2000 status codes may be returned in the data + field of a Kerberos error message. This allows the client to + understand a server failure more precisely. In addition, the server + may return errors to the client that are normally handled at the + application layer in the server, in order to let the client try to + recover. After receiving an error message, the client may attempt to + resubmit an AP request. + + #define GSS_C_EXTENDED_ERROR_FLAG 0x4000 + + These flags are only used if a client is aware of these conventions + when using the SSPI on the Windows platform; they are not generally + used by default. + + When NetBIOS addresses are used in the GSSAPI, they are identified by + the GSS_C_AF_NETBIOS value. This value is defined as: + + + +Jaganathan, et al. Expires January 31, 2007 [Page 9] + +Internet-Draft RC4-HMAC July 2006 + + + #define GSS_C_AF_NETBIOS 0x14 + + NetBios addresses are 16-octet addresses typically composed of 1 to + 15 characters, trailing blank (ASCII char 20) filled, with a 16-th + octet of 0x0. + +7.2. GSSAPI MIC Semantics + + The GSSAPI checksum type and algorithm is defined in Section 5. Only + the first 8 octets of the checksum are used. The resulting checksum + is stored in the SGN_CKSUM field . See [RFC1964] Section 1.2 for + GSS_GetMIC() and GSS_Wrap(conf_flag=FALSE). + + The GSS_GetMIC token has the following format: + + Byte no Name Description + 0..1 TOK_ID Identification field. + Tokens emitted by GSS_GetMIC() contain + the hex value 01 01 in this field. + 2..3 SGN_ALG Integrity algorithm indicator. + 11 00 - HMAC + 4..7 Filler Contains ff ff ff ff + 8..15 SND_SEQ Sequence number field. + 16..23 SGN_CKSUM Checksum of "to-be-signed data", + calculated according to algorithm + specified in SGN_ALG field. + + The MIC mechanism used for GSS MIC based messages is as follow: + + GetMIC(Kss, direction, export, seq_num, data) + { + struct Token { + struct Header { + OCTET TOK_ID[2]; + OCTET SGN_ALG[2]; + OCTET Filler[4]; + }; + OCTET SND_SEQ[8]; + OCTET SGN_CKSUM[8]; + } Token; + + + Token.TOK_ID = 01 01; + Token.SGN_SLG = 11 00; + Token.Filler = ff ff ff ff; + + // Create the sequence number + + + + +Jaganathan, et al. Expires January 31, 2007 [Page 10] + +Internet-Draft RC4-HMAC July 2006 + + + if (direction == sender_is_initiator) + { + memset(Token.SEND_SEQ+4, 0xff, 4) + } + else if (direction == sender_is_acceptor) + { + memset(Token.SEND_SEQ+4, 0, 4) + } + Token.SEND_SEQ[0] = (seq_num & 0xff000000) >> 24; + Token.SEND_SEQ[1] = (seq_num & 0x00ff0000) >> 16; + Token.SEND_SEQ[2] = (seq_num & 0x0000ff00) >> 8; + Token.SEND_SEQ[3] = (seq_num & 0x000000ff); + + // Derive signing key from session key + + Ksign = HMAC(Kss, "signaturekey"); + // length includes terminating null + + // Generate checksum of message - SGN_CKSUM + // Key derivation salt = 15 + + Sgn_Cksum = MD5((int32)15, Token.Header, data); + + // Save first 8 octets of HMAC Sgn_Cksum + + Sgn_Cksum = HMAC(Ksign, Sgn_Cksum); + memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8); + + // Encrypt the sequence number + + // Derive encryption key for the sequence number + // Key derivation salt = 0 + + if (exportable) + { + Kseq = HMAC(Kss, "fortybits", (int32)0); + // len includes terminating null + memset(Kseq+7, 0xab, 7) + } + else + { + Kseq = HMAC(Kss, (int32)0); + } + Kseq = HMAC(Kseq, Token.SGN_CKSUM); + + // Encrypt the sequence number + + RC4(Kseq, Token.SND_SEQ); + + + +Jaganathan, et al. Expires January 31, 2007 [Page 11] + +Internet-Draft RC4-HMAC July 2006 + + + } + +7.3. GSSAPI WRAP Semantics + + There are two encryption keys for GSSAPI message tokens, one that is + 128 bits in strength, and one that is 56 bits in strength as defined + in Section 6. + + All padding is rounded up to 1 byte. One byte is needed to say that + there is 1 byte of padding. The DES based mechanism type uses 8 byte + padding. See [RFC1964] Section 1.2.2.3. + + The RC4-HMAC GSS_Wrap() token has the following format: + + + Byte no Name Description + 0..1 TOK_ID Identification field. + Tokens emitted by GSS_Wrap() contain + the hex value 02 01 in this field. + 2..3 SGN_ALG Checksum algorithm indicator. + 11 00 - HMAC + 4..5 SEAL_ALG ff ff - none + 00 00 - DES-CBC + 10 00 - RC4 + 6..7 Filler Contains ff ff + 8..15 SND_SEQ Encrypted sequence number field. + 16..23 SGN_CKSUM Checksum of plaintext padded data, + calculated according to algorithm + specified in SGN_ALG field. + 24..31 Confounder Random confounder + 32..last Data encrypted or plaintext padded data + + The encryption mechanism used for GSS wrap based messages is as + follow: + + + WRAP(Kss, encrypt, direction, export, seq_num, data) + { + struct Token { // 32 octets + struct Header { + OCTET TOK_ID[2]; + OCTET SGN_ALG[2]; + OCTET SEAL_ALG[2]; + OCTET Filler[2]; + }; + OCTET SND_SEQ[8]; + OCTET SGN_CKSUM[8]; + OCTET Confounder[8]; + + + +Jaganathan, et al. Expires January 31, 2007 [Page 12] + +Internet-Draft RC4-HMAC July 2006 + + + } Token; + + + Token.TOK_ID = 02 01; + Token.SGN_SLG = 11 00; + Token.SEAL_ALG = (no_encrypt)? ff ff : 10 00; + Token.Filler = ff ff; + + // Create the sequence number + + if (direction == sender_is_initiator) + { + memset(&Token.SEND_SEQ[4], 0xff, 4) + } + else if (direction == sender_is_acceptor) + { + memset(&Token.SEND_SEQ[4], 0, 4) + } + Token.SEND_SEQ[0] = (seq_num & 0xff000000) >> 24; + Token.SEND_SEQ[1] = (seq_num & 0x00ff0000) >> 16; + Token.SEND_SEQ[2] = (seq_num & 0x0000ff00) >> 8; + Token.SEND_SEQ[3] = (seq_num & 0x000000ff); + + // Generate random confounder + + nonce(&Token.Confounder, 8); + + // Derive signing key from session key + + Ksign = HMAC(Kss, "signaturekey"); + + // Generate checksum of message - + // SGN_CKSUM + Token.Confounder + // Key derivation salt = 15 + + Sgn_Cksum = MD5((int32)15, Token.Header, + Token.Confounder); + + // Derive encryption key for data + // Key derivation salt = 0 + + for (i = 0; i < 16; i++) Klocal[i] = Kss[i] ^ 0xF0; + // XOR + if (exportable) + { + Kcrypt = HMAC(Klocal, "fortybits", (int32)0); + // len includes terminating null + memset(Kcrypt+7, 0xab, 7); + + + +Jaganathan, et al. Expires January 31, 2007 [Page 13] + +Internet-Draft RC4-HMAC July 2006 + + + } + else + { + Kcrypt = HMAC(Klocal, (int32)0); + } + + // new encryption key salted with seq + + Kcrypt = HMAC(Kcrypt, (int32)seq); + + // Encrypt confounder (if encrypting) + + if (encrypt) + RC4(Kcrypt, Token.Confounder); + + // Sum the data buffer + + Sgn_Cksum += MD5(data); // Append to checksum + + // Encrypt the data (if encrypting) + + if (encrypt) + RC4(Kcrypt, data); + + // Save first 8 octets of HMAC Sgn_Cksum + + Sgn_Cksum = HMAC(Ksign, Sgn_Cksum); + memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8); + + // Derive encryption key for the sequence number + // Key derivation salt = 0 + + if (exportable) + { + Kseq = HMAC(Kss, "fortybits", (int32)0); + // len includes terminating null + memset(Kseq+7, 0xab, 7) + } + else + { + Kseq = HMAC(Kss, (int32)0); + } + Kseq = HMAC(Kseq, Token.SGN_CKSUM); + + // Encrypt the sequence number + + RC4(Kseq, Token.SND_SEQ); + + + + +Jaganathan, et al. Expires January 31, 2007 [Page 14] + +Internet-Draft RC4-HMAC July 2006 + + + // Encrypted message = Token + Data + } + + The character constant "fortybits" evolved from the time when a 40- + bit key length was all that was exportable from the United States. + It is now used to recognize that the key length is of "exportable" + length. In this description, the key size is actually 56-bits. + + +8. Security Considerations + + Care must be taken in implementing these encryption types because + they use a stream cipher. If a different IV is not used in each + direction when using a session key, the encryption is weak. By using + the sequence number as an IV, this is avoided. + + There are two classes of attack on RC4 described in [MIRONOV]. + Strong distinguishers distinguish an RC4 keystream from randomness at + the start of the stream. Weak distinguishers can operate on any part + of the keystream, and the best ones, described in [FMcG] and + [MANTIN05], can exploit data from multiple, different keystreams. A + consequence of these is that encrypting the same data (for instance, + a password) sufficiently many times in separate RC4 keystreams can be + sufficient to leak information to an adversary. The encryption types + defined in this document defend against these by constructing a new + key stream for every message. However, it is RECOMMENDED not to use + the RC4 encryption types defined in this document for high-volume + connections. + + Weaknesses in MD4 [BOER91] were demonstrated by Den Boer and + Bosselaers in 1991. In August 2004, Xiaoyun Wang et al reported MD4 + collisions generated using hand calculation [WANG04]. + Implementations based on Wang's algorithm can find collisions in real + time. However, the intended usage of MD4 described in this document + does not rely on the collision-resistant property of MD4. + Futhermore, MD4 is always used in the context of a keyed hash in this + document. Although no evidence has suggested keyed MD4 hashes are + vulnerable to collision-based attacks, no study has directly proved + that the HMAC-MD4 is secure: the existing study simply assumed that + the hash function used in HMAC is collision proof. It is thus + RECOMMENDED not to use the RC4 encryption types defined in this + document if alternative stronger encryption types, such as aes256- + cts-hmac-sha1-96 [RFC3962], are available. + + +9. Acknowledgements + + The authors wish to thank Sam Hartman, Ken Raeburn and Qunli Li for + + + +Jaganathan, et al. Expires January 31, 2007 [Page 15] + +Internet-Draft RC4-HMAC July 2006 + + + their insightful comments. + + +10. IANA Considerations + + This document has no actions for IANA. + + +11. References + +11.1. Normative References + + [RFC1320] Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320, + April 1992. + + [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + April 1992. + + [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", + RFC 1964, June 1996. + + [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication", RFC 2104, + February 1997. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for + Kerberos 5", RFC 3961, February 2005. + + [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) + Encryption for Kerberos 5", RFC 3962, February 2005. + + [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The + Kerberos Network Authentication Service (V5)", RFC 4120, + July 2005. + +11.2. Informative References + + +Jaganathan, et al. Expires January 31, 2007 [Page 16] + +Internet-Draft RC4-HMAC July 2006 + + + [BOER91] Boer, D. and A. Bosselaers, "An Attack on the Last Two + Rounds of MD4", + http://citeseer.ist.psu.edu/denboer91attack.html, 1991. + + [FMcG] Fluhrer, S. and D. McGrew, "Statistical Analysis of the + Alleged RC4 Keystream Generator", Fast Software + Encryption: 7th International Workshop, FSE 2000, April + 2000, . + + [MANTIN01] Mantin, I., "Analysis of the Stream Cipher RC4", M.Sc. + Thesis, Weizmann Institute of Science, 2001, . + + [MIRONOV] Mironov, I., "(Not So) Random Shuffles of RC4", Advances + in Cryptology -- CRYPTO 2002: 22nd Annual International + Cryptology Conference, August 2002, + . + + [MANTIN05] Mantin, I., "Predicting and Distinguishing Attacks on RC4 + Keystream Generator", Advances in Cryptology -- EUROCRYPT + 2005: 24th Annual International Conference on the Theory + and Applications of Cryptographic Techniques, May 2005. + + [WANG04] Wang, X., Lai, X., Feng, D., Chen H., and X. Yu, + "Cryptanalysis of Hash functions MD4 and RIPEMD", + http://www.infosec.sdu.edu.cn/paper/md4-ripemd-attck.pdf, + Augest, 2004. + + + +Authors' Addresses + + Karthik Jaganathan + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + US + + Email: karthikj@microsoft.com + + + Larry Zhu + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + US + + Email: lzhu@microsoft.com + + + John Brezak + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + US + + Email: jbrezak@microsoft.com + + + + + + + + +Jaganathan, et al. Expires January 31, 2007 [Page 17] + +Internet-Draft RC4-HMAC July 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Acknowledgment + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + +Jaganathan, et al. Expires January 31, 2007 [Page 18] + + diff --git a/doc/krb5-protocol/rfc1510.errata b/doc/krb5-protocol/rfc1510.errata deleted file mode 100644 index 602325b27..000000000 --- a/doc/krb5-protocol/rfc1510.errata +++ /dev/null @@ -1,105 +0,0 @@ ----rfc1510.eratta---as of Auguest 10, 1994--- - -1. [19940312] The following lines describes corrections to pseudocode - in rfc1510 as of March 12, 1994. - - A: Throughout the pseudocode (section A), flags.ALLOW-POSTDATE should be - replaced by flags.MAY-POSTDATE. kdc-options.ALLOW-POSTDATE is - correct, however. - -A.2: In the processing for the kdc-options.POSTDATE (imperitive), both - the POSTDATED and the INVALID flag should be set. The setting of the - POSTDATE flag was inadvertantly omitted. - - You should change: - - if (req.kdc-options.POSTDATED is set) then - if (against_postdate_policy(req.from)) then - error_out(KDC_ERR_POLICY); - endif - set new_tkt.flags.INVALID; - new_tkt.starttime := req.from; - else - omit new_tkt.starttime; /* treated as authtime when - - To: - if (req.kdc-options.POSTDATED is set) then - if (against_postdate_policy(req.from)) then - error_out(KDC_ERR_POLICY); - endif - set new_tkt.flags.POSTDATED; <**** - set new_tkt.flags.INVALID; - new_tkt.starttime := req.from; - else - omit new_tkt.starttime; /* treated as authtime when - -A.6: In section A.6, all occursences of kdc-options.POSTDATE (imperitive) - should be replaced by kdc-options.ALLOW-POSTDATE and tgt.flags.POSTDATE - should be replaced by tgt.flags.MAY-POSTDATE. - - Note that instances of POSTDATED (adjective) are correct. - - ---- -2. [19940614] Processing of the etype filed, described in 3.1.3, and 5.4.1. - -If a there are multiple encryption keys registered for a client in the -Kerberos database (or if the key registered supports multiple -encryption types; e.g. DES-CBC-CRC and DES-CBC-MD5), then the etype -field from the AS request is used by the KDC to select the encryption -method to be used for encrypting the response to the client. If there -is more than one supported, strong encryption type in the etype list, -the first valid etype for which an encryption key is available is -used. The encryption method used to respond to a TGS request is taken -from the keytype of the session key found in the ticket granting -ticket. - -When the etype field is present in a KDC request, whether an AS or TGS -request, the KDC will attempt to assign the type of the random session -key from the list of methods in the etype field. The KDC will select -the appropriate type using the list of methods provided together with -information from the Kerberos database indicating acceptable -encryption methods for the application server. The KDC will not issue -tickets with a weak session key encryption type. - ---- -3. [19940707] Case of realm names for DNS based realm names, - - The following should appear in section 7.1 before the description - of the four classed of realm names (before "There are presently...") - - Kerberos realm names are case sensitive. Realm names that differ - only in the case of the characters are not equivalent. - - The domain example should be changes from: - domain: host.subdomain.domain (example) - - To: - - domain: ATHENA.MIT.EDU (example) - - The following should be append to the domain name paragraph of - section 7.1 (following "nor slashes (/).") - - Domain names must be converted to upper case when used as realm names. - ---- -4. [19940707] Official name of host is instance for NT-SRV-HST - - Append to paragraph 7.2.1: - - When a host has an official name and one or more aliases, the - official name of the host must be used when constructing the name - of the server principal. - ---- - -5. [19940722] The protocol is standards track - - In the 3rd paragraph of the overview delete: - - ", and are not being submitted for consideration as - an Internet standard at this time" - - as it contradicts the first sentence of the RFC. - diff --git a/doc/krb5-protocol/rfc1510.txt b/doc/krb5-protocol/rfc1510.txt deleted file mode 100644 index bc810cc50..000000000 --- a/doc/krb5-protocol/rfc1510.txt +++ /dev/null @@ -1,6275 +0,0 @@ - - - - - - -Network Working Group J. Kohl -Request for Comments: 1510 Digital Equipment Corporation - C. Neuman - ISI - September 1993 - - - The Kerberos Network Authentication Service (V5) - -Status of this Memo - - This RFC specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" for the standardization state and status - of this protocol. Distribution of this memo is unlimited. - -Abstract - - This document gives an overview and specification of Version 5 of the - protocol for the Kerberos network authentication system. Version 4, - described elsewhere [1,2], is presently in production use at MIT's - Project Athena, and at other Internet sites. - -Overview - - Project Athena, Athena, Athena MUSE, Discuss, Hesiod, Kerberos, - Moira, and Zephyr are trademarks of the Massachusetts Institute of - Technology (MIT). No commercial use of these trademarks may be made - without prior written permission of MIT. - - This RFC describes the concepts and model upon which the Kerberos - network authentication system is based. It also specifies Version 5 - of the Kerberos protocol. - - The motivations, goals, assumptions, and rationale behind most design - decisions are treated cursorily; for Version 4 they are fully - described in the Kerberos portion of the Athena Technical Plan [1]. - The protocols are under review, and are not being submitted for - consideration as an Internet standard at this time. Comments are - encouraged. Requests for addition to an electronic mailing list for - discussion of Kerberos, kerberos@MIT.EDU, may be addressed to - kerberos-request@MIT.EDU. This mailing list is gatewayed onto the - Usenet as the group comp.protocols.kerberos. Requests for further - information, including documents and code availability, may be sent - to info-kerberos@MIT.EDU. - - - - - -Kohl & Neuman [Page 1] - -RFC 1510 Kerberos September 1993 - - -Background - - The Kerberos model is based in part on Needham and Schroeder's - trusted third-party authentication protocol [3] and on modifications - suggested by Denning and Sacco [4]. The original design and - implementation of Kerberos Versions 1 through 4 was the work of two - former Project Athena staff members, Steve Miller of Digital - Equipment Corporation and Clifford Neuman (now at the Information - Sciences Institute of the University of Southern California), along - with Jerome Saltzer, Technical Director of Project Athena, and - Jeffrey Schiller, MIT Campus Network Manager. Many other members of - Project Athena have also contributed to the work on Kerberos. - Version 4 is publicly available, and has seen wide use across the - Internet. - - Version 5 (described in this document) has evolved from Version 4 - based on new requirements and desires for features not available in - Version 4. Details on the differences between Kerberos Versions 4 - and 5 can be found in [5]. - -Table of Contents - - 1. Introduction ....................................... 5 - 1.1. Cross-Realm Operation ............................ 7 - 1.2. Environmental assumptions ........................ 8 - 1.3. Glossary of terms ................................ 9 - 2. Ticket flag uses and requests ...................... 12 - 2.1. Initial and pre-authenticated tickets ............ 12 - 2.2. Invalid tickets .................................. 12 - 2.3. Renewable tickets ................................ 12 - 2.4. Postdated tickets ................................ 13 - 2.5. Proxiable and proxy tickets ...................... 14 - 2.6. Forwardable tickets .............................. 15 - 2.7. Other KDC options ................................ 15 - 3. Message Exchanges .................................. 16 - 3.1. The Authentication Service Exchange .............. 16 - 3.1.1. Generation of KRB_AS_REQ message ............... 17 - 3.1.2. Receipt of KRB_AS_REQ message .................. 17 - 3.1.3. Generation of KRB_AS_REP message ............... 17 - 3.1.4. Generation of KRB_ERROR message ................ 19 - 3.1.5. Receipt of KRB_AS_REP message .................. 19 - 3.1.6. Receipt of KRB_ERROR message ................... 20 - 3.2. The Client/Server Authentication Exchange ........ 20 - 3.2.1. The KRB_AP_REQ message ......................... 20 - 3.2.2. Generation of a KRB_AP_REQ message ............. 20 - 3.2.3. Receipt of KRB_AP_REQ message .................. 21 - 3.2.4. Generation of a KRB_AP_REP message ............. 23 - 3.2.5. Receipt of KRB_AP_REP message .................. 23 - - - -Kohl & Neuman [Page 2] - -RFC 1510 Kerberos September 1993 - - - 3.2.6. Using the encryption key ....................... 24 - 3.3. The Ticket-Granting Service (TGS) Exchange ....... 24 - 3.3.1. Generation of KRB_TGS_REQ message .............. 25 - 3.3.2. Receipt of KRB_TGS_REQ message ................. 26 - 3.3.3. Generation of KRB_TGS_REP message .............. 27 - 3.3.3.1. Encoding the transited field ................. 29 - 3.3.4. Receipt of KRB_TGS_REP message ................. 31 - 3.4. The KRB_SAFE Exchange ............................ 31 - 3.4.1. Generation of a KRB_SAFE message ............... 31 - 3.4.2. Receipt of KRB_SAFE message .................... 32 - 3.5. The KRB_PRIV Exchange ............................ 33 - 3.5.1. Generation of a KRB_PRIV message ............... 33 - 3.5.2. Receipt of KRB_PRIV message .................... 33 - 3.6. The KRB_CRED Exchange ............................ 34 - 3.6.1. Generation of a KRB_CRED message ............... 34 - 3.6.2. Receipt of KRB_CRED message .................... 34 - 4. The Kerberos Database .............................. 35 - 4.1. Database contents ................................ 35 - 4.2. Additional fields ................................ 36 - 4.3. Frequently Changing Fields ....................... 37 - 4.4. Site Constants ................................... 37 - 5. Message Specifications ............................. 38 - 5.1. ASN.1 Distinguished Encoding Representation ...... 38 - 5.2. ASN.1 Base Definitions ........................... 38 - 5.3. Tickets and Authenticators ....................... 42 - 5.3.1. Tickets ........................................ 42 - 5.3.2. Authenticators ................................. 47 - 5.4. Specifications for the AS and TGS exchanges ...... 49 - 5.4.1. KRB_KDC_REQ definition ......................... 49 - 5.4.2. KRB_KDC_REP definition ......................... 56 - 5.5. Client/Server (CS) message specifications ........ 58 - 5.5.1. KRB_AP_REQ definition .......................... 58 - 5.5.2. KRB_AP_REP definition .......................... 60 - 5.5.3. Error message reply ............................ 61 - 5.6. KRB_SAFE message specification ................... 61 - 5.6.1. KRB_SAFE definition ............................ 61 - 5.7. KRB_PRIV message specification ................... 62 - 5.7.1. KRB_PRIV definition ............................ 62 - 5.8. KRB_CRED message specification ................... 63 - 5.8.1. KRB_CRED definition ............................ 63 - 5.9. Error message specification ...................... 65 - 5.9.1. KRB_ERROR definition ........................... 66 - 6. Encryption and Checksum Specifications ............. 67 - 6.1. Encryption Specifications ........................ 68 - 6.2. Encryption Keys .................................. 71 - 6.3. Encryption Systems ............................... 71 - 6.3.1. The NULL Encryption System (null) .............. 71 - 6.3.2. DES in CBC mode with a CRC-32 checksum (descbc-crc)71 - - - -Kohl & Neuman [Page 3] - -RFC 1510 Kerberos September 1993 - - - 6.3.3. DES in CBC mode with an MD4 checksum (descbc-md4) 72 - 6.3.4. DES in CBC mode with an MD5 checksum (descbc-md5) 72 - 6.4. Checksums ........................................ 74 - 6.4.1. The CRC-32 Checksum (crc32) .................... 74 - 6.4.2. The RSA MD4 Checksum (rsa-md4) ................. 75 - 6.4.3. RSA MD4 Cryptographic Checksum Using DES - (rsa-md4-des) ......................................... 75 - 6.4.4. The RSA MD5 Checksum (rsa-md5) ................. 76 - 6.4.5. RSA MD5 Cryptographic Checksum Using DES - (rsa-md5-des) ......................................... 76 - 6.4.6. DES cipher-block chained checksum (des-mac) - 6.4.7. RSA MD4 Cryptographic Checksum Using DES - alternative (rsa-md4-des-k) ........................... 77 - 6.4.8. DES cipher-block chained checksum alternative - (des-mac-k) ........................................... 77 - 7. Naming Constraints ................................. 78 - 7.1. Realm Names ...................................... 77 - 7.2. Principal Names .................................. 79 - 7.2.1. Name of server principals ...................... 80 - 8. Constants and other defined values ................. 80 - 8.1. Host address types ............................... 80 - 8.2. KDC messages ..................................... 81 - 8.2.1. IP transport ................................... 81 - 8.2.2. OSI transport .................................. 82 - 8.2.3. Name of the TGS ................................ 82 - 8.3. Protocol constants and associated values ......... 82 - 9. Interoperability requirements ...................... 86 - 9.1. Specification 1 .................................. 86 - 9.2. Recommended KDC values ........................... 88 - 10. Acknowledgments ................................... 88 - 11. References ........................................ 89 - 12. Security Considerations ........................... 90 - 13. Authors' Addresses ................................ 90 - A. Pseudo-code for protocol processing ................ 91 - A.1. KRB_AS_REQ generation ............................ 91 - A.2. KRB_AS_REQ verification and KRB_AS_REP generation 92 - A.3. KRB_AS_REP verification .......................... 95 - A.4. KRB_AS_REP and KRB_TGS_REP common checks ......... 96 - A.5. KRB_TGS_REQ generation ........................... 97 - A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation 98 - A.7. KRB_TGS_REP verification ......................... 104 - A.8. Authenticator generation ......................... 104 - A.9. KRB_AP_REQ generation ............................ 105 - A.10. KRB_AP_REQ verification ......................... 105 - A.11. KRB_AP_REP generation ........................... 106 - A.12. KRB_AP_REP verification ......................... 107 - A.13. KRB_SAFE generation ............................. 107 - A.14. KRB_SAFE verification ........................... 108 - - - -Kohl & Neuman [Page 4] - -RFC 1510 Kerberos September 1993 - - - A.15. KRB_SAFE and KRB_PRIV common checks ............. 108 - A.16. KRB_PRIV generation ............................. 109 - A.17. KRB_PRIV verification ........................... 110 - A.18. KRB_CRED generation ............................. 110 - A.19. KRB_CRED verification ........................... 111 - A.20. KRB_ERROR generation ............................ 112 - -1. Introduction - - Kerberos provides a means of verifying the identities of principals, - (e.g., a workstation user or a network server) on an open - (unprotected) network. This is accomplished without relying on - authentication by the host operating system, without basing trust on - host addresses, without requiring physical security of all the hosts - on the network, and under the assumption that packets traveling along - the network can be read, modified, and inserted at will. (Note, - however, that many applications use Kerberos' functions only upon the - initiation of a stream-based network connection, and assume the - absence of any "hijackers" who might subvert such a connection. Such - use implicitly trusts the host addresses involved.) Kerberos - performs authentication under these conditions as a trusted third- - party authentication service by using conventional cryptography, - i.e., shared secret key. (shared secret key - Secret and private are - often used interchangeably in the literature. In our usage, it takes - two (or more) to share a secret, thus a shared DES key is a secret - key. Something is only private when no one but its owner knows it. - Thus, in public key cryptosystems, one has a public and a private - key.) - - The authentication process proceeds as follows: A client sends a - request to the authentication server (AS) requesting "credentials" - for a given server. The AS responds with these credentials, - encrypted in the client's key. The credentials consist of 1) a - "ticket" for the server and 2) a temporary encryption key (often - called a "session key"). The client transmits the ticket (which - contains the client's identity and a copy of the session key, all - encrypted in the server's key) to the server. The session key (now - shared by the client and server) is used to authenticate the client, - and may optionally be used to authenticate the server. It may also - be used to encrypt further communication between the two parties or - to exchange a separate sub-session key to be used to encrypt further - communication. - - The implementation consists of one or more authentication servers - running on physically secure hosts. The authentication servers - maintain a database of principals (i.e., users and servers) and their - secret keys. Code libraries provide encryption and implement the - Kerberos protocol. In order to add authentication to its - - - -Kohl & Neuman [Page 5] - -RFC 1510 Kerberos September 1993 - - - transactions, a typical network application adds one or two calls to - the Kerberos library, which results in the transmission of the - necessary messages to achieve authentication. - - The Kerberos protocol consists of several sub-protocols (or - exchanges). There are two methods by which a client can ask a - Kerberos server for credentials. In the first approach, the client - sends a cleartext request for a ticket for the desired server to the - AS. The reply is sent encrypted in the client's secret key. Usually - this request is for a ticket-granting ticket (TGT) which can later be - used with the ticket-granting server (TGS). In the second method, - the client sends a request to the TGS. The client sends the TGT to - the TGS in the same manner as if it were contacting any other - application server which requires Kerberos credentials. The reply is - encrypted in the session key from the TGT. - - Once obtained, credentials may be used to verify the identity of the - principals in a transaction, to ensure the integrity of messages - exchanged between them, or to preserve privacy of the messages. The - application is free to choose whatever protection may be necessary. - - To verify the identities of the principals in a transaction, the - client transmits the ticket to the server. Since the ticket is sent - "in the clear" (parts of it are encrypted, but this encryption - doesn't thwart replay) and might be intercepted and reused by an - attacker, additional information is sent to prove that the message - was originated by the principal to whom the ticket was issued. This - information (called the authenticator) is encrypted in the session - key, and includes a timestamp. The timestamp proves that the message - was recently generated and is not a replay. Encrypting the - authenticator in the session key proves that it was generated by a - party possessing the session key. Since no one except the requesting - principal and the server know the session key (it is never sent over - the network in the clear) this guarantees the identity of the client. - - The integrity of the messages exchanged between principals can also - be guaranteed using the session key (passed in the ticket and - contained in the credentials). This approach provides detection of - both replay attacks and message stream modification attacks. It is - accomplished by generating and transmitting a collision-proof - checksum (elsewhere called a hash or digest function) of the client's - message, keyed with the session key. Privacy and integrity of the - messages exchanged between principals can be secured by encrypting - the data to be passed using the session key passed in the ticket, and - contained in the credentials. - - The authentication exchanges mentioned above require read-only access - to the Kerberos database. Sometimes, however, the entries in the - - - -Kohl & Neuman [Page 6] - -RFC 1510 Kerberos September 1993 - - - database must be modified, such as when adding new principals or - changing a principal's key. This is done using a protocol between a - client and a third Kerberos server, the Kerberos Administration - Server (KADM). The administration protocol is not described in this - document. There is also a protocol for maintaining multiple copies of - the Kerberos database, but this can be considered an implementation - detail and may vary to support different database technologies. - -1.1. Cross-Realm Operation - - The Kerberos protocol is designed to operate across organizational - boundaries. A client in one organization can be authenticated to a - server in another. Each organization wishing to run a Kerberos - server establishes its own "realm". The name of the realm in which a - client is registered is part of the client's name, and can be used by - the end-service to decide whether to honor a request. - - By establishing "inter-realm" keys, the administrators of two realms - can allow a client authenticated in the local realm to use its - authentication remotely (Of course, with appropriate permission the - client could arrange registration of a separately-named principal in - a remote realm, and engage in normal exchanges with that realm's - services. However, for even small numbers of clients this becomes - cumbersome, and more automatic methods as described here are - necessary). The exchange of inter-realm keys (a separate key may be - used for each direction) registers the ticket-granting service of - each realm as a principal in the other realm. A client is then able - to obtain a ticket-granting ticket for the remote realm's ticket- - granting service from its local realm. When that ticket-granting - ticket is used, the remote ticket-granting service uses the inter- - realm key (which usually differs from its own normal TGS key) to - decrypt the ticket-granting ticket, and is thus certain that it was - issued by the client's own TGS. Tickets issued by the remote ticket- - granting service will indicate to the end-service that the client was - authenticated from another realm. - - A realm is said to communicate with another realm if the two realms - share an inter-realm key, or if the local realm shares an inter-realm - key with an intermediate realm that communicates with the remote - realm. An authentication path is the sequence of intermediate realms - that are transited in communicating from one realm to another. - - Realms are typically organized hierarchically. Each realm shares a - key with its parent and a different key with each child. If an - inter-realm key is not directly shared by two realms, the - hierarchical organization allows an authentication path to be easily - constructed. If a hierarchical organization is not used, it may be - necessary to consult some database in order to construct an - - - -Kohl & Neuman [Page 7] - -RFC 1510 Kerberos September 1993 - - - authentication path between realms. - - Although realms are typically hierarchical, intermediate realms may - be bypassed to achieve cross-realm authentication through alternate - authentication paths (these might be established to make - communication between two realms more efficient). It is important - for the end-service to know which realms were transited when deciding - how much faith to place in the authentication process. To facilitate - this decision, a field in each ticket contains the names of the - realms that were involved in authenticating the client. - -1.2. Environmental assumptions - - Kerberos imposes a few assumptions on the environment in which it can - properly function: - - + "Denial of service" attacks are not solved with Kerberos. There - are places in these protocols where an intruder intruder can - prevent an application from participating in the proper - authentication steps. Detection and solution of such attacks - (some of which can appear to be not-uncommon "normal" failure - modes for the system) is usually best left to the human - administrators and users. - - + Principals must keep their secret keys secret. If an intruder - somehow steals a principal's key, it will be able to masquerade - as that principal or impersonate any server to the legitimate - principal. - - + "Password guessing" attacks are not solved by Kerberos. If a - user chooses a poor password, it is possible for an attacker to - successfully mount an offline dictionary attack by repeatedly - attempting to decrypt, with successive entries from a - dictionary, messages obtained which are encrypted under a key - derived from the user's password. - - + Each host on the network must have a clock which is "loosely - synchronized" to the time of the other hosts; this - synchronization is used to reduce the bookkeeping needs of - application servers when they do replay detection. The degree - of "looseness" can be configured on a per-server basis. If the - clocks are synchronized over the network, the clock - synchronization protocol must itself be secured from network - attackers. - - + Principal identifiers are not recycled on a short-term basis. A - typical mode of access control will use access control lists - (ACLs) to grant permissions to particular principals. If a - - - -Kohl & Neuman [Page 8] - -RFC 1510 Kerberos September 1993 - - - stale ACL entry remains for a deleted principal and the - principal identifier is reused, the new principal will inherit - rights specified in the stale ACL entry. By not re-using - principal identifiers, the danger of inadvertent access is - removed. - -1.3. Glossary of terms - - Below is a list of terms used throughout this document. - - - Authentication Verifying the claimed identity of a - principal. - - - Authentication header A record containing a Ticket and an - Authenticator to be presented to a - server as part of the authentication - process. - - - Authentication path A sequence of intermediate realms transited - in the authentication process when - communicating from one realm to another. - - Authenticator A record containing information that can - be shown to have been recently generated - using the session key known only by the - client and server. - - - Authorization The process of determining whether a - client may use a service, which objects - the client is allowed to access, and the - type of access allowed for each. - - - Capability A token that grants the bearer permission - to access an object or service. In - Kerberos, this might be a ticket whose - use is restricted by the contents of the - authorization data field, but which - lists no network addresses, together - with the session key necessary to use - the ticket. - - - - - - -Kohl & Neuman [Page 9] - -RFC 1510 Kerberos September 1993 - - - Ciphertext The output of an encryption function. - Encryption transforms plaintext into - ciphertext. - - - Client A process that makes use of a network - service on behalf of a user. Note that - in some cases a Server may itself be a - client of some other server (e.g., a - print server may be a client of a file - server). - - - Credentials A ticket plus the secret session key - necessary to successfully use that - ticket in an authentication exchange. - - - KDC Key Distribution Center, a network service - that supplies tickets and temporary - session keys; or an instance of that - service or the host on which it runs. - The KDC services both initial ticket and - ticket-granting ticket requests. The - initial ticket portion is sometimes - referred to as the Authentication Server - (or service). The ticket-granting - ticket portion is sometimes referred to - as the ticket-granting server (or service). - - Kerberos Aside from the 3-headed dog guarding - Hades, the name given to Project - Athena's authentication service, the - protocol used by that service, or the - code used to implement the authentication - service. - - - Plaintext The input to an encryption function or - the output of a decryption function. - Decryption transforms ciphertext into - plaintext. - - - Principal A uniquely named client or server - instance that participates in a network - communication. - - - - -Kohl & Neuman [Page 10] - -RFC 1510 Kerberos September 1993 - - - Principal identifier The name used to uniquely identify each - different principal. - - - Seal To encipher a record containing several - fields in such a way that the fields - cannot be individually replaced without - either knowledge of the encryption key - or leaving evidence of tampering. - - - Secret key An encryption key shared by a principal - and the KDC, distributed outside the - bounds of the system, with a long lifetime. - In the case of a human user's - principal, the secret key is derived - from a password. - - - Server A particular Principal which provides a - resource to network clients. - - - Service A resource provided to network clients; - often provided by more than one server - (for example, remote file service). - - - Session key A temporary encryption key used between - two principals, with a lifetime limited - to the duration of a single login "session". - - - Sub-session key A temporary encryption key used between - two principals, selected and exchanged - by the principals using the session key, - and with a lifetime limited to the duration - of a single association. - - - Ticket A record that helps a client authenticate - itself to a server; it contains the - client's identity, a session key, a - timestamp, and other information, all - sealed using the server's secret key. - It only serves to authenticate a client - when presented along with a fresh - Authenticator. - - - -Kohl & Neuman [Page 11] - -RFC 1510 Kerberos September 1993 - - -2. Ticket flag uses and requests - - Each Kerberos ticket contains a set of flags which are used to - indicate various attributes of that ticket. Most flags may be - requested by a client when the ticket is obtained; some are - automatically turned on and off by a Kerberos server as required. - The following sections explain what the various flags mean, and gives - examples of reasons to use such a flag. - -2.1. Initial and pre-authenticated tickets - - The INITIAL flag indicates that a ticket was issued using the AS - protocol and not issued based on a ticket-granting ticket. - Application servers that want to require the knowledge of a client's - secret key (e.g., a passwordchanging program) can insist that this - flag be set in any tickets they accept, and thus be assured that the - client's key was recently presented to the application client. - - The PRE-AUTHENT and HW-AUTHENT flags provide addition information - about the initial authentication, regardless of whether the current - ticket was issued directly (in which case INITIAL will also be set) - or issued on the basis of a ticket-granting ticket (in which case the - INITIAL flag is clear, but the PRE-AUTHENT and HW-AUTHENT flags are - carried forward from the ticket-granting ticket). - -2.2. Invalid tickets - - The INVALID flag indicates that a ticket is invalid. Application - servers must reject tickets which have this flag set. A postdated - ticket will usually be issued in this form. Invalid tickets must be - validated by the KDC before use, by presenting them to the KDC in a - TGS request with the VALIDATE option specified. The KDC will only - validate tickets after their starttime has passed. The validation is - required so that postdated tickets which have been stolen before - their starttime can be rendered permanently invalid (through a hot- - list mechanism). - -2.3. Renewable tickets - - Applications may desire to hold tickets which can be valid for long - periods of time. However, this can expose their credentials to - potential theft for equally long periods, and those stolen - credentials would be valid until the expiration time of the - ticket(s). Simply using shortlived tickets and obtaining new ones - periodically would require the client to have long-term access to its - secret key, an even greater risk. Renewable tickets can be used to - mitigate the consequences of theft. Renewable tickets have two - "expiration times": the first is when the current instance of the - - - -Kohl & Neuman [Page 12] - -RFC 1510 Kerberos September 1993 - - - ticket expires, and the second is the latest permissible value for an - individual expiration time. An application client must periodically - (i.e., before it expires) present a renewable ticket to the KDC, with - the RENEW option set in the KDC request. The KDC will issue a new - ticket with a new session key and a later expiration time. All other - fields of the ticket are left unmodified by the renewal process. - When the latest permissible expiration time arrives, the ticket - expires permanently. At each renewal, the KDC may consult a hot-list - to determine if the ticket had been reported stolen since its last - renewal; it will refuse to renew such stolen tickets, and thus the - usable lifetime of stolen tickets is reduced. - - The RENEWABLE flag in a ticket is normally only interpreted by the - ticket-granting service (discussed below in section 3.3). It can - usually be ignored by application servers. However, some - particularly careful application servers may wish to disallow - renewable tickets. - - If a renewable ticket is not renewed by its expiration time, the KDC - will not renew the ticket. The RENEWABLE flag is reset by default, - but a client may request it be set by setting the RENEWABLE option - in the KRB_AS_REQ message. If it is set, then the renew-till field - in the ticket contains the time after which the ticket may not be - renewed. - -2.4. Postdated tickets - - Applications may occasionally need to obtain tickets for use much - later, e.g., a batch submission system would need tickets to be valid - at the time the batch job is serviced. However, it is dangerous to - hold valid tickets in a batch queue, since they will be on-line - longer and more prone to theft. Postdated tickets provide a way to - obtain these tickets from the KDC at job submission time, but to - leave them "dormant" until they are activated and validated by a - further request of the KDC. If a ticket theft were reported in the - interim, the KDC would refuse to validate the ticket, and the thief - would be foiled. - - The MAY-POSTDATE flag in a ticket is normally only interpreted by the - ticket-granting service. It can be ignored by application servers. - This flag must be set in a ticket-granting ticket in order to issue a - postdated ticket based on the presented ticket. It is reset by - default; it may be requested by a client by setting the ALLOW- - POSTDATE option in the KRB_AS_REQ message. This flag does not allow - a client to obtain a postdated ticket-granting ticket; postdated - ticket-granting tickets can only by obtained by requesting the - postdating in the KRB_AS_REQ message. The life (endtime-starttime) - of a postdated ticket will be the remaining life of the ticket- - - - -Kohl & Neuman [Page 13] - -RFC 1510 Kerberos September 1993 - - - granting ticket at the time of the request, unless the RENEWABLE - option is also set, in which case it can be the full life (endtime- - starttime) of the ticket-granting ticket. The KDC may limit how far - in the future a ticket may be postdated. - - The POSTDATED flag indicates that a ticket has been postdated. The - application server can check the authtime field in the ticket to see - when the original authentication occurred. Some services may choose - to reject postdated tickets, or they may only accept them within a - certain period after the original authentication. When the KDC issues - a POSTDATED ticket, it will also be marked as INVALID, so that the - application client must present the ticket to the KDC to be validated - before use. - -2.5. Proxiable and proxy tickets - - At times it may be necessary for a principal to allow a service to - perform an operation on its behalf. The service must be able to take - on the identity of the client, but only for a particular purpose. A - principal can allow a service to take on the principal's identity for - a particular purpose by granting it a proxy. - - The PROXIABLE flag in a ticket is normally only interpreted by the - ticket-granting service. It can be ignored by application servers. - When set, this flag tells the ticket-granting server that it is OK to - issue a new ticket (but not a ticket-granting ticket) with a - different network address based on this ticket. This flag is set by - default. - - This flag allows a client to pass a proxy to a server to perform a - remote request on its behalf, e.g., a print service client can give - the print server a proxy to access the client's files on a particular - file server in order to satisfy a print request. - - In order to complicate the use of stolen credentials, Kerberos - tickets are usually valid from only those network addresses - specifically included in the ticket (It is permissible to request or - issue tickets with no network addresses specified, but we do not - recommend it). For this reason, a client wishing to grant a proxy - must request a new ticket valid for the network address of the - service to be granted the proxy. - - The PROXY flag is set in a ticket by the TGS when it issues a - proxy ticket. Application servers may check this flag and require - additional authentication from the agent presenting the proxy in - order to provide an audit trail. - - - - - -Kohl & Neuman [Page 14] - -RFC 1510 Kerberos September 1993 - - -2.6. Forwardable tickets - - Authentication forwarding is an instance of the proxy case where the - service is granted complete use of the client's identity. An example - where it might be used is when a user logs in to a remote system and - wants authentication to work from that system as if the login were - local. - - The FORWARDABLE flag in a ticket is normally only interpreted by the - ticket-granting service. It can be ignored by application servers. - The FORWARDABLE flag has an interpretation similar to that of the - PROXIABLE flag, except ticket-granting tickets may also be issued - with different network addresses. This flag is reset by default, but - users may request that it be set by setting the FORWARDABLE option in - the AS request when they request their initial ticket-granting - ticket. - - This flag allows for authentication forwarding without requiring the - user to enter a password again. If the flag is not set, then - authentication forwarding is not permitted, but the same end result - can still be achieved if the user engages in the AS exchange with the - requested network addresses and supplies a password. - - The FORWARDED flag is set by the TGS when a client presents a ticket - with the FORWARDABLE flag set and requests it be set by specifying - the FORWARDED KDC option and supplying a set of addresses for the new - ticket. It is also set in all tickets issued based on tickets with - the FORWARDED flag set. Application servers may wish to process - FORWARDED tickets differently than non-FORWARDED tickets. - -2.7. Other KDC options - - There are two additional options which may be set in a client's - request of the KDC. The RENEWABLE-OK option indicates that the - client will accept a renewable ticket if a ticket with the requested - life cannot otherwise be provided. If a ticket with the requested - life cannot be provided, then the KDC may issue a renewable ticket - with a renew-till equal to the the requested endtime. The value of - the renew-till field may still be adjusted by site-determined limits - or limits imposed by the individual principal or server. - - The ENC-TKT-IN-SKEY option is honored only by the ticket-granting - service. It indicates that the to-be-issued ticket for the end - server is to be encrypted in the session key from the additional - ticket-granting ticket provided with the request. See section 3.3.3 - for specific details. - - - - - -Kohl & Neuman [Page 15] - -RFC 1510 Kerberos September 1993 - - -3. Message Exchanges - - The following sections describe the interactions between network - clients and servers and the messages involved in those exchanges. - -3.1. The Authentication Service Exchange - - Summary - - Message direction Message type Section - 1. Client to Kerberos KRB_AS_REQ 5.4.1 - 2. Kerberos to client KRB_AS_REP or 5.4.2 - KRB_ERROR 5.9.1 - - The Authentication Service (AS) Exchange between the client and the - Kerberos Authentication Server is usually initiated by a client when - it wishes to obtain authentication credentials for a given server but - currently holds no credentials. The client's secret key is used for - encryption and decryption. This exchange is typically used at the - initiation of a login session, to obtain credentials for a Ticket- - Granting Server, which will subsequently be used to obtain - credentials for other servers (see section 3.3) without requiring - further use of the client's secret key. This exchange is also used - to request credentials for services which must not be mediated - through the Ticket-Granting Service, but rather require a principal's - secret key, such as the password-changing service. (The password- - changing request must not be honored unless the requester can provide - the old password (the user's current secret key). Otherwise, it - would be possible for someone to walk up to an unattended session and - change another user's password.) This exchange does not by itself - provide any assurance of the the identity of the user. (To - authenticate a user logging on to a local system, the credentials - obtained in the AS exchange may first be used in a TGS exchange to - obtain credentials for a local server. Those credentials must then - be verified by the local server through successful completion of the - Client/Server exchange.) - - The exchange consists of two messages: KRB_AS_REQ from the client to - Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these - messages are described in sections 5.4.1, 5.4.2, and 5.9.1. - - In the request, the client sends (in cleartext) its own identity and - the identity of the server for which it is requesting credentials. - The response, KRB_AS_REP, contains a ticket for the client to present - to the server, and a session key that will be shared by the client - and the server. The session key and additional information are - encrypted in the client's secret key. The KRB_AS_REP message - contains information which can be used to detect replays, and to - - - -Kohl & Neuman [Page 16] - -RFC 1510 Kerberos September 1993 - - - associate it with the message to which it replies. Various errors - can occur; these are indicated by an error response (KRB_ERROR) - instead of the KRB_AS_REP response. The error message is not - encrypted. The KRB_ERROR message also contains information which can - be used to associate it with the message to which it replies. The - lack of encryption in the KRB_ERROR message precludes the ability to - detect replays or fabrications of such messages. - - In the normal case the authentication server does not know whether - the client is actually the principal named in the request. It simply - sends a reply without knowing or caring whether they are the same. - This is acceptable because nobody but the principal whose identity - was given in the request will be able to use the reply. Its critical - information is encrypted in that principal's key. The initial - request supports an optional field that can be used to pass - additional information that might be needed for the initial exchange. - This field may be used for preauthentication if desired, but the - mechanism is not currently specified. - -3.1.1. Generation of KRB_AS_REQ message - - The client may specify a number of options in the initial request. - Among these options are whether preauthentication is to be performed; - whether the requested ticket is to be renewable, proxiable, or - forwardable; whether it should be postdated or allow postdating of - derivative tickets; and whether a renewable ticket will be accepted - in lieu of a non-renewable ticket if the requested ticket expiration - date cannot be satisfied by a nonrenewable ticket (due to - configuration constraints; see section 4). See section A.1 for - pseudocode. - - The client prepares the KRB_AS_REQ message and sends it to the KDC. - -3.1.2. Receipt of KRB_AS_REQ message - - If all goes well, processing the KRB_AS_REQ message will result in - the creation of a ticket for the client to present to the server. - The format for the ticket is described in section 5.3.1. The - contents of the ticket are determined as follows. - -3.1.3. Generation of KRB_AS_REP message - - The authentication server looks up the client and server principals - named in the KRB_AS_REQ in its database, extracting their respective - keys. If required, the server pre-authenticates the request, and if - the pre-authentication check fails, an error message with the code - KDC_ERR_PREAUTH_FAILED is returned. If the server cannot accommodate - the requested encryption type, an error message with code - - - -Kohl & Neuman [Page 17] - -RFC 1510 Kerberos September 1993 - - - KDC_ERR_ETYPE_NOSUPP is returned. Otherwise it generates a "random" - session key ("Random" means that, among other things, it should be - impossible to guess the next session key based on knowledge of past - session keys. This can only be achieved in a pseudo-random number - generator if it is based on cryptographic principles. It would be - more desirable to use a truly random number generator, such as one - based on measurements of random physical phenomena.). - - If the requested start time is absent or indicates a time in the - past, then the start time of the ticket is set to the authentication - server's current time. If it indicates a time in the future, but the - POSTDATED option has not been specified, then the error - KDC_ERR_CANNOT_POSTDATE is returned. Otherwise the requested start - time is checked against the policy of the local realm (the - administrator might decide to prohibit certain types or ranges of - postdated tickets), and if acceptable, the ticket's start time is set - as requested and the INVALID flag is set in the new ticket. The - postdated ticket must be validated before use by presenting it to the - KDC after the start time has been reached. - - The expiration time of the ticket will be set to the minimum of the - following: - - +The expiration time (endtime) requested in the KRB_AS_REQ - message. - - +The ticket's start time plus the maximum allowable lifetime - associated with the client principal (the authentication - server's database includes a maximum ticket lifetime field - in each principal's record; see section 4). - - +The ticket's start time plus the maximum allowable lifetime - associated with the server principal. - - +The ticket's start time plus the maximum lifetime set by - the policy of the local realm. - - If the requested expiration time minus the start time (as determined - above) is less than a site-determined minimum lifetime, an error - message with code KDC_ERR_NEVER_VALID is returned. If the requested - expiration time for the ticket exceeds what was determined as above, - and if the "RENEWABLE-OK" option was requested, then the "RENEWABLE" - flag is set in the new ticket, and the renew-till value is set as if - the "RENEWABLE" option were requested (the field and option names are - described fully in section 5.4.1). If the RENEWABLE option has been - requested or if the RENEWABLE-OK option has been set and a renewable - ticket is to be issued, then the renew-till field is set to the - minimum of: - - - -Kohl & Neuman [Page 18] - -RFC 1510 Kerberos September 1993 - - - +Its requested value. - - +The start time of the ticket plus the minimum of the two - maximum renewable lifetimes associated with the principals' - database entries. - - +The start time of the ticket plus the maximum renewable - lifetime set by the policy of the local realm. - - The flags field of the new ticket will have the following options set - if they have been requested and if the policy of the local realm - allows: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. - If the new ticket is postdated (the start time is in the future), its - INVALID flag will also be set. - - If all of the above succeed, the server formats a KRB_AS_REP message - (see section 5.4.2), copying the addresses in the request into the - caddr of the response, placing any required pre-authentication data - into the padata of the response, and encrypts the ciphertext part in - the client's key using the requested encryption method, and sends it - to the client. See section A.2 for pseudocode. - -3.1.4. Generation of KRB_ERROR message - - Several errors can occur, and the Authentication Server responds by - returning an error message, KRB_ERROR, to the client, with the - error-code and e-text fields set to appropriate values. The error - message contents and details are described in Section 5.9.1. - -3.1.5. Receipt of KRB_AS_REP message - - If the reply message type is KRB_AS_REP, then the client verifies - that the cname and crealm fields in the cleartext portion of the - reply match what it requested. If any padata fields are present, - they may be used to derive the proper secret key to decrypt the - message. The client decrypts the encrypted part of the response - using its secret key, verifies that the nonce in the encrypted part - matches the nonce it supplied in its request (to detect replays). It - also verifies that the sname and srealm in the response match those - in the request, and that the host address field is also correct. It - then stores the ticket, session key, start and expiration times, and - other information for later use. The key-expiration field from the - encrypted part of the response may be checked to notify the user of - impending key expiration (the client program could then suggest - remedial action, such as a password change). See section A.3 for - pseudocode. - - Proper decryption of the KRB_AS_REP message is not sufficient to - - - -Kohl & Neuman [Page 19] - -RFC 1510 Kerberos September 1993 - - - verify the identity of the user; the user and an attacker could - cooperate to generate a KRB_AS_REP format message which decrypts - properly but is not from the proper KDC. If the host wishes to - verify the identity of the user, it must require the user to present - application credentials which can be verified using a securely-stored - secret key. If those credentials can be verified, then the identity - of the user can be assured. - -3.1.6. Receipt of KRB_ERROR message - - If the reply message type is KRB_ERROR, then the client interprets it - as an error and performs whatever application-specific tasks are - necessary to recover. - -3.2. The Client/Server Authentication Exchange - - Summary - - Message direction Message type Section - Client to Application server KRB_AP_REQ 5.5.1 - [optional] Application server to client KRB_AP_REP or 5.5.2 - KRB_ERROR 5.9.1 - - The client/server authentication (CS) exchange is used by network - applications to authenticate the client to the server and vice versa. - The client must have already acquired credentials for the server - using the AS or TGS exchange. - -3.2.1. The KRB_AP_REQ message - - The KRB_AP_REQ contains authentication information which should be - part of the first message in an authenticated transaction. It - contains a ticket, an authenticator, and some additional bookkeeping - information (see section 5.5.1 for the exact format). The ticket by - itself is insufficient to authenticate a client, since tickets are - passed across the network in cleartext(Tickets contain both an - encrypted and unencrypted portion, so cleartext here refers to the - entire unit, which can be copied from one message and replayed in - another without any cryptographic skill.), so the authenticator is - used to prevent invalid replay of tickets by proving to the server - that the client knows the session key of the ticket and thus is - entitled to use it. The KRB_AP_REQ message is referred to elsewhere - as the "authentication header." - -3.2.2. Generation of a KRB_AP_REQ message - - When a client wishes to initiate authentication to a server, it - obtains (either through a credentials cache, the AS exchange, or the - - - -Kohl & Neuman [Page 20] - -RFC 1510 Kerberos September 1993 - - - TGS exchange) a ticket and session key for the desired service. The - client may re-use any tickets it holds until they expire. The client - then constructs a new Authenticator from the the system time, its - name, and optionally an application specific checksum, an initial - sequence number to be used in KRB_SAFE or KRB_PRIV messages, and/or a - session subkey to be used in negotiations for a session key unique to - this particular session. Authenticators may not be re-used and will - be rejected if replayed to a server (Note that this can make - applications based on unreliable transports difficult to code - correctly, if the transport might deliver duplicated messages. In - such cases, a new authenticator must be generated for each retry.). - If a sequence number is to be included, it should be randomly chosen - so that even after many messages have been exchanged it is not likely - to collide with other sequence numbers in use. - - The client may indicate a requirement of mutual authentication or the - use of a session-key based ticket by setting the appropriate flag(s) - in the ap-options field of the message. - - The Authenticator is encrypted in the session key and combined with - the ticket to form the KRB_AP_REQ message which is then sent to the - end server along with any additional application-specific - information. See section A.9 for pseudocode. - -3.2.3. Receipt of KRB_AP_REQ message - - Authentication is based on the server's current time of day (clocks - must be loosely synchronized), the authenticator, and the ticket. - Several errors are possible. If an error occurs, the server is - expected to reply to the client with a KRB_ERROR message. This - message may be encapsulated in the application protocol if its "raw" - form is not acceptable to the protocol. The format of error messages - is described in section 5.9.1. - - The algorithm for verifying authentication information is as follows. - If the message type is not KRB_AP_REQ, the server returns the - KRB_AP_ERR_MSG_TYPE error. If the key version indicated by the Ticket - in the KRB_AP_REQ is not one the server can use (e.g., it indicates - an old key, and the server no longer possesses a copy of the old - key), the KRB_AP_ERR_BADKEYVER error is returned. If the USE- - SESSION-KEY flag is set in the ap-options field, it indicates to the - server that the ticket is encrypted in the session key from the - server's ticket-granting ticket rather than its secret key (This is - used for user-to-user authentication as described in [6]). Since it - is possible for the server to be registered in multiple realms, with - different keys in each, the srealm field in the unencrypted portion - of the ticket in the KRB_AP_REQ is used to specify which secret key - the server should use to decrypt that ticket. The KRB_AP_ERR_NOKEY - - - -Kohl & Neuman [Page 21] - -RFC 1510 Kerberos September 1993 - - - error code is returned if the server doesn't have the proper key to - decipher the ticket. - - The ticket is decrypted using the version of the server's key - specified by the ticket. If the decryption routines detect a - modification of the ticket (each encryption system must provide - safeguards to detect modified ciphertext; see section 6), the - KRB_AP_ERR_BAD_INTEGRITY error is returned (chances are good that - different keys were used to encrypt and decrypt). - - The authenticator is decrypted using the session key extracted from - the decrypted ticket. If decryption shows it to have been modified, - the KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm - of the client from the ticket are compared against the same fields in - the authenticator. If they don't match, the KRB_AP_ERR_BADMATCH - error is returned (they might not match, for example, if the wrong - session key was used to encrypt the authenticator). The addresses in - the ticket (if any) are then searched for an address matching the - operating-system reported address of the client. If no match is - found or the server insists on ticket addresses but none are present - in the ticket, the KRB_AP_ERR_BADADDR error is returned. - - If the local (server) time and the client time in the authenticator - differ by more than the allowable clock skew (e.g., 5 minutes), the - KRB_AP_ERR_SKEW error is returned. If the server name, along with - the client name, time and microsecond fields from the Authenticator - match any recently-seen such tuples, the KRB_AP_ERR_REPEAT error is - returned (Note that the rejection here is restricted to - authenticators from the same principal to the same server. Other - client principals communicating with the same server principal should - not be have their authenticators rejected if the time and microsecond - fields happen to match some other client's authenticator.). The - server must remember any authenticator presented within the allowable - clock skew, so that a replay attempt is guaranteed to fail. If a - server loses track of any authenticator presented within the - allowable clock skew, it must reject all requests until the clock - skew interval has passed. This assures that any lost or re-played - authenticators will fall outside the allowable clock skew and can no - longer be successfully replayed (If this is not done, an attacker - could conceivably record the ticket and authenticator sent over the - network to a server, then disable the client's host, pose as the - disabled host, and replay the ticket and authenticator to subvert the - authentication.). If a sequence number is provided in the - authenticator, the server saves it for later use in processing - KRB_SAFE and/or KRB_PRIV messages. If a subkey is present, the - server either saves it for later use or uses it to help generate its - own choice for a subkey to be returned in a KRB_AP_REP message. - - - - -Kohl & Neuman [Page 22] - -RFC 1510 Kerberos September 1993 - - - The server computes the age of the ticket: local (server) time minus - the start time inside the Ticket. If the start time is later than - the current time by more than the allowable clock skew or if the - INVALID flag is set in the ticket, the KRB_AP_ERR_TKT_NYV error is - returned. Otherwise, if the current time is later than end time by - more than the allowable clock skew, the KRB_AP_ERR_TKT_EXPIRED error - is returned. - - If all these checks succeed without an error, the server is assured - that the client possesses the credentials of the principal named in - the ticket and thus, the client has been authenticated to the server. - See section A.10 for pseudocode. - -3.2.4. Generation of a KRB_AP_REP message - - Typically, a client's request will include both the authentication - information and its initial request in the same message, and the - server need not explicitly reply to the KRB_AP_REQ. However, if - mutual authentication (not only authenticating the client to the - server, but also the server to the client) is being performed, the - KRB_AP_REQ message will have MUTUAL-REQUIRED set in its ap-options - field, and a KRB_AP_REP message is required in response. As with the - error message, this message may be encapsulated in the application - protocol if its "raw" form is not acceptable to the application's - protocol. The timestamp and microsecond field used in the reply must - be the client's timestamp and microsecond field (as provided in the - authenticator). [Note: In the Kerberos version 4 protocol, the - timestamp in the reply was the client's timestamp plus one. This is - not necessary in version 5 because version 5 messages are formatted - in such a way that it is not possible to create the reply by - judicious message surgery (even in encrypted form) without knowledge - of the appropriate encryption keys.] If a sequence number is to be - included, it should be randomly chosen as described above for the - authenticator. A subkey may be included if the server desires to - negotiate a different subkey. The KRB_AP_REP message is encrypted in - the session key extracted from the ticket. See section A.11 for - pseudocode. - -3.2.5. Receipt of KRB_AP_REP message - - If a KRB_AP_REP message is returned, the client uses the session key - from the credentials obtained for the server (Note that for - encrypting the KRB_AP_REP message, the sub-session key is not used, - even if present in the Authenticator.) to decrypt the message, and - verifies that the timestamp and microsecond fields match those in the - Authenticator it sent to the server. If they match, then the client - is assured that the server is genuine. The sequence number and subkey - (if present) are retained for later use. See section A.12 for - - - -Kohl & Neuman [Page 23] - -RFC 1510 Kerberos September 1993 - - - pseudocode. - -3.2.6. Using the encryption key - - After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and - server share an encryption key which can be used by the application. - The "true session key" to be used for KRB_PRIV, KRB_SAFE, or other - application-specific uses may be chosen by the application based on - the subkeys in the KRB_AP_REP message and the authenticator - (Implementations of the protocol may wish to provide routines to - choose subkeys based on session keys and random numbers and to - orchestrate a negotiated key to be returned in the KRB_AP_REP - message.). In some cases, the use of this session key will be - implicit in the protocol; in others the method of use must be chosen - from a several alternatives. We leave the protocol negotiations of - how to use the key (e.g., selecting an encryption or checksum type) - to the application programmer; the Kerberos protocol does not - constrain the implementation options. - - With both the one-way and mutual authentication exchanges, the peers - should take care not to send sensitive information to each other - without proper assurances. In particular, applications that require - privacy or integrity should use the KRB_AP_REP or KRB_ERROR responses - from the server to client to assure both client and server of their - peer's identity. If an application protocol requires privacy of its - messages, it can use the KRB_PRIV message (section 3.5). The KRB_SAFE - message (section 3.4) can be used to assure integrity. - -3.3. The Ticket-Granting Service (TGS) Exchange - - Summary - - Message direction Message type Section - 1. Client to Kerberos KRB_TGS_REQ 5.4.1 - 2. Kerberos to client KRB_TGS_REP or 5.4.2 - KRB_ERROR 5.9.1 - - The TGS exchange between a client and the Kerberos Ticket-Granting - Server is initiated by a client when it wishes to obtain - authentication credentials for a given server (which might be - registered in a remote realm), when it wishes to renew or validate an - existing ticket, or when it wishes to obtain a proxy ticket. In the - first case, the client must already have acquired a ticket for the - Ticket-Granting Service using the AS exchange (the ticket-granting - ticket is usually obtained when a client initially authenticates to - the system, such as when a user logs in). The message format for the - TGS exchange is almost identical to that for the AS exchange. The - primary difference is that encryption and decryption in the TGS - - - -Kohl & Neuman [Page 24] - -RFC 1510 Kerberos September 1993 - - - exchange does not take place under the client's key. Instead, the - session key from the ticket-granting ticket or renewable ticket, or - sub-session key from an Authenticator is used. As is the case for - all application servers, expired tickets are not accepted by the TGS, - so once a renewable or ticket-granting ticket expires, the client - must use a separate exchange to obtain valid tickets. - - The TGS exchange consists of two messages: A request (KRB_TGS_REQ) - from the client to the Kerberos Ticket-Granting Server, and a reply - (KRB_TGS_REP or KRB_ERROR). The KRB_TGS_REQ message includes - information authenticating the client plus a request for credentials. - The authentication information consists of the authentication header - (KRB_AP_REQ) which includes the client's previously obtained ticket- - granting, renewable, or invalid ticket. In the ticket-granting - ticket and proxy cases, the request may include one or more of: a - list of network addresses, a collection of typed authorization data - to be sealed in the ticket for authorization use by the application - server, or additional tickets (the use of which are described later). - The TGS reply (KRB_TGS_REP) contains the requested credentials, - encrypted in the session key from the ticket-granting ticket or - renewable ticket, or if present, in the subsession key from the - Authenticator (part of the authentication header). The KRB_ERROR - message contains an error code and text explaining what went wrong. - The KRB_ERROR message is not encrypted. The KRB_TGS_REP message - contains information which can be used to detect replays, and to - associate it with the message to which it replies. The KRB_ERROR - message also contains information which can be used to associate it - with the message to which it replies, but the lack of encryption in - the KRB_ERROR message precludes the ability to detect replays or - fabrications of such messages. - -3.3.1. Generation of KRB_TGS_REQ message - - Before sending a request to the ticket-granting service, the client - must determine in which realm the application server is registered - [Note: This can be accomplished in several ways. It might be known - beforehand (since the realm is part of the principal identifier), or - it might be stored in a nameserver. Presently, however, this - information is obtained from a configuration file. If the realm to - be used is obtained from a nameserver, there is a danger of being - spoofed if the nameservice providing the realm name is not - authenticated. This might result in the use of a realm which has - been compromised, and would result in an attacker's ability to - compromise the authentication of the application server to the - client.]. If the client does not already possess a ticket-granting - ticket for the appropriate realm, then one must be obtained. This is - first attempted by requesting a ticket-granting ticket for the - destination realm from the local Kerberos server (using the - - - -Kohl & Neuman [Page 25] - -RFC 1510 Kerberos September 1993 - - - KRB_TGS_REQ message recursively). The Kerberos server may return a - TGT for the desired realm in which case one can proceed. - Alternatively, the Kerberos server may return a TGT for a realm which - is "closer" to the desired realm (further along the standard - hierarchical path), in which case this step must be repeated with a - Kerberos server in the realm specified in the returned TGT. If - neither are returned, then the request must be retried with a - Kerberos server for a realm higher in the hierarchy. This request - will itself require a ticket-granting ticket for the higher realm - which must be obtained by recursively applying these directions. - - Once the client obtains a ticket-granting ticket for the appropriate - realm, it determines which Kerberos servers serve that realm, and - contacts one. The list might be obtained through a configuration file - or network service; as long as the secret keys exchanged by realms - are kept secret, only denial of service results from a false Kerberos - server. - - As in the AS exchange, the client may specify a number of options in - the KRB_TGS_REQ message. The client prepares the KRB_TGS_REQ - message, providing an authentication header as an element of the - padata field, and including the same fields as used in the KRB_AS_REQ - message along with several optional fields: the enc-authorization- - data field for application server use and additional tickets required - by some options. - - In preparing the authentication header, the client can select a sub- - session key under which the response from the Kerberos server will be - encrypted (If the client selects a sub-session key, care must be - taken to ensure the randomness of the selected subsession key. One - approach would be to generate a random number and XOR it with the - session key from the ticket-granting ticket.). If the sub-session key - is not specified, the session key from the ticket-granting ticket - will be used. If the enc-authorization-data is present, it must be - encrypted in the sub-session key, if present, from the authenticator - portion of the authentication header, or if not present in the - session key from the ticket-granting ticket. - - Once prepared, the message is sent to a Kerberos server for the - destination realm. See section A.5 for pseudocode. - -3.3.2. Receipt of KRB_TGS_REQ message - - The KRB_TGS_REQ message is processed in a manner similar to the - KRB_AS_REQ message, but there are many additional checks to be - performed. First, the Kerberos server must determine which server - the accompanying ticket is for and it must select the appropriate key - to decrypt it. For a normal KRB_TGS_REQ message, it will be for the - - - -Kohl & Neuman [Page 26] - -RFC 1510 Kerberos September 1993 - - - ticket granting service, and the TGS's key will be used. If the TGT - was issued by another realm, then the appropriate inter-realm key - must be used. If the accompanying ticket is not a ticket granting - ticket for the current realm, but is for an application server in the - current realm, the RENEW, VALIDATE, or PROXY options are specified in - the request, and the server for which a ticket is requested is the - server named in the accompanying ticket, then the KDC will decrypt - the ticket in the authentication header using the key of the server - for which it was issued. If no ticket can be found in the padata - field, the KDC_ERR_PADATA_TYPE_NOSUPP error is returned. - - Once the accompanying ticket has been decrypted, the user-supplied - checksum in the Authenticator must be verified against the contents - of the request, and the message rejected if the checksums do not - match (with an error code of KRB_AP_ERR_MODIFIED) or if the checksum - is not keyed or not collision-proof (with an error code of - KRB_AP_ERR_INAPP_CKSUM). If the checksum type is not supported, the - KDC_ERR_SUMTYPE_NOSUPP error is returned. If the authorization-data - are present, they are decrypted using the sub-session key from the - Authenticator. - - If any of the decryptions indicate failed integrity checks, the - KRB_AP_ERR_BAD_INTEGRITY error is returned. - -3.3.3. Generation of KRB_TGS_REP message - - The KRB_TGS_REP message shares its format with the KRB_AS_REP - (KRB_KDC_REP), but with its type field set to KRB_TGS_REP. The - detailed specification is in section 5.4.2. - - The response will include a ticket for the requested server. The - Kerberos database is queried to retrieve the record for the requested - server (including the key with which the ticket will be encrypted). - If the request is for a ticket granting ticket for a remote realm, - and if no key is shared with the requested realm, then the Kerberos - server will select the realm "closest" to the requested realm with - which it does share a key, and use that realm instead. This is the - only case where the response from the KDC will be for a different - server than that requested by the client. - - By default, the address field, the client's name and realm, the list - of transited realms, the time of initial authentication, the - expiration time, and the authorization data of the newly-issued - ticket will be copied from the ticket-granting ticket (TGT) or - renewable ticket. If the transited field needs to be updated, but - the transited type is not supported, the KDC_ERR_TRTYPE_NOSUPP error - is returned. - - - - -Kohl & Neuman [Page 27] - -RFC 1510 Kerberos September 1993 - - - If the request specifies an endtime, then the endtime of the new - ticket is set to the minimum of (a) that request, (b) the endtime - from the TGT, and (c) the starttime of the TGT plus the minimum of - the maximum life for the application server and the maximum life for - the local realm (the maximum life for the requesting principal was - already applied when the TGT was issued). If the new ticket is to be - a renewal, then the endtime above is replaced by the minimum of (a) - the value of the renew_till field of the ticket and (b) the starttime - for the new ticket plus the life (endtimestarttime) of the old - ticket. - - If the FORWARDED option has been requested, then the resulting ticket - will contain the addresses specified by the client. This option will - only be honored if the FORWARDABLE flag is set in the TGT. The PROXY - option is similar; the resulting ticket will contain the addresses - specified by the client. It will be honored only if the PROXIABLE - flag in the TGT is set. The PROXY option will not be honored on - requests for additional ticket-granting tickets. - - If the requested start time is absent or indicates a time in the - past, then the start time of the ticket is set to the authentication - server's current time. If it indicates a time in the future, but the - POSTDATED option has not been specified or the MAY-POSTDATE flag is - not set in the TGT, then the error KDC_ERR_CANNOT_POSTDATE is - returned. Otherwise, if the ticket-granting ticket has the - MAYPOSTDATE flag set, then the resulting ticket will be postdated and - the requested starttime is checked against the policy of the local - realm. If acceptable, the ticket's start time is set as requested, - and the INVALID flag is set. The postdated ticket must be validated - before use by presenting it to the KDC after the starttime has been - reached. However, in no case may the starttime, endtime, or renew- - till time of a newly-issued postdated ticket extend beyond the - renew-till time of the ticket-granting ticket. - - If the ENC-TKT-IN-SKEY option has been specified and an additional - ticket has been included in the request, the KDC will decrypt the - additional ticket using the key for the server to which the - additional ticket was issued and verify that it is a ticket-granting - ticket. If the name of the requested server is missing from the - request, the name of the client in the additional ticket will be - used. Otherwise the name of the requested server will be compared to - the name of the client in the additional ticket and if different, the - request will be rejected. If the request succeeds, the session key - from the additional ticket will be used to encrypt the new ticket - that is issued instead of using the key of the server for which the - new ticket will be used (This allows easy implementation of user-to- - user authentication [6], which uses ticket-granting ticket session - keys in lieu of secret server keys in situations where such secret - - - -Kohl & Neuman [Page 28] - -RFC 1510 Kerberos September 1993 - - - keys could be easily compromised.). - - If the name of the server in the ticket that is presented to the KDC - as part of the authentication header is not that of the ticket- - granting server itself, and the server is registered in the realm of - the KDC, If the RENEW option is requested, then the KDC will verify - that the RENEWABLE flag is set in the ticket and that the renew_till - time is still in the future. If the VALIDATE option is rqeuested, - the KDC will check that the starttime has passed and the INVALID flag - is set. If the PROXY option is requested, then the KDC will check - that the PROXIABLE flag is set in the ticket. If the tests succeed, - the KDC will issue the appropriate new ticket. - - Whenever a request is made to the ticket-granting server, the - presented ticket(s) is(are) checked against a hot-list of tickets - which have been canceled. This hot-list might be implemented by - storing a range of issue dates for "suspect tickets"; if a presented - ticket had an authtime in that range, it would be rejected. In this - way, a stolen ticket-granting ticket or renewable ticket cannot be - used to gain additional tickets (renewals or otherwise) once the - theft has been reported. Any normal ticket obtained before it was - reported stolen will still be valid (because they require no - interaction with the KDC), but only until their normal expiration - time. - - The ciphertext part of the response in the KRB_TGS_REP message is - encrypted in the sub-session key from the Authenticator, if present, - or the session key key from the ticket-granting ticket. It is not - encrypted using the client's secret key. Furthermore, the client's - key's expiration date and the key version number fields are left out - since these values are stored along with the client's database - record, and that record is not needed to satisfy a request based on a - ticket-granting ticket. See section A.6 for pseudocode. - -3.3.3.1. Encoding the transited field - - If the identity of the server in the TGT that is presented to the KDC - as part of the authentication header is that of the ticket-granting - service, but the TGT was issued from another realm, the KDC will look - up the inter-realm key shared with that realm and use that key to - decrypt the ticket. If the ticket is valid, then the KDC will honor - the request, subject to the constraints outlined above in the section - describing the AS exchange. The realm part of the client's identity - will be taken from the ticket-granting ticket. The name of the realm - that issued the ticket-granting ticket will be added to the transited - field of the ticket to be issued. This is accomplished by reading - the transited field from the ticket-granting ticket (which is treated - as an unordered set of realm names), adding the new realm to the set, - - - -Kohl & Neuman [Page 29] - -RFC 1510 Kerberos September 1993 - - - then constructing and writing out its encoded (shorthand) form (this - may involve a rearrangement of the existing encoding). - - Note that the ticket-granting service does not add the name of its - own realm. Instead, its responsibility is to add the name of the - previous realm. This prevents a malicious Kerberos server from - intentionally leaving out its own name (it could, however, omit other - realms' names). - - The names of neither the local realm nor the principal's realm are to - be included in the transited field. They appear elsewhere in the - ticket and both are known to have taken part in authenticating the - principal. Since the endpoints are not included, both local and - single-hop inter-realm authentication result in a transited field - that is empty. - - Because the name of each realm transited is added to this field, - it might potentially be very long. To decrease the length of this - field, its contents are encoded. The initially supported encoding is - optimized for the normal case of inter-realm communication: a - hierarchical arrangement of realms using either domain or X.500 style - realm names. This encoding (called DOMAIN-X500-COMPRESS) is now - described. - - Realm names in the transited field are separated by a ",". The ",", - "\", trailing "."s, and leading spaces (" ") are special characters, - and if they are part of a realm name, they must be quoted in the - transited field by preceding them with a "\". - - A realm name ending with a "." is interpreted as being prepended to - the previous realm. For example, we can encode traversal of EDU, - MIT.EDU, ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as: - - "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.". - - Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were endpoints, - that they would not be included in this field, and we would have: - - "EDU,MIT.,WASHINGTON.EDU" - - A realm name beginning with a "/" is interpreted as being appended to - the previous realm (For the purpose of appending, the realm preceding - the first listed realm is considered to be the null realm ("")). If - it is to stand by itself, then it should be preceded by a space (" - "). For example, we can encode traversal of /COM/HP/APOLLO, /COM/HP, - /COM, and /COM/DEC as: - - "/COM,/HP,/APOLLO, /COM/DEC". - - - -Kohl & Neuman [Page 30] - -RFC 1510 Kerberos September 1993 - - - Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints, - they they would not be included in this field, and we would have: - - "/COM,/HP" - - A null subfield preceding or following a "," indicates that all - realms between the previous realm and the next realm have been - traversed (For the purpose of interpreting null subfields, the - client's realm is considered to precede those in the transited field, - and the server's realm is considered to follow them.). Thus, "," - means that all realms along the path between the client and the - server have been traversed. ",EDU, /COM," means that that all realms - from the client's realm up to EDU (in a domain style hierarchy) have - been traversed, and that everything from /COM down to the server's - realm in an X.500 style has also been traversed. This could occur if - the EDU realm in one hierarchy shares an inter-realm key directly - with the /COM realm in another hierarchy. - -3.3.4. Receipt of KRB_TGS_REP message - - When the KRB_TGS_REP is received by the client, it is processed in - the same manner as the KRB_AS_REP processing described above. The - primary difference is that the ciphertext part of the response must - be decrypted using the session key from the ticket-granting ticket - rather than the client's secret key. See section A.7 for pseudocode. - -3.4. The KRB_SAFE Exchange - - The KRB_SAFE message may be used by clients requiring the ability to - detect modifications of messages they exchange. It achieves this by - including a keyed collisionproof checksum of the user data and some - control information. The checksum is keyed with an encryption key - (usually the last key negotiated via subkeys, or the session key if - no negotiation has occured). - -3.4.1. Generation of a KRB_SAFE message - - When an application wishes to send a KRB_SAFE message, it collects - its data and the appropriate control information and computes a - checksum over them. The checksum algorithm should be some sort of - keyed one-way hash function (such as the RSA-MD5-DES checksum - algorithm specified in section 6.4.5, or the DES MAC), generated - using the sub-session key if present, or the session key. Different - algorithms may be selected by changing the checksum type in the - message. Unkeyed or non-collision-proof checksums are not suitable - for this use. - - The control information for the KRB_SAFE message includes both a - - - -Kohl & Neuman [Page 31] - -RFC 1510 Kerberos September 1993 - - - timestamp and a sequence number. The designer of an application - using the KRB_SAFE message must choose at least one of the two - mechanisms. This choice should be based on the needs of the - application protocol. - - Sequence numbers are useful when all messages sent will be received - by one's peer. Connection state is presently required to maintain - the session key, so maintaining the next sequence number should not - present an additional problem. - - If the application protocol is expected to tolerate lost messages - without them being resent, the use of the timestamp is the - appropriate replay detection mechanism. Using timestamps is also the - appropriate mechanism for multi-cast protocols where all of one's - peers share a common sub-session key, but some messages will be sent - to a subset of one's peers. - - After computing the checksum, the client then transmits the - information and checksum to the recipient in the message format - specified in section 5.6.1. - -3.4.2. Receipt of KRB_SAFE message - - When an application receives a KRB_SAFE message, it verifies it as - follows. If any error occurs, an error code is reported for use by - the application. - - The message is first checked by verifying that the protocol version - and type fields match the current version and KRB_SAFE, respectively. - A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE - error. The application verifies that the checksum used is a - collisionproof keyed checksum, and if it is not, a - KRB_AP_ERR_INAPP_CKSUM error is generated. The recipient verifies - that the operating system's report of the sender's address matches - the sender's address in the message, and (if a recipient address is - specified or the recipient requires an address) that one of the - recipient's addresses appears as the recipient's address in the - message. A failed match for either case generates a - KRB_AP_ERR_BADADDR error. Then the timestamp and usec and/or the - sequence number fields are checked. If timestamp and usec are - expected and not present, or they are present but not current, the - KRB_AP_ERR_SKEW error is generated. If the server name, along with - the client name, time and microsecond fields from the Authenticator - match any recently-seen such tuples, the KRB_AP_ERR_REPEAT error is - generated. If an incorrect sequence number is included, or a - sequence number is expected but not present, the KRB_AP_ERR_BADORDER - error is generated. If neither a timestamp and usec or a sequence - number is present, a KRB_AP_ERR_MODIFIED error is generated. - - - -Kohl & Neuman [Page 32] - -RFC 1510 Kerberos September 1993 - - - Finally, the checksum is computed over the data and control - information, and if it doesn't match the received checksum, a - KRB_AP_ERR_MODIFIED error is generated. - - If all the checks succeed, the application is assured that the - message was generated by its peer and was not modified in transit. - -3.5. The KRB_PRIV Exchange - - The KRB_PRIV message may be used by clients requiring confidentiality - and the ability to detect modifications of exchanged messages. It - achieves this by encrypting the messages and adding control - information. - -3.5.1. Generation of a KRB_PRIV message - - When an application wishes to send a KRB_PRIV message, it collects - its data and the appropriate control information (specified in - section 5.7.1) and encrypts them under an encryption key (usually the - last key negotiated via subkeys, or the session key if no negotiation - has occured). As part of the control information, the client must - choose to use either a timestamp or a sequence number (or both); see - the discussion in section 3.4.1 for guidelines on which to use. - After the user data and control information are encrypted, the client - transmits the ciphertext and some "envelope" information to the - recipient. - -3.5.2. Receipt of KRB_PRIV message - - When an application receives a KRB_PRIV message, it verifies it as - follows. If any error occurs, an error code is reported for use by - the application. - - The message is first checked by verifying that the protocol version - and type fields match the current version and KRB_PRIV, respectively. - A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE - error. The application then decrypts the ciphertext and processes - the resultant plaintext. If decryption shows the data to have been - modified, a KRB_AP_ERR_BAD_INTEGRITY error is generated. The - recipient verifies that the operating system's report of the sender's - address matches the sender's address in the message, and (if a - recipient address is specified or the recipient requires an address) - that one of the recipient's addresses appears as the recipient's - address in the message. A failed match for either case generates a - KRB_AP_ERR_BADADDR error. Then the timestamp and usec and/or the - sequence number fields are checked. If timestamp and usec are - expected and not present, or they are present but not current, the - KRB_AP_ERR_SKEW error is generated. If the server name, along with - - - -Kohl & Neuman [Page 33] - -RFC 1510 Kerberos September 1993 - - - the client name, time and microsecond fields from the Authenticator - match any recently-seen such tuples, the KRB_AP_ERR_REPEAT error is - generated. If an incorrect sequence number is included, or a - sequence number is expected but not present, the KRB_AP_ERR_BADORDER - error is generated. If neither a timestamp and usec or a sequence - number is present, a KRB_AP_ERR_MODIFIED error is generated. - - If all the checks succeed, the application can assume the message was - generated by its peer, and was securely transmitted (without - intruders able to see the unencrypted contents). - -3.6. The KRB_CRED Exchange - - The KRB_CRED message may be used by clients requiring the ability to - send Kerberos credentials from one host to another. It achieves this - by sending the tickets together with encrypted data containing the - session keys and other information associated with the tickets. - -3.6.1. Generation of a KRB_CRED message - - When an application wishes to send a KRB_CRED message it first (using - the KRB_TGS exchange) obtains credentials to be sent to the remote - host. It then constructs a KRB_CRED message using the ticket or - tickets so obtained, placing the session key needed to use each - ticket in the key field of the corresponding KrbCredInfo sequence of - the encrypted part of the the KRB_CRED message. - - Other information associated with each ticket and obtained during the - KRB_TGS exchange is also placed in the corresponding KrbCredInfo - sequence in the encrypted part of the KRB_CRED message. The current - time and, if specifically required by the application the nonce, s- - address, and raddress fields, are placed in the encrypted part of the - KRB_CRED message which is then encrypted under an encryption key - previosuly exchanged in the KRB_AP exchange (usually the last key - negotiated via subkeys, or the session key if no negotiation has - occured). - -3.6.2. Receipt of KRB_CRED message - - When an application receives a KRB_CRED message, it verifies it. If - any error occurs, an error code is reported for use by the - application. The message is verified by checking that the protocol - version and type fields match the current version and KRB_CRED, - respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or - KRB_AP_ERR_MSG_TYPE error. The application then decrypts the - ciphertext and processes the resultant plaintext. If decryption shows - the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is - generated. - - - -Kohl & Neuman [Page 34] - -RFC 1510 Kerberos September 1993 - - - If present or required, the recipient verifies that the operating - system's report of the sender's address matches the sender's address - in the message, and that one of the recipient's addresses appears as - the recipient's address in the message. A failed match for either - case generates a KRB_AP_ERR_BADADDR error. The timestamp and usec - fields (and the nonce field if required) are checked next. If the - timestamp and usec are not present, or they are present but not - current, the KRB_AP_ERR_SKEW error is generated. - - If all the checks succeed, the application stores each of the new - tickets in its ticket cache together with the session key and other - information in the corresponding KrbCredInfo sequence from the - encrypted part of the KRB_CRED message. - -4. The Kerberos Database - - The Kerberos server must have access to a database containing the - principal identifiers and secret keys of principals to be - authenticated (The implementation of the Kerberos server need not - combine the database and the server on the same machine; it is - feasible to store the principal database in, say, a network name - service, as long as the entries stored therein are protected from - disclosure to and modification by unauthorized parties. However, we - recommend against such strategies, as they can make system management - and threat analysis quite complex.). - -4.1. Database contents - - A database entry should contain at least the following fields: - - Field Value - - name Principal's identifier - key Principal's secret key - p_kvno Principal's key version - max_life Maximum lifetime for Tickets - max_renewable_life Maximum total lifetime for renewable - Tickets - - The name field is an encoding of the principal's identifier. The key - field contains an encryption key. This key is the principal's secret - key. (The key can be encrypted before storage under a Kerberos - "master key" to protect it in case the database is compromised but - the master key is not. In that case, an extra field must be added to - indicate the master key version used, see below.) The p_kvno field is - the key version number of the principal's secret key. The max_life - field contains the maximum allowable lifetime (endtime - starttime) - for any Ticket issued for this principal. The max_renewable_life - - - -Kohl & Neuman [Page 35] - -RFC 1510 Kerberos September 1993 - - - field contains the maximum allowable total lifetime for any renewable - Ticket issued for this principal. (See section 3.1 for a description - of how these lifetimes are used in determining the lifetime of a - given Ticket.) - - A server may provide KDC service to several realms, as long as the - database representation provides a mechanism to distinguish between - principal records with identifiers which differ only in the realm - name. - - When an application server's key changes, if the change is routine - (i.e., not the result of disclosure of the old key), the old key - should be retained by the server until all tickets that had been - issued using that key have expired. Because of this, it is possible - for several keys to be active for a single principal. Ciphertext - encrypted in a principal's key is always tagged with the version of - the key that was used for encryption, to help the recipient find the - proper key for decryption. - - When more than one key is active for a particular principal, the - principal will have more than one record in the Kerberos database. - The keys and key version numbers will differ between the records (the - rest of the fields may or may not be the same). Whenever Kerberos - issues a ticket, or responds to a request for initial authentication, - the most recent key (known by the Kerberos server) will be used for - encryption. This is the key with the highest key version number. - -4.2. Additional fields - - Project Athena's KDC implementation uses additional fields in its - database: - - Field Value - - K_kvno Kerberos' key version - expiration Expiration date for entry - attributes Bit field of attributes - mod_date Timestamp of last modification - mod_name Modifying principal's identifier - - The K_kvno field indicates the key version of the Kerberos master key - under which the principal's secret key is encrypted. - - After an entry's expiration date has passed, the KDC will return an - error to any client attempting to gain tickets as or for the - principal. (A database may want to maintain two expiration dates: - one for the principal, and one for the principal's current key. This - allows password aging to work independently of the principal's - - - -Kohl & Neuman [Page 36] - -RFC 1510 Kerberos September 1993 - - - expiration date. However, due to the limited space in the responses, - the KDC must combine the key expiration and principal expiration date - into a single value called "key_exp", which is used as a hint to the - user to take administrative action.) - - The attributes field is a bitfield used to govern the operations - involving the principal. This field might be useful in conjunction - with user registration procedures, for site-specific policy - implementations (Project Athena currently uses it for their user - registration process controlled by the system-wide database service, - Moira [7]), or to identify the "string to key" conversion algorithm - used for a principal's key. (See the discussion of the padata field - in section 5.4.2 for details on why this can be useful.) Other bits - are used to indicate that certain ticket options should not be - allowed in tickets encrypted under a principal's key (one bit each): - Disallow issuing postdated tickets, disallow issuing forwardable - tickets, disallow issuing tickets based on TGT authentication, - disallow issuing renewable tickets, disallow issuing proxiable - tickets, and disallow issuing tickets for which the principal is the - server. - - The mod_date field contains the time of last modification of the - entry, and the mod_name field contains the name of the principal - which last modified the entry. - -4.3. Frequently Changing Fields - - Some KDC implementations may wish to maintain the last time that a - request was made by a particular principal. Information that might - be maintained includes the time of the last request, the time of the - last request for a ticket-granting ticket, the time of the last use - of a ticket-granting ticket, or other times. This information can - then be returned to the user in the last-req field (see section 5.2). - - Other frequently changing information that can be maintained is the - latest expiration time for any tickets that have been issued using - each key. This field would be used to indicate how long old keys - must remain valid to allow the continued use of outstanding tickets. - -4.4. Site Constants - - The KDC implementation should have the following configurable - constants or options, to allow an administrator to make and enforce - policy decisions: - - + The minimum supported lifetime (used to determine whether the - KDC_ERR_NEVER_VALID error should be returned). This constant - should reflect reasonable expectations of round-trip time to the - - - -Kohl & Neuman [Page 37] - -RFC 1510 Kerberos September 1993 - - - KDC, encryption/decryption time, and processing time by the client - and target server, and it should allow for a minimum "useful" - lifetime. - - + The maximum allowable total (renewable) lifetime of a ticket - (renew_till - starttime). - - + The maximum allowable lifetime of a ticket (endtime - starttime). - - + Whether to allow the issue of tickets with empty address fields - (including the ability to specify that such tickets may only be - issued if the request specifies some authorization_data). - - + Whether proxiable, forwardable, renewable or post-datable tickets - are to be issued. - -5. Message Specifications - - The following sections describe the exact contents and encoding of - protocol messages and objects. The ASN.1 base definitions are - presented in the first subsection. The remaining subsections specify - the protocol objects (tickets and authenticators) and messages. - Specification of encryption and checksum techniques, and the fields - related to them, appear in section 6. - -5.1. ASN.1 Distinguished Encoding Representation - - All uses of ASN.1 in Kerberos shall use the Distinguished Encoding - Representation of the data elements as described in the X.509 - specification, section 8.7 [8]. - -5.2. ASN.1 Base Definitions - - The following ASN.1 base definitions are used in the rest of this - section. Note that since the underscore character (_) is not - permitted in ASN.1 names, the hyphen (-) is used in its place for the - purposes of ASN.1 names. - - Realm ::= GeneralString - PrincipalName ::= SEQUENCE { - name-type[0] INTEGER, - name-string[1] SEQUENCE OF GeneralString - } - - Kerberos realms are encoded as GeneralStrings. Realms shall not - contain a character with the code 0 (the ASCII NUL). Most realms - will usually consist of several components separated by periods (.), - in the style of Internet Domain Names, or separated by slashes (/) in - - - -Kohl & Neuman [Page 38] - -RFC 1510 Kerberos September 1993 - - - the style of X.500 names. Acceptable forms for realm names are - specified in section 7. A PrincipalName is a typed sequence of - components consisting of the following sub-fields: - - name-type This field specifies the type of name that follows. - Pre-defined values for this field are - specified in section 7.2. The name-type should be - treated as a hint. 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). - This constraint may be eliminated in the future. - - name-string This field encodes a sequence of components that - form a name, each component encoded as a General - String. Taken together, a PrincipalName and a Realm - form a principal identifier. Most PrincipalNames - will have only a few components (typically one or two). - - KerberosTime ::= GeneralizedTime - -- Specifying UTC time zone (Z) - - The timestamps used in Kerberos are encoded as GeneralizedTimes. An - encoding shall specify the UTC time zone (Z) and shall not include - any fractional portions of the seconds. It further shall not include - any separators. Example: The only valid format for UTC time 6 - minutes, 27 seconds after 9 pm on 6 November 1985 is 19851106210627Z. - - HostAddress ::= SEQUENCE { - addr-type[0] INTEGER, - address[1] OCTET STRING - } - - HostAddresses ::= SEQUENCE OF SEQUENCE { - addr-type[0] INTEGER, - address[1] OCTET STRING - } - - - The host adddress encodings consists of two fields: - - addr-type This field specifies the type of address that - follows. Pre-defined values for this field are - specified in section 8.1. - - - address This field encodes a single address of type addr-type. - - The two forms differ slightly. HostAddress contains exactly one - - - -Kohl & Neuman [Page 39] - -RFC 1510 Kerberos September 1993 - - - address; HostAddresses contains a sequence of possibly many - addresses. - - AuthorizationData ::= SEQUENCE OF SEQUENCE { - ad-type[0] INTEGER, - ad-data[1] OCTET STRING - } - - - ad-data This field contains authorization data to be - interpreted according to the value of the - corresponding ad-type field. - - ad-type This field specifies the format for the ad-data - subfield. All negative values are reserved for - local use. Non-negative values are reserved for - registered use. - - APOptions ::= BIT STRING { - reserved(0), - use-session-key(1), - mutual-required(2) - } - - - TicketFlags ::= BIT STRING { - reserved(0), - forwardable(1), - forwarded(2), - proxiable(3), - proxy(4), - may-postdate(5), - postdated(6), - invalid(7), - renewable(8), - initial(9), - pre-authent(10), - hw-authent(11) - } - - KDCOptions ::= BIT STRING { - reserved(0), - forwardable(1), - forwarded(2), - proxiable(3), - proxy(4), - allow-postdate(5), - postdated(6), - - - -Kohl & Neuman [Page 40] - -RFC 1510 Kerberos September 1993 - - - unused7(7), - renewable(8), - unused9(9), - unused10(10), - unused11(11), - renewable-ok(27), - enc-tkt-in-skey(28), - renew(30), - validate(31) - } - - - LastReq ::= SEQUENCE OF SEQUENCE { - lr-type[0] INTEGER, - lr-value[1] KerberosTime - } - - 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 - ticket-granting ticket 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). - - 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. - - See section 6 for the definitions of Checksum, ChecksumType, - EncryptedData, EncryptionKey, EncryptionType, and KeyType. - - - - - - - - -Kohl & Neuman [Page 41] - -RFC 1510 Kerberos September 1993 - - -5.3. Tickets and Authenticators - - This section describes the format and encryption parameters for - tickets and authenticators. When a ticket or authenticator is - included in a protocol message it is treated as an opaque object. - -5.3.1. Tickets - - A ticket is a record that helps a client authenticate to a service. - A Ticket contains the following information: - -Ticket ::= [APPLICATION 1] SEQUENCE { - tkt-vno[0] INTEGER, - realm[1] Realm, - sname[2] PrincipalName, - enc-part[3] EncryptedData -} --- Encrypted part of ticket -EncTicketPart ::= [APPLICATION 3] SEQUENCE { - flags[0] TicketFlags, - key[1] EncryptionKey, - crealm[2] Realm, - cname[3] PrincipalName, - transited[4] TransitedEncoding, - authtime[5] KerberosTime, - starttime[6] KerberosTime OPTIONAL, - endtime[7] KerberosTime, - renew-till[8] KerberosTime OPTIONAL, - caddr[9] HostAddresses OPTIONAL, - authorization-data[10] AuthorizationData OPTIONAL -} --- encoded Transited field -TransitedEncoding ::= SEQUENCE { - tr-type[0] INTEGER, -- must be registered - contents[1] OCTET STRING -} - - The encoding of EncTicketPart is encrypted in the key shared by - Kerberos and the end server (the server's secret key). See section 6 - for the format of the ciphertext. - - tkt-vno This field specifies the version number for the ticket - format. This document describes version number 5. - - realm This field specifies the realm that issued a ticket. It - also serves to identify the realm part of the server's - principal identifier. Since a Kerberos server can only - issue tickets for servers within its realm, the two will - - - -Kohl & Neuman [Page 42] - -RFC 1510 Kerberos September 1993 - - - always be identical. - - sname This field specifies the name part of the server's - identity. - - enc-part This field holds the encrypted encoding of the - EncTicketPart sequence. - - flags This field indicates which of various options were used or - requested when the ticket was issued. It 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). Bit 0 is the most significant bit. The - encoding of the bits is specified in section 5.2. The - flags are described in more detail above in section 2. The - meanings of the flags are: - - Bit(s) Name Description - - 0 RESERVED Reserved for future expansion of this - field. - - 1 FORWARDABLE The FORWARDABLE flag is normally only - interpreted by the TGS, and can be - ignored by end servers. When set, - this flag tells the ticket-granting - server that it is OK to issue a new - ticket- granting ticket with a - different network address based on - the presented ticket. - - 2 FORWARDED When set, this flag indicates that - the ticket has either been forwarded - or was issued based on authentication - involving a forwarded ticket-granting - ticket. - - 3 PROXIABLE The PROXIABLE flag is normally only - interpreted by the TGS, and can be - ignored by end servers. The PROXIABLE - flag has an interpretation identical - to that of the FORWARDABLE flag, - except that the PROXIABLE flag tells - the ticket-granting server that only - non- ticket-granting tickets may be - issued with different network - addresses. - - - - -Kohl & Neuman [Page 43] - -RFC 1510 Kerberos September 1993 - - - 4 PROXY When set, this flag indicates that a - ticket is a proxy. - - 5 MAY-POSTDATE The MAY-POSTDATE flag is normally - only interpreted by the TGS, and can - be ignored by end servers. This flag - tells the ticket-granting server that - a post- dated ticket may be issued - based on this ticket-granting ticket. - - 6 POSTDATED This flag indicates that this ticket - has been postdated. The end-service - can check the authtime field to see - when the original authentication - occurred. - - 7 INVALID This flag indicates that a ticket is - invalid, and it must be validated by - the KDC before use. Application - servers must reject tickets which - have this flag set. - - 8 RENEWABLE The RENEWABLE flag is normally only - interpreted by the TGS, and can - usually be ignored by end servers - (some particularly careful servers - may wish to disallow renewable - tickets). A renewable ticket can be - used to obtain a replacement ticket - that expires at a later date. - - 9 INITIAL This flag indicates that this ticket - was issued using the AS protocol, and - not issued based on a ticket-granting - ticket. - - 10 PRE-AUTHENT This flag indicates that during - initial authentication, the client - was authenticated by the KDC before a - ticket was issued. The strength of - the preauthentication method is not - indicated, but is acceptable to the - KDC. - - 11 HW-AUTHENT This flag indicates that the protocol - employed for initial authentication - required the use of hardware expected - to be possessed solely by the named - - - -Kohl & Neuman [Page 44] - -RFC 1510 Kerberos September 1993 - - - client. The hardware authentication - method is selected by the KDC and the - strength of the method is not - indicated. - - 12-31 RESERVED Reserved for future use. - - key This field exists in the ticket and the KDC response and is - used to pass the session key from Kerberos to the - application server and the client. The field's encoding is - described in section 6.2. - - crealm This field contains the name of the realm in which the - client is registered and in which initial authentication - took place. - - cname This field contains the name part of the client's principal - identifier. - - transited This field lists the names of the Kerberos realms that took - part in authenticating the user to whom this ticket was - issued. It does not specify the order in which the realms - were transited. See section 3.3.3.1 for details on how - this field encodes the traversed realms. - - authtime This field indicates the time of initial authentication for - the named principal. It is the time of issue for the - original ticket on which this ticket is based. It is - included in the ticket to provide additional information to - the end service, and to provide the necessary information - for implementation of a `hot list' service at the KDC. An - end service that is particularly paranoid could refuse to - accept tickets for which the initial authentication - occurred "too far" in the past. - - This field is also returned as part of the response from - the KDC. When returned as part of the response to initial - authentication (KRB_AS_REP), this is the current time on - the Kerberos server (It is NOT recommended that this time - value be used to adjust the workstation's clock since the - workstation cannot reliably determine that such a - KRB_AS_REP actually came from the proper KDC in a timely - manner.). - - starttime This field in the ticket specifies the time after which the - ticket is valid. Together with endtime, this field - specifies the life of the ticket. If it is absent from - the ticket, its value should be treated as that of the - - - -Kohl & Neuman [Page 45] - -RFC 1510 Kerberos September 1993 - - - authtime field. - - endtime This field contains the time after which the ticket will - not be honored (its expiration time). Note that individual - services may place their own limits on the life of a ticket - and may reject tickets which have not yet expired. As - such, this is really an upper bound on the expiration time - for the ticket. - - renew-till This field is only present in tickets that have the - RENEWABLE flag set in the flags field. It indicates the - maximum endtime that may be included in a renewal. It can - be thought of as the absolute expiration time for the - ticket, including all renewals. - - caddr This field in a ticket contains zero (if omitted) or more - (if present) host addresses. These are the addresses from - which the ticket can be used. If there are no addresses, - the ticket can be used from any location. The decision - by the KDC to issue or by the end server to accept zero- - address tickets is a policy decision and is left to the - Kerberos and end-service administrators; they may refuse to - issue or accept such tickets. The suggested and default - policy, however, is that such tickets will only be issued - or accepted when additional information that can be used to - restrict the use of the ticket is included in the - authorization_data field. Such a ticket is a capability. - - Network addresses are included in the ticket to make it - harder for an attacker to use stolen credentials. Because - the session key is not sent over the network in cleartext, - credentials can't be stolen simply by listening to the - network; an attacker has to gain access to the session key - (perhaps through operating system security breaches or a - careless user's unattended session) to make use of stolen - tickets. - - It is important to note that the network address from which - a connection is received cannot be reliably determined. - Even if it could be, an attacker who has compromised the - client's workstation could use the credentials from there. - Including the network addresses only makes it more - difficult, not impossible, for an attacker to walk off with - stolen credentials and then use them from a "safe" - location. - - - - - - -Kohl & Neuman [Page 46] - -RFC 1510 Kerberos September 1993 - - - authorization-data The authorization-data field is used to pass - authorization data from the principal on whose behalf a - ticket was issued to the application service. If no - authorization data is included, this field will be left - out. The data in this field are specific to the end - service. It is expected that the field will contain the - names of service specific objects, and the rights to those - objects. The format for this field is described in section - 5.2. Although Kerberos is not concerned with the format of - the contents of the subfields, it does carry type - information (ad-type). - - By using the authorization_data field, a principal is able - to issue a proxy that is valid for a specific purpose. For - example, a client wishing to print a file can obtain a file - server proxy to be passed to the print server. By - specifying the name of the file in the authorization_data - field, the file server knows that the print server can only - use the client's rights when accessing the particular file - to be printed. - - It is interesting to note that if one specifies the - authorization-data field of a proxy and leaves the host - addresses blank, the resulting ticket and session key can - be treated as a capability. See [9] for some suggested - uses of this field. - - The authorization-data field is optional and does not have - to be included in a ticket. - -5.3.2. Authenticators - - An authenticator is a record sent with a ticket to a server to - certify the client's knowledge of the encryption key in the ticket, - to help the server detect replays, and to help choose a "true session - key" to use with the particular session. The encoding is encrypted - in the ticket's session key shared by the client and the server: - --- Unencrypted authenticator -Authenticator ::= [APPLICATION 2] SEQUENCE { - authenticator-vno[0] INTEGER, - crealm[1] Realm, - cname[2] PrincipalName, - cksum[3] Checksum OPTIONAL, - cusec[4] INTEGER, - ctime[5] KerberosTime, - subkey[6] EncryptionKey OPTIONAL, - seq-number[7] INTEGER OPTIONAL, - - - -Kohl & Neuman [Page 47] - -RFC 1510 Kerberos September 1993 - - - 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.1. - - cksum This field contains a checksum of the the application data - that accompanies the KRB_AP_REQ. - - 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 which is 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. - - For sequence numbers to adequately support the detection of - replays 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. - - - - - - -Kohl & Neuman [Page 48] - -RFC 1510 Kerberos September 1993 - - - authorization-data This field is the same as described for the ticket - in section 5.3.1. 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.4. Specifications for the AS and TGS exchanges - - This section specifies the format of the messages used in 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 type of its own. Instead, its type is - one of KRB_AS_REQ or KRB_TGS_REQ 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 Authentication Server to - request credentials for a service. - -The message fields are: - -AS-REQ ::= [APPLICATION 10] KDC-REQ -TGS-REQ ::= [APPLICATION 12] KDC-REQ - -KDC-REQ ::= SEQUENCE { - pvno[1] INTEGER, - msg-type[2] INTEGER, - padata[3] SEQUENCE OF PA-DATA OPTIONAL, - req-body[4] KDC-REQ-BODY -} - -PA-DATA ::= SEQUENCE { - padata-type[1] INTEGER, - padata-value[2] OCTET STRING, - -- might be encoded AP-REQ -} - -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] INTEGER, - - - -Kohl & Neuman [Page 49] - -RFC 1510 Kerberos September 1993 - - - etype[8] SEQUENCE OF INTEGER, -- EncryptionType, - -- in preference order - addresses[9] HostAddresses OPTIONAL, - enc-authorization-data[10] EncryptedData OPTIONAL, - -- Encrypted AuthorizationData encoding - additional-tickets[11] SEQUENCE OF Ticket OPTIONAL -} - - The fields in this message are: - - 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 The padata (pre-authentication data) field contains a of - authentication information which may be needed before - credentials can be issued or decrypted. In the case of - requests for additional tickets (KRB_TGS_REQ), this field - will include an element with padata-type of PA-TGS-REQ and - data of an authentication header (ticket-granting ticket - and authenticator). The checksum in the authenticator - (which must be collisionproof) is to be computed over the - KDC-REQ-BODY encoding. In most requests for initial - authentication (KRB_AS_REQ) and most replies (KDC-REP), the - padata field will be left out. - - This field may also contain information needed by certain - extensions to the Kerberos protocol. For example, it might - be used to initially verify the identity of a client before - any response is returned. This is accomplished with a - padata field with padata-type equal to PA-ENC-TIMESTAMP and - padata-value defined as follows: - - padata-type ::= PA-ENC-TIMESTAMP - padata-value ::= EncryptedData -- PA-ENC-TS-ENC - - PA-ENC-TS-ENC ::= SEQUENCE { - patimestamp[0] KerberosTime, -- client's time - pausec[1] INTEGER OPTIONAL - } - - - - -Kohl & Neuman [Page 50] - -RFC 1510 Kerberos September 1993 - - - with patimestamp containing the client's time and pausec - containing the microseconds which may be omitted if a - client will not generate more than one request per second. - The ciphertext (padata-value) consists of the PA-ENC-TS-ENC - sequence, encrypted using the client's secret key. - - The padata field can also contain information needed to - help the KDC or the client select the key needed for - generating or decrypting the response. This form of the - padata is useful for supporting the use of certain - "smartcards" with Kerberos. The details of such extensions - are beyond the scope of this specification. See [10] for - additional uses of this field. - - padata-type The padata-type element of the padata field indicates the - way that the padata-value element is to be interpreted. - Negative values of padata-type are reserved for - unregistered use; non-negative values are used for a - registered interpretation of the element type. - - 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 case, 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 to simply - copy the options field to the flags field. There are - various checks that must be made before honoring an option - 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: - - - - - - - -Kohl & Neuman [Page 51] - -RFC 1510 Kerberos September 1993 - - - Bit(s) 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 ticket- - granting ticket 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 - ticket-granting ticket 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 in a - subsequent request if the ticket- - granting ticket 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 ticket- - granting ticket 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 - - - -Kohl & Neuman [Page 52] - -RFC 1510 Kerberos September 1993 - - - the ticket-granting ticket 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 ticket-granting ticket - 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 UNUSED 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 ticket-granting ticket 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-26 RESERVED Reserved for future use. - - 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. If a - ticket with the requested life cannot - be provided, then a renewable ticket - may be issued with a renew-till equal - to the 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 - - - -Kohl & Neuman [Page 53] - -RFC 1510 Kerberos September 1993 - - - encrypted in the session key from the - additional ticket-granting ticket - 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 be - otherwise 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.1. sname may only be absent when the - ENC-TKT-IN-SKEY option is specified. If 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 ticket-granting - ticket, both from the padata field in the KRB_AP_REQ. - - - - -Kohl & Neuman [Page 54] - -RFC 1510 Kerberos September 1993 - - - 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 start time for the - requested ticket. - - till This field contains the expiration date requested by the - client in a ticket request. - - 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 it - 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 re-used. Ideally, it should be gen erated - randomly, but if the correct time is known, it may suffice - (Note, however, that if the time is used as the nonce, one - must make sure that the workstation time is monotonically - increasing. If the time is ever reset backwards, there is - a small, but finite, probability that a nonce will 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 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. If more than one option - which 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). - - - -Kohl & Neuman [Page 55] - -RFC 1510 Kerberos September 1993 - - - The application code 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. - - It should be noted 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, or if absent, the session key - from the ticket-granting ticket 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, - msg-type[1] INTEGER, - padata[2] SEQUENCE OF PA-DATA OPTIONAL, - crealm[3] Realm, - cname[4] PrincipalName, - ticket[5] Ticket, - enc-part[6] EncryptedData - } - - EncASRepPart ::= [APPLICATION 25[25]] EncKDCRepPart - EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart - - EncKDCRepPart ::= SEQUENCE { - key[0] EncryptionKey, - last-req[1] LastReq, - - - -Kohl & Neuman [Page 56] - -RFC 1510 Kerberos September 1993 - - - nonce[2] INTEGER, - 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 - } - - NOTE: In EncASRepPart, the application code in the encrypted - part of a message provides an additional check that - the message was decrypted properly. - - 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 this field is to encode an alternate - "mix-in" string to be used with a string-to-key algorithm - (such as is described in section 6.3.2). This ability is - useful to ease 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 mix-in 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.1. - - ticket The newly-issued ticket, from section 5.3.1. - - 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 encrypted part - is encoded as described in section 6.1. - - key This field is the same as described for the ticket in - section 5.3.1. - - 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 ticket-granting ticket was made, or the - last time that a request based on a ticket-granting ticket - - - -Kohl & Neuman [Page 57] - -RFC 1510 Kerberos September 1993 - - - 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 into timesharing systems. - - 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. 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 need 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 - expira tion 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.1), - provided so the client may verify they match the intended - request and 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 ticket granting ticket. 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 ticket-granting ticket. - -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, - msg-type[1] INTEGER, - - - -Kohl & Neuman [Page 58] - -RFC 1510 Kerberos September 1993 - - - ap-options[2] APOptions, - ticket[3] Ticket, - authenticator[4] EncryptedData - } - - APOptions ::= BIT STRING { - 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 being reset (0). The encoding of the bits is - specified in section 5.2. The meanings of the options are: - - Bit(s) Name Description - - 0 RESERVED Reserved for future expansion of - this field. - - 1 USE-SESSION-KEYThe 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 - ticket-granting ticket. When this - option is not specified, the ticket is - encrypted in the server's secret key. - - 2 MUTUAL-REQUIREDThe 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 authenticator, which includes the - client's choice of a subkey. Its encoding is described in - section 5.3.2. - - - - -Kohl & Neuman [Page 59] - -RFC 1510 Kerberos September 1993 - - -5.5.2. KRB_AP_REP definition - - The KRB_AP_REP message contains the Kerberos protocol version number, - the message type, and an encrypted timestamp. The message is sent in - in response to an application request (KRB_AP_REQ) where the mutual - authentication option has been selected in the ap-options field. - - AP-REP ::= [APPLICATION 15] SEQUENCE { - pvno[0] INTEGER, - msg-type[1] INTEGER, - enc-part[2] EncryptedData - } - - EncAPRepPart ::= [APPLICATION 27] SEQUENCE { - ctime[0] KerberosTime, - cusec[1] INTEGER, - subkey[2] EncryptionKey OPTIONAL, - seq-number[3] INTEGER OPTIONAL - } - - NOTE: in EncAPRepPart, the application code in the encrypted part of - a message provides an additional check that the message was decrypted - properly. - - 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. - - 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 which 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 also left out, the session key from - the ticket will be used. - - - - - -Kohl & Neuman [Page 60] - -RFC 1510 Kerberos September 1993 - - -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 session key. The message fields are: - - KRB-SAFE ::= [APPLICATION 20] SEQUENCE { - pvno[0] INTEGER, - msg-type[1] INTEGER, - safe-body[2] KRB-SAFE-BODY, - cksum[3] Checksum - } - - KRB-SAFE-BODY ::= SEQUENCE { - user-data[0] OCTET STRING, - timestamp[1] KerberosTime OPTIONAL, - usec[2] INTEGER OPTIONAL, - seq-number[3] INTEGER 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. It is to be encoded separately and then have the - checksum computed over it, for use in the cksum field. - - cksum This field contains the checksum of the application data. - Checksum details are described in section 6.4. The - - - -Kohl & Neuman [Page 61] - -RFC 1510 Kerberos September 1993 - - - checksum is computed over the encoding of the KRB-SAFE-BODY - sequence. - - user-data This field is part of the KRB_SAFE and KRB_PRIV messages - and contain 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 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 which 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 securely and - privately send a 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.7.1. KRB_PRIV definition - - The KRB_PRIV message contains user data encrypted in the Session Key. - The message fields are: - - KRB-PRIV ::= [APPLICATION 21] SEQUENCE { - pvno[0] INTEGER, - msg-type[1] INTEGER, - enc-part[3] EncryptedData - } - - - - - -Kohl & Neuman [Page 62] - -RFC 1510 Kerberos September 1993 - - - EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { - user-data[0] OCTET STRING, - timestamp[1] KerberosTime OPTIONAL, - usec[2] INTEGER OPTIONAL, - seq-number[3] INTEGER OPTIONAL, - s-address[4] HostAddress, -- sender's addr - r-address[5] HostAddress OPTIONAL - -- recip's addr - } - - NOTE: In EncKrbPrivPart, the application code in the encrypted part - of a message provides an additional check that the message was - decrypted properly. - - 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 (If supported by the - encryption method in use, an initialization vector may be - passed to the encryption procedure, in order to achieve - proper cipher chaining. The initialization vector might - come from the last block of the ciphertext from the - previous KRB_PRIV message, but it is the application's - choice whether or not to use such an initialization vector. - If left out, the default initialization vector for the - encryption algorithm will be used.). This encrypted - encoding is used for the enc-part field of the KRB-PRIV - message. See section 6 for the format of the ciphertext. - - 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 - - - -Kohl & Neuman [Page 63] - -RFC 1510 Kerberos September 1993 - - - each. The information needed to use the tickets is encryped under an - encryption key previously exchanged. The message fields are: - - KRB-CRED ::= [APPLICATION 22] SEQUENCE { - pvno[0] INTEGER, - msg-type[1] INTEGER, -- KRB_CRED - tickets[2] SEQUENCE OF Ticket, - enc-part[3] EncryptedData - } - - EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { - ticket-info[0] SEQUENCE OF KrbCredInfo, - nonce[1] INTEGER OPTIONAL, - timestamp[2] KerberosTime OPTIONAL, - usec[3] INTEGER 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 between the sender - and the intended recipient. This encrypted encoding is - used for the enc-part field of the KRB-CRED message. See - section 6 for the format of the ciphertext. - - - -Kohl & Neuman [Page 64] - -RFC 1510 Kerberos September 1993 - - - 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 re- - used; it should be generated randomly by the recipient of - the message and provided to the sender of the mes sage in - an application specific manner. - - 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 6.2. - - 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 value. - - 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 since the KRB_ERROR message is not protected by any - encryption, it is quite possible for an intruder to synthesize or - - - -Kohl & Neuman [Page 65] - -RFC 1510 Kerberos September 1993 - - - modify such a message. 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, - msg-type[1] INTEGER, - ctime[2] KerberosTime OPTIONAL, - cusec[3] INTEGER OPTIONAL, - stime[4] KerberosTime, - susec[5] INTEGER, - error-code[6] INTEGER, - crealm[7] Realm OPTIONAL, - cname[8] PrincipalName OPTIONAL, - realm[9] Realm, -- Correct realm - sname[10] PrincipalName, -- Correct name - e-text[11] GeneralString 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 This field is described above in section 5.4.1. - - cusec This field is described above in section 5.5.2. - - 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 999. 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 8. - Implementations are encouraged to provide for national - language support in the display of error messages. - - crealm, cname, srealm and sname These fields are described above in - - - -Kohl & Neuman [Page 66] - -RFC 1510 Kerberos September 1993 - - - section 5.3.1. - - 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 - - If the error-code is KRB_AP_ERR_METHOD, then the e-data field will - contain an encoding of the following sequence: - - METHOD-DATA ::= SEQUENCE { - method-type[0] INTEGER, - method-data[1] OCTET STRING OPTIONAL - } - - method-type will indicate the required alternate method; method-data - will contain any required additional information. - -6. Encryption and Checksum Specifications - - The Kerberos protocols described in this document are designed to use - stream encryption ciphers, which can be simulated using commonly - available block encryption ciphers, such as the Data Encryption - Standard [11], in conjunction with block chaining and checksum - methods [12]. Encryption is used to prove the identities of the - network entities participating in message exchanges. The Key - Distribution Center for each realm is trusted by all principals - registered in that realm to store a secret key in confidence. Proof - of knowledge of this secret key is used to verify the authenticity of - a principal. - - The KDC uses the principal's secret key (in the AS exchange) or a - shared session key (in the TGS exchange) to encrypt responses to - ticket requests; the ability to obtain the secret key or session key - implies the knowledge of the appropriate keys and the identity of the - KDC. The ability of a principal to decrypt the KDC response and - present a Ticket and a properly formed Authenticator (generated with - the session key from the KDC response) to a service verifies the - identity of the principal; likewise the ability of the service to - - - -Kohl & Neuman [Page 67] - -RFC 1510 Kerberos September 1993 - - - extract the session key from the Ticket and prove its knowledge - thereof in a response verifies the identity of the service. - - The Kerberos protocols generally assume that the encryption used is - secure from cryptanalysis; however, in some cases, the order of - fields in the encrypted portions of messages are arranged to minimize - the effects of poorly chosen keys. It is still important to choose - good keys. If keys are derived from user-typed passwords, those - passwords need to be well chosen to make brute force attacks more - difficult. Poorly chosen keys still make easy targets for intruders. - - The following sections specify the encryption and checksum mechanisms - currently defined for Kerberos. The encodings, chaining, and padding - requirements for each are described. For encryption methods, it is - often desirable to place random information (often referred to as a - confounder) at the start of the message. The requirements for a - confounder are specified with each encryption mechanism. - - Some encryption systems use a block-chaining method to improve the - the security characteristics of the ciphertext. However, these - chaining methods often don't provide an integrity check upon - decryption. Such systems (such as DES in CBC mode) must be augmented - with a checksum of the plaintext which can be verified at decryption - and used to detect any tampering or damage. Such checksums should be - good at detecting burst errors in the input. If any damage is - detected, the decryption routine is expected to return an error - indicating the failure of an integrity check. Each encryption type is - expected to provide and verify an appropriate checksum. The - specification of each encryption method sets out its checksum - requirements. - - Finally, where a key is to be derived from a user's password, an - algorithm for converting the password to a key of the appropriate - type is included. It is desirable for the string to key function to - be one-way, and for the mapping to be different in different realms. - This is important because users who are registered in more than one - realm will often use the same password in each, and it is desirable - that an attacker compromising the Kerberos server in one realm not - obtain or derive the user's key in another. - - For a discussion of the integrity characteristics of the candidate - encryption and checksum methods considered for Kerberos, the the - reader is referred to [13]. - -6.1. Encryption Specifications - - The following ASN.1 definition describes all encrypted messages. The - enc-part field which appears in the unencrypted part of messages in - - - -Kohl & Neuman [Page 68] - -RFC 1510 Kerberos September 1993 - - - section 5 is a sequence consisting of an encryption type, an optional - key version number, and the ciphertext. - - EncryptedData ::= SEQUENCE { - etype[0] INTEGER, -- EncryptionType - kvno[1] INTEGER OPTIONAL, - cipher[2] OCTET STRING -- ciphertext - } - - etype This field identifies which encryption algorithm was used - to encipher the cipher. Detailed specifications for - selected encryption types appear later in this section. - - kvno This field contains the version number of the key under - which data is encrypted. It is only present in messages - encrypted under long lasting keys, such as principals' - secret keys. - - cipher This field contains the enciphered text, encoded as an - OCTET STRING. - - The cipher field is generated by applying the specified encryption - algorithm to data composed of the message and algorithm-specific - inputs. Encryption mechanisms defined for use with Kerberos must - take sufficient measures to guarantee the integrity of the plaintext, - and we recommend they also take measures to protect against - precomputed dictionary attacks. If the encryption algorithm is not - itself capable of doing so, the protections can often be enhanced by - adding a checksum and a confounder. - - The suggested format for the data to be encrypted includes a - confounder, a checksum, the encoded plaintext, and any necessary - padding. The msg-seq field contains the part of the protocol message - described in section 5 which is to be encrypted. The confounder, - checksum, and padding are all untagged and untyped, and their length - is exactly sufficient to hold the appropriate item. The type and - length is implicit and specified by the particular encryption type - being used (etype). The format for the data to be encrypted is - described in the following diagram: - - +-----------+----------+-------------+-----+ - |confounder | check | msg-seq | pad | - +-----------+----------+-------------+-----+ - - The format cannot be described in ASN.1, but for those who prefer an - ASN.1-like notation: - - - - - -Kohl & Neuman [Page 69] - -RFC 1510 Kerberos September 1993 - - -CipherText ::= ENCRYPTED SEQUENCE { - confounder[0] UNTAGGED OCTET STRING(conf_length) OPTIONAL, - check[1] UNTAGGED OCTET STRING(checksum_length) OPTIONAL, - msg-seq[2] MsgSequence, - pad UNTAGGED OCTET STRING(pad_length) OPTIONAL -} - - In the above specification, UNTAGGED OCTET STRING(length) is the - notation for an octet string with its tag and length removed. It is - not a valid ASN.1 type. The tag bits and length must be removed from - the confounder since the purpose of the confounder is so that the - message starts with random data, but the tag and its length are - fixed. For other fields, the length and tag would be redundant if - they were included because they are specified by the encryption type. - - One generates a random confounder of the appropriate length, placing - it in confounder; zeroes out check; calculates the appropriate - checksum over confounder, check, and msg-seq, placing the result in - check; adds the necessary padding; then encrypts using the specified - encryption type and the appropriate key. - - Unless otherwise specified, a definition of an encryption algorithm - that specifies a checksum, a length for the confounder field, or an - octet boundary for padding uses this ciphertext format (The ordering - of the fields in the CipherText is important. Additionally, messages - encoded in this format must include a length as part of the msg-seq - field. This allows the recipient to verify that the message has not - been truncated. Without a length, an attacker could use a chosen - plaintext attack to generate a message which could be truncated, - while leaving the checksum intact. Note that if the msg-seq is an - encoding of an ASN.1 SEQUENCE or OCTET STRING, then the length is - part of that encoding.). Those fields which are not specified will be - omitted. - - In the interest of allowing all implementations using a particular - encryption type to communicate with all others using that type, the - specification of an encryption type defines any checksum that is - needed as part of the encryption process. If an alternative checksum - is to be used, a new encryption type must be defined. - - Some cryptosystems require additional information beyond the key and - the data to be encrypted. For example, DES, when used in cipher- - block-chaining mode, requires an initialization vector. If required, - the description for each encryption type must specify the source of - such additional information. - - - - - - -Kohl & Neuman [Page 70] - -RFC 1510 Kerberos September 1993 - - -6.2. Encryption Keys - - The sequence below shows the encoding of an encryption key: - - EncryptionKey ::= SEQUENCE { - keytype[0] INTEGER, - keyvalue[1] OCTET STRING - } - - keytype This field specifies the type of encryption key that - follows in the keyvalue field. It will almost always - correspond to the encryption algorithm used to generate the - EncryptedData, though more than one algorithm may use the - same type of key (the mapping is many to one). This might - happen, for example, if the encryption algorithm uses an - alternate checksum algorithm for an integrity check, or a - different chaining mechanism. - - keyvalue This field contains the key itself, encoded as an octet - string. - - All negative values for the encryption key type are reserved for - local use. All non-negative values are reserved for officially - assigned type fields and interpretations. - -6.3. Encryption Systems - -6.3.1. The NULL Encryption System (null) - - If no encryption is in use, the encryption system is said to be the - NULL encryption system. In the NULL encryption system there is no - checksum, confounder or padding. The ciphertext is simply the - plaintext. The NULL Key is used by the null encryption system and is - zero octets in length, with keytype zero (0). - -6.3.2. DES in CBC mode with a CRC-32 checksum (des-cbc-crc) - - The des-cbc-crc encryption mode encrypts information under the Data - Encryption Standard [11] using the cipher block chaining mode [12]. - A CRC-32 checksum (described in ISO 3309 [14]) is applied to the - confounder and message sequence (msg-seq) and placed in the cksum - field. DES blocks are 8 bytes. As a result, the data to be - encrypted (the concatenation of confounder, checksum, and message) - must be padded to an 8 byte boundary before encryption. The details - of the encryption of this data are identical to those for the des- - cbc-md5 encryption mode. - - Note that, since the CRC-32 checksum is not collisionproof, an - - - -Kohl & Neuman [Page 71] - -RFC 1510 Kerberos September 1993 - - - attacker could use a probabilistic chosenplaintext attack to generate - a valid message even if a confounder is used [13]. The use of - collision-proof checksums is recommended for environments where such - attacks represent a significant threat. The use of the CRC-32 as the - checksum for ticket or authenticator is no longer mandated as an - interoperability requirement for Kerberos Version 5 Specification 1 - (See section 9.1 for specific details). - -6.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4) - - The des-cbc-md4 encryption mode encrypts information under the Data - Encryption Standard [11] using the cipher block chaining mode [12]. - An MD4 checksum (described in [15]) is applied to the confounder and - message sequence (msg-seq) and placed in the cksum field. DES blocks - are 8 bytes. As a result, the data to be encrypted (the - concatenation of confounder, checksum, and message) must be padded to - an 8 byte boundary before encryption. The details of the encryption - of this data are identical to those for the descbc-md5 encryption - mode. - -6.3.4. DES in CBC mode with an MD5 checksum (des-cbc-md5) - - The des-cbc-md5 encryption mode encrypts information under the Data - Encryption Standard [11] using the cipher block chaining mode [12]. - An MD5 checksum (described in [16]) is applied to the confounder and - message sequence (msg-seq) and placed in the cksum field. DES blocks - are 8 bytes. As a result, the data to be encrypted (the - concatenation of confounder, checksum, and message) must be padded to - an 8 byte boundary before encryption. - - Plaintext and DES ciphtertext are encoded as 8-octet blocks which are - concatenated to make the 64-bit inputs for the DES algorithms. The - first octet supplies the 8 most significant bits (with the octet's - MSbit used as the DES input block's MSbit, etc.), the second octet - the next 8 bits, ..., and the eighth octet supplies the 8 least - significant bits. - - Encryption under DES using cipher block chaining requires an - additional input in the form of an initialization vector. Unless - otherwise specified, zero should be used as the initialization - vector. Kerberos' use of DES requires an 8-octet confounder. - - The DES specifications identify some "weak" and "semiweak" keys; - those keys shall not be used for encrypting messages for use in - Kerberos. Additionally, because of the way that keys are derived for - the encryption of checksums, keys shall not be used that yield "weak" - or "semi-weak" keys when eXclusive-ORed with the constant - F0F0F0F0F0F0F0F0. - - - -Kohl & Neuman [Page 72] - -RFC 1510 Kerberos September 1993 - - - A DES key is 8 octets of data, with keytype one (1). This consists - of 56 bits of key, and 8 parity bits (one per octet). The key is - encoded as a series of 8 octets written in MSB-first order. The bits - within the key are also encoded in MSB order. For example, if the - encryption key is: - (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) where - B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the - parity bits, the first octet of the key would be B1,B2,...,B7,P1 - (with B1 as the MSbit). [See the FIPS 81 introduction for - reference.] - - To generate a DES key from a text string (password), the text string - normally must have the realm and each component of the principal's - name appended(In some cases, it may be necessary to use a different - "mix-in" string for compatibility reasons; see the discussion of - padata in section 5.4.2.), then padded with ASCII nulls to an 8 byte - boundary. This string is then fan-folded and eXclusive-ORed with - itself to form an 8 byte DES key. The parity is corrected on the - key, and it is used to generate a DES CBC checksum on the initial - string (with the realm and name appended). Next, parity is corrected - on the CBC checksum. If the result matches a "weak" or "semiweak" - key as described in the DES specification, it is eXclusive-ORed with - the constant 00000000000000F0. Finally, the result is returned as - the key. Pseudocode follows: - - string_to_key(string,realm,name) { - odd = 1; - s = string + realm; - for(each component in name) { - s = s + component; - } - tempkey = NULL; - pad(s); /* with nulls to 8 byte boundary */ - for(8byteblock in s) { - if(odd == 0) { - odd = 1; - reverse(8byteblock) - } - else odd = 0; - tempkey = tempkey XOR 8byteblock; - } - fixparity(tempkey); - key = DES-CBC-check(s,tempkey); - fixparity(key); - if(is_weak_key_key(key)) - key = key XOR 0xF0; - return(key); - } - - - -Kohl & Neuman [Page 73] - -RFC 1510 Kerberos September 1993 - - -6.4. Checksums - - The following is the ASN.1 definition used for a checksum: - - Checksum ::= SEQUENCE { - cksumtype[0] INTEGER, - checksum[1] OCTET STRING - } - - cksumtype This field indicates the algorithm used to generate the - accompanying checksum. - - checksum This field contains the checksum itself, encoded - as an octet string. - - Detailed specification of selected checksum types appear later in - this section. Negative values for the checksum type are reserved for - local use. All non-negative values are reserved for officially - assigned type fields and interpretations. - - Checksums used by Kerberos can be classified by two properties: - whether they are collision-proof, and whether they are keyed. It is - infeasible to find two plaintexts which generate the same checksum - value for a collision-proof checksum. A key is required to perturb - or initialize the algorithm in a keyed checksum. To prevent - message-stream modification by an active attacker, unkeyed checksums - should only be used when the checksum and message will be - subsequently encrypted (e.g., the checksums defined as part of the - encryption algorithms covered earlier in this section). Collision- - proof checksums can be made tamper-proof as well if the checksum - value is encrypted before inclusion in a message. In such cases, the - composition of the checksum and the encryption algorithm must be - considered a separate checksum algorithm (e.g., RSA-MD5 encrypted - using DES is a new checksum algorithm of type RSA-MD5-DES). For most - keyed checksums, as well as for the encrypted forms of collisionproof - checksums, Kerberos prepends a confounder before the checksum is - calculated. - -6.4.1. The CRC-32 Checksum (crc32) - - The CRC-32 checksum calculates a checksum based on a cyclic - redundancy check as described in ISO 3309 [14]. The resulting - checksum is four (4) octets in length. The CRC-32 is neither keyed - nor collision-proof. The use of this checksum is not recommended. - An attacker using a probabilistic chosen-plaintext attack as - described in [13] might be able to generate an alternative message - that satisfies the checksum. The use of collision-proof checksums is - recommended for environments where such attacks represent a - - - -Kohl & Neuman [Page 74] - -RFC 1510 Kerberos September 1993 - - - significant threat. - -6.4.2. The RSA MD4 Checksum (rsa-md4) - - The RSA-MD4 checksum calculates a checksum using the RSA MD4 - algorithm [15]. The algorithm takes as input an input message of - arbitrary length and produces as output a 128-bit (16 octet) - checksum. RSA-MD4 is believed to be collision-proof. - -6.4.3. RSA MD4 Cryptographic Checksum Using DES (rsa-md4des) - - The RSA-MD4-DES checksum calculates a keyed collisionproof checksum - by prepending an 8 octet confounder before the text, applying the RSA - MD4 checksum algorithm, and encrypting the confounder and the - checksum using DES in cipher-block-chaining (CBC) mode using a - variant of the key, where the variant is computed by eXclusive-ORing - the key with the constant F0F0F0F0F0F0F0F0 (A variant of the key is - used to limit the use of a key to a particular function, separating - the functions of generating a checksum from other encryption - performed using the session key. The constant F0F0F0F0F0F0F0F0 was - chosen because it maintains key parity. The properties of DES - precluded the use of the complement. The same constant is used for - similar purpose in the Message Integrity Check in the Privacy - Enhanced Mail standard.). The initialization vector should be zero. - The resulting checksum is 24 octets long (8 octets of which are - redundant). This checksum is tamper-proof and believed to be - collision-proof. - - The DES specifications identify some "weak keys"; those keys shall - not be used for generating RSA-MD4 checksums for use in Kerberos. - - The format for the checksum is described in the following diagram: - - +--+--+--+--+--+--+--+-- - | des-cbc(confounder - +--+--+--+--+--+--+--+-- - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - rsa-md4(confounder+msg),key=var(key),iv=0) | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - The format cannot be described in ASN.1, but for those who prefer an - ASN.1-like notation: - - rsa-md4-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { - confounder[0] UNTAGGED OCTET STRING(8), - check[1] UNTAGGED OCTET STRING(16) - } - - - -Kohl & Neuman [Page 75] - -RFC 1510 Kerberos September 1993 - - -6.4.4. The RSA MD5 Checksum (rsa-md5) - - The RSA-MD5 checksum calculates a checksum using the RSA MD5 - algorithm [16]. The algorithm takes as input an input message of - arbitrary length and produces as output a 128-bit (16 octet) - checksum. RSA-MD5 is believed to be collision-proof. - -6.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5des) - - The RSA-MD5-DES checksum calculates a keyed collisionproof checksum - by prepending an 8 octet confounder before the text, applying the RSA - MD5 checksum algorithm, and encrypting the confounder and the - checksum using DES in cipher-block-chaining (CBC) mode using a - variant of the key, where the variant is computed by eXclusive-ORing - the key with the constant F0F0F0F0F0F0F0F0. The initialization - vector should be zero. The resulting checksum is 24 octets long (8 - octets of which are redundant). This checksum is tamper-proof and - believed to be collision-proof. - - The DES specifications identify some "weak keys"; those keys shall - not be used for encrypting RSA-MD5 checksums for use in Kerberos. - - The format for the checksum is described in the following diagram: - - +--+--+--+--+--+--+--+-- - | des-cbc(confounder - +--+--+--+--+--+--+--+-- - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - rsa-md5(confounder+msg),key=var(key),iv=0) | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - The format cannot be described in ASN.1, but for those who prefer an - ASN.1-like notation: - - rsa-md5-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { - confounder[0] UNTAGGED OCTET STRING(8), - check[1] UNTAGGED OCTET STRING(16) - } - -6.4.6. DES cipher-block chained checksum (des-mac) - - The DES-MAC checksum is computed by prepending an 8 octet confounder - to the plaintext, performing a DES CBC-mode encryption on the result - using the key and an initialization vector of zero, taking the last - block of the ciphertext, prepending the same confounder and - encrypting the pair using DES in cipher-block-chaining (CBC) mode - using a a variant of the key, where the variant is computed by - - - -Kohl & Neuman [Page 76] - -RFC 1510 Kerberos September 1993 - - - eXclusive-ORing the key with the constant F0F0F0F0F0F0F0F0. The - initialization vector should be zero. The resulting checksum is 128 - bits (16 octets) long, 64 bits of which are redundant. This checksum - is tamper-proof and collision-proof. - - The format for the checksum is described in the following diagram: - - +--+--+--+--+--+--+--+-- - | des-cbc(confounder - +--+--+--+--+--+--+--+-- - - +-----+-----+-----+-----+-----+-----+-----+-----+ - des-mac(conf+msg,iv=0,key),key=var(key),iv=0) | - +-----+-----+-----+-----+-----+-----+-----+-----+ - - The format cannot be described in ASN.1, but for those who prefer an - ASN.1-like notation: - - des-mac-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { - confounder[0] UNTAGGED OCTET STRING(8), - check[1] UNTAGGED OCTET STRING(8) - } - - The DES specifications identify some "weak" and "semiweak" keys; - those keys shall not be used for generating DES-MAC checksums for use - in Kerberos, nor shall a key be used whose veriant is "weak" or - "semi-weak". - -6.4.7. RSA MD4 Cryptographic Checksum Using DES alternative - (rsa-md4-des-k) - - The RSA-MD4-DES-K checksum calculates a keyed collision-proof - checksum by applying the RSA MD4 checksum algorithm and encrypting - the results using DES in cipherblock-chaining (CBC) mode using a DES - key as both key and initialization vector. The resulting checksum is - 16 octets long. This checksum is tamper-proof and believed to be - collision-proof. Note that this checksum type is the old method for - encoding the RSA-MD4-DES checksum and it is no longer recommended. - -6.4.8. DES cipher-block chained checksum alternative (desmac-k) - - The DES-MAC-K checksum is computed by performing a DES CBC-mode - encryption of the plaintext, and using the last block of the - ciphertext as the checksum value. It is keyed with an encryption key - and an initialization vector; any uses which do not specify an - additional initialization vector will use the key as both key and - initialization vector. The resulting checksum is 64 bits (8 octets) - long. This checksum is tamper-proof and collision-proof. Note that - - - -Kohl & Neuman [Page 77] - -RFC 1510 Kerberos September 1993 - - - this checksum type is the old method for encoding the DESMAC checksum - and it is no longer recommended. - - The DES specifications identify some "weak keys"; those keys shall - not be used for generating DES-MAC checksums for use in Kerberos. - -7. Naming Constraints - -7.1. Realm Names - - Although realm names are encoded as GeneralStrings and although a - realm can technically 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. - - There are presently four styles of realm names: domain, X500, other, - and reserved. Examples of each style follow: - - domain: host.subdomain.domain (example) - X500: C=US/O=OSF (example) - other: NAMETYPE:rest/of.name=without-restrictions (example) - reserved: reserved, but will not conflict with above - - Domain names must look like domain names: they consist of components - separated by periods (.) and they contain neither colons (:) nor - slashes (/). - - X.500 names contain an equal (=) and cannot contain a colon (:) - before the equal. 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. - - Names that fall into the other category must begin with a prefix that - contains no equal (=) or period (.) and the prefix must be followed - by a colon (:) and the rest of the name. All prefixes must be - assigned before they may be used. Presently none are assigned. - - The reserved category includes strings which 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 - - - -Kohl & Neuman [Page 78] - -RFC 1510 Kerberos September 1993 - - - various name styles. The following additional constraints apply to - the assignment of realm names in the domain and X.500 categories: the - name of a realm for the domain or X.500 formats must either 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 there will not in the future exists a name identical to the - realm name of the child unless it is assigned to the same entity as - the realm name. - -7.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 as a hint. 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). This constraint may be eliminated in the future. 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 - - 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). - - - -Kohl & Neuman [Page 79] - -RFC 1510 Kerberos September 1993 - - - 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 ticket - which has a first component of krbtgt and a second component - identifying the realm for which the ticket is valid. - - If instance is a single component following the service name and the - instance identifies 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 SRVXHST 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 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 8.2.3 for the - form of such names. - -7.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 lower case. For services such as telnet and the - Berkeley R commands which run with system privileges, the first - component will be the string "host" instead of a service specific - identifier. - -8. Constants and other defined values - -8.1. Host address types - - All negative values for the host address type are reserved for local - use. All non-negative values are reserved for officially assigned - - - -Kohl & Neuman [Page 80] - -RFC 1510 Kerberos September 1993 - - - type fields and interpretations. - - The values of the types for the following addresses are chosen to - match the defined address family constants in the Berkeley Standard - Distributions of Unix. They can be found in with - symbolic names AF_xxx (where xxx is an abbreviation of the address - family name). - - - Internet addresses - - Internet addresses are 32-bit (4-octet) quantities, encoded in MSB - order. The type of internet addresses is two (2). - - CHAOSnet addresses - - CHAOSnet addresses are 16-bit (2-octet) quantities, encoded in MSB - order. The type of CHAOSnet addresses is five (5). - - ISO addresses - - ISO addresses are variable-length. The type of ISO addresses is - seven (7). - - Xerox Network Services (XNS) addresses - - XNS addresses are 48-bit (6-octet) quantities, encoded in MSB - order. The type of XNS addresses is six (6). - - AppleTalk Datagram Delivery Protocol (DDP) addresses - - AppleTalk DDP addresses consist of an 8-bit node number and a 16- - bit network number. The first octet of the address is the node - number; the remaining two octets encode the network number in MSB - order. The type of AppleTalk DDP addresses is sixteen (16). - - DECnet Phase IV addresses - - DECnet Phase IV addresses are 16-bit addresses, encoded in LSB - order. The type of DECnet Phase IV addresses is twelve (12). - -8.2. KDC messages - -8.2.1. IP transport - - When contacting a Kerberos server (KDC) for a KRB_KDC_REQ request - using IP transport, the client shall send a UDP datagram containing - only an encoding of the request to port 88 (decimal) at the KDC's IP - - - -Kohl & Neuman [Page 81] - -RFC 1510 Kerberos September 1993 - - - address; the KDC will respond with a reply datagram containing only - an encoding of the reply message (either a KRB_ERROR or a - KRB_KDC_REP) to the sending port at the sender's IP address. - -8.2.2. OSI transport - - During authentication of an OSI client to and OSI server, the mutual - authentication of an OSI server to an OSI client, the transfer of - credentials from an OSI client to an OSI server, or during exchange - of private or integrity checked messages, Kerberos protocol messages - may be treated as opaque objects and the type of the authentication - mechanism will be: - - OBJECT IDENTIFIER ::= {iso (1), org(3), dod(5),internet(1), - security(5), kerberosv5(2)} - - Depending on the situation, the opaque object will be an - authentication header (KRB_AP_REQ), an authentication reply - (KRB_AP_REP), a safe message (KRB_SAFE), a private message - (KRB_PRIV), or a credentials message (KRB_CRED). The opaque data - contains an application code as specified in the ASN.1 description - for each message. The application code may be used by Kerberos to - determine the message type. - -8.2.3. Name of the TGS - - The principal identifier of the ticket-granting service shall be - composed of three parts: (1) the realm of the KDC issuing the TGS - ticket (2) a two-part name of type NT-SRVINST, with the first part - "krbtgt" and the second part the name of the realm which will accept - the ticket-granting ticket. For example, a ticket-granting ticket - issued by the ATHENA.MIT.EDU realm to be used to get tickets from the - ATHENA.MIT.EDU KDC has a principal identifier of "ATHENA.MIT.EDU" - (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A ticket-granting - ticket issued by the ATHENA.MIT.EDU realm to be used to get tickets - from the MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU" - (realm), ("krbtgt", "MIT.EDU") (name). - -8.3. Protocol constants and associated values - - The following tables list constants used in the protocol and defines - their meanings. - - - - - - - - - -Kohl & Neuman [Page 82] - -RFC 1510 Kerberos September 1993 - - ----------------+-----------+----------+----------------+--------------- -Encryption type|etype value|block size|minimum pad size|confounder size ----------------+-----------+----------+----------------+--------------- -NULL 0 1 0 0 -des-cbc-crc 1 8 4 8 -des-cbc-md4 2 8 0 8 -des-cbc-md5 3 8 0 8 - --------------------------------+-------------------+------------- -Checksum type |sumtype value |checksum size --------------------------------+-------------------+------------- -CRC32 1 4 -rsa-md4 2 16 -rsa-md4-des 3 24 -des-mac 4 16 -des-mac-k 5 8 -rsa-md4-des-k 6 16 -rsa-md5 7 16 -rsa-md5-des 8 24 - --------------------------------+----------------- -padata type |padata-type value --------------------------------+----------------- -PA-TGS-REQ 1 -PA-ENC-TIMESTAMP 2 -PA-PW-SALT 3 - --------------------------------+------------- -authorization data type |ad-type value --------------------------------+------------- -reserved values 0-63 -OSF-DCE 64 -SESAME 65 - --------------------------------+----------------- -alternate authentication type |method-type value --------------------------------+----------------- -reserved values 0-63 -ATT-CHALLENGE-RESPONSE 64 - --------------------------------+------------- -transited encoding type |tr-type value --------------------------------+------------- -DOMAIN-X500-COMPRESS 1 -reserved values all others - - - - - - -Kohl & Neuman [Page 83] - -RFC 1510 Kerberos September 1993 - - ---------------+-------+----------------------------------------- -Label |Value |Meaning or MIT code ---------------+-------+----------------------------------------- - -pvno 5 current Kerberos protocol version number - -message types - -KRB_AS_REQ 10 Request for initial authentication -KRB_AS_REP 11 Response to KRB_AS_REQ request -KRB_TGS_REQ 12 Request for authentication based on TGT -KRB_TGS_REP 13 Response to KRB_TGS_REQ request -KRB_AP_REQ 14 application request to server -KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL -KRB_SAFE 20 Safe (checksummed) application message -KRB_PRIV 21 Private (encrypted) application message -KRB_CRED 22 Private (encrypted) message to forward - credentials -KRB_ERROR 30 Error response - -name types - -KRB_NT_UNKNOWN 0 Name type not known -KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or - for users -KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt) -KRB_NT_SRV_HST 3 Service with host name as instance (telnet, - rcommands) -KRB_NT_SRV_XHST 4 Service with host as remaining components -KRB_NT_UID 5 Unique ID - -error codes - -KDC_ERR_NONE 0 No error -KDC_ERR_NAME_EXP 1 Client's entry in database has - expired -KDC_ERR_SERVICE_EXP 2 Server's entry in database has - expired -KDC_ERR_BAD_PVNO 3 Requested protocol version number - not supported -KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old - master key -KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old - master key -KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos database -KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos database -KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in - database - - - -Kohl & Neuman [Page 84] - -RFC 1510 Kerberos September 1993 - - -KDC_ERR_NULL_KEY 9 The client or server has a null key -KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating -KDC_ERR_NEVER_VALID 11 Requested start time is later than - end time -KDC_ERR_POLICY 12 KDC policy rejects request -KDC_ERR_BADOPTION 13 KDC cannot accommodate requested - option -KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption - type -KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type -KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type -KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type -KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been revoked -KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been - revoked -KDC_ERR_TGT_REVOKED 20 TGT has been revoked -KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again - later -KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again - later -KDC_ERR_KEY_EXPIRED 23 Password has expired - change - password to reset -KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information - was invalid -KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authentication - required* -KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field - failed -KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired -KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid -KRB_AP_ERR_REPEAT 34 Request is a replay -KRB_AP_ERR_NOT_US 35 The ticket isn't for us -KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match -KRB_AP_ERR_SKEW 37 Clock skew too great -KRB_AP_ERR_BADADDR 38 Incorrect net address -KRB_AP_ERR_BADVERSION 39 Protocol version mismatch -KRB_AP_ERR_MSG_TYPE 40 Invalid msg type -KRB_AP_ERR_MODIFIED 41 Message stream modified -KRB_AP_ERR_BADORDER 42 Message out of order -KRB_AP_ERR_BADKEYVER 44 Specified version of key is not - available -KRB_AP_ERR_NOKEY 45 Service key not available -KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed -KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction -KRB_AP_ERR_METHOD 48 Alternative authentication method - required* -KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message -KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in - - - -Kohl & Neuman [Page 85] - -RFC 1510 Kerberos September 1993 - - - message -KRB_ERR_GENERIC 60 Generic error (description in e-text) -KRB_ERR_FIELD_TOOLONG 61 Field is too long for this - implementation - - *This error carries additional information in the e-data field. The - contents of the e-data field for this message is described in section - 5.9.1. - -9. Interoperability requirements - - Version 5 of the Kerberos protocol supports a myriad of options. - Among these are multiple encryption and checksum types, alternative - encoding schemes for the transited field, optional mechanisms for - pre-authentication, the handling of tickets with no addresses, - options for mutual authentication, user to user authentication, - support for proxies, forwarding, postdating, and renewing tickets, - the format of realm names, and the handling of authorization data. - - In order to ensure the interoperability of realms, it is necessary to - define a minimal configuration which must be supported by all - implementations. This minimal configuration is subject to change as - technology does. For example, if at some later date it is discovered - that one of the required encryption or checksum algorithms is not - secure, it will be replaced. - -9.1. Specification 1 - - This section defines the first specification of these options. - Implementations which are configured in this way can be said to - support Kerberos Version 5 Specification 1 (5.1). - - Encryption and checksum methods - - The following encryption and checksum mechanisms must be supported. - Implementations may support other mechanisms as well, but the - additional mechanisms may only be used when communicating with - principals known to also support them: Encryption: DES-CBC-MD5 - Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5 - - Realm Names - - All implementations must understand hierarchical realms in both the - Internet Domain and the X.500 style. When a ticket granting ticket - for an unknown realm is requested, the KDC must be able to determine - the names of the intermediate realms between the KDCs realm and the - requested realm. - - - - -Kohl & Neuman [Page 86] - -RFC 1510 Kerberos September 1993 - - - Transited field encoding - - DOMAIN-X500-COMPRESS (described in section 3.3.3.1) must be - supported. Alternative encodings may be supported, but they may be - used only when that encoding is supported by ALL intermediate realms. - - Pre-authentication methods - - The TGS-REQ method must be supported. The TGS-REQ method is not used - on the initial request. The PA-ENC-TIMESTAMP method must be supported - by clients but whether it is enabled by default may be determined on - a realm by realm basis. If not used in the initial request and the - error KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENCTIMESTAMP - as an acceptable method, the client should retry the initial request - using the PA-ENC-TIMESTAMP preauthentication method. Servers need not - support the PAENC-TIMESTAMP method, but if not supported the server - should ignore the presence of PA-ENC-TIMESTAMP pre-authentication in - a request. - - Mutual authentication - - Mutual authentication (via the KRB_AP_REP message) must be supported. - - Ticket addresses and flags - - All KDC's must pass on tickets that carry no addresses (i.e., if a - TGT contains no addresses, the KDC will return derivative tickets), - but each realm may set its own policy for issuing such tickets, and - each application server will set its own policy with respect to - accepting them. By default, servers should not accept them. - - Proxies and forwarded tickets must be supported. Individual realms - and application servers can set their own policy on when such tickets - will be accepted. - - All implementations must recognize renewable and postdated tickets, - but need not actually implement them. If these options are not - supported, the starttime and endtime in the ticket shall specify a - ticket's entire useful life. When a postdated ticket is decoded by a - server, all implementations shall make the presence of the postdated - flag visible to the calling server. - - User-to-user authentication - - Support for user to user authentication (via the ENC-TKTIN-SKEY KDC - option) must be provided by implementations, but individual realms - may decide as a matter of policy to reject such requests on a per- - principal or realm-wide basis. - - - -Kohl & Neuman [Page 87] - -RFC 1510 Kerberos September 1993 - - - Authorization data - - Implementations must pass all authorization data subfields from - ticket-granting tickets to any derivative tickets unless directed to - suppress a subfield as part of the definition of that registered - subfield type (it is never incorrect to pass on a subfield, and no - registered subfield types presently specify suppression at the KDC). - - Implementations must make the contents of any authorization data - subfields available to the server when a ticket is used. - Implementations are not required to allow clients to specify the - contents of the authorization data fields. - -9.2. Recommended KDC values - - Following is a list of recommended values for a KDC implementation, - based on the list of suggested configuration constants (see section - 4.4). - - minimum lifetime 5 minutes - - maximum renewable lifetime 1 week - - maximum ticket lifetime 1 day - - empty addresses only when suitable restrictions appear - in authorization data - - proxiable, etc. Allowed. - -10. Acknowledgments - - Early versions of this document, describing version 4 of the - protocol, were written by Jennifer Steiner (formerly at Project - Athena); these drafts provided an excellent starting point for this - current version 5 specification. Many people in the Internet - community have contributed ideas and suggested protocol changes for - version 5. Notable contributions came from Ted Anderson, Steve - Bellovin and Michael Merritt [17], Daniel Bernstein, Mike Burrows, - Donald Davis, Ravi Ganesan, Morrie Gasser, Virgil Gligor, Bill - Griffeth, Mark Lillibridge, Mark Lomas, Steve Lunt, Piers McMahon, - Joe Pato, William Sommerfeld, Stuart Stubblebine, Ralph Swick, Ted - T'so, and Stanley Zanarotti. Many others commented and helped shape - this specification into its current form. - - - - - - - -Kohl & Neuman [Page 88] - -RFC 1510 Kerberos September 1993 - - -11. References - - [1] Miller, S., Neuman, C., Schiller, J., and J. Saltzer, "Section - E.2.1: Kerberos Authentication and Authorization System", - M.I.T. Project Athena, Cambridge, Massachusetts, December 21, - 1987. - - [2] Steiner, J., Neuman, C., and J. Schiller, "Kerberos: An - Authentication Service for Open Network Systems", pp. 191-202 in - Usenix Conference Proceedings, Dallas, Texas, February, 1988. - - [3] Needham, R., and M. Schroeder, "Using Encryption for - Authentication in Large Networks of Computers", Communications - of the ACM, Vol. 21 (12), pp. 993-999, December 1978. - - [4] Denning, D., and G. Sacco, "Time stamps in Key Distribution - Protocols", Communications of the ACM, Vol. 24 (8), pp. 533-536, - August 1981. - - [5] Kohl, J., Neuman, C., and T. Ts'o, "The Evolution of the - Kerberos Authentication Service", in an IEEE Computer Society - Text soon to be published, June 1992. - - [6] Davis, D., and R. Swick, "Workstation Services and Kerberos - Authentication at Project Athena", Technical Memorandum TM-424, - MIT Laboratory for Computer Science, February 1990. - - [7] Levine, P., Gretzinger, M, Diaz, J., Sommerfeld, W., and K. - Raeburn, "Section E.1: Service Management System, M.I.T. - Project Athena, Cambridge, Mas sachusetts (1987). - - [8] CCITT, Recommendation X.509: The Directory Authentication - Framework, December 1988. - - [9] Neuman, C., "Proxy-Based Authorization and Accounting for - Distributed Systems," in Proceedings of the 13th International - Conference on Distributed Computing Systems", Pittsburgh, PA, - May 1993. - - [10] Pato, J., "Using Pre-Authentication to Avoid Password Guessing - Attacks", Open Software Foundation DCE Request for Comments 26, - December 1992. - - [11] National Bureau of Standards, U.S. Department of Commerce, "Data - Encryption Standard", Federal Information Processing Standards - Publication 46, Washington, DC (1977). - - - - - -Kohl & Neuman [Page 89] - -RFC 1510 Kerberos September 1993 - - - [12] National Bureau of Standards, U.S. Department of Commerce, "DES - Modes of Operation", Federal Information Processing Standards - Publication 81, Springfield, VA, December 1980. - - [13] Stubblebine S., and V. Gligor, "On Message Integrity in - Cryptographic Protocols", in Proceedings of the IEEE Symposium - on Research in Security and Privacy, Oakland, California, May - 1992. - - [14] International Organization for Standardization, "ISO Information - Processing Systems - Data Communication High-Level Data Link - Control Procedure - Frame Structure", IS 3309, October 1984, 3rd - Edition. - - [15] Rivest, R., "The MD4 Message Digest Algorithm", RFC 1320, MIT - Laboratory for Computer Science, April 1992. - - [16] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, MIT - Laboratory for Computer Science, April 1992. - - [17] Bellovin S., and M. Merritt, "Limitations of the Kerberos - Authentication System", Computer Communications Review, Vol. - 20(5), pp. 119-132, October 1990. - -12. Security Considerations - - Security issues are discussed throughout this memo. - -13. Authors' Addresses - - John Kohl - Digital Equipment Corporation - 110 Spit Brook Road, M/S ZKO3-3/U14 - Nashua, NH 03062 - - Phone: 603-881-2481 - EMail: jtkohl@zk3.dec.com - - - B. Clifford Neuman - USC/Information Sciences Institute - 4676 Admiralty Way #1001 - Marina del Rey, CA 90292-6695 - - Phone: 310-822-1511 - EMail: bcn@isi.edu - - - - - -Kohl & Neuman [Page 90] - -RFC 1510 Kerberos September 1993 - - -A. Pseudo-code for protocol processing - - This appendix provides pseudo-code describing how the messages are to - be constructed and interpreted by clients and servers. - -A.1. KRB_AS_REQ generation - request.pvno := protocol version; /* pvno = 5 */ - request.msg-type := message type; /* type = KRB_AS_REQ */ - - if(pa_enc_timestamp_required) then - request.padata.padata-type = PA-ENC-TIMESTAMP; - get system_time; - padata-body.patimestamp,pausec = system_time; - encrypt padata-body into request.padata.padata-value - using client.key; /* derived from password */ - endif - - body.kdc-options := users's preferences; - body.cname := user's name; - body.realm := user's realm; - body.sname := service's name; /* usually "krbtgt", - "localrealm" */ - if (body.kdc-options.POSTDATED is set) then - body.from := requested starting time; - else - omit body.from; - endif - body.till := requested end time; - if (body.kdc-options.RENEWABLE is set) then - body.rtime := requested final renewal time; - endif - body.nonce := random_nonce(); - body.etype := requested etypes; - if (user supplied addresses) then - body.addresses := user's addresses; - else - omit body.addresses; - endif - omit body.enc-authorization-data; - request.req-body := body; - - kerberos := lookup(name of local kerberos server (or servers)); - send(packet,kerberos); - - wait(for response); - if (timed_out) then - retry or use alternate server; - endif - - - -Kohl & Neuman [Page 91] - -RFC 1510 Kerberos September 1993 - - -A.2. KRB_AS_REQ verification and KRB_AS_REP generation - decode message into req; - - client := lookup(req.cname,req.realm); - server := lookup(req.sname,req.realm); - get system_time; - kdc_time := system_time.seconds; - - if (!client) then - /* no client in Database */ - error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN); - endif - if (!server) then - /* no server in Database */ - error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); - endif - - if(client.pa_enc_timestamp_required and - pa_enc_timestamp not present) then - error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)); - endif - - if(pa_enc_timestamp present) then - decrypt req.padata-value into decrypted_enc_timestamp - using client.key; - using auth_hdr.authenticator.subkey; - if (decrypt_error()) then - error_out(KRB_AP_ERR_BAD_INTEGRITY); - if(decrypted_enc_timestamp is not within allowable - skew) then error_out(KDC_ERR_PREAUTH_FAILED); - endif - if(decrypted_enc_timestamp and usec is replay) - error_out(KDC_ERR_PREAUTH_FAILED); - endif - add decrypted_enc_timestamp and usec to replay cache; - endif - - use_etype := first supported etype in req.etypes; - - if (no support for req.etypes) then - error_out(KDC_ERR_ETYPE_NOSUPP); - endif - - new_tkt.vno := ticket version; /* = 5 */ - new_tkt.sname := req.sname; - new_tkt.srealm := req.srealm; - reset all flags in new_tkt.flags; - - - - -Kohl & Neuman [Page 92] - -RFC 1510 Kerberos September 1993 - - - /* It should be noted that local policy may affect the */ - /* processing of any of these flags. For example, some */ - /* realms may refuse to issue renewable tickets */ - - if (req.kdc-options.FORWARDABLE is set) then - set new_tkt.flags.FORWARDABLE; - endif - if (req.kdc-options.PROXIABLE is set) then - set new_tkt.flags.PROXIABLE; - endif - if (req.kdc-options.ALLOW-POSTDATE is set) then - set new_tkt.flags.ALLOW-POSTDATE; - endif - if ((req.kdc-options.RENEW is set) or - (req.kdc-options.VALIDATE is set) or - (req.kdc-options.PROXY is set) or - (req.kdc-options.FORWARDED is set) or - (req.kdc-options.ENC-TKT-IN-SKEY is set)) then - error_out(KDC_ERR_BADOPTION); - endif - - new_tkt.session := random_session_key(); - new_tkt.cname := req.cname; - new_tkt.crealm := req.crealm; - new_tkt.transited := empty_transited_field(); - - new_tkt.authtime := kdc_time; - - if (req.kdc-options.POSTDATED is set) then - if (against_postdate_policy(req.from)) then - error_out(KDC_ERR_POLICY); - endif - set new_tkt.flags.INVALID; - new_tkt.starttime := req.from; - else - omit new_tkt.starttime; /* treated as authtime when - omitted */ - endif - if (req.till = 0) then - till := infinity; - else - till := req.till; - endif - - new_tkt.endtime := min(till, - new_tkt.starttime+client.max_life, - new_tkt.starttime+server.max_life, - new_tkt.starttime+max_life_for_realm); - - - -Kohl & Neuman [Page 93] - -RFC 1510 Kerberos September 1993 - - - if ((req.kdc-options.RENEWABLE-OK is set) and - (new_tkt.endtime < req.till)) then - /* we set the RENEWABLE option for later processing */ - set req.kdc-options.RENEWABLE; - req.rtime := req.till; - endif - - if (req.rtime = 0) then - rtime := infinity; - else - rtime := req.rtime; - endif - - if (req.kdc-options.RENEWABLE is set) then - set new_tkt.flags.RENEWABLE; - new_tkt.renew-till := min(rtime, - new_tkt.starttime+client.max_rlife, - new_tkt.starttime+server.max_rlife, - new_tkt.starttime+max_rlife_for_realm); - else - omit new_tkt.renew-till; /* only present if RENEWABLE */ - endif - - if (req.addresses) then - new_tkt.caddr := req.addresses; - else - omit new_tkt.caddr; - endif - - new_tkt.authorization_data := empty_authorization_data(); - - encode to-be-encrypted part of ticket into OCTET STRING; - new_tkt.enc-part := encrypt OCTET STRING - using etype_for_key(server.key), server.key, server.p_kvno; - - - /* Start processing the response */ - - resp.pvno := 5; - resp.msg-type := KRB_AS_REP; - resp.cname := req.cname; - resp.crealm := req.realm; - resp.ticket := new_tkt; - - resp.key := new_tkt.session; - resp.last-req := fetch_last_request_info(client); - resp.nonce := req.nonce; - resp.key-expiration := client.expiration; - - - -Kohl & Neuman [Page 94] - -RFC 1510 Kerberos September 1993 - - - resp.flags := new_tkt.flags; - - resp.authtime := new_tkt.authtime; - resp.starttime := new_tkt.starttime; - resp.endtime := new_tkt.endtime; - - if (new_tkt.flags.RENEWABLE) then - resp.renew-till := new_tkt.renew-till; - endif - - resp.realm := new_tkt.realm; - resp.sname := new_tkt.sname; - - resp.caddr := new_tkt.caddr; - - encode body of reply into OCTET STRING; - - resp.enc-part := encrypt OCTET STRING - using use_etype, client.key, client.p_kvno; - send(resp); - -A.3. KRB_AS_REP verification - decode response into resp; - - if (resp.msg-type = KRB_ERROR) then - if(error = KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)) - then set pa_enc_timestamp_required; - goto KRB_AS_REQ; - endif - process_error(resp); - return; - endif - - /* On error, discard the response, and zero the session key */ - /* from the response immediately */ - - key = get_decryption_key(resp.enc-part.kvno, resp.enc-part.etype, - resp.padata); - unencrypted part of resp := decode of decrypt of resp.enc-part - using resp.enc-part.etype and key; - zero(key); - - if (common_as_rep_tgs_rep_checks fail) then - destroy resp.key; - return error; - endif - - if near(resp.princ_exp) then - - - -Kohl & Neuman [Page 95] - -RFC 1510 Kerberos September 1993 - - - print(warning message); - endif - save_for_later(ticket,session,client,server,times,flags); - -A.4. KRB_AS_REP and KRB_TGS_REP common checks - if (decryption_error() or - (req.cname != resp.cname) or - (req.realm != resp.crealm) or - (req.sname != resp.sname) or - (req.realm != resp.realm) or - (req.nonce != resp.nonce) or - (req.addresses != resp.caddr)) then - destroy resp.key; - return KRB_AP_ERR_MODIFIED; - endif - - /* make sure no flags are set that shouldn't be, and that */ - /* all that should be are set */ - if (!check_flags_for_compatability(req.kdc-options,resp.flags)) - then destroy resp.key; - return KRB_AP_ERR_MODIFIED; - endif - - if ((req.from = 0) and - (resp.starttime is not within allowable skew)) then - destroy resp.key; - return KRB_AP_ERR_SKEW; - endif - if ((req.from != 0) and (req.from != resp.starttime)) then - destroy resp.key; - return KRB_AP_ERR_MODIFIED; - endif - if ((req.till != 0) and (resp.endtime > req.till)) then - destroy resp.key; - return KRB_AP_ERR_MODIFIED; - endif - - if ((req.kdc-options.RENEWABLE is set) and - (req.rtime != 0) and (resp.renew-till > req.rtime)) then - destroy resp.key; - return KRB_AP_ERR_MODIFIED; - endif - if ((req.kdc-options.RENEWABLE-OK is set) and - (resp.flags.RENEWABLE) and - (req.till != 0) and - (resp.renew-till > req.till)) then - destroy resp.key; - return KRB_AP_ERR_MODIFIED; - - - -Kohl & Neuman [Page 96] - -RFC 1510 Kerberos September 1993 - - - endif - -A.5. KRB_TGS_REQ generation - /* Note that make_application_request might have to */ - /* recursivly call this routine to get the appropriate */ - /* ticket-granting ticket */ - - request.pvno := protocol version; /* pvno = 5 */ - request.msg-type := message type; /* type = KRB_TGS_REQ */ - - body.kdc-options := users's preferences; - /* If the TGT is not for the realm of the end-server */ - /* then the sname will be for a TGT for the end-realm */ - /* and the realm of the requested ticket (body.realm) */ - /* will be that of the TGS to which the TGT we are */ - /* sending applies */ - body.sname := service's name; - body.realm := service's realm; - - if (body.kdc-options.POSTDATED is set) then - body.from := requested starting time; - else - omit body.from; - endif - body.till := requested end time; - if (body.kdc-options.RENEWABLE is set) then - body.rtime := requested final renewal time; - endif - body.nonce := random_nonce(); - body.etype := requested etypes; - if (user supplied addresses) then - body.addresses := user's addresses; - else - omit body.addresses; - endif - - body.enc-authorization-data := user-supplied data; - if (body.kdc-options.ENC-TKT-IN-SKEY) then - body.additional-tickets_ticket := second TGT; - endif - - request.req-body := body; - check := generate_checksum (req.body,checksumtype); - - request.padata[0].padata-type := PA-TGS-REQ; - request.padata[0].padata-value := create a KRB_AP_REQ using - the TGT and checksum - - - - -Kohl & Neuman [Page 97] - -RFC 1510 Kerberos September 1993 - - - /* add in any other padata as required/supplied */ - - kerberos := lookup(name of local kerberose server (or servers)); - send(packet,kerberos); - - wait(for response); - if (timed_out) then - retry or use alternate server; - endif - -A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation - /* note that reading the application request requires first - determining the server for which a ticket was issued, and - choosing the correct key for decryption. The name of the - server appears in the plaintext part of the ticket. */ - - if (no KRB_AP_REQ in req.padata) then - error_out(KDC_ERR_PADATA_TYPE_NOSUPP); - endif - verify KRB_AP_REQ in req.padata; - - /* Note that the realm in which the Kerberos server is - operating is determined by the instance from the - ticket-granting ticket. The realm in the ticket-granting - ticket is the realm under which the ticket granting ticket was - issued. It is possible for a single Kerberos server to - support more than one realm. */ - - auth_hdr := KRB_AP_REQ; - tgt := auth_hdr.ticket; - - if (tgt.sname is not a TGT for local realm and is not - req.sname) then error_out(KRB_AP_ERR_NOT_US); - - realm := realm_tgt_is_for(tgt); - - decode remainder of request; - - if (auth_hdr.authenticator.cksum is missing) then - error_out(KRB_AP_ERR_INAPP_CKSUM); - endif - if (auth_hdr.authenticator.cksum type is not supported) then - error_out(KDC_ERR_SUMTYPE_NOSUPP); - endif - if (auth_hdr.authenticator.cksum is not both collision-proof - and keyed) then - error_out(KRB_AP_ERR_INAPP_CKSUM); - endif - - - -Kohl & Neuman [Page 98] - -RFC 1510 Kerberos September 1993 - - - set computed_checksum := checksum(req); - if (computed_checksum != auth_hdr.authenticatory.cksum) then - error_out(KRB_AP_ERR_MODIFIED); - endif - - server := lookup(req.sname,realm); - - if (!server) then - if (is_foreign_tgt_name(server)) then - server := best_intermediate_tgs(server); - else - /* no server in Database */ - error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); - endif - endif - - session := generate_random_session_key(); - - - use_etype := first supported etype in req.etypes; - - if (no support for req.etypes) then - error_out(KDC_ERR_ETYPE_NOSUPP); - endif - - new_tkt.vno := ticket version; /* = 5 */ - new_tkt.sname := req.sname; - new_tkt.srealm := realm; - reset all flags in new_tkt.flags; - - /* It should be noted that local policy may affect the */ - /* processing of any of these flags. For example, some */ - /* realms may refuse to issue renewable tickets */ - - new_tkt.caddr := tgt.caddr; - resp.caddr := NULL; /* We only include this if they change */ - if (req.kdc-options.FORWARDABLE is set) then - if (tgt.flags.FORWARDABLE is reset) then - error_out(KDC_ERR_BADOPTION); - endif - set new_tkt.flags.FORWARDABLE; - endif - if (req.kdc-options.FORWARDED is set) then - if (tgt.flags.FORWARDABLE is reset) then - error_out(KDC_ERR_BADOPTION); - endif - set new_tkt.flags.FORWARDED; - new_tkt.caddr := req.addresses; - - - -Kohl & Neuman [Page 99] - -RFC 1510 Kerberos September 1993 - - - resp.caddr := req.addresses; - endif - if (tgt.flags.FORWARDED is set) then - set new_tkt.flags.FORWARDED; - endif - - if (req.kdc-options.PROXIABLE is set) then - if (tgt.flags.PROXIABLE is reset) - error_out(KDC_ERR_BADOPTION); - endif - set new_tkt.flags.PROXIABLE; - endif - if (req.kdc-options.PROXY is set) then - if (tgt.flags.PROXIABLE is reset) then - error_out(KDC_ERR_BADOPTION); - endif - set new_tkt.flags.PROXY; - new_tkt.caddr := req.addresses; - resp.caddr := req.addresses; - endif - - if (req.kdc-options.POSTDATE is set) then - if (tgt.flags.POSTDATE is reset) - error_out(KDC_ERR_BADOPTION); - endif - set new_tkt.flags.POSTDATE; - endif - if (req.kdc-options.POSTDATED is set) then - if (tgt.flags.POSTDATE is reset) then - error_out(KDC_ERR_BADOPTION); - endif - set new_tkt.flags.POSTDATED; - set new_tkt.flags.INVALID; - if (against_postdate_policy(req.from)) then - error_out(KDC_ERR_POLICY); - endif - new_tkt.starttime := req.from; - endif - - - if (req.kdc-options.VALIDATE is set) then - if (tgt.flags.INVALID is reset) then - error_out(KDC_ERR_POLICY); - endif - if (tgt.starttime > kdc_time) then - error_out(KRB_AP_ERR_NYV); - endif - if (check_hot_list(tgt)) then - - - -Kohl & Neuman [Page 100] - -RFC 1510 Kerberos September 1993 - - - error_out(KRB_AP_ERR_REPEAT); - endif - tkt := tgt; - reset new_tkt.flags.INVALID; - endif - - if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW, - and those already processed) is set) then - error_out(KDC_ERR_BADOPTION); - endif - - new_tkt.authtime := tgt.authtime; - - if (req.kdc-options.RENEW is set) then - /* Note that if the endtime has already passed, the ticket */ - /* would have been rejected in the initial authentication */ - /* stage, so there is no need to check again here */ - if (tgt.flags.RENEWABLE is reset) then - error_out(KDC_ERR_BADOPTION); - endif - if (tgt.renew-till >= kdc_time) then - error_out(KRB_AP_ERR_TKT_EXPIRED); - endif - tkt := tgt; - new_tkt.starttime := kdc_time; - old_life := tgt.endttime - tgt.starttime; - new_tkt.endtime := min(tgt.renew-till, - new_tkt.starttime + old_life); - else - new_tkt.starttime := kdc_time; - if (req.till = 0) then - till := infinity; - else - till := req.till; - endif - new_tkt.endtime := min(till, - new_tkt.starttime+client.max_life, - new_tkt.starttime+server.max_life, - new_tkt.starttime+max_life_for_realm, - tgt.endtime); - - if ((req.kdc-options.RENEWABLE-OK is set) and - (new_tkt.endtime < req.till) and - (tgt.flags.RENEWABLE is set) then - /* we set the RENEWABLE option for later */ - /* processing */ - set req.kdc-options.RENEWABLE; - req.rtime := min(req.till, tgt.renew-till); - - - -Kohl & Neuman [Page 101] - -RFC 1510 Kerberos September 1993 - - - endif - endif - - if (req.rtime = 0) then - rtime := infinity; - else - rtime := req.rtime; - endif - - if ((req.kdc-options.RENEWABLE is set) and - (tgt.flags.RENEWABLE is set)) then - set new_tkt.flags.RENEWABLE; - new_tkt.renew-till := min(rtime, - new_tkt.starttime+client.max_rlife, - new_tkt.starttime+server.max_rlife, - new_tkt.starttime+max_rlife_for_realm, - tgt.renew-till); - else - new_tkt.renew-till := OMIT; - /* leave the renew-till field out */ - endif - if (req.enc-authorization-data is present) then - decrypt req.enc-authorization-data - into decrypted_authorization_data - using auth_hdr.authenticator.subkey; - if (decrypt_error()) then - error_out(KRB_AP_ERR_BAD_INTEGRITY); - endif - endif - new_tkt.authorization_data := - req.auth_hdr.ticket.authorization_data + - decrypted_authorization_data; - - new_tkt.key := session; - new_tkt.crealm := tgt.crealm; - new_tkt.cname := req.auth_hdr.ticket.cname; - - if (realm_tgt_is_for(tgt) := tgt.realm) then - /* tgt issued by local realm */ - new_tkt.transited := tgt.transited; - else - /* was issued for this realm by some other realm */ - if (tgt.transited.tr-type not supported) then - error_out(KDC_ERR_TRTYPE_NOSUPP); - endif - new_tkt.transited - := compress_transited(tgt.transited + tgt.realm) - endif - - - -Kohl & Neuman [Page 102] - -RFC 1510 Kerberos September 1993 - - - encode encrypted part of new_tkt into OCTET STRING; - if (req.kdc-options.ENC-TKT-IN-SKEY is set) then - if (server not specified) then - server = req.second_ticket.client; - endif - if ((req.second_ticket is not a TGT) or - (req.second_ticket.client != server)) then - error_out(KDC_ERR_POLICY); - endif - - new_tkt.enc-part := encrypt OCTET STRING using - using etype_for_key(second-ticket.key), - second-ticket.key; - else - new_tkt.enc-part := encrypt OCTET STRING - using etype_for_key(server.key), server.key, - server.p_kvno; - endif - - resp.pvno := 5; - resp.msg-type := KRB_TGS_REP; - resp.crealm := tgt.crealm; - resp.cname := tgt.cname; - resp.ticket := new_tkt; - - resp.key := session; - resp.nonce := req.nonce; - resp.last-req := fetch_last_request_info(client); - resp.flags := new_tkt.flags; - - resp.authtime := new_tkt.authtime; - resp.starttime := new_tkt.starttime; - resp.endtime := new_tkt.endtime; - - omit resp.key-expiration; - - resp.sname := new_tkt.sname; - resp.realm := new_tkt.realm; - - if (new_tkt.flags.RENEWABLE) then - resp.renew-till := new_tkt.renew-till; - endif - - - encode body of reply into OCTET STRING; - - if (req.padata.authenticator.subkey) - resp.enc-part := encrypt OCTET STRING using use_etype, - - - -Kohl & Neuman [Page 103] - -RFC 1510 Kerberos September 1993 - - - req.padata.authenticator.subkey; - else resp.enc-part := encrypt OCTET STRING - using use_etype, tgt.key; - - send(resp); - -A.7. KRB_TGS_REP verification - decode response into resp; - - if (resp.msg-type = KRB_ERROR) then - process_error(resp); - return; - endif - - /* On error, discard the response, and zero the session key from - the response immediately */ - - if (req.padata.authenticator.subkey) - unencrypted part of resp := - decode of decrypt of resp.enc-part - using resp.enc-part.etype and subkey; - else unencrypted part of resp := - decode of decrypt of resp.enc-part - using resp.enc-part.etype and tgt's session key; - if (common_as_rep_tgs_rep_checks fail) then - destroy resp.key; - return error; - endif - - check authorization_data as necessary; - save_for_later(ticket,session,client,server,times,flags); - -A.8. Authenticator generation - body.authenticator-vno := authenticator vno; /* = 5 */ - body.cname, body.crealm := client name; - if (supplying checksum) then - body.cksum := checksum; - endif - get system_time; - body.ctime, body.cusec := system_time; - if (selecting sub-session key) then - select sub-session key; - body.subkey := sub-session key; - endif - if (using sequence numbers) then - select initial sequence number; - body.seq-number := initial sequence; - endif - - - -Kohl & Neuman [Page 104] - -RFC 1510 Kerberos September 1993 - - -A.9. KRB_AP_REQ generation - obtain ticket and session_key from cache; - - packet.pvno := protocol version; /* 5 */ - packet.msg-type := message type; /* KRB_AP_REQ */ - - if (desired(MUTUAL_AUTHENTICATION)) then - set packet.ap-options.MUTUAL-REQUIRED; - else - reset packet.ap-options.MUTUAL-REQUIRED; - endif - if (using session key for ticket) then - set packet.ap-options.USE-SESSION-KEY; - else - reset packet.ap-options.USE-SESSION-KEY; - endif - packet.ticket := ticket; /* ticket */ - generate authenticator; - encode authenticator into OCTET STRING; - encrypt OCTET STRING into packet.authenticator - using session_key; - -A.10. KRB_AP_REQ verification - receive packet; - if (packet.pvno != 5) then - either process using other protocol spec - or error_out(KRB_AP_ERR_BADVERSION); - endif - if (packet.msg-type != KRB_AP_REQ) then - error_out(KRB_AP_ERR_MSG_TYPE); - endif - if (packet.ticket.tkt_vno != 5) then - either process using other protocol spec - or error_out(KRB_AP_ERR_BADVERSION); - endif - if (packet.ap_options.USE-SESSION-KEY is set) then - retrieve session key from ticket-granting ticket for - packet.ticket.{sname,srealm,enc-part.etype}; - else - retrieve service key for - packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno}; - endif - if (no_key_available) then - if (cannot_find_specified_skvno) then - error_out(KRB_AP_ERR_BADKEYVER); - else - error_out(KRB_AP_ERR_NOKEY); - endif - - - -Kohl & Neuman [Page 105] - -RFC 1510 Kerberos September 1993 - - - endif - decrypt packet.ticket.enc-part into decr_ticket - using retrieved key; - if (decryption_error()) then - error_out(KRB_AP_ERR_BAD_INTEGRITY); - endif - decrypt packet.authenticator into decr_authenticator - using decr_ticket.key; - if (decryption_error()) then - error_out(KRB_AP_ERR_BAD_INTEGRITY); - endif - if (decr_authenticator.{cname,crealm} != - decr_ticket.{cname,crealm}) then - error_out(KRB_AP_ERR_BADMATCH); - endif - if (decr_ticket.caddr is present) then - if (sender_address(packet) is not in decr_ticket.caddr) - then error_out(KRB_AP_ERR_BADADDR); - endif - elseif (application requires addresses) then - error_out(KRB_AP_ERR_BADADDR); - endif - if (not in_clock_skew(decr_authenticator.ctime, - decr_authenticator.cusec)) then - error_out(KRB_AP_ERR_SKEW); - endif - if (repeated(decr_authenticator.{ctime,cusec,cname,crealm})) - then error_out(KRB_AP_ERR_REPEAT); - endif - save_identifier(decr_authenticator.{ctime,cusec,cname,crealm}); - get system_time; - if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or - (decr_ticket.flags.INVALID is set)) then - /* it hasn't yet become valid */ - error_out(KRB_AP_ERR_TKT_NYV); - endif - if (system_time-decr_ticket.endtime > CLOCK_SKEW) then - error_out(KRB_AP_ERR_TKT_EXPIRED); - endif - /* caller must check decr_ticket.flags for any pertinent */ - /* details */ - return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED); - -A.11. KRB_AP_REP generation - packet.pvno := protocol version; /* 5 */ - packet.msg-type := message type; /* KRB_AP_REP */ - body.ctime := packet.ctime; - body.cusec := packet.cusec; - - - -Kohl & Neuman [Page 106] - -RFC 1510 Kerberos September 1993 - - - if (selecting sub-session key) then - select sub-session key; - body.subkey := sub-session key; - endif - if (using sequence numbers) then - select initial sequence number; - body.seq-number := initial sequence; - endif - - encode body into OCTET STRING; - - select encryption type; - encrypt OCTET STRING into packet.enc-part; - -A.12. KRB_AP_REP verification - receive packet; - if (packet.pvno != 5) then - either process using other protocol spec - or error_out(KRB_AP_ERR_BADVERSION); - endif - if (packet.msg-type != KRB_AP_REP) then - error_out(KRB_AP_ERR_MSG_TYPE); - endif - cleartext := decrypt(packet.enc-part) - using ticket's session key; - if (decryption_error()) then - error_out(KRB_AP_ERR_BAD_INTEGRITY); - endif - if (cleartext.ctime != authenticator.ctime) then - error_out(KRB_AP_ERR_MUT_FAIL); - endif - if (cleartext.cusec != authenticator.cusec) then - error_out(KRB_AP_ERR_MUT_FAIL); - endif - if (cleartext.subkey is present) then - save cleartext.subkey for future use; - endif - if (cleartext.seq-number is present) then - save cleartext.seq-number for future verifications; - endif - return(AUTHENTICATION_SUCCEEDED); - -A.13. KRB_SAFE generation - collect user data in buffer; - - /* assemble packet: */ - packet.pvno := protocol version; /* 5 */ - packet.msg-type := message type; /* KRB_SAFE */ - - - -Kohl & Neuman [Page 107] - -RFC 1510 Kerberos September 1993 - - - body.user-data := buffer; /* DATA */ - if (using timestamp) then - get system_time; - body.timestamp, body.usec := system_time; - endif - if (using sequence numbers) then - body.seq-number := sequence number; - endif - body.s-address := sender host addresses; - if (only one recipient) then - body.r-address := recipient host address; - endif - checksum.cksumtype := checksum type; - compute checksum over body; - checksum.checksum := checksum value; /* checksum.checksum */ - packet.cksum := checksum; - packet.safe-body := body; - -A.14. KRB_SAFE verification - receive packet; - if (packet.pvno != 5) then - either process using other protocol spec - or error_out(KRB_AP_ERR_BADVERSION); - endif - if (packet.msg-type != KRB_SAFE) then - error_out(KRB_AP_ERR_MSG_TYPE); - endif - if (packet.checksum.cksumtype is not both collision-proof - and keyed) then - error_out(KRB_AP_ERR_INAPP_CKSUM); - endif - if (safe_priv_common_checks_ok(packet)) then - set computed_checksum := checksum(packet.body); - if (computed_checksum != packet.checksum) then - error_out(KRB_AP_ERR_MODIFIED); - endif - return (packet, PACKET_IS_GENUINE); - else - return common_checks_error; - endif - -A.15. KRB_SAFE and KRB_PRIV common checks - if (packet.s-address != O/S_sender(packet)) then - /* O/S report of sender not who claims to have sent it */ - error_out(KRB_AP_ERR_BADADDR); - endif - if ((packet.r-address is present) and - (packet.r-address != local_host_address)) then - - - -Kohl & Neuman [Page 108] - -RFC 1510 Kerberos September 1993 - - - /* was not sent to proper place */ - error_out(KRB_AP_ERR_BADADDR); - endif - if (((packet.timestamp is present) and - (not in_clock_skew(packet.timestamp,packet.usec))) or - (packet.timestamp is not present and timestamp expected)) - then error_out(KRB_AP_ERR_SKEW); - endif - if (repeated(packet.timestamp,packet.usec,packet.s-address)) - then error_out(KRB_AP_ERR_REPEAT); - endif - if (((packet.seq-number is present) and - ((not in_sequence(packet.seq-number)))) or - (packet.seq-number is not present and sequence expected)) - then error_out(KRB_AP_ERR_BADORDER); - endif - if (packet.timestamp not present and - packet.seq-number not present) then - error_out(KRB_AP_ERR_MODIFIED); - endif - - save_identifier(packet.{timestamp,usec,s-address}, - sender_principal(packet)); - - return PACKET_IS_OK; - -A.16. KRB_PRIV generation - collect user data in buffer; - - /* assemble packet: */ - packet.pvno := protocol version; /* 5 */ - packet.msg-type := message type; /* KRB_PRIV */ - - packet.enc-part.etype := encryption type; - - body.user-data := buffer; - if (using timestamp) then - get system_time; - body.timestamp, body.usec := system_time; - endif - if (using sequence numbers) then - body.seq-number := sequence number; - endif - body.s-address := sender host addresses; - if (only one recipient) then - body.r-address := recipient host address; - endif - - - - -Kohl & Neuman [Page 109] - -RFC 1510 Kerberos September 1993 - - - encode body into OCTET STRING; - - select encryption type; - encrypt OCTET STRING into packet.enc-part.cipher; - -A.17. KRB_PRIV verification - receive packet; - if (packet.pvno != 5) then - either process using other protocol spec - or error_out(KRB_AP_ERR_BADVERSION); - endif - if (packet.msg-type != KRB_PRIV) then - error_out(KRB_AP_ERR_MSG_TYPE); - endif - - cleartext := decrypt(packet.enc-part) using negotiated key; - if (decryption_error()) then - error_out(KRB_AP_ERR_BAD_INTEGRITY); - endif - - if (safe_priv_common_checks_ok(cleartext)) then - return(cleartext.DATA, PACKET_IS_GENUINE_AND_UNMODIFIED); - else - return common_checks_error; - endif - -A.18. KRB_CRED generation - invoke KRB_TGS; /* obtain tickets to be provided to peer */ - - /* assemble packet: */ - packet.pvno := protocol version; /* 5 */ - packet.msg-type := message type; /* KRB_CRED */ - - for (tickets[n] in tickets to be forwarded) do - packet.tickets[n] = tickets[n].ticket; - done - - packet.enc-part.etype := encryption type; - - for (ticket[n] in tickets to be forwarded) do - body.ticket-info[n].key = tickets[n].session; - body.ticket-info[n].prealm = tickets[n].crealm; - body.ticket-info[n].pname = tickets[n].cname; - body.ticket-info[n].flags = tickets[n].flags; - body.ticket-info[n].authtime = tickets[n].authtime; - body.ticket-info[n].starttime = tickets[n].starttime; - body.ticket-info[n].endtime = tickets[n].endtime; - body.ticket-info[n].renew-till = tickets[n].renew-till; - - - -Kohl & Neuman [Page 110] - -RFC 1510 Kerberos September 1993 - - - body.ticket-info[n].srealm = tickets[n].srealm; - body.ticket-info[n].sname = tickets[n].sname; - body.ticket-info[n].caddr = tickets[n].caddr; - done - - get system_time; - body.timestamp, body.usec := system_time; - - if (using nonce) then - body.nonce := nonce; - endif - - if (using s-address) then - body.s-address := sender host addresses; - endif - if (limited recipients) then - body.r-address := recipient host address; - endif - - encode body into OCTET STRING; - - select encryption type; - encrypt OCTET STRING into packet.enc-part.cipher - using negotiated encryption key; - -A.19. KRB_CRED verification - receive packet; - if (packet.pvno != 5) then - either process using other protocol spec - or error_out(KRB_AP_ERR_BADVERSION); - endif - if (packet.msg-type != KRB_CRED) then - error_out(KRB_AP_ERR_MSG_TYPE); - endif - - cleartext := decrypt(packet.enc-part) using negotiated key; - if (decryption_error()) then - error_out(KRB_AP_ERR_BAD_INTEGRITY); - endif - if ((packet.r-address is present or required) and - (packet.s-address != O/S_sender(packet)) then - /* O/S report of sender not who claims to have sent it */ - error_out(KRB_AP_ERR_BADADDR); - endif - if ((packet.r-address is present) and - (packet.r-address != local_host_address)) then - /* was not sent to proper place */ - error_out(KRB_AP_ERR_BADADDR); - - - -Kohl & Neuman [Page 111] - -RFC 1510 Kerberos September 1993 - - - endif - if (not in_clock_skew(packet.timestamp,packet.usec)) then - error_out(KRB_AP_ERR_SKEW); - endif - if (repeated(packet.timestamp,packet.usec,packet.s-address)) - then error_out(KRB_AP_ERR_REPEAT); - endif - if (packet.nonce is required or present) and - (packet.nonce != expected-nonce) then - error_out(KRB_AP_ERR_MODIFIED); - endif - - for (ticket[n] in tickets that were forwarded) do - save_for_later(ticket[n],key[n],principal[n], - server[n],times[n],flags[n]); - return - -A.20. KRB_ERROR generation - - /* assemble packet: */ - packet.pvno := protocol version; /* 5 */ - packet.msg-type := message type; /* KRB_ERROR */ - - get system_time; - packet.stime, packet.susec := system_time; - packet.realm, packet.sname := server name; - - if (client time available) then - packet.ctime, packet.cusec := client_time; - endif - packet.error-code := error code; - if (client name available) then - packet.cname, packet.crealm := client name; - endif - if (error text available) then - packet.e-text := error text; - endif - if (error data available) then - packet.e-data := error data; - endif - - - - - - - - - - - -Kohl & Neuman [Page 112] - \ No newline at end of file diff --git a/doc/krb5-protocol/rfc3961.txt b/doc/krb5-protocol/rfc3961.txt new file mode 100644 index 000000000..0ac50b959 --- /dev/null +++ b/doc/krb5-protocol/rfc3961.txt @@ -0,0 +1,2803 @@ + + + + + + +Network Working Group K. Raeburn +Request for Comments: 3961 MIT +Category: Standards Track February 2005 + + + Encryption and Checksum Specifications + for Kerberos 5 + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document describes a framework for defining encryption and + checksum mechanisms for use with the Kerberos protocol, defining an + abstraction layer between the Kerberos protocol and related + protocols, and the actual mechanisms themselves. The document also + defines several mechanisms. Some are taken from RFC 1510, modified + in form to fit this new framework and occasionally modified in + content when the old specification was incorrect. New mechanisms are + presented here as well. This document does NOT indicate which + mechanisms may be considered "required to implement". + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 3. Encryption Algorithm Profile . . . . . . . . . . . . . . . . 4 + 4. Checksum Algorithm Profile . . . . . . . . . . . . . . . . . 9 + 5. Simplified Profile for CBC Ciphers with Key Derivation . . . 10 + 5.1. A Key Derivation Function . . . . . . . . . . . . . . . 10 + 5.2. Simplified Profile Parameters . . . . . . . . . . . . . 12 + 5.3. Cryptosystem Profile Based on Simplified Profile . . . 13 + 5.4. Checksum Profiles Based on Simplified Profile . . . . . 16 + 6. Profiles for Kerberos Encryption and Checksum Algorithms . . 16 + 6.1. Unkeyed Checksums . . . . . . . . . . . . . . . . . . . 17 + 6.2. DES-based Encryption and Checksum Types . . . . . . . . 18 + 6.3. Triple-DES Based Encryption and Checksum Types . . . . 28 + 7. Use of Kerberos Encryption Outside This Specification . . . . 30 + + + +Raeburn Standards Track [Page 1] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + 8. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . . 31 + 9. Implementation Notes . . . . . . . . . . . . . . . . . . . . 32 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 + 12. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 36 + A. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . 38 + A.1. n-fold . . . . . . . . . . . . . . . . . . . . . . . . 38 + A.2. mit_des_string_to_key . . . . . . . . . . . . . . . . . 39 + A.3. DES3 DR and DK . . . . . . . . . . . . . . . . . . . . 43 + A.4. DES3string_to_key . . . . . . . . . . . . . . . . . . . 44 + A.5. Modified CRC-32 . . . . . . . . . . . . . . . . . . . . 44 + B. Significant Changes from RFC 1510 . . . . . . . . . . . . . . 45 + Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 + Normative References. . . . . . . . . . . . . . . . . . . . . . . 47 + Informative References. . . . . . . . . . . . . . . . . . . . . . 48 + Editor's Address. . . . . . . . . . . . . . . . . . . . . . . . . 49 + Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 50 + +1. Introduction + + The Kerberos protocols [Kerb] are designed to encrypt messages of + arbitrary sizes, using block encryption ciphers or, less commonly, + stream encryption ciphers. Encryption is used to prove the + identities of the network entities participating in message + exchanges. However, nothing in the Kerberos protocol requires that + any specific encryption algorithm be used, as long as the algorithm + includes certain operations. + + The following sections specify the encryption and checksum mechanisms + currently defined for Kerberos, as well as a framework for defining + future mechanisms. The encoding, chaining, padding, and other + requirements for each are described. Appendix A gives test vectors + for several functions. + +2. Concepts + + Both encryption and checksum mechanisms are profiled in later + sections. Each profile specifies a collection of operations and + attributes that must be defined for a mechanism. A Kerberos + encryption or checksum mechanism specification is not complete if it + does not define all of these operations and attributes. + + An encryption mechanism must provide for confidentiality and + integrity of the original plaintext. (Incorporating a checksum may + permit integrity checking, if the encryption mode does not provide an + integrity check itself.) It must also provide non-malleability + + + + + +Raeburn Standards Track [Page 2] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + [Bellare98] [Dolev91]. Use of a random confounder prepended to the + plaintext is recommended. It should not be possible to determine if + two ciphertexts correspond to the same plaintext without the key. + + A checksum mechanism [1] must provide proof of the integrity of the + associated message and must preserve the confidentiality of the + message in case it is not sent in the clear. Finding two plaintexts + with the same checksum should be infeasible. It is NOT required that + an eavesdropper be unable to determine whether two checksums are for + the same message, as the messages themselves would presumably be + visible to any such eavesdropper. + + Due to advances in cryptography, some cryptographers consider using + the same key for multiple purposes unwise. Since keys are used in + performing a number of different functions in Kerberos, it is + desirable to use different keys for each of these purposes, even + though we start with a single long-term or session key. + + We do this by enumerating the different uses of keys within Kerberos + and by making the "usage number" an input to the encryption or + checksum mechanisms; such enumeration is outside the scope of this + document. Later sections define simplified profile templates for + encryption and checksum mechanisms that use a key derivation function + applied to a CBC mode (or similar) cipher and a checksum or hash + algorithm. + + We distinguish the "base key" specified by other documents from the + "specific key" for a specific encryption or checksum operation. It + is expected but not required that the specific key be one or more + separate keys derived from the original protocol key and the key + usage number. The specific key should not be explicitly referenced + outside of this document. The typical language used in other + documents should be something like, "encrypt this octet string using + this key and this usage number"; generation of the specific key and + cipher state (described in the next section) are implicit. The + creation of a new cipher-state object, or the re-use of one from a + previous encryption operation, may also be explicit. + + New protocols defined in terms of the Kerberos encryption and + checksum types should use their own key usage values. Key usages are + unsigned 32-bit integers; zero is not permitted. + + All data is assumed to be in the form of strings of octets or eight- + bit bytes. Environments with other byte sizes will have to emulate + this behavior in order to get correct results. + + + + + + +Raeburn Standards Track [Page 3] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + Each algorithm is assigned an encryption type (or "etype") or + checksum type number, for algorithm identification within the + Kerberos protocol. The full list of current type number assignments + is given in section 8. + +3. Encryption Algorithm Profile + + An encryption mechanism profile must define the following attributes + and operations. The operations must be defined as functions in the + mathematical sense. No additional or implicit inputs (such as + Kerberos principal names or message sequence numbers) are permitted. + + protocol key format + This describes which octet string values represent valid keys. + For encryption mechanisms that don't have perfectly dense key + spaces, this will describe the representation used for encoding + keys. It need not describe invalid specific values; all key + generation routines should avoid such values. + + specific key structure + This is not a protocol format at all, but a description of the + keying material derived from the chosen key and used to encrypt or + decrypt data or compute or verify a checksum. It may, for + example, be a single key, a set of keys, or a combination of the + original key with additional data. The authors recommend using + one or more keys derived from the original key via one-way key + derivation functions. + + required checksum mechanism + This indicates a checksum mechanism that must be available when + this encryption mechanism is used. Since Kerberos has no built in + mechanism for negotiating checksum mechanisms, once an encryption + mechanism is decided, the corresponding checksum mechanism can be + used. + + key-generation seed length, K + This is the length of the random bitstring needed to generate a + key with the encryption scheme's random-to-key function (described + below). This must be a fixed value so that various techniques for + producing a random bitstring of a given length may be used with + key generation functions. + + key generation functions + Keys must be generated in a number of cases, from different types + of inputs. All function specifications must indicate how to + generate keys in the proper wire format and must avoid generating + keys that significantly compromise the confidentiality of + encrypted data, if the cryptosystem has such. Entropy from each + + + +Raeburn Standards Track [Page 4] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + source should be preserved as much as possible. Many of the + inputs, although unknown, may be at least partly predictable + (e.g., a password string is likely to be entirely in the ASCII + subset and of fairly short length in many environments; a semi- + random string may include time stamps). The benefit of such + predictability to an attacker must be minimized. + + string-to-key (UTF-8 string, UTF-8 string, opaque)->(protocol-key) + This function generates a key from two UTF-8 strings and an opaque + octet string. One of the strings is usually the principal's pass + phrase, but generally it is merely a secret string. The other + string is a "salt" string intended to produce different keys from + the same password for different users or realms. Although the + strings provided will use UTF-8 encoding, no specific version of + Unicode should be assumed; all valid UTF-8 strings should be + allowed. Strings provided in other encodings MUST first be + converted to UTF-8 before applying this function. + + The third argument, the octet string, may be used to pass + mechanism-specific parameters into this function. Since doing so + implies knowledge of the specific encryption system, generating + non-default parameter values should be an uncommon operation, and + normal Kerberos applications should be able to treat this + parameter block as an opaque object supplied by the Key + Distribution Center or defaulted to some mechanism-specific + constant value. + + The string-to-key function should be a one-way function so that + compromising a user's key in one realm does not compromise it in + another, even if the same password (but a different salt) is used. + + random-to-key (bitstring[K])->(protocol-key) + This function generates a key from a random bitstring of a + specific size. All the bits of the input string are assumed to be + equally random, even though the entropy present in the random + source may be limited. + + key-derivation (protocol-key, integer)->(specific-key) + In this function, the integer input is the key usage value, as + described above. An attacker is assumed to know the usage values. + The specific-key output value was described in section 2. + + string-to-key parameter format + This describes the format of the block of data that can be passed + to the string-to-key function above to configure additional + parameters for that function. Along with the mechanism of + encoding parameter values, bounds on the allowed parameters should + also be described to avoid allowing a spoofed KDC to compromise + + + +Raeburn Standards Track [Page 5] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + the user's password. If practical it may be desirable to + construct the encoding so that values unacceptably weakening the + resulting key cannot be encoded. + + Local security policy might permit tighter bounds to avoid excess + resource consumption. If so, the specification should recommended + defaults for these bounds. The description should also outline + possible weaknesses if bounds checks or other validations are not + applied to a parameter string received from the network. + + As mentioned above, this should be considered opaque to most + normal applications. + + default string-to-key parameters (octet string) + This default value for the "params" argument to the string-to-key + function should be used when the application protocol (Kerberos or + other) does not explicitly set the parameter value. As indicated + above, in most cases this parameter block should be treated as an + opaque object. + + cipher state + This describes any information that can be carried over from one + encryption or decryption operation to the next, for use with a + given specific key. For example, a block cipher used in CBC mode + may put an initial vector of one block in the cipher state. Other + encryption modes may track nonces or other data. + + This state must be non-empty and must influence encryption so that + messages are decrypted in the same order they were a encrypted, if + the cipher state is carried over from one encryption to the next. + Distinguishing out-of-order or missing messages from corrupted + messages is not required. If desired, this can be done at a + higher level by including sequence numbers and not "chaining" the + cipher state between encryption operations. + + The cipher state may not be reused in multiple encryption or + decryption operations. These operations all generate a new cipher + state that may be used for following operations using the same key + and operation. + + The contents of the cipher state must be treated as opaque outside + of encryption system specifications. + + initial cipher state (specific-key, direction)->(state) + This describes the generation of the initial value for the cipher + state if it is not being carried over from a previous encryption + or decryption operation. + + + + +Raeburn Standards Track [Page 6] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + This describes any initial state setup needed before encrypting + arbitrary amounts of data with a given specific key. The specific + key and the direction of operations to be performed (encrypt + versus decrypt) must be the only input needed for this + initialization. + + This state should be treated as opaque in any uses outside of an + encryption algorithm definition. + + IMPLEMENTATION NOTE: [Kerb1510] was vague on whether and to what + degree an application protocol could exercise control over the + initial vector used in DES CBC operations. Some existing + implementations permit setting the initial vector. This framework + does not provide for application control of the cipher state + (beyond "initialize" and "carry over from previous encryption"), + as the form and content of the initial cipher state can vary + between encryption systems and may not always be a single block of + random data. + + New Kerberos application protocols should not assume control over + the initial vector, or that one even exists. However, a general- + purpose implementation may wish to provide the capability, in case + applications explicitly setting it are encountered. + + encrypt (specific-key, state, octet string)->(state, octet string) + This function takes the specific key, cipher state, and a non- + empty plaintext string as input and generates ciphertext and a new + cipher state as outputs. If the basic encryption algorithm itself + does not provide for integrity protection (e.g., DES in CBC mode), + then some form of verifiable MAC or checksum must be included. + Some random factor such as a confounder should be included so that + an observer cannot know if two messages contain the same + plaintext, even if the cipher state and specific keys are the + same. The exact length of the plaintext need not be encoded, but + if it is not and if padding is required, the padding must be added + at the end of the string so that the decrypted version may be + parsed from the beginning. + + The specification of the encryption function must indicate not + only the precise contents of the output octet string, but also the + output cipher state. The application protocol may carry the + output cipher state forward from one encryption with a given + specific key to another; the effect of this "chaining" must be + defined [2]. + + Assuming that values for the specific key and cipher state are + correctly-produced, no input octet string may result in an error + indication. + + + +Raeburn Standards Track [Page 7] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + decrypt (specific-key, state, octet string)->(state, octet string) + This function takes the specific key, cipher state, and ciphertext + as inputs and verifies the integrity of the supplied ciphertext. + If the ciphertext's integrity is intact, this function produces + the plaintext and a new cipher state as outputs; otherwise, an + error indication must be returned, and the data discarded. + + The result of the decryption may be longer than the original + plaintext, as, for example, when the encryption mode adds padding + to reach a multiple of a block size. If this is the case, any + extra octets must come after the decoded plaintext. An + application protocol that needs to know the exact length of the + message must encode a length or recognizable "end of message" + marker within the plaintext [3]. + + As with the encryption function, a correct specification for this + function must indicate not only the contents of the output octet + string, but also the resulting cipher state. + + pseudo-random (protocol-key, octet-string)->(octet-string) + This pseudo-random function should generate an octet string of + some size that is independent of the octet string input. The PRF + output string should be suitable for use in key generation, even + if the octet string input is public. It should not reveal the + input key, even if the output is made public. + + These operations and attributes are all that is required to support + Kerberos and various proposed preauthentication schemes. + + For convenience of certain application protocols that may wish to use + the encryption profile, we add the constraint that, for any given + plaintext input size, a message size must exist between that given + size and that size plus 65,535 such that the length of the decrypted + version of the ciphertext will never have extra octets at the end. + + Expressed mathematically, for every message length L1, there exists a + message size L2 such that + + L2 >= L1 + L2 < L1 + 65,536 + for every message M with |M| = L2, decrypt(encrypt(M)) = M + + A document defining a new encryption type should also describe known + weaknesses or attacks, so that its security may be fairly assessed, + and should include test vectors or other validation procedures for + the operations defined. Specific references to information that is + readily available elsewhere are sufficient. + + + + +Raeburn Standards Track [Page 8] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + +4. Checksum Algorithm Profile + + A checksum mechanism profile must define the following attributes and + operations: + + associated encryption algorithm(s) + This indicates the types of encryption keys this checksum + mechanism can be used with. + + A keyed checksum mechanism may have more than one associated + encryption algorithm if they share the same wire-key format, + string-to-key function, default string-to-key-parameters, and key + derivation function. (This combination means that, for example, a + checksum type, key usage value, and password are adequate to get + the specific key used to compute a checksum.) + + An unkeyed checksum mechanism can be used with any encryption + type, as the key is ignored, but its use must be limited to cases + where the checksum itself is protected, to avoid trivial attacks. + + get_mic function + This function generates a MIC token for a given specific key (see + section 3) and message (represented as an octet string) that may + be used to verify the integrity of the associated message. This + function is not required to return the same deterministic result + for each use; it need only generate a token that the verify_mic + routine can check. + + The output of this function will also dictate the size of the + checksum. It must be no larger than 65,535 octets. + + verify_mic function + Given a specific key, message, and MIC token, this function + ascertains whether the message integrity has been compromised. + For a deterministic get_mic routine, the corresponding verify_mic + may simply generate another checksum and compare the two. + + The get_mic and verify_mic operations must allow inputs of arbitrary + length; if any padding is needed, the padding scheme must be + specified as part of these functions. + + These operations and attributes are all that should be required to + support Kerberos and various proposed preauthentication schemes. + + As with encryption mechanism definition documents, documents defining + new checksum mechanisms should indicate validation processes and + known weaknesses. + + + + +Raeburn Standards Track [Page 9] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + +5. Simplified Profile for CBC Ciphers with Key Derivation + + The profile outlined in sections 3 and 4 describes a large number of + operations that must be defined for encryption and checksum + algorithms to be used with Kerberos. Here we describe a simpler + profile that can generate both encryption and checksum mechanism + definitions, filling in uses of key derivation in appropriate places, + providing integrity protection, and defining multiple operations for + the cryptosystem profile based on a smaller set of operations. Not + all of the existing cryptosystems for Kerberos fit into this + simplified profile, but we recommend that future cryptosystems use it + or something based on it [4]. + + Not all the operations in the complete profiles are defined through + this mechanism; several must still be defined for each new algorithm + pair. + +5.1. A Key Derivation Function + + Rather than define some scheme by which a "protocol key" is composed + of a large number of encryption keys, we use keys derived from a base + key to perform cryptographic operations. The base key must be used + only for generating the derived keys, and this derivation must be + non-invertible and entropy preserving. Given these restrictions, + compromise of one derived key does not compromise others. Attack of + the base key is limited, as it is only used for derivation and is not + exposed to any user data. + + To generate a derived key from a base key, we generate a pseudorandom + octet string by using an algorithm DR, described below, and generate + a key from that octet string by using a function dependent on the + encryption algorithm. The input length needed for that function, + which is also dependent on the encryption algorithm, dictates the + length of the string to be generated by the DR algorithm (the value + "k" below). These procedures are based on the key derivation in + [Blumenthal96]. + + Derived Key = DK(Base Key, Well-Known Constant) + + DK(Key, Constant) = random-to-key(DR(Key, Constant)) + + DR(Key, Constant) = k-truncate(E(Key, Constant, + initial-cipher-state)) + + Here DR is the random-octet generation function described below, and + DK is the key-derivation function produced from it. In this + construction, E(Key, Plaintext, CipherState) is a cipher, Constant is + a well-known constant determined by the specific usage of this + + + +Raeburn Standards Track [Page 10] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + function, and k-truncate truncates its argument by taking the first k + bits. Here, k is the key generation seed length needed for the + encryption system. + + The output of the DR function is a string of bits; the actual key is + produced by applying the cryptosystem's random-to-key operation on + this bitstring. + + If the Constant is smaller than the cipher block size of E, then it + must be expanded with n-fold() so it can be encrypted. If the output + of E is shorter than k bits, it is fed back into the encryption as + many times as necessary. The construct is as follows (where | + indicates concatentation): + + K1 = E(Key, n-fold(Constant), initial-cipher-state) + K2 = E(Key, K1, initial-cipher-state) + K3 = E(Key, K2, initial-cipher-state) + K4 = ... + + DR(Key, Constant) = k-truncate(K1 | K2 | K3 | K4 ...) + + n-fold is an algorithm that takes m input bits and "stretches" them + to form n output bits with equal contribution from each input bit to + the output, as described in [Blumenthal96]: + + We first define a primitive called n-folding, which takes a + variable-length input block and produces a fixed-length output + sequence. The intent is to give each input bit approximately + equal weight in determining the value of each output bit. Note + that whenever we need to treat a string of octets as a number, the + assumed representation is Big-Endian -- Most Significant Byte + first. + + To n-fold a number X, replicate the input value to a length that + is the least common multiple of n and the length of X. Before + each repetition, the input is rotated to the right by 13 bit + positions. The successive n-bit chunks are added together using + 1's-complement addition (that is, with end-around carry) to yield + a n-bit result.... + + Test vectors for n-fold are supplied in appendix A [5]. + + In this section, n-fold is always used to produce c bits of output, + where c is the cipher block size of E. + + The size of the Constant must not be larger than c, because reducing + the length of the Constant by n-folding can cause collisions. + + + + +Raeburn Standards Track [Page 11] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + If the size of the Constant is smaller than c, then the Constant must + be n-folded to length c. This string is used as input to E. If the + block size of E is less than the random-to-key input size, then the + output from E is taken as input to a second invocation of E. This + process is repeated until the number of bits accumulated is greater + than or equal to the random-to-key input size. When enough bits have + been computed, the first k are taken as the random data used to + create the key with the algorithm-dependent random-to-key function. + + As the derived key is the result of one or more encryptions in the + base key, deriving the base key from the derived key is equivalent to + determining the key from a very small number of plaintext/ciphertext + pairs. Thus, this construction is as strong as the cryptosystem + itself. + +5.2. Simplified Profile Parameters + + These are the operations and attributes that must be defined: + + protocol key format + string-to-key function + default string-to-key parameters + key-generation seed length, k + random-to-key function + As above for the normal encryption mechanism profile. + + unkeyed hash algorithm, H + This should be a collision-resistant hash algorithm with fixed- + size output, suitable for use in an HMAC [HMAC]. It must support + inputs of arbitrary length. Its output must be at least the + message block size (below). + + HMAC output size, h + This indicates the size of the leading substring output by the + HMAC function that should be used in transmitted messages. It + should be at least half the output size of the hash function H, + and at least 80 bits; it need not match the output size. + + message block size, m + This is the size of the smallest units the cipher can handle in + the mode in which it is being used. Messages will be padded to a + multiple of this size. If a block cipher is used in a mode that + + + + + + + + + +Raeburn Standards Track [Page 12] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + can handle messages that are not multiples of the cipher block + size, such as CBC mode with cipher text stealing (CTS, see [RC5]), + this value would be one octet. For traditional CBC mode with + padding, it would be the underlying cipher's block size. + + This value must be a multiple of eight bits (one octet). + + encryption/decryption functions, E and D + These are basic encryption and decryption functions for messages + of sizes that are multiples of the message block size. No + integrity checking or confounder should be included here. For + inputs these functions take the IV or similar data, a protocol- + format key, and an octet string, returning a new IV and octet + string. + + The encryption function is not required to use CBC mode but is + assumed to be using something with similar properties. In + particular, prepending a cipher block-size confounder to the + plaintext should alter the entire ciphertext (comparable to + choosing and including a random initial vector for CBC mode). + + The result of encrypting one cipher block (of size c, above) must + be deterministic for the random octet generation function DR in + the previous section to work. For best security, it should also + be no larger than c. + + cipher block size, c + This is the block size of the block cipher underlying the + encryption and decryption functions indicated above, used for key + derivation and for the size of the message confounder and initial + vector. (If a block cipher is not in use, some comparable + parameter should be determined.) It must be at least 5 octets. + + This is not actually an independent parameter; rather, it is a + property of the functions E and D. It is listed here to clarify + the distinction between it and the message block size, m. + + Although there are still a number of properties to specify, they are + fewer and simpler than in the full profile. + +5.3. Cryptosystem Profile Based on Simplified Profile + + The above key derivation function is used to produce three + intermediate keys. One is used for computing checksums of + unencrypted data. The other two are used for encrypting and + checksumming plaintext to be sent encrypted. + + + + + +Raeburn Standards Track [Page 13] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + The ciphertext output is the concatenation of the output of the basic + encryption function E and a (possibly truncated) HMAC using the + specified hash function H, both applied to the plaintext with a + random confounder prefix and sufficient padding to bring it to a + multiple of the message block size. When the HMAC is computed, the + key is used in the protocol key form. + + Decryption is performed by removing the (partial) HMAC, decrypting + the remainder, and verifying the HMAC. The cipher state is an + initial vector, initialized to zero. + + The substring notation "[1..h]" in the following table should be read + as using 1-based indexing; leading substrings are used. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Raeburn Standards Track [Page 14] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + Cryptosystem from Simplified Profile +------------------------------------------------------------------------ +protocol key format As given. + +specific key structure Three protocol-format keys: { Kc, Ke, Ki }. + +key-generation seed As given. +length + +required checksum As defined below in section 5.4. +mechanism + +cipher state Initial vector (usually of length c) + +initial cipher state All bits zero + +encryption function conf = Random string of length c + pad = Shortest string to bring confounder + and plaintext to a length that's a + multiple of m. + (C1, newIV) = E(Ke, conf | plaintext | pad, + oldstate.ivec) + H1 = HMAC(Ki, conf | plaintext | pad) + ciphertext = C1 | H1[1..h] + newstate.ivec = newIV + +decryption function (C1,H1) = ciphertext + (P1, newIV) = D(Ke, C1, oldstate.ivec) + if (H1 != HMAC(Ki, P1)[1..h]) + report error + newstate.ivec = newIV + +default string-to-key As given. +params + +pseudo-random function tmp1 = H(octet-string) + tmp2 = truncate tmp1 to multiple of m + PRF = E(DK(protocol-key, prfconstant), + tmp2, initial-cipher-state) + + The "prfconstant" used in the PRF operation is the three-octet string + "prf". + + + + + + + + + +Raeburn Standards Track [Page 15] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + Cryptosystem from Simplified Profile +------------------------------------------------------------------------ +key generation functions: + +string-to-key function As given. + +random-to-key function As given. + +key-derivation function The "well-known constant" used for the DK + function is the key usage number, expressed as + four octets in big-endian order, followed by + one octet indicated below. + + Kc = DK(base-key, usage | 0x99); + Ke = DK(base-key, usage | 0xAA); + Ki = DK(base-key, usage | 0x55); + +5.4. Checksum Profiles Based on Simplified Profile + + When an encryption system is defined with the simplified profile + given in section 5.2, a checksum algorithm may be defined for it as + follows: + + Checksum Mechanism from Simplified Profile + -------------------------------------------------- + associated cryptosystem As defined above. + + get_mic HMAC(Kc, message)[1..h] + + verify_mic get_mic and compare + + The HMAC function and key Kc are as described in section 5.3. + +6. Profiles for Kerberos Encryption and Checksum Algorithms + + These profiles describe the encryption and checksum systems defined + for Kerberos. The astute reader will notice that some of them do not + fulfill all the requirements outlined in previous sections. These + systems are defined for backward compatibility; newer implementations + should (whenever possible) attempt to utilize encryption systems that + satisfy all the profile requirements. + + The full list of current encryption and checksum type number + assignments, including values currently reserved but not defined in + this document, is given in section 8. + + + + + + +Raeburn Standards Track [Page 16] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + +6.1. Unkeyed Checksums + + These checksum types use no encryption keys and thus can be used in + combination with any encryption type, but they may only be used with + caution, in limited circumstances where the lack of a key does not + provide a window for an attack, preferably as part of an encrypted + message [6]. Keyed checksum algorithms are recommended. + +6.1.1. The RSA MD5 Checksum + + The RSA-MD5 checksum calculates a checksum by using the RSA MD5 + algorithm [MD5-92]. The algorithm takes as input an input message of + arbitrary length and produces as output a 128-bit (sixteen octet) + checksum. + + rsa-md5 + ---------------------------------------------- + associated cryptosystem any + + get_mic rsa-md5(msg) + + verify_mic get_mic and compare + + The rsa-md5 checksum algorithm is assigned a checksum type number of + seven (7). + +6.1.2. The RSA MD4 Checksum + + The RSA-MD4 checksum calculates a checksum using the RSA MD4 + algorithm [MD4-92]. The algorithm takes as input an input message of + arbitrary length and produces as output a 128-bit (sixteen octet) + checksum. + + rsa-md4 + ---------------------------------------------- + associated cryptosystem any + + get_mic md4(msg) + + verify_mic get_mic and compare + + The rsa-md4 checksum algorithm is assigned a checksum type number of + two (2). + + + + + + + + +Raeburn Standards Track [Page 17] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + +6.1.3. CRC-32 Checksum + + This CRC-32 checksum calculates a checksum based on a cyclic + redundancy check as described in ISO 3309 [CRC] but modified as + described below. The resulting checksum is four (4) octets in + length. The CRC-32 is neither keyed nor collision-proof; thus, the + use of this checksum is not recommended. An attacker using a + probabilistic chosen-plaintext attack as described in [SG92] might be + able to generate an alternative message that satisfies the checksum. + + The CRC-32 checksum used in the des-cbc-crc encryption mode is + identical to the 32-bit FCS described in ISO 3309 with two + exceptions: The sum with the all-ones polynomial times x**k is + omitted, and the final remainder is not ones-complemented. ISO 3309 + describes the FCS in terms of bits, whereas this document describes + the Kerberos protocol in terms of octets. To clarify the ISO 3309 + definition for the purpose of computing the CRC-32 in the des-cbc-crc + encryption mode, the ordering of bits in each octet shall be assumed + to be LSB first. Given this assumed ordering of bits within an + octet, the mapping of bits to polynomial coefficients shall be + identical to that specified in ISO 3309. + + Test values for this modified CRC function are included in appendix + A.5. + + crc32 + ---------------------------------------------- + associated cryptosystem any + + get_mic crc32(msg) + + verify_mic get_mic and compare + + The crc32 checksum algorithm is assigned a checksum type number of + one (1). + +6.2. DES-Based Encryption and Checksum Types + + These encryption systems encrypt information under the Data + Encryption Standard [DES77] by using the cipher block chaining mode + [DESM80]. A checksum is computed as described below and placed in + the cksum field. DES blocks are eight bytes. As a result, the data + to be encrypted (the concatenation of confounder, checksum, and + message) must be padded to an eight byte boundary before encryption. + The values of the padding bytes are unspecified. + + + + + + +Raeburn Standards Track [Page 18] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + Plaintext and DES ciphertext are encoded as blocks of eight octets, + which are concatenated to make the 64-bit inputs for the DES + algorithms. The first octet supplies the eight most significant bits + (with the octet's MSB used as the DES input block's MSB, etc.), the + second octet the next eight bits, and so on. The eighth octet + supplies the 8 least significant bits. + + Encryption under DES using cipher block chaining requires an + additional input in the form of an initialization vector; this vector + is specified below for each encryption system. + + The DES specifications [DESI81] identify four 'weak' and twelve + 'semi-weak' keys; these keys SHALL NOT be used for encrypting + messages for use in Kerberos. The "variant keys" generated for the + RSA-MD5-DES, RSA-MD4-DES, and DES-MAC checksum types by an + eXclusive-OR of a DES key with a constant are not checked for this + property. + + A DES key is eight octets of data. This consists of 56 bits of + actual key data, and eight parity bits, one per octet. The key is + encoded as a series of eight octets written in MSB-first order. The + bits within the key are also encoded in MSB order. For example, if + the encryption key is + (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8), where + B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the + parity bits, the first octet of the key would be B1,B2,...,B7,P1 + (with B1 as the most significant bit). See the [DESM80] introduction + for reference. + + Encryption Data Format + + The format for the data to be encrypted includes a one-block + confounder, a checksum, the encoded plaintext, and any necessary + padding, as described in the following diagram. The msg-seq field + contains the part of the protocol message to be encrypted. + + +-----------+----------+---------+-----+ + |confounder | checksum | msg-seq | pad | + +-----------+----------+---------+-----+ + + One generates a random confounder of one block, placing it in + 'confounder'; zeros out the 'checksum' field (of length appropriate + to exactly hold the checksum to be computed); adds the necessary + padding; calculates the appropriate checksum over the whole sequence, + placing the result in 'checksum'; and then encrypts using the + specified encryption type and the appropriate key. + + + + + +Raeburn Standards Track [Page 19] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + String or Random-Data to Key Transformation + + To generate a DES key from two UTF-8 text strings (password and + salt), the two strings are concatenated, password first, and the + result is then padded with zero-valued octets to a multiple of eight + octets. + + The top bit of each octet (always zero if the password is plain + ASCII, as was assumed when the original specification was written) is + discarded, and the remaining seven bits of each octet form a + bitstring. This is then fan-folded and eXclusive-ORed with itself to + produce a 56-bit string. An eight-octet key is formed from this + string, each octet using seven bits from the bitstring, leaving the + least significant bit unassigned. The key is then "corrected" by + correcting the parity on the key, and if the key matches a 'weak' or + 'semi-weak' key as described in the DES specification, it is + eXclusive-ORed with the constant 0x00000000000000F0. This key is + then used to generate a DES CBC checksum on the initial string with + the salt appended. The result of the CBC checksum is then + "corrected" as described above to form the result, which is returned + as the key. + + For purposes of the string-to-key function, the DES CBC checksum is + calculated by CBC encrypting a string using the key as IV and the + final eight byte block as the checksum. + + Pseudocode follows: + + removeMSBits(8byteblock) { + /* Treats a 64 bit block as 8 octets and removes the MSB in + each octet (in big endian mode) and concatenates the + result. E.g., the input octet string: + 01110000 01100001 11110011 01110011 11110111 01101111 + 11110010 01100100 + results in the output bitstring: + 1110000 1100001 1110011 1110011 1110111 1101111 + 1110010 1100100 */ + } + + reverse(56bitblock) { + /* Treats a 56-bit block as a binary string and reverses it. + E.g., the input string: + 1000001 1010100 1001000 1000101 1001110 1000001 + 0101110 1001101 + results in the output string: + 1011001 0111010 1000001 0111001 1010001 0001001 + 0010101 1000001 */ + } + + + +Raeburn Standards Track [Page 20] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + add_parity_bits(56bitblock) { + /* Copies a 56-bit block into a 64-bit block, left shifts + content in each octet, and add DES parity bit. + E.g., the input string: + 1100000 0001111 0011100 0110100 1000101 1100100 + 0110110 0010111 + results in the output string: + 11000001 00011111 00111000 01101000 10001010 11001000 + 01101101 00101111 */ + } + + key_correction(key) { + fixparity(key); + if (is_weak_key(key)) + key = key XOR 0xF0; + return(key); + } + + mit_des_string_to_key(string,salt) { + odd = 1; + s = string | salt; + tempstring = 0; /* 56-bit string */ + pad(s); /* with nulls to 8 byte boundary */ + for (8byteblock in s) { + 56bitstring = removeMSBits(8byteblock); + if (odd == 0) reverse(56bitstring); + odd = ! odd; + tempstring = tempstring XOR 56bitstring; + } + tempkey = key_correction(add_parity_bits(tempstring)); + key = key_correction(DES-CBC-check(s,tempkey)); + return(key); + } + + des_string_to_key(string,salt,params) { + if (length(params) == 0) + type = 0; + else if (length(params) == 1) + type = params[0]; + else + error("invalid params"); + if (type == 0) + mit_des_string_to_key(string,salt); + else + error("invalid params"); + } + + + + + +Raeburn Standards Track [Page 21] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + One common extension is to support the "AFS string-to-key" algorithm, + which is not defined here, if the type value above is one (1). + + For generation of a key from a random bitstring, we start with a 56- + bit string and, as with the string-to-key operation above, insert + parity bits. If the result is a weak or semi-weak key, we modify it + by eXclusive-OR with the constant 0x00000000000000F0: + + des_random_to_key(bitstring) { + return key_correction(add_parity_bits(bitstring)); + } + +6.2.1. DES with MD5 + + The des-cbc-md5 encryption mode encrypts information under DES in CBC + mode with an all-zero initial vector and with an MD5 checksum + (described in [MD5-92]) computed and placed in the checksum field. + + The encryption system parameters for des-cbc-md5 are as follows: + + des-cbc-md5 + -------------------------------------------------------------------- + protocol key format 8 bytes, parity in low bit of each + + specific key structure copy of original key + + required checksum rsa-md5-des + mechanism + + key-generation seed 8 bytes + length + + cipher state 8 bytes (CBC initial vector) + + initial cipher state all-zero + + encryption function des-cbc(confounder | checksum | msg | pad, + ivec=oldstate) + where + checksum = md5(confounder | 0000... + | msg | pad) + + newstate = last block of des-cbc output + + decryption function decrypt encrypted text and verify checksum + + newstate = last block of ciphertext + + + + +Raeburn Standards Track [Page 22] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + des-cbc-md5 + -------------------------------------------------------------------- + default string-to-key empty string + params + + pseudo-random function des-cbc(md5(input-string), ivec=0) + + key generation functions: + + string-to-key des_string_to_key + + random-to-key des_random_to_key + + key-derivation identity + + The des-cbc-md5 encryption type is assigned the etype value three + (3). + +6.2.2. DES with MD4 + + The des-cbc-md4 encryption mode also encrypts information under DES + in CBC mode, with an all-zero initial vector. An MD4 checksum + (described in [MD4-92]) is computed and placed in the checksum field. + + des-cbc-md4 + -------------------------------------------------------------------- + protocol key format 8 bytes, parity in low bit of each + + specific key structure copy of original key + + required checksum rsa-md4-des + mechanism + + key-generation seed 8 bytes + length + + cipher state 8 bytes (CBC initial vector) + + initial cipher state all-zero + + encryption function des-cbc(confounder | checksum | msg | pad, + ivec=oldstate) + where + checksum = md4(confounder | 0000... + | msg | pad) + + newstate = last block of des-cbc output + + + + +Raeburn Standards Track [Page 23] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + des-cbc-md4 + -------------------------------------------------------------------- + + decryption function decrypt encrypted text and verify checksum + + newstate = last block of ciphertext + + default string-to-key empty string + params + + pseudo-random function des-cbc(md5(input-string), ivec=0) + + key generation functions: + + string-to-key des_string_to_key + + random-to-key copy input, then fix parity bits + + key-derivation identity + + Note that des-cbc-md4 uses md5, not md4, in the PRF definition. + + The des-cbc-md4 encryption algorithm is assigned the etype value two + (2). + +6.2.3. DES with CRC + + The des-cbc-crc encryption type uses DES in CBC mode with the key + used as the initialization vector, with a four-octet CRC-based + checksum computed as described in section 6.1.3. Note that this is + not a standard CRC-32 checksum, but a slightly modified one. + + des-cbc-crc + -------------------------------------------------------------------- + protocol key format 8 bytes, parity in low bit of each + + specific key structure copy of original key + + required checksum rsa-md5-des + mechanism + + key-generation seed 8 bytes + length + + cipher state 8 bytes (CBC initial vector) + + + + + + +Raeburn Standards Track [Page 24] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + des-cbc-crc + -------------------------------------------------------------------- + initial cipher state copy of original key + + encryption function des-cbc(confounder | checksum | msg | pad, + ivec=oldstate) + where + checksum = crc(confounder | 00000000 + | msg | pad) + + newstate = last block of des-cbc output + + decryption function decrypt encrypted text and verify checksum + + newstate = last block of ciphertext + + default string-to-key empty string + params + + pseudo-random function des-cbc(md5(input-string), ivec=0) + + key generation functions: + + string-to-key des_string_to_key + + random-to-key copy input, then fix parity bits + + key-derivation identity + + The des-cbc-crc encryption algorithm is assigned the etype value one + (1). + +6.2.4. RSA MD5 Cryptographic Checksum Using DES + + The RSA-MD5-DES checksum calculates a keyed collision-proof checksum + by prepending an eight octet confounder before the text, applying the + RSA MD5 checksum algorithm, and encrypting the confounder and the + checksum by using DES in cipher-block-chaining (CBC) mode with a + variant of the key, where the variant is computed by eXclusive-ORing + the key with the hexadecimal constant 0xF0F0F0F0F0F0F0F0. The + initialization vector should be zero. The resulting checksum is 24 + octets long. + + + + + + + + + +Raeburn Standards Track [Page 25] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + rsa-md5-des + ---------------------------------------------------------------- + associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc + + get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, + conf | rsa-md5(conf | msg)) + + verify_mic decrypt and verify rsa-md5 checksum + + The rsa-md5-des checksum algorithm is assigned a checksum type number + of eight (8). + +6.2.5. RSA MD4 Cryptographic Checksum Using DES + + The RSA-MD4-DES checksum calculates a keyed collision-proof checksum + by prepending an eight octet confounder before the text, applying the + RSA MD4 checksum algorithm [MD4-92], and encrypting the confounder + and the checksum using DES in cipher-block-chaining (CBC) mode with a + variant of the key, where the variant is computed by eXclusive-ORing + the key with the constant 0xF0F0F0F0F0F0F0F0 [7]. The initialization + vector should be zero. The resulting checksum is 24 octets long. + + rsa-md4-des + ---------------------------------------------------------------- + associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc + + get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, + conf | rsa-md4(conf | msg), + ivec=0) + + verify_mic decrypt and verify rsa-md4 checksum + + The rsa-md4-des checksum algorithm is assigned a checksum type number + of three (3). + +6.2.6. RSA MD4 Cryptographic Checksum Using DES Alternative + + The RSA-MD4-DES-K checksum calculates a keyed collision-proof + checksum by applying the RSA MD4 checksum algorithm and encrypting + the results by using DES in cipher block chaining (CBC) mode with a + DES key as both key and initialization vector. The resulting + checksum is 16 octets long. This checksum is tamper-proof and + believed to be collision-proof. Note that this checksum type is the + old method for encoding the RSA-MD4-DES checksum; it is no longer + recommended. + + + + + + +Raeburn Standards Track [Page 26] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + rsa-md4-des-k + ---------------------------------------------------------------- + associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc + + get_mic des-cbc(key, md4(msg), ivec=key) + + verify_mic decrypt, compute checksum and compare + + The rsa-md4-des-k checksum algorithm is assigned a checksum type + number of six (6). + +6.2.7. DES CBC Checksum + + The DES-MAC checksum is computed by prepending an eight octet + confounder to the plaintext, padding with zero-valued octets if + necessary to bring the length to a multiple of eight octets, + performing a DES CBC-mode encryption on the result by using the key + and an initialization vector of zero, taking the last block of the + ciphertext, prepending the same confounder, and encrypting the pair + by using DES in cipher-block-chaining (CBC) mode with a variant of + the key, where the variant is computed by eXclusive-ORing the key + with the constant 0xF0F0F0F0F0F0F0F0. The initialization vector + should be zero. The resulting checksum is 128 bits (sixteen octets) + long, 64 bits of which are redundant. This checksum is tamper-proof + and collision-proof. + + des-mac + --------------------------------------------------------------------- + associated des-cbc-md5, des-cbc-md4, des-cbc-crc + cryptosystem + + get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, + conf | des-mac(key, conf | msg | pad, ivec=0), + ivec=0) + + verify_mic decrypt, compute DES MAC using confounder, compare + + The des-mac checksum algorithm is assigned a checksum type number of + four (4). + +6.2.8. DES CBC Checksum Alternative + + The DES-MAC-K checksum is computed by performing a DES CBC-mode + encryption of the plaintext, with zero-valued padding bytes if + necessary to bring the length to a multiple of eight octets, and by + using the last block of the ciphertext as the checksum value. It is + keyed with an encryption key that is also used as the initialization + vector. The resulting checksum is 64 bits (eight octets) long. This + + + +Raeburn Standards Track [Page 27] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + checksum is tamper-proof and collision-proof. Note that this + checksum type is the old method for encoding the DESMAC checksum; it + is no longer recommended. + + des-mac-k + ---------------------------------------------------------------- + associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc + + get_mic des-mac(key, msg | pad, ivec=key) + + verify_mic compute MAC and compare + + The des-mac-k checksum algorithm is assigned a checksum type number + of five (5). + +6.3. Triple-DES Based Encryption and Checksum Types + + This encryption and checksum type pair is based on the Triple DES + cryptosystem in Outer-CBC mode and on the HMAC-SHA1 message + authentication algorithm. + + A Triple DES key is the concatenation of three DES keys as described + above for des-cbc-md5. A Triple DES key is generated from random + data by creating three DES keys from separate sequences of random + data. + + Encrypted data using this type must be generated as described in + section 5.3. If the length of the input data is not a multiple of + the block size, zero-valued octets must be used to pad the plaintext + to the next eight-octet boundary. The confounder must be eight + random octets (one block). + + The simplified profile for Triple DES, with key derivation as defined + in section 5, is as follows: + + des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd + ------------------------------------------------ + protocol key format 24 bytes, parity in low + bit of each + + key-generation seed 21 bytes + length + + + + + + + + + +Raeburn Standards Track [Page 28] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd + ------------------------------------------------ + hash function SHA-1 + + HMAC output size 160 bits + + message block size 8 bytes + + default string-to-key empty string + params + + encryption and triple-DES encrypt and + decryption functions decrypt, in outer-CBC + mode (cipher block size + 8 octets) + + key generation functions: + + random-to-key DES3random-to-key (see + below) + + string-to-key DES3string-to-key (see + below) + + The des3-cbc-hmac-sha1-kd encryption type is assigned the value + sixteen (16). The hmac-sha1-des3-kd checksum algorithm is assigned a + checksum type number of twelve (12). + +6.3.1. Triple DES Key Production (random-to-key, string-to-key) + + The 168 bits of random key data are converted to a protocol key value + as follows. First, the 168 bits are divided into three groups of 56 + bits, which are expanded individually into 64 bits as follows: + + DES3random-to-key: + 1 2 3 4 5 6 7 p + 9 10 11 12 13 14 15 p + 17 18 19 20 21 22 23 p + 25 26 27 28 29 30 31 p + 33 34 35 36 37 38 39 p + 41 42 43 44 45 46 47 p + 49 50 51 52 53 54 55 p + 56 48 40 32 24 16 8 p + + The "p" bits are parity bits computed over the data bits. The output + of the three expansions, each corrected to avoid "weak" and "semi- + weak" keys as in section 6.2, are concatenated to form the protocol + key value. + + + +Raeburn Standards Track [Page 29] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + The string-to-key function is used to transform UTF-8 passwords into + DES3 keys. The DES3 string-to-key function relies on the "N-fold" + algorithm and DK function, described in section 5. + + The n-fold algorithm is applied to the password string concatenated + with a salt value. For 3-key triple DES, the operation will involve + a 168-fold of the input password string, to generate an intermediate + key, from which the user's long-term key will be derived with the DK + function. The DES3 string-to-key function is shown here in + pseudocode: + + DES3string-to-key(passwordString, salt, params) + if (params != emptyString) + error("invalid params"); + s = passwordString + salt + tmpKey = random-to-key(168-fold(s)) + key = DK (tmpKey, KerberosConstant) + + Weak key checking is performed in the random-to-key and DK + operations. The KerberosConstant value is the byte string {0x6b 0x65 + 0x72 0x62 0x65 0x72 0x6f 0x73}. These values correspond to the ASCII + encoding for the string "kerberos". + +7. Use of Kerberos Encryption Outside This Specification + + Several Kerberos-based application protocols and preauthentication + systems have been designed and deployed that perform encryption and + message integrity checks in various ways. Although in some cases + there may be good reason for specifying these protocols in terms of + specific encryption or checksum algorithms, we anticipate that in + many cases this will not be true, and more generic approaches + independent of particular algorithms will be desirable. Rather than + have each protocol designer reinvent schemes for protecting data, + using multiple keys, etc., we have attempted to present in this + section a general framework that should be sufficient not only for + the Kerberos protocol itself but also for many preauthentication + systems and application protocols, while trying to avoid some of the + assumptions that can work their way into such protocol designs. + + Some problematic assumptions we've seen (and sometimes made) include + the following: a random bitstring is always valid as a key (not true + for DES keys with parity); the basic block encryption chaining mode + provides no integrity checking, or can easily be separated from such + checking (not true for many modes in development that do both + simultaneously); a checksum for a message always results in the same + value (not true if a confounder is incorporated); an initial vector + is used (may not be true if a block cipher in CBC mode is not in + use). + + + +Raeburn Standards Track [Page 30] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + Although such assumptions the may hold for any given set of + encryption and checksum algorithms, they may not be true of the next + algorithms to be defined, leaving the application protocol unable to + make use of those algorithms without updates to its specification. + + The Kerberos protocol uses only the attributes and operations + described in sections 3 and 4. Preauthentication systems and + application protocols making use of Kerberos are encouraged to use + them as well. The specific key and string-to-key parameters should + generally be treated as opaque. Although the string-to-key + parameters are manipulated as an octet string, the representation for + the specific key structure is implementation defined; it may not even + be a single object. + + We don't recommend doing so, but some application protocols will + undoubtedly continue to use the key data directly, even if only in + some of the currently existing protocol specifications. An + implementation intended to support general Kerberos applications may + therefore need to make the key data available, as well as the + attributes and operations described in sections 3 and 4 [8]. + +8. Assigned Numbers + + The following encryption-type numbers are already assigned or + reserved for use in Kerberos and related protocols. + + encryption type etype section or comment + ----------------------------------------------------------------- + des-cbc-crc 1 6.2.3 + des-cbc-md4 2 6.2.2 + des-cbc-md5 3 6.2.1 + [reserved] 4 + des3-cbc-md5 5 + [reserved] 6 + des3-cbc-sha1 7 + dsaWithSHA1-CmsOID 9 (pkinit) + md5WithRSAEncryption-CmsOID 10 (pkinit) + sha1WithRSAEncryption-CmsOID 11 (pkinit) + rc2CBC-EnvOID 12 (pkinit) + rsaEncryption-EnvOID 13 (pkinit from PKCS#1 v1.5) + rsaES-OAEP-ENV-OID 14 (pkinit from PKCS#1 v2.0) + des-ede3-cbc-Env-OID 15 (pkinit) + des3-cbc-sha1-kd 16 6.3 + aes128-cts-hmac-sha1-96 17 [KRB5-AES] + aes256-cts-hmac-sha1-96 18 [KRB5-AES] + rc4-hmac 23 (Microsoft) + rc4-hmac-exp 24 (Microsoft) + subkey-keymaterial 65 (opaque; PacketCable) + + + +Raeburn Standards Track [Page 31] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + (The "des3-cbc-sha1" assignment is a deprecated version using no key + derivation. It should not be confused with des3-cbc-sha1-kd.) + + Several numbers have been reserved for use in encryption systems not + defined here. Encryption-type numbers have unfortunately been + overloaded on occasion in Kerberos-related protocols, so some of the + reserved numbers do not and will not correspond to encryption systems + fitting the profile presented here. + + The following checksum-type numbers are assigned or reserved. As + with encryption-type numbers, some overloading of checksum numbers + has occurred. + + Checksum type sumtype checksum section or + value size reference + --------------------------------------------------------------------- + CRC32 1 4 6.1.3 + rsa-md4 2 16 6.1.2 + rsa-md4-des 3 24 6.2.5 + des-mac 4 16 6.2.7 + des-mac-k 5 8 6.2.8 + rsa-md4-des-k 6 16 6.2.6 + rsa-md5 7 16 6.1.1 + rsa-md5-des 8 24 6.2.4 + rsa-md5-des3 9 24 ?? + sha1 (unkeyed) 10 20 ?? + hmac-sha1-des3-kd 12 20 6.3 + hmac-sha1-des3 13 20 ?? + sha1 (unkeyed) 14 20 ?? + hmac-sha1-96-aes128 15 20 [KRB5-AES] + hmac-sha1-96-aes256 16 20 [KRB5-AES] + [reserved] 0x8003 ? [GSS-KRB5] + + Encryption and checksum-type numbers are signed 32-bit values. Zero + is invalid, and negative numbers are reserved for local use. All + standardized values must be positive. + +9. Implementation Notes + + The "interface" described here is the minimal information that must + be defined to make a cryptosystem useful within Kerberos in an + interoperable fashion. The use of functional notation used in some + places is not an attempt to define an API for cryptographic + functionality within Kerberos. Actual implementations providing + clean APIs will probably make additional information available, that + could be derived from a specification written to the framework given + here. For example, an application designer may wish to determine the + largest number of bytes that can be encrypted without overflowing a + + + +Raeburn Standards Track [Page 32] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + certain size output buffer or conversely, the maximum number of bytes + that might be obtained by decrypting a ciphertext message of a given + size. (In fact, an implementation of the GSS-API Kerberos mechanism + [GSS-KRB5] will require some of these.) + + The presence of a mechanism in this document should not be taken to + indicate that it must be implemented for compliance with any + specification; required mechanisms will be specified elsewhere. + Indeed, some of the mechanisms described here for backward + compatibility are now considered rather weak for protecting critical + data. + +10. Security Considerations + + Recent years have brought so many advancements in large-scale attacks + capability against DES that it is no longer considered a strong + encryption mechanism. Triple-DES is generally preferred in its + place, despite its poorer performance. See [ESP-DES] for a summary + of some of the potential attacks and [EFF-DES] for a detailed + discussion of the implementation of particular attacks. However, + most Kerberos implementations still have DES as their primary + interoperable encryption type. + + DES has four 'weak' keys and twelve 'semi-weak' keys, and the use of + single-DES here avoids them. However, DES also has 48 'possibly- + weak' keys [Schneier96] (note that the tables in many editions of the + reference contains errors) that are not avoided. + + DES weak keys have the property that E1(E1(P)) = P (where E1 denotes + encryption of a single block with key 1). DES semi-weak keys, or + "dual" keys, are pairs of keys with the property that E1(P) = D2(P), + and thus E2(E1(P)) = P. Because of the use of CBC mode and the + leading random confounder, however, these properties are unlikely to + present a security problem. + + Many of the choices concerning when to perform weak-key corrections + relate more to compatibility with existing implementations than to + any risk analysis. + + Although checks are also done for the component DES keys in a + triple-DES key, the nature of the weak keys make it extremely + unlikely that they will weaken the triple-DES encryption. It is only + slightly more likely than having the middle of the three sub-keys + match one of the other two, which effectively converts the encryption + to single-DES - a case we make no effort to avoid. + + + + + + +Raeburn Standards Track [Page 33] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + The true CRC-32 checksum is not collision-proof; an attacker could + use a probabilistic chosen-plaintext attack to generate a valid + message even if a confounder is used [SG92]. The use of collision- + proof checksums is of course recommended for environments where such + attacks represent a significant threat. The "simplifications" (read: + bugs) introduced when CRC-32 was implemented for Kerberos cause + leading zeros effectively to be ignored, so messages differing only + in leading zero bits will have the same checksum. + + [HMAC] and [IPSEC-HMAC] discuss weaknesses of the HMAC algorithm. + Unlike [IPSEC-HMAC], the triple-DES specification here does not use + the suggested truncation of the HMAC output. As pointed out in + [IPSEC-HMAC], SHA-1 was not developed for use as a keyed hash + function, which is a criterion of HMAC. [HMAC-TEST] contains test + vectors for HMAC-SHA-1. + + The mit_des_string_to_key function was originally constructed with + the assumption that all input would be ASCII; it ignores the top bit + of each input byte. Folding with XOR is also not an especially good + mixing mechanism for preserving randomness. + + The n-fold function used in the string-to-key operation for des3- + cbc-hmac-sha1-kd was designed to cause each bit of input to + contribute equally to the output. It was not designed to maximize or + equally distribute randomness in the input, and conceivably + randomness may be lost in cases of partially structured input. This + should only be an issue for highly structured passwords, however. + + [RFC1851] discusses the relative strength of triple-DES encryption. + The relatively slow speed of triple-DES encryption may also be an + issue for some applications. + + [Bellovin91] suggests that analyses of encryption schemes include a + model of an attacker capable of submitting known plaintexts to be + encrypted with an unknown key, as well as be able to perform many + types of operations on known protocol messages. Recent experiences + with the chosen-plaintext attacks on Kerberos version 4 bear out the + value of this suggestion. + + The use of unkeyed encrypted checksums, such as those used in the + single-DES cryptosystems specified in [Kerb1510], allows for cut- + and-paste attacks, especially if a confounder is not used. In + addition, unkeyed encrypted checksums are vulnerable to chosen- + plaintext attacks: An attacker with access to an encryption oracle + can easily encrypt the required unkeyed checksum along with the + + + + + + +Raeburn Standards Track [Page 34] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + chosen plaintext. [Bellovin99] These weaknesses, combined with a + common implementation design choice described below, allow for a + cross-protocol attack from version 4 to version 5. + + The use of a random confounder is an important means to prevent an + attacker from making effective use of protocol exchanges as an + encryption oracle. In Kerberos version 4, the encryption of constant + plaintext to constant ciphertext makes an effective encryption oracle + for an attacker. The use of random confounders in [Kerb1510] + frustrates this sort of chosen-plaintext attack. + + Using the same key for multiple purposes can enable or increase the + scope of chosen-plaintext attacks. Some software that implements + both versions 4 and 5 of the Kerberos protocol uses the same keys for + both versions. This enables the encryption oracle of version 4 to be + used to attack version 5. Vulnerabilities to attacks such as this + cross-protocol attack make it unwise to use a key for multiple + purposes. + + This document, like the Kerberos protocol, does not address limiting + the amount of data a key may be used with to a quantity based on the + robustness of the algorithm or size of the key. It is assumed that + any defined algorithms and key sizes will be strong enough to support + very large amounts of data, or they will be deprecated once + significant attacks are known. + + This document also places no bounds on the amount of data that can be + handled in various operations. To avoid denial of service attacks, + implementations will probably seek to restrict message sizes at some + higher level. + +11. IANA Considerations + + Two registries for numeric values have been created: Kerberos + Encryption Type Numbers and Kerberos Checksum Type Numbers. These + are signed values ranging from -2147483648 to 2147483647. Positive + values should be assigned only for algorithms specified in accordance + with this specification for use with Kerberos or related protocols. + Negative values are for private use; local and experimental + algorithms should use these values. Zero is reserved and may not be + assigned. + + Positive encryption- and checksum-type numbers may be assigned + following either of two policies described in [BCP26]. + + Standards-track specifications may be assigned values under the + Standards Action policy. + + + + +Raeburn Standards Track [Page 35] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + Specifications in non-standards track RFCs may be assigned values + after Expert Review. A non-IETF specification may be assigned values + by publishing an Informational or standards-track RFC referencing the + external specification; that specification must be public and + published in some permanent record, much like the IETF RFCs. It is + highly desirable, though not required, that the full specification be + published as an IETF RFC. + + Smaller encryption type values should be used for IETF standards- + track mechanisms, and much higher values (16777216 and above) for + other mechanisms. (Rationale: In the Kerberos ASN.1 encoding, + smaller numbers encode to smaller octet sequences, so this favors + standards-track mechanisms with slightly smaller messages.) Aside + from that guideline, IANA may choose numbers as it sees fit. + + Internet-Draft specifications should not include values for + encryption- and checksum-type numbers. Instead, they should indicate + that values would be assigned by IANA when the document is approved + as an RFC. For development and interoperability testing, values in + the private-use range (negative values) may be used but should not be + included in the draft specification. + + Each registered value should have an associated unique reference + name. The lists given in section 8 were used to create the initial + registry; they include reservations for specifications in progress in + parallel with this document, and certain other values believed to + already be in use. + +12. Acknowledgements + + This document is an extension of the encryption specification + included in [Kerb1510] by B. Clifford Neuman and John Kohl, and much + of the text of the background, concepts, and DES specifications is + drawn directly from that document. + + The abstract framework presented in this document was put together by + Jeff Altman, Sam Hartman, Jeff Hutzelman, Cliff Neuman, Ken Raeburn, + and Tom Yu, and the details were refined several times based on + comments from John Brezak and others. + + Marc Horowitz wrote the original specification of triple-DES and key + derivation in a pair of Internet-Drafts (under the names draft- + horowitz-key-derivation and draft-horowitz-kerb-key-derivation) that + were later folded into a draft revision of [Kerb1510], from which + this document was later split off. + + + + + + +Raeburn Standards Track [Page 36] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + Tom Yu provided the text describing the modifications to the standard + CRC algorithm as Kerberos implementations actually use it, and some + of the text in the Security Considerations section. + + Miroslav Jurisic provided information for one of the UTF-8 test cases + for the string-to-key functions. + + Marcus Watts noticed some errors in earlier versions and pointed out + that the simplified profile could easily be modified to support + cipher text stealing modes. + + Simon Josefsson contributed some clarifications to the DES "CBC + checksum" and string-to-key and weak key descriptions, and some test + vectors. + + Simon Josefsson, Louis LeVay, and others also caught some errors in + earlier versions of this document. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Raeburn Standards Track [Page 37] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + +A. Test Vectors + + This section provides test vectors for various functions defined or + described in this document. For convenience, most inputs are ASCII + strings, though some UTF-8 samples are provided for string-to-key + functions. Keys and other binary data are specified as hexadecimal + strings. + +A.1. n-fold + + The n-fold function is defined in section 5.1. As noted there, the + sample vector in the original paper defining the algorithm appears to + be incorrect. Here are some test cases provided by Marc Horowitz and + Simon Josefsson: + + 64-fold("012345") = + 64-fold(303132333435) = be072631276b1955 + + 56-fold("password") = + 56-fold(70617373776f7264) = 78a07b6caf85fa + + 64-fold("Rough Consensus, and Running Code") = + 64-fold(526f75676820436f6e73656e7375732c20616e642052756e + 6e696e6720436f6465) = bb6ed30870b7f0e0 + + 168-fold("password") = + 168-fold(70617373776f7264) = + 59e4a8ca7c0385c3c37b3f6d2000247cb6e6bd5b3e + + 192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") + 192-fold(4d41535341434856534554545320494e5354495456544520 + 4f4620544543484e4f4c4f4759) = + db3b0d8f0b061e603282b308a50841229ad798fab9540c1b + + 168-fold("Q") = + 168-fold(51) = + 518a54a2 15a8452a 518a54a2 15a8452a + 518a54a2 15 + + 168-fold("ba") = + 168-fold(6261) = + fb25d531 ae897449 9f52fd92 ea9857c4 + ba24cf29 7e + + Here are some additional values corresponding to folded values of the + string "kerberos"; the 64-bit form is used in the des3 string-to-key + (section 6.3.1). + + + + +Raeburn Standards Track [Page 38] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + 64-fold("kerberos") = + 6b657262 65726f73 + 128-fold("kerberos") = + 6b657262 65726f73 7b9b5b2b 93132b93 + 168-fold("kerberos") = + 8372c236 344e5f15 50cd0747 e15d62ca + 7a5a3bce a4 + 256-fold("kerberos") = + 6b657262 65726f73 7b9b5b2b 93132b93 + 5c9bdcda d95c9899 c4cae4de e6d6cae4 + + Note that the initial octets exactly match the input string when the + output length is a multiple of the input length. + +A.2. mit_des_string_to_key + + The function mit_des_string_to_key is defined in section 6.2. We + present here several test values, with some of the intermediate + results. The fourth test demonstrates the use of UTF-8 with three + characters. The last two tests are specifically constructed so as to + trigger the weak-key fixups for the intermediate key produced by + fan-folding; we have no test cases that cause such fixups for the + final key. + +UTF-8 encodings used in test vector: +eszett U+00DF C3 9F s-caron U+0161 C5 A1 +c-acute U+0107 C4 87 g-clef U+1011E F0 9D 84 9E + +Test vector: + +salt: "ATHENA.MIT.EDUraeburn" + 415448454e412e4d49542e4544557261656275726e +password: "password" 70617373776f7264 +fan-fold result: c01e38688ac86c2e +intermediate key: c11f38688ac86d2f +DES key: cbc22fae235298e3 + +salt: "WHITEHOUSE.GOVdanny" + 5748495445484f5553452e474f5664616e6e79 +password: "potatoe" 706f7461746f65 +fan-fold result: a028944ee63c0416 +intermediate key: a129944fe63d0416 +DES key: df3d32a74fd92a01 + +salt: "EXAMPLE.COMpianist" 4558414D504C452E434F4D7069616E697374 +password: g-clef (U+1011E) f09d849e +fan-fold result: 3c4a262c18fab090 +intermediate key: 3d4a262c19fbb091 + + + +Raeburn Standards Track [Page 39] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + +DES key: 4ffb26bab0cd9413 + +salt: "ATHENA.MIT.EDUJuri" + s-caron(U+0161) + "i" + c-acute(U+0107) + 415448454e412e4d49542e4544554a757269c5a169c487 +password: eszett(U+00DF) + c39f +fan-fold result:b8f6c40e305afc9e +intermediate key: b9f7c40e315bfd9e +DES key: 62c81a5232b5e69d + +salt: "AAAAAAAA" 4141414141414141 +password: "11119999" 3131313139393939 +fan-fold result: e0e0e0e0f0f0f0f0 +intermediate key: e0e0e0e0f1f1f101 +DES key: 984054d0f1a73e31 + +salt: "FFFFAAAA" 4646464641414141 +password: "NNNN6666" 4e4e4e4e36363636 +fan-fold result: 1e1e1e1e0e0e0e0e +intermediate key: 1f1f1f1f0e0e0efe +DES key: c4bf6b25adf7a4f8 + + This trace provided by Simon Josefsson shows the intermediate + processing stages of one of the test inputs: + + string_to_key (des-cbc-md5, string, salt) + ;; string: + ;; `password' (length 8 bytes) + ;; 70 61 73 73 77 6f 72 64 + ;; salt: + ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes) + ;; 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 72 61 + ;; 65 62 75 72 6e + des_string_to_key (string, salt) + ;; String: + ;; `password' (length 8 bytes) + ;; 70 61 73 73 77 6f 72 64 + ;; Salt: + ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes) + ;; 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 72 61 + ;; 65 62 75 72 6e + odd = 1; + s = string | salt; + tempstring = 0; /* 56-bit string */ + pad(s); /* with nulls to 8 byte boundary */ + ;; s = pad(string|salt): + ;; `passwordATHENA.MIT.EDUraeburn\x00\x00\x00' + ;; (length 32 bytes) + + + +Raeburn Standards Track [Page 40] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + ;; 70 61 73 73 77 6f 72 64 41 54 48 45 4e 41 2e 4d + ;; 49 54 2e 45 44 55 72 61 65 62 75 72 6e 00 00 00 + for (8byteblock in s) { + ;; loop iteration 0 + ;; 8byteblock: + ;; `password' (length 8 bytes) + ;; 70 61 73 73 77 6f 72 64 + ;; 01110000 01100001 01110011 01110011 01110111 01101111 + ;; 01110010 01100100 + 56bitstring = removeMSBits(8byteblock); + ;; 56bitstring: + ;; 1110000 1100001 1110011 1110011 1110111 1101111 + ;; 1110010 1100100 + if (odd == 0) reverse(56bitstring); ;; odd=1 + odd = ! odd + tempstring = tempstring XOR 56bitstring; + ;; tempstring + ;; 1110000 1100001 1110011 1110011 1110111 1101111 + ;; 1110010 1100100 + + for (8byteblock in s) { + ;; loop iteration 1 + ;; 8byteblock: + ;; `ATHENA.M' (length 8 bytes) + ;; 41 54 48 45 4e 41 2e 4d + ;; 01000001 01010100 01001000 01000101 01001110 01000001 + ;; 00101110 01001101 + 56bitstring = removeMSBits(8byteblock); + ;; 56bitstring: + ;; 1000001 1010100 1001000 1000101 1001110 1000001 + ;; 0101110 1001101 + if (odd == 0) reverse(56bitstring); ;; odd=0 + reverse(56bitstring) + ;; 56bitstring after reverse + ;; 1011001 0111010 1000001 0111001 1010001 0001001 + ;; 0010101 1000001 + odd = ! odd + tempstring = tempstring XOR 56bitstring; + ;; tempstring + ;; 0101001 1011011 0110010 1001010 0100110 1100110 + ;; 1100111 0100101 + + for (8byteblock in s) { + ;; loop iteration 2 + ;; 8byteblock: + ;; `IT.EDUra' (length 8 bytes) + ;; 49 54 2e 45 44 55 72 61 + ;; 01001001 01010100 00101110 01000101 01000100 01010101 + + + +Raeburn Standards Track [Page 41] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + ;; 01110010 01100001 + 56bitstring = removeMSBits(8byteblock); + ;; 56bitstring: + ;; 1001001 1010100 0101110 1000101 1000100 1010101 + ;; 1110010 1100001 + if (odd == 0) reverse(56bitstring); ;; odd=1 + odd = ! odd + tempstring = tempstring XOR 56bitstring; + ;; tempstring + ;; 1100000 0001111 0011100 0001111 1100010 0110011 + ;; 0010101 1000100 + + for (8byteblock in s) { + ;; loop iteration 3 + ;; 8byteblock: + ;; `eburn\x00\x00\x00' (length 8 bytes) + ;; 65 62 75 72 6e 00 00 00 + ;; 01100101 01100010 01110101 01110010 01101110 00000000 + ;; 00000000 00000000 + 56bitstring = removeMSBits(8byteblock); + ;; 56bitstring: + ;; 1100101 1100010 1110101 1110010 1101110 0000000 + ;; 0000000 0000000 + if (odd == 0) reverse(56bitstring); ;; odd=0 + reverse(56bitstring) + ;; 56bitstring after reverse + ;; 0000000 0000000 0000000 0111011 0100111 1010111 + ;; 0100011 1010011 + odd = ! odd + tempstring = tempstring XOR 56bitstring; + ;; tempstring + ;; 1100000 0001111 0011100 0110100 1000101 1100100 + ;; 0110110 0010111 + + for (8byteblock in s) { + } + ;; for loop terminated + + tempkey = key_correction(add_parity_bits(tempstring)); + ;; tempkey + ;; `\xc1\x1f8h\x8a\xc8m\x2f' (length 8 bytes) + ;; c1 1f 38 68 8a c8 6d 2f + ;; 11000001 00011111 00111000 01101000 10001010 11001000 + ;; 01101101 00101111 + + key = key_correction(DES-CBC-check(s,tempkey)); + ;; key + ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes) + + + +Raeburn Standards Track [Page 42] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + ;; cb c2 2f ae 23 52 98 e3 + ;; 11001011 11000010 00101111 10101110 00100011 01010010 + ;; 10011000 11100011 + + ;; string_to_key key: + ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes) + ;; cb c2 2f ae 23 52 98 e3 + +A.3. DES3 DR and DK + + These tests show the derived-random and derived-key values for the + des3-hmac-sha1-kd encryption scheme, using the DR and DK functions + defined in section 6.3.1. The input keys were randomly generated; + the usage values are from this specification. + + key: dce06b1f64c857a11c3db57c51899b2cc1791008ce973b92 + usage: 0000000155 + DR: 935079d14490a75c3093c4a6e8c3b049c71e6ee705 + DK: 925179d04591a79b5d3192c4a7e9c289b049c71f6ee604cd + + key: 5e13d31c70ef765746578531cb51c15bf11ca82c97cee9f2 + usage: 00000001aa + DR: 9f58e5a047d894101c469845d67ae3c5249ed812f2 + DK: 9e58e5a146d9942a101c469845d67a20e3c4259ed913f207 + + key: 98e6fd8a04a4b6859b75a176540b9752bad3ecd610a252bc + usage: 0000000155 + DR: 12fff90c773f956d13fc2ca0d0840349dbd39908eb + DK: 13fef80d763e94ec6d13fd2ca1d085070249dad39808eabf + + key: 622aec25a2fe2cad7094680b7c64940280084c1a7cec92b5 + usage: 00000001aa + DR: f8debf05b097e7dc0603686aca35d91fd9a5516a70 + DK: f8dfbf04b097e6d9dc0702686bcb3489d91fd9a4516b703e + + key: d3f8298ccb166438dcb9b93ee5a7629286a491f838f802fb + usage: 6b65726265726f73 ("kerberos") + DR: 2270db565d2a3d64cfbfdc5305d4f778a6de42d9da + DK: 2370da575d2a3da864cebfdc5204d56df779a7df43d9da43 + + key: c1081649ada74362e6a1459d01dfd30d67c2234c940704da + usage: 0000000155 + DR: 348056ec98fcc517171d2b4d7a9493af482d999175 + DK: 348057ec98fdc48016161c2a4c7a943e92ae492c989175f7 + + key: 5d154af238f46713155719d55e2f1f790dd661f279a7917c + usage: 00000001aa + DR: a8818bc367dadacbe9a6c84627fb60c294b01215e5 + + + +Raeburn Standards Track [Page 43] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + DK: a8808ac267dada3dcbe9a7c84626fbc761c294b01315e5c1 + + key: 798562e049852f57dc8c343ba17f2ca1d97394efc8adc443 + usage: 0000000155 + DR: c813f88b3be2b2f75424ce9175fbc8483b88c8713a + DK: c813f88a3be3b334f75425ce9175fbe3c8493b89c8703b49 + + key: 26dce334b545292f2feab9a8701a89a4b99eb9942cecd016 + usage: 00000001aa + DR: f58efc6f83f93e55e695fd252cf8fe59f7d5ba37ec + DK: f48ffd6e83f83e7354e694fd252cf83bfe58f7d5ba37ec5d + +A.4. DES3string_to_key + + These are the keys generated for some of the above input strings for + triple-DES with key derivation as defined in section 6.3.1. + + salt: "ATHENA.MIT.EDUraeburn" + passwd: "password" + key: 850bb51358548cd05e86768c313e3bfef7511937dcf72c3e + + salt: "WHITEHOUSE.GOVdanny" + passwd: "potatoe" + key: dfcd233dd0a43204ea6dc437fb15e061b02979c1f74f377a + + salt: "EXAMPLE.COMbuckaroo" + passwd: "penny" + key: 6d2fcdf2d6fbbc3ddcadb5da5710a23489b0d3b69d5d9d4a + + salt: "ATHENA.MIT.EDUJuri" + s-caron(U+0161) + "i" + + c-acute(U+0107) + passwd: eszett(U+00DF) + key: 16d5a40e1ce3bacb61b9dce00470324c831973a7b952feb0 + + salt: "EXAMPLE.COMpianist" + passwd: g-clef(U+1011E) + key: 85763726585dbc1cce6ec43e1f751f07f1c4cbb098f40b19 + +A.5. Modified CRC-32 + + Below are modified-CRC32 values for various ASCII and octet strings. + Only the printable ASCII characters are checksummed, without a C- + style trailing zero-valued octet. The 32-bit modified CRC and the + sequence of output bytes as used in Kerberos are shown. (The octet + values are separated here to emphasize that they are octet values and + not 32-bit numbers, which will be the most convenient form for + manipulation in some implementations. The bit and byte order used + + + + +Raeburn Standards Track [Page 44] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + internally for such a number is irrelevant; the octet sequence + generated is what is important.) + + mod-crc-32("foo") = 33 bc 32 73 + mod-crc-32("test0123456789") = d6 88 3e b8 + mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") = f7 80 41 e3 + mod-crc-32(8000) = 4b 98 83 3b + mod-crc-32(0008) = 32 88 db 0e + mod-crc-32(0080) = 20 83 b8 ed + mod-crc-32(80) = 20 83 b8 ed + mod-crc-32(80000000) = 3b b6 59 ed + mod-crc-32(00000001) = 96 30 07 77 + +B. Significant Changes from RFC 1510 + + The encryption and checksum mechanism profiles are new. The old + specification defined a few operations for various mechanisms but + didn't outline what abstract properties should be required of new + mechanisms, or how to ensure that a mechanism specification is + complete enough for interoperability between implementations. The + new profiles differ from the old specification in a few ways: + + Some message definitions in [Kerb1510] could be read as permitting + the initial vector to be specified by the application; the text + was too vague. It is explicitly not permitted in this + specification. Some encryption algorithms may not use + initialization vectors, so relying on chosen, secret + initialization vectors for security is unwise. Also, the + prepended confounder in the existing algorithms is roughly + equivalent to a per-message initialization vector that is revealed + in encrypted form. However, carrying state across from one + encryption to another is explicitly permitted through the opaque + "cipher state" object. + + The use of key derivation is new. + + Several new methods are introduced, including generation of a key + in wire-protocol format from random input data. + + The means for influencing the string-to-key algorithm are laid out + more clearly. + + Triple-DES support is new. + + The pseudo-random function is new. + + The des-cbc-crc, DES string-to-key and CRC descriptions have been + updated to align them with existing implementations. + + + +Raeburn Standards Track [Page 45] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + [Kerb1510] did not indicate what character set or encoding might be + used for pass phrases and salts. + + In [Kerb1510], key types, encryption algorithms, and checksum + algorithms were only loosely associated, and the association was not + well described. In this specification, key types and encryption + algorithms have a one-to-one correspondence, and associations between + encryption and checksum algorithms are described so that checksums + can be computed given negotiated keys, without requiring further + negotiation for checksum types. + +Notes + + [1] Although Message Authentication Code (MAC) or Message Integrity + Check (MIC) would be more appropriate terms for many of the uses + in this document, we continue to use the term checksum for + historical reasons. + + [2] Extending CBC mode across messages would be one obvious example + of this chaining. Another might be the use of counter mode, with + a counter randomly initialized and attached to the ciphertext; a + second message could continue incrementing the counter when + chaining the cipher state, thus avoiding having to transmit + another counter value. However, this chaining is only useful for + uninterrupted, ordered sequences of messages. + + [3] In the case of Kerberos, the encrypted objects will generally be + ASN.1 DER encodings, which contain indications of their length in + the first few octets. + + [4] As of the time of this writing, new modes of operation have been + proposed, some of which may permit encryption and integrity + protection simultaneously. After some of these proposals have + been subjected to adequate analysis, we may wish to formulate a + new simplified profile based on one of them. + + [5] It should be noted that the sample vector in appendix B.2 of the + original paper appears to be incorrect. Two independent + implementations from the specification (one in C by Marc + Horowitz, and another in Scheme by Bill Sommerfeld) agree on a + value different from that in [Blumenthal96]. + + [6] For example, in MIT's implementation of [Kerb1510], the rsa-md5 + unkeyed checksum of application data may be included in an + authenticator encrypted in a service's key. + + [7] Using a variant of the key limits the use of a key to a + particular function, separating the functions of generating a + + + +Raeburn Standards Track [Page 46] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + checksum from other encryption performed using the session key. + The constant 0xF0F0F0F0F0F0F0F0 was chosen because it maintains + key parity. The properties of DES precluded the use of the + complement. The same constant is used for similar purpose in the + Message Integrity Check in the Privacy Enhanced Mail standard. + + [8] Perhaps one of the more common reasons for directly performing + encryption is direct control over the negotiation and to select a + "sufficiently strong" encryption algorithm (whatever that means + in the context of a given application). Although Kerberos + directly provides no direct facility for negotiating encryption + types between the application client and server, there are other + means to accomplish similar goals (for example, requesting only + "strong" session key types from the KDC, and assuming that the + type actually returned by the KDC will be understood and + supported by the application server). + +Normative References + + [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing + an IANA Considerations Section in RFCs", BCP 26, RFC + 2434, October 1998. + + [Bellare98] Bellare, M., Desai, A., Pointcheval, D., and P. + Rogaway, "Relations Among Notions of Security for + Public-Key Encryption Schemes". Extended abstract + published in Advances in Cryptology-Crypto 98 + Proceedings, Lecture Notes in Computer Science Vol. + 1462, H. Krawcyzk ed., Springer-Verlag, 1998. + + [Blumenthal96] Blumenthal, U. and S. Bellovin, "A Better Key Schedule + for DES-Like Ciphers", Proceedings of PRAGOCRYPT '96, + 1996. + + [CRC] International Organization for Standardization, "ISO + Information Processing Systems - Data Communication - + High-Level Data Link Control Procedure - Frame + Structure," IS 3309, 3rd Edition, October 1984. + + [DES77] National Bureau of Standards, U.S. Department of + Commerce, "Data Encryption Standard," Federal + Information Processing Standards Publication 46, + Washington, DC, 1977. + + + + + + + + +Raeburn Standards Track [Page 47] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + [DESI81] National Bureau of Standards, U.S. Department of + Commerce, "Guidelines for implementing and using NBS + Data Encryption Standard," Federal Information + Processing Standards Publication 74, Washington, DC, + 1981. + + [DESM80] National Bureau of Standards, U.S. Department of + Commerce, "DES Modes of Operation," Federal + Information Processing Standards Publication 81, + Springfield, VA, December 1980. + + [Dolev91] Dolev, D., Dwork, C., and M. Naor, "Non-malleable + cryptography", Proceedings of the 23rd Annual + Symposium on Theory of Computing, ACM, 1991. + + [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: + Keyed-Hashing for Message Authentication", RFC 2104, + February 1997. + + [KRB5-AES] Raeburn, K., "Advanced Encryption Standard (AES) + Encryption for Kerberos 5", RFC 3962, February 2005. + + [MD4-92] Rivest, R., "The MD4 Message-Digest Algorithm", RFC + 1320, April 1992. + + [MD5-92] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC + 1321, April 1992. + + [SG92] Stubblebine, S. and V. D. Gligor, "On Message + Integrity in Cryptographic Protocols," in Proceedings + of the IEEE Symposium on Research in Security and + Privacy, Oakland, California, May 1992. + +Informative References + + [Bellovin91] Bellovin, S. M. and M. Merrit, "Limitations of the + Kerberos Authentication System", in Proceedings of the + Winter 1991 Usenix Security Conference, January, 1991. + + [Bellovin99] Bellovin, S. M. and D. Atkins, private communications, + 1999. + + [EFF-DES] Electronic Frontier Foundation, "Cracking DES: Secrets + of Encryption Research, Wiretap Politics, and Chip + Design", O'Reilly & Associates, Inc., May 1998. + + [ESP-DES] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher + Algorithm With Explicit IV", RFC 2405, November 1998. + + + +Raeburn Standards Track [Page 48] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + + [GSS-KRB5] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", + RFC 1964, June 1996. + + [HMAC-TEST] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and + HMAC-SHA-1", RFC 2202, September 1997. + + [IPSEC-HMAC] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 + within ESP and AH", RFC 2404, November 1998. + + [Kerb] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The + Kerberos Network Authentication Service (V5)", Work in + Progress, September 2004. + + [Kerb1510] Kohl, J. and C. Neuman, "The Kerberos Network + Authentication Service (V5)", RFC 1510, September + 1993. + + [RC5] Baldwin, R. and R. Rivest, "The RC5, RC5-CBC, RC5- + CBC-Pad, and RC5-CTS Algorithms", RFC 2040, October + 1996. + + [RFC1851] Karn, P., Metzger, P., and W. Simpson, "The ESP Triple + DES Transform", RFC 1851, September 1995. + + [Schneier96] Schneier, B., "Applied Cryptography Second Edition", + John Wiley & Sons, New York, NY, 1996. ISBN 0-471- + 12845-7. + +Editor's Address + + Kenneth Raeburn + Massachusetts Institute of Technology + 77 Massachusetts Avenue + Cambridge, MA 02139 + + EMail: raeburn@mit.edu + + + + + + + + + + + + + + + +Raeburn Standards Track [Page 49] + +RFC 3961 Encryption and Checksum Specifications February 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the IETF's procedures with respect to rights in IETF Documents can + be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Raeburn Standards Track [Page 50] + diff --git a/doc/krb5-protocol/rfc3962.txt b/doc/krb5-protocol/rfc3962.txt new file mode 100644 index 000000000..762beedbd --- /dev/null +++ b/doc/krb5-protocol/rfc3962.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group K. Raeburn +Request for Comments: 3962 MIT +Category: Standards Track February 2005 + + + Advanced Encryption Standard (AES) Encryption for Kerberos 5 + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + The United States National Institute of Standards and Technology + (NIST) has chosen a new Advanced Encryption Standard (AES), which is + significantly faster and (it is believed) more secure than the old + Data Encryption Standard (DES) algorithm. This document is a + specification for the addition of this algorithm to the Kerberos + cryptosystem suite. + +1. Introduction + + This document defines encryption key and checksum types for Kerberos + 5 using the AES algorithm recently chosen by NIST. These new types + support 128-bit block encryption and key sizes of 128 or 256 bits. + + Using the "simplified profile" of [KCRYPTO], we can define a pair of + encryption and checksum schemes. AES is used with ciphertext + stealing to avoid message expansion, and SHA-1 [SHA1] is the + associated checksum function. + +2. Conventions used in this Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 + [KEYWORDS]. + + + + + + +Raeburn Standards Track [Page 1] + +RFC 3962 AES Encryption for Kerberos 5 February 2005 + + +3. Protocol Key Representation + + The profile in [KCRYPTO] treats keys and random octet strings as + conceptually different. But since the AES key space is dense, we can + use any bit string of appropriate length as a key. We use the byte + representation for the key described in [AES], where the first bit of + the bit string is the high bit of the first byte of the byte string + (octet string) representation. + +4. Key Generation from Pass Phrases or Random Data + + Given the above format for keys, we can generate keys from the + appropriate amounts of random data (128 or 256 bits) by simply + copying the input string. + + To generate an encryption key from a pass phrase and salt string, we + use the PBKDF2 function from PKCS #5 v2.0 ([PKCS5]), with parameters + indicated below, to generate an intermediate key (of the same length + as the desired final key), which is then passed into the DK function + with the 8-octet ASCII string "kerberos" as is done for des3-cbc- + hmac-sha1-kd in [KCRYPTO]. (In [KCRYPTO] terms, the PBKDF2 function + produces a "random octet string", hence the application of the + random-to-key function even though it's effectively a simple identity + operation.) The resulting key is the user's long-term key for use + with the encryption algorithm in question. + + tkey = random2key(PBKDF2(passphrase, salt, iter_count, keylength)) + key = DK(tkey, "kerberos") + + The pseudorandom function used by PBKDF2 will be a SHA-1 HMAC of the + passphrase and salt, as described in Appendix B.1 to PKCS#5. + + The number of iterations is specified by the string-to-key parameters + supplied. The parameter string is four octets indicating an unsigned + number in big-endian order. This is the number of iterations to be + performed. If the value is 00 00 00 00, the number of iterations to + be performed is 4,294,967,296 (2**32). (Thus the minimum expressible + iteration count is 1.) + + For environments where slower hardware is the norm, implementations + of protocols such as Kerberos may wish to limit the number of + iterations to prevent a spoofed response supplied by an attacker from + consuming lots of client-side CPU time; if such a limit is + implemented, it SHOULD be no less than 50,000. Even for environments + with fast hardware, 4 billion iterations is likely to take a fairly + long time; much larger bounds might still be enforced, and it might + be wise for implementations to permit interruption of this operation + by the user if the environment allows for it. + + + +Raeburn Standards Track [Page 2] + +RFC 3962 AES Encryption for Kerberos 5 February 2005 + + + If the string-to-key parameters are not supplied, the value used is + 00 00 10 00 (decimal 4,096, indicating 4,096 iterations). + + Note that this is not a requirement, nor even a recommendation, for + this value to be used in "optimistic preauthentication" (e.g., + attempting timestamp-based preauthentication using the user's long- + term key without having first communicated with the KDC) in the + absence of additional information, or as a default value for sites to + use for their principals' long-term keys in their Kerberos database. + It is simply the interpretation of the absence of the string-to-key + parameter field when the KDC has had an opportunity to provide it. + + Sample test vectors are given in Appendix B. + +5. Ciphertext Stealing + + Cipher block chaining is used to encrypt messages, with the initial + vector stored in the cipher state. Unlike previous Kerberos + cryptosystems, we use ciphertext stealing to handle the possibly + partial final block of the message. + + Ciphertext stealing is described on pages 195-196 of [AC], and + section 8 of [RC5]; it has the advantage that no message expansion is + done during encryption of messages of arbitrary sizes as is typically + done in CBC mode with padding. Some errata for [RC5] are listed in + Appendix A and are considered part of the ciphertext stealing + technique as used here. + + Ciphertext stealing, as defined in [RC5], assumes that more than one + block of plain text is available. If exactly one block is to be + encrypted, that block is simply encrypted with AES (also known as ECB + mode). Input smaller than one block is padded at the end to one + block; the values of the padding bits are unspecified. + (Implementations MAY use all-zero padding, but protocols MUST NOT + rely on the result being deterministic. Implementations MAY use + random padding, but protocols MUST NOT rely on the result not being + deterministic. Note that in most cases, the Kerberos encryption + profile will add a random confounder independent of this padding.) + + For consistency, ciphertext stealing is always used for the last two + blocks of the data to be encrypted, as in [RC5]. If the data length + is a multiple of the block size, this is equivalent to plain CBC mode + with the last two ciphertext blocks swapped. + + A test vector is given in Appendix B. + + + + + + +Raeburn Standards Track [Page 3] + +RFC 3962 AES Encryption for Kerberos 5 February 2005 + + + The initial vector carried out from one encryption for use in a + subsequent encryption is the next-to-last block of the encryption + output; this is the encrypted form of the last plaintext block. When + decrypting, the next-to-last block of the supplied ciphertext is + carried forward as the next initial vector. If only one ciphertext + block is available (decrypting one block, or encrypting one block or + less), then that one block is carried out instead. + +6. Kerberos Algorithm Profile Parameters + + This is a summary of the parameters to be used with the simplified + algorithm profile described in [KCRYPTO]: + + +--------------------------------------------------------------------+ + | protocol key format 128- or 256-bit string | + | | + | string-to-key function PBKDF2+DK with variable | + | iteration count (see | + | above) | + | | + | default string-to-key parameters 00 00 10 00 | + | | + | key-generation seed length key size | + | | + | random-to-key function identity function | + | | + | hash function, H SHA-1 | + | | + | HMAC output size, h 12 octets (96 bits) | + | | + | message block size, m 1 octet | + | | + | encryption/decryption functions, AES in CBC-CTS mode | + | E and D (cipher block size 16 | + | octets), with next-to- | + | last block (last block | + | if only one) as CBC-style | + | ivec | + +--------------------------------------------------------------------+ + + Using this profile with each key size gives us two each of encryption + and checksum algorithm definitions. + + + + + + + + + +Raeburn Standards Track [Page 4] + +RFC 3962 AES Encryption for Kerberos 5 February 2005 + + +7. Assigned Numbers + + The following encryption type numbers are assigned: + + +--------------------------------------------------------------------+ + | encryption types | + +--------------------------------------------------------------------+ + | type name etype value key size | + +--------------------------------------------------------------------+ + | aes128-cts-hmac-sha1-96 17 128 | + | aes256-cts-hmac-sha1-96 18 256 | + +--------------------------------------------------------------------+ + + The following checksum type numbers are assigned: + + +--------------------------------------------------------------------+ + | checksum types | + +--------------------------------------------------------------------+ + | type name sumtype value length | + +--------------------------------------------------------------------+ + | hmac-sha1-96-aes128 15 96 | + | hmac-sha1-96-aes256 16 96 | + +--------------------------------------------------------------------+ + + These checksum types will be used with the corresponding encryption + types defined above. + +8. Security Considerations + + This new algorithm has not been around long enough to receive the + decades of intense analysis that DES has received. It is possible + that some weakness exists that has not been found by the + cryptographers analyzing these algorithms before and during the AES + selection process. + + The use of the HMAC function has drawbacks for certain pass phrase + lengths. For example, a pass phrase longer than the hash function + block size (64 bytes, for SHA-1) is hashed to a smaller size (20 + bytes) before applying the main HMAC algorithm. However, entropy is + generally sparse in pass phrases, especially in long ones, so this + may not be a problem in the rare cases of users with long pass + phrases. + + Also, generating a 256-bit key from a pass phrase of any length may + be deceptive, as the effective entropy in pass-phrase-derived key + cannot be nearly that large given the properties of the string-to-key + function described here. + + + + +Raeburn Standards Track [Page 5] + +RFC 3962 AES Encryption for Kerberos 5 February 2005 + + + The iteration count in PBKDF2 appears to be useful primarily as a + constant multiplier for the amount of work required for an attacker + using brute-force methods. Unfortunately, it also multiplies, by the + same amount, the work needed by a legitimate user with a valid + password. Thus the work factor imposed on an attacker (who may have + many powerful workstations at his disposal) must be balanced against + the work factor imposed on the legitimate user (who may have a PDA or + cell phone); the available computing power on either side increases + as time goes on, as well. A better way to deal with the brute-force + attack is through preauthentication mechanisms that provide better + protection of the user's long-term key. Use of such mechanisms is + out of the scope of this document. + + If a site does wish to use this means of protection against a brute- + force attack, the iteration count should be chosen based on the + facilities available to both attacker and legitimate user, and the + amount of work the attacker should be required to perform to acquire + the key or password. + + As an example: + + The author's tests on a 2GHz Pentium 4 system indicated that in + one second, nearly 90,000 iterations could be done, producing a + 256-bit key. This was using the SHA-1 assembly implementation + from OpenSSL, and a pre-release version of the PBKDF2 code for + MIT's Kerberos package, on a single system. No attempt was made + to do multiple hashes in parallel, so we assume an attacker doing + so can probably do at least 100,000 iterations per second -- + rounded up to 2**17, for ease of calculation. For simplicity, we + also assume the final AES encryption step costs nothing. + + Paul Leach estimates [LEACH] that a password-cracking dictionary + may have on the order of 2**21 entries, with capitalization, + punctuation, and other variations contributing perhaps a factor of + 2**11, giving a ballpark estimate of 2**32. + + Thus, for a known iteration count N and a known salt string, an + attacker with some number of computers comparable to the author's + would need roughly N*2**15 CPU seconds to convert the entire + dictionary plus variations into keys. + + An attacker using a dozen such computers for a month would have + roughly 2**25 CPU seconds available. So using 2**12 (4,096) + iterations would mean an attacker with a dozen such computers + dedicated to a brute-force attack against a single key (actually, + any password-derived keys sharing the same salt and iteration + + + + + +Raeburn Standards Track [Page 6] + +RFC 3962 AES Encryption for Kerberos 5 February 2005 + + + count) would process all the variations of the dictionary entries + in four months and, on average, would likely find the user's + password in two months. + + Thus, if this form of attack is of concern, users should be + required to change their passwords every few months, and an + iteration count a few orders of magnitude higher should be chosen. + Perhaps several orders of magnitude, as many users will tend to + use the shorter and simpler passwords (to the extent they can, + given a site's password quality checks) that the attacker would + likely try first. + + Since this estimate is based on currently available CPU power, the + iteration counts used for this mode of defense should be increased + over time, at perhaps 40%-60% each year or so. + + Note that if the attacker has a large amount of storage available, + intermediate results could be cached, saving a lot of work for the + next attack with the same salt and a greater number of iterations + than had been run at the point where the intermediate results were + saved. Thus, it would be wise to generate a new random salt + string when passwords are changed. The default salt string, + derived from the principal name, only protects against the use of + one dictionary of keys against multiple users. + + If the PBKDF2 iteration count can be spoofed by an intruder on the + network, and the limit on the accepted iteration count is very high, + the intruder may be able to introduce a form of denial of service + attack against the client by sending a very high iteration count, + causing the client to spend a great deal of CPU time computing an + incorrect key. + + An intruder spoofing the KDC reply, providing a low iteration count + and reading the client's reply from the network, may be able to + reduce the work needed in the brute-force attack outlined above. + Thus, implementations may seek to enforce lower bounds on the number + of iterations that will be used. + + Since threat models and typical end-user equipment will vary widely + from site to site, allowing site-specific configuration of such + bounds is recommended. + + Any benefit against other attacks specific to the HMAC or SHA-1 + algorithms is probably achieved with a fairly small number of + iterations. + + + + + + +Raeburn Standards Track [Page 7] + +RFC 3962 AES Encryption for Kerberos 5 February 2005 + + + In the "optimistic preauthentication" case mentioned in section 3, + the client may attempt to produce a key without first communicating + with the KDC. If the client has no additional information, it can + only guess as to the iteration count to be used. Even such + heuristics as "iteration count X was used to acquire tickets for the + same principal only N hours ago" can be wrong. Given the + recommendation above for increasing the iteration counts used over + time, it is impossible to recommend any specific default value for + this case; allowing site-local configuration is recommended. (If the + lower and upper bound checks described above are implemented, the + default count for optimistic preauthentication should be between + those bounds.) + + Ciphertext stealing mode, as it requires no additional padding in + most cases, will reveal the exact length of each message being + encrypted rather than merely bounding it to a small range of possible + lengths as in CBC mode. Such obfuscation should not be relied upon + at higher levels in any case; if the length must be obscured from an + outside observer, this should be done by intentionally varying the + length of the message to be encrypted. + +9. IANA Considerations + + Kerberos encryption and checksum type values used in section 7 were + previously reserved in [KCRYPTO] for the mechanisms defined in this + document. The registries have been updated to list this document as + the reference. + +10. Acknowledgements + + Thanks to John Brezak, Gerardo Diaz Cuellar, Ken Hornstein, Paul + Leach, Marcus Watts, Larry Zhu, and others for feedback on earlier + versions of this document. + + + + + + + + + + + + + + + + + + +Raeburn Standards Track [Page 8] + +RFC 3962 AES Encryption for Kerberos 5 February 2005 + + +A. Errata for RFC 2040 Section 8 + + (Copied from the RFC Editor's errata web site on July 8, 2004.) + + Reported By: Bob Baldwin; baldwin@plusfive.com + Date: Fri, 26 Mar 2004 06:49:02 -0800 + + In Section 8, Description of RC5-CTS, of the encryption method, + it says: + + 1. Exclusive-or Pn-1 with the previous ciphertext + block, Cn-2, to create Xn-1. + + It should say: + + 1. Exclusive-or Pn-1 with the previous ciphertext + block, Cn-2, to create Xn-1. For short messages where + Cn-2 does not exist, use IV. + + Reported By: Bob Baldwin; baldwin@plusfive.com + Date: Mon, 22 Mar 2004 20:26:40 -0800 + + In Section 8, first paragraph, second sentence says: + + This mode handles any length of plaintext and produces ciphertext + whose length matches the plaintext length. + + In Section 8, first paragraph, second sentence should read: + + This mode handles any length of plaintext longer than one + block and produces ciphertext whose length matches the + plaintext length. + + In Section 8, step 6 of the decryption method says: + + 6. Decrypt En to create Pn-1. + + In Section 8, step 6 of the decryption method should read: + + 6. Decrypt En and exclusive-or with Cn-2 to create Pn-1. + For short messages where Cn-2 does not exist, use the IV. + + + + + + + + + + +Raeburn Standards Track [Page 9] + +RFC 3962 AES Encryption for Kerberos 5 February 2005 + + +B. Sample Test Vectors + + Sample values for the PBKDF2 HMAC-SHA1 string-to-key function are + included below. + + Iteration count = 1 + Pass phrase = "password" + Salt = "ATHENA.MIT.EDUraeburn" + 128-bit PBKDF2 output: + cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15 + 128-bit AES key: + 42 26 3c 6e 89 f4 fc 28 b8 df 68 ee 09 79 9f 15 + 256-bit PBKDF2 output: + cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15 + 0a d1 f7 a0 4b b9 f3 a3 33 ec c0 e2 e1 f7 08 37 + 256-bit AES key: + fe 69 7b 52 bc 0d 3c e1 44 32 ba 03 6a 92 e6 5b + bb 52 28 09 90 a2 fa 27 88 39 98 d7 2a f3 01 61 + + Iteration count = 2 + Pass phrase = "password" + Salt="ATHENA.MIT.EDUraeburn" + 128-bit PBKDF2 output: + 01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d + 128-bit AES key: + c6 51 bf 29 e2 30 0a c2 7f a4 69 d6 93 bd da 13 + 256-bit PBKDF2 output: + 01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d + a0 53 78 b9 32 44 ec 8f 48 a9 9e 61 ad 79 9d 86 + 256-bit AES key: + a2 e1 6d 16 b3 60 69 c1 35 d5 e9 d2 e2 5f 89 61 + 02 68 56 18 b9 59 14 b4 67 c6 76 22 22 58 24 ff + + Iteration count = 1200 + Pass phrase = "password" + Salt = "ATHENA.MIT.EDUraeburn" + 128-bit PBKDF2 output: + 5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b + 128-bit AES key: + 4c 01 cd 46 d6 32 d0 1e 6d be 23 0a 01 ed 64 2a + 256-bit PBKDF2 output: + 5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b + a7 e5 2d db c5 e5 14 2f 70 8a 31 e2 e6 2b 1e 13 + 256-bit AES key: + 55 a6 ac 74 0a d1 7b 48 46 94 10 51 e1 e8 b0 a7 + 54 8d 93 b0 ab 30 a8 bc 3f f1 62 80 38 2b 8c 2a + + + + + +Raeburn Standards Track [Page 10] + +RFC 3962 AES Encryption for Kerberos 5 February 2005 + + + Iteration count = 5 + Pass phrase = "password" + Salt=0x1234567878563412 + 128-bit PBKDF2 output: + d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49 + 128-bit AES key: + e9 b2 3d 52 27 37 47 dd 5c 35 cb 55 be 61 9d 8e + 256-bit PBKDF2 output: + d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49 + 3f 98 d2 03 e6 be 49 a6 ad f4 fa 57 4b 6e 64 ee + 256-bit AES key: + 97 a4 e7 86 be 20 d8 1a 38 2d 5e bc 96 d5 90 9c + ab cd ad c8 7c a4 8f 57 45 04 15 9f 16 c3 6e 31 + (This test is based on values given in [PECMS].) + + Iteration count = 1200 + Pass phrase = (64 characters) + "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" + Salt="pass phrase equals block size" + 128-bit PBKDF2 output: + 13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9 + 128-bit AES key: + 59 d1 bb 78 9a 82 8b 1a a5 4e f9 c2 88 3f 69 ed + 256-bit PBKDF2 output: + 13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9 + c5 ec 59 f1 a4 52 f5 cc 9a d9 40 fe a0 59 8e d1 + 256-bit AES key: + 89 ad ee 36 08 db 8b c7 1f 1b fb fe 45 94 86 b0 + 56 18 b7 0c ba e2 20 92 53 4e 56 c5 53 ba 4b 34 + + Iteration count = 1200 + Pass phrase = (65 characters) + "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" + Salt = "pass phrase exceeds block size" + 128-bit PBKDF2 output: + 9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61 + 128-bit AES key: + cb 80 05 dc 5f 90 17 9a 7f 02 10 4c 00 18 75 1d + 256-bit PBKDF2 output: + 9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61 + 1a 8b 4d 28 26 01 db 3b 36 be 92 46 91 5e c8 2a + 256-bit AES key: + d7 8c 5c 9c b8 72 a8 c9 da d4 69 7f 0b b5 b2 d2 + 14 96 c8 2b eb 2c ae da 21 12 fc ee a0 57 40 1b + + + + + + + +Raeburn Standards Track [Page 11] + +RFC 3962 AES Encryption for Kerberos 5 February 2005 + + + Iteration count = 50 + Pass phrase = g-clef (0xf09d849e) + Salt = "EXAMPLE.COMpianist" + 128-bit PBKDF2 output: + 6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39 + 128-bit AES key: + f1 49 c1 f2 e1 54 a7 34 52 d4 3e 7f e6 2a 56 e5 + 256-bit PBKDF2 output: + 6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39 + e7 fe 37 a0 c4 1e 02 c2 81 ff 30 69 e1 e9 4f 52 + 256-bit AES key: + 4b 6d 98 39 f8 44 06 df 1f 09 cc 16 6d b4 b8 3c + 57 18 48 b7 84 a3 d6 bd c3 46 58 9a 3e 39 3f 9e + + Some test vectors for CBC with ciphertext stealing, using an initial + vector of all-zero. + + AES 128-bit key: + 0000: 63 68 69 63 6b 65 6e 20 74 65 72 69 79 61 6b 69 + + IV: + 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + Input: + 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 + 0010: 20 + Output: + 0000: c6 35 35 68 f2 bf 8c b4 d8 a5 80 36 2d a7 ff 7f + 0010: 97 + Next IV: + 0000: c6 35 35 68 f2 bf 8c b4 d8 a5 80 36 2d a7 ff 7f + + IV: + 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + Input: + 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 + 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 + Output: + 0000: fc 00 78 3e 0e fd b2 c1 d4 45 d4 c8 ef f7 ed 22 + 0010: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 + Next IV: + 0000: fc 00 78 3e 0e fd b2 c1 d4 45 d4 c8 ef f7 ed 22 + + + + + + + + + + +Raeburn Standards Track [Page 12] + +RFC 3962 AES Encryption for Kerberos 5 February 2005 + + + IV: + 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + Input: + 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 + 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 + Output: + 0000: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8 + 0010: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 + Next IV: + 0000: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8 + + IV: + 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + Input: + 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 + 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 + 0020: 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c + Output: + 0000: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 + 0010: b3 ff fd 94 0c 16 a1 8c 1b 55 49 d2 f8 38 02 9e + 0020: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 + Next IV: + 0000: b3 ff fd 94 0c 16 a1 8c 1b 55 49 d2 f8 38 02 9e + + IV: + 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + Input: + 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 + 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 + 0020: 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20 + Output: + 0000: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 + 0010: 9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8 + 0020: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8 + Next IV: + 0000: 9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8 + + + + + + + + + + + + + + + +Raeburn Standards Track [Page 13] + +RFC 3962 AES Encryption for Kerberos 5 February 2005 + + + IV: + 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + Input: + 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 + 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 + 0020: 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20 + 0030: 61 6e 64 20 77 6f 6e 74 6f 6e 20 73 6f 75 70 2e + Output: + 0000: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 + 0010: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8 + 0020: 48 07 ef e8 36 ee 89 a5 26 73 0d bc 2f 7b c8 40 + 0030: 9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8 + Next IV: + 0000: 48 07 ef e8 36 ee 89 a5 26 73 0d bc 2f 7b c8 40 + +Normative References + + [AC] Schneier, B., "Applied Cryptography", second edition, John + Wiley and Sons, New York, 1996. + + [AES] National Institute of Standards and Technology, U.S. + Department of Commerce, "Advanced Encryption Standard", + Federal Information Processing Standards Publication 197, + Washington, DC, November 2001. + + [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for + Kerberos 5", RFC 3961, February 2005. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [PKCS5] Kaliski, B., "PKCS #5: Password-Based Cryptography + Specification Version 2.0", RFC 2898, September 2000. + + [RC5] Baldwin, R. and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, + and RC5-CTS Algorithms", RFC 2040, October 1996. + + [SHA1] National Institute of Standards and Technology, U.S. + Department of Commerce, "Secure Hash Standard", Federal + Information Processing Standards Publication 180-1, + Washington, DC, April 1995. + + + + + + + + + + +Raeburn Standards Track [Page 14] + +RFC 3962 AES Encryption for Kerberos 5 February 2005 + + +Informative References + + [LEACH] Leach, P., email to IETF Kerberos working group mailing + list, 5 May 2003, ftp://ftp.ietf.org/ietf-mail- + archive/krb-wg/2003-05.mail. + + [PECMS] Gutmann, P., "Password-based Encryption for CMS", RFC + 3211, December 2001. + +Author's Address + + Kenneth Raeburn + Massachusetts Institute of Technology + 77 Massachusetts Avenue + Cambridge, MA 02139 + + EMail: raeburn@mit.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Raeburn Standards Track [Page 15] + +RFC 3962 AES Encryption for Kerberos 5 February 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the IETF's procedures with respect to rights in IETF Documents can + be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Raeburn Standards Track [Page 16] + diff --git a/doc/krb5-protocol/rfc4120.txt b/doc/krb5-protocol/rfc4120.txt new file mode 100644 index 000000000..e2816aff2 --- /dev/null +++ b/doc/krb5-protocol/rfc4120.txt @@ -0,0 +1,7731 @@ + + + + + + +Network Working Group C. Neuman +Request for Comments: 4120 USC-ISI +Obsoletes: 1510 T. Yu +Category: Standards Track S. Hartman + K. Raeburn + MIT + July 2005 + + + The Kerberos Network Authentication Service (V5) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document provides an overview and specification of Version 5 of + the Kerberos protocol, and it obsoletes RFC 1510 to clarify aspects + of the protocol and its intended use that require more detailed or + clearer explanation than was provided in RFC 1510. This document is + intended to provide a detailed description of the protocol, suitable + for implementation, together with descriptions of the appropriate use + of protocol messages and fields within those messages. + + + + + + + + + + + + + + + + + + + +Neuman, et al. Standards Track [Page 1] + +RFC 4120 Kerberos V5 July 2005 + + +Table of Contents + + 1. Introduction ....................................................5 + 1.1. The Kerberos Protocol ......................................6 + 1.2. Cross-Realm Operation ......................................8 + 1.3. Choosing a Principal with Which to Communicate .............9 + 1.4. Authorization .............................................10 + 1.5. Extending Kerberos without Breaking Interoperability ......11 + 1.5.1. Compatibility with RFC 1510 ........................11 + 1.5.2. Sending Extensible Messages ........................12 + 1.6. Environmental Assumptions .................................12 + 1.7. Glossary of Terms .........................................13 + 2. Ticket Flag Uses and Requests ..................................16 + 2.1. Initial, Pre-authenticated, and + Hardware-Authenticated Tickets ............................17 + 2.2. Invalid Tickets ...........................................17 + 2.3. Renewable Tickets .........................................17 + 2.4. Postdated Tickets .........................................18 + 2.5. Proxiable and Proxy Tickets ...............................19 + 2.6. Forwardable Tickets .......................................19 + 2.7. Transited Policy Checking .................................20 + 2.8. OK as Delegate ............................................21 + 2.9. Other KDC Options .........................................21 + 2.9.1. Renewable-OK .......................................21 + 2.9.2. ENC-TKT-IN-SKEY ....................................22 + 2.9.3. Passwordless Hardware Authentication ...............22 + 3. Message Exchanges ..............................................22 + 3.1. The Authentication Service Exchange .......................22 + 3.1.1. Generation of KRB_AS_REQ Message ...................24 + 3.1.2. Receipt of KRB_AS_REQ Message ......................24 + 3.1.3. Generation of KRB_AS_REP Message ...................24 + 3.1.4. Generation of KRB_ERROR Message ....................27 + 3.1.5. Receipt of KRB_AS_REP Message ......................27 + 3.1.6. Receipt of KRB_ERROR Message .......................28 + 3.2. The Client/Server Authentication Exchange .................29 + 3.2.1. The KRB_AP_REQ Message .............................29 + 3.2.2. Generation of a KRB_AP_REQ Message .................29 + 3.2.3. Receipt of KRB_AP_REQ Message ......................30 + 3.2.4. Generation of a KRB_AP_REP Message .................33 + 3.2.5. Receipt of KRB_AP_REP Message ......................33 + 3.2.6. Using the Encryption Key ...........................33 + 3.3. The Ticket-Granting Service (TGS) Exchange ................34 + 3.3.1. Generation of KRB_TGS_REQ Message ..................35 + 3.3.2. Receipt of KRB_TGS_REQ Message .....................37 + 3.3.3. Generation of KRB_TGS_REP Message ..................38 + 3.3.4. Receipt of KRB_TGS_REP Message .....................42 + + + + + +Neuman, et al. Standards Track [Page 2] + +RFC 4120 Kerberos V5 July 2005 + + + 3.4. The KRB_SAFE Exchange .....................................42 + 3.4.1. Generation of a KRB_SAFE Message ...................42 + 3.4.2. Receipt of KRB_SAFE Message ........................43 + 3.5. The KRB_PRIV Exchange .....................................44 + 3.5.1. Generation of a KRB_PRIV Message ...................44 + 3.5.2. Receipt of KRB_PRIV Message ........................44 + 3.6. The KRB_CRED Exchange .....................................45 + 3.6.1. Generation of a KRB_CRED Message ...................45 + 3.6.2. Receipt of KRB_CRED Message ........................46 + 3.7. User-to-User Authentication Exchanges .....................47 + 4. Encryption and Checksum Specifications .........................48 + 5. Message Specifications .........................................50 + 5.1. Specific Compatibility Notes on ASN.1 .....................51 + 5.1.1. ASN.1 Distinguished Encoding Rules .................51 + 5.1.2. Optional Integer Fields ............................52 + 5.1.3. Empty SEQUENCE OF Types ............................52 + 5.1.4. Unrecognized Tag Numbers ...........................52 + 5.1.5. Tag Numbers Greater Than 30 ........................53 + 5.2. Basic Kerberos Types ......................................53 + 5.2.1. KerberosString .....................................53 + 5.2.2. Realm and PrincipalName ............................55 + 5.2.3. KerberosTime .......................................55 + 5.2.4. Constrained Integer Types ..........................55 + 5.2.5. HostAddress and HostAddresses ......................56 + 5.2.6. AuthorizationData ..................................57 + 5.2.7. PA-DATA ............................................60 + 5.2.8. KerberosFlags ......................................64 + 5.2.9. Cryptosystem-Related Types .........................65 + 5.3. Tickets ...................................................66 + 5.4. Specifications for the AS and TGS Exchanges ...............73 + 5.4.1. KRB_KDC_REQ Definition .............................73 + 5.4.2. KRB_KDC_REP Definition .............................81 + 5.5. Client/Server (CS) Message Specifications .................84 + 5.5.1. KRB_AP_REQ Definition ..............................84 + 5.5.2. KRB_AP_REP Definition ..............................88 + 5.5.3. Error Message Reply ................................89 + 5.6. KRB_SAFE Message Specification ............................89 + 5.6.1. KRB_SAFE definition ................................89 + 5.7. KRB_PRIV Message Specification ............................91 + 5.7.1. KRB_PRIV Definition ................................91 + 5.8. KRB_CRED Message Specification ............................92 + 5.8.1. KRB_CRED Definition ................................92 + 5.9. Error Message Specification ...............................94 + 5.9.1. KRB_ERROR Definition ...............................94 + 5.10. Application Tag Numbers ..................................96 + + + + + + +Neuman, et al. Standards Track [Page 3] + +RFC 4120 Kerberos V5 July 2005 + + + 6. Naming Constraints .............................................97 + 6.1. Realm Names ...............................................97 + 6.2. Principal Names .......................................... 99 + 6.2.1. Name of Server Principals .........................100 + 7. Constants and Other Defined Values ............................101 + 7.1. Host Address Types .......................................101 + 7.2. KDC Messaging: IP Transports .............................102 + 7.2.1. UDP/IP transport ..................................102 + 7.2.2. TCP/IP Transport ..................................103 + 7.2.3. KDC Discovery on IP Networks ......................104 + 7.3. Name of the TGS ..........................................105 + 7.4. OID Arc for KerberosV5 ...................................106 + 7.5. Protocol Constants and Associated Values .................106 + 7.5.1. Key Usage Numbers .................................106 + 7.5.2. PreAuthentication Data Types ......................108 + 7.5.3. Address Types .....................................109 + 7.5.4. Authorization Data Types ..........................109 + 7.5.5. Transited Encoding Types ..........................109 + 7.5.6. Protocol Version Number ...........................109 + 7.5.7. Kerberos Message Types ............................110 + 7.5.8. Name Types ........................................110 + 7.5.9. Error Codes .......................................110 + 8. Interoperability Requirements .................................113 + 8.1. Specification 2 ..........................................113 + 8.2. Recommended KDC Values ...................................116 + 9. IANA Considerations ...........................................116 + 10. Security Considerations ......................................117 + 11. Acknowledgements .............................................121 + A. ASN.1 Module ..................................................123 + B. Changes since RFC 1510 ........................................131 + Normative References .............................................134 + Informative References ...........................................135 + + + + + + + + + + + + + + + + + + + +Neuman, et al. Standards Track [Page 4] + +RFC 4120 Kerberos V5 July 2005 + + +1. Introduction + + This document describes the concepts and model upon which the + Kerberos network authentication system is based. It also specifies + Version 5 of the Kerberos protocol. The motivations, goals, + assumptions, and rationale behind most design decisions are treated + cursorily; they are more fully described in a paper available in IEEE + communications [NT94] and earlier in the Kerberos portion of the + Athena Technical Plan [MNSS87]. + + This document is not intended to describe Kerberos to the end user, + system administrator, or application developer. Higher-level papers + describing Version 5 of the Kerberos system [NT94] and documenting + version 4 [SNS88] are available elsewhere. + + The Kerberos model is based in part on Needham and Schroeder's + trusted third-party authentication protocol [NS78] and on + modifications suggested by Denning and Sacco [DS81]. The original + design and implementation of Kerberos Versions 1 through 4 was the + work of two former Project Athena staff members, Steve Miller of + Digital Equipment Corporation and Clifford Neuman (now at the + Information Sciences Institute of the University of Southern + California), along with Jerome Saltzer, Technical Director of Project + Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other + members of Project Athena have also contributed to the work on + Kerberos. + + Version 5 of the Kerberos protocol (described in this document) has + evolved because of new requirements and desires for features not + available in Version 4. The design of Version 5 was led by Clifford + Neuman and John Kohl with much input from the community. The + development of the MIT reference implementation was led at MIT by + John Kohl and Theodore Ts'o, with help and contributed code from many + others. Since RFC 1510 was issued, many individuals have proposed + extensions and revisions to the protocol. This document reflects + some of these proposals. Where such changes involved significant + effort, the document cites the contribution of the proposer. + + Reference implementations of both Version 4 and Version 5 of Kerberos + are publicly available, and commercial implementations have been + developed and are widely used. Details on the differences between + Versions 4 and 5 can be found in [KNT94]. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + + + + +Neuman, et al. Standards Track [Page 5] + +RFC 4120 Kerberos V5 July 2005 + + +1.1. The Kerberos Protocol + + Kerberos provides a means of verifying the identities of principals, + (e.g., a workstation user or a network server) on an open + (unprotected) network. This is accomplished without relying on + assertions by the host operating system, without basing trust on host + addresses, without requiring physical security of all the hosts on + the network, and under the assumption that packets traveling along + the network can be read, modified, and inserted at will. Kerberos + performs authentication under these conditions as a trusted third- + party authentication service by using conventional (shared secret + key) cryptography. Extensions to Kerberos (outside the scope of this + document) can provide for the use of public key cryptography during + certain phases of the authentication protocol. Such extensions + support Kerberos authentication for users registered with public key + certification authorities and provide certain benefits of public key + cryptography in situations where they are needed. + + The basic Kerberos authentication process proceeds as follows: A + client sends a request to the authentication server (AS) for + "credentials" for a given server. The AS responds with these + credentials, encrypted in the client's key. The credentials consist + of a "ticket" for the server and a temporary encryption key (often + called a "session key"). The client transmits the ticket (which + contains the client's identity and a copy of the session key, all + encrypted in the server's key) to the server. The session key (now + shared by the client and server) is used to authenticate the client + and may optionally be used to authenticate the server. It may also + be used to encrypt further communication between the two parties or + to exchange a separate sub-session key to be used to encrypt further + communication. Note that many applications use Kerberos' functions + only upon the initiation of a stream-based network connection. + Unless an application performs encryption or integrity protection for + the data stream, the identity verification applies only to the + initiation of the connection, and it does not guarantee that + subsequent messages on the connection originate from the same + principal. + + Implementation of the basic protocol consists of one or more + authentication servers running on physically secure hosts. The + authentication servers maintain a database of principals (i.e., users + and servers) and their secret keys. Code libraries provide + encryption and implement the Kerberos protocol. In order to add + authentication to its transactions, a typical network application + adds calls to the Kerberos library directly or through the Generic + Security Services Application Programming Interface (GSS-API) + described in a separate document [RFC4121]. These calls result in + the transmission of the messages necessary to achieve authentication. + + + +Neuman, et al. Standards Track [Page 6] + +RFC 4120 Kerberos V5 July 2005 + + + The Kerberos protocol consists of several sub-protocols (or + exchanges). There are two basic methods by which a client can ask a + Kerberos server for credentials. In the first approach, the client + sends a cleartext request for a ticket for the desired server to the + AS. The reply is sent encrypted in the client's secret key. Usually + this request is for a ticket-granting ticket (TGT), which can later + be used with the ticket-granting server (TGS). In the second method, + the client sends a request to the TGS. The client uses the TGT to + authenticate itself to the TGS in the same manner as if it were + contacting any other application server that requires Kerberos + authentication. The reply is encrypted in the session key from the + TGT. Though the protocol specification describes the AS and the TGS + as separate servers, in practice they are implemented as different + protocol entry points within a single Kerberos server. + + Once obtained, credentials may be used to verify the identity of the + principals in a transaction, to ensure the integrity of messages + exchanged between them, or to preserve privacy of the messages. The + application is free to choose whatever protection may be necessary. + + To verify the identities of the principals in a transaction, the + client transmits the ticket to the application server. Because the + ticket is sent "in the clear" (parts of it are encrypted, but this + encryption doesn't thwart replay) and might be intercepted and reused + by an attacker, additional information is sent to prove that the + message originated with the principal to whom the ticket was issued. + This information (called the authenticator) is encrypted in the + session key and includes a timestamp. The timestamp proves that the + message was recently generated and is not a replay. Encrypting the + authenticator in the session key proves that it was generated by a + party possessing the session key. Since no one except the requesting + principal and the server know the session key (it is never sent over + the network in the clear), this guarantees the identity of the + client. + + The integrity of the messages exchanged between principals can also + be guaranteed by using the session key (passed in the ticket and + contained in the credentials). This approach provides detection of + both replay attacks and message stream modification attacks. It is + accomplished by generating and transmitting a collision-proof + checksum (elsewhere called a hash or digest function) of the client's + message, keyed with the session key. Privacy and integrity of the + messages exchanged between principals can be secured by encrypting + the data to be passed by using the session key contained in the + ticket or the sub-session key found in the authenticator. + + + + + + +Neuman, et al. Standards Track [Page 7] + +RFC 4120 Kerberos V5 July 2005 + + + The authentication exchanges mentioned above require read-only access + to the Kerberos database. Sometimes, however, the entries in the + database must be modified, such as when adding new principals or + changing a principal's key. This is done using a protocol between a + client and a third Kerberos server, the Kerberos Administration + Server (KADM). There is also a protocol for maintaining multiple + copies of the Kerberos database. Neither of these protocols are + described in this document. + +1.2. Cross-Realm Operation + + The Kerberos protocol is designed to operate across organizational + boundaries. A client in one organization can be authenticated to a + server in another. Each organization wishing to run a Kerberos + server establishes its own "realm". The name of the realm in which a + client is registered is part of the client's name and can be used by + the end-service to decide whether to honor a request. + + By establishing "inter-realm" keys, the administrators of two realms + can allow a client authenticated in the local realm to prove its + identity to servers in other realms. The exchange of inter-realm + keys (a separate key may be used for each direction) registers the + ticket-granting service of each realm as a principal in the other + realm. A client is then able to obtain a TGT for the remote realm's + ticket-granting service from its local realm. When that TGT is used, + the remote ticket-granting service uses the inter-realm key (which + usually differs from its own normal TGS key) to decrypt the TGT; thus + it is certain that the ticket was issued by the client's own TGS. + Tickets issued by the remote ticket-granting service will indicate to + the end-service that the client was authenticated from another realm. + + Without cross-realm operation, and with appropriate permission, the + client can arrange registration of a separately-named principal in a + remote realm and engage in normal exchanges with that realm's + services. However, for even small numbers of clients this becomes + cumbersome, and more automatic methods as described here are + necessary. + + A realm is said to communicate with another realm if the two realms + share an inter-realm key, or if the local realm shares an inter-realm + key with an intermediate realm that communicates with the remote + realm. An authentication path is the sequence of intermediate realms + that are transited in communicating from one realm to another. + + Realms may be organized hierarchically. Each realm shares a key with + its parent and a different key with each child. If an inter-realm + key is not directly shared by two realms, the hierarchical + organization allows an authentication path to be easily constructed. + + + +Neuman, et al. Standards Track [Page 8] + +RFC 4120 Kerberos V5 July 2005 + + + If a hierarchical organization is not used, it may be necessary to + consult a database in order to construct an authentication path + between realms. + + Although realms are typically hierarchical, intermediate realms may + be bypassed to achieve cross-realm authentication through alternate + authentication paths. (These might be established to make + communication between two realms more efficient.) It is important + for the end-service to know which realms were transited when deciding + how much faith to place in the authentication process. To facilitate + this decision, a field in each ticket contains the names of the + realms that were involved in authenticating the client. + + The application server is ultimately responsible for accepting or + rejecting authentication and SHOULD check the transited field. The + application server may choose to rely on the Key Distribution Center + (KDC) for the application server's realm to check the transited + field. The application server's KDC will set the + TRANSITED-POLICY-CHECKED flag in this case. The KDCs for + intermediate realms may also check the transited field as they issue + TGTs for other realms, but they are encouraged not to do so. A + client may request that the KDCs not check the transited field by + setting the DISABLE-TRANSITED-CHECK flag. KDCs SHOULD honor this + flag. + +1.3. Choosing a Principal with Which to Communicate + + The Kerberos protocol provides the means for verifying (subject to + the assumptions in Section 1.6) that the entity with which one + communicates is the same entity that was registered with the KDC + using the claimed identity (principal name). It is still necessary + to determine whether that identity corresponds to the entity with + which one intends to communicate. + + When appropriate data has been exchanged in advance, the application + may perform this determination syntactically based on the application + protocol specification, information provided by the user, and + configuration files. For example, the server principal name + (including realm) for a telnet server might be derived from the + user-specified host name (from the telnet command line), the "host/" + prefix specified in the application protocol specification, and a + mapping to a Kerberos realm derived syntactically from the domain + part of the specified hostname and information from the local + Kerberos realms database. + + One can also rely on trusted third parties to make this + determination, but only when the data obtained from the third party + is suitably integrity-protected while resident on the third-party + + + +Neuman, et al. Standards Track [Page 9] + +RFC 4120 Kerberos V5 July 2005 + + + server and when transmitted. Thus, for example, one should not rely + on an unprotected DNS record to map a host alias to the primary name + of a server, accepting the primary name as the party that one intends + to contact, since an attacker can modify the mapping and impersonate + the party. + + Implementations of Kerberos and protocols based on Kerberos MUST NOT + use insecure DNS queries to canonicalize the hostname components of + the service principal names (i.e., they MUST NOT use insecure DNS + queries to map one name to another to determine the host part of the + principal name with which one is to communicate). In an environment + without secure name service, application authors MAY append a + statically configured domain name to unqualified hostnames before + passing the name to the security mechanisms, but they should do no + more than that. Secure name service facilities, if available, might + be trusted for hostname canonicalization, but such canonicalization + by the client SHOULD NOT be required by KDC implementations. + + Implementation note: Many current implementations do some degree of + canonicalization of the provided service name, often using DNS even + though it creates security problems. However, there is no + consistency among implementations as to whether the service name is + case folded to lowercase or whether reverse resolution is used. To + maximize interoperability and security, applications SHOULD provide + security mechanisms with names that result from folding the user- + entered name to lowercase without performing any other modifications + or canonicalization. + +1.4. Authorization + + As an authentication service, Kerberos provides a means of verifying + the identity of principals on a network. Authentication is usually + useful primarily as a first step in the process of authorization, + determining whether a client may use a service, which objects the + client is allowed to access, and the type of access allowed for each. + Kerberos does not, by itself, provide authorization. Possession of a + client ticket for a service provides only for authentication of the + client to that service, and in the absence of a separate + authorization procedure, an application should not consider it to + authorize the use of that service. + + Separate authorization methods MAY be implemented as application- + specific access control functions and may utilize files on the + application server, on separately issued authorization credentials + such as those based on proxies [Neu93], or on other authorization + services. Separately authenticated authorization credentials MAY be + embedded in a ticket's authorization data when encapsulated by the + KDC-issued authorization data element. + + + +Neuman, et al. Standards Track [Page 10] + +RFC 4120 Kerberos V5 July 2005 + + + Applications should not accept the mere issuance of a service ticket + by the Kerberos server (even by a modified Kerberos server) as + granting authority to use the service, since such applications may + become vulnerable to the bypass of this authorization check in an + environment where other options for application authentication are + provided, or if they interoperate with other KDCs. + +1.5. Extending Kerberos without Breaking Interoperability + + As the deployed base of Kerberos implementations grows, extending + Kerberos becomes more important. Unfortunately, some extensions to + the existing Kerberos protocol create interoperability issues because + of uncertainty regarding the treatment of certain extensibility + options by some implementations. This section includes guidelines + that will enable future implementations to maintain interoperability. + + Kerberos provides a general mechanism for protocol extensibility. + Some protocol messages contain typed holes -- sub-messages that + contain an octet-string along with an integer that defines how to + interpret the octet-string. The integer types are registered + centrally, but they can be used both for vendor extensions and for + extensions standardized through the IETF. + + In this document, the word "extension" refers to extension by + defining a new type to insert into an existing typed hole in a + protocol message. It does not refer to extension by addition of new + fields to ASN.1 types, unless the text explicitly indicates + otherwise. + +1.5.1. Compatibility with RFC 1510 + + Note that existing Kerberos message formats cannot readily be + extended by adding fields to the ASN.1 types. Sending additional + fields often results in the entire message being discarded without an + error indication. Future versions of this specification will provide + guidelines to ensure that ASN.1 fields can be added without creating + an interoperability problem. + + In the meantime, all new or modified implementations of Kerberos that + receive an unknown message extension SHOULD preserve the encoding of + the extension but otherwise ignore its presence. Recipients MUST NOT + decline a request simply because an extension is present. + + There is one exception to this rule. If an unknown authorization + data element type is received by a server other than the ticket- + granting service either in an AP-REQ or in a ticket contained in an + AP-REQ, then authentication MUST fail. One of the primary uses of + authorization data is to restrict the use of the ticket. If the + + + +Neuman, et al. Standards Track [Page 11] + +RFC 4120 Kerberos V5 July 2005 + + + service cannot determine whether the restriction applies to that + service, then a security weakness may result if the ticket can be + used for that service. Authorization elements that are optional + SHOULD be enclosed in the AD-IF-RELEVANT element. + + The ticket-granting service MUST ignore but propagate to derivative + tickets any unknown authorization data types, unless those data types + are embedded in a MANDATORY-FOR-KDC element, in which case the + request will be rejected. This behavior is appropriate because + requiring that the ticket-granting service understand unknown + authorization data types would require that KDC software be upgraded + to understand new application-level restrictions before applications + used these restrictions, decreasing the utility of authorization data + as a mechanism for restricting the use of tickets. No security + problem is created because services to which the tickets are issued + will verify the authorization data. + + Implementation note: Many RFC 1510 implementations ignore unknown + authorization data elements. Depending on these implementations to + honor authorization data restrictions may create a security weakness. + +1.5.2. Sending Extensible Messages + + Care must be taken to ensure that old implementations can understand + messages sent to them, even if they do not understand an extension + that is used. Unless the sender knows that an extension is + supported, the extension cannot change the semantics of the core + message or previously defined extensions. + + For example, an extension including key information necessary to + decrypt the encrypted part of a KDC-REP could only be used in + situations where the recipient was known to support the extension. + Thus when designing such extensions it is important to provide a way + for the recipient to notify the sender of support for the extension. + For example in the case of an extension that changes the KDC-REP + reply key, the client could indicate support for the extension by + including a padata element in the AS-REQ sequence. The KDC should + only use the extension if this padata element is present in the + AS-REQ. Even if policy requires the use of the extension, it is + better to return an error indicating that the extension is required + than to use the extension when the recipient may not support it. + Debugging implementations that do not interoperate is easier when + errors are returned. + +1.6. Environmental Assumptions + + Kerberos imposes a few assumptions on the environment in which it can + properly function, including the following: + + + +Neuman, et al. Standards Track [Page 12] + +RFC 4120 Kerberos V5 July 2005 + + + * "Denial of service" attacks are not solved with Kerberos. There + are places in the protocols where an intruder can prevent an + application from participating in the proper authentication steps. + Detection and solution of such attacks (some of which can appear + to be not-uncommon "normal" failure modes for the system) are + usually best left to the human administrators and users. + + * Principals MUST keep their secret keys secret. If an intruder + somehow steals a principal's key, it will be able to masquerade as + that principal or to impersonate any server to the legitimate + principal. + + * "Password guessing" attacks are not solved by Kerberos. If a user + chooses a poor password, it is possible for an attacker to + successfully mount an offline dictionary attack by repeatedly + attempting to decrypt, with successive entries from a dictionary, + messages obtained which are encrypted under a key derived from the + user's password. + + * Each host on the network MUST have a clock which is "loosely + synchronized" to the time of the other hosts; this synchronization + is used to reduce the bookkeeping needs of application servers + when they do replay detection. The degree of "looseness" can be + configured on a per-server basis, but it is typically on the order + of 5 minutes. If the clocks are synchronized over the network, + the clock synchronization protocol MUST itself be secured from + network attackers. + + * Principal identifiers are not recycled on a short-term basis. A + typical mode of access control will use access control lists + (ACLs) to grant permissions to particular principals. If a stale + ACL entry remains for a deleted principal and the principal + identifier is reused, the new principal will inherit rights + specified in the stale ACL entry. By not re-using principal + identifiers, the danger of inadvertent access is removed. + +1.7. Glossary of Terms + + Below is a list of terms used throughout this document. + + Authentication + Verifying the claimed identity of a principal. + + Authentication header + A record containing a Ticket and an Authenticator to be presented + to a server as part of the authentication process. + + + + + +Neuman, et al. Standards Track [Page 13] + +RFC 4120 Kerberos V5 July 2005 + + + Authentication path + A sequence of intermediate realms transited in the authentication + process when communicating from one realm to another. + + Authenticator + A record containing information that can be shown to have been + recently generated using the session key known only by the client + and server. + + Authorization + The process of determining whether a client may use a service, + which objects the client is allowed to access, and the type of + access allowed for each. + + Capability + A token that grants the bearer permission to access an object or + service. In Kerberos, this might be a ticket whose use is + restricted by the contents of the authorization data field, but + which lists no network addresses, together with the session key + necessary to use the ticket. + + Ciphertext + The output of an encryption function. Encryption transforms + plaintext into ciphertext. + + Client + A process that makes use of a network service on behalf of a user. + Note that in some cases a Server may itself be a client of some + other server (e.g., a print server may be a client of a file + server). + + Credentials + A ticket plus the secret session key necessary to use that ticket + successfully in an authentication exchange. + + Encryption Type (etype) + When associated with encrypted data, an encryption type identifies + the algorithm used to encrypt the data and is used to select the + appropriate algorithm for decrypting the data. Encryption type + tags are communicated in other messages to enumerate algorithms + that are desired, supported, preferred, or allowed to be used for + encryption of data between parties. This preference is combined + with local information and policy to select an algorithm to be + used. + + KDC + Key Distribution Center. A network service that supplies tickets + and temporary session keys; or an instance of that service or the + + + +Neuman, et al. Standards Track [Page 14] + +RFC 4120 Kerberos V5 July 2005 + + + host on which it runs. The KDC services both initial ticket and + ticket-granting ticket requests. The initial ticket portion is + sometimes referred to as the Authentication Server (or service). + The ticket-granting ticket portion is sometimes referred to as the + ticket-granting server (or service). + + Kerberos + The name given to the Project Athena's authentication service, the + protocol used by that service, or the code used to implement the + authentication service. The name is adopted from the three-headed + dog that guards Hades. + + Key Version Number (kvno) + A tag associated with encrypted data identifies which key was used + for encryption when a long-lived key associated with a principal + changes over time. It is used during the transition to a new key + so that the party decrypting a message can tell whether the data + was encrypted with the old or the new key. + + Plaintext + The input to an encryption function or the output of a decryption + function. Decryption transforms ciphertext into plaintext. + + Principal + A named client or server entity that participates in a network + communication, with one name that is considered canonical. + + Principal identifier + The canonical name used to identify each different principal + uniquely. + + Seal + To encipher a record containing several fields in such a way that + the fields cannot be individually replaced without knowledge of + the encryption key or leaving evidence of tampering. + + Secret key + An encryption key shared by a principal and the KDC, distributed + outside the bounds of the system, with a long lifetime. In the + case of a human user's principal, the secret key MAY be derived + from a password. + + Server + A particular Principal that provides a resource to network + clients. The server is sometimes referred to as the Application + Server. + + + + + +Neuman, et al. Standards Track [Page 15] + +RFC 4120 Kerberos V5 July 2005 + + + Service + A resource provided to network clients; often provided by more + than one server (for example, remote file service). + + Session key + A temporary encryption key used between two principals, with a + lifetime limited to the duration of a single login "session". In + the Kerberos system, a session key is generated by the KDC. The + session key is distinct from the sub-session key, described next. + + Sub-session key + A temporary encryption key used between two principals, selected + and exchanged by the principals using the session key, and with a + lifetime limited to the duration of a single association. The + sub-session key is also referred to as the subkey. + + Ticket + A record that helps a client authenticate itself to a server; it + contains the client's identity, a session key, a timestamp, and + other information, all sealed using the server's secret key. It + only serves to authenticate a client when presented along with a + fresh Authenticator. + +2. Ticket Flag Uses and Requests + + Each Kerberos ticket contains a set of flags that are used to + indicate attributes of that ticket. Most flags may be requested by a + client when the ticket is obtained; some are automatically turned on + and off by a Kerberos server as required. The following sections + explain what the various flags mean and give examples of reasons to + use them. With the exception of the INVALID flag, clients MUST + ignore ticket flags that are not recognized. KDCs MUST ignore KDC + options that are not recognized. Some implementations of RFC 1510 + are known to reject unknown KDC options, so clients may need to + resend a request without new KDC options if the request was rejected + when sent with options added since RFC 1510. Because new KDCs will + ignore unknown options, clients MUST confirm that the ticket returned + by the KDC meets their needs. + + Note that it is not, in general, possible to determine whether an + option was not honored because it was not understood or because it + was rejected through either configuration or policy. When adding a + new option to the Kerberos protocol, designers should consider + whether the distinction is important for their option. If it is, a + mechanism for the KDC to return an indication that the option was + understood but rejected needs to be provided in the specification of + the option. Often in such cases, the mechanism needs to be broad + enough to permit an error or reason to be returned. + + + +Neuman, et al. Standards Track [Page 16] + +RFC 4120 Kerberos V5 July 2005 + + +2.1. Initial, Pre-authenticated, and Hardware-Authenticated Tickets + + The INITIAL flag indicates that a ticket was issued using the AS + protocol, rather than issued based on a TGT. Application servers + that want to require the demonstrated knowledge of a client's secret + key (e.g., a password-changing program) can insist that this flag be + set in any tickets they accept, and can thus be assured that the + client's key was recently presented to the authentication server. + + The PRE-AUTHENT and HW-AUTHENT flags provide additional information + about the initial authentication, regardless of whether the current + ticket was issued directly (in which case INITIAL will also be set) + or issued on the basis of a TGT (in which case the INITIAL flag is + clear, but the PRE-AUTHENT and HW-AUTHENT flags are carried forward + from the TGT). + +2.2. Invalid Tickets + + The INVALID flag indicates that a ticket is invalid. Application + servers MUST reject tickets that have this flag set. A postdated + ticket will be issued in this form. Invalid tickets MUST be + validated by the KDC before use, by being presented to the KDC in a + TGS request with the VALIDATE option specified. The KDC will only + validate tickets after their starttime has passed. The validation is + required so that postdated tickets that have been stolen before their + starttime can be rendered permanently invalid (through a hot-list + mechanism) (see Section 3.3.3.1). + +2.3. Renewable Tickets + + Applications may desire to hold tickets that can be valid for long + periods of time. However, this can expose their credentials to + potential theft for equally long periods, and those stolen + credentials would be valid until the expiration time of the + ticket(s). Simply using short-lived tickets and obtaining new ones + periodically would require the client to have long-term access to its + secret key, an even greater risk. Renewable tickets can be used to + mitigate the consequences of theft. Renewable tickets have two + "expiration times": the first is when the current instance of the + ticket expires, and the second is the latest permissible value for an + individual expiration time. An application client must periodically + (i.e., before it expires) present a renewable ticket to the KDC, with + the RENEW option set in the KDC request. The KDC will issue a new + ticket with a new session key and a later expiration time. All other + fields of the ticket are left unmodified by the renewal process. + When the latest permissible expiration time arrives, the ticket + expires permanently. At each renewal, the KDC MAY consult a hot-list + to determine whether the ticket had been reported stolen since its + + + +Neuman, et al. Standards Track [Page 17] + +RFC 4120 Kerberos V5 July 2005 + + + last renewal; it will refuse to renew stolen tickets, and thus the + usable lifetime of stolen tickets is reduced. + + The RENEWABLE flag in a ticket is normally only interpreted by the + ticket-granting service (discussed below in Section 3.3). It can + usually be ignored by application servers. However, some + particularly careful application servers MAY disallow renewable + tickets. + + If a renewable ticket is not renewed by its expiration time, the KDC + will not renew the ticket. The RENEWABLE flag is reset by default, + but a client MAY request it be set by setting the RENEWABLE option in + the KRB_AS_REQ message. If it is set, then the renew-till field in + the ticket contains the time after which the ticket may not be + renewed. + +2.4. Postdated Tickets + + Applications may occasionally need to obtain tickets for use much + later; e.g., a batch submission system would need tickets to be valid + at the time the batch job is serviced. However, it is dangerous to + hold valid tickets in a batch queue, since they will be on-line + longer and more prone to theft. Postdated tickets provide a way to + obtain these tickets from the KDC at job submission time, but to + leave them "dormant" until they are activated and validated by a + further request of the KDC. If a ticket theft were reported in the + interim, the KDC would refuse to validate the ticket, and the thief + would be foiled. + + The MAY-POSTDATE flag in a ticket is normally only interpreted by the + ticket-granting service. It can be ignored by application servers. + This flag MUST be set in a TGT in order to issue a postdated ticket + based on the presented ticket. It is reset by default; a client MAY + request it by setting the ALLOW-POSTDATE option in the KRB_AS_REQ + message. This flag does not allow a client to obtain a postdated + TGT; postdated TGTs can only be obtained by requesting the postdating + in the KRB_AS_REQ message. The life (endtime-starttime) of a + postdated ticket will be the remaining life of the TGT at the time of + the request, unless the RENEWABLE option is also set, in which case + it can be the full life (endtime-starttime) of the TGT. The KDC MAY + limit how far in the future a ticket may be postdated. + + The POSTDATED flag indicates that a ticket has been postdated. The + application server can check the authtime field in the ticket to see + when the original authentication occurred. Some services MAY choose + to reject postdated tickets, or they may only accept them within a + certain period after the original authentication. When the KDC + issues a POSTDATED ticket, it will also be marked as INVALID, so that + + + +Neuman, et al. Standards Track [Page 18] + +RFC 4120 Kerberos V5 July 2005 + + + the application client MUST present the ticket to the KDC to be + validated before use. + +2.5. Proxiable and Proxy Tickets + + At times it may be necessary for a principal to allow a service to + perform an operation on its behalf. The service must be able to take + on the identity of the client, but only for a particular purpose. A + principal can allow a service to do this by granting it a proxy. + + The process of granting a proxy by using the proxy and proxiable + flags is used to provide credentials for use with specific services. + Though conceptually also a proxy, users wishing to delegate their + identity in a form usable for all purposes MUST use the ticket + forwarding mechanism described in the next section to forward a TGT. + + The PROXIABLE flag in a ticket is normally only interpreted by the + ticket-granting service. It can be ignored by application servers. + When set, this flag tells the ticket-granting server that it is OK to + issue a new ticket (but not a TGT) with a different network address + based on this ticket. This flag is set if requested by the client on + initial authentication. By default, the client will request that it + be set when requesting a TGT, and that it be reset when requesting + any other ticket. + + This flag allows a client to pass a proxy to a server to perform a + remote request on its behalf (e.g., a print service client can give + the print server a proxy to access the client's files on a particular + file server in order to satisfy a print request). + + In order to complicate the use of stolen credentials, Kerberos + tickets are often valid only from those network addresses + specifically included in the ticket, but it is permissible as a + policy option to allow requests and to issue tickets with no network + addresses specified. When granting a proxy, the client MUST specify + the new network address from which the proxy is to be used or + indicate that the proxy is to be issued for use from any address. + + The PROXY flag is set in a ticket by the TGS when it issues a proxy + ticket. Application servers MAY check this flag; and at their option + they MAY require additional authentication from the agent presenting + the proxy in order to provide an audit trail. + +2.6. Forwardable Tickets + + Authentication forwarding is an instance of a proxy where the service + that is granted is complete use of the client's identity. An example + of where it might be used is when a user logs in to a remote system + + + +Neuman, et al. Standards Track [Page 19] + +RFC 4120 Kerberos V5 July 2005 + + + and wants authentication to work from that system as if the login + were local. + + The FORWARDABLE flag in a ticket is normally only interpreted by the + ticket-granting service. It can be ignored by application servers. + The FORWARDABLE flag has an interpretation similar to that of the + PROXIABLE flag, except TGTs may also be issued with different network + addresses. This flag is reset by default, but users MAY request that + it be set by setting the FORWARDABLE option in the AS request when + they request their initial TGT. + + This flag allows for authentication forwarding without requiring the + user to enter a password again. If the flag is not set, then + authentication forwarding is not permitted, but the same result can + still be achieved if the user engages in the AS exchange, specifies + the requested network addresses, and supplies a password. + + The FORWARDED flag is set by the TGS when a client presents a ticket + with the FORWARDABLE flag set and requests a forwarded ticket by + specifying the FORWARDED KDC option and supplying a set of addresses + for the new ticket. It is also set in all tickets issued based on + tickets with the FORWARDED flag set. Application servers may choose + to process FORWARDED tickets differently than non-FORWARDED tickets. + + If addressless tickets are forwarded from one system to another, + clients SHOULD still use this option to obtain a new TGT in order to + have different session keys on the different systems. + +2.7. Transited Policy Checking + + In Kerberos, the application server is ultimately responsible for + accepting or rejecting authentication, and it SHOULD check that only + suitably trusted KDCs are relied upon to authenticate a principal. + The transited field in the ticket identifies which realms (and thus + which KDCs) were involved in the authentication process, and an + application server would normally check this field. If any of these + are untrusted to authenticate the indicated client principal + (probably determined by a realm-based policy), the authentication + attempt MUST be rejected. The presence of trusted KDCs in this list + does not provide any guarantee; an untrusted KDC may have fabricated + the list. + + Although the end server ultimately decides whether authentication is + valid, the KDC for the end server's realm MAY apply a realm-specific + policy for validating the transited field and accepting credentials + for cross-realm authentication. When the KDC applies such checks and + accepts such cross-realm authentication, it will set the + TRANSITED-POLICY-CHECKED flag in the service tickets it issues based + + + +Neuman, et al. Standards Track [Page 20] + +RFC 4120 Kerberos V5 July 2005 + + + on the cross-realm TGT. A client MAY request that the KDCs not check + the transited field by setting the DISABLE-TRANSITED-CHECK flag. + KDCs are encouraged but not required to honor this flag. + + Application servers MUST either do the transited-realm checks + themselves or reject cross-realm tickets without + TRANSITED-POLICY-CHECKED set. + +2.8. OK as Delegate + + For some applications, a client may need to delegate authority to a + server to act on its behalf in contacting other services. This + requires that the client forward credentials to an intermediate + server. The ability for a client to obtain a service ticket to a + server conveys no information to the client about whether the server + should be trusted to accept delegated credentials. The + OK-AS-DELEGATE provides a way for a KDC to communicate local realm + policy to a client regarding whether an intermediate server is + trusted to accept such credentials. + + The copy of the ticket flags in the encrypted part of the KDC reply + may have the OK-AS-DELEGATE flag set to indicate to the client that + the server specified in the ticket has been determined by the policy + of the realm to be a suitable recipient of delegation. A client can + use the presence of this flag to help it decide whether to delegate + credentials (grant either a proxy or a forwarded TGT) to this server. + It is acceptable to ignore the value of this flag. When setting this + flag, an administrator should consider the security and placement of + the server on which the service will run, as well as whether the + service requires the use of delegated credentials. + +2.9. Other KDC Options + + There are three additional options that MAY be set in a client's + request of the KDC. + +2.9.1. Renewable-OK + + The RENEWABLE-OK option indicates that the client will accept a + renewable ticket if a ticket with the requested life cannot otherwise + be provided. If a ticket with the requested life cannot be provided, + then the KDC MAY issue a renewable ticket with a renew-till equal to + the requested endtime. The value of the renew-till field MAY still + be adjusted by site-determined limits or limits imposed by the + individual principal or server. + + + + + + +Neuman, et al. Standards Track [Page 21] + +RFC 4120 Kerberos V5 July 2005 + + +2.9.2. ENC-TKT-IN-SKEY + + In its basic form, the Kerberos protocol supports authentication in a + client-server setting and is not well suited to authentication in a + peer-to-peer environment because the long-term key of the user does + not remain on the workstation after initial login. Authentication of + such peers may be supported by Kerberos in its user-to-user variant. + The ENC-TKT-IN-SKEY option supports user-to-user authentication by + allowing the KDC to issue a service ticket encrypted using the + session key from another TGT issued to another user. The + ENC-TKT-IN-SKEY option is honored only by the ticket-granting + service. It indicates that the ticket to be issued for the end + server is to be encrypted in the session key from the additional + second TGT provided with the request. See Section 3.3.3 for specific + details. + +2.9.3. Passwordless Hardware Authentication + + The OPT-HARDWARE-AUTH option indicates that the client wishes to use + some form of hardware authentication instead of or in addition to the + client's password or other long-lived encryption key. + OPT-HARDWARE-AUTH is honored only by the authentication service. If + supported and allowed by policy, the KDC will return an error code of + KDC_ERR_PREAUTH_REQUIRED and include the required METHOD-DATA to + perform such authentication. + +3. Message Exchanges + + The following sections describe the interactions between network + clients and servers and the messages involved in those exchanges. + +3.1. The Authentication Service Exchange + + Summary + + Message direction Message type Section + 1. Client to Kerberos KRB_AS_REQ 5.4.1 + 2. Kerberos to client KRB_AS_REP or 5.4.2 + KRB_ERROR 5.9.1 + + The Authentication Service (AS) Exchange between the client and the + Kerberos Authentication Server is initiated by a client when it + wishes to obtain authentication credentials for a given server but + currently holds no credentials. In its basic form, the client's + secret key is used for encryption and decryption. This exchange is + typically used at the initiation of a login session to obtain + credentials for a Ticket-Granting Server, which will subsequently be + used to obtain credentials for other servers (see Section 3.3) + + + +Neuman, et al. Standards Track [Page 22] + +RFC 4120 Kerberos V5 July 2005 + + + without requiring further use of the client's secret key. This + exchange is also used to request credentials for services that must + not be mediated through the Ticket-Granting Service, but rather + require knowledge of a principal's secret key, such as the password- + changing service (the password-changing service denies requests + unless the requester can demonstrate knowledge of the user's old + password; requiring this knowledge prevents unauthorized password + changes by someone walking up to an unattended session). + + This exchange does not by itself provide any assurance of the + identity of the user. To authenticate a user logging on to a local + system, the credentials obtained in the AS exchange may first be used + in a TGS exchange to obtain credentials for a local server; those + credentials must then be verified by a local server through + successful completion of the Client/Server exchange. + + The AS exchange consists of two messages: KRB_AS_REQ from the client + to Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for + these messages are described in Sections 5.4.1, 5.4.2, and 5.9.1. + + In the request, the client sends (in cleartext) its own identity and + the identity of the server for which it is requesting credentials, + other information about the credentials it is requesting, and a + randomly generated nonce, which can be used to detect replays and to + associate replies with the matching requests. This nonce MUST be + generated randomly by the client and remembered for checking against + the nonce in the expected reply. The response, KRB_AS_REP, contains + a ticket for the client to present to the server, and a session key + that will be shared by the client and the server. The session key + and additional information are encrypted in the client's secret key. + The encrypted part of the KRB_AS_REP message also contains the nonce + that MUST be matched with the nonce from the KRB_AS_REQ message. + + Without pre-authentication, the authentication server does not know + whether the client is actually the principal named in the request. + It simply sends a reply without knowing or caring whether they are + the same. This is acceptable because nobody but the principal whose + identity was given in the request will be able to use the reply. Its + critical information is encrypted in that principal's key. However, + an attacker can send a KRB_AS_REQ message to get known plaintext in + order to attack the principal's key. Especially if the key is based + on a password, this may create a security exposure. So the initial + request supports an optional field that can be used to pass + additional information that might be needed for the initial exchange. + This field SHOULD be used for pre-authentication as described in + sections 3.1.1 and 5.2.7. + + + + + +Neuman, et al. Standards Track [Page 23] + +RFC 4120 Kerberos V5 July 2005 + + + Various errors can occur; these are indicated by an error response + (KRB_ERROR) instead of the KRB_AS_REP response. The error message is + not encrypted. The KRB_ERROR message contains information that can + be used to associate it with the message to which it replies. The + contents of the KRB_ERROR message are not integrity-protected. As + such, the client cannot detect replays, fabrications, or + modifications. A solution to this problem will be included in a + future version of the protocol. + +3.1.1. Generation of KRB_AS_REQ Message + + The client may specify a number of options in the initial request. + Among these options are whether pre-authentication is to be + performed; whether the requested ticket is to be renewable, + proxiable, or forwardable; whether it should be postdated or allow + postdating of derivative tickets; and whether a renewable ticket will + be accepted in lieu of a non-renewable ticket if the requested ticket + expiration date cannot be satisfied by a non-renewable ticket (due to + configuration constraints). + + The client prepares the KRB_AS_REQ message and sends it to the KDC. + +3.1.2. Receipt of KRB_AS_REQ Message + + If all goes well, processing the KRB_AS_REQ message will result in + the creation of a ticket for the client to present to the server. + The format for the ticket is described in Section 5.3. + + Because Kerberos can run over unreliable transports such as UDP, the + KDC MUST be prepared to retransmit responses in case they are lost. + If a KDC receives a request identical to one it has recently + processed successfully, the KDC MUST respond with a KRB_AS_REP + message rather than a replay error. In order to reduce ciphertext + given to a potential attacker, KDCs MAY send the same response + generated when the request was first handled. KDCs MUST obey this + replay behavior even if the actual transport in use is reliable. + +3.1.3. Generation of KRB_AS_REP Message + + The authentication server looks up the client and server principals + named in the KRB_AS_REQ in its database, extracting their respective + keys. If the requested client principal named in the request is + unknown because it doesn't exist in the KDC's principal database, + then an error message with a KDC_ERR_C_PRINCIPAL_UNKNOWN is returned. + + If required to do so, the server pre-authenticates the request, and + if the pre-authentication check fails, an error message with the code + KDC_ERR_PREAUTH_FAILED is returned. If pre-authentication is + + + +Neuman, et al. Standards Track [Page 24] + +RFC 4120 Kerberos V5 July 2005 + + + required, but was not present in the request, an error message with + the code KDC_ERR_PREAUTH_REQUIRED is returned, and a METHOD-DATA + object will be stored in the e-data field of the KRB-ERROR message to + specify which pre-authentication mechanisms are acceptable. Usually + this will include PA-ETYPE-INFO and/or PA-ETYPE-INFO2 elements as + described below. If the server cannot accommodate any encryption + type requested by the client, an error message with code + KDC_ERR_ETYPE_NOSUPP is returned. Otherwise, the KDC generates a + 'random' session key, meaning that, among other things, it should be + impossible to guess the next session key based on knowledge of past + session keys. Although this can be achieved in a pseudo-random + number generator if it is based on cryptographic principles, it is + more desirable to use a truly random number generator, such as one + based on measurements of random physical phenomena. See [RFC4086] + for an in-depth discussion of randomness. + + In response to an AS request, if there are multiple encryption keys + registered for a client in the Kerberos database, then the etype + field from the AS request is used by the KDC to select the encryption + method to be used to protect the encrypted part of the KRB_AS_REP + message that is sent to the client. If there is more than one + supported strong encryption type in the etype list, the KDC SHOULD + use the first valid strong etype for which an encryption key is + available. + + When the user's key is generated from a password or pass phrase, the + string-to-key function for the particular encryption key type is + used, as specified in [RFC3961]. The salt value and additional + parameters for the string-to-key function have default values + (specified by Section 4 and by the encryption mechanism + specification, respectively) that may be overridden by + pre-authentication data (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO, + PA-ETYPE-INFO2, etc). Since the KDC is presumed to store a copy of + the resulting key only, these values should not be changed for + password-based keys except when changing the principal's key. + + When the AS server is to include pre-authentication data in a + KRB-ERROR or in an AS-REP, it MUST use PA-ETYPE-INFO2, not PA-ETYPE- + INFO, if the etype field of the client's AS-REQ lists at least one + "newer" encryption type. Otherwise (when the etype field of the + client's AS-REQ does not list any "newer" encryption types), it MUST + send both PA-ETYPE-INFO2 and PA-ETYPE-INFO (both with an entry for + each enctype). A "newer" enctype is any enctype first officially + specified concurrently with or subsequent to the issue of this RFC. + The enctypes DES, 3DES, or RC4 and any defined in [RFC1510] are not + "newer" enctypes. + + + + + +Neuman, et al. Standards Track [Page 25] + +RFC 4120 Kerberos V5 July 2005 + + + It is not possible to generate a user's key reliably given a pass + phrase without contacting the KDC, since it will not be known whether + alternate salt or parameter values are required. + + The KDC will attempt to assign the type of the random session key + from the list of methods in the etype field. The KDC will select the + appropriate type using the list of methods provided and information + from the Kerberos database indicating acceptable encryption methods + for the application server. The KDC will not issue tickets with a + weak session key encryption type. + + If the requested starttime is absent, indicates a time in the past, + or is within the window of acceptable clock skew for the KDC and the + POSTDATE option has not been specified, then the starttime of the + ticket is set to the authentication server's current time. If it + indicates a time in the future beyond the acceptable clock skew, but + the POSTDATED option has not been specified, then the error + KDC_ERR_CANNOT_POSTDATE is returned. Otherwise the requested + starttime is checked against the policy of the local realm (the + administrator might decide to prohibit certain types or ranges of + postdated tickets), and if the ticket's starttime is acceptable, it + is set as requested, and the INVALID flag is set in the new ticket. + The postdated ticket MUST be validated before use by presenting it to + the KDC after the starttime has been reached. + + The expiration time of the ticket will be set to the earlier of the + requested endtime and a time determined by local policy, possibly by + using realm- or principal-specific factors. For example, the + expiration time MAY be set to the earliest of the following: + + * The expiration time (endtime) requested in the KRB_AS_REQ + message. + + * The ticket's starttime plus the maximum allowable lifetime + associated with the client principal from the authentication + server's database. + + * The ticket's starttime plus the maximum allowable lifetime + associated with the server principal. + + * The ticket's starttime plus the maximum lifetime set by the + policy of the local realm. + + If the requested expiration time minus the starttime (as determined + above) is less than a site-determined minimum lifetime, an error + message with code KDC_ERR_NEVER_VALID is returned. If the requested + expiration time for the ticket exceeds what was determined as above, + and if the 'RENEWABLE-OK' option was requested, then the 'RENEWABLE' + + + +Neuman, et al. Standards Track [Page 26] + +RFC 4120 Kerberos V5 July 2005 + + + flag is set in the new ticket, and the renew-till value is set as if + the 'RENEWABLE' option were requested (the field and option names are + described fully in Section 5.4.1). + + If the RENEWABLE option has been requested or if the RENEWABLE-OK + option has been set and a renewable ticket is to be issued, then the + renew-till field MAY be set to the earliest of: + + * Its requested value. + + * The starttime of the ticket plus the minimum of the two maximum + renewable lifetimes associated with the principals' database + entries. + + * The starttime of the ticket plus the maximum renewable lifetime + set by the policy of the local realm. + + The flags field of the new ticket will have the following options set + if they have been requested and if the policy of the local realm + allows: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. + If the new ticket is postdated (the starttime is in the future), its + INVALID flag will also be set. + + If all of the above succeed, the server will encrypt the ciphertext + part of the ticket using the encryption key extracted from the server + principal's record in the Kerberos database using the encryption type + associated with the server principal's key. (This choice is NOT + affected by the etype field in the request.) It then formats a + KRB_AS_REP message (see Section 5.4.2), copying the addresses in the + request into the caddr of the response, placing any required pre- + authentication data into the padata of the response, and encrypts the + ciphertext part in the client's key using an acceptable encryption + method requested in the etype field of the request, or in some key + specified by pre-authentication mechanisms being used. + +3.1.4. Generation of KRB_ERROR Message + + Several errors can occur, and the Authentication Server responds by + returning an error message, KRB_ERROR, to the client, with the + error-code and e-text fields set to appropriate values. The error + message contents and details are described in Section 5.9.1. + +3.1.5. Receipt of KRB_AS_REP Message + + If the reply message type is KRB_AS_REP, then the client verifies + that the cname and crealm fields in the cleartext portion of the + reply match what it requested. If any padata fields are present, + they may be used to derive the proper secret key to decrypt the + + + +Neuman, et al. Standards Track [Page 27] + +RFC 4120 Kerberos V5 July 2005 + + + message. The client decrypts the encrypted part of the response + using its secret key and verifies that the nonce in the encrypted + part matches the nonce it supplied in its request (to detect + replays). It also verifies that the sname and srealm in the response + match those in the request (or are otherwise expected values), and + that the host address field is also correct. It then stores the + ticket, session key, start and expiration times, and other + information for later use. The last-req field (and the deprecated + key-expiration field) from the encrypted part of the response MAY be + checked to notify the user of impending key expiration. This enables + the client program to suggest remedial action, such as a password + change. + + Upon validation of the KRB_AS_REP message (by checking the returned + nonce against that sent in the KRB_AS_REQ message), the client knows + that the current time on the KDC is that read from the authtime field + of the encrypted part of the reply. The client can optionally use + this value for clock synchronization in subsequent messages by + recording with the ticket the difference (offset) between the + authtime value and the local clock. This offset can then be used by + the same user to adjust the time read from the system clock when + generating messages [DGT96]. + + This technique MUST be used when adjusting for clock skew instead of + directly changing the system clock, because the KDC reply is only + authenticated to the user whose secret key was used, but not to the + system or workstation. If the clock were adjusted, an attacker + colluding with a user logging into a workstation could agree on a + password, resulting in a KDC reply that would be correctly validated + even though it did not originate from a KDC trusted by the + workstation. + + Proper decryption of the KRB_AS_REP message is not sufficient for the + host to verify the identity of the user; the user and an attacker + could cooperate to generate a KRB_AS_REP format message that decrypts + properly but is not from the proper KDC. If the host wishes to + verify the identity of the user, it MUST require the user to present + application credentials that can be verified using a securely-stored + secret key for the host. If those credentials can be verified, then + the identity of the user can be assured. + +3.1.6. Receipt of KRB_ERROR Message + + If the reply message type is KRB_ERROR, then the client interprets it + as an error and performs whatever application-specific tasks are + necessary for recovery. + + + + + +Neuman, et al. Standards Track [Page 28] + +RFC 4120 Kerberos V5 July 2005 + + +3.2. The Client/Server Authentication Exchange + + Summary + + Message direction Message type Section + Client to Application server KRB_AP_REQ 5.5.1 + [optional] Application server to client KRB_AP_REP or 5.5.2 + KRB_ERROR 5.9.1 + + The client/server authentication (CS) exchange is used by network + applications to authenticate the client to the server and vice versa. + The client MUST have already acquired credentials for the server + using the AS or TGS exchange. + +3.2.1. The KRB_AP_REQ Message + + The KRB_AP_REQ contains authentication information that SHOULD be + part of the first message in an authenticated transaction. It + contains a ticket, an authenticator, and some additional bookkeeping + information (see Section 5.5.1 for the exact format). The ticket by + itself is insufficient to authenticate a client, since tickets are + passed across the network in cleartext (tickets contain both an + encrypted and unencrypted portion, so cleartext here refers to the + entire unit, which can be copied from one message and replayed in + another without any cryptographic skill). The authenticator is used + to prevent invalid replay of tickets by proving to the server that + the client knows the session key of the ticket and thus is entitled + to use the ticket. The KRB_AP_REQ message is referred to elsewhere + as the 'authentication header'. + +3.2.2. Generation of a KRB_AP_REQ Message + + When a client wishes to initiate authentication to a server, it + obtains (either through a credentials cache, the AS exchange, or the + TGS exchange) a ticket and session key for the desired service. The + client MAY re-use any tickets it holds until they expire. To use a + ticket, the client constructs a new Authenticator from the system + time and its name, and optionally from an application-specific + checksum, an initial sequence number to be used in KRB_SAFE or + KRB_PRIV messages, and/or a session subkey to be used in negotiations + for a session key unique to this particular session. Authenticators + MUST NOT be re-used and SHOULD be rejected if replayed to a server. + Note that this can make applications based on unreliable transports + difficult to code correctly. If the transport might deliver + duplicated messages, either a new authenticator MUST be generated for + each retry, or the application server MUST match requests and replies + and replay the first reply in response to a detected duplicate. + + + + +Neuman, et al. Standards Track [Page 29] + +RFC 4120 Kerberos V5 July 2005 + + + If a sequence number is to be included, it SHOULD be randomly chosen + so that even after many messages have been exchanged it is not likely + to collide with other sequence numbers in use. + + The client MAY indicate a requirement of mutual authentication or the + use of a session-key based ticket (for user-to-user authentication, + see section 3.7) by setting the appropriate flag(s) in the ap-options + field of the message. + + The Authenticator is encrypted in the session key and combined with + the ticket to form the KRB_AP_REQ message, which is then sent to the + end server along with any additional application-specific + information. + +3.2.3. Receipt of KRB_AP_REQ Message + + Authentication is based on the server's current time of day (clocks + MUST be loosely synchronized), the authenticator, and the ticket. + Several errors are possible. If an error occurs, the server is + expected to reply to the client with a KRB_ERROR message. This + message MAY be encapsulated in the application protocol if its raw + form is not acceptable to the protocol. The format of error messages + is described in Section 5.9.1. + + The algorithm for verifying authentication information is as follows. + If the message type is not KRB_AP_REQ, the server returns the + KRB_AP_ERR_MSG_TYPE error. If the key version indicated by the + Ticket in the KRB_AP_REQ is not one the server can use (e.g., it + indicates an old key, and the server no longer possesses a copy of + the old key), the KRB_AP_ERR_BADKEYVER error is returned. If the + USE-SESSION-KEY flag is set in the ap-options field, it indicates to + the server that user-to-user authentication is in use, and that the + ticket is encrypted in the session key from the server's TGT rather + than in the server's secret key. See Section 3.7 for a more complete + description of the effect of user-to-user authentication on all + messages in the Kerberos protocol. + + Because it is possible for the server to be registered in multiple + realms, with different keys in each, the srealm field in the + unencrypted portion of the ticket in the KRB_AP_REQ is used to + specify which secret key the server should use to decrypt that + ticket. The KRB_AP_ERR_NOKEY error code is returned if the server + doesn't have the proper key to decipher the ticket. + + The ticket is decrypted using the version of the server's key + specified by the ticket. If the decryption routines detect a + modification of the ticket (each encryption system MUST provide + safeguards to detect modified ciphertext), the + + + +Neuman, et al. Standards Track [Page 30] + +RFC 4120 Kerberos V5 July 2005 + + + KRB_AP_ERR_BAD_INTEGRITY error is returned (chances are good that + different keys were used to encrypt and decrypt). + + The authenticator is decrypted using the session key extracted from + the decrypted ticket. If decryption shows that is has been modified, + the KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm + of the client from the ticket are compared against the same fields in + the authenticator. If they don't match, the KRB_AP_ERR_BADMATCH + error is returned; normally this is caused by a client error or an + attempted attack. The addresses in the ticket (if any) are then + searched for an address matching the operating-system reported + address of the client. If no match is found or the server insists on + ticket addresses but none are present in the ticket, the + KRB_AP_ERR_BADADDR error is returned. If the local (server) time and + the client time in the authenticator differ by more than the + allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW error is + returned. + + Unless the application server provides its own suitable means to + protect against replay (for example, a challenge-response sequence + initiated by the server after authentication, or use of a server- + generated encryption subkey), the server MUST utilize a replay cache + to remember any authenticator presented within the allowable clock + skew. Careful analysis of the application protocol and + implementation is recommended before eliminating this cache. The + replay cache will store at least the server name, along with the + client name, time, and microsecond fields from the recently-seen + authenticators, and if a matching tuple is found, the + KRB_AP_ERR_REPEAT error is returned. Note that the rejection here is + restricted to authenticators from the same principal to the same + server. Other client principals communicating with the same server + principal should not have their authenticators rejected if the time + and microsecond fields happen to match some other client's + authenticator. + + If a server loses track of authenticators presented within the + allowable clock skew, it MUST reject all requests until the clock + skew interval has passed, providing assurance that any lost or + replayed authenticators will fall outside the allowable clock skew + and can no longer be successfully replayed. If this were not done, + an attacker could subvert the authentication by recording the ticket + and authenticator sent over the network to a server and replaying + them following an event that caused the server to lose track of + recently seen authenticators. + + Implementation note: If a client generates multiple requests to the + KDC with the same timestamp, including the microsecond field, all but + the first of the requests received will be rejected as replays. This + + + +Neuman, et al. Standards Track [Page 31] + +RFC 4120 Kerberos V5 July 2005 + + + might happen, for example, if the resolution of the client's clock is + too coarse. Client implementations SHOULD ensure that the timestamps + are not reused, possibly by incrementing the microseconds field in + the time stamp when the clock returns the same time for multiple + requests. + + If multiple servers (for example, different services on one machine, + or a single service implemented on multiple machines) share a service + principal (a practice that we do not recommend in general, but that + we acknowledge will be used in some cases), either they MUST share + this replay cache, or the application protocol MUST be designed so as + to eliminate the need for it. Note that this applies to all of the + services. If any of the application protocols does not have replay + protection built in, an authenticator used with such a service could + later be replayed to a different service with the same service + principal but no replay protection, if the former doesn't record the + authenticator information in the common replay cache. + + If a sequence number is provided in the authenticator, the server + saves it for later use in processing KRB_SAFE and/or KRB_PRIV + messages. If a subkey is present, the server either saves it for + later use or uses it to help generate its own choice for a subkey to + be returned in a KRB_AP_REP message. + + The server computes the age of the ticket: local (server) time minus + the starttime inside the Ticket. If the starttime is later than the + current time by more than the allowable clock skew, or if the INVALID + flag is set in the ticket, the KRB_AP_ERR_TKT_NYV error is returned. + Otherwise, if the current time is later than end time by more than + the allowable clock skew, the KRB_AP_ERR_TKT_EXPIRED error is + returned. + + If all these checks succeed without an error, the server is assured + that the client possesses the credentials of the principal named in + the ticket, and thus, that the client has been authenticated to the + server. + + Passing these checks provides only authentication of the named + principal; it does not imply authorization to use the named service. + Applications MUST make a separate authorization decision based upon + the authenticated name of the user, the requested operation, local + access control information such as that contained in a .k5login or + .k5users file, and possibly a separate distributed authorization + service. + + + + + + + +Neuman, et al. Standards Track [Page 32] + +RFC 4120 Kerberos V5 July 2005 + + +3.2.4. Generation of a KRB_AP_REP Message + + Typically, a client's request will include both the authentication + information and its initial request in the same message, and the + server need not explicitly reply to the KRB_AP_REQ. However, if + mutual authentication (authenticating not only the client to the + server, but also the server to the client) is being performed, the + KRB_AP_REQ message will have MUTUAL-REQUIRED set in its ap-options + field, and a KRB_AP_REP message is required in response. As with the + error message, this message MAY be encapsulated in the application + protocol if its "raw" form is not acceptable to the application's + protocol. The timestamp and microsecond field used in the reply MUST + be the client's timestamp and microsecond field (as provided in the + authenticator). If a sequence number is to be included, it SHOULD be + randomly chosen as described above for the authenticator. A subkey + MAY be included if the server desires to negotiate a different + subkey. The KRB_AP_REP message is encrypted in the session key + extracted from the ticket. + + Note that in the Kerberos Version 4 protocol, the timestamp in the + reply was the client's timestamp plus one. This is not necessary in + Version 5 because Version 5 messages are formatted in such a way that + it is not possible to create the reply by judicious message surgery + (even in encrypted form) without knowledge of the appropriate + encryption keys. + +3.2.5. Receipt of KRB_AP_REP Message + + If a KRB_AP_REP message is returned, the client uses the session key + from the credentials obtained for the server to decrypt the message + and verifies that the timestamp and microsecond fields match those in + the Authenticator it sent to the server. If they match, then the + client is assured that the server is genuine. The sequence number + and subkey (if present) are retained for later use. (Note that for + encrypting the KRB_AP_REP message, the sub-session key is not used, + even if it is present in the Authentication.) + +3.2.6. Using the Encryption Key + + After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and + server share an encryption key that can be used by the application. + In some cases, the use of this session key will be implicit in the + protocol; in others the method of use must be chosen from several + alternatives. The application MAY choose the actual encryption key + to be used for KRB_PRIV, KRB_SAFE, or other application-specific uses + based on the session key from the ticket and subkeys in the + KRB_AP_REP message and the authenticator. Implementations of the + protocol MAY provide routines to choose subkeys based on session keys + + + +Neuman, et al. Standards Track [Page 33] + +RFC 4120 Kerberos V5 July 2005 + + + and random numbers and to generate a negotiated key to be returned in + the KRB_AP_REP message. + + To mitigate the effect of failures in random number generation on the + client, it is strongly encouraged that any key derived by an + application for subsequent use include the full key entropy derived + from the KDC-generated session key carried in the ticket. We leave + the protocol negotiations of how to use the key (e.g., for selecting + an encryption or checksum type) to the application programmer. The + Kerberos protocol does not constrain the implementation options, but + an example of how this might be done follows. + + One way that an application may choose to negotiate a key to be used + for subsequent integrity and privacy protection is for the client to + propose a key in the subkey field of the authenticator. The server + can then choose a key using the key proposed by the client as input, + returning the new subkey in the subkey field of the application + reply. This key could then be used for subsequent communication. + + With both the one-way and mutual authentication exchanges, the peers + should take care not to send sensitive information to each other + without proper assurances. In particular, applications that require + privacy or integrity SHOULD use the KRB_AP_REP response from the + server to the client to assure both client and server of their peer's + identity. If an application protocol requires privacy of its + messages, it can use the KRB_PRIV message (section 3.5). The + KRB_SAFE message (Section 3.4) can be used to ensure integrity. + +3.3. The Ticket-Granting Service (TGS) Exchange + + Summary + + Message direction Message type Section + 1. Client to Kerberos KRB_TGS_REQ 5.4.1 + 2. Kerberos to client KRB_TGS_REP or 5.4.2 + KRB_ERROR 5.9.1 + + The TGS exchange between a client and the Kerberos TGS is initiated + by a client when it seeks to obtain authentication credentials for a + given server (which might be registered in a remote realm), when it + seeks to renew or validate an existing ticket, or when it seeks to + obtain a proxy ticket. In the first case, the client must already + have acquired a ticket for the Ticket-Granting Service using the AS + exchange (the TGT is usually obtained when a client initially + authenticates to the system, such as when a user logs in). The + message format for the TGS exchange is almost identical to that for + the AS exchange. The primary difference is that encryption and + decryption in the TGS exchange does not take place under the client's + + + +Neuman, et al. Standards Track [Page 34] + +RFC 4120 Kerberos V5 July 2005 + + + key. Instead, the session key from the TGT or renewable ticket, or + sub-session key from an Authenticator is used. As is the case for + all application servers, expired tickets are not accepted by the TGS, + so once a renewable or TGT expires, the client must use a separate + exchange to obtain valid tickets. + + The TGS exchange consists of two messages: a request (KRB_TGS_REQ) + from the client to the Kerberos Ticket-Granting Server, and a reply + (KRB_TGS_REP or KRB_ERROR). The KRB_TGS_REQ message includes + information authenticating the client plus a request for credentials. + The authentication information consists of the authentication header + (KRB_AP_REQ), which includes the client's previously obtained + ticket-granting, renewable, or invalid ticket. In the TGT and proxy + cases, the request MAY include one or more of the following: a list + of network addresses, a collection of typed authorization data to be + sealed in the ticket for authorization use by the application server, + or additional tickets (the use of which are described later). The + TGS reply (KRB_TGS_REP) contains the requested credentials, encrypted + in the session key from the TGT or renewable ticket, or, if present, + in the sub-session key from the Authenticator (part of the + authentication header). The KRB_ERROR message contains an error code + and text explaining what went wrong. The KRB_ERROR message is not + encrypted. The KRB_TGS_REP message contains information that can be + used to detect replays, and to associate it with the message to which + it replies. The KRB_ERROR message also contains information that can + be used to associate it with the message to which it replies. The + same comments about integrity protection of KRB_ERROR messages + mentioned in Section 3.1 apply to the TGS exchange. + +3.3.1. Generation of KRB_TGS_REQ Message + + Before sending a request to the ticket-granting service, the client + MUST determine in which realm the application server is believed to + be registered. This can be accomplished in several ways. It might + be known beforehand (since the realm is part of the principal + identifier), it might be stored in a nameserver, or it might be + obtained from a configuration file. If the realm to be used is + obtained from a nameserver, there is a danger of being spoofed if the + nameservice providing the realm name is not authenticated. This + might result in the use of a realm that has been compromised, which + would result in an attacker's ability to compromise the + authentication of the application server to the client. + + If the client knows the service principal name and realm and it does + not already possess a TGT for the appropriate realm, then one must be + obtained. This is first attempted by requesting a TGT for the + destination realm from a Kerberos server for which the client + possesses a TGT (by using the KRB_TGS_REQ message recursively). The + + + +Neuman, et al. Standards Track [Page 35] + +RFC 4120 Kerberos V5 July 2005 + + + Kerberos server MAY return a TGT for the desired realm, in which case + one can proceed. Alternatively, the Kerberos server MAY return a TGT + for a realm that is 'closer' to the desired realm (further along the + standard hierarchical path between the client's realm and the + requested realm server's realm). Note that in this case + misconfiguration of the Kerberos servers may cause loops in the + resulting authentication path, which the client should be careful to + detect and avoid. + + If the Kerberos server returns a TGT for a realm 'closer' than the + desired realm, the client MAY use local policy configuration to + verify that the authentication path used is an acceptable one. + Alternatively, a client MAY choose its own authentication path, + rather than rely on the Kerberos server to select one. In either + case, any policy or configuration information used to choose or + validate authentication paths, whether by the Kerberos server or by + the client, MUST be obtained from a trusted source. + + When a client obtains a TGT that is 'closer' to the destination + realm, the client MAY cache this ticket and reuse it in future + KRB-TGS exchanges with services in the 'closer' realm. However, if + the client were to obtain a TGT for the 'closer' realm by starting at + the initial KDC rather than as part of obtaining another ticket, then + a shorter path to the 'closer' realm might be used. This shorter + path may be desirable because fewer intermediate KDCs would know the + session key of the ticket involved. For this reason, clients SHOULD + evaluate whether they trust the realms transited in obtaining the + 'closer' ticket when making a decision to use the ticket in future. + + Once the client obtains a TGT for the appropriate realm, it + determines which Kerberos servers serve that realm and contacts one + of them. The list might be obtained through a configuration file or + network service, or it MAY be generated from the name of the realm. + As long as the secret keys exchanged by realms are kept secret, only + denial of service results from using a false Kerberos server. + + As in the AS exchange, the client MAY specify a number of options in + the KRB_TGS_REQ message. One of these options is the ENC-TKT-IN-SKEY + option used for user-to-user authentication. An overview of user- + to-user authentication can be found in Section 3.7. When generating + the KRB_TGS_REQ message, this option indicates that the client is + including a TGT obtained from the application server in the + additional tickets field of the request and that the KDC SHOULD + encrypt the ticket for the application server using the session key + from this additional ticket, instead of a server key from the + principal database. + + + + + +Neuman, et al. Standards Track [Page 36] + +RFC 4120 Kerberos V5 July 2005 + + + The client prepares the KRB_TGS_REQ message, providing an + authentication header as an element of the padata field, and + including the same fields as used in the KRB_AS_REQ message along + with several optional fields: the enc-authorizatfion-data field for + application server use and additional tickets required by some + options. + + In preparing the authentication header, the client can select a sub- + session key under which the response from the Kerberos server will be + encrypted. If the client selects a sub-session key, care must be + taken to ensure the randomness of the selected sub-session key. + + If the sub-session key is not specified, the session key from the TGT + will be used. If the enc-authorization-data is present, it MUST be + encrypted in the sub-session key, if present, from the authenticator + portion of the authentication header, or, if not present, by using + the session key from the TGT. + + Once prepared, the message is sent to a Kerberos server for the + destination realm. + +3.3.2. Receipt of KRB_TGS_REQ Message + + The KRB_TGS_REQ message is processed in a manner similar to the + KRB_AS_REQ message, but there are many additional checks to be + performed. First, the Kerberos server MUST determine which server + the accompanying ticket is for, and it MUST select the appropriate + key to decrypt it. For a normal KRB_TGS_REQ message, it will be for + the ticket-granting service, and the TGS's key will be used. If the + TGT was issued by another realm, then the appropriate inter-realm key + MUST be used. If (a) the accompanying ticket is not a TGT for the + current realm, but is for an application server in the current realm, + (b) the RENEW, VALIDATE, or PROXY options are specified in the + request, and (c) the server for which a ticket is requested is the + server named in the accompanying ticket, then the KDC will decrypt + the ticket in the authentication header using the key of the server + for which it was issued. If no ticket can be found in the padata + field, the KDC_ERR_PADATA_TYPE_NOSUPP error is returned. + + Once the accompanying ticket has been decrypted, the user-supplied + checksum in the Authenticator MUST be verified against the contents + of the request, and the message MUST be rejected if the checksums do + not match (with an error code of KRB_AP_ERR_MODIFIED) or if the + checksum is not collision-proof (with an error code of + KRB_AP_ERR_INAPP_CKSUM). If the checksum type is not supported, the + KDC_ERR_SUMTYPE_NOSUPP error is returned. If the authorization-data + are present, they are decrypted using the sub-session key from the + Authenticator. + + + +Neuman, et al. Standards Track [Page 37] + +RFC 4120 Kerberos V5 July 2005 + + + If any of the decryptions indicate failed integrity checks, the + KRB_AP_ERR_BAD_INTEGRITY error is returned. + + As discussed in Section 3.1.2, the KDC MUST send a valid KRB_TGS_REP + message if it receives a KRB_TGS_REQ message identical to one it has + recently processed. However, if the authenticator is a replay, but + the rest of the request is not identical, then the KDC SHOULD return + KRB_AP_ERR_REPEAT. + +3.3.3. Generation of KRB_TGS_REP Message + + The KRB_TGS_REP message shares its format with the KRB_AS_REP + (KRB_KDC_REP), but with its type field set to KRB_TGS_REP. The + detailed specification is in Section 5.4.2. + + The response will include a ticket for the requested server or for a + ticket granting server of an intermediate KDC to be contacted to + obtain the requested ticket. The Kerberos database is queried to + retrieve the record for the appropriate server (including the key + with which the ticket will be encrypted). If the request is for a + TGT for a remote realm, and if no key is shared with the requested + realm, then the Kerberos server will select the realm 'closest' to + the requested realm with which it does share a key and use that realm + instead. This is the only case where the response for the KDC will + be for a different server than that requested by the client. + + By default, the address field, the client's name and realm, the list + of transited realms, the time of initial authentication, the + expiration time, and the authorization data of the newly-issued + ticket will be copied from the TGT or renewable ticket. If the + transited field needs to be updated, but the transited type is not + supported, the KDC_ERR_TRTYPE_NOSUPP error is returned. + + If the request specifies an endtime, then the endtime of the new + ticket is set to the minimum of (a) that request, (b) the endtime + from the TGT, and (c) the starttime of the TGT plus the minimum of + the maximum life for the application server and the maximum life for + the local realm (the maximum life for the requesting principal was + already applied when the TGT was issued). If the new ticket is to be + a renewal, then the endtime above is replaced by the minimum of (a) + the value of the renew_till field of the ticket and (b) the starttime + for the new ticket plus the life (endtime-starttime) of the old + ticket. + + If the FORWARDED option has been requested, then the resulting ticket + will contain the addresses specified by the client. This option will + only be honored if the FORWARDABLE flag is set in the TGT. The PROXY + option is similar; the resulting ticket will contain the addresses + + + +Neuman, et al. Standards Track [Page 38] + +RFC 4120 Kerberos V5 July 2005 + + + specified by the client. It will be honored only if the PROXIABLE + flag in the TGT is set. The PROXY option will not be honored on + requests for additional TGTs. + + If the requested starttime is absent, indicates a time in the past, + or is within the window of acceptable clock skew for the KDC and the + POSTDATE option has not been specified, then the starttime of the + ticket is set to the authentication server's current time. If it + indicates a time in the future beyond the acceptable clock skew, but + the POSTDATED option has not been specified or the MAY-POSTDATE flag + is not set in the TGT, then the error KDC_ERR_CANNOT_POSTDATE is + returned. Otherwise, if the TGT has the MAY-POSTDATE flag set, then + the resulting ticket will be postdated, and the requested starttime + is checked against the policy of the local realm. If acceptable, the + ticket's starttime is set as requested, and the INVALID flag is set. + The postdated ticket MUST be validated before use by presenting it to + the KDC after the starttime has been reached. However, in no case + may the starttime, endtime, or renew-till time of a newly-issued + postdated ticket extend beyond the renew-till time of the TGT. + + If the ENC-TKT-IN-SKEY option has been specified and an additional + ticket has been included in the request, it indicates that the client + is using user-to-user authentication to prove its identity to a + server that does not have access to a persistent key. Section 3.7 + describes the effect of this option on the entire Kerberos protocol. + When generating the KRB_TGS_REP message, this option in the + KRB_TGS_REQ message tells the KDC to decrypt the additional ticket + using the key for the server to which the additional ticket was + issued and to verify that it is a TGT. If the name of the requested + server is missing from the request, the name of the client in the + additional ticket will be used. Otherwise, the name of the requested + server will be compared to the name of the client in the additional + ticket. If it is different, the request will be rejected. If the + request succeeds, the session key from the additional ticket will be + used to encrypt the new ticket that is issued instead of using the + key of the server for which the new ticket will be used. + + If (a) the name of the server in the ticket that is presented to the + KDC as part of the authentication header is not that of the TGS + itself, (b) the server is registered in the realm of the KDC, and (c) + the RENEW option is requested, then the KDC will verify that the + RENEWABLE flag is set in the ticket, that the INVALID flag is not set + in the ticket, and that the renew_till time is still in the future. + If the VALIDATE option is requested, the KDC will check that the + starttime has passed and that the INVALID flag is set. If the PROXY + option is requested, then the KDC will check that the PROXIABLE flag + + + + + +Neuman, et al. Standards Track [Page 39] + +RFC 4120 Kerberos V5 July 2005 + + + is set in the ticket. If the tests succeed and the ticket passes the + hotlist check described in the next section, the KDC will issue the + appropriate new ticket. + + The ciphertext part of the response in the KRB_TGS_REP message is + encrypted in the sub-session key from the Authenticator, if present, + or in the session key from the TGT. It is not encrypted using the + client's secret key. Furthermore, the client's key's expiration date + and the key version number fields are left out since these values are + stored along with the client's database record, and that record is + not needed to satisfy a request based on a TGT. + +3.3.3.1. Checking for Revoked Tickets + + Whenever a request is made to the ticket-granting server, the + presented ticket(s) is (are) checked against a hot-list of tickets + that have been canceled. This hot-list might be implemented by + storing a range of issue timestamps for 'suspect tickets'; if a + presented ticket had an authtime in that range, it would be rejected. + In this way, a stolen TGT or renewable ticket cannot be used to gain + additional tickets (renewals or otherwise) once the theft has been + reported to the KDC for the realm in which the server resides. Any + normal ticket obtained before it was reported stolen will still be + valid (because tickets require no interaction with the KDC), but only + until its normal expiration time. If TGTs have been issued for + cross-realm authentication, use of the cross-realm TGT will not be + affected unless the hot-list is propagated to the KDCs for the realms + for which such cross-realm tickets were issued. + +3.3.3.2. Encoding the Transited Field + + If the identity of the server in the TGT that is presented to the KDC + as part of the authentication header is that of the ticket-granting + service, but the TGT was issued from another realm, the KDC will look + up the inter-realm key shared with that realm and use that key to + decrypt the ticket. If the ticket is valid, then the KDC will honor + the request, subject to the constraints outlined above in the section + describing the AS exchange. The realm part of the client's identity + will be taken from the TGT. The name of the realm that issued the + TGT, if it is not the realm of the client principal, will be added to + the transited field of the ticket to be issued. This is accomplished + by reading the transited field from the TGT (which is treated as an + unordered set of realm names), adding the new realm to the set, and + then constructing and writing out its encoded (shorthand) form (this + may involve a rearrangement of the existing encoding). + + Note that the ticket-granting service does not add the name of its + own realm. Instead, its responsibility is to add the name of the + + + +Neuman, et al. Standards Track [Page 40] + +RFC 4120 Kerberos V5 July 2005 + + + previous realm. This prevents a malicious Kerberos server from + intentionally leaving out its own name (it could, however, omit other + realms' names). + + The names of neither the local realm nor the principal's realm are to + be included in the transited field. They appear elsewhere in the + ticket and both are known to have taken part in authenticating the + principal. Because the endpoints are not included, both local and + single-hop inter-realm authentication result in a transited field + that is empty. + + Because this field has the name of each transited realm added to it, + it might potentially be very long. To decrease the length of this + field, its contents are encoded. The initially supported encoding is + optimized for the normal case of inter-realm communication: a + hierarchical arrangement of realms using either domain or X.500 style + realm names. This encoding (called DOMAIN-X500-COMPRESS) is now + described. + + Realm names in the transited field are separated by a ",". The ",", + "\", trailing "."s, and leading spaces (" ") are special characters, + and if they are part of a realm name, they MUST be quoted in the + transited field by preceding them with a "\". + + A realm name ending with a "." is interpreted as being prepended to + the previous realm. For example, we can encode traversal of EDU, + MIT.EDU, ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as: + + "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.". + + Note that if either ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were + endpoints, they would not be included in this field, and we would + have: + + "EDU,MIT.,WASHINGTON.EDU" + + A realm name beginning with a "/" is interpreted as being appended to + the previous realm. For the purpose of appending, the realm + preceding the first listed realm is considered the null realm (""). + If a realm name beginning with a "/" is to stand by itself, then it + SHOULD be preceded by a space (" "). For example, we can encode + traversal of /COM/HP/APOLLO, /COM/HP, /COM, and /COM/DEC as: + + "/COM,/HP,/APOLLO, /COM/DEC". + + As in the example above, if /COM/HP/APOLLO and /COM/DEC were + endpoints, they would not be included in this field, and we would + have: + + + +Neuman, et al. Standards Track [Page 41] + +RFC 4120 Kerberos V5 July 2005 + + + "/COM,/HP" + + A null subfield preceding or following a "," indicates that all + realms between the previous realm and the next realm have been + traversed. For the purpose of interpreting null subfields, the + client's realm is considered to precede those in the transited field, + and the server's realm is considered to follow them. Thus, "," means + that all realms along the path between the client and the server have + been traversed. ",EDU, /COM," means that all realms from the + client's realm up to EDU (in a domain style hierarchy) have been + traversed, and that everything from /COM down to the server's realm + in an X.500 style has also been traversed. This could occur if the + EDU realm in one hierarchy shares an inter-realm key directly with + the /COM realm in another hierarchy. + +3.3.4. Receipt of KRB_TGS_REP Message + + When the KRB_TGS_REP is received by the client, it is processed in + the same manner as the KRB_AS_REP processing described above. The + primary difference is that the ciphertext part of the response must + be decrypted using the sub-session key from the Authenticator, if it + was specified in the request, or the session key from the TGT, rather + than the client's secret key. The server name returned in the reply + is the true principal name of the service. + +3.4. The KRB_SAFE Exchange + + The KRB_SAFE message MAY be used by clients requiring the ability to + detect modifications of messages they exchange. It achieves this by + including a keyed collision-proof checksum of the user data and some + control information. The checksum is keyed with an encryption key + (usually the last key negotiated via subkeys, or the session key if + no negotiation has occurred). + +3.4.1. Generation of a KRB_SAFE Message + + When an application wishes to send a KRB_SAFE message, it collects + its data and the appropriate control information and computes a + checksum over them. The checksum algorithm should be the keyed + checksum mandated to be implemented along with the crypto system used + for the sub-session or session key. The checksum is generated using + the sub-session key, if present, or the session key. Some + implementations use a different checksum algorithm for the KRB_SAFE + messages, but doing so in an interoperable manner is not always + possible. + + The control information for the KRB_SAFE message includes both a + timestamp and a sequence number. The designer of an application + + + +Neuman, et al. Standards Track [Page 42] + +RFC 4120 Kerberos V5 July 2005 + + + using the KRB_SAFE message MUST choose at least one of the two + mechanisms. This choice SHOULD be based on the needs of the + application protocol. + + Sequence numbers are useful when all messages sent will be received + by one's peer. Connection state is presently required to maintain + the session key, so maintaining the next sequence number should not + present an additional problem. + + If the application protocol is expected to tolerate lost messages + without their being resent, the use of the timestamp is the + appropriate replay detection mechanism. Using timestamps is also the + appropriate mechanism for multi-cast protocols in which all of one's + peers share a common sub-session key, but some messages will be sent + to a subset of one's peers. + + After computing the checksum, the client then transmits the + information and checksum to the recipient in the message format + specified in Section 5.6.1. + +3.4.2. Receipt of KRB_SAFE Message + + When an application receives a KRB_SAFE message, it verifies it as + follows. If any error occurs, an error code is reported for use by + the application. + + The message is first checked by verifying that the protocol version + and type fields match the current version and KRB_SAFE, respectively. + A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE + error. The application verifies that the checksum used is a + collision-proof keyed checksum that uses keys compatible with the + sub-session or session key as appropriate (or with the application + key derived from the session or sub-session keys). If it is not, a + KRB_AP_ERR_INAPP_CKSUM error is generated. The sender's address MUST + be included in the control information; the recipient verifies that + the operating system's report of the sender's address matches the + sender's address in the message, and (if a recipient address is + specified or the recipient requires an address) that one of the + recipient's addresses appears as the recipient's address in the + message. To work with network address translation, senders MAY use + the directional address type specified in Section 8.1 for the sender + address and not include recipient addresses. A failed match for + either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp + and usec and/or the sequence number fields are checked. If timestamp + and usec are expected and not present, or if they are present but not + current, the KRB_AP_ERR_SKEW error is generated. Timestamps are not + required to be strictly ordered; they are only required to be in the + skew window. If the server name, along with the client name, time, + + + +Neuman, et al. Standards Track [Page 43] + +RFC 4120 Kerberos V5 July 2005 + + + and microsecond fields from the Authenticator match any recently-seen + (sent or received) such tuples, the KRB_AP_ERR_REPEAT error is + generated. If an incorrect sequence number is included, or if a + sequence number is expected but not present, the KRB_AP_ERR_BADORDER + error is generated. If neither a time-stamp and usec nor a sequence + number is present, a KRB_AP_ERR_MODIFIED error is generated. + Finally, the checksum is computed over the data and control + information, and if it doesn't match the received checksum, a + KRB_AP_ERR_MODIFIED error is generated. + + If all the checks succeed, the application is assured that the + message was generated by its peer and was not modified in transit. + + Implementations SHOULD accept any checksum algorithm they implement + that has both adequate security and keys compatible with the sub- + session or session key. Unkeyed or non-collision-proof checksums are + not suitable for this use. + +3.5. The KRB_PRIV Exchange + + The KRB_PRIV message MAY be used by clients requiring confidentiality + and the ability to detect modifications of exchanged messages. It + achieves this by encrypting the messages and adding control + information. + +3.5.1. Generation of a KRB_PRIV Message + + When an application wishes to send a KRB_PRIV message, it collects + its data and the appropriate control information (specified in + Section 5.7.1) and encrypts them under an encryption key (usually the + last key negotiated via subkeys, or the session key if no negotiation + has occurred). As part of the control information, the client MUST + choose to use either a timestamp or a sequence number (or both); see + the discussion in Section 3.4.1 for guidelines on which to use. + After the user data and control information are encrypted, the client + transmits the ciphertext and some 'envelope' information to the + recipient. + +3.5.2. Receipt of KRB_PRIV Message + + When an application receives a KRB_PRIV message, it verifies it as + follows. If any error occurs, an error code is reported for use by + the application. + + The message is first checked by verifying that the protocol version + and type fields match the current version and KRB_PRIV, respectively. + A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE + error. The application then decrypts the ciphertext and processes + + + +Neuman, et al. Standards Track [Page 44] + +RFC 4120 Kerberos V5 July 2005 + + + the resultant plaintext. If decryption shows that the data has been + modified, a KRB_AP_ERR_BAD_INTEGRITY error is generated. + + The sender's address MUST be included in the control information; the + recipient verifies that the operating system's report of the sender's + address matches the sender's address in the message. If a recipient + address is specified or the recipient requires an address, then one + of the recipient's addresses MUST also appear as the recipient's + address in the message. Where a sender's or receiver's address might + not otherwise match the address in a message because of network + address translation, an application MAY be written to use addresses + of the directional address type in place of the actual network + address. + + A failed match for either case generates a KRB_AP_ERR_BADADDR error. + To work with network address translation, implementations MAY use the + directional address type defined in Section 7.1 for the sender + address and include no recipient address. + + Next the timestamp and usec and/or the sequence number fields are + checked. If timestamp and usec are expected and not present, or if + they are present but not current, the KRB_AP_ERR_SKEW error is + generated. If the server name, along with the client name, time, and + microsecond fields from the Authenticator match any such recently- + seen tuples, the KRB_AP_ERR_REPEAT error is generated. If an + incorrect sequence number is included, or if a sequence number is + expected but not present, the KRB_AP_ERR_BADORDER error is generated. + If neither a time-stamp and usec nor a sequence number is present, a + KRB_AP_ERR_MODIFIED error is generated. + + If all the checks succeed, the application can assume the message was + generated by its peer and was securely transmitted (without intruders + seeing the unencrypted contents). + +3.6. The KRB_CRED Exchange + + The KRB_CRED message MAY be used by clients requiring the ability to + send Kerberos credentials from one host to another. It achieves this + by sending the tickets together with encrypted data containing the + session keys and other information associated with the tickets. + +3.6.1. Generation of a KRB_CRED Message + + When an application wishes to send a KRB_CRED message, it first + (using the KRB_TGS exchange) obtains credentials to be sent to the + remote host. It then constructs a KRB_CRED message using the ticket + or tickets so obtained, placing the session key needed to use each + + + + +Neuman, et al. Standards Track [Page 45] + +RFC 4120 Kerberos V5 July 2005 + + + ticket in the key field of the corresponding KrbCredInfo sequence of + the encrypted part of the KRB_CRED message. + + Other information associated with each ticket and obtained during the + KRB_TGS exchange is also placed in the corresponding KrbCredInfo + sequence in the encrypted part of the KRB_CRED message. The current + time and, if they are specifically required by the application, the + nonce, s-address, and r-address fields are placed in the encrypted + part of the KRB_CRED message, which is then encrypted under an + encryption key previously exchanged in the KRB_AP exchange (usually + the last key negotiated via subkeys, or the session key if no + negotiation has occurred). + + Implementation note: When constructing a KRB_CRED message for + inclusion in a GSSAPI initial context token, the MIT implementation + of Kerberos will not encrypt the KRB_CRED message if the session key + is a DES or triple DES key. For interoperability with MIT, the + Microsoft implementation will not encrypt the KRB_CRED in a GSSAPI + token if it is using a DES session key. Starting at version 1.2.5, + MIT Kerberos can receive and decode either encrypted or unencrypted + KRB_CRED tokens in the GSSAPI exchange. The Heimdal implementation + of Kerberos can also accept either encrypted or unencrypted KRB_CRED + messages. Since the KRB_CRED message in a GSSAPI token is encrypted + in the authenticator, the MIT behavior does not present a security + problem, although it is a violation of the Kerberos specification. + +3.6.2. Receipt of KRB_CRED Message + + When an application receives a KRB_CRED message, it verifies it. If + any error occurs, an error code is reported for use by the + application. The message is verified by checking that the protocol + version and type fields match the current version and KRB_CRED, + respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or + KRB_AP_ERR_MSG_TYPE error. The application then decrypts the + ciphertext and processes the resultant plaintext. If decryption + shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY + error is generated. + + If present or required, the recipient MAY verify that the operating + system's report of the sender's address matches the sender's address + in the message, and that one of the recipient's addresses appears as + the recipient's address in the message. The address check does not + provide any added security, since the address, if present, has + already been checked in the KRB_AP_REQ message and there is not any + benefit to be gained by an attacker in reflecting a KRB_CRED message + back to its originator. Thus, the recipient MAY ignore the address + even if it is present in order to work better in Network Address + Translation (NAT) environments. A failed match for either case + + + +Neuman, et al. Standards Track [Page 46] + +RFC 4120 Kerberos V5 July 2005 + + + generates a KRB_AP_ERR_BADADDR error. Recipients MAY skip the + address check, as the KRB_CRED message cannot generally be reflected + back to the originator. The timestamp and usec fields (and the nonce + field, if required) are checked next. If the timestamp and usec are + not present, or if they are present but not current, the + KRB_AP_ERR_SKEW error is generated. + + If all the checks succeed, the application stores each of the new + tickets in its credentials cache together with the session key and + other information in the corresponding KrbCredInfo sequence from the + encrypted part of the KRB_CRED message. + +3.7. User-to-User Authentication Exchanges + + User-to-User authentication provides a method to perform + authentication when the verifier does not have a access to long-term + service key. This might be the case when running a server (for + example, a window server) as a user on a workstation. In such cases, + the server may have access to the TGT obtained when the user logged + in to the workstation, but because the server is running as an + unprivileged user, it might not have access to system keys. Similar + situations may arise when running peer-to-peer applications. + + Summary + + Message direction Message type Sections + 0. Message from application server Not specified + 1. Client to Kerberos KRB_TGS_REQ 3.3 & 5.4.1 + 2. Kerberos to client KRB_TGS_REP or 3.3 & 5.4.2 + KRB_ERROR 5.9.1 + 3. Client to application server KRB_AP_REQ 3.2 & 5.5.1 + + To address this problem, the Kerberos protocol allows the client to + request that the ticket issued by the KDC be encrypted using a + session key from a TGT issued to the party that will verify the + authentication. This TGT must be obtained from the verifier by means + of an exchange external to the Kerberos protocol, usually as part of + the application protocol. This message is shown in the summary above + as message 0. Note that because the TGT is encrypted in the KDC's + secret key, it cannot be used for authentication without possession + of the corresponding secret key. Furthermore, because the verifier + does not reveal the corresponding secret key, providing a copy of the + verifier's TGT does not allow impersonation of the verifier. + + Message 0 in the table above represents an application-specific + negotiation between the client and server, at the end of which both + have determined that they will use user-to-user authentication, and + the client has obtained the server's TGT. + + + +Neuman, et al. Standards Track [Page 47] + +RFC 4120 Kerberos V5 July 2005 + + + Next, the client includes the server's TGT as an additional ticket in + its KRB_TGS_REQ request to the KDC (message 1 in the table above) and + specifies the ENC-TKT-IN-SKEY option in its request. + + If validated according to the instructions in Section 3.3.3, the + application ticket returned to the client (message 2 in the table + above) will be encrypted using the session key from the additional + ticket and the client will note this when it uses or stores the + application ticket. + + When contacting the server using a ticket obtained for user-to-user + authentication (message 3 in the table above), the client MUST + specify the USE-SESSION-KEY flag in the ap-options field. This tells + the application server to use the session key associated with its TGT + to decrypt the server ticket provided in the application request. + +4. Encryption and Checksum Specifications + + The Kerberos protocols described in this document are designed to + encrypt messages of arbitrary sizes, using stream or block encryption + ciphers. Encryption is used to prove the identities of the network + entities participating in message exchanges. The Key Distribution + Center for each realm is trusted by all principals registered in that + realm to store a secret key in confidence. Proof of knowledge of + this secret key is used to verify the authenticity of a principal. + + The KDC uses the principal's secret key (in the AS exchange) or a + shared session key (in the TGS exchange) to encrypt responses to + ticket requests; the ability to obtain the secret key or session key + implies the knowledge of the appropriate keys and the identity of the + KDC. The ability of a principal to decrypt the KDC response and to + present a Ticket and a properly formed Authenticator (generated with + the session key from the KDC response) to a service verifies the + identity of the principal; likewise the ability of the service to + extract the session key from the Ticket and to prove its knowledge + thereof in a response verifies the identity of the service. + + [RFC3961] defines a framework for defining encryption and checksum + mechanisms for use with Kerberos. It also defines several such + mechanisms, and more may be added in future updates to that document. + + The string-to-key operation provided by [RFC3961] is used to produce + a long-term key for a principal (generally for a user). The default + salt string, if none is provided via pre-authentication data, is the + concatenation of the principal's realm and name components, in order, + with no separators. Unless it is indicated otherwise, the default + string-to-key opaque parameter set as defined in [RFC3961] is used. + + + + +Neuman, et al. Standards Track [Page 48] + +RFC 4120 Kerberos V5 July 2005 + + + Encrypted data, keys, and checksums are transmitted using the + EncryptedData, EncryptionKey, and Checksum data objects defined in + Section 5.2.9. The encryption, decryption, and checksum operations + described in this document use the corresponding encryption, + decryption, and get_mic operations described in [RFC3961], with + implicit "specific key" generation using the "key usage" values + specified in the description of each EncryptedData or Checksum object + to vary the key for each operation. Note that in some cases, the + value to be used is dependent on the method of choosing the key or + the context of the message. + + Key usages are unsigned 32-bit integers; zero is not permitted. The + key usage values for encrypting or checksumming Kerberos messages are + indicated in Section 5 along with the message definitions. The key + usage values 512-1023 are reserved for uses internal to a Kerberos + implementation. (For example, seeding a pseudo-random number + generator with a value produced by encrypting something with a + session key and a key usage value not used for any other purpose.) + Key usage values between 1024 and 2047 (inclusive) are reserved for + application use; applications SHOULD use even values for encryption + and odd values for checksums within this range. Key usage values are + also summarized in a table in Section 7.5.1. + + There might exist other documents that define protocols in terms of + the RFC 1510 encryption types or checksum types. These documents + would not know about key usages. In order that these specifications + continue to be meaningful until they are updated, if no key usage + values are specified, then key usages 1024 and 1025 must be used to + derive keys for encryption and checksums, respectively. (This does + not apply to protocols that do their own encryption independent of + this framework, by directly using the key resulting from the Kerberos + authentication exchange.) New protocols defined in terms of the + Kerberos encryption and checksum types SHOULD use their own key usage + values. + + Unless it is indicated otherwise, no cipher state chaining is done + from one encryption operation to another. + + Implementation note: Although it is not recommended, some application + protocols will continue to use the key data directly, even if only in + currently existing protocol specifications. An implementation + intended to support general Kerberos applications may therefore need + to make key data available, as well as the attributes and operations + described in [RFC3961]. One of the more common reasons for directly + performing encryption is direct control over negotiation and + selection of a "sufficiently strong" encryption algorithm (in the + context of a given application). Although Kerberos does not directly + provide a facility for negotiating encryption types between the + + + +Neuman, et al. Standards Track [Page 49] + +RFC 4120 Kerberos V5 July 2005 + + + application client and server, there are approaches for using + Kerberos to facilitate this negotiation. For example, a client may + request only "sufficiently strong" session key types from the KDC and + expect that any type returned by the KDC will be understood and + supported by the application server. + +5. Message Specifications + + The ASN.1 collected here should be identical to the contents of + Appendix A. In the case of a conflict, the contents of Appendix A + shall take precedence. + + The Kerberos protocol is defined here in terms of Abstract Syntax + Notation One (ASN.1) [X680], which provides a syntax for specifying + both the abstract layout of protocol messages as well as their + encodings. Implementors not utilizing an existing ASN.1 compiler or + support library are cautioned to understand the actual ASN.1 + specification thoroughly in order to ensure correct implementation + behavior. There is more complexity in the notation than is + immediately obvious, and some tutorials and guides to ASN.1 are + misleading or erroneous. + + Note that in several places, changes to abstract types from RFC 1510 + have been made. This is in part to address widespread assumptions + that various implementors have made, in some cases resulting in + unintentional violations of the ASN.1 standard. These are clearly + flagged where they occur. The differences between the abstract types + in RFC 1510 and abstract types in this document can cause + incompatible encodings to be emitted when certain encoding rules, + e.g., the Packed Encoding Rules (PER), are used. This theoretical + incompatibility should not be relevant for Kerberos, since Kerberos + explicitly specifies the use of the Distinguished Encoding Rules + (DER). It might be an issue for protocols seeking to use Kerberos + types with other encoding rules. (This practice is not recommended.) + With very few exceptions (most notably the usages of BIT STRING), the + encodings resulting from using the DER remain identical between the + types defined in RFC 1510 and the types defined in this document. + + The type definitions in this section assume an ASN.1 module + definition of the following form: + + + + + + + + + + + +Neuman, et al. Standards Track [Page 50] + +RFC 4120 Kerberos V5 July 2005 + + + KerberosV5Spec2 { + iso(1) identified-organization(3) dod(6) internet(1) + security(5) kerberosV5(2) modules(4) krb5spec2(2) + } DEFINITIONS EXPLICIT TAGS ::= BEGIN + + -- rest of definitions here + + END + + This specifies that the tagging context for the module will be + explicit and non-automatic. + + Note that in some other publications (such as [RFC1510] and + [RFC1964]), the "dod" portion of the object identifier is erroneously + specified as having the value "5". In the case of RFC 1964, use of + the "correct" OID value would result in a change in the wire + protocol; therefore, it remains unchanged for now. + + Note that elsewhere in this document, nomenclature for various + message types is inconsistent, but it largely follows C language + conventions, including use of underscore (_) characters and all-caps + spelling of names intended to be numeric constants. Also, in some + places, identifiers (especially those referring to constants) are + written in all-caps in order to distinguish them from surrounding + explanatory text. + + The ASN.1 notation does not permit underscores in identifiers, so in + actual ASN.1 definitions, underscores are replaced with hyphens (-). + Additionally, structure member names and defined values in ASN.1 MUST + begin with a lowercase letter, whereas type names MUST begin with an + uppercase letter. + +5.1. Specific Compatibility Notes on ASN.1 + + For compatibility purposes, implementors should heed the following + specific notes regarding the use of ASN.1 in Kerberos. These notes + do not describe deviations from standard usage of ASN.1. The purpose + of these notes is instead to describe some historical quirks and + non-compliance of various implementations, as well as historical + ambiguities, which, although they are valid ASN.1, can lead to + confusion during implementation. + +5.1.1. ASN.1 Distinguished Encoding Rules + + The encoding of Kerberos protocol messages shall obey the + Distinguished Encoding Rules (DER) of ASN.1 as described in [X690]. + Some implementations (believed primarily to be those derived from DCE + 1.1 and earlier) are known to use the more general Basic Encoding + + + +Neuman, et al. Standards Track [Page 51] + +RFC 4120 Kerberos V5 July 2005 + + + Rules (BER); in particular, these implementations send indefinite + encodings of lengths. Implementations MAY accept such encodings in + the interest of backward compatibility, though implementors are + warned that decoding fully-general BER is fraught with peril. + +5.1.2. Optional Integer Fields + + Some implementations do not internally distinguish between an omitted + optional integer value and a transmitted value of zero. The places + in the protocol where this is relevant include various microseconds + fields, nonces, and sequence numbers. Implementations SHOULD treat + omitted optional integer values as having been transmitted with a + value of zero, if the application is expecting this. + +5.1.3. Empty SEQUENCE OF Types + + There are places in the protocol where a message contains a SEQUENCE + OF type as an optional member. This can result in an encoding that + contains an empty SEQUENCE OF encoding. The Kerberos protocol does + not semantically distinguish between an absent optional SEQUENCE OF + type and a present optional but empty SEQUENCE OF type. + Implementations SHOULD NOT send empty SEQUENCE OF encodings that are + marked OPTIONAL, but SHOULD accept them as being equivalent to an + omitted OPTIONAL type. In the ASN.1 syntax describing Kerberos + messages, instances of these problematic optional SEQUENCE OF types + are indicated with a comment. + +5.1.4. Unrecognized Tag Numbers + + Future revisions to this protocol may include new message types with + different APPLICATION class tag numbers. Such revisions should + protect older implementations by only sending the message types to + parties that are known to understand them; e.g., by means of a flag + bit set by the receiver in a preceding request. In the interest of + robust error handling, implementations SHOULD gracefully handle + receiving a message with an unrecognized tag anyway, and return an + error message, if appropriate. + + In particular, KDCs SHOULD return KRB_AP_ERR_MSG_TYPE if the + incorrect tag is sent over a TCP transport. The KDCs SHOULD NOT + respond to messages received with an unknown tag over UDP transport + in order to avoid denial of service attacks. For non-KDC + applications, the Kerberos implementation typically indicates an + error to the application which takes appropriate steps based on the + application protocol. + + + + + + +Neuman, et al. Standards Track [Page 52] + +RFC 4120 Kerberos V5 July 2005 + + +5.1.5. Tag Numbers Greater Than 30 + + A naive implementation of a DER ASN.1 decoder may experience problems + with ASN.1 tag numbers greater than 30, due to such tag numbers being + encoded using more than one byte. Future revisions of this protocol + may utilize tag numbers greater than 30, and implementations SHOULD + be prepared to gracefully return an error, if appropriate, when they + do not recognize the tag. + +5.2. Basic Kerberos Types + + This section defines a number of basic types that are potentially + used in multiple Kerberos protocol messages. + +5.2.1. KerberosString + + The original specification of the Kerberos protocol in RFC 1510 uses + GeneralString in numerous places for human-readable string data. + Historical implementations of Kerberos cannot utilize the full power + of GeneralString. This ASN.1 type requires the use of designation + and invocation escape sequences as specified in ISO-2022/ECMA-35 + [ISO-2022/ECMA-35] to switch character sets, and the default + character set that is designated as G0 is the ISO-646/ECMA-6 + [ISO-646/ECMA-6] International Reference Version (IRV) (a.k.a. U.S. + ASCII), which mostly works. + + ISO-2022/ECMA-35 defines four character-set code elements (G0..G3) + and two Control-function code elements (C0..C1). DER prohibits the + designation of character sets as any but the G0 and C0 sets. + Unfortunately, this seems to have the side effect of prohibiting the + use of ISO-8859 (ISO Latin) [ISO-8859] character sets or any other + character sets that utilize a 96-character set, as ISO-2022/ECMA-35 + prohibits designating them as the G0 code element. This side effect + is being investigated in the ASN.1 standards community. + + In practice, many implementations treat GeneralStrings as if they + were 8-bit strings of whichever character set the implementation + defaults to, without regard to correct usage of character-set + designation escape sequences. The default character set is often + determined by the current user's operating system-dependent locale. + At least one major implementation places unescaped UTF-8 encoded + Unicode characters in the GeneralString. This failure to adhere to + the GeneralString specifications results in interoperability issues + when conflicting character encodings are utilized by the Kerberos + clients, services, and KDC. + + + + + + +Neuman, et al. Standards Track [Page 53] + +RFC 4120 Kerberos V5 July 2005 + + + This unfortunate situation is the result of improper documentation of + the restrictions of the ASN.1 GeneralString type in prior Kerberos + specifications. + + The new (post-RFC 1510) type KerberosString, defined below, is a + GeneralString that is constrained to contain only characters in + IA5String. + + KerberosString ::= GeneralString (IA5String) + + In general, US-ASCII control characters should not be used in + KerberosString. Control characters SHOULD NOT be used in principal + names or realm names. + + For compatibility, implementations MAY choose to accept GeneralString + values that contain characters other than those permitted by + IA5String, but they should be aware that character set designation + codes will likely be absent, and that the encoding should probably be + treated as locale-specific in almost every way. Implementations MAY + also choose to emit GeneralString values that are beyond those + permitted by IA5String, but they should be aware that doing so is + extraordinarily risky from an interoperability perspective. + + Some existing implementations use GeneralString to encode unescaped + locale-specific characters. This is a violation of the ASN.1 + standard. Most of these implementations encode US-ASCII in the + left-hand half, so as long as the implementation transmits only + US-ASCII, the ASN.1 standard is not violated in this regard. As soon + as such an implementation encodes unescaped locale-specific + characters with the high bit set, it violates the ASN.1 standard. + + Other implementations have been known to use GeneralString to contain + a UTF-8 encoding. This also violates the ASN.1 standard, since UTF-8 + is a different encoding, not a 94 or 96 character "G" set as defined + by ISO 2022. It is believed that these implementations do not even + use the ISO 2022 escape sequence to change the character encoding. + Even if implementations were to announce the encoding change by using + that escape sequence, the ASN.1 standard prohibits the use of any + escape sequences other than those used to designate/invoke "G" or "C" + sets allowed by GeneralString. + + Future revisions to this protocol will almost certainly allow for a + more interoperable representation of principal names, probably + including UTF8String. + + Note that applying a new constraint to a previously unconstrained + type constitutes creation of a new ASN.1 type. In this particular + case, the change does not result in a changed encoding under DER. + + + +Neuman, et al. Standards Track [Page 54] + +RFC 4120 Kerberos V5 July 2005 + + +5.2.2. Realm and PrincipalName + + Realm ::= KerberosString + + PrincipalName ::= SEQUENCE { + name-type [0] Int32, + name-string [1] SEQUENCE OF KerberosString + } + + Kerberos realm names are encoded as KerberosStrings. Realms shall + not contain a character with the code 0 (the US-ASCII NUL). Most + realms will usually consist of several components separated by + periods (.), in the style of Internet Domain Names, or separated by + slashes (/), in the style of X.500 names. Acceptable forms for realm + names are specified in Section 6.1. A PrincipalName is a typed + sequence of components consisting of the following subfields: + + name-type + This field specifies the type of name that follows. Pre-defined + values for this field are specified in Section 6.2. The name-type + SHOULD be treated as a hint. 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). + + name-string + This field encodes a sequence of components that form a name, each + component encoded as a KerberosString. Taken together, a + PrincipalName and a Realm form a principal identifier. Most + PrincipalNames will have only a few components (typically one or + two). + +5.2.3. KerberosTime + + KerberosTime ::= GeneralizedTime -- with no fractional seconds + + The timestamps used in Kerberos are encoded as GeneralizedTimes. A + KerberosTime value shall not include any fractional portions of the + seconds. As required by the DER, it further shall not include any + separators, and it shall specify the UTC time zone (Z). Example: The + only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6 + November 1985 is 19851106210627Z. + +5.2.4. Constrained Integer Types + + Some integer members of types SHOULD be constrained to values + representable in 32 bits, for compatibility with reasonable + implementation limits. + + + + +Neuman, et al. Standards Track [Page 55] + +RFC 4120 Kerberos V5 July 2005 + + + Int32 ::= INTEGER (-2147483648..2147483647) + -- signed values representable in 32 bits + + UInt32 ::= INTEGER (0..4294967295) + -- unsigned 32 bit values + + Microseconds ::= INTEGER (0..999999) + -- microseconds + + Although this results in changes to the abstract types from the RFC + 1510 version, the encoding in DER should be unaltered. Historical + implementations were typically limited to 32-bit integer values + anyway, and assigned numbers SHOULD fall in the space of integer + values representable in 32 bits in order to promote interoperability + anyway. + + Several integer fields in messages are constrained to fixed values. + + pvno + also TKT-VNO or AUTHENTICATOR-VNO, this recurring field is always + the constant integer 5. There is no easy way to make this field + into a useful protocol version number, so its value is fixed. + + msg-type + this integer field is usually identical to the application tag + number of the containing message type. + +5.2.5. HostAddress and HostAddresses + + HostAddress ::= SEQUENCE { + addr-type [0] Int32, + address [1] OCTET STRING + } + + -- NOTE: HostAddresses is always used as an OPTIONAL field and + -- should not be empty. + HostAddresses -- NOTE: subtly different from rfc1510, + -- but has a value mapping and encodes the same + ::= SEQUENCE OF HostAddress + + The host address encodings consist of two fields: + + addr-type + This field specifies the type of address that follows. Pre- + defined values for this field are specified in Section 7.5.3. + + address + This field encodes a single address of type addr-type. + + + +Neuman, et al. Standards Track [Page 56] + +RFC 4120 Kerberos V5 July 2005 + + +5.2.6. AuthorizationData + + -- NOTE: AuthorizationData is always used as an OPTIONAL field and + -- should not be empty. + AuthorizationData ::= SEQUENCE OF SEQUENCE { + ad-type [0] Int32, + ad-data [1] OCTET STRING + } + + ad-data + This field contains authorization data to be interpreted according + to the value of the corresponding ad-type field. + + ad-type + This field specifies the format for the ad-data subfield. All + negative values are reserved for local use. Non-negative values + are reserved for registered use. + + Each sequence of type and data is referred to as an authorization + element. Elements MAY be application specific; however, there is a + common set of recursive elements that should be understood by all + implementations. These elements contain other elements embedded + within them, and the interpretation of the encapsulating element + determines which of the embedded elements must be interpreted, and + which may be ignored. + + These common authorization data elements are recursively defined, + meaning that the ad-data for these types will itself contain a + sequence of authorization data whose interpretation is affected by + the encapsulating element. Depending on the meaning of the + encapsulating element, the encapsulated elements may be ignored, + might be interpreted as issued directly by the KDC, or might be + stored in a separate plaintext part of the ticket. The types of the + encapsulating elements are specified as part of the Kerberos + specification because the behavior based on these values should be + understood across implementations, whereas other elements need only + be understood by the applications that they affect. + + Authorization data elements are considered critical if present in a + ticket or authenticator. If an unknown authorization data element + type is received by a server either in an AP-REQ or in a ticket + contained in an AP-REQ, then, unless it is encapsulated in a known + authorization data element amending the criticality of the elements + it contains, authentication MUST fail. Authorization data is + intended to restrict the use of a ticket. If the service cannot + determine whether the restriction applies to that service, then a + + + + + +Neuman, et al. Standards Track [Page 57] + +RFC 4120 Kerberos V5 July 2005 + + + security weakness may result if the ticket can be used for that + service. Authorization elements that are optional can be enclosed in + an AD-IF-RELEVANT element. + + In the definitions that follow, the value of the ad-type for the + element will be specified as the least significant part of the + subsection number, and the value of the ad-data will be as shown in + the ASN.1 structure that follows the subsection heading. + + Contents of ad-data ad-type + + DER encoding of AD-IF-RELEVANT 1 + + DER encoding of AD-KDCIssued 4 + + DER encoding of AD-AND-OR 5 + + DER encoding of AD-MANDATORY-FOR-KDC 8 + +5.2.6.1. IF-RELEVANT + + AD-IF-RELEVANT ::= AuthorizationData + + AD elements encapsulated within the if-relevant element are intended + for interpretation only by application servers that understand the + particular ad-type of the embedded element. Application servers that + do not understand the type of an element embedded within the + if-relevant element MAY ignore the uninterpretable element. This + element promotes interoperability across implementations that may + have local extensions for authorization. The ad-type for + AD-IF-RELEVANT is (1). + +5.2.6.2. KDCIssued + + AD-KDCIssued ::= SEQUENCE { + ad-checksum [0] Checksum, + i-realm [1] Realm OPTIONAL, + i-sname [2] PrincipalName OPTIONAL, + elements [3] AuthorizationData + } + + ad-checksum + A cryptographic checksum computed over the DER encoding of the + AuthorizationData in the "elements" field, keyed with the session + key. Its checksumtype is the mandatory checksum type for the + encryption type of the session key, and its key usage value is 19. + + + + + +Neuman, et al. Standards Track [Page 58] + +RFC 4120 Kerberos V5 July 2005 + + + i-realm, i-sname + The name of the issuing principal if different from that of the + KDC itself. This field would be used when the KDC can verify the + authenticity of elements signed by the issuing principal, and it + allows this KDC to notify the application server of the validity + of those elements. + + elements + A sequence of authorization data elements issued by the KDC. + + The KDC-issued ad-data field is intended to provide a means for + Kerberos principal credentials to embed within themselves privilege + attributes and other mechanisms for positive authorization, + amplifying the privileges of the principal beyond what can be done + using credentials without such an a-data element. + + The above means cannot be provided without this element because the + definition of the authorization-data field allows elements to be + added at will by the bearer of a TGT at the time when they request + service tickets, and elements may also be added to a delegated ticket + by inclusion in the authenticator. + + For KDC-issued elements, this is prevented because the elements are + signed by the KDC by including a checksum encrypted using the + server's key (the same key used to encrypt the ticket or a key + derived from that key). Elements encapsulated with in the KDC-issued + element MUST be ignored by the application server if this "signature" + is not present. Further, elements encapsulated within this element + from a TGT MAY be interpreted by the KDC, and used as a basis + according to policy for including new signed elements within + derivative tickets, but they will not be copied to a derivative + ticket directly. If they are copied directly to a derivative ticket + by a KDC that is not aware of this element, the signature will not be + correct for the application ticket elements, and the field will be + ignored by the application server. + + This element and the elements it encapsulates MAY safely be ignored + by applications, application servers, and KDCs that do not implement + this element. + + The ad-type for AD-KDC-ISSUED is (4). + +5.2.6.3. AND-OR + + AD-AND-OR ::= SEQUENCE { + condition-count [0] Int32, + elements [1] AuthorizationData + } + + + +Neuman, et al. Standards Track [Page 59] + +RFC 4120 Kerberos V5 July 2005 + + + When restrictive AD elements are encapsulated within the and-or + element, the and-or element is considered satisfied if and only if at + least the number of encapsulated elements specified in condition- + count are satisfied. Therefore, this element MAY be used to + implement an "or" operation by setting the condition-count field to + 1, and it MAY specify an "and" operation by setting the condition + count to the number of embedded elements. Application servers that + do not implement this element MUST reject tickets that contain + authorization data elements of this type. + + The ad-type for AD-AND-OR is (5). + +5.2.6.4. MANDATORY-FOR-KDC + + AD-MANDATORY-FOR-KDC ::= AuthorizationData + + AD elements encapsulated within the mandatory-for-kdc element are to + be interpreted by the KDC. KDCs that do not understand the type of + an element embedded within the mandatory-for-kdc element MUST reject + the request. + + The ad-type for AD-MANDATORY-FOR-KDC is (8). + +5.2.7. PA-DATA + + Historically, PA-DATA have been known as "pre-authentication data", + meaning that they were used to augment the initial authentication + with the KDC. Since that time, they have also been used as a typed + hole with which to extend protocol exchanges with the KDC. + + PA-DATA ::= SEQUENCE { + -- NOTE: first tag is [1], not [0] + padata-type [1] Int32, + padata-value [2] OCTET STRING -- might be encoded AP-REQ + } + + padata-type + Indicates the way that the padata-value element is to be + interpreted. Negative values of padata-type are reserved for + unregistered use; non-negative values are used for a registered + interpretation of the element type. + + padata-value + Usually contains the DER encoding of another type; the padata-type + field identifies which type is encoded here. + + + + + + +Neuman, et al. Standards Track [Page 60] + +RFC 4120 Kerberos V5 July 2005 + + + padata-type Name Contents of padata-value + + 1 pa-tgs-req DER encoding of AP-REQ + + 2 pa-enc-timestamp DER encoding of PA-ENC-TIMESTAMP + + 3 pa-pw-salt salt (not ASN.1 encoded) + + 11 pa-etype-info DER encoding of ETYPE-INFO + + 19 pa-etype-info2 DER encoding of ETYPE-INFO2 + + This field MAY also contain information needed by certain + extensions to the Kerberos protocol. For example, it might be + used to verify the identity of a client initially before any + response is returned. + + The padata field can also contain information needed to help the + KDC or the client select the key needed for generating or + decrypting the response. This form of the padata is useful for + supporting the use of certain token cards with Kerberos. The + details of such extensions are specified in separate documents. + See [Pat92] for additional uses of this field. + +5.2.7.1. PA-TGS-REQ + + In the case of requests for additional tickets (KRB_TGS_REQ), + padata-value will contain an encoded AP-REQ. The checksum in the + authenticator (which MUST be collision-proof) is to be computed over + the KDC-REQ-BODY encoding. + +5.2.7.2. Encrypted Timestamp Pre-authentication + + There are pre-authentication types that may be used to pre- + authenticate a client by means of an encrypted timestamp. + + PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC + + PA-ENC-TS-ENC ::= SEQUENCE { + patimestamp [0] KerberosTime -- client's time --, + pausec [1] Microseconds OPTIONAL + } + + Patimestamp contains the client's time, and pausec contains the + microseconds, which MAY be omitted if a client will not generate more + than one request per second. The ciphertext (padata-value) consists + of the PA-ENC-TS-ENC encoding, encrypted using the client's secret + key and a key usage value of 1. + + + +Neuman, et al. Standards Track [Page 61] + +RFC 4120 Kerberos V5 July 2005 + + + This pre-authentication type was not present in RFC 1510, but many + implementations support it. + +5.2.7.3. PA-PW-SALT + + The padata-value for this pre-authentication type contains the salt + for the string-to-key to be used by the client to obtain the key for + decrypting the encrypted part of an AS-REP message. Unfortunately, + for historical reasons, the character set to be used is unspecified + and probably locale-specific. + + This pre-authentication type was not present in RFC 1510, but many + implementations support it. It is necessary in any case where the + salt for the string-to-key algorithm is not the default. + + In the trivial example, a zero-length salt string is very commonplace + for realms that have converted their principal databases from + Kerberos Version 4. + + A KDC SHOULD NOT send PA-PW-SALT when issuing a KRB-ERROR message + that requests additional pre-authentication. Implementation note: + Some KDC implementations issue an erroneous PA-PW-SALT when issuing a + KRB-ERROR message that requests additional pre-authentication. + Therefore, clients SHOULD ignore a PA-PW-SALT accompanying a + KRB-ERROR message that requests additional pre-authentication. As + noted in section 3.1.3, a KDC MUST NOT send PA-PW-SALT when the + client's AS-REQ includes at least one "newer" etype. + +5.2.7.4. PA-ETYPE-INFO + + The ETYPE-INFO pre-authentication type is sent by the KDC in a + KRB-ERROR indicating a requirement for additional pre-authentication. + It is usually used to notify a client of which key to use for the + encryption of an encrypted timestamp for the purposes of sending a + PA-ENC-TIMESTAMP pre-authentication value. It MAY also be sent in an + AS-REP to provide information to the client about which key salt to + use for the string-to-key to be used by the client to obtain the key + for decrypting the encrypted part the AS-REP. + + ETYPE-INFO-ENTRY ::= SEQUENCE { + etype [0] Int32, + salt [1] OCTET STRING OPTIONAL + } + + ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY + + The salt, like that of PA-PW-SALT, is also completely unspecified + with respect to character set and is probably locale-specific. + + + +Neuman, et al. Standards Track [Page 62] + +RFC 4120 Kerberos V5 July 2005 + + + If ETYPE-INFO is sent in an AS-REP, there shall be exactly one + ETYPE-INFO-ENTRY, and its etype shall match that of the enc-part in + the AS-REP. + + This pre-authentication type was not present in RFC 1510, but many + implementations that support encrypted timestamps for pre- + authentication need to support ETYPE-INFO as well. As noted in + Section 3.1.3, a KDC MUST NOT send PA-ETYPE-INFO when the client's + AS-REQ includes at least one "newer" etype. + +5.2.7.5. PA-ETYPE-INFO2 + + The ETYPE-INFO2 pre-authentication type is sent by the KDC in a + KRB-ERROR indicating a requirement for additional pre-authentication. + It is usually used to notify a client of which key to use for the + encryption of an encrypted timestamp for the purposes of sending a + PA-ENC-TIMESTAMP pre-authentication value. It MAY also be sent in an + AS-REP to provide information to the client about which key salt to + use for the string-to-key to be used by the client to obtain the key + for decrypting the encrypted part the AS-REP. + +ETYPE-INFO2-ENTRY ::= SEQUENCE { + etype [0] Int32, + salt [1] KerberosString OPTIONAL, + s2kparams [2] OCTET STRING OPTIONAL +} + +ETYPE-INFO2 ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY + + The type of the salt is KerberosString, but existing installations + might have locale-specific characters stored in salt strings, and + implementors MAY choose to handle them. + + The interpretation of s2kparams is specified in the cryptosystem + description associated with the etype. Each cryptosystem has a + default interpretation of s2kparams that will hold if that element is + omitted from the encoding of ETYPE-INFO2-ENTRY. + + If ETYPE-INFO2 is sent in an AS-REP, there shall be exactly one + ETYPE-INFO2-ENTRY, and its etype shall match that of the enc-part in + the AS-REP. + + The preferred ordering of the "hint" pre-authentication data that + affect client key selection is: ETYPE-INFO2, followed by ETYPE-INFO, + followed by PW-SALT. As noted in Section 3.1.3, a KDC MUST NOT send + ETYPE-INFO or PW-SALT when the client's AS-REQ includes at least one + "newer" etype. + + + + +Neuman, et al. Standards Track [Page 63] + +RFC 4120 Kerberos V5 July 2005 + + + The ETYPE-INFO2 pre-authentication type was not present in RFC 1510. + +5.2.8. KerberosFlags + + For several message types, a specific constrained bit string type, + KerberosFlags, is used. + + KerberosFlags ::= BIT STRING (SIZE (32..MAX)) + -- minimum number of bits shall be sent, + -- but no fewer than 32 + + Compatibility note: The following paragraphs describe a change from + the RFC 1510 description of bit strings that would result in + incompatility in the case of an implementation that strictly + conformed to ASN.1 DER and RFC 1510. + + ASN.1 bit strings have multiple uses. The simplest use of a bit + string is to contain a vector of bits, with no particular meaning + attached to individual bits. This vector of bits is not necessarily + a multiple of eight bits long. The use in Kerberos of a bit string + as a compact boolean vector wherein each element has a distinct + meaning poses some problems. The natural notation for a compact + boolean vector is the ASN.1 "NamedBit" notation, and the DER require + that encodings of a bit string using "NamedBit" notation exclude any + trailing zero bits. This truncation is easy to neglect, especially + given C language implementations that naturally choose to store + boolean vectors as 32-bit integers. + + For example, if the notation for KDCOptions were to include the + "NamedBit" notation, as in RFC 1510, and a KDCOptions value to be + encoded had only the "forwardable" (bit number one) bit set, the DER + encoding MUST include only two bits: the first reserved bit + ("reserved", bit number zero, value zero) and the one-valued bit (bit + number one) for "forwardable". + + Most existing implementations of Kerberos unconditionally send 32 + bits on the wire when encoding bit strings used as boolean vectors. + This behavior violates the ASN.1 syntax used for flag values in RFC + 1510, but it occurs on such a widely installed base that the protocol + description is being modified to accommodate it. + + Consequently, this document removes the "NamedBit" notations for + individual bits, relegating them to comments. The size constraint on + the KerberosFlags type requires that at least 32 bits be encoded at + all times, though a lenient implementation MAY choose to accept fewer + than 32 bits and to treat the missing bits as set to zero. + + + + + +Neuman, et al. Standards Track [Page 64] + +RFC 4120 Kerberos V5 July 2005 + + + Currently, no uses of KerberosFlags specify more than 32 bits' worth + of flags, although future revisions of this document may do so. When + more than 32 bits are to be transmitted in a KerberosFlags value, + future revisions to this document will likely specify that the + smallest number of bits needed to encode the highest-numbered one- + valued bit should be sent. This is somewhat similar to the DER + encoding of a bit string that is declared with the "NamedBit" + notation. + +5.2.9. Cryptosystem-Related Types + + Many Kerberos protocol messages contain an EncryptedData as a + container for arbitrary encrypted data, which is often the encrypted + encoding of another data type. Fields within EncryptedData assist + the recipient in selecting a key with which to decrypt the enclosed + data. + + EncryptedData ::= SEQUENCE { + etype [0] Int32 -- EncryptionType --, + kvno [1] UInt32 OPTIONAL, + cipher [2] OCTET STRING -- ciphertext + } + + etype + This field identifies which encryption algorithm was used to + encipher the cipher. + + kvno + This field contains the version number of the key under which data + is encrypted. It is only present in messages encrypted under long + lasting keys, such as principals' secret keys. + + cipher + This field contains the enciphered text, encoded as an OCTET + STRING. (Note that the encryption mechanisms defined in [RFC3961] + MUST incorporate integrity protection as well, so no additional + checksum is required.) + + The EncryptionKey type is the means by which cryptographic keys used + for encryption are transferred. + + EncryptionKey ::= SEQUENCE { + keytype [0] Int32 -- actually encryption type --, + keyvalue [1] OCTET STRING + } + + + + + + +Neuman, et al. Standards Track [Page 65] + +RFC 4120 Kerberos V5 July 2005 + + + keytype + This field specifies the encryption type of the encryption key + that follows in the keyvalue field. Although its name is + "keytype", it actually specifies an encryption type. Previously, + multiple cryptosystems that performed encryption differently but + were capable of using keys with the same characteristics were + permitted to share an assigned number to designate the type of + key; this usage is now deprecated. + + keyvalue + This field contains the key itself, encoded as an octet string. + + Messages containing cleartext data to be authenticated will usually + do so by using a member of type Checksum. Most instances of Checksum + use a keyed hash, though exceptions will be noted. + + Checksum ::= SEQUENCE { + cksumtype [0] Int32, + checksum [1] OCTET STRING + } + + cksumtype + This field indicates the algorithm used to generate the + accompanying checksum. + + checksum + This field contains the checksum itself, encoded as an octet + string. + + See Section 4 for a brief description of the use of encryption and + checksums in Kerberos. + +5.3. Tickets + + This section describes the format and encryption parameters for + tickets and authenticators. When a ticket or authenticator is + included in a protocol message, it is treated as an opaque object. A + ticket is a record that helps a client authenticate to a service. A + Ticket contains the following information: + + Ticket ::= [APPLICATION 1] SEQUENCE { + tkt-vno [0] INTEGER (5), + realm [1] Realm, + sname [2] PrincipalName, + enc-part [3] EncryptedData -- EncTicketPart + } + + -- Encrypted part of ticket + + + +Neuman, et al. Standards Track [Page 66] + +RFC 4120 Kerberos V5 July 2005 + + + EncTicketPart ::= [APPLICATION 3] SEQUENCE { + flags [0] TicketFlags, + key [1] EncryptionKey, + crealm [2] Realm, + cname [3] PrincipalName, + transited [4] TransitedEncoding, + authtime [5] KerberosTime, + starttime [6] KerberosTime OPTIONAL, + endtime [7] KerberosTime, + renew-till [8] KerberosTime OPTIONAL, + caddr [9] HostAddresses OPTIONAL, + authorization-data [10] AuthorizationData OPTIONAL + } + + -- encoded Transited field + TransitedEncoding ::= SEQUENCE { + tr-type [0] Int32 -- must be registered --, + contents [1] OCTET STRING + } + + TicketFlags ::= KerberosFlags + -- reserved(0), + -- forwardable(1), + -- forwarded(2), + -- proxiable(3), + -- proxy(4), + -- may-postdate(5), + -- postdated(6), + -- invalid(7), + -- renewable(8), + -- initial(9), + -- pre-authent(10), + -- hw-authent(11), + -- the following are new since 1510 + -- transited-policy-checked(12), + -- ok-as-delegate(13) + + tkt-vno + This field specifies the version number for the ticket format. + This document describes version number 5. + + realm + This field specifies the realm that issued a ticket. It also + serves to identify the realm part of the server's principal + identifier. Since a Kerberos server can only issue tickets for + servers within its realm, the two will always be identical. + + + + + +Neuman, et al. Standards Track [Page 67] + +RFC 4120 Kerberos V5 July 2005 + + + sname + This field specifies all components of the name part of the + server's identity, including those parts that identify a specific + instance of a service. + + enc-part + This field holds the encrypted encoding of the EncTicketPart + sequence. It is encrypted in the key shared by Kerberos and the + end server (the server's secret key), using a key usage value of + 2. + + flags + This field indicates which of various options were used or + requested when the ticket was issued. The meanings of the flags + are as follows: + + Bit(s) Name Description + + 0 reserved Reserved for future expansion of this field. + + 1 forwardable The FORWARDABLE flag is normally only + interpreted by the TGS, and can be ignored + by end servers. When set, this flag tells + the ticket-granting server that it is OK to + issue a new TGT with a different network + address based on the presented ticket. + + 2 forwarded When set, this flag indicates that the + ticket has either been forwarded or was + issued based on authentication involving a + forwarded TGT. + + 3 proxiable The PROXIABLE flag is normally only + interpreted by the TGS, and can be ignored + by end servers. The PROXIABLE flag has an + interpretation identical to that of the + FORWARDABLE flag, except that the PROXIABLE + flag tells the ticket-granting server that + only non-TGTs may be issued with different + network addresses. + + 4 proxy When set, this flag indicates that a ticket + is a proxy. + + 5 may-postdate The MAY-POSTDATE flag is normally only + interpreted by the TGS, and can be ignored + by end servers. This flag tells the + + + + +Neuman, et al. Standards Track [Page 68] + +RFC 4120 Kerberos V5 July 2005 + + + ticket-granting server that a post-dated + ticket MAY be issued based on this TGT. + + 6 postdated This flag indicates that this ticket has + been postdated. The end-service can check + the authtime field to see when the original + authentication occurred. + + 7 invalid This flag indicates that a ticket is + invalid, and it must be validated by the KDC + before use. Application servers must reject + tickets which have this flag set. + + 8 renewable The RENEWABLE flag is normally only + interpreted by the TGS, and can usually be + ignored by end servers (some particularly + careful servers MAY disallow renewable + tickets). A renewable ticket can be used to + obtain a replacement ticket that expires at + a later date. + + 9 initial This flag indicates that this ticket was + issued using the AS protocol, and not issued + based on a TGT. + + 10 pre-authent This flag indicates that during initial + authentication, the client was authenticated + by the KDC before a ticket was issued. The + strength of the pre-authentication method is + not indicated, but is acceptable to the KDC. + + 11 hw-authent This flag indicates that the protocol + employed for initial authentication required + the use of hardware expected to be possessed + solely by the named client. The hardware + authentication method is selected by the KDC + and the strength of the method is not + indicated. + + 12 transited- This flag indicates that the KDC for + policy-checked the realm has checked the transited field + against a realm-defined policy for trusted + certifiers. If this flag is reset (0), then + the application server must check the + transited field itself, and if unable to do + so, it must reject the authentication. If + the flag is set (1), then the application + server MAY skip its own validation of the + + + +Neuman, et al. Standards Track [Page 69] + +RFC 4120 Kerberos V5 July 2005 + + + transited field, relying on the validation + performed by the KDC. At its option the + application server MAY still apply its own + validation based on a separate policy for + acceptance. + + This flag is new since RFC 1510. + + 13 ok-as-delegate This flag indicates that the server (not the + client) specified in the ticket has been + determined by policy of the realm to be a + suitable recipient of delegation. A client + can use the presence of this flag to help it + decide whether to delegate credentials + (either grant a proxy or a forwarded TGT) to + this server. The client is free to ignore + the value of this flag. When setting this + flag, an administrator should consider the + security and placement of the server on + which the service will run, as well as + whether the service requires the use of + delegated credentials. + + This flag is new since RFC 1510. + + 14-31 reserved Reserved for future use. + + key + This field exists in the ticket and the KDC response and is used + to pass the session key from Kerberos to the application server + and the client. + + crealm + This field contains the name of the realm in which the client is + registered and in which initial authentication took place. + + cname + This field contains the name part of the client's principal + identifier. + + transited + This field lists the names of the Kerberos realms that took part + in authenticating the user to whom this ticket was issued. It + does not specify the order in which the realms were transited. + See Section 3.3.3.2 for details on how this field encodes the + traversed realms. When the names of CAs are to be embedded in the + transited field (as specified for some extensions to the + + + + +Neuman, et al. Standards Track [Page 70] + +RFC 4120 Kerberos V5 July 2005 + + + protocol), the X.500 names of the CAs SHOULD be mapped into items + in the transited field using the mapping defined by RFC 2253. + + authtime + This field indicates the time of initial authentication for the + named principal. It is the time of issue for the original ticket + on which this ticket is based. It is included in the ticket to + provide additional information to the end service, and to provide + the necessary information for implementation of a "hot list" + service at the KDC. An end service that is particularly paranoid + could refuse to accept tickets for which the initial + authentication occurred "too far" in the past. This field is also + returned as part of the response from the KDC. When it is + returned as part of the response to initial authentication + (KRB_AS_REP), this is the current time on the Kerberos server. It + is NOT recommended that this time value be used to adjust the + workstation's clock, as the workstation cannot reliably determine + that such a KRB_AS_REP actually came from the proper KDC in a + timely manner. + + starttime + This field in the ticket specifies the time after which the ticket + is valid. Together with endtime, this field specifies the life of + the ticket. If the starttime field is absent from the ticket, + then the authtime field SHOULD be used in its place to determine + the life of the ticket. + + endtime + This field contains the time after which the ticket will not be + honored (its expiration time). Note that individual services MAY + place their own limits on the life of a ticket and MAY reject + tickets which have not yet expired. As such, this is really an + upper bound on the expiration time for the ticket. + + renew-till + This field is only present in tickets that have the RENEWABLE flag + set in the flags field. It indicates the maximum endtime that may + be included in a renewal. It can be thought of as the absolute + expiration time for the ticket, including all renewals. + + caddr + This field in a ticket contains zero (if omitted) or more (if + present) host addresses. These are the addresses from which the + ticket can be used. If there are no addresses, the ticket can be + used from any location. The decision by the KDC to issue or by + the end server to accept addressless tickets is a policy decision + and is left to the Kerberos and end-service administrators; they + MAY refuse to issue or accept such tickets. Because of the wide + + + +Neuman, et al. Standards Track [Page 71] + +RFC 4120 Kerberos V5 July 2005 + + + deployment of network address translation, it is recommended that + policy allow the issue and acceptance of such tickets. + + Network addresses are included in the ticket to make it harder for + an attacker to use stolen credentials. Because the session key is + not sent over the network in cleartext, credentials can't be + stolen simply by listening to the network; an attacker has to gain + access to the session key (perhaps through operating system + security breaches or a careless user's unattended session) to make + use of stolen tickets. + + Note that the network address from which a connection is received + cannot be reliably determined. Even if it could be, an attacker + who has compromised the client's workstation could use the + credentials from there. Including the network addresses only + makes it more difficult, not impossible, for an attacker to walk + off with stolen credentials and then to use them from a "safe" + location. + + authorization-data + The authorization-data field is used to pass authorization data + from the principal on whose behalf a ticket was issued to the + application service. If no authorization data is included, this + field will be left out. Experience has shown that the name of + this field is confusing, and that a better name would be + "restrictions". Unfortunately, it is not possible to change the + name at this time. + + This field contains restrictions on any authority obtained on the + basis of authentication using the ticket. It is possible for any + principal in possession of credentials to add entries to the + authorization data field since these entries further restrict what + can be done with the ticket. Such additions can be made by + specifying the additional entries when a new ticket is obtained + during the TGS exchange, or they MAY be added during chained + delegation using the authorization data field of the + authenticator. + + Because entries may be added to this field by the holder of + credentials, except when an entry is separately authenticated by + encapsulation in the KDC-issued element, it is not allowable for + the presence of an entry in the authorization data field of a + ticket to amplify the privileges one would obtain from using a + ticket. + + The data in this field may be specific to the end service; the + field will contain the names of service specific objects, and the + rights to those objects. The format for this field is described + + + +Neuman, et al. Standards Track [Page 72] + +RFC 4120 Kerberos V5 July 2005 + + + in Section 5.2.6. Although Kerberos is not concerned with the + format of the contents of the subfields, it does carry type + information (ad-type). + + By using the authorization_data field, a principal is able to + issue a proxy that is valid for a specific purpose. For example, + a client wishing to print a file can obtain a file server proxy to + be passed to the print server. By specifying the name of the file + in the authorization_data field, the file server knows that the + print server can only use the client's rights when accessing the + particular file to be printed. + + A separate service providing authorization or certifying group + membership may be built using the authorization-data field. In + this case, the entity granting authorization (not the authorized + entity) may obtain a ticket in its own name (e.g., the ticket is + issued in the name of a privilege server), and this entity adds + restrictions on its own authority and delegates the restricted + authority through a proxy to the client. The client would then + present this authorization credential to the application server + separately from the authentication exchange. Alternatively, such + authorization credentials MAY be embedded in the ticket + authenticating the authorized entity, when the authorization is + separately authenticated using the KDC-issued authorization data + element (see 5.2.6.2). + + Similarly, if one specifies the authorization-data field of a + proxy and leaves the host addresses blank, the resulting ticket + and session key can be treated as a capability. See [Neu93] for + some suggested uses of this field. + + The authorization-data field is optional and does not have to be + included in a ticket. + +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. + + + +Neuman, et al. Standards Track [Page 73] + +RFC 4120 Kerberos V5 July 2005 + + + 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), + + + +Neuman, et al. Standards Track [Page 74] + +RFC 4120 Kerberos V5 July 2005 + + + -- 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 + + + +Neuman, et al. Standards Track [Page 75] + +RFC 4120 Kerberos V5 July 2005 + + + 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 + + + +Neuman, et al. Standards Track [Page 76] + +RFC 4120 Kerberos V5 July 2005 + + + 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 + + + +Neuman, et al. Standards Track [Page 77] + +RFC 4120 Kerberos V5 July 2005 + + + 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 + + + +Neuman, et al. Standards Track [Page 78] + +RFC 4120 Kerberos V5 July 2005 + + + 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. + + + + + +Neuman, et al. Standards Track [Page 79] + +RFC 4120 Kerberos V5 July 2005 + + + 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). + + + + + + +Neuman, et al. Standards Track [Page 80] + +RFC 4120 Kerberos V5 July 2005 + + + 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 + + + +Neuman, et al. Standards Track [Page 81] + +RFC 4120 Kerberos V5 July 2005 + + + 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. + + + + +Neuman, et al. Standards Track [Page 82] + +RFC 4120 Kerberos V5 July 2005 + + + 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. + + + + + + + +Neuman, et al. Standards Track [Page 83] + +RFC 4120 Kerberos V5 July 2005 + + + 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". + + + + + + +Neuman, et al. Standards Track [Page 84] + +RFC 4120 Kerberos V5 July 2005 + + + 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. + + + + + + +Neuman, et al. Standards Track [Page 85] + +RFC 4120 Kerberos V5 July 2005 + + + 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. + + + +Neuman, et al. Standards Track [Page 86] + +RFC 4120 Kerberos V5 July 2005 + + + 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. + + + + +Neuman, et al. Standards Track [Page 87] + +RFC 4120 Kerberos V5 July 2005 + + +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. + + + +Neuman, et al. Standards Track [Page 88] + +RFC 4120 Kerberos V5 July 2005 + + + 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. + + + + +Neuman, et al. Standards Track [Page 89] + +RFC 4120 Kerberos V5 July 2005 + + + 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. + + + + +Neuman, et al. Standards Track [Page 90] + +RFC 4120 Kerberos V5 July 2005 + + +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. + + + + + + + +Neuman, et al. Standards Track [Page 91] + +RFC 4120 Kerberos V5 July 2005 + + +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 + } + + + + + +Neuman, et al. Standards Track [Page 92] + +RFC 4120 Kerberos V5 July 2005 + + + 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. + + + + + +Neuman, et al. Standards Track [Page 93] + +RFC 4120 Kerberos V5 July 2005 + + + 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, + + + +Neuman, et al. Standards Track [Page 94] + +RFC 4120 Kerberos V5 July 2005 + + + 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). + + + + + + +Neuman, et al. Standards Track [Page 95] + +RFC 4120 Kerberos V5 July 2005 + + + 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 + + + + +Neuman, et al. Standards Track [Page 96] + +RFC 4120 Kerberos V5 July 2005 + + + 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. + + + +Neuman, et al. Standards Track [Page 97] + +RFC 4120 Kerberos V5 July 2005 + + + 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 + + + +Neuman, et al. Standards Track [Page 98] + +RFC 4120 Kerberos V5 July 2005 + + + 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 + + + +Neuman, et al. Standards Track [Page 99] + +RFC 4120 Kerberos V5 July 2005 + + + 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. + + + +Neuman, et al. Standards Track [Page 100] + +RFC 4120 Kerberos V5 July 2005 + + +7. Constants and Other Defined Values + +7.1. Host Address Types + + All negative values for the host address type are reserved for local + use. All non-negative values are reserved for officially assigned + type fields and interpretations. + + Internet (IPv4) Addresses + + Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded + in MSB order (most significant byte first). The IPv4 loopback + address SHOULD NOT appear in a Kerberos PDU. The type of IPv4 + addresses is two (2). + + Internet (IPv6) Addresses + + IPv6 addresses [RFC3513] are 128-bit (16-octet) quantities, + encoded in MSB order (most significant byte first). The type of + IPv6 addresses is twenty-four (24). The following addresses MUST + NOT appear in any Kerberos PDU: + + * the Unspecified Address + * the Loopback Address + * Link-Local addresses + + This restriction applies to the inclusion in the address fields of + Kerberos PDUs, but not to the address fields of packets that might + carry such PDUs. The restriction is necessary because the use of + an address with non-global scope could allow the acceptance of a + message sent from a node that may have the same address, but which + is not the host intended by the entity that added the restriction. + If the link-local address type needs to be used for communication, + then the address restriction in tickets must not be used (i.e., + addressless tickets must be used). + + IPv4-mapped IPv6 addresses MUST be represented as addresses of + type 2. + + DECnet Phase IV Addresses + + DECnet Phase IV addresses are 16-bit addresses, encoded in LSB + order. The type of DECnet Phase IV addresses is twelve (12). + + + + + + + + +Neuman, et al. Standards Track [Page 101] + +RFC 4120 Kerberos V5 July 2005 + + + Netbios Addresses + + Netbios addresses are 16-octet addresses typically composed of 1 + to 15 alphanumeric characters and padded with the US-ASCII SPC + character (code 32). The 16th octet MUST be the US-ASCII NUL + character (code 0). The type of Netbios addresses is twenty (20). + + Directional Addresses + + Including the sender address in KRB_SAFE and KRB_PRIV messages is + undesirable in many environments because the addresses may be + changed in transport by network address translators. However, if + these addresses are removed, the messages may be subject to a + reflection attack in which a message is reflected back to its + originator. The directional address type provides a way to avoid + transport addresses and reflection attacks. Directional addresses + are encoded as four-byte unsigned integers in network byte order. + If the message is originated by the party sending the original + KRB_AP_REQ message, then an address of 0 SHOULD be used. If the + message is originated by the party to whom that KRB_AP_REQ was + sent, then the address 1 SHOULD be used. Applications involving + multiple parties can specify the use of other addresses. + + Directional addresses MUST only be used for the sender address + field in the KRB_SAFE or KRB_PRIV messages. They MUST NOT be used + as a ticket address or in a KRB_AP_REQ message. This address type + SHOULD only be used in situations where the sending party knows + that the receiving party supports the address type. This + generally means that directional addresses may only be used when + the application protocol requires their support. Directional + addresses are type (3). + +7.2. KDC Messaging: IP Transports + + Kerberos defines two IP transport mechanisms for communication + between clients and servers: UDP/IP and TCP/IP. + +7.2.1. UDP/IP transport + + Kerberos servers (KDCs) supporting IP transports MUST accept UDP + requests and SHOULD listen for them on port 88 (decimal) unless + specifically configured to listen on an alternative UDP port. + Alternate ports MAY be used when running multiple KDCs for multiple + realms on the same host. + + + + + + + +Neuman, et al. Standards Track [Page 102] + +RFC 4120 Kerberos V5 July 2005 + + + Kerberos clients supporting IP transports SHOULD support the sending + of UDP requests. Clients SHOULD use KDC discovery [7.2.3] to + identify the IP address and port to which they will send their + request. + + When contacting a KDC for a KRB_KDC_REQ request using UDP/IP + transport, the client shall send a UDP datagram containing only an + encoding of the request to the KDC. The KDC will respond with a + reply datagram containing only an encoding of the reply message + (either a KRB_ERROR or a KRB_KDC_REP) to the sending port at the + sender's IP address. The response to a request made through UDP/IP + transport MUST also use UDP/IP transport. If the response cannot be + handled using UDP (for example, because it is too large), the KDC + MUST return KRB_ERR_RESPONSE_TOO_BIG, forcing the client to retry the + request using the TCP transport. + +7.2.2. TCP/IP Transport + + Kerberos servers (KDCs) supporting IP transports MUST accept TCP + requests and SHOULD listen for them on port 88 (decimal) unless + specifically configured to listen on an alternate TCP port. + Alternate ports MAY be used when running multiple KDCs for multiple + realms on the same host. + + Clients MUST support the sending of TCP requests, but MAY choose to + try a request initially using the UDP transport. Clients SHOULD use + KDC discovery [7.2.3] to identify the IP address and port to which + they will send their request. + + Implementation note: Some extensions to the Kerberos protocol will + not succeed if any client or KDC not supporting the TCP transport is + involved. Implementations of RFC 1510 were not required to support + TCP/IP transports. + + When the KRB_KDC_REQ message is sent to the KDC over a TCP stream, + the response (KRB_KDC_REP or KRB_ERROR message) MUST be returned to + the client on the same TCP stream that was established for the + request. The KDC MAY close the TCP stream after sending a response, + but MAY leave the stream open for a reasonable period of time if it + expects a follow-up. Care must be taken in managing TCP/IP + connections on the KDC to prevent denial of service attacks based on + the number of open TCP/IP connections. + + The client MUST be prepared to have the stream closed by the KDC at + any time after the receipt of a response. A stream closure SHOULD + NOT be treated as a fatal error. Instead, if multiple exchanges are + required (e.g., certain forms of pre-authentication), the client may + need to establish a new connection when it is ready to send + + + +Neuman, et al. Standards Track [Page 103] + +RFC 4120 Kerberos V5 July 2005 + + + subsequent messages. A client MAY close the stream after receiving a + response, and SHOULD close the stream if it does not expect to send + follow-up messages. + + A client MAY send multiple requests before receiving responses, + though it must be prepared to handle the connection being closed + after the first response. + + Each request (KRB_KDC_REQ) and response (KRB_KDC_REP or KRB_ERROR) + sent over the TCP stream is preceded by the length of the request as + 4 octets in network byte order. The high bit of the length is + reserved for future expansion and MUST currently be set to zero. If + a KDC that does not understand how to interpret a set high bit of the + length encoding receives a request with the high order bit of the + length set, it MUST return a KRB-ERROR message with the error + KRB_ERR_FIELD_TOOLONG and MUST close the TCP stream. + + If multiple requests are sent over a single TCP connection and the + KDC sends multiple responses, the KDC is not required to send the + responses in the order of the corresponding requests. This may + permit some implementations to send each response as soon as it is + ready, even if earlier requests are still being processed (for + example, waiting for a response from an external device or database). + +7.2.3. KDC Discovery on IP Networks + + Kerberos client implementations MUST provide a means for the client + to determine the location of the Kerberos Key Distribution Centers + (KDCs). Traditionally, Kerberos implementations have stored such + configuration information in a file on each client machine. + Experience has shown that this method of storing configuration + information presents problems with out-of-date information and + scaling, especially when using cross-realm authentication. This + section describes a method for using the Domain Name System [RFC1035] + for storing KDC location information. + +7.2.3.1. DNS vs. Kerberos: Case Sensitivity of Realm Names + + In Kerberos, realm names are case sensitive. Although it is strongly + encouraged that all realm names be all uppercase, this recommendation + has not been adopted by all sites. Some sites use all lowercase + names and other use mixed case. DNS, on the other hand, is case + insensitive for queries. Because the realm names "MYREALM", + "myrealm", and "MyRealm" are all different, but resolve the same in + the domain name system, it is necessary that only one of the possible + combinations of upper- and lowercase characters be used in realm + names. + + + + +Neuman, et al. Standards Track [Page 104] + +RFC 4120 Kerberos V5 July 2005 + + +7.2.3.2. Specifying KDC Location Information with DNS SRV records + + KDC location information is to be stored using the DNS SRV RR + [RFC2782]. The format of this RR is as follows: + + _Service._Proto.Realm TTL Class SRV Priority Weight Port Target + + The Service name for Kerberos is always "kerberos". + + The Proto can be either "udp" or "tcp". If these SRV records are to + be used, both "udp" and "tcp" records MUST be specified for all KDC + deployments. + + The Realm is the Kerberos realm that this record corresponds to. The + realm MUST be a domain-style realm name. + + TTL, Class, SRV, Priority, Weight, and Target have the standard + meaning as defined in RFC 2782. + + As per RFC 2782, the Port number used for "_udp" and "_tcp" SRV + records SHOULD be the value assigned to "kerberos" by the Internet + Assigned Number Authority: 88 (decimal), unless the KDC is configured + to listen on an alternate TCP port. + + Implementation note: Many existing client implementations do not + support KDC Discovery and are configured to send requests to the IANA + assigned port (88 decimal), so it is strongly recommended that KDCs + be configured to listen on that port. + +7.2.3.3. KDC Discovery for Domain Style Realm Names on IP Networks + + These are DNS records for a Kerberos realm EXAMPLE.COM. It has two + Kerberos servers, kdc1.example.com and kdc2.example.com. Queries + should be directed to kdc1.example.com first as per the specified + priority. Weights are not used in these sample records. + + _kerberos._udp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. + _kerberos._udp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. + _kerberos._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. + _kerberos._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. + +7.3. Name of the TGS + + The principal identifier of the ticket-granting service shall be + composed of three parts: the realm of the KDC issuing the TGS ticket, + and a two-part name of type NT-SRV-INST, with the first part "krbtgt" + and the second part the name of the realm that will accept the TGT. + For example, a TGT issued by the ATHENA.MIT.EDU realm to be used to + + + +Neuman, et al. Standards Track [Page 105] + +RFC 4120 Kerberos V5 July 2005 + + + get tickets from the ATHENA.MIT.EDU KDC has a principal identifier of + "ATHENA.MIT.EDU" (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A TGT + issued by the ATHENA.MIT.EDU realm to be used to get tickets from the + MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU" (realm), + ("krbtgt", "MIT.EDU") (name). + +7.4. OID Arc for KerberosV5 + + This OID MAY be used to identify Kerberos protocol messages + encapsulated in other protocols. It also designates the OID arc for + KerberosV5-related OIDs assigned by future IETF action. + Implementation note: RFC 1510 had an incorrect value (5) for "dod" in + its OID. + + id-krb5 OBJECT IDENTIFIER ::= { + iso(1) identified-organization(3) dod(6) internet(1) + security(5) kerberosV5(2) + } + + Assignment of OIDs beneath the id-krb5 arc must be obtained by + contacting the registrar for the id-krb5 arc, or its designee. At + the time of the issuance of this RFC, such registrations can be + obtained by contacting krb5-oid-registrar@mit.edu. + +7.5. Protocol Constants and Associated Values + + The following tables list constants used in the protocol and define + their meanings. In the "specification" section, ranges are specified + that limit the values of constants for which values are defined here. + This allows implementations to make assumptions about the maximum + values that will be received for these constants. Implementations + receiving values outside the range specified in the "specification" + section MAY reject the request, but they MUST recover cleanly. + +7.5.1. Key Usage Numbers + + The encryption and checksum specifications in [RFC3961] require as + input a "key usage number", to alter the encryption key used in any + specific message in order to make certain types of cryptographic + attack more difficult. These are the key usage values assigned in + this document: + + 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with + the client key (Section 5.2.7.2) + + + + + + + +Neuman, et al. Standards Track [Page 106] + +RFC 4120 Kerberos V5 July 2005 + + + 2. AS-REP Ticket and TGS-REP Ticket (includes TGS session + key or application session key), encrypted with the + service key (Section 5.3) + 3. AS-REP encrypted part (includes TGS session key or + application session key), encrypted with the client key + (Section 5.4.2) + 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with + the TGS session key (Section 5.4.1) + 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with + the TGS authenticator subkey (Section 5.4.1) + 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, + keyed with the TGS session key (Section 5.5.1) + 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes + TGS authenticator subkey), encrypted with the TGS session + key (Section 5.5.1) + 8. TGS-REP encrypted part (includes application session + key), encrypted with the TGS session key (Section 5.4.2) + 9. TGS-REP encrypted part (includes application session + key), encrypted with the TGS authenticator subkey + (Section 5.4.2) + 10. AP-REQ Authenticator cksum, keyed with the application + session key (Section 5.5.1) + 11. AP-REQ Authenticator (includes application authenticator + subkey), encrypted with the application session key + (Section 5.5.1) + 12. AP-REP encrypted part (includes application session + subkey), encrypted with the application session key + (Section 5.5.2) + 13. KRB-PRIV encrypted part, encrypted with a key chosen by + the application (Section 5.7.1) + 14. KRB-CRED encrypted part, encrypted with a key chosen by + the application (Section 5.8.1) + 15. KRB-SAFE cksum, keyed with a key chosen by the + application (Section 5.6.1) + 16-18. Reserved for future use in Kerberos and related + protocols. + 19. AD-KDC-ISSUED checksum (ad-checksum in 5.2.6.4) + 20-21. Reserved for future use in Kerberos and related + protocols. + 22-25. Reserved for use in the Kerberos Version 5 GSS-API + mechanisms [RFC4121]. + 26-511. Reserved for future use in Kerberos and related + protocols. + 512-1023. Reserved for uses internal to a Kerberos implementation. + 1024. Encryption for application use in protocols that do not + specify key usage values + + + + + +Neuman, et al. Standards Track [Page 107] + +RFC 4120 Kerberos V5 July 2005 + + + 1025. Checksums for application use in protocols that do not + specify key usage values + 1026-2047. Reserved for application use. + +7.5.2. PreAuthentication Data Types + + Padata and Data Type Padata-type Comment + Value + + PA-TGS-REQ 1 + PA-ENC-TIMESTAMP 2 + PA-PW-SALT 3 + [reserved] 4 + PA-ENC-UNIX-TIME 5 (deprecated) + PA-SANDIA-SECUREID 6 + PA-SESAME 7 + PA-OSF-DCE 8 + PA-CYBERSAFE-SECUREID 9 + PA-AFS3-SALT 10 + PA-ETYPE-INFO 11 + PA-SAM-CHALLENGE 12 (sam/otp) + PA-SAM-RESPONSE 13 (sam/otp) + PA-PK-AS-REQ_OLD 14 (pkinit) + PA-PK-AS-REP_OLD 15 (pkinit) + PA-PK-AS-REQ 16 (pkinit) + PA-PK-AS-REP 17 (pkinit) + PA-ETYPE-INFO2 19 (replaces pa-etype-info) + PA-USE-SPECIFIED-KVNO 20 + PA-SAM-REDIRECT 21 (sam/otp) + PA-GET-FROM-TYPED-DATA 22 (embedded in typed data) + TD-PADATA 22 (embeds padata) + PA-SAM-ETYPE-INFO 23 (sam/otp) + PA-ALT-PRINC 24 (crawdad@fnal.gov) + PA-SAM-CHALLENGE2 30 (kenh@pobox.com) + PA-SAM-RESPONSE2 31 (kenh@pobox.com) + PA-EXTRA-TGT 41 Reserved extra TGT + TD-PKINIT-CMS-CERTIFICATES 101 CertificateSet from CMS + TD-KRB-PRINCIPAL 102 PrincipalName + TD-KRB-REALM 103 Realm + TD-TRUSTED-CERTIFIERS 104 from PKINIT + TD-CERTIFICATE-INDEX 105 from PKINIT + TD-APP-DEFINED-ERROR 106 application specific + TD-REQ-NONCE 107 INTEGER + TD-REQ-SEQ 108 INTEGER + PA-PAC-REQUEST 128 (jbrezak@exchange.microsoft.com) + + + + + + +Neuman, et al. Standards Track [Page 108] + +RFC 4120 Kerberos V5 July 2005 + + +7.5.3. Address Types + + Address Type Value + + IPv4 2 + Directional 3 + ChaosNet 5 + XNS 6 + ISO 7 + DECNET Phase IV 12 + AppleTalk DDP 16 + NetBios 20 + IPv6 24 + +7.5.4. Authorization Data Types + + Authorization Data Type Ad-type Value + + AD-IF-RELEVANT 1 + AD-INTENDED-FOR-SERVER 2 + AD-INTENDED-FOR-APPLICATION-CLASS 3 + AD-KDC-ISSUED 4 + AD-AND-OR 5 + AD-MANDATORY-TICKET-EXTENSIONS 6 + AD-IN-TICKET-EXTENSIONS 7 + AD-MANDATORY-FOR-KDC 8 + Reserved values 9-63 + OSF-DCE 64 + SESAME 65 + AD-OSF-DCE-PKI-CERTID 66 (hemsath@us.ibm.com) + AD-WIN2K-PAC 128 (jbrezak@exchange.microsoft.com) + AD-ETYPE-NEGOTIATION 129 (lzhu@windows.microsoft.com) + +7.5.5. Transited Encoding Types + + Transited Encoding Type Tr-type Value + + DOMAIN-X500-COMPRESS 1 + Reserved values All others + +7.5.6. Protocol Version Number + + Label Value Meaning or MIT Code + + pvno 5 Current Kerberos protocol version number + + + + + + +Neuman, et al. Standards Track [Page 109] + +RFC 4120 Kerberos V5 July 2005 + + +7.5.7. Kerberos Message Types + + Message Type Value Meaning + + KRB_AS_REQ 10 Request for initial authentication + KRB_AS_REP 11 Response to KRB_AS_REQ request + KRB_TGS_REQ 12 Request for authentication based on TGT + KRB_TGS_REP 13 Response to KRB_TGS_REQ request + KRB_AP_REQ 14 Application request to server + KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL + KRB_RESERVED16 16 Reserved for user-to-user krb_tgt_request + KRB_RESERVED17 17 Reserved for user-to-user krb_tgt_reply + KRB_SAFE 20 Safe (checksummed) application message + KRB_PRIV 21 Private (encrypted) application message + KRB_CRED 22 Private (encrypted) message to forward + credentials + KRB_ERROR 30 Error response + +7.5.8. Name Types + + Name Type Value Meaning + + KRB_NT_UNKNOWN 0 Name type not known + KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, + or for users + KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt) + KRB_NT_SRV_HST 3 Service with host name as instance + (telnet, rcommands) + KRB_NT_SRV_XHST 4 Service with host as remaining components + KRB_NT_UID 5 Unique ID + KRB_NT_X500_PRINCIPAL 6 Encoded X.509 Distinguished name [RFC2253] + KRB_NT_SMTP_NAME 7 Name in form of SMTP email name + (e.g., user@example.com) + KRB_NT_ENTERPRISE 10 Enterprise name; may be mapped to + principal name + +7.5.9. Error Codes + + Error Code Value Meaning + + KDC_ERR_NONE 0 No error + KDC_ERR_NAME_EXP 1 Client's entry in database + has expired + KDC_ERR_SERVICE_EXP 2 Server's entry in database + has expired + KDC_ERR_BAD_PVNO 3 Requested protocol version + number not supported + + + + +Neuman, et al. Standards Track [Page 110] + +RFC 4120 Kerberos V5 July 2005 + + + KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in + old master key + KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in + old master key + KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in + Kerberos database + KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in + Kerberos database + KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries + in database + KDC_ERR_NULL_KEY 9 The client or server has a + null key + KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for + postdating + KDC_ERR_NEVER_VALID 11 Requested starttime is + later than end time + KDC_ERR_POLICY 12 KDC policy rejects request + KDC_ERR_BADOPTION 13 KDC cannot accommodate + requested option + KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for + encryption type + KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for + checksum type + KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for + padata type + KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for + transited type + KDC_ERR_CLIENT_REVOKED 18 Clients credentials have + been revoked + KDC_ERR_SERVICE_REVOKED 19 Credentials for server have + been revoked + KDC_ERR_TGT_REVOKED 20 TGT has been revoked + KDC_ERR_CLIENT_NOTYET 21 Client not yet valid; try + again later + KDC_ERR_SERVICE_NOTYET 22 Server not yet valid; try + again later + KDC_ERR_KEY_EXPIRED 23 Password has expired; + change password to reset + KDC_ERR_PREAUTH_FAILED 24 Pre-authentication + information was invalid + KDC_ERR_PREAUTH_REQUIRED 25 Additional pre- + authentication required + KDC_ERR_SERVER_NOMATCH 26 Requested server and ticket + don't match + KDC_ERR_MUST_USE_USER2USER 27 Server principal valid for + user2user only + KDC_ERR_PATH_NOT_ACCEPTED 28 KDC Policy rejects + transited path + + + +Neuman, et al. Standards Track [Page 111] + +RFC 4120 Kerberos V5 July 2005 + + + KDC_ERR_SVC_UNAVAILABLE 29 A service is not available + KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on + decrypted field failed + KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired + KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid + KRB_AP_ERR_REPEAT 34 Request is a replay + KRB_AP_ERR_NOT_US 35 The ticket isn't for us + KRB_AP_ERR_BADMATCH 36 Ticket and authenticator + don't match + KRB_AP_ERR_SKEW 37 Clock skew too great + KRB_AP_ERR_BADADDR 38 Incorrect net address + KRB_AP_ERR_BADVERSION 39 Protocol version mismatch + KRB_AP_ERR_MSG_TYPE 40 Invalid msg type + KRB_AP_ERR_MODIFIED 41 Message stream modified + KRB_AP_ERR_BADORDER 42 Message out of order + KRB_AP_ERR_BADKEYVER 44 Specified version of key is + not available + KRB_AP_ERR_NOKEY 45 Service key not available + KRB_AP_ERR_MUT_FAIL 46 Mutual authentication + failed + KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction + KRB_AP_ERR_METHOD 48 Alternative authentication + method required + KRB_AP_ERR_BADSEQ 49 Incorrect sequence number + in message + KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of + checksum in message + KRB_AP_PATH_NOT_ACCEPTED 51 Policy rejects transited + path + KRB_ERR_RESPONSE_TOO_BIG 52 Response too big for UDP; + retry with TCP + KRB_ERR_GENERIC 60 Generic error (description + in e-text) + KRB_ERR_FIELD_TOOLONG 61 Field is too long for this + implementation + KDC_ERROR_CLIENT_NOT_TRUSTED 62 Reserved for PKINIT + KDC_ERROR_KDC_NOT_TRUSTED 63 Reserved for PKINIT + KDC_ERROR_INVALID_SIG 64 Reserved for PKINIT + KDC_ERR_KEY_TOO_WEAK 65 Reserved for PKINIT + KDC_ERR_CERTIFICATE_MISMATCH 66 Reserved for PKINIT + KRB_AP_ERR_NO_TGT 67 No TGT available to + validate USER-TO-USER + KDC_ERR_WRONG_REALM 68 Reserved for future use + KRB_AP_ERR_USER_TO_USER_REQUIRED 69 Ticket must be for + USER-TO-USER + KDC_ERR_CANT_VERIFY_CERTIFICATE 70 Reserved for PKINIT + KDC_ERR_INVALID_CERTIFICATE 71 Reserved for PKINIT + KDC_ERR_REVOKED_CERTIFICATE 72 Reserved for PKINIT + + + +Neuman, et al. Standards Track [Page 112] + +RFC 4120 Kerberos V5 July 2005 + + + KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 Reserved for PKINIT + KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 Reserved for PKINIT + KDC_ERR_CLIENT_NAME_MISMATCH 75 Reserved for PKINIT + KDC_ERR_KDC_NAME_MISMATCH 76 Reserved for PKINIT + +8. Interoperability Requirements + + Version 5 of the Kerberos protocol supports a myriad of options. + Among these are multiple encryption and checksum types; alternative + encoding schemes for the transited field; optional mechanisms for + pre-authentication; the handling of tickets with no addresses; + options for mutual authentication; user-to-user authentication; + support for proxies; the format of realm names; the handling of + authorization data; and forwarding, postdating, and renewing tickets. + + In order to ensure the interoperability of realms, it is necessary to + define a minimal configuration that must be supported by all + implementations. This minimal configuration is subject to change as + technology does. For example, if at some later date it is discovered + that one of the required encryption or checksum algorithms is not + secure, it will be replaced. + +8.1. Specification 2 + + This section defines the second specification of these options. + Implementations which are configured in this way can be said to + support Kerberos Version 5 Specification 2 (5.2). Specification 1 + (deprecated) may be found in RFC 1510. + + Transport + + TCP/IP and UDP/IP transport MUST be supported by clients and KDCs + claiming conformance to specification 2. + + Encryption and Checksum Methods + + The following encryption and checksum mechanisms MUST be + supported: + + Encryption: AES256-CTS-HMAC-SHA1-96 [RFC3962] + Checksums: HMAC-SHA1-96-AES256 [RFC3962] + + Implementations SHOULD support other mechanisms as well, but the + additional mechanisms may only be used when communicating with + principals known to also support them. The following mechanisms + from [RFC3961] and [RFC3962] SHOULD be supported: + + + + + +Neuman, et al. Standards Track [Page 113] + +RFC 4120 Kerberos V5 July 2005 + + + Encryption: AES128-CTS-HMAC-SHA1-96, DES-CBC-MD5, DES3-CBC-SHA1-KD + Checksums: DES-MD5, HMAC-SHA1-DES3-KD, HMAC-SHA1-96-AES128 + + Implementations MAY support other mechanisms as well, but the + additional mechanisms may only be used when communicating with + principals known to support them also. + + Implementation note: Earlier implementations of Kerberos generate + messages using the CRC-32 and RSA-MD5 checksum methods. For + interoperability with these earlier releases, implementors MAY + consider supporting these checksum methods but should carefully + analyze the security implications to limit the situations within + which these methods are accepted. + + Realm Names + + All implementations MUST understand hierarchical realms in both + the Internet Domain and the X.500 style. When a TGT for an + unknown realm is requested, the KDC MUST be able to determine the + names of the intermediate realms between the KDCs realm and the + requested realm. + + Transited Field Encoding + + DOMAIN-X500-COMPRESS (described in Section 3.3.3.2) MUST be + supported. Alternative encodings MAY be supported, but they may + only be used when that encoding is supported by ALL intermediate + realms. + + Pre-authentication Methods + + The TGS-REQ method MUST be supported. It is not used on the + initial request. The PA-ENC-TIMESTAMP method MUST be supported by + clients, but whether it is enabled by default MAY be determined on + a realm-by-realm basis. If the method is not used in the initial + request and the error KDC_ERR_PREAUTH_REQUIRED is returned + specifying PA-ENC-TIMESTAMP as an acceptable method, the client + SHOULD retry the initial request using the PA-ENC-TIMESTAMP pre- + authentication method. Servers need not support the PA-ENC- + TIMESTAMP method, but if it is not supported the server SHOULD + ignore the presence of PA-ENC-TIMESTAMP pre-authentication in a + request. + + The ETYPE-INFO2 method MUST be supported; this method is used to + communicate the set of supported encryption types, and + corresponding salt and string to key parameters. The ETYPE-INFO + method SHOULD be supported for interoperability with older + implementation. + + + +Neuman, et al. Standards Track [Page 114] + +RFC 4120 Kerberos V5 July 2005 + + + Mutual Authentication + + Mutual authentication (via the KRB_AP_REP message) MUST be + supported. + + Ticket Addresses and Flags + + All KDCs MUST pass through tickets that carry no addresses (i.e., + if a TGT contains no addresses, the KDC will return derivative + tickets). Implementations SHOULD default to requesting + addressless tickets, as this significantly increases + interoperability with network address translation. In some cases, + realms or application servers MAY require that tickets have an + address. + + Implementations SHOULD accept directional address type for the + KRB_SAFE and KRB_PRIV message and SHOULD include directional + addresses in these messages when other address types are not + available. + + Proxies and forwarded tickets MUST be supported. Individual + realms and application servers can set their own policy on when + such tickets will be accepted. + + All implementations MUST recognize renewable and postdated + tickets, but they need not actually implement them. If these + options are not supported, the starttime and endtime in the ticket + SHALL specify a ticket's entire useful life. When a postdated + ticket is decoded by a server, all implementations SHALL make the + presence of the postdated flag visible to the calling server. + + User-to-User Authentication + + Support for user-to-user authentication (via the ENC-TKT-IN-SKEY + KDC option) MUST be provided by implementations, but individual + realms MAY decide as a matter of policy to reject such requests on + a per-principal or realm-wide basis. + + Authorization Data + + Implementations MUST pass all authorization data subfields from + TGTs to any derivative tickets unless they are directed to + suppress a subfield as part of the definition of that registered + subfield type. (It is never incorrect to pass on a subfield, and + no registered subfield types presently specify suppression at the + KDC.) + + + + + +Neuman, et al. Standards Track [Page 115] + +RFC 4120 Kerberos V5 July 2005 + + + Implementations MUST make the contents of any authorization data + subfields available to the server when a ticket is used. + Implementations are not required to allow clients to specify the + contents of the authorization data fields. + + Constant Ranges + + All protocol constants are constrained to 32-bit (signed) values + unless further constrained by the protocol definition. This limit + is provided to allow implementations to make assumptions about the + maximum values that will be received for these constants. + Implementations receiving values outside this range MAY reject the + request, but they MUST recover cleanly. + +8.2. Recommended KDC Values + + Following is a list of recommended values for a KDC configuration. + + Minimum lifetime 5 minutes + Maximum renewable lifetime 1 week + Maximum ticket lifetime 1 day + Acceptable clock skew 5 minutes + Empty addresses Allowed + Proxiable, etc. Allowed + +9. IANA Considerations + + Section 7 of this document specifies protocol constants and other + defined values required for the interoperability of multiple + implementations. Until a subsequent RFC specifies otherwise, or the + Kerberos working group is shut down, allocations of additional + protocol constants and other defined values required for extensions + to the Kerberos protocol will be administered by the Kerberos working + group. Following the recommendations outlined in [RFC2434], guidance + is provided to the IANA as follows: + + "reserved" realm name types in Section 6.1 and "other" realm types + except those beginning with "X-" or "x-" will not be registered + without IETF standards action, at which point guidelines for further + assignment will be specified. Realm name types beginning with "X-" + or "x-" are for private use. + + For host address types described in Section 7.1, negative values are + for private use. Assignment of additional positive numbers is + subject to review by the Kerberos working group or other expert + review. + + + + + +Neuman, et al. Standards Track [Page 116] + +RFC 4120 Kerberos V5 July 2005 + + + Additional key usage numbers, as defined in Section 7.5.1, will be + assigned subject to review by the Kerberos working group or other + expert review. + + Additional preauthentication data type values, as defined in section + 7.5.2, will be assigned subject to review by the Kerberos working + group or other expert review. + + Additional authorization data types as defined in Section 7.5.4, will + be assigned subject to review by the Kerberos working group or other + expert review. Although it is anticipated that there may be + significant demand for private use types, provision is intentionally + not made for a private use portion of the namespace because conflicts + between privately assigned values could have detrimental security + implications. + + Additional transited encoding types, as defined in Section 7.5.5, + present special concerns for interoperability with existing + implementations. As such, such assignments will only be made by + standards action, except that the Kerberos working group or another + other working group with competent jurisdiction may make preliminary + assignments for documents that are moving through the standards + process. + + Additional Kerberos message types, as described in Section 7.5.7, + will be assigned subject to review by the Kerberos working group or + other expert review. + + Additional name types, as described in Section 7.5.8, will be + assigned subject to review by the Kerberos working group or other + expert review. + + Additional error codes described in Section 7.5.9 will be assigned + subject to review by the Kerberos working group or other expert + review. + +10. Security Considerations + + As an authentication service, Kerberos provides a means of verifying + the identity of principals on a network. By itself, Kerberos does + not provide authorization. Applications should not accept the + issuance of a service ticket by the Kerberos server as granting + authority to use the service, since such applications may become + vulnerable to the bypass of this authorization check in an + environment where they inter-operate with other KDCs or where other + options for application authentication are provided. + + + + + +Neuman, et al. Standards Track [Page 117] + +RFC 4120 Kerberos V5 July 2005 + + + Denial of service attacks are not solved with Kerberos. There are + places in the protocols where an intruder can prevent an application + from participating in the proper authentication steps. Because + authentication is a required step for the use of many services, + successful denial of service attacks on a Kerberos server might + result in the denial of other network services that rely on Kerberos + for authentication. Kerberos is vulnerable to many kinds of denial + of service attacks: those on the network, which would prevent clients + from contacting the KDC; those on the domain name system, which could + prevent a client from finding the IP address of the Kerberos server; + and those by overloading the Kerberos KDC itself with repeated + requests. + + Interoperability conflicts caused by incompatible character-set usage + (see 5.2.1) can result in denial of service for clients that utilize + character-sets in Kerberos strings other than those stored in the KDC + database. + + Authentication servers maintain a database of principals (i.e., users + and servers) and their secret keys. The security of the + authentication server machines is critical. The breach of security + of an authentication server will compromise the security of all + servers that rely upon the compromised KDC, and will compromise the + authentication of any principals registered in the realm of the + compromised KDC. + + Principals must keep their secret keys secret. If an intruder + somehow steals a principal's key, it will be able to masquerade as + that principal or impersonate any server to the legitimate principal. + + Password-guessing attacks are not solved by Kerberos. If a user + chooses a poor password, it is possible for an attacker to + successfully mount an off-line dictionary attack by repeatedly + attempting to decrypt, with successive entries from a dictionary, + messages obtained that are encrypted under a key derived from the + user's password. + + Unless pre-authentication options are required by the policy of a + realm, the KDC will not know whether a request for authentication + succeeds. An attacker can request a reply with credentials for any + principal. These credentials will likely not be of much use to the + attacker unless it knows the client's secret key, but the + availability of the response encrypted in the client's secret key + provides the attacker with ciphertext that may be used to mount brute + force or dictionary attacks to decrypt the credentials, by guessing + the user's password. For this reason it is strongly encouraged that + Kerberos realms require the use of pre-authentication. Even with + + + + +Neuman, et al. Standards Track [Page 118] + +RFC 4120 Kerberos V5 July 2005 + + + pre-authentication, attackers may try brute force or dictionary + attacks against credentials that are observed by eavesdropping on the + network. + + Because a client can request a ticket for any server principal and + can attempt a brute force or dictionary attack against the server + principal's key using that ticket, it is strongly encouraged that + keys be randomly generated (rather than generated from passwords) for + any principals that are usable as the target principal for a + KRB_TGS_REQ or KRB_AS_REQ messages. [RFC4086] + + Although the DES-CBC-MD5 encryption method and DES-MD5 checksum + methods are listed as SHOULD be implemented for backward + compatibility, the single DES encryption algorithm on which these are + based is weak, and stronger algorithms should be used whenever + possible. + + Each host on the network must have a clock that is loosely + synchronized to the time of the other hosts; this synchronization is + used to reduce the bookkeeping needs of application servers when they + do replay detection. The degree of "looseness" can be configured on + a per-server basis, but it is typically on the order of 5 minutes. + If the clocks are synchronized over the network, the clock + synchronization protocol MUST itself be secured from network + attackers. + + Principal identifiers must not recycled on a short-term basis. A + typical mode of access control will use access control lists (ACLs) + to grant permissions to particular principals. If a stale ACL entry + remains for a deleted principal and the principal identifier is + reused, the new principal will inherit rights specified in the stale + ACL entry. By not reusing principal identifiers, the danger of + inadvertent access is removed. + + Proper decryption of an KRB_AS_REP message from the KDC is not + sufficient for the host to verify the identity of the user; the user + and an attacker could cooperate to generate a KRB_AS_REP format + message that decrypts properly but is not from the proper KDC. To + authenticate a user logging on to a local system, the credentials + obtained in the AS exchange may first be used in a TGS exchange to + obtain credentials for a local server. Those credentials must then + be verified by a local server through successful completion of the + Client/Server exchange. + + Many RFC 1510-compliant implementations ignore unknown authorization + data elements. Depending on these implementations to honor + authorization data restrictions may create a security weakness. + + + + +Neuman, et al. Standards Track [Page 119] + +RFC 4120 Kerberos V5 July 2005 + + + Kerberos credentials contain clear-text information identifying the + principals to which they apply. If privacy of this information is + needed, this exchange should itself be encapsulated in a protocol + providing for confidentiality on the exchange of these credentials. + + Applications must take care to protect communications subsequent to + authentication, either by using the KRB_PRIV or KRB_SAFE messages as + appropriate, or by applying their own confidentiality or integrity + mechanisms on such communications. Completion of the KRB_AP_REQ and + KRB_AP_REP exchange without subsequent use of confidentiality and + integrity mechanisms provides only for authentication of the parties + to the communication and not confidentiality and integrity of the + subsequent communication. Applications applying confidentiality and + integrity protection mechanisms other than KRB_PRIV and KRB_SAFE must + make sure that the authentication step is appropriately linked with + the protected communication channel that is established by the + application. + + Unless the application server provides its own suitable means to + protect against replay (for example, a challenge-response sequence + initiated by the server after authentication, or use of a server- + generated encryption subkey), the server must utilize a replay cache + to remember any authenticator presented within the allowable clock + skew. All services sharing a key need to use the same replay cache. + If separate replay caches are used, then an authenticator used with + one such service could later be replayed to a different service with + the same service principal. + + If a server loses track of authenticators presented within the + allowable clock skew, it must reject all requests until the clock + skew interval has passed, providing assurance that any lost or + replayed authenticators will fall outside the allowable clock skew + and can no longer be successfully replayed. + + Implementations of Kerberos should not use untrusted directory + servers to determine the realm of a host. To allow this would allow + the compromise of the directory server to enable an attacker to + direct the client to accept authentication with the wrong principal + (i.e., one with a similar name, but in a realm with which the + legitimate host was not registered). + + Implementations of Kerberos must not use DNS to map one name to + another (canonicalize) in order to determine the host part of the + principal name with which one is to communicate. To allow this + canonicalization would allow a compromise of the DNS to result in a + client obtaining credentials and correctly authenticating to the + + + + + +Neuman, et al. Standards Track [Page 120] + +RFC 4120 Kerberos V5 July 2005 + + + wrong principal. Though the client will know who it is communicating + with, it will not be the principal with which it intended to + communicate. + + If the Kerberos server returns a TGT for a realm 'closer' than the + desired realm, the client may use local policy configuration to + verify that the authentication path used is an acceptable one. + Alternatively, a client may choose its own authentication path rather + than rely on the Kerberos server to select one. In either case, any + policy or configuration information used to choose or validate + authentication paths, whether by the Kerberos server or client, must + be obtained from a trusted source. + + The Kerberos protocol in its basic form does not provide perfect + forward secrecy for communications. If traffic has been recorded by + an eavesdropper, then messages encrypted using the KRB_PRIV message, + or messages encrypted using application-specific encryption under + keys exchanged using Kerberos can be decrypted if the user's, + application server's, or KDC's key is subsequently discovered. This + is because the session key used to encrypt such messages, when + transmitted over the network, is encrypted in the key of the + application server. It is also encrypted under the session key from + the user's TGT when it is returned to the user in the KRB_TGS_REP + message. The session key from the TGT is sent to the user in the + KRB_AS_REP message encrypted in the user's secret key and embedded in + the TGT, which was encrypted in the key of the KDC. Applications + requiring perfect forward secrecy must exchange keys through + mechanisms that provide such assurance, but may use Kerberos for + authentication of the encrypted channel established through such + other means. + +11. Acknowledgements + + This document is a revision to RFC 1510 which was co-authored with + John Kohl. The specification of the Kerberos protocol described in + this document is the result of many years of effort. Over this + period, many individuals have contributed to the definition of the + protocol and to the writing of the specification. Unfortunately, it + is not possible to list all contributors as authors of this document, + though there are many not listed who are authors in spirit, including + those who contributed text for parts of some sections, who + contributed to the design of parts of the protocol, and who + contributed significantly to the discussion of the protocol in the + IETF common authentication technology (CAT) and Kerberos working + groups. + + + + + + +Neuman, et al. Standards Track [Page 121] + +RFC 4120 Kerberos V5 July 2005 + + + Among those contributing to the development and specification of + Kerberos were Jeffrey Altman, John Brezak, Marc Colan, Johan + Danielsson, Don Davis, Doug Engert, Dan Geer, Paul Hill, John Kohl, + Marc Horowitz, Matt Hur, Jeffrey Hutzelman, Paul Leach, John Linn, + Ari Medvinsky, Sasha Medvinsky, Steve Miller, Jon Rochlis, Jerome + Saltzer, Jeffrey Schiller, Jennifer Steiner, Ralph Swick, Mike Swift, + Jonathan Trostle, Theodore Ts'o, Brian Tung, Jacques Vidrine, Assar + Westerlund, and Nicolas Williams. Many other members of MIT Project + Athena, the MIT networking group, and the Kerberos and CAT working + groups of the IETF contributed but are not listed. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Neuman, et al. Standards Track [Page 122] + +RFC 4120 Kerberos V5 July 2005 + + +A. ASN.1 module + +KerberosV5Spec2 { + iso(1) identified-organization(3) dod(6) internet(1) + security(5) kerberosV5(2) modules(4) krb5spec2(2) +} DEFINITIONS EXPLICIT TAGS ::= BEGIN + +-- OID arc for KerberosV5 +-- +-- This OID may be used to identify Kerberos protocol messages +-- encapsulated in other protocols. +-- +-- This OID also designates the OID arc for KerberosV5-related OIDs. +-- +-- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its OID. +id-krb5 OBJECT IDENTIFIER ::= { + iso(1) identified-organization(3) dod(6) internet(1) + security(5) kerberosV5(2) +} + +Int32 ::= INTEGER (-2147483648..2147483647) + -- signed values representable in 32 bits + +UInt32 ::= INTEGER (0..4294967295) + -- unsigned 32 bit values + +Microseconds ::= INTEGER (0..999999) + -- microseconds + +KerberosString ::= GeneralString (IA5String) + +Realm ::= KerberosString + +PrincipalName ::= SEQUENCE { + name-type [0] Int32, + name-string [1] SEQUENCE OF KerberosString +} + +KerberosTime ::= GeneralizedTime -- with no fractional seconds + +HostAddress ::= SEQUENCE { + addr-type [0] Int32, + address [1] OCTET STRING +} + +-- NOTE: HostAddresses is always used as an OPTIONAL field and +-- should not be empty. +HostAddresses -- NOTE: subtly different from rfc1510, + + + +Neuman, et al. Standards Track [Page 123] + +RFC 4120 Kerberos V5 July 2005 + + + -- but has a value mapping and encodes the same + ::= SEQUENCE OF HostAddress + +-- NOTE: AuthorizationData is always used as an OPTIONAL field and +-- should not be empty. +AuthorizationData ::= SEQUENCE OF SEQUENCE { + ad-type [0] Int32, + ad-data [1] OCTET STRING +} + +PA-DATA ::= SEQUENCE { + -- NOTE: first tag is [1], not [0] + padata-type [1] Int32, + padata-value [2] OCTET STRING -- might be encoded AP-REQ +} + +KerberosFlags ::= BIT STRING (SIZE (32..MAX)) + -- minimum number of bits shall be sent, + -- but no fewer than 32 + +EncryptedData ::= SEQUENCE { + etype [0] Int32 -- EncryptionType --, + kvno [1] UInt32 OPTIONAL, + cipher [2] OCTET STRING -- ciphertext +} + +EncryptionKey ::= SEQUENCE { + keytype [0] Int32 -- actually encryption type --, + keyvalue [1] OCTET STRING +} + +Checksum ::= SEQUENCE { + cksumtype [0] Int32, + checksum [1] OCTET STRING +} + +Ticket ::= [APPLICATION 1] SEQUENCE { + tkt-vno [0] INTEGER (5), + realm [1] Realm, + sname [2] PrincipalName, + enc-part [3] EncryptedData -- EncTicketPart +} + +-- Encrypted part of ticket +EncTicketPart ::= [APPLICATION 3] SEQUENCE { + flags [0] TicketFlags, + key [1] EncryptionKey, + crealm [2] Realm, + + + +Neuman, et al. Standards Track [Page 124] + +RFC 4120 Kerberos V5 July 2005 + + + cname [3] PrincipalName, + transited [4] TransitedEncoding, + authtime [5] KerberosTime, + starttime [6] KerberosTime OPTIONAL, + endtime [7] KerberosTime, + renew-till [8] KerberosTime OPTIONAL, + caddr [9] HostAddresses OPTIONAL, + authorization-data [10] AuthorizationData OPTIONAL +} + +-- encoded Transited field +TransitedEncoding ::= SEQUENCE { + tr-type [0] Int32 -- must be registered --, + contents [1] OCTET STRING +} + +TicketFlags ::= KerberosFlags + -- reserved(0), + -- forwardable(1), + -- forwarded(2), + -- proxiable(3), + -- proxy(4), + -- may-postdate(5), + -- postdated(6), + -- invalid(7), + -- renewable(8), + -- initial(9), + -- pre-authent(10), + -- hw-authent(11), +-- the following are new since 1510 + -- transited-policy-checked(12), + -- ok-as-delegate(13) + +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, + + + +Neuman, et al. Standards Track [Page 125] + +RFC 4120 Kerberos V5 July 2005 + + + 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) + +AS-REP ::= [APPLICATION 11] KDC-REP + +TGS-REP ::= [APPLICATION 13] KDC-REP + + + + +Neuman, et al. Standards Track [Page 126] + +RFC 4120 Kerberos V5 July 2005 + + +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 +} + +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), + + + +Neuman, et al. Standards Track [Page 127] + +RFC 4120 Kerberos V5 July 2005 + + + -- mutual-required(2) + +-- 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 +} + +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 +} + +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 +} + +KRB-PRIV ::= [APPLICATION 21] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (21), + -- NOTE: there is no [2] tag + + + +Neuman, et al. Standards Track [Page 128] + +RFC 4120 Kerberos V5 July 2005 + + + 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 +} + +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 +} + +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, + + + +Neuman, et al. Standards Track [Page 129] + +RFC 4120 Kerberos V5 July 2005 + + + 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 +} + +METHOD-DATA ::= SEQUENCE OF PA-DATA + +TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { + data-type [0] Int32, + data-value [1] OCTET STRING OPTIONAL +} + +-- preauth stuff follows + +PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC + +PA-ENC-TS-ENC ::= SEQUENCE { + patimestamp [0] KerberosTime -- client's time --, + pausec [1] Microseconds OPTIONAL +} + +ETYPE-INFO-ENTRY ::= SEQUENCE { + etype [0] Int32, + salt [1] OCTET STRING OPTIONAL +} + +ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY + +ETYPE-INFO2-ENTRY ::= SEQUENCE { + etype [0] Int32, + salt [1] KerberosString OPTIONAL, + s2kparams [2] OCTET STRING OPTIONAL +} + +ETYPE-INFO2 ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY + +AD-IF-RELEVANT ::= AuthorizationData + +AD-KDCIssued ::= SEQUENCE { + ad-checksum [0] Checksum, + i-realm [1] Realm OPTIONAL, + i-sname [2] PrincipalName OPTIONAL, + elements [3] AuthorizationData + + + +Neuman, et al. Standards Track [Page 130] + +RFC 4120 Kerberos V5 July 2005 + + +} + +AD-AND-OR ::= SEQUENCE { + condition-count [0] Int32, + elements [1] AuthorizationData +} + +AD-MANDATORY-FOR-KDC ::= AuthorizationData + +END + +B. Changes since RFC 1510 + + This document replaces RFC 1510 and clarifies specification of items + that were not completely specified. Where changes to recommended + implementation choices were made, or where new options were added, + those changes are described within the document and listed in this + section. More significantly, "Specification 2" in Section 8 changes + the required encryption and checksum methods to bring them in line + with the best current practices and to deprecate methods that are no + longer considered sufficiently strong. + + Discussion was added to Section 1 regarding the ability to rely on + the KDC to check the transited field, and on the inclusion of a flag + in a ticket indicating that this check has occurred. This is a new + capability not present in RFC 1510. Pre-existing implementations may + ignore or not set this flag without negative security implications. + + The definition of the secret key says that in the case of a user the + key may be derived from a password. In RFC 1510, it said that the + key was derived from the password. This change was made to + accommodate situations where the user key might be stored on a + smart-card, or otherwise obtained independently of a password. + + The introduction mentions the use of public key cryptography for + initial authentication in Kerberos by reference. RFC 1510 did not + include such a reference. + + Section 1.3 was added to explain that while Kerberos provides + authentication of a named principal, it is still the responsibility + of the application to ensure that the authenticated name is the + entity with which the application wishes to communicate. + + Discussion of extensibility has been added to the introduction. + + Discussion of how extensibility affects ticket flags and KDC options + was added to the introduction of Section 2. No changes were made to + existing options and flags specified in RFC 1510, though some of the + + + +Neuman, et al. Standards Track [Page 131] + +RFC 4120 Kerberos V5 July 2005 + + + sections in the specification were renumbered, and text was revised + to make the description and intent of existing options clearer, + especially with respect to the ENC-TKT-IN-SKEY option (now section + 2.9.2) which is used for user-to-user authentication. The new option + and ticket flag transited policy checking (Section 2.7) was added. + + A warning regarding generation of session keys for application use + was added to Section 3, urging the inclusion of key entropy from the + KDC generated session key in the ticket. An example regarding use of + the sub-session key was added to Section 3.2.6. Descriptions of the + pa-etype-info, pa-etype-info2, and pa-pw-salt pre-authentication data + items were added. The recommendation for use of pre-authentication + was changed from "MAY" to "SHOULD" and a note was added regarding + known plaintext attacks. + + In RFC 1510, Section 4 described the database in the KDC. This + discussion was not necessary for interoperability and unnecessarily + constrained implementation. The old Section 4 was removed. + + The current Section 4 was formerly Section 6 on encryption and + checksum specifications. The major part of this section was brought + up to date to support new encryption methods, and moved to a separate + document. Those few remaining aspects of the encryption and checksum + specification specific to Kerberos are now specified in Section 4. + + Significant changes were made to the layout of Section 5 to clarify + the correct behavior for optional fields. Many of these changes were + made necessary because of improper ASN.1 description in the original + Kerberos specification which left the correct behavior + underspecified. Additionally, the wording in this section was + tightened wherever possible to ensure that implementations conforming + to this specification will be extensible with the addition of new + fields in future specifications. + + Text was added describing time_t=0 issues in the ASN.1. Text was + also added, clarifying issues with implementations treating omitted + optional integers as zero. Text was added clarifying behavior for + optional SEQUENCE or SEQUENCE OF that may be empty. Discussion was + added regarding sequence numbers and behavior of some + implementations, including "zero" behavior and negative numbers. A + compatibility note was added regarding the unconditional sending of + EncTGSRepPart regardless of the enclosing reply type. Minor changes + were made to the description of the HostAddresses type. Integer + types were constrained. KerberosString was defined as a + (significantly) constrained GeneralString. KerberosFlags was defined + to reflect existing implementation behavior that departs from the + + + + + +Neuman, et al. Standards Track [Page 132] + +RFC 4120 Kerberos V5 July 2005 + + + definition in RFC 1510. The transited-policy-checked(12) and the + ok-as-delegate(13) ticket flags were added. The disable-transited- + check(26) KDC option was added. + + Descriptions of commonly implemented PA-DATA were added to Section 5. + The description of KRB-SAFE has been updated to note the existing + implementation behavior of double-encoding. + + There were two definitions of METHOD-DATA in RFC 1510. The second + one, intended for use with KRB_AP_ERR_METHOD was removed leaving the + SEQUENCE OF PA-DATA definition. + + Section 7, naming constraints, from RFC 1510 was moved to Section 6. + + Words were added describing the convention that domain-based realm + names for newly-created realms should be specified as uppercase. + This recommendation does not make lowercase realm names illegal. + Words were added highlighting that the slash-separated components in + the X.500 style of realm names is consistent with existing RFC 1510 + based implementations, but that it conflicts with the general + recommendation of X.500 name representation specified in RFC 2253. + + Section 8, network transport, constants and defined values, from RFC + 1510 was moved to Section 7. Since RFC 1510, the definition of the + TCP transport for Kerberos messages was added, and the encryption and + checksum number assignments have been moved into a separate document. + + "Specification 2" in Section 8 of the current document changes the + required encryption and checksum methods to bring them in line with + the best current practices and to deprecate methods that are no + longer considered sufficiently strong. + + Two new sections, on IANA considerations and security considerations + were added. + + The pseudo-code has been removed from the appendix. The pseudo-code + was sometimes misinterpreted to limit implementation choices and in + RFC 1510, it was not always consistent with the words in the + specification. Effort was made to clear up any ambiguities in the + specification, rather than to rely on the pseudo-code. + + An appendix was added containing the complete ASN.1 module drawn from + the discussion in Section 5 of the current document. + +END NOTES + + (*TM) Project Athena, Athena, and Kerberos are trademarks of the + Massachusetts Institute of Technology (MIT). + + + +Neuman, et al. Standards Track [Page 133] + +RFC 4120 Kerberos V5 July 2005 + + +Normative References + + [RFC3961] Raeburn, K., "Encryption and Checksum + Specifications for Kerberos 5", RFC 3961, February + 2005. + + [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) + Encryption for Kerberos 5", RFC 3962, February + 2005. + + [ISO-646/ECMA-6] International Organization for Standardization, + "7-bit Coded Character Set for Information + Interchange", ISO/IEC 646:1991. + + [ISO-2022/ECMA-35] International Organization for Standardization, + "Character code structure and extension + techniques", ISO/IEC 2022:1994. + + [RFC1035] Mockapetris, P., "Domain names - implementation + and specification", STD 13, RFC 1035, November + 1987. + + [RFC2119] Bradner, S., "Key words for use in RFCs to + Indicate Requirement Levels", BCP 14, RFC 2119, + March 1997. + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for + Writing an IANA Considerations Section in RFCs", + BCP 26, RFC 2434, October 1998. + + [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS + RR for specifying the location of services (DNS + SRV)", RFC 2782, February 2000. + + [RFC2253] Wahl, M., Kille, S., and T. Howes, "Lightweight + Directory Access Protocol (v3): UTF-8 String + Representation of Distinguished Names", RFC 2253, + December 1997. + + [RFC3513] Hinden, R. and S. Deering, "Internet Protocol + Version 6 (IPv6) Addressing Architecture", RFC + 3513, April 2003. + + [X680] Abstract Syntax Notation One (ASN.1): + Specification of Basic Notation, ITU-T + Recommendation X.680 (1997) | ISO/IEC + International Standard 8824-1:1998. + + + + +Neuman, et al. Standards Track [Page 134] + +RFC 4120 Kerberos V5 July 2005 + + + [X690] ASN.1 encoding rules: Specification of Basic + Encoding Rules (BER), Canonical Encoding Rules + (CER) and Distinguished Encoding Rules (DER), + ITU-T Recommendation X.690 (1997)| ISO/IEC + International Standard 8825-1:1998. + +Informative References + + [ISO-8859] International Organization for Standardization, + "8-bit Single-byte Coded Graphic Character Sets -- + Latin Alphabet", ISO/IEC 8859. + + [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API + Mechanism", RFC 1964, June 1996. + + [DGT96] Don Davis, Daniel Geer, and Theodore Ts'o, + "Kerberos With Clocks Adrift: History, Protocols, + and Implementation", USENIX Computing Systems 9:1, + January 1996. + + [DS81] Dorothy E. Denning and Giovanni Maria Sacco, + "Time-stamps in Key Distribution Protocols," + Communications of the ACM, Vol. 24 (8), p. 533- + 536, August 1981. + + [KNT94] John T. Kohl, B. Clifford Neuman, and Theodore Y. + Ts'o, "The Evolution of the Kerberos + Authentication System". In Distributed Open + Systems, pages 78-94. IEEE Computer Society Press, + 1994. + + [MNSS87] S. P. Miller, B. C. Neuman, J. I. Schiller, and J. + H. Saltzer, Section E.2.1: Kerberos Authentication + and Authorization System, M.I.T. Project Athena, + Cambridge, Massachusetts, December 21, 1987. + + [NS78] Roger M. Needham and Michael D. Schroeder, "Using + Encryption for Authentication in Large Networks of + Computers," Communications of the ACM, Vol. 21 + (12), pp. 993-999, December 1978. + + [Neu93] B. Clifford Neuman, "Proxy-Based Authorization and + Accounting for Distributed Systems," in + Proceedings of the 13th International Conference + on Distributed Computing Systems, Pittsburgh, PA, + May 1993. + + + + + +Neuman, et al. Standards Track [Page 135] + +RFC 4120 Kerberos V5 July 2005 + + + [NT94] B. Clifford Neuman and Theodore Y. Ts'o, "An + Authentication Service for Computer Networks," + IEEE Communications Magazine, Vol. 32 (9), p. 33- + 38, September 1994. + + [Pat92] J. Pato, Using Pre-Authentication to Avoid + Password Guessing Attacks, Open Software + Foundation DCE Request for Comments 26 (December + 1992. + + [RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network + Authentication Service (V5)", RFC 1510, September + 1993. + + [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, + RFC 4086, June 2005. + + [SNS88] J. G. Steiner, B. C. Neuman, and J. I. Schiller, + "Kerberos: An Authentication Service for Open + Network Systems," p. 191-202, Usenix Conference + Proceedings, Dallas, Texas, February 1988. + + [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The + Kerberos Version 5 Generic Security Service + Application Program Interface (GSS-API) Mechanism: + Version 2", RFC 4121, July 2005. + + + + + + + + + + + + + + + + + + + + + + + + +Neuman, et al. Standards Track [Page 136] + +RFC 4120 Kerberos V5 July 2005 + + +Authors' Addresses + + Clifford Neuman + Information Sciences Institute + University of Southern California + 4676 Admiralty Way + Marina del Rey, CA 90292, USA + + EMail: bcn@isi.edu + + + Tom Yu + Massachusetts Institute of Technology + 77 Massachusetts Avenue + Cambridge, MA 02139, USA + + EMail: tlyu@mit.edu + + + Sam Hartman + Massachusetts Institute of Technology + 77 Massachusetts Avenue + Cambridge, MA 02139, USA + + EMail: hartmans-ietf@mit.edu + + + Kenneth Raeburn + Massachusetts Institute of Technology + 77 Massachusetts Avenue + Cambridge, MA 02139, USA + + EMail: raeburn@mit.edu + + + + + + + + + + + + + + + + + + +Neuman, et al. Standards Track [Page 137] + +RFC 4120 Kerberos V5 July 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Neuman, et al. Standards Track [Page 138] + diff --git a/doc/krb5-protocol/rfc4121.txt b/doc/krb5-protocol/rfc4121.txt new file mode 100644 index 000000000..b4115143f --- /dev/null +++ b/doc/krb5-protocol/rfc4121.txt @@ -0,0 +1,1123 @@ + + + + + + +Network Working Group L. Zhu +Request for Comments: 4121 K. Jaganathan +Updates: 1964 Microsoft +Category: Standards Track S. Hartman + MIT + July 2005 + + + The Kerberos Version 5 + Generic Security Service Application Program Interface (GSS-API) + Mechanism: Version 2 + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document defines protocols, procedures, and conventions to be + employed by peers implementing the Generic Security Service + Application Program Interface (GSS-API) when using the Kerberos + Version 5 mechanism. + + RFC 1964 is updated and incremental changes are proposed in response + to recent developments such as the introduction of Kerberos + cryptosystem framework. These changes support the inclusion of new + cryptosystems, by defining new per-message tokens along with their + encryption and checksum algorithms based on the cryptosystem + profiles. + + + + + + + + + + + + + + +Zhu, et al. Standards Track [Page 1] + +RFC 4121 Kerberos Version 5 GSS-API July 2005 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Key Derivation for Per-Message Tokens ...........................4 + 3. Quality of Protection ...........................................4 + 4. Definitions and Token Formats ...................................5 + 4.1. Context Establishment Tokens ...............................5 + 4.1.1. Authenticator Checksum ..............................6 + 4.2. Per-Message Tokens .........................................9 + 4.2.1. Sequence Number .....................................9 + 4.2.2. Flags Field .........................................9 + 4.2.3. EC Field ...........................................10 + 4.2.4. Encryption and Checksum Operations .................10 + 4.2.5. RRC Field ..........................................11 + 4.2.6. Message Layouts ....................................12 + 4.3. Context Deletion Tokens ...................................13 + 4.4. Token Identifier Assignment Considerations ................13 + 5. Parameter Definitions ..........................................14 + 5.1. Minor Status Codes ........................................14 + 5.1.1. Non-Kerberos-specific Codes ........................14 + 5.1.2. Kerberos-specific Codes ............................15 + 5.2. Buffer Sizes ..............................................15 + 6. Backwards Compatibility Considerations .........................15 + 7. Security Considerations ........................................16 + 8. Acknowledgements................................................17 + 9. References .....................................................18 + 9.1. Normative References ......................................18 + 9.2. Informative References ....................................18 + +1. Introduction + + [RFC3961] defines a generic framework for describing encryption and + checksum types to be used with the Kerberos protocol and associated + protocols. + + [RFC1964] describes the GSS-API mechanism for Kerberos Version 5. It + defines the format of context establishment, per-message and context + deletion tokens, and uses algorithm identifiers for each cryptosystem + in per-message and context deletion tokens. + + The approach taken in this document obviates the need for algorithm + identifiers. This is accomplished by using the same encryption + algorithm, specified by the crypto profile [RFC3961] for the session + key or subkey that is created during context negotiation, and its + required checksum algorithm. Message layouts of the per-message + tokens are therefore revised to remove algorithm indicators and to + add extra information to support the generic crypto framework + [RFC3961]. + + + +Zhu, et al. Standards Track [Page 2] + +RFC 4121 Kerberos Version 5 GSS-API July 2005 + + + Tokens transferred between GSS-API peers for security context + establishment are also described in this document. The data elements + exchanged between a GSS-API endpoint implementation and the Kerberos + Key Distribution Center (KDC) [RFC4120] are not specific to GSS-API + usage and are therefore defined within [RFC4120] rather than this + specification. + + The new token formats specified in this document MUST be used with + all "newer" encryption types [RFC4120] and MAY be used with + encryption types that are not "newer", provided that the initiator + and acceptor know from the context establishment that they can both + process these new token formats. + + "Newer" encryption types are those which have been specified along + with or since the new Kerberos cryptosystem specification [RFC3961], + as defined in section 3.1.3 of [RFC4120]. The list of not-newer + encryption types is as follows [RFC3961]: + + Encryption Type Assigned Number + ---------------------------------------------- + des-cbc-crc 1 + des-cbc-md4 2 + des-cbc-md5 3 + des3-cbc-md5 5 + des3-cbc-sha1 7 + dsaWithSHA1-CmsOID 9 + md5WithRSAEncryption-CmsOID 10 + sha1WithRSAEncryption-CmsOID 11 + rc2CBC-EnvOID 12 + rsaEncryption-EnvOID 13 + rsaES-OAEP-ENV-OID 14 + des-ede3-cbc-Env-OID 15 + des3-cbc-sha1-kd 16 + rc4-hmac 23 + + Conventions used in this document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + The term "little-endian order" is used for brevity to refer to the + least-significant-octet-first encoding, while the term "big-endian + order" is for the most-significant-octet-first encoding. + + + + + + + +Zhu, et al. Standards Track [Page 3] + +RFC 4121 Kerberos Version 5 GSS-API July 2005 + + +2. Key Derivation for Per-Message Tokens + + To limit the exposure of a given key, [RFC3961] adopted "one-way" + "entropy-preserving" derived keys, from a base key or protocol key, + for different purposes or key usages. + + This document defines four key usage values below that are used to + derive a specific key for signing and sealing messages from the + session key or subkey [RFC4120] created during the context + establishment. + + Name Value + ------------------------------------- + KG-USAGE-ACCEPTOR-SEAL 22 + KG-USAGE-ACCEPTOR-SIGN 23 + KG-USAGE-INITIATOR-SEAL 24 + KG-USAGE-INITIATOR-SIGN 25 + + When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is + used as the usage number in the key derivation function for deriving + keys to be used in MIC tokens (as defined in section 4.2.6.1). + KG-USAGE-ACCEPTOR-SEAL is used for Wrap tokens (as defined in section + 4.2.6.2). Similarly, when the sender is the context initiator, + KG-USAGE-INITIATOR-SIGN is used as the usage number in the key + derivation function for MIC tokens, while KG-USAGE-INITIATOR-SEAL is + used for Wrap tokens. Even if the Wrap token does not provide for + confidentiality, the same usage values specified above are used. + + During the context initiation and acceptance sequence, the acceptor + MAY assert a subkey in the AP-REP message. If the acceptor asserts a + subkey, the base key is the acceptor-asserted subkey and subsequent + per-message tokens MUST be flagged with "AcceptorSubkey", as + described in section 4.2.2. Otherwise, if the initiator asserts a + subkey in the AP-REQ message, the base key is this subkey; if the + initiator does not assert a subkey, the base key is the session key + in the service ticket. + +3. Quality of Protection + + The GSS-API specification [RFC2743] provides Quality of Protection + (QOP) values that can be used by applications to request a certain + type of encryption or signing. A zero QOP value is used to indicate + the "default" protection; applications that do not use the default + QOP are not guaranteed to be portable across implementations, or even + to inter-operate with different deployment configurations of the same + implementation. Using a different algorithm than the one for which + the key is defined may not be appropriate. Therefore, when the new + method in this document is used, the QOP value is ignored. + + + +Zhu, et al. Standards Track [Page 4] + +RFC 4121 Kerberos Version 5 GSS-API July 2005 + + + The encryption and checksum algorithms in per-message tokens are now + implicitly defined by the algorithms associated with the session key + or subkey. Therefore, algorithm identifiers as described in + [RFC1964] are no longer needed and are removed from the new token + headers. + +4. Definitions and Token Formats + + This section provides terms and definitions, as well as descriptions + for tokens specific to the Kerberos Version 5 GSS-API mechanism. + +4.1. Context Establishment Tokens + + All context establishment tokens emitted by the Kerberos Version 5 + GSS-API mechanism SHALL have the framing described in section 3.1 of + [RFC2743], as illustrated by the following pseudo-ASN.1 structures: + + GSS-API DEFINITIONS ::= + + BEGIN + + MechType ::= OBJECT IDENTIFIER + -- representing Kerberos V5 mechanism + + GSSAPI-Token ::= + -- option indication (delegation, etc.) indicated within + -- mechanism-specific token + [APPLICATION 0] IMPLICIT SEQUENCE { + thisMech MechType, + innerToken ANY DEFINED BY thisMech + -- contents mechanism-specific + -- ASN.1 structure not required + } + + END + + The innerToken field starts with a two-octet token-identifier + (TOK_ID) expressed in big-endian order, followed by a Kerberos + message. + + Following are the TOK_ID values used in the context establishment + tokens: + + Token TOK_ID Value in Hex + ----------------------------------------- + KRB_AP_REQ 01 00 + KRB_AP_REP 02 00 + KRB_ERROR 03 00 + + + +Zhu, et al. Standards Track [Page 5] + +RFC 4121 Kerberos Version 5 GSS-API July 2005 + + + Where Kerberos message KRB_AP_REQUEST, KRB_AP_REPLY, and KRB_ERROR + are defined in [RFC4120]. + + If an unknown token identifier (TOK_ID) is received in the initial + context establishment token, the receiver MUST return + GSS_S_CONTINUE_NEEDED major status, and the returned output token + MUST contain a KRB_ERROR message with the error code + KRB_AP_ERR_MSG_TYPE [RFC4120]. + +4.1.1. Authenticator Checksum + + The authenticator in the KRB_AP_REQ message MUST include the optional + sequence number and the checksum field. The checksum field is used + to convey service flags, channel bindings, and optional delegation + information. + + The checksum type MUST be 0x8003. When delegation is used, a + ticket-granting ticket will be transferred in a KRB_CRED message. + This ticket SHOULD have its forwardable flag set. The EncryptedData + field of the KRB_CRED message [RFC4120] MUST be encrypted in the + session key of the ticket used to authenticate the context. + + The authenticator checksum field SHALL have the following format: + + Octet Name Description + ----------------------------------------------------------------- + 0..3 Lgth Number of octets in Bnd field; Represented + in little-endian order; Currently contains + hex value 10 00 00 00 (16). + 4..19 Bnd Channel binding information, as described in + section 4.1.1.2. + 20..23 Flags Four-octet context-establishment flags in + little-endian order as described in section + 4.1.1.1. + 24..25 DlgOpt The delegation option identifier (=1) in + little-endian order [optional]. This field + and the next two fields are present if and + only if GSS_C_DELEG_FLAG is set as described + in section 4.1.1.1. + 26..27 Dlgth The length of the Deleg field in + little-endian order [optional]. + 28..(n-1) Deleg A KRB_CRED message (n = Dlgth + 28) + [optional]. + n..last Exts Extensions [optional]. + + The length of the checksum field MUST be at least 24 octets when + GSS_C_DELEG_FLAG is not set (as described in section 4.1.1.1), and at + least 28 octets plus Dlgth octets when GSS_C_DELEG_FLAG is set. When + + + +Zhu, et al. Standards Track [Page 6] + +RFC 4121 Kerberos Version 5 GSS-API July 2005 + + + GSS_C_DELEG_FLAG is set, the DlgOpt, Dlgth, and Deleg fields of the + checksum data MUST immediately follow the Flags field. The optional + trailing octets (namely the "Exts" field) facilitate future + extensions to this mechanism. When delegation is not used, but the + Exts field is present, the Exts field starts at octet 24 (DlgOpt, + Dlgth and Deleg are absent). + + Initiators that do not support the extensions MUST NOT include more + than 24 octets in the checksum field (when GSS_C_DELEG_FLAG is not + set) or more than 28 octets plus the KRB_CRED in the Deleg field + (when GSS_C_DELEG_FLAG is set). Acceptors that do not understand the + + Extensions MUST ignore any octets past the Deleg field of the + checksum data (when GSS_C_DELEG_FLAG is set) or past the Flags field + of the checksum data (when GSS_C_DELEG_FLAG is not set). + +4.1.1.1. Checksum Flags Field + + The checksum "Flags" field is used to convey service options or + extension negotiation information. + + The following context establishment flags are defined in [RFC2744]. + + Flag Name Value + --------------------------------- + GSS_C_DELEG_FLAG 1 + GSS_C_MUTUAL_FLAG 2 + GSS_C_REPLAY_FLAG 4 + GSS_C_SEQUENCE_FLAG 8 + GSS_C_CONF_FLAG 16 + GSS_C_INTEG_FLAG 32 + + Context establishment flags are exposed to the calling application. + If the calling application desires a particular service option, then + it requests that option via GSS_Init_sec_context() [RFC2743]. If the + corresponding return state values [RFC2743] indicate that any of the + above optional context level services will be active on the context, + the corresponding flag values in the table above MUST be set in the + checksum Flags field. + + Flag values 4096..524288 (2^12, 2^13, ..., 2^19) are reserved for use + with legacy vendor-specific extensions to this mechanism. + + + + + + + + + +Zhu, et al. Standards Track [Page 7] + +RFC 4121 Kerberos Version 5 GSS-API July 2005 + + + All other flag values not specified herein are reserved for future + use. Future revisions of this mechanism may use these reserved flags + and may rely on implementations of this version to not use such flags + in order to properly negotiate mechanism versions. Undefined flag + values MUST be cleared by the sender, and unknown flags MUST be + ignored by the receiver. + +4.1.1.2. Channel Binding Information + + These tags are intended to be used to identify the particular + communications channel for which the GSS-API security context + establishment tokens are intended, thus limiting the scope within + which an intercepted context establishment token can be reused by an + attacker (see [RFC2743], section 1.1.6). + + When using C language bindings, channel bindings are communicated to + the GSS-API using the following structure [RFC2744]: + + typedef struct gss_channel_bindings_struct { + OM_uint32 initiator_addrtype; + gss_buffer_desc initiator_address; + OM_uint32 acceptor_addrtype; + gss_buffer_desc acceptor_address; + gss_buffer_desc application_data; + } *gss_channel_bindings_t; + + The member fields and constants used for different address types are + defined in [RFC2744]. + + The "Bnd" field contains the MD5 hash of channel bindings, taken over + all non-null components of bindings, in order of declaration. + Integer fields within channel bindings are represented in little- + endian order for the purposes of the MD5 calculation. + + In computing the contents of the Bnd field, the following detailed + points apply: + + (1) For purposes of MD5 hash computation, each integer field and + input length field SHALL be formatted into four octets, using + little-endian octet ordering. + + (2) All input length fields within gss_buffer_desc elements of a + gss_channel_bindings_struct even those which are zero-valued, + SHALL be included in the hash calculation. The value elements of + gss_buffer_desc elements SHALL be dereferenced, and the resulting + data SHALL be included within the hash computation, only for the + case of gss_buffer_desc elements having non-zero length + specifiers. + + + +Zhu, et al. Standards Track [Page 8] + +RFC 4121 Kerberos Version 5 GSS-API July 2005 + + + (3) If the caller passes the value GSS_C_NO_BINDINGS instead of a + valid channel binding structure, the Bnd field SHALL be set to 16 + zero-valued octets. + + If the caller to GSS_Accept_sec_context [RFC2743] passes in + GSS_C_NO_CHANNEL_BINDINGS [RFC2744] as the channel bindings, then the + acceptor MAY ignore any channel bindings supplied by the initiator, + returning success even if the initiator did pass in channel bindings. + + If the application supplies, in the channel bindings, a buffer with a + length field larger than 4294967295 (2^32 - 1), the implementation of + this mechanism MAY choose to reject the channel bindings altogether, + using major status GSS_S_BAD_BINDINGS [RFC2743]. In any case, the + size of channel-binding data buffers that can be used (interoperable, + without extensions) with this specification is limited to 4294967295 + octets. + +4.2. Per-Message Tokens + + Two classes of tokens are defined in this section: (1) "MIC" tokens, + emitted by calls to GSS_GetMIC() and consumed by calls to + GSS_VerifyMIC(), and (2) "Wrap" tokens, emitted by calls to + GSS_Wrap() and consumed by calls to GSS_Unwrap(). + + These new per-message tokens do not include the generic GSS-API token + framing used by the context establishment tokens. These new tokens + are designed to be used with newer crypto systems that can have + variable-size checksums. + +4.2.1. Sequence Number + + To distinguish intentionally-repeated messages from maliciously- + replayed ones, per-message tokens contain a sequence number field, + which is a 64 bit integer expressed in big-endian order. After + sending a GSS_GetMIC() or GSS_Wrap() token, the sender's sequence + numbers SHALL be incremented by one. + +4.2.2. Flags Field + + The "Flags" field is a one-octet integer used to indicate a set of + attributes for the protected message. For example, one flag is + allocated as the direction-indicator, thus preventing the acceptance + of the same message sent back in the reverse direction by an + adversary. + + + + + + + +Zhu, et al. Standards Track [Page 9] + +RFC 4121 Kerberos Version 5 GSS-API July 2005 + + + The meanings of bits in this field (the least significant bit is bit + 0) are as follows: + + Bit Name Description + -------------------------------------------------------------- + 0 SentByAcceptor When set, this flag indicates the sender + is the context acceptor. When not set, + it indicates the sender is the context + initiator. + 1 Sealed When set in Wrap tokens, this flag + indicates confidentiality is provided + for. It SHALL NOT be set in MIC tokens. + 2 AcceptorSubkey A subkey asserted by the context acceptor + is used to protect the message. + + The rest of available bits are reserved for future use and MUST be + cleared. The receiver MUST ignore unknown flags. + +4.2.3. EC Field + + The "EC" (Extra Count) field is a two-octet integer field expressed + in big-endian order. + + In Wrap tokens with confidentiality, the EC field SHALL be used to + encode the number of octets in the filler, as described in section + 4.2.4. + + In Wrap tokens without confidentiality, the EC field SHALL be used to + encode the number of octets in the trailing checksum, as described in + section 4.2.4. + +4.2.4. Encryption and Checksum Operations + + The encryption algorithms defined by the crypto profiles provide for + integrity protection [RFC3961]. Therefore, no separate checksum is + needed. + + The result of decryption can be longer than the original plaintext + [RFC3961] and the extra trailing octets are called "crypto-system + residue" in this document. However, given the size of any plaintext + data, one can always find a (possibly larger) size, such that when + padding the to-be-encrypted text to that size, there will be no + crypto-system residue added [RFC3961]. + + In Wrap tokens that provide for confidentiality, the first 16 octets + of the Wrap token (the "header", as defined in section 4.2.6), SHALL + be appended to the plaintext data before encryption. Filler octets + MAY be inserted between the plaintext data and the "header." The + + + +Zhu, et al. Standards Track [Page 10] + +RFC 4121 Kerberos Version 5 GSS-API July 2005 + + + values and size of the filler octets are chosen by implementations, + such that there SHALL be no crypto-system residue present after the + decryption. The resulting Wrap token is {"header" | + encrypt(plaintext-data | filler | "header")}, where encrypt() is the + encryption operation (which provides for integrity protection) + defined in the crypto profile [RFC3961], and the RRC field (as + defined in section 4.2.5) in the to-be-encrypted header contains the + hex value 00 00. + + In Wrap tokens that do not provide for confidentiality, the checksum + SHALL be calculated first over the to-be-signed plaintext data, and + then over the first 16 octets of the Wrap token (the "header", as + defined in section 4.2.6). Both the EC field and the RRC field in + the token header SHALL be filled with zeroes for the purpose of + calculating the checksum. The resulting Wrap token is {"header" | + plaintext-data | get_mic(plaintext-data | "header")}, where get_mic() + is the checksum operation for the required checksum mechanism of the + chosen encryption mechanism defined in the crypto profile [RFC3961]. + + The parameters for the key and the cipher-state in the encrypt() and + get_mic() operations have been omitted for brevity. + + For MIC tokens, the checksum SHALL be calculated as follows: the + checksum operation is calculated first over the to-be-signed + plaintext data, and then over the first 16 octets of the MIC token, + where the checksum mechanism is the required checksum mechanism of + the chosen encryption mechanism defined in the crypto profile + [RFC3961]. + + The resulting Wrap and MIC tokens bind the data to the token header, + including the sequence number and the direction indicator. + +4.2.5. RRC Field + + The "RRC" (Right Rotation Count) field in Wrap tokens is added to + allow the data to be encrypted in-place by existing SSPI (Security + Service Provider Interface) [SSPI] applications that do not provide + an additional buffer for the trailer (the cipher text after the in- + place-encrypted data) in addition to the buffer for the header (the + cipher text before the in-place-encrypted data). Excluding the first + 16 octets of the token header, the resulting Wrap token in the + previous section is rotated to the right by "RRC" octets. The net + result is that "RRC" octets of trailing octets are moved toward the + header. + + Consider the following as an example of this rotation operation: + Assume that the RRC value is 3 and the token before the rotation is + {"header" | aa | bb | cc | dd | ee | ff | gg | hh}. The token after + + + +Zhu, et al. Standards Track [Page 11] + +RFC 4121 Kerberos Version 5 GSS-API July 2005 + + + rotation would be {"header" | ff | gg | hh | aa | bb | cc | dd | ee + }, where {aa | bb | cc |...| hh} would be used to indicate the octet + sequence. + + The RRC field is expressed as a two-octet integer in big-endian + order. + + The rotation count value is chosen by the sender based on + implementation details. The receiver MUST be able to interpret all + possible rotation count values, including rotation counts greater + than the length of the token. + +4.2.6. Message Layouts + + Per-message tokens start with a two-octet token identifier (TOK_ID) + field, expressed in big-endian order. These tokens are defined + separately in the following sub-sections. + +4.2.6.1. MIC Tokens + + Use of the GSS_GetMIC() call yields a token (referred as the MIC + token in this document), separate from the user data being protected, + which can be used to verify the integrity of that data as received. + The token has the following format: + + Octet no Name Description + -------------------------------------------------------------- + 0..1 TOK_ID Identification field. Tokens emitted by + GSS_GetMIC() contain the hex value 04 04 + expressed in big-endian order in this + field. + 2 Flags Attributes field, as described in section + 4.2.2. + 3..7 Filler Contains five octets of hex value FF. + 8..15 SND_SEQ Sequence number field in clear text, + expressed in big-endian order. + 16..last SGN_CKSUM Checksum of the "to-be-signed" data and + octet 0..15, as described in section 4.2.4. + + The Filler field is included in the checksum calculation for + simplicity. + + + + + + + + + + +Zhu, et al. Standards Track [Page 12] + +RFC 4121 Kerberos Version 5 GSS-API July 2005 + + +4.2.6.2. Wrap Tokens + + Use of the GSS_Wrap() call yields a token (referred as the Wrap token + in this document), which consists of a descriptive header, followed + by a body portion that contains either the input user data in + plaintext concatenated with the checksum, or the input user data + encrypted. The GSS_Wrap() token SHALL have the following format: + + Octet no Name Description + -------------------------------------------------------------- + 0..1 TOK_ID Identification field. Tokens emitted by + GSS_Wrap() contain the hex value 05 04 + expressed in big-endian order in this + field. + 2 Flags Attributes field, as described in section + 4.2.2. + 3 Filler Contains the hex value FF. + 4..5 EC Contains the "extra count" field, in big- + endian order as described in section 4.2.3. + 6..7 RRC Contains the "right rotation count" in big- + endian order, as described in section + 4.2.5. + 8..15 SND_SEQ Sequence number field in clear text, + expressed in big-endian order. + 16..last Data Encrypted data for Wrap tokens with + confidentiality, or plaintext data followed + by the checksum for Wrap tokens without + confidentiality, as described in section + 4.2.4. + +4.3. Context Deletion Tokens + + Context deletion tokens are empty in this mechanism. Both peers to a + security context invoke GSS_Delete_sec_context() [RFC2743] + independently, passing a null output_context_token buffer to indicate + that no context_token is required. Implementations of + GSS_Delete_sec_context() should delete relevant locally-stored + context information. + +4.4. Token Identifier Assignment Considerations + + Token identifiers (TOK_ID) from 0x60 0x00 through 0x60 0xFF inclusive + are reserved and SHALL NOT be assigned. Thus, by examining the first + two octets of a token, one can tell unambiguously if it is wrapped + with the generic GSS-API token framing. + + + + + + +Zhu, et al. Standards Track [Page 13] + +RFC 4121 Kerberos Version 5 GSS-API July 2005 + + +5. Parameter Definitions + + This section defines parameter values used by the Kerberos V5 GSS-API + mechanism. It defines interface elements that support portability, + and assumes use of C language bindings per [RFC2744]. + +5.1. Minor Status Codes + + This section recommends common symbolic names for minor_status values + to be returned by the Kerberos V5 GSS-API mechanism. Use of these + definitions will enable independent implementers to enhance + application portability across different implementations of the + mechanism defined in this specification. (In all cases, + implementations of GSS_Display_status() will enable callers to + convert minor_status indicators to text representations.) Each + implementation should make available, through include files or other + means, a facility to translate these symbolic names into the concrete + values that a particular GSS-API implementation uses to represent the + minor_status values specified in this section. + + This list may grow over time and the need for additional minor_status + codes, specific to particular implementations, may arise. However, + it is recommended that implementations should return a minor_status + value as defined on a mechanism-wide basis within this section when + that code accurately represents reportable status rather than using a + separate, implementation-defined code. + +5.1.1. Non-Kerberos-specific Codes + + GSS_KRB5_S_G_BAD_SERVICE_NAME + /* "No @ in SERVICE-NAME name string" */ + GSS_KRB5_S_G_BAD_STRING_UID + /* "STRING-UID-NAME contains nondigits" */ + GSS_KRB5_S_G_NOUSER + /* "UID does not resolve to username" */ + GSS_KRB5_S_G_VALIDATE_FAILED + /* "Validation error" */ + GSS_KRB5_S_G_BUFFER_ALLOC + /* "Couldn't allocate gss_buffer_t data" */ + GSS_KRB5_S_G_BAD_MSG_CTX + /* "Message context invalid" */ + GSS_KRB5_S_G_WRONG_SIZE + /* "Buffer is the wrong size" */ + GSS_KRB5_S_G_BAD_USAGE + /* "Credential usage type is unknown" */ + GSS_KRB5_S_G_UNKNOWN_QOP + /* "Unknown quality of protection specified" */ + + + + +Zhu, et al. Standards Track [Page 14] + +RFC 4121 Kerberos Version 5 GSS-API July 2005 + + +5.1.2. Kerberos-specific Codes + + GSS_KRB5_S_KG_CCACHE_NOMATCH + /* "Client principal in credentials does not match + specified name" */ + GSS_KRB5_S_KG_KEYTAB_NOMATCH + /* "No key available for specified service + principal" */ + GSS_KRB5_S_KG_TGT_MISSING + /* "No Kerberos ticket-granting ticket available" */ + GSS_KRB5_S_KG_NO_SUBKEY + /* "Authenticator has no subkey" */ + GSS_KRB5_S_KG_CONTEXT_ESTABLISHED + /* "Context is already fully established" */ + GSS_KRB5_S_KG_BAD_SIGN_TYPE + /* "Unknown signature type in token" */ + GSS_KRB5_S_KG_BAD_LENGTH + /* "Invalid field length in token" */ + GSS_KRB5_S_KG_CTX_INCOMPLETE + /* "Attempt to use incomplete security context" */ + +5.2. Buffer Sizes + + All implementations of this specification MUST be capable of + accepting buffers of at least 16K octets as input to GSS_GetMIC(), + GSS_VerifyMIC(), and GSS_Wrap(). They MUST also be capable of + accepting the output_token generated by GSS_Wrap() for a 16K octet + input buffer as input to GSS_Unwrap(). Implementations SHOULD + support 64K octet input buffers, and MAY support even larger input + buffer sizes. + +6. Backwards Compatibility Considerations + + The new token formats defined in this document will only be + recognized by new implementations. To address this, implementations + can always use the explicit sign or seal algorithm in [RFC1964] when + the key type corresponds to not "newer" enctypes. As an alternative, + one might retry sending the message with the sign or seal algorithm + explicitly defined as in [RFC1964]. However, this would require + either the use of a mechanism such as [RFC2478] to securely negotiate + the method, or the use of an out-of-band mechanism to choose the + appropriate mechanism. For this reason, it is RECOMMENDED that the + new token formats defined in this document SHOULD be used only if + both peers are known to support the new mechanism during context + negotiation because of, for example, the use of "new" enctypes. + + + + + + +Zhu, et al. Standards Track [Page 15] + +RFC 4121 Kerberos Version 5 GSS-API July 2005 + + + GSS_Unwrap() or GSS_VerifyMIC() can process a message token as + follows: it can look at the first octet of the token header, and if + it is 0x60, then the token must carry the generic GSS-API pseudo + ASN.1 framing. Otherwise, the first two octets of the token contain + the TOK_ID that uniquely identify the token message format. + +7. Security Considerations + + Channel bindings are validated by the acceptor. The acceptor can + ignore the channel bindings restriction supplied by the initiator and + carried in the authenticator checksum, if (1) channel bindings are + not used by GSS_Accept_sec_context [RFC2743], and (2) the acceptor + does not prove to the initiator that it has the same channel bindings + as the initiator (even if the client requested mutual + authentication). This limitation should be considered by designers + of applications that would use channel bindings, whether to limit the + use of GSS-API contexts to nodes with specific network addresses, to + authenticate other established, secure channels using Kerberos + Version 5, or for any other purpose. + + Session key types are selected by the KDC. Under the current + mechanism, no negotiation of algorithm types occurs, so server-side + (acceptor) implementations cannot request that clients not use + algorithm types not understood by the server. However, + administrators can control what enctypes can be used for session keys + for this mechanism by controlling the set of the ticket session key + enctypes which the KDC is willing to use in tickets for a given + acceptor principal. Therefore, the KDC could be given the task of + limiting session keys for a given service to types actually supported + by the Kerberos and GSSAPI software on the server. This has a + drawback for cases in which a service principal name is used for both + GSSAPI-based and non-GSSAPI-based communication (most notably the + "host" service key), if the GSSAPI implementation does not understand + (for example) AES [RFC3962], but the Kerberos implementation does. + This means that AES session keys cannot be issued for that service + principal, which keeps the protection of non-GSSAPI services weaker + than necessary. KDC administrators desiring to limit the session key + types to support interoperability with such GSSAPI implementations + should carefully weigh the reduction in protection offered by such + mechanisms against the benefits of interoperability. + + + + + + + + + + + +Zhu, et al. Standards Track [Page 16] + +RFC 4121 Kerberos Version 5 GSS-API July 2005 + + +8. Acknowledgements + + Ken Raeburn and Nicolas Williams corrected many of our errors in the + use of generic profiles and were instrumental in the creation of this + document. + + The text for security considerations was contributed by Nicolas + Williams and Ken Raeburn. + + Sam Hartman and Ken Raeburn suggested the "floating trailer" idea, + namely the encoding of the RRC field. + + Sam Hartman and Nicolas Williams recommended the replacing our + earlier key derivation function for directional keys with different + key usage numbers for each direction as well as retaining the + directional bit for maximum compatibility. + + Paul Leach provided numerous suggestions and comments. + + Scott Field, Richard Ward, Dan Simon, Kevin Damour, and Simon + Josefsson also provided valuable inputs on this document. + + Jeffrey Hutzelman provided comments and clarifications for the text + related to the channel bindings. + + Jeffrey Hutzelman and Russ Housley suggested many editorial changes. + + Luke Howard provided implementations of this document for the Heimdal + code base, and helped inter-operability testing with the Microsoft + code base, together with Love Hornquist Astrand. These experiments + formed the basis of this document. + + Martin Rex provided suggestions of TOK_ID assignment recommendations, + thus the token tagging in this document is unambiguous if the token + is wrapped with the pseudo ASN.1 header. + + John Linn wrote the original Kerberos Version 5 mechanism + specification [RFC1964], of which some text has been retained. + + + + + + + + + + + + + +Zhu, et al. Standards Track [Page 17] + +RFC 4121 Kerberos Version 5 GSS-API July 2005 + + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2743] Linn, J., "Generic Security Service Application Program + Interface Version 2, Update 1", RFC 2743, January 2000. + + [RFC2744] Wray, J., "Generic Security Service API Version 2: + C-bindings", RFC 2744, January 2000. + + [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC + 1964, June 1996. + + [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for + Kerberos 5", RFC 3961, February 2005. + + [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The + Kerberos Network Authentication Service (V5)", RFC 4120, + July 2005. + +9.2. Informative References + + [SSPI] Leach, P., "Security Service Provider Interface", + Microsoft Developer Network (MSDN), April 2003. + + [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) + Encryption for Kerberos 5", RFC 3962, February 2005. + + [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API + Negotiation Mechanism", RFC 2478, December 1998. + + + + + + + + + + + + + + + + + + +Zhu, et al. Standards Track [Page 18] + +RFC 4121 Kerberos Version 5 GSS-API July 2005 + + +Authors' Addresses + + Larry Zhu + One Microsoft Way + Redmond, WA 98052 - USA + + EMail: LZhu@microsoft.com + + + Karthik Jaganathan + One Microsoft Way + Redmond, WA 98052 - USA + + EMail: karthikj@microsoft.com + + + Sam Hartman + Massachusetts Institute of Technology + 77 Massachusetts Avenue + Cambridge, MA 02139 - USA + + EMail: hartmans-ietf@mit.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zhu, et al. Standards Track [Page 19] + +RFC 4121 Kerberos Version 5 GSS-API July 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Zhu, et al. Standards Track [Page 20] +