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

Versions: 00 01 02 03

Network Working Group                                         K. Gaonkar
Internet-Draft                                   Georgia Tech University
Intended status: Standards Track                              L. Dondeti
Expires: August 28, 2008                                    V. Narayanan
                                                          QUALCOMM, Inc.
                                                                 G. Zorn
                                                       February 25, 2008


           RADIUS Support for EAP Re-authentication Protocol
                   draft-gaonkar-radext-erp-attrs-03

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 28, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   RFCxxxx (draft-ietf-hokey-erx after publication) [6] specifies the
   EAP Re-authentication Protocol (ERP).  This document specifies RADIUS
   support for ERP.  The procedures in RFC3579 [1] are used for
   encapsulating the EAP Initiate and Finish messages specified in
   RFCxxxx (draft-ietf-hokey-erx after publication) [6].  This document



Gaonkar, et al.          Expires August 28, 2008                [Page 1]

Internet-Draft               RADIUS for ERP                February 2008


   specifies attributes for the request and delivery of Domain Specific
   Root Keys from the AAA/EAP server to the ER Server.  Additionally,
   this document also specifies RADIUS message processing rules relevant
   to ERP.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  RADIUS Support for ERP  . . . . . . . . . . . . . . . . . . . . 3
     3.1.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . 4
     3.2.  DSRK Request and Delivery . . . . . . . . . . . . . . . . . 5
     3.3.  Conflicting Messages  . . . . . . . . . . . . . . . . . . . 5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7
   Intellectual Property and Copyright Statements  . . . . . . . . . . 8





























Gaonkar, et al.          Expires August 28, 2008                [Page 2]

Internet-Draft               RADIUS for ERP                February 2008


