877313e435
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@12581 ec53bebd-3082-4978-b11e-865c3cabbd6b
462 lines
20 KiB
Plaintext
462 lines
20 KiB
Plaintext
|
||
|
||
|
||
<Kerberos Working Group> 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
|