The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows
RFC 4757

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>
Subject: Document Action: 'The RC4-HMAC Kerberos Encryption 
         Types Used by Microsoft Windows' to Informational RFC 

The IESG has approved the following document:

- 'The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows '
   <draft-jaganathan-rc4-hmac-04.txt> as an Informational RFC

This document has been reviewed in the IETF but is not the product of an
IETF Working Group. 

The IESG contact person is Sam Hartman.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-jaganathan-rc4-hmac-04.txt

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.