-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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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.
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]
+\f
+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
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]
+\f
+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]
+\f
projects / krb5.git / commitdiff