Mercurial > hg > ietf
changeset 24:e17057ceb2db
Completed initial version, before review
| author | Sebastien Decugis <sdecugis@nict.go.jp> |
|---|---|
| date | Fri, 05 Jun 2009 14:38:08 +0900 |
| parents | 2654f7c6c834 |
| children | 1c96f5301544 |
| files | draft-sdecugis-dime-diameter-erp.xml |
| diffstat | 1 files changed, 541 insertions(+), 155 deletions(-) [+] |
line wrap: on
line diff
--- a/draft-sdecugis-dime-diameter-erp.xml Wed Jun 03 18:24:36 2009 +0900 +++ b/draft-sdecugis-dime-diameter-erp.xml Fri Jun 05 14:38:08 2009 +0900 @@ -1,10 +1,14 @@ <?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 RFC4005 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4005.xml"> +<!ENTITY RFC4072 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4072.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.draft-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.draft-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.draft-gaonkar-radext-erp-attrs SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-gaonkar-radext-erp-attrs-03.xml"> <!ENTITY nbsp " "> ]> <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> @@ -22,7 +26,8 @@ <?rfc rfcedstyle="yes"?> <?rfc rfcprocack="no"?> <?rfc tocindent="yes"?> -<rfc category="std" docName="draft-sdecugis-dime-diameter-erp" ipr="full3978"> +<rfc category="std" docName="draft-sdecugis-dime-diameter-erp" + ipr="trust200902"> <front> <title abbrev="Diameter ERP support">Diameter support for EAP Re-authentication Protocol (ERP)</title> @@ -61,14 +66,14 @@ <keyword>Re-authentication</keyword> <abstract> - <t>The EAP Re-authentication Protocol (a.k.a. ERP, RFC5296) 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> + <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> <note title="Foreword"> @@ -77,10 +82,9 @@ in its design and scope.</t> <t>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> + 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 (<eref target="http://tools.ietf.org/html/draft-ietf-dime-erp-00">draft-ietf-dime-erp-00</eref> @@ -88,11 +92,11 @@ target="http://tools.ietf.org/html/draft-wu-dime-local-keytran-00">draft-wu-dime-local-keytran-00</eref>) was focused on the implicit bootstrapping scenario described in <xref target="RFC5296"></xref>. By re-using the Diameter EAP application, - these documents create constraining requirements on routing of Diameter - messages, that cannot be met by standard Diameter routing algorithm - defined in the <xref target="RFC3588">Diameter Base Protocol</xref>. - They also introduce interoperability problems for the peer and the NAS - that cannot be overcome easily.</t> + these documents create implicit constraints on routing of messages that + cannot be met by standard Diameter routing algorithm defined in the + <xref target="RFC3588">Diameter Base Protocol</xref>. A separate + Diameter Id may also allow the authenticator to dynamically discover if + the local domain supports ERP or not.</t> </note> <note title="Requirements Language"> @@ -107,46 +111,57 @@ <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> - <t>(bootstrapping) Creation of a root key for the session, 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> + 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) A one-round-trip ERP exchange between the - peer and the ER server, functionally equivalent to a full EAP + <t>Re-authentication: one-round-trip exchange between the peer and + the ER server, functionally equivalent to a full EAP authentication.</t> - </list>The bootstrapping of the ER server can occur before - (asynchronous) or during (synchronous) the re-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 DER/DEA commands.</t> + new Application Id for ERP, and re-use the Diameter EAP commands + (DER/DEA).</t> - <t>It also discusses the key distribution (bootstrapping) and proposes - some solutions for different architectures. Anyway, a deployment that - conforms to this specification may adopt a different mechanism for key - distribution, such as described in <xref - target="I-D.ietf-hokey-key-mgm"></xref>. Security considerations for key - distribution are explained in <xref target="RFC5295"></xref>.</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> <section title="Terminology"> <t>We re-use here the terminology from <xref target="RFC5296"></xref>. - In particular, the term "EAP server" refers to a server for EAP with - sufficient extensions for ERP to create ERP keying material.</t> + In particular, the EAP server implicitely supports ERP extensions to + generate the ERP keying material and send it to the ER server. These + terms "authenticator", "ER server", "EAP server" denote logical + functional entities and make no assumption on the real implementation + and deployment.</t> - <t>"root key" or "bootstrapping material" refer to the rRK (for ER - server in home domain) or the rDSRK (ER server in separate domain), - depending on the context.</t> + <t>"root key" or "bootstrapping material" refer to the rRK (home ER + server) or rDSRK (foreign ER server) derived from an EMSK, depending on + the context.</t> + + <t>We re-use also some terminology and abbreviations from <xref + target="RFC4072"></xref>, for example DER/DEA.</t> </section> <section anchor="Overview" title="Overview"> - <t>The following figure shows the components involved in ERP, and their - interactions. During the lifetime of the EMSK derived from a full EAP - authentication, a peer may attach to several authenticators, and - eventually use different ER servers (for example in inter-domain - roaming).</t> + <t>During the lifetime of an EMSK (derived during a full EAP + authentication), 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, as opposed to IEEE + 802.11r-2008 for example, so it can be used in case of multihoming or + horizontal handovers. 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.</t> <figure title="Diameter applications used in the ERP mechanism."> <artwork><![CDATA[ Diameter +--------+ @@ -159,148 +174,519 @@ ]]></artwork> </figure> - <t>The ER server may be located in the home domain (same as the EAP - server) or the visited domain (same as authenticator, in case it differs - from the home domain). <cref>TBD: Can the ER server be located in a - third domain (ex: broker's)?</cref></t> + <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>TBD: Can the ER server be located in a third domain + (ex: broker's)?</cref></t> - <t>The bootstrapping of the ER server occurs sometime between the - initial EAP authentication, and the first ERP re-authentication. See - section <xref target="Bootstrapping">4</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 process, based on <xref target="RFC5296"></xref>, and - shows how Diameter is used in this context. See section <xref - target="Re-authentication">5</xref> for a detailed description.</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="Diameter ERP exchange. "> - <artwork><![CDATA[ ER server - (bootstrapped) - Peer Authenticator (local or home domain) - ==== ============= ====================== + <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 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 + <================================== + Diameter ERP, cmd code DEA + EAP-Payload: EAP-Finish/Re-auth + EAP-Master-Session-Key: rMSK <---------------------- EAP-Finish/Re-auth ]]></artwork> </figure> + </section> - <t></t> + <section anchor="ApplicationId" title="Application Id"> + <t>We define a Diameter ERP Application in this document, with an + Application Id value of <cref>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>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="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>TBD</cref>) is of type + <cref>{DiameterIdentity? OctetString?}</cref>. It contains the name of + the realm in which the ER server is located.</t> + + <t><cref>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>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="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>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>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>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>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>TBD</cref>) is of type + <cref>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>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>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>Therefore, + in DER/DEA with Diameter ERP application ID, do we set the 'M' flag to + these AVPs?</cref>.</t> + + <figure title="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></t> + <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="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>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>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>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>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>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>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>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="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></t> + <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. + Explication follow.</t> + + <figure title="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>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>See guidelines in I-D.ietf-dime-app-design-guide</cref></t> + + <t><cref>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. </cref></t> + + <t><cref>The new authenticator will therefore derive the new Session-Id + from this EMSKName and use this for accounting purpose. </cref></t> + + <t><cref>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? </cref></t> + + <t><cref>It is possible to cache the necessary information at the ER + server level. Is it useful to specify this mechanism in this + document?</cref> </t> </section> <section anchor="Acknowledgements" title="Acknowledgements"> - <t>Remember, it's important to acknowledge people who have contributed - to the work.</t> + <t><cref>Remember, it's important to acknowledge people who have + contributed to the work</cref></t> </section> <section anchor="IANA" title="IANA Considerations"> - <t>This memo includes no request to IANA.</t> + <t><cref>Request a new Application Id for Diameter ERP.</cref></t> - <t>(It's good - indeed pretty much mandatory now - to have an explicit - note because otherwise IANA wastes cycles trying to figure out if - something is needed..)</t> + <t><cref>Request new AVP Codes for ERP-* AVPs</cref></t> </section> <section anchor="Security" title="Security Considerations"> - <t>Remember to consider security from the start.. and all drafts are - required to have a security considerations section before they will pass - the IESG.</t> + <t><cref>Security considerations from RFC3588 (+bis), RFC4072, RFC5247, + RFC5295, and RFC5296 apply</cref></t> + + <t><cref>Is it safe to use ERP-RK-Request / Answer AVPs? What is the + worst case?</cref></t> </section> </middle> - <!-- *****BACK MATTER ***** --> - <back> - <!-- References split to informative and normative --> - <references title="Normative References"> - <reference anchor="RFC2119" - target="http://xml.resource.org/public/rfc/html/rfc2119.html"> - <front> - <title abbrev="RFC Key Words">Key words for use in RFCs to Indicate - Requirement Levels</title> - - <author fullname="Scott Bradner" initials="S." surname="Bradner"> - <organization>Harvard University</organization> - - <address> - <postal> - <street>1350 Mass. Ave.</street> - - <street>Cambridge</street> - - <street>MA 02138</street> - </postal> - - <phone>- +1 617 495 3864</phone> - - <email>sob@harvard.edu</email> - </address> - </author> - - <date month="March" year="1997" /> - - <area>General</area> - - <keyword>keyword</keyword> - - <abstract> - <t>In many standards track documents several words are used to - signify the requirements in the specification. These words are - often capitalized. This document defines these words as they - should be interpreted in IETF documents. Authors who follow these - guidelines should incorporate this phrase near the beginning of - their document: <list> - <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.</t> - </list></t> - - <t>Note that the force of these words is modified by the - requirement level of the document in which they are used.</t> - </abstract> - </front> - - <seriesInfo name="BCP" value="14" /> - - <seriesInfo name="RFC" value="2119" /> - - <format octets="4723" target="ftp://ftp.isi.edu/in-notes/rfc2119.txt" - type="TXT" /> - - <format octets="14486" - target="http://xml.resource.org/public/rfc/html/rfc2119.html" - type="HTML" /> - - <format octets="5661" - target="http://xml.resource.org/public/rfc/xml/rfc2119.xml" - type="XML" /> - </reference> + &RFC2119; &RFC3588; - &RFC4005; + &RFC4072; &RFC5295; @@ -308,13 +694,13 @@ </references> <references title="Informative References"> + &RFC3748; + &I-D.draft-ietf-hokey-key-mgm; - </references> - <section anchor="app-additional" title="Additional stuff"> - <t>You can add appendices just as regular sections, the only difference - is that they go within the "back" element, and not within the "middle" - element. And they follow the "reference" elements.</t> - </section> + &I-D.draft-gaonkar-radext-erp-attrs; + + &I-D.draft-ietf-dime-app-design-guide; + </references> </back> </rfc>