1.  Introduction

   RFC3579 [1] specifies EAP message encapsulation in RADIUS messages.
   [6] defines the EAP Re-authentication Protocol to allow faster re-
   authentication of a previously authenticated peer.  In ERP, a peer
   authenticates to the network by proving possession of key material
   derived during a previous EAP exchange.  For this purpose, ERP
   defines two new EAP codes - EAP Initiate and EAP Finish.  This
   document specifies the encapsulation of these messages in RADIUS.  In
   addition, a Domain Specific Root Key (DSRK) may be transported from
   the RADIUS or EAP Server to an EAP Re-authentication (ER) server in
   the local domain for the purpose of re-authenticating the peer within
   that domain (see Figure 2 of [6].  This document defines how the DSRK
   is transported to the ER server using RADIUS.


2.  Terminology

   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 RFC 2119 [2].

   This document uses terminology defined in [7], [8], [6], and [1].


3.  RADIUS Support for ERP

   The EAP Re-authentication Protocol, defined in [6], provides a
   mechanism for efficient re-authentication of EAP peers that have
   unexpired keying material from a previous EAP exchange.  For this
   purpose, an Extended Master Session Key (EMSK) based re-
   authentication key hierarchy has been defined [8].  ERP may be
   executed between the ER peer and an ER server in the peer's home
   domain or the local domain visited by the peer.  In the latter case,
   a Domain Specific Root Key (DSRK), derived from the EMSK, is provided
   to the local domain ER server.  The peer and the local server
   subsequently use the re-authentication key hierarchy from the DSRK to
   authenticate and derive authenticator specific keys within that
   domain.

   The DSRK can be obtained as part of the regular EAP exchange or as
   part of an ERP bootstrapping exchange.  The local ER server
   requesting the DSRK needs to be in the path of the EAP or ERP
   bootstrapping exchange in order to request and obtain the DSRK.







Gaonkar, et al.          Expires August 28, 2008                [Page 3]

Internet-Draft               RADIUS for ERP                February 2008


3.1.  Protocol Overview

   RADIUS may be used to transport ERP messages between the NAS
   (authenticator) and an authentication server (ER server).

   In ERP, the peer sends an EAP Initiate Reauth message to the ER
   server via the authenticator.  Alternatively, the NAS may send an EAP
   Initiate Reauth-Start message to the peer to trigger the start of
   ERP; the peer then responds with an EAP Initiate Reauth message to
   the NAS.

   The general guidelines for encapsulating EAP messages in RADIUS from
   RFC3579 [1] apply to the new EAP messages defined for ERP as well.
   The EAP Initiate Reauth message is encapsulated in an EAP-Message
   attribute of a RADIUS Access-Request message by the NAS and sent to
   the RADIUS server.  In order to permit non-EAP aware RADIUS proxies
   to forward the Access-Request packet, the NAS MUST copy the contents
   of the value field of the 'rIKName as NAI' TLV or the peer-id TLV
   (when the former is not present) of the EAP Initiate Reauth message
   into the User-Name attribute of the Access-Request.

   The ER server processes the EAP Initiate Reauth message in accordance
   with [6], and if that is successful, it responds with an EAP Finish
   Reauth message indicating a success ('R' flag set to 0).  The RADIUS
   server MUST encapsulate the EAP Finish Reauth message with the R flag
   set to zero in an EAP-Message attribute of a RADIUS Access-Accept
   message.  The Re-authentication Master Session Key (rMSK) is
   transported along with this message to the NAS.  The rMSK transport
   follows the same procedures of MSK transport along with EAP Success
   messages in a regular EAP exchange.  The MS-MPPE-Recv-Key and MS-
   MPPE-Send-Key attributes defined in RFC2548 [3] are used to transport
   the rMSK from the server to the NAS as follows:

   MS-MPPE-Recv-Key = rMSK (0, n/2-1)

   MS-MPPE-Send-Key = rMSK (n/2, n-1)

   where, 'n' is the total length of the rMSK in octets and the (x, y)
   notation indicates the starting and ending octets of the key
   material.

   If the processing of the EAP Initiate Reauth message resulted in a
   failure, the RADIUS server MUST encapsulate an EAP Finish Reauth
   message indicating failure ('R' flag set to 1) in an EAP-Message
   attribute of a RADIUS Access-Reject message.  Whether the RADIUS
   server sends an EAP Finish Reauth message is specified in [6].





Gaonkar, et al.          Expires August 28, 2008                [Page 4]

Internet-Draft               RADIUS for ERP                February 2008


3.2.  DSRK Request and Delivery

   A local ER server, collocated with a RADIUS server in the peer's
   visited domain, may request a DSRK from the EAP server, either in the
   initial EAP exchange or in an ERP bootstrapping exchange.  The key
   request and delivery mechanism specified in [9] is used.  A RADIUS
   server acting as an ER server may include the Keying-Material
   attribute defined in [9] in the RADIUS Access-Request message
   containing an EAP Response packet or an EAP Initiate Reauth packet in
   the EAP-Message attribute.  The App ID field of the Keying-Material
   attribute MUST be set to "EAP DSRK" and the Optional Data field
   SHOULD be set to the domain or server identity required to derive the
   DSRK.  The RADIUS server requesting the DSRK needs to be in the path
   of the corresponding EAP or ERP exchange between the peer and the EAP
   or ER server.

   The RADIUS server, acting as the EAP server, if it wishes to include
   a DSRK in response to a request for it, SHOULD include the Keying-
   Material attribute defined in [9] in the RADIUS Access-Accept message
   (containing either an EAP Success or EAP Finish Reauth with the 'R'
   flag set to 0).  The App ID of the Keying-Material attribute MUST be
   set to "EAP DSRK" and the Optional Data field SHOULD be set to the
   domain or server identity used by the EAP server to derive the DSRK.
   The encrypted DSRK itself must be included in the Data field of the
   Keying-Material attribute in accordance with [9].

3.3.  Conflicting Messages

   In addition to the rules specified in Section 2.6.3. of RFC3579 [1],
   the following combinations SHOULD NOT be sent by a RADIUS Server:

      Access-Accept/EAP-Message/EAP Finish Reauth with 'R' flag set to 1

      Access-Reject/EAP-Message/EAP Finish Reauth with 'R' flag set to 0

      Access-Reject/Keying-Material

      Access-Challenge/EAP-Message/EAP Initiate Reauth

      Access-Challenge/EAP-Message/EAP Finish Reauth


4.  Security Considerations

   The security considerations specified in RFC 3579 [1], RFC 2548 [3],
   and [9] are applicable to this document.





Gaonkar, et al.          Expires August 28, 2008                [Page 5]

Internet-Draft               RADIUS for ERP                February 2008


5.  IANA Considerations

   This document requires IANA registration of the following value of
   the App ID field for the RADIUS Keying-Material attribute:

   2 ...  EAP DSRK


6.  Acknowledgments


7.  References

7.1.  Normative References

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

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

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

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

   [5]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs",
        draft-narten-iana-considerations-rfc2434bis-08 (work in
        progress), October 2007.

7.2.  Informative References

   [6]  Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re-
        authentication Protocol (ERP)", draft-ietf-hokey-erx-12 (work in
        progress), February 2008.

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

   [8]  Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri,
        "Specification for the Derivation of Root Keys from an Extended
        Master  Session Key (EMSK)", draft-ietf-hokey-emsk-hierarchy-04
        (work in progress), February 2008.



Gaonkar, et al.          Expires August 28, 2008                [Page 6]

Internet-Draft               RADIUS for ERP                February 2008


   [9]  Zorn, G., "RADIUS Attributes for the Delivery of Keying
        Material", draft-zorn-radius-keywrap-13 (work in progress),
        April 2007.


Authors' Addresses

   Kedar Gaonkar
   Georgia Tech University

   Email: kgaonkar3@gatech.edu


   Lakshminath Dondeti
   QUALCOMM, Inc.
   5775 Morehouse Dr
   San Diego, CA
   USA

   Phone: +1 858-845-1267
   Email: ldondeti@qualcomm.com


   Vidya Narayanan
   QUALCOMM, Inc.
   5775 Morehouse Dr
   San Diego, CA
   USA

   Phone: +1 858-845-2483
   Email: vidyan@qualcomm.com


   Glen Zorn

   Email: glenzorn@comcast.net















Gaonkar, et al.          Expires August 28, 2008                [Page 7]

Internet-Draft               RADIUS for ERP                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).





Gaonkar, et al.          Expires August 28, 2008                [Page 8]


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