From c0f1b9f48ed161d2dee18036d582219b485dea4a Mon Sep 17 00:00:00 2001 From: Ken Raeburn Date: Fri, 8 Dec 2000 04:55:09 +0000 Subject: [PATCH] check in -01 draft git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@12888 dc483132-0cff-0310-8789-dd5450dbe970 --- src/lib/gssapi/krb5/3des.txt | 489 ++++++++++++++++++++++------------- 1 file changed, 305 insertions(+), 184 deletions(-) diff --git a/src/lib/gssapi/krb5/3des.txt b/src/lib/gssapi/krb5/3des.txt index f39c6fce6..64ca1ac49 100644 --- a/src/lib/gssapi/krb5/3des.txt +++ b/src/lib/gssapi/krb5/3des.txt @@ -1,169 +1,249 @@ -CAT Working Group K. Raeburn -Internet-draft MIT -Category: June xx, 2000 -Updates: RFC 1964 -Document: draft-raeburn-gssapi-krb5-3des-XX.txt - Triple-DES Support for the Kerberos 5 GSSAPI Mechanism + + + + + +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 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. - - 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 a better approach. - Efforts to produce such a specification are under way. - - In the interest of providing increased security in the near term, - however, MIT is adding support for triple-DES to the existing - mechanism implementation we ship, as described here. + 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: + One new sealing algorithm is defined, for use in Wrap tokens. + - 02 00 - DES3-KD + +--------------------------------------------------------------------+ + | name octet values | + +--------------------------------------------------------------------+ + | DES3-KD 02 00 | + +--------------------------------------------------------------------+ This algorithm uses triple-DES with key derivation, with a usage - value KG_USAGE_SEAL. Padding is still to 8-byte multiples, and the - IV for encrypting application data is zero. + 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: + Delete tokens. + - 04 00 - HMAC SHA1 DES3-KD + +--------------------------------------------------------------------+ + | 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 (should be described) in [KrbRev]. - [XXX: The current [KrbRev] description refers to out-of-date I-Ds - from Marc Horowitz. The text in [KrbRev] may be inadequate to - produce an interoperable implementation.] + 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: + list defined in [KrbRev]; one for signing messages, one for sealing + messages, and one for encrypting sequence numbers: + - #define KG_USAGE_SEAL 22 - #define KG_USAGE_SIGN 23 - #define KG_USAGE_SEQ 24 + +--------------------------------------------------------------------+ + | 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. + 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 continue to force the use of plain DES when the - application doesn't use mechanism-specific QOP values, the better - choice appears to be to redefine the DES QOP value as some 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. + 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: - GSS_KRB5_INTEG_C_QOP_HMAC_SHA1 0x0004 - /* SHA-1 checksum encrypted with key derivation */ + +--------------------------------------------------------------------+ + | 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 - 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 open the question of whether to specify means for - deriving a key of one type given a key of another type, and the - security implications of whether to generate a long key from a - shorter one, our implementation will simply return an error if the - QOP value specified does not correspond to the session key type. - [XXX: Not implemented yet. Currently an error is reported for all - non-zero values. This should be changed before the release, so an - application can insist on getting no less than triple-DES - protection.] +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.) + 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. + 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: - - Byte no 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. - - Wrap: - - 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. - 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 + 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. @@ -175,52 +255,57 @@ Status of this Memo 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. + 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 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, - 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 principal, which keeps the - protection of non-GSSAPI services weaker than necessary. However, - in the most recent MIT releases thus far, while triple-DES support - has been present, it has required additional work to enable, so it - should not be in use for many services. + 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. + connecting with the more secure cryptosystem to any service that can + be accessed with the weaker cryptosystem. - We have chosen 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 protection of - non-GSSAPI Kerberos services running earlier versions of the - software. - [XXX: Actually, we haven't entirely decided and cast it in stone - yet, it's just what I've implemented; it's easy to change.] + 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 4. + 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 @@ -235,40 +320,76 @@ Status of this Memo RFC 1964, June, 1996. [KrbRev] Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network - Authentication Service (V5)", - draft-ietf-cat-kerberos-revisions-05.txt, March 10, 2000. + 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 + 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. - - 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." + 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] + -- 2.26.2