[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 RFC 6942

Diameter Maintenance and                                      L. Dondeti
Extensions (DIME)                                         QUALCOMM, Inc.
Internet-Draft                                     J. Bournelle (Editor)
Intended status: Standards Track                               L. Morand
Expires: July 18, 2009                                       Orange Labs
                                                              S. Decugis
                                                                    NICT
                                                        January 14, 2009


          Diameter Support for EAP Re-authentication Protocol
                       draft-ietf-dime-erp-00.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 July 18, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.




Dondeti, et al.           Expires July 18, 2009                 [Page 1]


Internet-Draft          Diameter Support for ERP            January 2009


Abstract

   EAP Re-authentication Protocol (ERP) defines extensions to the
   Extensible Authentication Protocol (EAP) to support efficient re-
   authentication between the EAP peer and an EAP re-authentication
   server through any EAP/ERP authenticator.  This document specifies
   Diameter support for ERP.  The Diameter EAP application is re-used
   for encapsulating the newly defined EAP codes specified in the ERP
   specification.  Additionally, this document also defines specific
   Diameter processing rules relevant to ERP.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Diameter Support for ERP  . . . . . . . . . . . . . . . . . . . 3
     3.1.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . 3
     3.2.  DSRK Request and Delivery . . . . . . . . . . . . . . . . . 4
   4.  Command Codes . . . . . . . . . . . . . . . . . . . . . . . . . 4
   5.  Attribute Value Pair Definitions  . . . . . . . . . . . . . . . 5
     5.1.  EAP-DSRK-Request AVP  . . . . . . . . . . . . . . . . . . . 5
     5.2.  EAP-DSRK AVP  . . . . . . . . . . . . . . . . . . . . . . . 5
     5.3.  EAP-DSRK-Name AVP . . . . . . . . . . . . . . . . . . . . . 5
     5.4.  EAP-DSRK-Lifetime AVP . . . . . . . . . . . . . . . . . . . 5
   6.  AVP Occurrence Table  . . . . . . . . . . . . . . . . . . . . . 5
   7.  AVP Flag Rules  . . . . . . . . . . . . . . . . . . . . . . . . 6
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     11.1. Normative References  . . . . . . . . . . . . . . . . . . . 7
     11.2. Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8

















Dondeti, et al.           Expires July 18, 2009                 [Page 2]


Internet-Draft          Diameter Support for ERP            January 2009


1.  Introduction

   RFC 4072 [1] specifies a Diameter application that carries EAP
   packets between a Diameter client and the Diameter Server/EAP server.
   RFC 5296 [2] defines the EAP Re-authentication Protocol to allow
   faster re-authentication of a previously authenticated peer.

   In ERP, a peer is authenticated by the network thanks to keying
   material obtained during a previous EAP exchange.  This keying
   material is derived from the Extended Master Session Key (EMSK) as
   defined in the RFC 5295 [5].  To accomplish the EAP reauthentication
   functionality, ERP defines two new EAP codes - EAP-Initiate and EAP
   Finish.  This document specifies the reuse of Diameter EAP
   Application to carry these new EAP messages.

   ERP is executed between the peer and a server located either in the
   peer's home domain or in the local domain visited by the peer.  In
   the latter case, a Domain Specific Root Key (DSRK) is derived from
   the EMSK, as defined in the RFC 5295 [5], and is provided by the Home
   EAP server to the local domain server.  For that purpose, this
   document specifies the transport of the DSRK using the Diameter EAP
   Application.


2.  Assumptions

   This document defines only additional optional AVPs for usage with
   the Diameter EAP application.  This document does not define a new
   Diameter application and therefore a new Application ID is not
   required, as described in the Diameter Base protocol [3].

   In this document, when EAP re-authentication is performed in the
   domain visited by the peer, it is assumed that the local ER server is
   co-located with a Diameter agent in the visited domain present in the
   path of the full EAP exchange.  (Editor's Note: it is not clear at
   the time of writing wether this document must require this local AAA
   server to be on the path.)


3.  Diameter Support for ERP

3.1.  Protocol Overview

   The Diameter EAP Application is used to transport ERP messages
   between the NAS (authenticator) and an authentication server (ER
   server).

   In ERP, the peer sends an EAP-Initiate/Re-auth message to the ER



Dondeti, et al.           Expires July 18, 2009                 [Page 3]


Internet-Draft          Diameter Support for ERP            January 2009


   server via the authenticator.  Alternatively, the NAS may send an
   EAP-Initiate/Re-auth-Start message to the peer to trigger the start
   of ERP.  In this case, the peer responds with an EAP-Initiate/Re-auth
   message to the NAS.

   The general guidelines for encapsulating EAP messages in Diameter
   from RFC 4072 [1] apply to the new EAP codes defined for ERP as well.
   The EAP-Initiate/Re-auth message is encapsulated in an EAP-Payload
   AVP of a Diameter EAP Request (DER) message by the NAS and sent to
   the Diameter server.  The NAS MUST copy the contents of the value
   field of the 'KeyName-NAI' TLV or the 'peer-id' TLV (when the former
   is not present) of the EAP Initiate/Re-auth message into a User-Name
   AVP of the Diameter EAP-Request.

   The ER server processes the EAP-Initiate/Re-auth message in
   accordance with [2] and responds with an EAP-Finish/Re-auth message.
   The Diameter server MUST encapsulate the EAP-Finish/Re-auth message
   within an EAP-Payload AVP of a Diameter EAP Answer message.  In an
   EAP re-authentication successful case, an EAP-Master-Session-Key AVP
   is included in the Diameter EAP Answer (DEA) message that contains
   the Re-authentication Master Session Key (rMSK).  The Diameter
   Result-Code SHOULD be a success Result-Code.  In an EAP re-
   authentication failure case, the Diameter Result-Code AVP of the a
   Diameter EAP Answer (DEA) message SHOULD be a failure Result-Code and
   no EAP-Master-Session-Key AVP is present.  (Editor's Note: it is FFS
   if a SHOULD is sufficient) (2nd Editor's Note: add a figure ?)

3.2.  DSRK Request and Delivery

   A local ER server, collocated with a Diameter proxy in the domain
   visited by the peer, may request a DSRK from the home EAP/ERP server,
   either in the initial EAP exchange (implicit bootstrapping) or in an
   ERP bootstrapping exchange (explicit bootstrapping).  This is done by
   including the EAP-DSRK-Request AVP in the Diameter EAP Request (DER)
   message.  The EAP-DSRK-Request AVP contains the domain or server
   identity required to derive the DSRK.

   In successful case, the DSRK is carried by the EAP-DSRK AVP in the
   Diameter EAP Answer (DEA) message.  Along with the EAP-DSRK AVP, an
   EAP-DSRK-Name AVP MUST be used to send the DSRK's keyname and an EAP-
   DSRK-Lifetime AVP MUST be used to send the DSRK's lifetime.
   (Editor's Note: add a figure ?).


4.  Command Codes

   This document re-uses the EAP application commands [1] and does not
   define new command codes.



Dondeti, et al.           Expires July 18, 2009                 [Page 4]


Internet-Draft          Diameter Support for ERP            January 2009


5.  Attribute Value Pair Definitions

   This section defines new AVPs for the ERP support within Diameter EAP
   Application.

5.1.  EAP-DSRK-Request AVP

   The EAP-DSRK Request AVP (AVP Code TBD) is of type DiameterIdentity.
   This AVP fulfills two purposes: first, it indicates that a ERP server
   is located in the local domain that is willing to play the role of an
   ERP server for a particular session.  Second, it conveys information
   about the domain name to the Diameter/EAP/ERP server.  (Editor's
   Note: it is FFS if DiameterIdentity is the correct type).

5.2.  EAP-DSRK AVP

   The EAP-DSRK AVP (AVP Code TBD) is of type OctetString.  This AVP
   contains keying material to be used by the visited domain (i.e. the
   DSRK).  Exactly how this keying material is derived is beyond the
   scope of this document.

5.3.  EAP-DSRK-Name AVP

   The EAP-DSRK-Name AVP (AVP Code TBD) is of type OctetString.  This
   AVP contains the EMSKname which identifies the keying material.  How
   this name is derived is beyond the scope of this document and defined
   in [5].

5.4.  EAP-DSRK-Lifetime AVP

   The EAP-DSRK-Lifetime AVP (AVP Code TBD) is of type Unsigned64 and
   contains the DSRK lifetime in seconds.  (Editor's Note: it is FFS if
   Unsigned32 is not sufficient).  (Editor's Note: it is FFS default
   value)


6.  AVP Occurrence Table

   The following table lists the AVPs that may optionally be present in
   the DER and DEA commands [1].











Dondeti, et al.           Expires July 18, 2009                 [Page 5]


Internet-Draft          Diameter Support for ERP            January 2009


                                   +---------------+
                                   |  Command-Code |
                                   +-+-----+-----+-+
      Attribute Name                 | DER | DEA |
      -------------------------------|-----+-----+
      EAP-DSRK-Request               | 0-1 |  0  |
      EAP-DSRK                       |  0  | 0-1 |
      EAP-DSRK-Name                  |  0  | 0-1 |
      EAP-DSRK-Lifetime              |  0  | 0-1 |
                                     +-----+-----+

                 Figure 1: DER and DEA Commands AVP Table

   When the EAP-DSRK AVP is present in the DEA then the EAP-DSRK-Name
   and the EAP-DSRK-Lifetime MUST also be present.


7.  AVP Flag Rules

   The following table describes the Diameter AVPs, their AVP Code
   values, types, possible flag values, and whether the AVP MAY be
   encrypted.  The Diameter base [3] specifies the AVP Flag rules for
   AVPs in Section 4.5.


                                            +---------------------+
                                            |    AVP Flag Rules   |
                                            +----+-----+----+-----+----+
                     AVP  Section           |    |     |SHLD|MUST |    |
  Attribute Name     Code Defined Data Type |MUST| MAY |NOT |NOT  |Encr|
  ------------------------------------------+----+-----+----+-----+----+
  EAP-DSRK-Request   TBD  4.7.1  DiamIdent  |    |  P  |    | V,M | Y  |
  EAP-DSRK           TBD  4.7.2  OctetString|    |  P  |    | V,M | Y  |
  EAP-DSRK-Name      TBD  4.7.3  OctetString|    |  P  |    | V,M | Y  |
  EAP-DSRK-Lifetime  TBD  4.7.4  Unsigned64 |    |  P  |    | V,M | Y  |
  ------------------------------------------+----+-----+----+-----+----+

  Due to space constraints, the short form DiamIdent is used to
  represent DiameterIdentity.

                      Figure 2: AVP Flag Rules Table


8.  Security Considerations

   The security considerations specified in RFC 4072 [1], and RFC 3588
   [3] are applicable to this document.




Dondeti, et al.           Expires July 18, 2009                 [Page 6]


Internet-Draft          Diameter Support for ERP            January 2009


   EAP channel bindings may be necessary to ensure that the Diameter
   client and the server are in sync regarding the key Requesting
   Entity's Identity.  Specifically, the Requesting Entity advertises
   its identity through the EAP lower layer, and the user or the EAP
   peer communicates that identity to the EAP server (and the EAP server
   communicates that identity to the Diameter server) via the EAP method
   for user/peer to server verification of the Requesting Entity's
   Identity.


9.  IANA Considerations

   This document requires IANA registration of the following new AVPs to
   the AVP registry established by RFC 3588 [3]:

   o  EAP-DSRK-Request

   o  EAP-DSRK

   o  EAP-DSRK-Name

   o  EAP-DSRK-Lifetime


10.  Acknowledgments

   Vidya Narayanan reviewed a rough draft version and found some errors.
   Many thanks for her input.


11.  References

11.1.  Normative References

   [1]  Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
        Authentication Protocol (EAP) Application", RFC 4072,
        August 2005.

   [2]  Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re-
        authentication Protocol (ERP)", RFC 5296, August 2008.

   [3]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
        "Diameter Base Protocol", RFC 3588, September 2003.

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





Dondeti, et al.           Expires July 18, 2009                 [Page 7]


Internet-Draft          Diameter Support for ERP            January 2009


11.2.  Informative References

   [5]  Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri,
        "Specification for the Derivation of Root Keys from an Extended
        Master Session Key (EMSK)", RFC 5295, August 2008.

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


Authors' Addresses

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

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


   Julien Bournelle
   Orange Labs
   38-40 rue du general Leclerc
   Issy-Les-Moulineaux  92794
   France

   Email: julien.bournelle@orange-ftgroup.com


   Lionel Morand
   Orange Labs
   38-40 rue du general Leclerc
   Issy-Les-Moulineaux  92794
   France

   Email: lionel.morand@orange-ftgroup.com












Dondeti, et al.           Expires July 18, 2009                 [Page 8]


Internet-Draft          Diameter Support for ERP            January 2009


   Sebastien Decugis
   NICT
   4-2-1 Nukui-Kitamachi
   Tokyo  184-8795
   Koganei, Japan

   Email: sdecugis@nict.go.jp












































Dondeti, et al.           Expires July 18, 2009                 [Page 9]


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