Mercurial > hg > ietf
changeset 1:7a9e3b46c8c8
Source XML file for draft-ietf-dime-erp-00
| author | Sebastien Decugis <sdecugis@nict.go.jp> |
|---|---|
| date | Tue, 17 Mar 2009 14:19:17 +0900 |
| parents | e94ae8c3cd3b |
| children | 8c7a9fc32b39 |
| files | draft-ietf-dime-erp-00.xml |
| diffstat | 1 files changed, 560 insertions(+), 0 deletions(-) [+] |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/draft-ietf-dime-erp-00.xml Tue Mar 17 14:19:17 2009 +0900 @@ -0,0 +1,560 @@ +<?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>