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

from i-d repository

Browse Source 
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@9309 ec53bebd-3082-4978-b11e-865c3cabbd6b
This commit is contained in:
Assar Westerlund
2000-12-08 00:32:13 +00:00
parent af16cfb31b
commit e40fdaf463
1 changed files with 395 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

395
doc/standardisation/draft-raeburn-krb-gssapi-krb5-3des-01.txt Normal file
View File

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