Mercurial > hg > ietf
view draft-ietf-dime-erp-00.xml @ 44:dedca4345401 submit-02
Cleaned-up reference to old version, unused.
author | Sebastien Decugis <sdecugis@nict.go.jp> |
---|---|
date | Wed, 07 Oct 2009 16:48:11 +0900 |
parents | 7a9e3b46c8c8 |
children |
line wrap: on
line source
<?xml version="1.0" encoding="UTF-8"?> <?xml-stylesheet type='text/xsl' href='../../../rfc2629.xslt' ?> <!DOCTYPE rfc SYSTEM "rfc2629.dtd"[ <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'> <!ENTITY rfc3748 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml'> <!ENTITY rfc4072 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4072.xml'> <!ENTITY rfc3588 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml'> <!ENTITY rfc5295 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5295.xml'> <!ENTITY rfc5296 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5296.xml'> ]> <?rfc toc="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?> <?rfc sortrefs="yes" ?> <?rfc symrefs="no"?> <?rfc comments="yes"?> <?rfc inline="no"?> <rfc ipr="trust200811" docName="draft-ietf-dime-erp-00.txt" category="std"> <front> <title abbrev="Diameter Support for ERP">Diameter Support for EAP Re-authentication Protocol</title> <author fullname="Lakshminath Dondeti" initials="L" surname="Dondeti"> <organization>QUALCOMM, Inc.</organization> <address> <postal> <street>5775 Morehouse Dr</street> <city>San Diego</city> <region>CA</region> <country>USA</country> </postal> <phone>+1 858-845-1267</phone> <email>ldondeti@qualcomm.com</email> </address> </author> <author initials="J." surname="Bournelle (Editor)" fullname="Julien Bournelle"> <organization abbrev="Orange Labs">Orange Labs</organization> <address> <postal> <street>38-40 rue du general Leclerc</street> <city>Issy-Les-Moulineaux</city> <code>92794</code> <country>France</country> </postal> <email>julien.bournelle@orange-ftgroup.com</email> </address> </author> <author initials="L." surname="Morand" fullname="Lionel Morand"> <organization abbrev="Orange Labs">Orange Labs</organization> <address> <postal> <street>38-40 rue du general Leclerc</street> <city>Issy-Les-Moulineaux</city> <code>92794</code> <country>France</country> </postal> <email>lionel.morand@orange-ftgroup.com</email> </address> </author> <author initials="S." surname="Decugis" fullname="Sebastien Decugis"> <organization abbrev="NICT">NICT</organization> <address> <postal> <street>4-2-1 Nukui-Kitamachi</street> <city>Tokyo</city> <code>184-8795</code> <country>Koganei, Japan</country> </postal> <email>sdecugis@nict.go.jp</email> </address> </author> <date year="2009"/> <area>Operations and Management</area> <workgroup>Diameter Maintenance and Extensions (DIME)</workgroup> <keyword>Internet-Draft</keyword> <keyword>EAP</keyword> <keyword>Diameter</keyword> <keyword>Re-authentication</keyword> <keyword>inter-authenticator roaming</keyword> <abstract> <t> 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.</t> </abstract> </front> <middle> <section title="Introduction" anchor="intro"> <t>RFC 4072 <xref target="RFC4072"/> specifies a Diameter application that carries EAP packets between a Diameter client and the Diameter Server/EAP server. RFC 5296 <xref target="RFC5296"/> defines the EAP Re-authentication Protocol to allow faster re-authentication of a previously authenticated peer.</t> <!-- <t> In ERP, a peer is authenticated by the network by proving possession of key material derived during a previous EAP exchange. For this purpose, an Extended Master Session Key (EMSK) based re-authentication key hierarchy has been defined <xref target="RFC5295"/>. 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 by the home ER server to the local domain ER server. <t/> <t> To accomplish the 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.</t> <t>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. This document also specifies how the DSRK is transported to the local ER server using Diameter. </t> </section> <section title="Terminology"> <t> 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 <xref target="RFC2119"/>. </t> <t> This document uses terminology defined in <xref target="RFC3748"/>, <xref target="RFC5295"/>, <xref target="RFC5296"/>, and <xref target="RFC4072"/>. </t> --> <t> 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 <xref target="RFC5295"/>. 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. </t> <t> 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 <xref target="RFC5295"/>, 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. </t> </section> <section title="Assumptions"> <!-- <t>This document defines additional optional AVPs for usage with the Diameter EAP application. Routing of these messages is therefore provided via the Diameter Application Identifier (among other elements), as specified by the Diameter Base protocol <xref target="RFC3588"/>. Based on the deployment of ERP, a local Diameter server (the same entity serves as a Diameter proxy during the full EAP authentication) may play the role of the ER server for future re-authentication attempts. As such, the local Diameter server requesting the DSRK needs to be in the path of the current EAP exchange between the peer and the EAP server and also along in the future. The Diameter client is furthermore assumed to be able to route the re-authentication messages to the ER server. </t> --> <t> 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 <xref target="RFC3588"/>. </t> <t> 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.) </t> </section> <section title="Diameter Support for ERP" anchor="diameter_support"> <section title="Protocol Overview" anchor="overview"> <t>The Diameter EAP Application is used to transport ERP messages between the NAS (authenticator) and an authentication server (ER server).</t> <t>In ERP, the peer sends an EAP-Initiate/Re-auth message to the ER 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.</t> <t>The general guidelines for encapsulating EAP messages in Diameter from RFC 4072 <xref target="RFC4072"/> 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.</t> <!-- To be checked: peer-id presence ? --> <!-- <t>The ER server processes the EAP-Initiate/Re-auth message in accordance with <xref target="RFC5296"/>, and if that is successful, it responds with an EAP-Finish/Re-auth message indicating a success (R flag set to '0'). The Diameter server MUST encapsulate the EAP-Finish/Re-auth message in an EAP-Payload AVP attribute of a Diameter EAP-Answer message. An EAP-Master-Session-Key AVP included in the Diameter EAP-Answer contains the Re-authentication Master Session Key (rMSK). The Diameter Result Code, if any, SHOULD be a success Result Code. </t> <t>If the processing of the EAP-Initiate/Re-auth message resulted in a failure, the Diameter server MUST encapsulate an EAP-Finish/Re-auth message indicating failure ('R' flag set to 1) in an EAP-Payload AVP of a Diameter EAP-Answer message. The Diameter Result Code, if any, SHOULD be a failure Result Code. Whether an EAP Finish Reauth message is sent at all is specified in <xref target="I-D.ietf-hokey-erx"/>.</t> --> <t> The ER server processes the EAP-Initiate/Re-auth message in accordance with <xref target="RFC5296"/> 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 ?) </t> </section> <section title="DSRK Request and Delivery" anchor="dsrk"> <t>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.</t> <!-- <t>An EAP/ER server MAY send the DSRK when it receives a valid Diameter EAP-Request message containing an EAP-DSRK-Request AVP. An EAP/ER server MUST send the DSRK (or send a failure result) when it receives a valid Diameter EAP-Request message containing an EAP-DSRK-Request AVP along with a valid EAP-Initiate/Re-auth packet with the bootstrapping flag turned on. If an EAP-DSRK-Request AVP is included in any other Diameter EAP Request message, the Diameter server MUST reply with a failure result. An EAP-DSRK AVP MUST be used to send a DSRK; 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.</t> --> <t> 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 ?).</t> </section> </section> <section title="Command Codes"> <t> This document re-uses the EAP application commands <xref target="RFC4072"/> and does not define new command codes.</t> <!-- <t> <figure anchor="cmd" title="ERP Command Codes"> <artwork><![CDATA[ Command-Name Abbrev. Code Reference Application Diameter-EAP-Request DER 268 RFC 4072 EAP Diameter-EAP-Answer DEA 268 RFC 4072 EAP ]]></artwork> </figure> </t> <t>Re-Auth-Request (RAR) may trigger ERP.</t> <t>Session-Termination-Request (STR), Session-Termination-Answer (STA), Abort-Session-Request (ASR), Abort-Session-Answer (ASA), Accounting-Request (ACR), and Accounting-Answer (ACA) commands are used together with Diameter ERP, they follow the rules in the Diameter EAP application <xref target="RFC4072"/> and the Diameter Base specification <xref target="RFC3588"/>. The accounting commands use the Application Identifier value of 3 (Diameter Base Accounting); the others use 0 (Diameter Common Messages). </t> <section title="Diameter-EAP-Request (DER)"> <t>The Diameter-EAP-Request (DER) message <xref target="RFC4072"/>, indicated by the Command- Code field set to 268 and the 'R' bit set in the Command Flags field, is sent by the NAS to the Diameter server to initiate a network access authentication and authorization procedure.</t> <t>The DEA message format is the same as defined in <xref target="RFC4072"/> with an addition of optional EAP Re-authentication Protocol (ERP) AVPs. The addition of the EAP-DSRK-Request AVP to the Diameter-EAP-Request message indicates that an ERP server is present and willing to participate in the ERP protocol for this session. Furthermore, the EAP-DSRK-Request AVP provides identity information about the domain of the ERP server. </t> <t> <figure> <artwork><![CDATA[ <Diameter-EAP-Request> ::= < Diameter Header: 268, REQ, PXY > < Session-Id > { Auth-Application-Id } { Origin-Host } { Origin-Realm } { Destination-Realm } { Auth-Request-Type } [ EAP-DSRK-Request ] [ User-Name ] [ Destination-Host ] ... * [ AVP ] ]]></artwork> </figure> </t> </section> <section title="Diameter-EAP-Answer (DEA)"> <t>The Diameter-EAP-Answer (DEA) message defined in <xref target="RFC4072"/>, indicated by the Command-Code field set to 268 and 'R' bit cleared in the Command Flags field, is sent in response to the Diameter-EAP-Request message (DER). </t> <t>The DEA message format is the same as defined in <xref target="RFC4072"/> with an addition of optional EAP Re-authentication Protocol (ERP) AVPs. The addition of the EAP-DSRK, EAP-DSRK-Name and the EAP-DSRK-Lifetime AVP to the Diameter-EAP-Answer message indicates that an Diameter / ER server is able to provide ERP support for this session and delivers keying material, lifetime and a key name. </t> <t> <figure> <artwork><![CDATA[ <Diameter-EAP-Answer> ::= < Diameter Header: 268, PXY > < Session-Id > { Auth-Application-Id } { Auth-Request-Type } { Result-Code } { Origin-Host } { Origin-Realm } [ EAP-DSRK ] [ EAP-DSRK-Name ] [ EAP-DSRK-Lifetime ] [ User-Name ] ... * [ AVP ] ]]></artwork> </figure> </t> </section> --> </section> <!-- ====================================================================== --> <section title="Attribute Value Pair Definitions"> <t>This section defines new AVPs for the ERP support within Diameter EAP Application. </t> <section title="EAP-DSRK-Request AVP"> <t>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 <!--and ER server identity--> to the Diameter/EAP/ERP server. (Editor's Note: it is FFS if DiameterIdentity is the correct type).</t> </section> <section title="EAP-DSRK AVP"> <t>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.</t> </section> <section title="EAP-DSRK-Name AVP"> <t>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 <xref target="RFC5295"/>.</t> </section> <section title="EAP-DSRK-Lifetime AVP"> <t>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)</t> </section> </section> <!-- ====================================================================== --> <section title="AVP Occurrence Table"> <t>The following table lists the AVPs that may optionally be present in the DER and DEA commands <xref target="RFC4072"/>. </t> <t> <figure anchor="naspavptable" title="DER and DEA Commands AVP Table"> <artwork><![CDATA[ +---------------+ | 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 | +-----+-----+ ]]></artwork> </figure> </t> <t>When the EAP-DSRK AVP is present in the DEA then the EAP-DSRK-Name and the EAP-DSRK-Lifetime MUST also be present.</t> </section> <section title="AVP Flag Rules"> <t>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 <xref target="RFC3588"/> specifies the AVP Flag rules for AVPs in Section 4.5. </t> <t> <figure anchor="flagstable" title="AVP Flag Rules Table"> <artwork><![CDATA[ +---------------------+ | 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. ]]></artwork> </figure> </t> </section> <!-- ====================================================================== --> <section title="Security Considerations" anchor="SecCons"> <t>The security considerations specified in RFC 4072 <xref target="RFC4072"/>, and RFC 3588 <xref target="RFC3588"/> are applicable to this document. </t> <t>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. </t> </section> <!-- ====================================================================== --> <section title="IANA Considerations" anchor="ianaCons"> <t>This document requires IANA registration of the following new AVPs to the AVP registry established by RFC 3588 <xref target="RFC3588"/>: <list style="symbols"> <t>EAP-DSRK-Request</t> <t>EAP-DSRK</t> <t>EAP-DSRK-Name</t> <t>EAP-DSRK-Lifetime</t> </list> </t> </section> <section title="Acknowledgments" anchor="ack"> <t>Vidya Narayanan reviewed a rough draft version and found some errors. Many thanks for her input.</t> </section> </middle> <back> <references title="Normative References"> &rfc2119; &rfc3588; &rfc4072; &rfc5296; </references> <references title="Informative References"> &rfc3748; &rfc5295; </references> </back> </rfc>