oysteikt/heimdal
0
0
Fork 0
Code Issues 5 Pull Requests Releases Activity

x

Browse Source 
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@12581 ec53bebd-3082-4978-b11e-865c3cabbd6b
This commit is contained in:
Love Hörnquist Åstrand
2003-08-17 19:12:14 +00:00
parent 5cff5e1802
commit 877313e435
1 changed files with 461 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

461
doc/standardisation/draft-ms-krb-wg-gssapi-cfx-00.txt Normal file
View File

@@ -0,0 +1,461 @@
<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