From 877313e435d593fde6b391827bb5da876458449d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Love=20H=C3=B6rnquist=20=C3=85strand?= Date: Sun, 17 Aug 2003 19:12:14 +0000 Subject: [PATCH] x git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@12581 ec53bebd-3082-4978-b11e-865c3cabbd6b --- .../draft-ms-krb-wg-gssapi-cfx-00.txt | 461 ++++++++++++++++++ 1 file changed, 461 insertions(+) create mode 100644 doc/standardisation/draft-ms-krb-wg-gssapi-cfx-00.txt diff --git a/doc/standardisation/draft-ms-krb-wg-gssapi-cfx-00.txt b/doc/standardisation/draft-ms-krb-wg-gssapi-cfx-00.txt new file mode 100644 index 000000000..0f959cb8e --- /dev/null +++ b/doc/standardisation/draft-ms-krb-wg-gssapi-cfx-00.txt @@ -0,0 +1,461 @@ + + + + Larry Zhu +Internet Draft Microsoft +Updates: 1964 Karthik Jaganathan +Category: Standards Track Microsoft +draft-ietf-krb-wg-gssapi-cfx-00.txt August 16, 2003 + Expires: February 16, 2004 + + Crypto Profile Based Support for the Inclusion of New Encryption and + Checksum Algorithms in the Kerberos V5 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 + + [KCRYPTO] introduced a generic framework for the inclusion of new + encryption and checksum algorithms to be used in the Kerberos V5 + protocol. [AES-KRB5] describes a crypto profile (per [KCRYPTO]) for + AES. This document introduces a generic method for adding new + crypto-systems to the GSSAPI-KerberosV5 mechanism based on crypto + profiles as defined in [KCRYPTO]. It also describes the use of AES + encryption for GSSAPI as an example of this new method. + + +2. Conventions used in this document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in + this document are to be interpreted as described in RFC-2119 [2]. + + +3. Introduction + + [GSSAPI-KRB5] describes the GSSAPI mechanism for Kerberos V5. It + defines the format of context initiation, per-message and context + deletion tokens. When adding new crypto system support, the + + +Zhu Standards Trace - February 16, 2003 1 + Crypto Profile Support for Kerberos GSSAPI August 2003 + + + approach taken in [GSSAPI-KRB5] is to add algorithm identifiers for + each new cryptosystem. + + The approach taken in this document is to use the same encryption + and checksum algorithms specified by the crypto profile for the + session key or subkey that is created during context negotiation. + Message layouts of the per-message and context deletion tokens are + revised to remove algorithm indicators and add extra information to + support the generic crypto framework [KCRYPTO]. + + "Newer" encryption and checksum types MUST use the new token formats + defined in this document. Older encryption and checksum types SHALL + NOT use these new token formats. The term "newer" is more precisely + defined in [KRBCLAR]. + + Note that in this document, "AES" is used for brevity to refer + loosely to either aes128-cts-hmac-sha1-96 or aes256-cts-hmac-sha1-96 + as defined in [AES-KRB5]. + +4. Quality of Protection and Algorithm Identifiers + + The GSSAPI specification [GSSAPI] provides for QOP values that can + be used by the application to request a certain type of encryption + or signing. A zero QOP value is used to indicate the "default" + protection; applications which use the default QOP are not + guaranteed to be portable across implementations or even inter- + operate with different deployment configurations of the same + implementation. Using an algorithm that is different from the one + for which the key is defined may not be appropriate. Therefore, when + the new method in this document is used, the QOP value is ignored. + + The encryption and checksum algorithms in per-message and context + deletion tokens are now implicitly defined by the algorithms + associated with the session and subkey. Algorithms identifiers are + therefore no longer needed and removed from the token headers. + +5. Key Derivation + + To limit the exposure of a given key, [KCRYPTO] adopted "one-way" + "entropy-preserving" derived keys, for different purposes or key + usages, from a base key or protocol key. This document defines four + key usage values below for signing and sealing messages: + + Name value + ------------------------------------- + KG-USAGE-ACCEPTOR-SIGN 22 + KG-USAGE-ACCEPTOR-SEAL 23 + KG-USAGE-INITIATOR-SIGN 24 + KG-USAGE-INITIATOR-SEAL 25 + + + When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is + used as the usage number in the key derivation function for deriving + keys to be used in MIC and context deletion tokens, and KG-USAGE- +Zhu Standards Track - February 16, 2004 2 + Crypto Profile Support for Kerberos GSSAPI August 2003 + + + ACCEPTOR-SEAL is used for Wrap tokens; similarly when the sender is + the context initiator, KG-USAGE-INITIATOR-SIGN is used as the usage + number in the key derivation function for MIC and context deletion + tokens, KG-USAGE-INITIATOR-SEAL is used for Wrap Tokens. Even if + the Wrap token does not provide for confidentiality the same usage + values specified above are used. + +6. Token Formats and Definitions + + The new token formats defined in this document are designed to + accommodate the requirements of newer crypto systems. Certain + implementations of GSSAPI, such as SSPI, allow for "scatter-gather" + and in-place encryption, mostly by leveraging low level details of + crypto systems. The token layouts have been designed to satisfy the + above requirements without incurring significant performance + penalties or loosing generality. + + The design along with the rationale behind it, is discussed in + detail in the following sections. + +6.1. Sequence Number and Direction Indicators + + The sequence number for any per-message or context deletion token is + a 64 bit integer (expressed in big endian order). One separate byte + is used as the directional indicator: the hex value FF if the sender + is the context acceptor, 00 otherwise. Both the sequence number and + the directional indicator are protected as specified in section 6.2. + +6.2. Encryption and Checksum Operations + + The encryption algorithms defined by the crypto profiles provide for + integrity protection. Therefore no separate checksum is needed. + + In Wrap tokens that provide for confidentiality, the "header" (the + first 16 bytes of the Wrap token) is appended to the plaintext data + before encryption. Hence the resulting Wrap token is {"header" | + encrypt(plaintext-data | "header")}, where encrypt() is the + encryption operation defined in the crypto profile. In Wrap tokens + that do not provide for confidentiality, the checksum is calculated + over the plaintext data concatenated with the token header (the + first 16 bytes of the Wrap token). Hence the resulting Wrap token + is {"header" | plaintext-data | get_mic(plaintext-data | "header")}, + where get_mic() is the checksum operation defined in the crypto + profile. The parameters for the key and the cipher-state in the + encrypt() and get_mic() operations have been omitted for brevity. + + The resulting Wrap tokens bind the data to the token header, + including the sequence number, directional indicator, and the + rotation count. + + [With AEAD, Wrap tokens with confidentiality do not need to encrypt + the header and the overhead can be reduced slightly] + + +Zhu Standards Track - February 16, 2004 3 + Crypto Profile Support for Kerberos GSSAPI August 2003 + + + For MIC tokens, the checksum is first calculated over the token + header (the first 16 bytes of the MIC token) and then the to-be- + signed plaintext data. + + For context deletion tokens, the checksum is calculated over the + token header (the first 16 bytes of the context deletion token). + + When AES is used, the checksum algorithm is HMAC_SHA1_96 and the + checksum size is 12 bytes. Data is pre-pended with a 16 byte + confounder before encryption, and no padding is needed. + +6.3. RRC Field + + A new field, called "RRC" (Right Rotation Count), is added to allow + the data to be encrypted in place. The resulting Wrap token in the + previous section, excluding the first 16 bytes of the token header, + is rotated to the right by "RRC" bytes. The net result is that + "RRC" bytes of trailing octets are moved toward the header. + Consider the following as an example of this rotation operation: + Assume that the RRC value is 3 and the token before the rotation is + {"header" | aa | bb | cc | dd | ee | ff | gg | hh}, the token after + rotation would be {"header" | ff | gg | hh | aa | bb | cc | dd | ee + }, where {aa | bb | cc |...| hh} is used to indicate the byte + sequence. + + The RRC field is expressed as a two octet integer in big endian + order. + + The rotation count value is chosen by the sender based on + implementation details, and the receiver MUST be able to interpret + all possible rotation count values. + +6.4. EC Field + + The decryption operation in the crypto profile may not always return + the exact length of the plaintext data. An "EC"(Extra Count) field + is added to the Wrap() token header to indicate the number of bytes + that have been added to the end of the plaintext data before + encryption. The "EC" field is a two byte integer expressed in big + endian order and it should be 00 00 if confidentiality is not + provided for by the Wrap tokens. + +6.5. Seal Field + + The Seal field in Wrap tokens is used to indicate whether + confidentiality is provided for. If confidentiality is provided for + by the Wrap token, this field contains the hex value FF, otherwise it + contains the hex value 00. + +6.6. Message Layout for Per-message and Context Deletion Tokens + + The new message layouts are as follows. + + MIC Token: +Zhu Standards Track - February 16, 2004 4 + Crypto Profile Support for Kerberos GSSAPI August 2003 + + + + Byte no Name Description + 0..1 TOK_ID Identification field. + Tokens emitted by GSS_GetMIC() + contain the hex value 04 04 in + this field. + 2..2 Direction Hex value FF if the sender is the + context acceptor, 00 otherwise. + 3..7 Filler Contains 5 bytes of hex value FF. + 8..15 SND_SEQ Sequence number field in + cleartext, in big endian order. + 16.. SGN_CKSUM Checksum of byte 0..15 and the + "to-be-signed" data, where the + checksum algorithm is defined by + the crypto profile for the + session key or subkey. + + + The Filler field is included in the checksum calculation for + simplicity. This is common to both MIC and context deletion token + checksum calculations. + + Wrap Token: + + Byte no Name Description + 0..1 TOK_ID Identification field. + Tokens emitted by GSS_Wrap() + contain the hex value 05 04 + in this field. + 2..2 Direction Hex value FF if the sender is the + context acceptor, 00 otherwise. + 3..3 Seal Confidentiality indicator: hex + value FF if confidentiality is + provided for, 00 otherwise. + 4..5 EC Contains the "extra count" field, + in big endian order as described in + section 6.4. + 6..7 RRC Contains the "right rotation + count" in big endian order, as + described in section 6.3. + 8..15 SND_SEQ Sequence number field in + cleartext, in big endian order. + 16.. Data Encrypted or plaintext data, as + described in section 6.2, where + the encryption or checksum + algorithm is defined by the crypto + profile for the session key or + subkey. + + + Context Deletion Token: + + Byte no Name Description +Zhu Standards Track - February 16, 2004 5 + Crypto Profile Support for Kerberos GSSAPI August 2003 + + + 0..1 TOK_ID Identification field. + Tokens emitted by + GSS_Delete_sec_context() contain + the hex value 04 05 in this + field. + 2..2 Direction Hex value FF if the sender is the + context acceptor, 00 otherwise. + 3..7 Filler Contains 5 bytes of hex value FF. + 8..15 SND_SEQ Sequence number field in + cleartext, in big endian order. + 16.. SGN_CKSUM Checksum of byte 0..15, where the + checksum algorithm is defined by + the crypto profile for the + session key or subkey. + + +7. Backwards compatibility considerations + + The new token formats defined in this document will only be + recognized by new implementations. A MIC or wrap token generated + with the algorithms defined in this document will not be recognized + by an older implementation that only recognizes the algorithms + defined in [GSSAPI-KRB5]. To address this, implementations can + always use the explicit sign or seal algorithm in [GSSAPI-KRB5] when + the key type corresponds to those algorithms. An alternative + approach might be to retry sending the message with the sign or seal + algorithm explicitly defined as in [GSSAPI-KRB5]. However this would + require the use of a mechanism such as [SPNEGO] to securely + negotiate the algorithm or the use out of band mechanism to choose + appropriate algorithms. For this reason, it is RECOMMENDED that the + use of the new token formats defined in this document be confined + only for "newer encryption and checksum" described by a crypto + profile. + +8. Security Considerations + + It is possible that the KDC returns a session-key type that is not + supported by the GSSAPI implementation (either on the client and the + server). In this case the implementation MUST not try to use the key + with a supported cryptosystem. This will ensure that no security + weaknesses arise due to the use of an inappropriate key with an + encryption algorithm. + + In addition the security problem described in [3DES] arising from + the use of a service implementation with a GSSAPI mechanism + supporting only DES and a Kerberos mechanism supporting both DES and + Triple DES is actually a more generic one. It arises whenever the + GSSAPI implementation does not support a stronger cryptosystem + supported by the Kerberos mechanism. KDC administrators desiring to + limit the session key types to support interoperability with such + GSSAPI implementations should carefully weigh the reduction in + protection offered by such mechanisms against the benefits of + interoperability. +Zhu Standards Track - February 16, 2004 6 + Crypto Profile Support for Kerberos GSSAPI August 2003 + + + + It is recommended by some cryptographers that the output of a + checksum used with an encryption algorithm should have the same + strength as the key in use. In this regard standardization work for + SHA-256 and SHA-512 to be used with AES is currently in progress. + This document retains the use of HMAC_SHA1_96 as specified in the + [AES-KRB5] draft. The use of SHA-256 or SHA-512 with AES will + require new crypto profiles and there should not be any further + changes needed to this document. + +9. Acknowledgments + + + The authors wish to acknowledge the contributions from the following + individuals: + + Ken Raeburn and Nicolas Willams corrected many of our errors in the + use of generic profiles and were instrumental in the creation of this + draft. Sam Hartman and Ken Raeburn suggested the "floating trailer" + idea. + + Sam Hartman and Nicolas Williams recommended the replacing our + earlier key derivation function for directional keys with different + key usage numbers for each direction as well as retaining the + directional bit for maximum compatibility. + + Paul Leach provided numerous suggestions and comments. Scott Field, + Richard Ward, Dan Simon also provided valuable inputs on this draft. + +10. References + + [AES] National Institute of Standards and Technology, U.S. + Department of Commerce, "Advanced Encryption Standard", Federal + Information Processing Standards Publication 197, Washington, DC, + November 2001. + + [AES-KRB5] Raeburn, K., "AES Encryption for Kerberos 5", draft- + raeburn-krb-rijndael-krb-05.txt, June, 2003. Work in progress. + + [DES3] Raeburn, K., "Triple-DES Support for the Kerberos 5 GSSAPI + Mechanism", draft-raeburn-gssapi-krb5-3des-XX.txt in the MIT + distribution, June 2000. + + + [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. + + [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for + Kerberos 5", draft-ietf-krb-wg-crypto-05.txt, June, 2003. Work in + progress. + +Zhu Standards Track - February 16, 2004 7 + Crypto Profile Support for Kerberos GSSAPI August 2003 + + + + [KRBCLAR] Neuman, C., Kohl, J., Ts'o T., Yu T., Hartman, S., + Raeburn, K., "The Kerveros Network Authentication Service (V5)", + http://www.isi.edu/people/bcn/draft-kerberos-rev.html/krb- + clarifications-00-020222.txt, February,2002. Work in progress. + + [SPNEGO] Baize, E., Pinkas D., "The Simple and Protected GSS-API + Negotiation Mechanism.", RFC 2478, December 1998. + +11. Author's Address + + Larry Zhu + One Microsoft Way + Redmond, WA 98052 - USA + EMail: LZhu@microsoft.com + + Karthik Jaganathan + One Microsoft Way + Redmond, WA 98052 - USA + EMail: karthikj@microsoft.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zhu Standards Track - February 16, 2004 8