+++ /dev/null
-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.
--- /dev/null
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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, <http://www.mindspring.com/~dmcgrew/rc4-03.pdf>.
+
+ [MANTIN01] Mantin, I., "Analysis of the Stream Cipher RC4", M.Sc.
+ Thesis, Weizmann Institute of Science, 2001, <http://
+ www.wisdom.weizmann.ac.il/~itsik/RC4/Papers/Mantin1.zip>.
+
+ [MIRONOV] Mironov, I., "(Not So) Random Shuffles of RC4", Advances
+ in Cryptology -- CRYPTO 2002: 22nd Annual International
+ Cryptology Conference, August 2002,
+ <http://eprint.iacr.org/2002/067.pdf>.
+
+ [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]
+\f
+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]
+\f
+
+++ /dev/null
----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.
-
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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 <sys/socket.h> 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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
\ No newline at end of file
--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
projects / krb5.git / commitdiff