Technical Summary
This draft describes the rc4 Kerberos encryption types implemented
originally in Windows 2000.
Working Group Summary
This document is not the product of any working group but has been
reviewed by members of the Kerberos working group.
Protocol Quality
This document was reviewed by Sam Hartman and Ken Raeburn for the
IESG. These encryption types have been implemented in a
wide variety of Kerberos implementations from Microsoft and other
vendors. The IETF Kerberos community strongly supported the
publication of this document as an informational document in order to
document these encryption types. The reliance on md4 and the concern
about RC4 distinguishers makes these encryption types unsuitable for a
standards track protocol.
Note to RFC Editor
1. section 1, paragraph 1
REPLACE OLD:
Furthermore, 3DES is not available
for export, and there was a desire to use a single flavor of
encryption in the product for both US and international products.
WITH NEW:
Furthermore, 3DES is not available
for export when windows 2000 was released, and there was a desire to
use a single flavor of
encryption in the product for both US and international products.
2. section 10, paragraph 1.
REPLACE OLD:
This document has no actions for IANA.
With NEW:
Section 5 of this document defines two Kerberos encryption types 23
and 24. The Kerberos parameters registration page at
http://www.iana.org/assignments/kerberos-parameters should be updated to
reference this document for these two encryption types.
3. on page 6, starting at the 3rd line
REPLACE OLD:
if (export){
*((DWORD *)(L40+10)) = T;
HMAC (K, L40, 10 + 4, K1);
}
else
{
HMAC (K, &T, 4, K1);
}
WITH NEW:
if (export){
*((DWORD *)(L40+10)) = T;
K1 = HMAC(K, L40); // where the length of L40 in
octets is 14
}
else
{
K1 = HMAC(K, &T); // where the length of T in octets
is 4
}
IESG Note
This document documents the RC4 Kerberos encryption types first
introduced in Microsoft Windows 2000. Since then, these
encryption types have been implemented in a number of Kerberos
implementations. The IETF Kerberos community supports publishing
this specification as an informational document in order to
describe this widely implemented technology. However, while these
encryption types provide the operations necessary to implement the
base Kerberos specification [RFC4120], they do not provide all the
required operations in the Kerberos cryptography framework
[RFC3961]. As a result, it is not generally possible to implement
potential extensions to Kerberos using these encryption
types. The Kerberos encryption type negotiation mechanism
[RFC4537] provides one approach for using such extensions even when
a Kerberos infrastructure uses long-term RC4 keys. Because this
specification does not implement operations required by RFC 3961
and because of security concerns with the use of RC4 and MD4
discussed in Section 8, this specification is not appropriate for
publication on the standards track.
Note to IANA: the rfc-editor note introduces new iana actions.