[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09

Network Working Group                                       G. Zorn, Ed.
Internet-Draft                                            Aruba Networks
Updates: 2865 (if approved)                                      H. Zhou
Intended status: Standards Track                              J. Salowey
Expires: August 24, 2008                                   Cisco Systems
                                                       February 21, 2008


                    Session Key Transport in RADIUS
                    draft-zorn-radius-keyreq-09.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 August 24, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This document describes an extension to the RADIUS protocol designed
   to support requests for, and delivery of, session key material
   between RADIUS clients and servers.

   The messages described in this document may be used for a wide
   variety of keying applications.



Zorn, et al.             Expires August 24, 2008                [Page 1]


Internet-Draft       Session Key Transport in RADIUS       February 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Specification of Requirements  . . . . . . . . . . . . . . . .  3
   3.  Packet Format  . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Packet Types . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Key-Request  . . . . . . . . . . . . . . . . . . . . . . .  7
     4.2.  Key-Response . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
   Intellectual Property and Copyright Statements . . . . . . . . . . 12






































Zorn, et al.             Expires August 24, 2008                [Page 2]


Internet-Draft       Session Key Transport in RADIUS       February 2008


1.  Introduction

   AAA servers are a central repository of authentication credentials.
   Since authentication is typically a prerequisite to key distribution,
   it is natural for AAA servers to be able to deliver keys to clients
   for various purposes.  One example of this is the provisioning of the
   link layer encryption keys used in IEEE 802.11 and 802.1X. There is a
   wide variety of additional uses for key distribution in RADIUS.

   This document describes an extension to the RADIUS protocol designed
   to support requests for, and delivery of, session key material
   between RADIUS clients and servers.  One example of the applicability
   of these extensions is the case where the end of a session key's
   lifetime [KEYWRAP] is approaching, but the messages described in this
   document may be used for a wide variety of keying applications.

   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.  Packet Format

   Exactly one RADIUS packet is encapsulated in the UDP Data field
   [RFC0768] where the UDP Destination Port field indicates 1812
   (decimal).

   When a reply is generated, the source and destination ports are
   reversed.

   A summary of the RADIUS data format is shown below.  The fields are
   transmitted from left to right.














Zorn, et al.             Expires August 24, 2008                [Page 3]


Internet-Draft       Session Key Transport in RADIUS       February 2008


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Code      |  Identifier   |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                         Authenticator                         |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Attributes ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-

   Code

      The Code field is one octet, and identifies the type of RADIUS
      packet.

      If a RADIUS server receives a packet with an unrecognized Code
      field, the server SHOULD respond with an Error-Notification
      message containing instances of the Error-Code and Unrecognized-
      Packet-Type Attributes [ERRMSG]; if the server does not support
      the Error-Notification message, then the invalid packet MUST be
      silently discarded.

      If a RADIUS client receives a packet with an unrecognized Code
      field, the client SHOULD post a RADIUS Accounting-Request message
      with the Acct-Status-Type Attribute set to Acct-Error-Notification
      containing instances of the Error-Code and Unrecognized-Packet-
      Type Attributes [ERRMSG].  The invalid packet MUST be discarded.

      The RADIUS Codes (decimal) defined in this document are as
      follows:

         <MSG1> Key-Request

         <MSG2> Key-Response

   Identifier

      The Identifier field is one octet, and aids in matching requests
      and replies.  The RADIUS server can detect a duplicate request if
      it has the same client source IP address, source UDP port and
      Identifier within a short span of time.







Zorn, et al.             Expires August 24, 2008                [Page 4]


Internet-Draft       Session Key Transport in RADIUS       February 2008


   Length

      The Length field is two octets.  It indicates the length of the
      packet including the Code, Identifier, Length, Authenticator and
      Attribute fields.  Octets outside the range of the Length field
      MUST be treated as padding and ignored on reception.  If the
      packet is shorter than the Length field indicates, it MUST be
      silently discarded.  The minimum length is 20 and maximum length
      is 4096.

   Authenticator

      The Authenticator field is sixteen (16) octets.  The most
      significant octet is transmitted first.  This value is used to
      authenticate the reply from the RADIUS server.

      Since the Message-Authentication-Code Attribute [KEYWRAP] is
      required to be present in both the Key-Request and the Key-
      Response messages, the client and server MAY ignore the contents
      of the Authenticator field.  In any case, the validity of the of
      the Authenticator field MUST NOT affect the evaluation of the
      integrity of the message.

      Request Authenticator

         In Key-Request packets, the Authenticator value is a 16 octet
         random number, called the Request Authenticator.  The value
         SHOULD be unpredictable and unique over the lifetime of a
         secret (the password shared between the client and the RADIUS
         server), since repetition of an authenticator value in
         conjunction with the same secret would permit an attacker to
         reply with a previously intercepted response.  Since it is
         expected that the same secret MAY be used to authenticate with
         servers in disparate geographic regions, the Request
         Authenticator field SHOULD exhibit global and temporal
         uniqueness.

         The Authenticator value in a Key-Request packet SHOULD also be
         unpredictable, lest an attacker trick a server into responding
         to a predicted future request, and then use the response to
         masquerade as that server to a future notification packet.

         Although protocols such as RADIUS are incapable of protecting
         against theft of an authenticated session via real-time active
         wiretapping attacks, generation of unique unpredictable
         requests can protect against a wide range of active attacks
         against authentication.




Zorn, et al.             Expires August 24, 2008                [Page 5]


Internet-Draft       Session Key Transport in RADIUS       February 2008


      Response Authenticator

         The value of the Authenticator field in the Key-Response packet
         is called the Response Authenticator, and contains a one-way
         MD5 hash calculated over a stream of octets consisting of: the
         RADIUS packet, beginning with the Code field, including the
         Identifier, the Length, the Request Authenticator field from
         the Key-Request packet, and the response Attributes, followed
         by the shared secret.  That is,

         Acknowledgement Auth =
                      MD5(Code+ID+Length+RequestAuth+Attributes+Secret)

         where '+' denotes concatenation.

   Administrative Note

      The secret shared between the client and the RADIUS server SHOULD
      be at least as large and unguessable as a well- chosen password.
      It is preferred that the secret be at least 16 octets.  This is to
      ensure a sufficiently large range for the secret to provide
      protection against exhaustive search attacks.  The secret MUST NOT
      be empty (length 0) since this would allow packets to be trivially
      forged.

      A RADIUS server MUST use the source IP address of the RADIUS UDP
      packet to decide which shared secret to use, so that RADIUS
      requests can be proxied.

      When using a forwarding proxy, the proxy must be able to alter the
      packet as it passes through in each direction - when the proxy
      forwards the request, the proxy MAY add a Proxy-State Attribute,
      and when the proxy forwards a response, it MUST remove its Proxy-
      State Attribute if it added one.  Proxy-State is always added or
      removed after any other Proxy-States, but no other assumptions
      regarding its location within the list of attributes can be made.
      Since Key-Response packets are authenticated on the entire packet
      contents, the stripping of the Proxy-State attribute invalidates
      the signature in the packet - so the proxy has to re-sign it.

      Further details of RADIUS proxy implementation are outside the
      scope of this document.


4.  Packet Types

   The RADIUS Packet type is determined by the Code field in the first
   octet of the Packet.



Zorn, et al.             Expires August 24, 2008                [Page 6]


Internet-Draft       Session Key Transport in RADIUS       February 2008


4.1.  Key-Request

   Description

      Key-Request packets are sent to a RADIUS server to request the
      delivery of a session key.  A RADIUS client wishing to request the
      delivery of a session key MUST transmit a RADIUS packet with the
      Code field set to <MSG1> (Key-Request).

      Upon receipt of an Key-Request packet from a valid client, the
      server MUST reply using either a Key-Response message or a Error-
      Notification message [ERRMSG].

      A Key-Request message MUST contain either a NAS-IP-Address
      Attribute [RFC2865] or a NAS-Identifier Attribute [RFC2865] or
      both.  To help defeat spoofing attacks, a Key-Request message MUST
      contain either a Message-Authenticator Attribute [RFC2869] or a
      Message-Authentication-Code Attribute [KEYWRAP].

      A Key-Request message SHOULD contain a Session-Id Attribute
      [LOGOFF] if one was returned from the server in the Access-Accept
      message for the session; if no Session-Id Attribute is included,
      the packet MUST contain a User-Name Attribute and such additional
      Attributes as are necessary to positively identify a given user
      session (e.g., Service-Type [RFC2865], Calling-Station-Id
      [RFC2865], etc.).

      A Key-Request packet MAY contain one or more Key Attributes
      [KEYWRAP] in order to request a key with a particular identifier
      or encrypted using a particular algorithm.

      A summary of the Key-Request packet 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Code      |  Identifier   |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                      Request Authenticator                    |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Attributes ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-




Zorn, et al.             Expires August 24, 2008                [Page 7]


Internet-Draft       Session Key Transport in RADIUS       February 2008


   Code

      <MSG1> for Key-Request

   Identifier

      The Identifier field MUST be changed whenever the content of the
      Attributes field changes, and whenever a valid reply has been
      received for a previous request.  For retransmissions, the
      Identifier MUST remain unchanged.

   Request Authenticator

      The Request Authenticator value MUST be changed each time a new
      Identifier is used.

      Implementation Note

         Since the Message-Authentication-Code Attribute [KEYWRAP] is
         required to be present in the Key-Request message, the server
         MAY ignore the contents of the Request Authenticator.  In any
         case, the validity of the of the Request Authenticator field
         MUST NOT affect the evaluation of the integrity of the request.

   Attributes

      The Attribute field is variable in length, and contains the list
      of required Attributes, as well as any desired optional
      Attributes.

4.2.  Key-Response

   Description

      A Key-Response packet is sent by a RADIUS server in response to a
      Key-Request packet.  A RADIUS server wishing to transfer keying
      material to a client in response to a Key-Request packet MUST
      transmit a RADIUS packet with the Code field set to <MSG2> (Key-
      Response).

      At least one Key Attribute [KEYWRAP] MUST be included in a Key-
      Response packet.

      A summary of the Key-Response packet format is shown below.  The
      fields are transmitted from left to right.






Zorn, et al.             Expires August 24, 2008                [Page 8]


Internet-Draft       Session Key Transport in RADIUS       February 2008


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Code      |  Identifier   |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                        Response Authenticator                 |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Attributes ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-

   Code

      <MSG2> for Key-Response

   Identifier

      The Identifier field is a copy of the Identifier field of the Key-
      Request packet which caused this Key-Response packet to be
      created.

   Response Authenticator

      The Response Authenticator value is calculated from the Key-
      Request packet, as described above.

      Implementation Note

         Since the Message-Authentication-Code Attribute [KEYWRAP] is
         required to be present in the Key-Response message, the client
         MAY ignore the contents of the Response Authenticator.  In any
         case, the validity of the of the Response Authenticator field
         MUST NOT affect the evaluation of the integrity of the message.

   Attributes

      The Attribute field is variable in length, and MAY contain any
      desired optional Attributes in addition to the required
      Attributes.


5.  IANA Considerations

   The criteria to be used by the Internet Assigned Numbers Authority
   (IANA) for assignment of numbers within namespaces defined within
   this document are identical to those given in [RFC3575].



Zorn, et al.             Expires August 24, 2008                [Page 9]


Internet-Draft       Session Key Transport in RADIUS       February 2008


6.  Security Considerations

   If the key used in the generation of the Message-Authentication-Code
   Attribute is compromised, an attacker might be able to modify or
   replace the keying material.


7.  Normative References

   [ERRMSG]   Zorn, G., "RADIUS Error Messages",
              draft-zorn-radius-err-msg-09.txt (work in progress),
              February 2008.

   [KEYWRAP]  Zorn, G., Zhang, T., Walker, J., and J. Salowey, "RADIUS
              Attributes for the Delivery of Keying Material",
              draft-zorn-radius-keywrap-13.txt (work in progress),
              February 2008.

   [LOGOFF]   Zorn, G. and A. Lior, "User Session Tracking in RADIUS",
              draft-zorn-radius-logoff-11.txt (work in progress),
              February 2008.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

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

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

   [RFC2869]  Rigney, C., Willats, W., and P. Calhoun, "RADIUS
              Extensions", RFC 2869, June 2000.

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













Zorn, et al.             Expires August 24, 2008               [Page 10]


Internet-Draft       Session Key Transport in RADIUS       February 2008


Authors' Addresses

   Glen Zorn (editor)
   Aruba Networks
   1322 Crossman Avenue
   Sunnyvale, CA  94089-1113
   USA

   Email: gwz@arubanetworks.com


   Hao Zhou
   Cisco Systems
   4125 Highlander Parkway
   REQ01/3/
   Richfield, OH  44286
   US

   Phone: +1 (330) 523-2132
   Email: hzhou@cisco.com


   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 August 24, 2008               [Page 11]


Internet-Draft       Session Key Transport in RADIUS       February 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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 August 24, 2008               [Page 12]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/