Kerberos Working Group K. Raeburn Category: Informational MIT Document: draft-raeburn-krb-gssapi-krb5-3des-01.txt November 24, 2000 Triple-DES Support for the Kerberos 5 GSSAPI Mechanism Status 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. 1. Abstract The GSSAPI Kerberos 5 mechanism definition [GSSAPI-KRB5] specifically enumerates encryption and checksum types, independently of how such schemes may be used in Kerberos. In the long run, a new Kerberos- based mechanism, which does not require separately enumerating for the GSSAPI mechanism each of the various encryption types defined by Kerberos, is probably a better approach. Various people have expressed interest in designing one, but the work has not yet been completed. The MIT Kerberos 5 release version 1.2 includes support for triple- DES with key derivation [KrbRev]. Recent work by the EFF [EFF] has demonstrated the vulnerability of single-DES mechanisms to brute- force attacks by sufficiently motivated and well-funded parties. So, in the interest of providing increased security in the near term, MIT is adding support for triple-DES to the existing mechanism implementation we ship, as an interim measure. Raeburn [Page 1]
INTERNET DRAFT Triple-DES for GSSAPI Kerberos November 2000 2. New Algorithm Identifiers One new sealing algorithm is defined, for use in Wrap tokens. +--------------------------------------------------------------------+ | name octet values | +--------------------------------------------------------------------+ | DES3-KD 02 00 | +--------------------------------------------------------------------+ This algorithm uses triple-DES with key derivation, with a usage value KG_USAGE_SEAL. (Unlike the EncryptedData definition in [KrbRev], no integrity protection is needed, so this is "raw" triple- DES, with no checksum attached to the encrypted data.) Padding is still to 8-byte multiples, and the IV for encrypting application data is zero. One new signing algorithm is defined, for use in MIC, Wrap, and Delete tokens. +--------------------------------------------------------------------+ | name octet values | +--------------------------------------------------------------------+ | HMAC SHA1 DES3-KD 04 00 | +--------------------------------------------------------------------+ This algorithm generates an HMAC using SHA-1 and a derived DES3 key with usage KG_USAGE_SIGN, as described in [KrbRev]. [N.B.: The current [KrbRev] description refers to expired I-Ds from Marc Horowitz. The text in [KrbRev] may be inadequate to produce an interoperable implementation.] The checksum size for this algorithm is 20 octets. See section 4.3 below for the use of checksum lengths of other than eight bytes. Raeburn [Page 2]
INTERNET DRAFT Triple-DES for GSSAPI Kerberos November 2000 3. Key Derivation For purposes of key derivation, we add three new usage values to the list defined in [KrbRev]; one for signing messages, one for sealing messages, and one for encrypting sequence numbers: +--------------------------------------------------------------------+ | name value | +--------------------------------------------------------------------+ | KG_USAGE_SEAL 22 | | KG_USAGE_SIGN 23 | | KG_USAGE_SEQ 24 | +--------------------------------------------------------------------+ 4. Adjustments to Previous Definitions 4.1. Quality of Protection The GSSAPI specification [GSSAPI] says that a zero QOP value indicates the "default". The original specification for the Kerberos 5 mechanism says that a zero QOP value (or a QOP value with the appropriate bits clear) means DES encryption. Rather than forcing the use of plain DES when the application doesn't use mechanism-specific QOP values, we redefine the explicit DES QOP value as a non-zero value, and define a triple-DES value as well. Then a zero value continues to imply the default, which would be triple-DES protection when given a triple-DES session key. Our values are: +--------------------------------------------------------------------+ | name value meaning | +--------------------------------------------------------------------+ | GSS_KRB5_INTEG_C_QOP_HMAC_SHA1 0x0004 SHA-1 HMAC, using | | key derivation | | | | GSS_KRB5_CONF_C_QOP_DES 0x0100 plain DES encryption | | | | GSS_KRB5_CONF_C_QOP_DES3_KD 0x0200 triple-DES with key | | derivation | +--------------------------------------------------------------------+ Rather than attempt to specify a generic mechanism for deriving a key of one type given a key of another type, and evaluate the security implications of using a short key to generate a longer key to satisfy the requested quality of protection, our implementation will simply Raeburn [Page 3]
INTERNET DRAFT Triple-DES for GSSAPI Kerberos November 2000 return an error if the nonzero QOP value specified does not correspond to the session key type. 4.2. MIC Sequence Number Encryption The sequence numbers are encrypted in the context key (as defined in [GSSAPI-KRB5] -- this will be either the Kerberos session key or asubkey provided by the context initiator), using whatever encryption system is designated by the type of that context key. The IV is formed from the first N bytes of the SGN_CKSUM field, where N is the number of bytes needed for the IV. (With all algorithms described here and in [GSSAPI-KRB5], the checksum is at least as large as the IV.) 4.3. Message Layout Both MIC and Wrap tokens, as defined in [GSSAPI-KRB5], contain an checksum field SGN_CKSUM. In [GSSAPI-KRB5], this field was specified as being 8 bytes long. We now change this size to be "defined by the checksum algorithm", and retroactively amend the descriptions of all the checksum algorithms described in [GSSAPI-KRB5] to explicitly specify 8-byte output. Application data continues to immediately follow the checksum field in the Wrap token. The revised message descriptions are thus: MIC token: Byte # Name Description ---------------------------------------------------------------------- 0..1 TOK_ID Identification field. 2..3 SGN_ALG Integrity algorithm indicator. 4..7 Filler Contains ff ff ff ff 8..15 SND_SEQ Sequence number field. 16..s+15 SGN_CKSUM Checksum of "to-be-signed data", calculated according to algorithm specified in SGN_ALG field. Raeburn [Page 4]
INTERNET DRAFT Triple-DES for GSSAPI Kerberos November 2000 Wrap token: Byte # 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. 4..5 SEAL_ALG Sealing algorithm indicator. 6..7 Filler Contains ff ff 8..15 SND_SEQ Encrypted sequence number field. 16..s+15 SGN_CKSUM Checksum of plaintext padded data, calculated according to algorithm specified in SGN_ALG field. s+16..last Data encrypted or plaintext padded data Where "s" indicates the size of the checksum. As indicated above in section 2, we define the HMAC SHA1 DES3-KD checksum algorithm to produce a 20-byte output, so encrypted data begins at byte 36. 5. Backwards Compatibility Considerations The context initiator should request of the KDC credentials using session-key cryptosystem types supported by that implementation; if the only types returned by the KDC are not supported by the mechanism implementation, it should indicate a failure. This may seem obvious, but early implementations of both Kerberos and the GSSAPI Kerberos mechanism supported only DES keys, so the cryptosystem compatibility question was easy to overlook. 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, administration of the server's Kerberos data (e.g., the service key) has to be done in communication with the KDC, and it is from the KDC that the client will request credentials. The KDC could therefore be tasked with limiting session keys for a given service to types actually supported by the Kerberos and GSSAPI software on the server. This does have a drawback for cases where a service principal name is used both for GSSAPI-based and non-GSSAPI-based communication (most notably the "host" service key), if the GSSAPI implementation does not understand triple-DES but the Kerberos implementation does. It means that triple-DES session keys cannot be issued for that service Raeburn [Page 5]
INTERNET DRAFT Triple-DES for GSSAPI Kerberos November 2000 principal, which keeps the protection of non-GSSAPI services weaker than necessary. It would also be possible to have clients attempt to get single-DES session keys before trying to get triple-DES session keys, and have the KDC refuse to issue the single-DES keys only for the most critical of services, for which single-DES protection is considered inadequate. However, that would eliminate the possibility of connecting with the more secure cryptosystem to any service that can be accessed with the weaker cryptosystem. For MIT's 1.2 release, we chose to go with the former approach, putting the burden on the KDC administration and gaining the best protection possible for GSSAPI services, possibly at the cost of weaker protection of non-GSSAPI Kerberos services running earlier versions of the software. 6. Security Considerations Various tradeoffs arise regarding the mixing of new and old software, or GSSAPI-based and non-GSSAPI Kerberos authentication. They are discussed in section 5. 7. References [EFF] Electronic Frontier Foundation, "Cracking DES: Secrets of Encryption Research, Wiretap Politics, and Chip Design", O'Reilly & Associates, Inc., May, 1998. [GSSAPI] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January, 2000. [GSSAPI-KRB5] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June, 1996. [KrbRev] Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network Authentication Service (V5)", draft-ietf-cat-kerberos- revisions-06.txt, July 4, 2000. 8. Author's Address Kenneth Raeburn Massachusetts Institute of Technology 77 Massachusetts Avenue Cambridge, MA 02139 9. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. Raeburn [Page 6]
INTERNET DRAFT Triple-DES for GSSAPI Kerberos November 2000 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. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." 10. Document Change History >From -00 to -01: Converted master to GNU troff and tbl, rewriting tables in the process. Specify informational category only. Modify some text to emphasize that this document intends to describe MIT's extensions. Point out that while EncryptedData for 3des-kd includes a checksum, DES3-KD GSS encryption does not. Shorten backwards-compatibility descriptions a little. Submit to Kerberos working group rather than CAT. Raeburn [Page 7]