diff options
Diffstat (limited to 'crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt')
| -rw-r--r-- | crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt | 589 |
1 files changed, 0 insertions, 589 deletions
diff --git a/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt b/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt deleted file mode 100644 index 1fc9927..0000000 --- a/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt +++ /dev/null @@ -1,589 +0,0 @@ - - -CAT working group M. Swift -Internet Draft J. Brezak -Document: draft-brezak-win2k-krb-rc4-hmac-02.txt Microsoft -Category: Informational November 2000 - - - The Windows 2000 RC4-HMAC Kerberos encryption type - - -tatus of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026 [1]. 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. - -. Abstract - - The 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), and provide exportable (meet United States government - export restriction requirements) encryption. - - The 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 Windows 2000. - - -. Conventions used in this document - - - -wift Category - Informational 1 - - Windows 2000 RC4-HMAC Kerberos E-Type June 2000 - - - 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 RFC-2119 [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 RFC 1510. 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 [6] - 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 - -. Basic Operations - - The MD5 HMAC function is defined in [3]. It is used in this - encryption type for checksum operations. Refer to [3] 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 [7]. 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 [RSADSI]. A - compatible cipher is described in [8]. 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 as defined in [9] (RFC- - 1510BIS) in Section titled "Key Derivation". With each message, the - message type (T) is used as a component of the keying material. This - summarizes the different key derivation values used in the various - -wift Category - Informational 2 - - Windows 2000 RC4-HMAC Kerberos E-Type June 2000 - - - operations. Note that these differ from the key derivations used in - other Kerberos encryption types. - - T = 1 for TS-ENC-TS in the AS-Request - T = 8 for the AS-Reply - T = 7 for the Authenticator in the TGS-Request - T = 8 for the TGS-Reply - T = 2 for the Server Ticket in the AP-Request - T = 11 for the Authenticator in the AP-Request - T = 12 for the Server returned AP-Reply - T = 15 in the generation of checksum for the MIC token - T = 0 in the generation of sequence number for the MIC token - T = 13 in the generation of checksum for the WRAP 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. - -. 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) - - -. 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. - -wift Category - Informational 3 - - Windows 2000 RC4-HMAC Kerberos E-Type June 2000 - - - - BYTE L40[14] = "fortybits"; - BYTE SK = "signaturekey"; - - ENCRYPT (K, fRC4_EXP, T, data, data_len, edata, edata_len) - { - if (fRC4_EXP){ - *((DWORD *)(L40+10)) = T; - HMAC (K, L40, 10 + 4, K1); - }else{ - HMAC (K, &T, 4, K1); - } - memcpy (K2, K1, 16); - if (fRC4_EXP) memset (K1+7, 0xAB, 9); - add_8_random_bytes(data, data_len, conf_plus_data); - HMAC (K2, conf_plus_data, 8 + data_len, checksum); - HMAC (K1, checksum, 16, K3); - RC4(K3, conf_plus_data, 8 + data_len, edata + 16); - memcpy (edata, checksum, 16); - edata_len = 16 + 8 + data_len; - } - - DECRYPT (K, fRC4_EXP, T, edata, edata_len, data, data_len) - { - if (fRC4_EXP){ - *((DWORD *)(L40+10)) = T; - HMAC (K, L40, 14, K1); - }else{ - HMAC (K, &T, 4, K1); - } - memcpy (K2, K1, 16); - if (fRC4_EXP) memset (K1+7, 0xAB, 9); - HMAC (K1, edata, 16, K3); // checksum is at edata - RC4(K3, edata + 16, edata_len - 16, edata + 16); - data_len = edata_len - 16 - 8; - memcpy (data, edata + 16 + 8, data_len); - - // verify generated and received checksums - HMAC (K2, edata + 16, edata_len - 16, checksum); - if (memcmp(edata, checksum, 16) != 0) - printf("CHECKSUM ERROR !!!!!!\n"); - } - - The header field on the encrypted data in KDC messages is: - - typedef struct _RC4_MDx_HEADER { - UCHAR Checksum[16]; - UCHAR Confounder[8]; - } RC4_MDx_HEADER, *PRC4_MDx_HEADER; - - The KDC message is encrypted using the ENCRYPT function not - including the Checksum in the RC4_MDx_HEADER. - - -wift Category - Informational 4 - - Windows 2000 RC4-HMAC Kerberos E-Type June 2000 - - - 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. - -. 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. - -. GSSAPI Kerberos V5 Mechanism Type - -.1 Mechanism Specific Changes - - The GSSAPI per-message tokens also require new checksum and - encryption types. The GSS-API per-message tokens must be changed to - support these new encryption types (See [5] Section 1.2.2). The - sealing algorithm identifier (SEAL_ALG) for an RC4 based encryption - is: - Byte 4..5 SEAL_ALG 0x10 0x00 - RC4 - - The signing algorithm identifier (SGN_ALG) for MD5 HMAC is: - Byte 2..3 SGN ALG 0x11 0x00 - HMAC - - The only support quality of protection is: - #define GSS_KRB5_INTEG_C_QOP_DEFAULT 0x0 - - In addition, when using an RC4 based encryption type, the sequence - number is 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 [5] - 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 framing - they are raw AP message and do not include object - identifiers. - #define GSS_C_DCE_STYLE 0x1000 - - - -wift Category - Informational 5 - - Windows 2000 RC4-HMAC Kerberos E-Type June 2000 - - - 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: - #define GSS_C_AF_NETBIOS 0x14 - NetBios addresses are 16-octet addresses typically composed of 1 to th 15 characters, trailing blank (ascii char 20) filled, with a 16 - octet of 0x0. - -.2 GSSAPI Checksum Type - - 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 [5] Section 1.2) for - GSS_GetMIC() and GSS_Wrap(conf_flag=FALSE). - - MIC (K, fRC4_EXP, seq_num, MIC_hdr, msg, msg_len, - MIC_seq, MIC_checksum) - { - HMAC (K, SK, 13, K4); - T = 15; - memcpy (T_plus_hdr_plus_msg + 00, &T, 4); - memcpy (T_plus_hdr_plus_msg + 04, MIC_hdr, 8); - // 0101 1100 FFFFFFFF - memcpy (T_plus_hdr_plus_msg + 12, msg, msg_len); - MD5 (T_hdr_msg, 4 + 8 + msg_len, MD5_of_T_hdr_msg); - HMAC (K4, MD5_of_T_hdr_msg, CHKSUM); - memcpy (MIC_checksum, CHKSUM, 8); // use only first 8 bytes - - T = 0; - if (fRC4_EXP){ - *((DWORD *)(L40+10)) = T; - HMAC (K, L40, 14, K5); - }else{ - HMAC (K, &T, 4, K5); - -wift Category - Informational 6 - - Windows 2000 RC4-HMAC Kerberos E-Type June 2000 - - - } - if (fRC4_EXP) memset(K5+7, 0xAB, 9); - HMAC(K5, MIT_checksum, 8, K6); - copy_seq_num_in_big_endian(seq_num, seq_plus_direction); - //0x12345678 - copy_direction_flag (direction_flag, seq_plus_direction + - 4); //0x12345678FFFFFFFF - RC4(K6, seq_plus_direction, 8, MIC_seq); - } - -.3 GSSAPI Encryption Types - - There are two encryption types 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 [5] Section 1.2.2.3. - - The encryption mechanism used for GSS wrap based messages is as - follow: - - - WRAP (K, fRC4_EXP, seq_num, WRAP_hdr, msg, msg_len, - WRAP_seq, WRAP_checksum, edata, edata_len) - { - HMAC (K, SK, 13, K7); - T = 13; - PAD = 1; - memcpy (T_hdr_conf_msg_pad + 00, &T, 4); - memcpy (T_hdr_conf_msg_pad + 04, WRAP_hdr, 8); // 0101 1100 - FFFFFFFF - memcpy (T_hdr_conf_msg_pad + 12, msg, msg_len); - memcpy (T_hdr_conf_msg_pad + 12 + msg_len, &PAD, 1); - MD5 (T_hdr_conf_msg_pad, - 4 + 8 + 8 + msg_len + 1, - MD5_of_T_hdr_conf_msg_pad); - HMAC (K7, MD5_of_T_hdr_conf_msg_pad, CHKSUM); - memcpy (WRAP_checksum, CHKSUM, 8); // use only first 8 - bytes - - T = 0; - if (fRC4_EXP){ - *((DWORD *)(L40+10)) = T; - HMAC (K, L40, 14, K8); - }else{ - HMAC (K, &T, 4, K8); - } - if (fRC4_EXP) memset(K8+7, 0xAB, 9); - HMAC(K8, WRAP_checksum, 8, K9); - copy_seq_num_in_big_endian(seq_num, seq_plus_direction); - //0x12345678 - -wift Category - Informational 7 - - Windows 2000 RC4-HMAC Kerberos E-Type June 2000 - - - copy_direction_flag (direction_flag, seq_plus_direction + - 4); //0x12345678FFFFFFFF - RC4(K9, seq_plus_direction, 8, WRAP_seq); - - for (i = 0; i < 16; i++) K10 [i] ^= 0xF0; // XOR each byte - of key with 0xF0 - T = 0; - if (fRC4_EXP){ - *(DWORD *)(L40+10) = T; - HMAC(K10, L40, 14, K11); - memset(K11+7, 0xAB, 9); - }else{ - HMAC(K10, &T, 4, K11); - } - HMAC(K11, seq_num, 4, K12); - RC4(K12, T_hdr_conf_msg_pad + 4 + 8, 8 + msg_len + 1, - edata); /* skip T & hdr */ - edata_len = 8 + msg_len + 1; // conf + msg_len + pad - } - - - 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. - -. Security Considerations - - Care must be taken in implementing this encryption type because it - uses a stream cipher. If a different IV isnÆt used in each direction - when using a session key, the encryption is weak. By using the - sequence number as an IV, this is avoided. - -0. Acknowledgements - - We would like to thank Salil Dangi for the valuable input in - refining the descriptions of the functions and review input. - -1. References - - 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP - 9, RFC 2026, October 1996. - - 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997 - - 3 Krawczyk, H., Bellare, M., Canetti, R.,"HMAC: Keyed-Hashing for - Message Authentication", RFC 2104, February 1997 - - 4 Kohl, J., Neuman, C., "The Kerberos Network Authentication - Service (V5)", RFC 1510, September 1993 - - - -wift Category - Informational 8 - - Windows 2000 RC4-HMAC Kerberos E-Type June 2000 - - - - 5 Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC-1964, - June 1996 - - 6 R. Rivest, "The MD4 Message-Digest Algorithm", RFC-1320, April - 1992 - - 7 R. Rivest, "The MD5 Message-Digest Algorithm", RFC-1321, April - 1992 - - 8 Thayer, R. and K. Kaukonen, "A Stream Cipher Encryption - Algorithm", Work in Progress. - - 9 RC4 is a proprietary encryption algorithm available under license - from RSA Data Security Inc. For licensing information, contact: - - RSA Data Security, Inc. - 100 Marine Parkway - Redwood City, CA 94065-1031 - - 10 Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network - Authentication Service (V5)", draft-ietf-cat-kerberos-revisions- - 04.txt, June 25, 1999 - - -2. Author's Addresses - - Mike Swift - Dept. of Computer Science - Sieg Hall - University of Washington - Seattle, WA 98105 - Email: mikesw@cs.washington.edu - - John Brezak - Microsoft - One Microsoft Way - Redmond, Washington - Email: jbrezak@microsoft.com - - - - - - - - - - - - - - - -wift Category - Informational 9 - - Windows 2000 RC4-HMAC Kerberos E-Type October 1999 - - - -3. Full Copyright Statement - - "Copyright (C) The Internet Society (2000). All Rights Reserved. - - This document and translations of it may be copied and - furnished to others, and derivative works that comment on or - otherwise explain it or assist in its implementation may be - prepared, copied, published and distributed, in whole or in - part, without restriction of any kind, provided that the above - copyright notice and this paragraph are included on all such - copies and derivative works. However, this document itself may - not be modified in any way, such as by removing the copyright - notice or references to the Internet Society or other Internet - organizations, except as needed for the purpose of developing - Internet standards in which case the procedures for copyrights - defined in the Internet Standards process must be followed, or - as required to translate it into languages other than English. - - The limited permissions granted above are perpetual and will - not be revoked by the Internet Society or its successors or - assigns. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -wift Category - Informational 10 - |
