Network Working Group                                            G. Zorn
Internet-Draft                                             Cisco Systems
Updates: 2865, 2866, 3576, 3579                                 T. Zhang
(if approved)                              3e Technologies International
Intended status: Informational                                 J. Walker
Expires: October 18, 2007                              Intel Corporation
                                                              J. Salowey
                                                           Cisco Systems
                                                          April 16, 2007


         RADIUS Attributes for the Delivery of Keying Material
                    draft-zorn-radius-keywrap-13.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

   This Internet-Draft will expire on October 18, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document defines a set of RADIUS Attributes designed to allow
   both the secure transmission of cryptographic keying material and
   strong authentication of any RADIUS message.



Zorn, et al.            Expires October 18, 2007                [Page 1]


Internet-Draft       RADIUS Keying Material Transfer          April 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Specification of Requirements  . . . . . . . . . . . . . . . .  3
   3.  Attributes . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     3.1.  Keying-Material  . . . . . . . . . . . . . . . . . . . . .  3
     3.2.  MAC-Randomizer . . . . . . . . . . . . . . . . . . . . . .  7
     3.3.  Message-Authentication-Code  . . . . . . . . . . . . . . .  8
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  Attribute Types  . . . . . . . . . . . . . . . . . . . . . 12
     4.2.  Attribute Values . . . . . . . . . . . . . . . . . . . . . 12
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   6.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 17
































Zorn, et al.            Expires October 18, 2007                [Page 2]


Internet-Draft       RADIUS Keying Material Transfer          April 2007


1.  Introduction

   Many remote access deployments (for example, deployments utilizing
   wireless LAN technology) require the secure transmission of
   cryptographic keying material from a RADIUS [RFC2865] server to a
   network access point.  Typically, this material is produced as a by-
   product of an EAP [RFC3748] authentication and is of a form that may
   be used in virtually any cryptographic algorithm after appropriate
   processing.

   This document defines a set of RADIUS Attributes that can be used to
   securely transfer cryptographic keying material using standard
   techniques with well understood security properties.  In addition,
   the Message-Authentication-Code Attribute may be used to provide
   strong authentication for any RADIUS message, including those used
   for accounting and dynamic authorization.

   Discussion of this draft may be directed to the authors.


2.  Specification of Requirements

   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 [RFC2119].


3.  Attributes

   The following subsections describe the Attributes defined by this
   document.  This specification concerns the following values:

      [TBD1] Keying-Material

      [TBD2] MAC-Randomizer

      [TBD3] Message-Authentication-Code

3.1.  Keying-Material

   Description

      This Attribute MAY be used to transfer cryptographic keying
      material from a RADIUS server to a client.

      It MAY be sent in request messages (e.g., Access-Request, etc.),
      as well; if the Keying-Material Attribute is present in a request,
      it SHOULD be taken as a hint by the server that the client prefers



Zorn, et al.            Expires October 18, 2007                [Page 3]


Internet-Draft       RADIUS Keying Material Transfer          April 2007


      this method of key delivery over others, the server is not
      obligated to honor the hint, however.  When the Keying-Material
      Attribute is included in a request message the Key ID, Lifetime,
      IV and Key Material fields MAY be omitted.

      If the client requires the use of the Keying-Material Attribute
      for keying material delivery and it is not present in the Access-
      Accept or Access-Challenge message, the client MAY ignore the
      message in question and end the user session.

      Any packet that contains a Keying-Material Attribute MUST also
      include the Message-Authentication-Code Attribute.

      Any packet that contains an instance of the Keying-Material
      Attribute MUST NOT contain an instance of any other attribute
      (e.g., MS-CHAP-MPPE-Keys [RFC2548], Tunnel-Password [RFC2868],
      etc.) encapsulating identical keying material.

      The Keying-Material Attribute MUST NOT be used to transfer long-
      lived keys (i.e., passwords) between RADIUS servers and clients.

      A summary of the Keying-Material attribute format is shown below.
      The fields are transmitted from left to right.




























Zorn, et al.            Expires October 18, 2007                [Page 4]


