diff options
Diffstat (limited to 'crypto/heimdal/doc/standardisation/draft-raeburn-krb-gssapi-krb5-3des-01.txt')
-rw-r--r-- | crypto/heimdal/doc/standardisation/draft-raeburn-krb-gssapi-krb5-3des-01.txt | 395 |
1 files changed, 0 insertions, 395 deletions
diff --git a/crypto/heimdal/doc/standardisation/draft-raeburn-krb-gssapi-krb5-3des-01.txt b/crypto/heimdal/doc/standardisation/draft-raeburn-krb-gssapi-krb5-3des-01.txt deleted file mode 100644 index 64ca1ac..0000000 --- a/crypto/heimdal/doc/standardisation/draft-raeburn-krb-gssapi-krb5-3des-01.txt +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - -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] - |