diff options
| -rw-r--r-- | src/lib/gssapi/krb5/3des.txt | 274 |
1 files changed, 274 insertions, 0 deletions
diff --git a/src/lib/gssapi/krb5/3des.txt b/src/lib/gssapi/krb5/3des.txt new file mode 100644 index 0000000000..f39c6fce6e --- /dev/null +++ b/src/lib/gssapi/krb5/3des.txt @@ -0,0 +1,274 @@ +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 + +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. + +2. New Algorithm Identifiers + + One new sealing algorithm is defined, for use in WRAP tokens: + + 02 00 - DES3-KD + + 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. + + One new signing algorithm is defined, for use in MIC, Wrap, and + Delete tokens: + + 04 00 - HMAC SHA1 DES3-KD + + 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.] + + 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. + +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: + + #define KG_USAGE_SEAL 22 + #define KG_USAGE_SIGN 23 + #define 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 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. + + Our values are: + + GSS_KRB5_INTEG_C_QOP_HMAC_SHA1 0x0004 + /* SHA-1 checksum encrypted with 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 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.] + +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: + + 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 + + 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 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. + + 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. + + 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.] + +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. + +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-05.txt, March 10, 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. + + 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." |