Internet-Draft       RADIUS Keying Material Transfer          April 2007


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     |    Reserved   |    Enc Type   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             App ID                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             KEK ID
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                KEK ID (cont'd)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                KEK ID (cont'd)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                KEK ID (cont'd)                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             KM ID
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                KM ID (cont'd)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                KM ID (cont'd)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                KM ID (cont'd)                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Lifetime                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               IV
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                  IV (cont'd)                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              Data
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



      Type

         [TBD1] for Keying-Material

      Length

         >= 24

      Reserved

         This field is reserved for future usage and MUST be zero-
         filled.





Zorn, et al.            Expires October 18, 2007                [Page 5]


Internet-Draft       RADIUS Keying Material Transfer          April 2007


      Enc Type

         The Enc Type field indicates the method used to encrypt the
         contents of the Data field.  This document defines only one
         value (decimal) for this field:

            0 AES Key Wrap with 128-bit KEK [RFC3394]

         Implementations MUST support Enc Type 0 (AES Key Wrap with 128-
         bit KEK); other values are to be assigned by IANA.

         Implementation Note

            A shared secret is used as the key-encrypting-key (KEK) for
            the AES key wrap algorithm.  Implementations SHOULD provide
            a means to provision a key (cryptographically separate from
            the normal RADIUS shared secret) to be used exclusively as a
            KEK.

      App ID

         The App ID field is 4 octets in length and identifies the type
         of application for which the key material is to be used.  This
         allows for multiple keys for different purposes to be present
         in the same message.  This document defines two values for the
         App ID:

            0 Unspecified

            1 EAP MSK

         Other values are to be assigned by IANA; further specification
         of the content of this field is outside the scope of this
         document.

      KEK ID

         The KEK ID field is 16 octets in length and contains an
         identifier for the KEK.  The KEK ID MUST refer to an encryption
         key of a type and length appropriate for use with the algorithm
         specified by the Enc Type field (see above).  This key is used
         to protect the contents of the Data field (below).  Further
         specification of the content of this field is outside the scope
         of this document.







Zorn, et al.            Expires October 18, 2007                [Page 6]


Internet-Draft       RADIUS Keying Material Transfer          April 2007


      KM ID

         The KM ID field is 16 octets in length and contains an
         identifier for the contents of the Data field.  The KM ID MAY
         be used by communicating parties to identify the material being
         transmitted.  The combination of App ID and KM ID MUST uniquely
         identify the keying material between the parties utilizing it.
         The KM ID is assumed to be known to the parties that derived
         the keying material.  Further specification of the content of
         this field is outside the scope of this document.

      Lifetime

         The Lifetime field is an integer [RFC2865] representing the
         period of time (in seconds) for which the keying material is
         valid.

         Note: Applications using this value SHOULD consider the
         beginning of the lifetime to be the point in time when the
         keying material is first used.

      IV

         The length of the IV field depends upon the value of the Enc
         Type field, but is fixed for any given value thereof.  When the
         value of the Enc Type field is 0 (decimal), the IV field MUST
         be 8 octets in length (as illustrated above) and the value of
         the IV field MUST be as specified in [RFC3394].

      Data

         The Data field is variable length and contains the actual
         encrypted keying material.

3.2.  MAC-Randomizer

   Description

      The MAC-Randomizer Attribute MUST be present in any message that
      includes an instance of the Message-Authentication-Code Attribute.
      The Random field MUST contain a 32 octet random number which
      SHOULD satisfy the requirements of [RFC4086].

      Implementation Note

         The Random field MUST be filled in before the MAC is computed.
         The MAC-Randomizer Attribute SHOULD be placed at the beginning
         of the RADIUS message if possible.



Zorn, et al.            Expires October 18, 2007                [Page 7]


Internet-Draft       RADIUS Keying Material Transfer          April 2007


      A summary of the MAC-Randomizer attribute format is shown below.
      The fields are transmitted from left to right.


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |           Random...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



      Type

         [TBD2] for MAC-Randomizer

      Length

         34

      Random

         This field MUST contain a 32 octet random number which SHOULD
         satisfy the requirements of [RFC4086].

3.3.  Message-Authentication-Code

   Description

      This Attribute MAY be used to "sign" messages to prevent spoofing
      If it is present in a request, the receiver should take this a
      hint that the sender prefers the use of this Attribute for message
      authentication; the receiver is not obligated to do so, however.

      The Message-Authentication-Code Attribute MUST be included in any
      message that contains a Key attribute.

      Any packet that contains an instance of the Message-
      Authentication-Code Attribute SHOULD NOT contain an instance of
      the Message-Authenticator Attribute [RFC3579].  If both attributes
      are to be included in a message (e.g., for backward compatibility
      in a network containing both old and new clients), the value of
      the Message-Authentication-Code Attribute MUST be computed first.

      If any message is received containing an instance of the Message-
      Authentication-Code Attribute, the receiver MUST calculate the
      correct value of the Message-Authentication-Code and silently
      discard the packet if the computed value does not match the value



Zorn, et al.            Expires October 18, 2007                [Page 8]


Internet-Draft       RADIUS Keying Material Transfer          April 2007


      received.

      If a received message contains an instance of the MAC-Randomizer
      Attribute (Section 3.2), the received MAC-Randomizer Attribute
      SHOULD be included in the computation of the Message-
      Authentication-Code Attribute sent in the response, as described
      below.

      A summary of the Message-Authentication-Code attribute format is
      shown below.  The fields are transmitted from left to right.


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     |    Reserved   |    MAC Type   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           MAC Key ID
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             MAC Key ID (cont'd)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             MAC Key ID (cont'd)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             MAC Key ID (cont'd)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             MAC...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



      Type

         [TBD3] for Message-Authentication-Code

      Length

         >20

      Reserved

         This field is reserved for future usage and MUST be zero-
         filled.

      MAC Type

         The MAC Type field specifies the algorithm used to create the
         value in the MAC field.  This document defines six values for
         the MAC Type field:



Zorn, et al.            Expires October 18, 2007                [Page 9]


Internet-Draft       RADIUS Keying Material Transfer          April 2007


            0 HMAC-SHA-1 [FIPS.180-2.2002] [RFC2104]

            1 HMAC-SHA-256 [FIPS.180-2.2002] [RFC4231]

            2 HMAC-SHA-512 [FIPS.180-2.2002] [RFC4231]

            3 CMAC-AES-128 [NIST.SP800-38B]

            4 CMAC-AES-192 [NIST.SP800-38B]

            5 CMAC-AES-256 [NIST.SP800-38B]

         Implementations MUST support MAC Type 0 (HMAC-SHA-1); other
         values are to be assigned by IANA.

      MAC Key ID

         The MAC Key ID field is 16 octets in length and contains an
         identifier for the key.  The MAC Key ID MUST refer to a key of
         a type and length appropriate for use with the algorithm
         specified by the MAC Type field (see above).  Further
         specification of the content of this field is outside the scope
         of this document.

      MAC

         Both the length and value of the MAC field depend upon the
         algorithm specified by the value of the MAC Type field.  If the
         algorithm specified is HMAC-SHA-1, HMAC-SHA-256 or HMAC-SHA-
         512, the MAC field MUST be 20, 32 or 64 octets in length,
         respectively.  If the algorithm specified is CMAC-AES-128,
         CMAC-AES-192 or CMAC-AES-256, the MAC field SHOULD be 64 octets
         in length.  The derivation of the MAC field value for all the
         algorithms specified in this document is identical, except for
         the algorithm used.  There are differences, however, depending
         upon whether the MAC is being computed for a request message or
         a response.  These differences are detailed below, with the
         free variable HASH-ALG representing the actual algorithm used.

         Request Messages

            For requests (e.g., CoA-Request [RFC3576], Accounting-
            Request [RFC2866], etc.), the value of the MAC field is a
            hash of the entire packet except the Request Authenticator
            in the header of the RADIUS packet, using a shared secret as
            the key, as follows.





Zorn, et al.            Expires October 18, 2007               [Page 10]


Internet-Draft       RADIUS Keying Material Transfer          April 2007


            MAC = MAC-ALG(Key, Type + Identifier + Length + Attributes)
            where '+' represents concatenation

            The MAC-Randomizer Attribute (Section 3.2) MUST be included
            in any request in which the Message-Authentication-Code
            Attribute is used.  The Random field of the MAC-Randomizer
            Attribute MUST be filled in before the value of the MAC
            field is computed.

            If the Message-Authenticator-Code Attribute is included in a
            client request, the server SHOULD ignore the contents of the
            Request Authenticator.

            Implementation Notes

               When the hash is calculated, both the MAC field of the
               Message-Authenticator-Code attribute and the String field
               of the Message-Authenticator Attribute (if any) MUST be
               considered to be zero-filled.

               Implementations SHOULD provide a means to provision a key
               (cryptographically separate from the normal RADIUS shared
               secret) to be used exclusively in the generation of the
               Message-Authentication-Code.

         Response Messages

            For responses (e.g., CoA-ACK [RFC3576], Accounting-Response
            [RFC2866], etc.), the value of the MAC field is a hash of
            the entire packet except the Response Authenticator in the
            header of the RADIUS packet using a shared secret as the
            key, as follows.

            MAC = HASH-ALG(Key, Type + Identifier + Length + Attributes)
            where '+ ' represents concateation

            If the request contained an instance of the MAC-Randomizer
            Attribute and the responder wishes to include an instance of
            the Message-Authentication-Code Attribute in the
            corresponding response, then the MAC-Randomizer Attribute
            from the request MUST be included in the response.

            If the Message-Authenticator-Code Attribute is included in a
            server response, the client SHOULD ignore the contents of
            the Response Authenticator.






Zorn, et al.            Expires October 18, 2007               [Page 11]


Internet-Draft       RADIUS Keying Material Transfer          April 2007


            Implementation Notes

               When the hash is calculated, both the MAC field of the
               Message-Authenticator-Code attribute and the String field
               of the Message-Authenticator Attribute (if any) MUST be
               considered to be zero-filled.

               The Message-Authentication-Code Attribute MUST be created
               and inserted in the packet before the Response
               Authenticator is calculated.

               Implementations SHOULD provide a means to provision a key
               (cryptographically separate from the normal RADIUS shared
               secret) to be used exclusively in the generation of the
               Message-Authentication-Code.


4.  IANA Considerations

   This section explains the criteria to be used by the IANA for
   assignment of numbers within namespaces defined within this document.
   The "Specification Required" policy is used here with the meaning
   defined in BCP 26 [RFC2434].

4.1.  Attribute Types

   Upon publication of this document as an RFC, IANA must assign numbers
   to the Keying-Material [TBD1], MAC-Randomizer [TBD2] and Message-
   Authentication-Code [TBD3] Attributes.

4.2.  Attribute Values

   As defined in Section 3.1, numbers may need to be assigned for future
   values of the Enc Type field of the Keying-Material attribute.  These
   numbers may be assigned by applying the "Specification Required"
   policy.  In particular, specifications MUST define the length of the
   IV field for the algorithm used.

   As defined in Section 3.2, numbers may need to be assigned for future
   values of the MAC Type field of the Message-Authentication-Code
   attribute.  These numbers may be assigned by applying the
   "Specification Required" policy.

   As defined in Section 3.2, numbers may need to be assigned for future
   values of the App ID field of the Keying-Material attribute.  These
   numbers may be assigned by applying the "First Come First Served"
   policy.




Zorn, et al.            Expires October 18, 2007               [Page 12]


Internet-Draft       RADIUS Keying Material Transfer          April 2007


5.  Security Considerations

   It is RECOMMENDED in this memo that two new keys be shared by the
   RADIUS client and server.  If implemented, these two keys MUST be
   different from each other and SHOULD NOT be based on a password.
   These two keys SHOULD be cryptographically independent of the RADIUS
   shared secret used in calculating the Response Authenticator
   [RFC2865], Request Authenticator [RFC2866] [RFC3576] and Message-
   Authenticator Attribute [RFC3579]; otherwise if the shared secret is
   broken, all is lost.

   To avoid the possibility of collisions, the same MAC key SHOULD NOT
   be used with more than 2^(n/2) messages, where 'n' is the length of
   the MAC value in octets.

   If a packet that contains an instance of the Keying-Material
   Attribute also contains an instance of another, weaker key transport
   attribute (e.g., MS-MPPE-Recv-Key [RFC2548]) encapsulating identical
   keying material, then breaking the weaker attribute might facilitate
   a known-plaintext attack against the KEK.


6.  Contributors

   Hao Zhou, Nancy Cam-Winget, Paul Funk and John Fossaceca all
   contributed to this document.


7.  Acknowledgements

   Thanks (in no particular order) to Keith McCloghrie, Kaushik Narayan,
   Murtaza Chiba, Bill Burr, Russ Housley, David McGrew, Pat Calhoun,
   Joel Halpern, Jim Schaad and Greg Weber for useful feedback.


8.  References

8.1.  Normative References

   [FIPS.180-2.2002]
              National Institute of Standards and Technology, "Secure
              Hash Standard", FIPS PUB 180-2, August 2002, <http://
              .nist.gov/publications/fips/fips180-2/
              fips180-2withchangenotice.pdf>.

   [NIST.SP800-38B]
              Dworkin, M., "Recommendation for Block Cipher Modes of
              Operation: The CMAC Mode for Authentication", May 2005, <h



Zorn, et al.            Expires October 18, 2007               [Page 13]


Internet-Draft       RADIUS Keying Material Transfer          April 2007


              ttp://csrc.nist.gov/CryptoToolkit/modes/
              800-38_Series_Publications/SP800-38B.pdf>.

   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              April 1992.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              February 1997.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

   [RFC2866]  Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

   [RFC2868]  Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
              M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol
              Support", RFC 2868, June 2000.

   [RFC3394]  Schaad, J. and R. Housley, "Advanced Encryption Standard
              (AES) Key Wrap Algorithm", RFC 3394, September 2002.

   [RFC3575]  Aboba, B., "IANA Considerations for RADIUS (Remote
              Authentication Dial In User Service)", RFC 3575,
              July 2003.

   [RFC3576]  Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
              Aboba, "Dynamic Authorization Extensions to Remote
              Authentication Dial In User Service (RADIUS)", RFC 3576,
              July 2003.

   [RFC3579]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
              Dial In User Service) Support For Extensible
              Authentication Protocol (EAP)", RFC 3579, September 2003.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

   [RFC4231]  Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-
              224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512",



Zorn, et al.            Expires October 18, 2007               [Page 14]


Internet-Draft       RADIUS Keying Material Transfer          April 2007


              RFC 4231, December 2005.

8.2.  Informative References

   [RFC2548]  Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
              RFC 2548, March 1999.

   [RFC3078]  Pall, G. and G. Zorn, "Microsoft Point-To-Point Encryption
              (MPPE) Protocol", RFC 3078, March 2001.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.


Authors' Addresses

   Glen Zorn
   Cisco Systems
   2901 Third Avenue, Suite 600
   SEA1/5/
   Seattle, WA  98121
   US

   Phone: +1 (425) 344 8113
   Email: gwz@cisco.com


   Tiebing Zhang
   3e Technologies International
   700 King Farm Blvd.
   Rockville, MD  20850
   US

   Phone: +1 (301) 944-1322
   Email: tzhang@3eti.com


   Jesse Walker
   Intel Corporation
   JF3-206
   2111 N.E. 25th Ave
   Hillsboro, OR  97214-5961
   US

   Phone: +1 (503) 712-1849
   Email: jesse.walker@intel.com




Zorn, et al.            Expires October 18, 2007               [Page 15]


Internet-Draft       RADIUS Keying Material Transfer          April 2007


   Joseph Salowey
   Cisco Systems
   2901 Third Avenue
   SEA1/6/
   Seattle, WA  98121
   US

   Phone: +1 (206) 256-3380
   Email: jsalowey@cisco.com










































Zorn, et al.            Expires October 18, 2007               [Page 16]


Internet-Draft       RADIUS Keying Material Transfer          April 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Zorn, et al.            Expires October 18, 2007               [Page 17]