Mercurial > hg > ietf
view draft-sdecugis-dime-diameter-erp.xml @ 28:e067e505c18d
Update to version -01
| author | Sebastien Decugis <sdecugis@nict.go.jp> |
|---|---|
| date | Fri, 17 Jul 2009 12:10:12 +0900 |
| parents | 1c96f5301544 |
| children |
line wrap: on
line source
<?xml version="1.0" encoding="US-ASCII"?> <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> <!ENTITY RFC3748 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml"> <!ENTITY RFC3588 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml"> <!ENTITY RFC4072 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4072.xml"> <!ENTITY RFC4187 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4187.xml"> <!ENTITY RFC5247 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5247.xml"> <!ENTITY RFC5295 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5295.xml"> <!ENTITY RFC5296 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5296.xml"> <!ENTITY I-D.ietf-hokey-key-mgm SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-hokey-key-mgm-06.xml"> <!ENTITY I-D.ietf-dime-app-design-guide SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dime-app-design-guide-08.xml"> <!ENTITY I-D.gaonkar-radext-erp-attrs SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-gaonkar-radext-erp-attrs-03.xml"> <!ENTITY I-D.ietf-dime-erp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dime-erp-00.xml"> <!ENTITY I-D.wu-dime-local-keytran SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-wu-dime-local-keytran-00.xml"> <!ENTITY nbsp " "> ]> <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <?rfc strict="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc editing="no"?> <?rfc toc="yes"?> <?rfc tocompact="yes"?> <?rfc tocdepth="3"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?> <?rfc rfcedstyle="yes"?> <?rfc rfcprocack="no"?> <?rfc tocindent="yes"?> <rfc category="std" docName="draft-sdecugis-dime-diameter-erp-01" ipr="trust200902"> <front> <title abbrev="Diameter ERP support">Diameter support for EAP Re-authentication Protocol (ERP)</title> <author fullname="Sebastien Decugis" initials="S." role="editor" surname="Decugis"> <organization abbrev="NICT">NICT</organization> <address> <postal> <street>4-2-1 Nukui-Kitamachi</street> <city>Koganei, Tokyo</city> <code>184-8795</code> <country>JP</country> </postal> <email>sdecugis@nict.go.jp</email> </address> </author> <date year="2009" /> <area>Operations & Management</area> <workgroup>Diameter Maintenance and Extensions (DIME)</workgroup> <keyword>Internet-Draft</keyword> <keyword>ERP</keyword> <keyword>Diameter</keyword> <keyword>Re-authentication</keyword> <abstract> <t>The EAP Re-authentication Protocol (ERP) provides a mechanism to optimize EAP authentication delay in the case of re-authentication, which can be significant in roaming mobile situation. This mechanism assumes that a protocol for Authentication, Authorization and Accounting (AAA) is available to transport ERP between the authenticator(s) and the EAP/ERP server. draft-gaonkar-radext-erp-attrs-03 specifies the transport of ERP using RADIUS. This document specifies the transport of ERP using Diameter.</t> </abstract> </front> <middle> <section anchor="Introduction" title="Introduction"> <t><xref target="RFC5296"></xref> defines the EAP Re-authentication Protocol (ERP) and mechanism that consists in the two following steps:<list style="numbers"> <t>Bootstrapping: creation of a root key for re-authentication, after initial EAP authentication of the peer. This root key is distributed from the EAP server to the ER server. How this key is tranported is not specified in the ERP mechanism.</t> <t>Re-authentication: one-round-trip exchange between the peer and the ER server, functionally equivalent to a full EAP authentication.</t> </list></t> <t>This document specifies how Diameter is used to carry the re-authentication exchange (second step). For this purpose, we define a new Application Id for ERP, and re-use the Diameter EAP commands (DER/DEA).</t> <t>We also discuss the key distribution (first step, bootstrapping) and propose some solutions for different architectures. Anyway, implementors are free to choose a different mechanism for key distribution, as for example using RADIUS <xref target="I-D.ietf-hokey-key-mgm"></xref>. Security considerations for key distribution are explained in <xref target="RFC5295"></xref>.</t> <section title="Differences with other documents"> <t>This document differs from <xref target="I-D.ietf-dime-erp"></xref> in its design and scope. In this new version, we use a new Diameter application id for messages with ERP payload exchanged between authenticator and ER server. This simplifies the routing of Diameter messages to the appropriate server, and allows more flexibility in the deployment of ERP.</t> <t>The scope of previous documents (<xref target="I-D.ietf-dime-erp"></xref> and <xref target="I-D.wu-dime-local-keytran"></xref>) was focused on the bootstrapping of the mechanism. In particular, these documents did not consider the routing of Diameter message for re-authentication exchanges (ERP exchange, and also <xref target="RFC4187"></xref> for the second document). By re-using the Diameter EAP application, they create implicit constraints on routing of messages that cannot be met by standard Diameter routing algorithm, as defined in the <xref target="RFC3588">Diameter Base Protocol</xref>.</t> <t>A separate Diameter application solves this routing issue, and can also allow the authenticator to dynamically discover if the local domain supports re-authentication or not.</t> </section> </section> <section title="Terminology"> <t>We re-use in this document the terminology from <xref target="RFC5296"></xref>. In particular, unless specified otherwise, the EAP server has implicit support for ERP extensions for generation of ERP keying material and its transmission to ER server. These terms "authenticator", "ER server", "EAP server" designate logical functional entities and make no assumption on the real implementation and deployment.</t> <t>"Root key" (RK) or "bootstrapping material" refer to the rRK or rDSRK derived from an EMSK, depending on the location of the ER server in home or foreign domain.</t> <t>We re-use also some terminology and abbreviations from <xref target="RFC4072"></xref>, for example DER/DEA.</t> <section title="Requirements Language"> <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 <xref target="RFC2119"></xref>.</t> </section> </section> <section anchor="Overview" title="Overview"> <t>During the lifetime of an EMSK (derived during a full EAP authentication by compatible EAP methods), a peer may attach to several authenticators. In this case, re-authentication is more efficient than full authentication, especially in the case of roaming. ERP provides a mechanism for re-authentication independent of the link layer, so it can be used in case of multihoming or handovers between different access technologies. The following figure shows the components involved in ERP, and their interactions. When the peer attaches to a new authenticator, the ER server involved in the transaction may change, for example in the case of inter-domain roaming. The home EAP server is assumed to be constant for a given peer.</t> <figure title="Figure 1. Diameter applications used in the ERP mechanism."> <artwork><![CDATA[ Diameter +--------+ +-------------+ ERP +-----------+ (*) | Home | Peer <->|Authenticator|<=======>| ER server | <---> | EAP | +-------------+ +-----------+ | server | +--------+ (*) Several protocols can be used between ER server and home EAP server to transport bootstrapping material. ]]></artwork> </figure> <t>The ER server may be located in the home domain (same as EAP server) or the visited domain (same as authenticator, when it differs from the home domain). <cref anchor="Editor1">Can the ER server be located in a third domain (ex: broker's)?</cref></t> <t>The bootstrapping of the ER server has to occur sometime between the initial EAP authentication and the first ERP re-authentication with this ER server. See section <xref target="Bootstrapping"></xref> for detail on this process. Then, the peer re-authenticates, for example after a movement that makes it attach to a new authenticator. The following figure describes this re-authentication, and shows how Diameter is used in this context. See section <xref target="Re-authentication"></xref> for a detailed description, and following sections for details on the Diameter messages format.</t> <figure title="Figure 2. Diameter ERP exchange. "> <artwork><![CDATA[ ER server (bootstrapped) Peer Authenticator (local or home domain) ==== ============= ====================== [ <------------------------ ] [optional EAP-Initiate/Re-auth-start] -----------------------> EAP-Initiate/Re-auth ==================================> Diameter ERP, cmd code DER User-Name: Keyname-NAI EAP-Payload: EAP-Initiate/Re-auth <================================== Diameter ERP, cmd code DEA EAP-Payload: EAP-Finish/Re-auth EAP-Master-Session-Key: rMSK <---------------------- EAP-Finish/Re-auth ]]></artwork> </figure> </section> <section anchor="ApplicationId" title="Application Id"> <t>We define a Diameter ERP Application in this document, with an Application Id value of <cref anchor="IANA1">TBD</cref>. Diameter nodes conforming to this specification (in the role of ER server or authenticator) MUST advertise support by including the Diameter ERP Application ID value in the Auth-Application-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer command <xref target="RFC3588"></xref>.</t> <t>The primary use of the Diameter ERP Application Id is to ensure proper routing of the messages, and that the nodes that advertise the support for this application do understand the new AVPs defined in the next section (although these AVP have the 'M' flag cleared).</t> </section> <section anchor="AVPs" title="AVPs"> <t>This specification defines the following new AVPs.</t> <section title="ERP-RK-Request AVP"> <t>The ERP-RK-Request AVP (AVP Code <cref anchor="IANA2">TBD</cref>) is of type grouped AVP. It is used by the ER server to request root key material used in ERP.</t> <t>This AVP has the M and V bits cleared.</t> <figure title="Figure 3. ERP-RK-Request ABNF"> <artwork><![CDATA[ ERP-RK-Request ::= < AVP Header: TBD > { ERP-Realm } * [ AVP ] ]]></artwork> </figure> </section> <section title="ERP-Realm AVP"> <t>The ERP-Realm AVP (AVP Code <cref anchor="IANA3">TBD</cref>) is of type <cref anchor="Editor2">DiameterIdentity? OctetString?</cref>. It contains the name of the realm in which the ER server is located.</t> <t><cref anchor="Editor3">FFS: We may re-use Origin-Realm here instead? On the other hand, ERP-Realm may be useful in CER/CEA with a NAS...</cref></t> <t>This AVP has the M and V bits cleared.</t> </section> <section title="ERP-RK-Answer AVP"> <t>The ERP-RK-Answer AVP (AVP Code <cref anchor="IANA4">TBD</cref>) is of type grouped AVP. It is used by the home EAP server to provide ERP root key material to the ER server.</t> <t>This AVP has the M and V bits cleared.</t> <figure title="Figure 4. ERP-RK-Answer ABNF"> <artwork><![CDATA[ ERP-RK-Answer ::= < AVP Header: TBD > { ERP-RK } { ERP-RK-Name } { ERP-RK-Lifetime } * [ AVP ] ]]></artwork> </figure> </section> <section title="ERP-RK AVP"> <t>The ERP-RK AVP (AVP Code <cref anchor="IANA5">TBD</cref>) is of type OctetString. It contains the root key (either rRK or rDSRK) to be used for ERP with the peer to which the current session belongs. How this material is derived and used is specified in <xref target="RFC5296"></xref>.</t> <t><cref anchor="Editor4">Can we re-use EAP-Master-Session-Key here?</cref></t> <t>This AVP has the M and V bits cleared.</t> </section> <section title="ERP-RK-Name AVP"> <t>The ERP-RK AVP (AVP Code <cref anchor="IANA6">TBD</cref>) 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="RFC5296"></xref>.</t> <t><cref anchor="Editor5">Can we re-use EAP-Key-Name here?</cref></t> <t>This AVP has the M and V bits cleared.</t> </section> <section title="ERP-RK-Lifetime AVP"> <t>The ERP-RK-Lifetime AVP (AVP Code <cref anchor="IANA7">TBD</cref>) is of type <cref anchor="Editor6">Unsigned64? 32?</cref> and contains the root key material remaining lifetime in seconds. It MUST not be greater than the remaining lifetime of the EMSK it is derived from. <cref anchor="Editor7">FFS: is it better to pass an absolute value here, for example expiration date? How to express it then (TZ, ...)? Synchronization problems?</cref></t> <t>This AVP has the M and V bits cleared.</t> </section> </section> <section anchor="Commands" title="Commands"> <t>We do not define any new command in this specification. We reuse the Diameter-EAP-Request and Diameter-EAP-Answer commands defined in <xref target="RFC4072"></xref>.</t> <t>The Application Id field in the command header <cref anchor="Editor8">and the value in Auth-Application-Id AVP which is redundant???</cref> can be set to Diameter EAP application or Diameter ERP application, depending on the situation, as explained in the next sections.</t> <t>Since the original ABNF of these commands allow other optional AVPs ("* [ AVP ]"), and the new AVPs defined in this specification do not have the 'M' flag set, the ABNF does not need any change. Anyway, a Diameter node that advertize support for the Diameter ERP application MUST support the ERP-RK-Request and ERP-RK-Answer AVP <cref anchor="Editor9">Therefore, in DER/DEA with Diameter ERP application ID, do we set the 'M' flag to these AVPs?</cref>.</t> <figure title="Figure 5. Command Codes"> <artwork><![CDATA[ Command-Name Abbrev. Code Reference Application --------------------------------------------------------- Diameter-EAP-Request DER 268 RFC 4072 Diameter ERP Diameter-EAP-Answer DEA 268 RFC 4072 Diameter ERP ]]></artwork> </figure> </section> <section anchor="Bootstrapping" title="Bootstrapping options"> <t>Bootstrapping involves the ER server and the EAP server directly, but also indirectly the peer and the authenticator. For ERP to be successful, the peer must derive the same keying material as the ER server. To make this possible, it must learn the domain name of the ER server. How this is achieved is outside the scope of this specification, but it usually involves that the authenticator is configured to advertize this domain name. This could be achieved for example by including the ERP-Realm AVP in a CER/CEA exchange.</t> <t>As stated in the <xref target="Overview"></xref>, the bootstrapping of an ER server has to happen between the initial EAP authentication of the peer, when the EMSK is created, and the moment the peer re-authenticates with this ER server, when the bootstrapping material is needed. While asynchrounous solutions are perfectly possible, it is usually easier to bootstrap the ER server during one of these events.</t> <section title="Bootstrapping during initial EAP authentication"> <t>Bootstrapping an ER server during the initial EAP authentication offers the advantage that the server is immediatly available for re-authentication of the peer, thus minimizing the re-authentication delay.</t> <t>On the other hand, re-authentication may only concern a small number of peers in the visited domain. Deriving and caching key material for all the peers (for example, for the peers that do not support ERP, or that are not mobile) is a waste of resources and SHOULD be avoided. In addition, bootstrapping ERP during full EAP authentication may prevent re-authentication in case of inter-domain roaming. Hence, while this mecanism is useful in some situations, it should be deployed with care.</t> <t>In the case where ER server is collocated with the Home EAP server, ER bootstrapping is transparent with regards to this specification, although some sort of communication might be needed inside the node. In this case, the server MUST advertise support of both the Diameter EAP application and the Diameter ERP application, but the new AVPs defined in this specification are not used.</t> <t>When ER server and EAP server are different entities with regards to Diameter, one or more Diameter EAP proxy(ies) is(are) needed in the same domain as the ER server. While this(these) proxy(ies) might be separate entity(ies) with secure communication channel with the ER server, it is functionally equivalent to consider that the ER server acts as a Diameter EAP proxy. In the rest of this section, we consider that the ER server acts as a Diameter EAP proxy in its domain.</t> <t>In order to bootstrap the ER server during full EAP authentication, this server must be on the route, and act as a proxy, for the first and last round of exchanges of the full EAP authentication, as captured in the figure bellow.</t> <figure title="Figure 6. ERP bootstrapping during full EAP authentication"> <artwork><![CDATA[ ER server & Authenticator EAP Proxy Home EAP server ============= =========== =============== -------------------------> Diameter EAP/DER (EAP-Response) -------------------------> Diameter EAP/DER (EAP-Response) (ERP-RK-Request) <==================================================> Multi-round Diameter EAP exchanges, unmodified <------------------------- Diameter EAP/DEA (EAP-Success) (MSK) (ERP-RK-Answer) <------------------------- Diameter EAP/DEA (EAP-Success) (MSK) [ERP-Realm] ]]></artwork> </figure> <t>The ER server proxies the first DER of the full EAP authentication and adds the ERP-RK-Request AVP inside, if this AVP is not already in the message, then forwards the request.</t> <t>If the EAP server does not support ERP extensions, it will simply ignore this grouped AVP and continue as specified in <xref target="RFC4072"></xref>. If the server supports the ERP extensions, it caches the ERP-Realm value with the session, and continues the EAP authentication. When the authentication is complete, if it is successful and the EAP method generated an EMSK, the server MUST compute the rRK or rDSRK (depending on the value of ERP-Realm) as specified in <xref target="RFC5296"></xref>, and add an ERP-RK-Answer AVP in the Diameter-EAP-Request message, in addition to the MSK and EAP-Success payload. <cref anchor="Editor10">FFS: is it important to check that the server that added the ERP-RK-Request is in the path of the answer? What's the worst that can happen?</cref></t> <t>When the ER server proxies a Diameter-EAP-Answer message with a Session-Id corresponding to a message to which it added an ERP-RK-Answer, and the Result-Code is DIAMETER_SUCCESS, it MUST examine the message and remove any ERP-RK-Answer AVP, and save its content. If the message does not contain an ERP-RK-Answer AVP, the ER server MAY save this information to avoid possible attempts later for this session. In any case, the information stored SHOULD NOT have a lifetime greater than the EMSK lifetime <cref anchor="Editor11">FFS: how does the ER server knows the EMSK lifetime, if there is no ERP-RK-Answer? What is the lifetime of the MSK for example?</cref></t> <t>If the ER server is successfully bootstrapped, it MAY also add the ERP-Realm AVP after removing the ERP-RK-Answer AVP in the Diameter-EAP-Answer message. This could be used by the authenticator to notify the peer that ERP is bootstrapped, with the ER domain information. How this information can be transmitted to the peer is outside the scope of this document. <cref anchor="Editor12">Is it possible? It would be useful...</cref></t> </section> <section title="Bootstrapping during first re-authentication"> <t>Bootstrapping the ER server during the first re-authentication offers several advantages: it saves resources, since we generate and cache only useful keying material, it can also accomodate inter-domain roaming or ER servers that loose their state (for example after reboot).</t> <t>On the other hand, the first re-authentication with the ER server requires a one-round-trip with the home EAP server, which adds some delay to the process (but it is more efficient than a full EAP authentication in any case). Note that following re-authentications for the same session with the same ER server will not have this additional delay.</t> <t><xref target="RFC5296"></xref> describes two types of bootstrapping for ERP: implicit bootstrapping and explicit bootstrapping. In implicit bootstrapping, the peer knows the domain it is located in, and assumes that the ER server already possess the keying material for the session. In this case, the peer uses a Keyname-NAI in the form "EMSKname@localdomain". In explicit bootstrapping, the Keyname-NAI is in the form "EMSKname@homedomain". As we will see in next section <xref target="Re-authentication"></xref>, the domain part of the Keyname-NAI becomes the Destination-Realm of the Diameter message, and the Application Id is set to Diameter ERP application.</t> <t>In the case of implicit bootstrapping (how the peer learns that the ER server is bootstrapped is outside the scope of this specification) or after a first succesful re-authentication in the visited domain, the message is routed to the local ER server following normal Diameter routing. If the ER server does not have key information corresponding to this EMSKname, <cref anchor="Editor13">return an error to the peer? proxy the request and send ERP-RK-Request to the home EAP server? How do we learn which is the home domain?</cref>. See the next section <xref target="Re-authentication"></xref> for detail.</t> <t>In the case of explicit bootstrapping (the ERP message has its 'B' flag set), if an ER server exists in the visited domain, it SHOULD be configured for and act as a Diameter ERP proxy, and process the messages as described below. If not, the ER server in the home domain will be used, which is less efficient. The description that follow for the ER server in the visited domain is also valid for the ER server in the home domain.</t> <t><cref anchor="Editor14">What should we do if the ER server receives an explicit bootstrapping request but already possess the rDSRK?</cref></t> <t>The ER server proxies the request (DER with Diameter ERP application code) as follow, in addition to standard proxy operations:<list> <t>Change the Application Id in the header of the message to Diameter EAP Application (code 5). <cref anchor="Editor15">What about the Application-Auth-Id AVP?</cref></t> <t>Add the ERP-RK-Request AVP, which contains the name of the domain the ER server is located in (with regards to ERP).</t> </list>Then the request is forwarded as usual. With its Diameter EAP application id and Destination-Realm set to the home domain of the peer, the request reaches the home EAP server. If this server does not support ERP extensions, it replies with an error since the encapsulated EAP-Initiate/Re-auth command is not understood. Otherwise, it processes the ERP request as described in <xref target="RFC5296"></xref>. In particular, it includes the Domain-Name TLV attribute with the content from the ERP-Realm AVP. It creates the DEA reply message following standard processing from <xref target="RFC4072"></xref> (in particular EAP-Master-Session-Key AVP is used to transport the rMSK), and includes the ERP-RK-Answer AVP.</t> <t>The ER server receives this DEA and proxies it as follow, in addition to standard proxy operations:<list> <t>Set the Application Id back to Diameter ERP (code <cref anchor="IANA8">TBD</cref>)</t> <t>Extract and cache the content of the ERP-RK-Answer.</t> </list>The DEA is then forwarded to the authenticator, that can use the rMSK as described in <xref target="RFC5296"></xref>.</t> <t>The figure below captures this Diameter ERP Proxy behavior:</t> <figure title="Figure 7. ERP explicit bootstrapping message flow"> <artwork><![CDATA[ Authenticator ER server Home EAP server ============= ========= =============== -----------------------> Diameter ERP/DER (EAP-Initiate) ------------------------> Diameter EAP/DER (EAP-Initiate) (ERP-RK-Request) <------------------------ Diameter EAP/DEA (EAP-Finish) (ERP-RK-Answer) (rMSK) <---------------------- Diameter ERP/DEA (EAP-Finish) (rMSK) ]]></artwork> </figure> </section> </section> <section anchor="Re-authentication" title="Re-Authentication"> <t>This section describes a re-authentication exchange with a bootstrapped ER server. The peer is assumed to know the domain of the bootstrapped ER server in advance. See previous section <xref target="Bootstrapping"></xref> for more information. EAP-Initiate/Re-auth-start with Domain-Name TLV is a possibility for the peer to learn the domain of the ER server attached to the authenticator.</t> <t>The following figure describes the re-authentication exchange.</t> <figure title="Figure 8. Diameter ERP exchange"> <artwork><![CDATA[ Bootstrapped ER server Peer Authenticator (in local or home domain) ==== ============= ========================= [ <------------------------ ] [optional EAP-Initiate/Re-auth-start] -----------------------> EAP-Initiate/Re-auth =================================> Diameter ERP, cmd code DER User-Name: Keyname-NAI EAP-Payload: EAP-Initiate/Re-auth <================================= Diameter ERP, cmd code DEA EAP-Payload: EAP-Finish/Re-auth EAP-Master-Session-Key: rMSK <---------------------- EAP-Finish/Re-auth ]]></artwork> </figure> <t>The authenticator that does not support ERP <xref target="RFC4072"></xref> discards EAP packets with unknown ERP-specific code (EAP-Initiate). The peer falls back to full EAP authentication in that case.</t> <t>When the ERP-compatible authenticator receives an EAP-Initiate/Re-auth message from the peer (or after having sent a EAP-Initiate/Re-auth-start packet), it process as described in <xref target="RFC5296"></xref> with regards to the EAP state machine, and similarly to <xref target="RFC4072">Diameter EAP</xref>, with regards to Diameter, with the following differences:<list> <t>The application id is set to Diameter ERP instead of Diameter EAP.</t> <t>The User-Name and Destination-Realm are derived from the Keyname-NAI.</t> <t><cref anchor="Editor16">How do we create / retrieve the Session-Id?</cref></t> </list></t> <t>The ER server receives this request and process the ERP payload as described in <xref target="RFC5296"></xref>. If re-authentication is successful, it creates a DEA answer as described in Diameter EAP, with the following differences:<list> <t>The application id is set to Diameter ERP.</t> <t>The EAP-Payload AVP contains the ERP message: EAP-Finish/Re-auth</t> <t>The EAP-Master-Session-Key AVP contains the rMSK</t> <t>The Result-Code AVP contains DIAMETER_SUCCESS.</t> </list>In case the re-authentication fails, the Result-Code AVP contains an error code, and no EAP-Master-Session-Key AVP is included.</t> <t>When the authenticator receives this answer, it processes it as described in Diameter EAP: forwards the EAP payload to the peer, and use the rMSK as a shared secret in Secure Association Protocol.</t> </section> <section anchor="Sessions" title="Sessions"> <t>This section describes how sessions are handled in case of re-authentication.</t> <t><cref anchor="Editor17">The content of this section is to be written, I am just listing the ideas here.</cref></t> <t>See guidelines in <xref target="I-D.ietf-dime-app-design-guide"></xref>.</t> <t>During initial full EAP authentication, the identity of the peer is used to create the Session-Id AVP, which is then used during accounting. When the peer attaches to a new authenticator and performs ERP, its identity is not disclosed to the authenticator. Instead, the peer presents the Keyname-NAI. This identifiers contains the EMSKName as user part. The new authenticator will therefore derive the new Session-Id from this EMSKName and use this for accounting purpose.</t> <t>Although the home EAP server is able to link EMSKName with the peer's identity, the other Diameter entities do not have this mapping. In particular, the realm part of Keyname-NAI is the visited network. How does the authenticator figures out that the account records must be sent to the home domain of the peer?</t> <t>It is possible to cache the necessary information at the ER server level. Is it useful to specify this mechanism in this document? It would involve:<list> <t>An additional AVP during bootstrapping of ER server, in the ERP-RK-Answer, to pass the real User-Name and Session-Id (only in case of explicit bootstrapping)</t> <t>An additional AVP in Diameter ERP/DEA (EAP-Finish/Re-Auth) to pass the real Session-Id and User-Name and Destination-Realm of the re-authenticated peer, for accounting messages.</t> </list></t> </section> <section title="Contributors"> <t>Hannes Tschofenig, Lakshminath Dondeti, Julien Bournelle, and Lionel Morand wrote the initial Diameter ERP draft document.</t> </section> <section anchor="Acknowledgements" title="Acknowledgements"> <t>Vidya Narayanan reviewed a rough draft version of the previous document and found some errors.</t> <t>Qin Wu and Glen Zorn actively participated in the discussions on the design for Diameter ERP, providing the point of view and experience from HOKEY workgroup.</t> <t>Hannes Tschofenig provided useful advices for the writing of this document.</t> <t>Many thanks to these people!</t> </section> <section anchor="IANA" title="IANA Considerations"> <t>This document requires IANA registration of the following new elements in the <eref target="http://www.iana.org/assignments/aaa-parameters/">Authentication, Authorization, and Accounting (AAA) Parameters</eref> registries.</t> <section title="Diameter ERP application"> <t>This specification requires IANA to allocate a new value "Diameter ERP" in the "Application IDs" registry created by in <xref target="RFC3588"></xref>.</t> <figure title="IANA consideration for Diameter ERP application"> <artwork><![CDATA[ Application Identifier | Value -----------------------------------+------ Diameter ERP | TBD ]]></artwork> </figure> </section> <section title="New AVPs"> <t>This specification requires IANA to allocate new values from the "AVP Codes" registry defined in <xref target="RFC3588"></xref> for the following AVPs:<list> <t>ERP-RK-Request</t> <t>ERP-Realm</t> <t>ERP-RK-Answer</t> <t>ERP-RK</t> <t>ERP-RK-Name</t> <t>ERP-RK-Lifetime</t> </list>These AVPs are defined in section <xref target="AVPs"></xref>.</t> </section> </section> <section anchor="Security" title="Security Considerations"> <t>The security considerations from the following RFC apply here: <xref target="RFC3588"></xref>, <xref target="RFC4072"></xref>, <xref target="RFC5247"></xref>, <xref target="RFC5295"></xref>, and <xref target="RFC5296"></xref>.</t> <t><cref anchor="Editor18">FFS: Do we really respect these security considerations with the mechanism we describe here? Is it safe to use ERP-RK-Request / Answer AVPs? What is the worst case?</cref></t> </section> </middle> <back> <references title="Normative References"> &RFC2119; &RFC3588; &RFC4072; &RFC5295; &RFC5296; </references> <references title="Informative References"> &RFC3748; &RFC4187; &RFC5247; &I-D.ietf-hokey-key-mgm; &I-D.gaonkar-radext-erp-attrs; &I-D.ietf-dime-erp; &I-D.wu-dime-local-keytran; &I-D.ietf-dime-app-design-guide; </references> </back> </rfc>