Mercurial > hg > ietf
changeset 54:b817687af36c
Initial version: based on -04 as found in tools.ietf.org
| author | Sebastien Decugis <sdecugis@nict.go.jp> |
|---|---|
| date | Thu, 21 Oct 2010 16:22:23 +0900 |
| parents | 6fb888615123 |
| children | 4890fc91096d |
| files | draft-ietf-dime-erp-05.xml |
| diffstat | 1 files changed, 765 insertions(+), 0 deletions(-) [+] |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/draft-ietf-dime-erp-05.xml Thu Oct 21 16:22:23 2010 +0900 @@ -0,0 +1,765 @@ +<?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 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-dime-local-keytran SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dime-local-keytran-07.xml"> +]> +<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> +<?rfc strict="yes"?> +<?rfc comments="no"?> +<?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-ietf-dime-erp-04.txt" ipr="trust200902"> + <front> + <title abbrev="Diameter ERP Application">Diameter Support for the EAP + Re-authentication Protocol (ERP)</title> + + <author fullname="Julien Bournelle" initials="J." surname="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 fullname="Lionel Morand" initials="L." surname="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 fullname="Sebastien Decugis" initials="S." role="editor" + surname="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> + + <author fullname="Qin Wu" initials="Q." surname="Wu"> + <organization abbrev="Huawei">Huawei Technologies Co., + Ltd</organization> + + <address> + <postal> + <street>Site B, Floor 12F, Huihong Mansion, No.91 Baixia + Rd.</street> + + <city>Nanjing</city> + + <code>210001</code> + + <country>China</country> + </postal> + + <email>sunseawq@huawei.com</email> + </address> + </author> + + <author fullname="Glen Zorn" initials="G." role="editor" surname="Zorn"> + <organization>Network Zen</organization> + + <address> + <postal> + <street>1463 East Republican Street</street> + + <city>Seattle</city> + + <region>Washington</region> + + <code>98112</code> + + <country>USA</country> + </postal> + + <phone>+1 206 931 0768</phone> + + <email>gwz@net-zen.net</email> + </address> + </author> + + <date year="2010" /> + + <area>Operations & Management</area> + + <keyword>Internet-Draft</keyword> + + <keyword>EAP</keyword> + + <keyword>Diameter</keyword> + + <keyword>Re-authentication</keyword> + + <keyword>AAA</keyword> + + <keyword>inter-authenticator roaming</keyword> + + <abstract> + <t>The EAP Re-authentication Protocol (ERP) defines extensions to the + Extensible Authentication Protocol (EAP) to support efficient + re-authentication between the peer and an EAP Re-authentication (ER) + server through a compatible authenticator. This document specifies + Diameter support for ERP. It defines a new Diameter ERP application to + transport ERP messages between an ER authenticator and the ER server, + and a set of new AVPs that can be used to transport the cryptographic + material needed by the re-authentication server.</t> + </abstract> + </front> + + <middle> + <section anchor="Introduction" title="Introduction"> + <t><xref target="RFC5296">RFC 5296</xref> defines the EAP + Re-authentication Protocol (ERP). It consists of the following steps: + <list style="hanging"> + <t hangText="Bootstrapping"><vspace blankLines="0" /> A root key for + re-authentication is derived from the Extended Master Session Key + (EMSK) created during EAP authentication <xref + target="RFC5295"></xref>. This root key is transported from the EAP + server to the ER server.</t> + + <t hangText="Re-authentication"><vspace blankLines="0" /> A + one-round-trip exchange between the peer and the ER server, + resulting in mutual authentication. To support the EAP + reauthentication functionality, ERP defines two new EAP codes - + EAP-Initiate and EAP-Finish.</t> + </list> This document defines how Diameter transports the ERP messages + during the re-authentication process. For this purpose, we define a new + Application Identifier for ERP, and re-use the Diameter EAP commands + (DER/DEA). <vspace blankLines="1" /> This document also discusses the + distribution of the root key during bootstrapping, in conjunction with + either the initial EAP authentication (implicit bootstrapping) or the + first ERP exchange (explicit bootstrapping). Security considerations for + this key distribution are detailed in <xref target="RFC5295">RFC + 5295</xref>.</t> + </section> + + <section title="Terminology"> + <t>This document uses terminology defined in <xref target="RFC3748">RFC + 3748</xref>, <xref target="RFC5295">RFC 5295</xref>, <xref + target="RFC5296">RFC 5296</xref>, and <xref target="RFC4072">RFC + 4072</xref>. <vspace blankLines="1" /> "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. <vspace + blankLines="1" /> We use the notation "ERP/DER" and "ERP/DEA" in this + document to refer to Diameter-EAP-Request and Diameter-EAP-Answer + commands with the Application Id set to "Diameter ERP Application" <xref + target="IANA_AppId"></xref>; the same commands are denoted "EAP/DER" and + "EAP/DEA" when the Application Id in the message is set to "Diameter EAP + Application" <xref target="RFC4072"></xref>.</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 title="Assumptions"> + <t>This document assumes the existence of at most one logical ER server + entity in a domain. If several physical servers are deployed for + robustness, a replication mechanism must be deployed to synchronize the + ERP states (root keys<cref>FFS: authorization attributes</cref>) between + these servers. This replication mechanism is out of the scope of this + document. If multiple ER servers are deployed in the domain, we assume + that they can be used interchangeably.</t> + </section> + + <section anchor="Overview" title="Protocol Overview"> + <t>The following figure shows the components involved in ERP, and their + interactions. <figure align="center" anchor="Fig-Overview" + title="Diameter ERP Overview"> + <artwork><![CDATA[ + Diameter +--------+ + +-------------+ ERP +-----------+ (*) | Home | +Peer <->|Authenticator|<=======>| ER server | <---> | EAP | + +-------------+ +-----------+ | server | + +--------+ +(*) Diameter EAP application, explicit bootstrapping scenario only. +]]></artwork> + </figure> The ER server is located either in the home domain (same as + EAP server) or in the visited domain (same as authenticator, when it + differs from the home domain). <list style="hanging"> + <t hangText="QUESTION:"><vspace blankLines="0" /> Can the ER server + be located in a third domain (ex: broker's) according to ERP + mechanism?</t> + </list> <vspace blankLines="1" /> When the peer initiates an ERP + exchange, the authenticator creates a Diameter-EAP-Request message <xref + target="RFC4072"></xref>. The Application Id of the message is set to + that of the Diameter ERP application (code: TBD) in the message. The + generation of the ERP/DER message is detailed in <xref + target="Re-authentication"></xref>. <vspace blankLines="1" /> If there + is an ER server in the same domain as the authenticator (local domain), + Diameter routing MUST <list style="hanging"> + <t hangText="QUESTION:"><vspace blankLines="0" /> Should this say + "SHOULD: instead of "MUST"?</t> + </list> be configured so that this ERP/DER message reachs this server, + even if the Destination-Realm is not the local domain. <vspace + blankLines="1" /> If there is no local ER server, the message is routed + according to its Destination-Realm AVP content, extracted from the realm + component of the keyName-NAI attribute. As specified in <xref + target="RFC5296">RFC 5296</xref>, this realm is the home domain of the + peer in case of a bootstrapping exchange (the 'B' flag is set in the ERP + message) or the domain of the bootstrapped ER server otherwise. <list + style="hanging"> + <t hangText="NOTE:"><vspace blankLines="0" /> This actually might + allow the ER server to be in a third party realm.</t> + </list> <vspace blankLines="1" /> If no ER server is available in the + home domain either, the ERP/DER message cannot be delivered, and an + error DIAMETER_UNABLE_TO_DELIVER is generated <xref + target="RFC3588"></xref> and returned to the authenticator. The + authenticator may cache this information (with limited duration) to + avoid further attempts for ERP with this realm. It may also fallback to + full EAP authentication to authenticate the peer. <vspace + blankLines="1" /> When an ER server receives the ERP/DER message, it + searches its local database for a root key <list style="hanging"> + <t hangText="FFS:"><vspace blankLines="0" /> and authorization + state?</t> + </list> matching the keyName part of the User-Name AVP. If such key is + found, the ER server processes the ERP message as described in <xref + target="RFC5296">RFC 5296</xref> then creates the ERP/DEA answer as + described in <xref target="Re-authentication"></xref>. The rMSK is + included in this answer. <vspace blankLines="1" /> Finally, the + authenticator extracts the rMSK from the ERP/DEA as described in <xref + target="RFC5296">RFC 5296</xref>, and forwards the content of the + EAP-Payload AVP, the EAP-Finish/Re-Auth message, to the peer. <vspace + blankLines="1" /> If the EAP-Initiate/Re-Auth message has its 'B' flag + set (Bootstrapping exchange), the ER server should not possess the root + key in its local database <list style="hanging"> + <t hangText="COMMENT:"><vspace blankLines="0" /> This may not be + true in future RFC5296bis?</t> + </list> In this case, the ER server acts as a proxy, and forwards the + message to the home EAP server after changing its Application Id to + Diameter EAP and adding an AVP to request the root key. See <xref + target="Bootstrapping"></xref> for more detail on this process.</t> + </section> + + <section anchor="Bootstrapping" title="Bootstrapping the ER Server"> + <t>The bootstrapping process involves the home EAP server and the ER + server, but also impacts the peer and the authenticator. In ERP, the + peer must derive the same keying material as the ER server. To achieve + this, it must learn the domain name of the ER server. How this + information is acquired is outside the scope of this specification, but + it may involves that the authenticator is configured to advertize this + domain name, especially in the case of re-authentication after a + handover. <vspace blankLines="1" /> The bootstrapping of an ER server + with a given root key happens either during the initial EAP + authentication of the peer when the EMSK -- from which the root key is + derived -- is created, during the first re-authentication, or sometime + between those events. We only consider the first two possibilities in + this specification, in the following sub-sections.</t> + + <section title="Bootstrapping During the Initial EAP authentication"> + <t>Bootstrapping the ER server during the initial EAP authentication + (also known as implicit bootstrapping) offers the advantage that the + server is immediatly available for re-authentication of the peer, thus + minimizing re-authentication delay. On the other hand, it is possible + that only a small number of peers will use re-authentication in the + visited domain. Deriving and caching key material for all the peers + (for example, for the peers that do not support ERP) is a waste of + resources and SHOULD be avoided. <vspace blankLines="1" /> To achieve + implicit bootstrapping, the ER server must act as a Diameter EAP Proxy + as defined in the Diameter Base Protocol <xref + target="RFC3588"></xref>, and routing must be configured so that + Diameter messages of a full EAP authentication are routed through this + proxy. The figure bellow illustrates this mechanism. <figure + align="center" anchor="Implict" + 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) + (Key AVP (rRK)) + <------------------------- + Diameter EAP/DEA + (EAP-Success) + (MSK) + [ERP-Realm] +]]></artwork> + </figure> 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 (which might happen if there are ER servers + in the visited and the home domains), then forwards the request. + <vspace blankLines="1" /> If the EAP server does not support the ERP + extensions, it will simply ignore this grouped AVP and continue as + specified in <xref target="RFC4072">RFC 4072</xref>. If the server + supports the ERP extensions, it caches the ERP-Realm value with the + session data, and continues the EAP authentication. When the + authentication is complete, if it is successful and the EAP method + generated an EMSK, the server MUST derive the rRK as specified in + <xref target="RFC5296">RFC 5296</xref>, and include an instance of the + Key AVP <xref target="KAVP"></xref> in the Diameter-EAP-Answer + message. <vspace blankLines="1" /> 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, extract and remove any + Key AVP <xref target="KAVP"></xref> from the message, and save its + content. If the message does not contain an ERP-RK-Answer AVP, the ER + server MAY cache this information to avoid possible subsequent + re-authentication attempts for this session. In any case, the + information stored SHOULD NOT have a lifetime greater than the EMSK + lifetime <list style="hanging"> + <t hangText="QUESTION:"><vspace blankLines="0" /> 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?</t> + </list> <vspace blankLines="1" /> If the ER server is successfully + bootstrapped, it MAY also add the ERP-Realm AVP after removing the + ERP-RK-Answer AVP in the EAP/DEA 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. <list style="hanging"> + <t hangText="QUESTION:"><vspace blankLines="0" /> Is this + possible? It might be useful...</t> + </list></t> + </section> + + <section title="Bootstrapping During the First Re-authentication"> + <t>Bootstrapping the ER server during the first re-authentication + (also known as explicit bootstrapping) offers several advantages: it + saves resources, since we generate and cache only root keys that we + actually need, and it can accomodate inter-domain handovers or ER + servers that lose their state (for example after reboot). <list + style="hanging"> + <t hangText="COMMENT:"><vspace blankLines="0" /> This last point + might not be true currently, since the peer would not issue a + bootstrapping exchange... But this might change also with + RFC5296bis AFAIU</t> + </list> On the other hand, the first re-authentication with the ER + server requires a one-round-trip exchange 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). It also requires some + synchronization between the peer and the visited domain: since the ERP + message used is different <list style="hanging"> + <t hangText="QUESTION:"><vspace blankLines="0" /> and the root key + used also?</t> + </list> for the explicit bootstrapping exchange than for normal + re-authentication; explicit bootstrapping should not be used if + implicit bootstrapping was already performed. <list style="hanging"> + <t hangText="QUESTION:"><vspace blankLines="0" /> What should we + do if the ER server receives an explicit bootstrapping request but + already possess the rDSRK? Can it answer without going to the home + server? That would be simpler -- planned in rfc5296bis ?</t> + </list> <vspace blankLines="1" /> The ER server receives the ERP/DER + message containing the EAP-Initiate/Re-Auth message with the 'B' flag + set. It proxies this message, and performs the following processing in + addition to standard proxy operations: <list> + <t>Changes the Application Id in the header of the message to + Diameter EAP Application (code 5).</t> + + <t>Change the content of Application-Auth-Id accordingly. <list + style="hanging"> + <t hangText="QUESTION:"><vspace blankLines="0" /> Is t better + to leave it unmodified?</t> + </list></t> + + <t>Add the ERP-RK-Request AVP, which contains the name of the + domain where the ER server is located.</t> + + <t><list style="hanging"> + <t hangText="QUESTION:"><vspace blankLines="0" /> Add the + Destination-Host to reach the appropriate EAP server, the one + with the EMSK. How does the ER server know this + information?</t> + </list></t> + </list> Then the server forwards the EAP/DER request, which is + routed to the home EAP server. <vspace blankLines="1" /> If the home + EAP server does not support the 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 EAP/DEA reply message <xref target="RFC4072"></xref>. + including an instance of the Key AVP <xref target="KAVP"></xref>. + <list style="hanging"> + <t hangText="QUESTION:"><vspace blankLines="0" /> What about + authorization AVPs?</t> + </list> <vspace blankLines="1" /> The ER server receives this + EAP/DEA and proxies it as follows, in addition to standard proxy + operations: <list> + <t>Set the Application Id back to Diameter ERP (code TBD)</t> + + <t>Extract and cache the content of the Key AVP. <list + style="hanging"> + <t hangText="QUESTION:"><vspace blankLines="0" /> And + authorization AVPs ?</t> + </list></t> + </list> The DEA is then forwarded to the authenticator, that can use + the rMSK as described in <xref target="RFC5296">RFC 5296</xref>. + <vspace blankLines="1" /> The figure below captures this proxy + behavior: <figure align="center" anchor="FigExplicit" + 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) + (Key AVP) + <---------------------- + Diameter ERP/DEA + (EAP-Finish) + (Key AVP) +]]></artwork> + </figure></t> + </section> + </section> + + <section anchor="Re-authentication" title="Re-Authentication"> + <t>This section describes in detail a re-authentication exchange with a + (bootstrapped) ER server. The following figure summarizes the + re-authentication exchange. <figure align="center" anchor="FigReauth" + title="Diameter ERP Re-authentication 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 + Key AVP: rMSK + <---------------------- + EAP-Finish/Re-auth +]]></artwork> + </figure> In ERP, the peer sends an EAP-Initiate/Re-auth message to + the ER server via the authenticator. Alternatively, the authenticator + 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. <vspace blankLines="1" /> If the + authenticator does not support ERP (pure <xref target="RFC4072"></xref> + support), it discards the EAP packets with an unknown ERP-specific code + (EAP-Initiate). The peer may fallback to full EAP authentication in this + case. <vspace blankLines="1" /> When the authenticator receives an + EAP-Initiate/Re-auth message from the peer, it process as described in + <xref target="RFC5296"></xref> with regards to the EAP state machine. It + creates a Diameter EAP Request message following the general process of + <xref target="RFC4072">DiameterEAP</xref>, with the following + differences: <list> + <t>The Application Id in the header is set to Diameter ERP (code + TBD).</t> + + <t>The value in Auth-Application-Id AVP is also set to Diameter ERP + Application.</t> + + <t>The keyName-NAI attribute from ERP message is used to create the + content of User-Name AVP and Destination-Realm AVP.</t> + + <t><list style="hanging"> + <t hangText="FFS:"><vspace blankLines="0" /> What about + Session-ID AVP -- in case of re-auth at the same place, and in + case of handover?</t> + </list></t> + + <t>The Auth-Request-Type AVP content is set to [Editor's note: FFS]. + <list style="hanging"> + <t hangText="QUESTION:"><vspace blankLines="0" /> Do we really + do authorization with Diameter ERP ? -- need to pass the + authorization attrs to the ER server in that case. Idea FFS: we + do authorization only for explicit bootstrapping + exchanges...</t> + </list></t> + + <t>The EAP-Payload AVP contains the ERP message, + EAP-Initiate/Re-Auth.</t> + </list> Then this ERP/DER message is sent as described in <xref + target="Overview"></xref>. <vspace blankLines="1" /> The ER server + receives and processes this request as described in <xref + target="Overview"></xref>. It then creates an ERP/DEA message following + the general processing described in <xref target="RFC4072">RFC + 4072</xref>, with the following differences: <list> + <t>The Application Id in the header is set to Diameter ERP (code + TBD).</t> + + <t>The value of the Auth-Application-Id AVP is also set to Diameter + ERP Application.</t> + + <t>The EAP-Payload AVP contains the ERP message, + EAP-Finish/Re-auth.</t> + + <t>In case of successful authentication, an instance of the Key AVP + containing the Re-authentication Master Session Key (rMSK) derived + by ERP is included. <list style="hanging"> + <t hangText="QUESTION:"><vspace blankLines="0" /> What about all + the authorization attributes? If we want to include them, they + have to be present on the ER server...</t> + </list></t> + </list> When the authenticator receives this ERP/DEA answer, it + processes it as described in <xref target="RFC4072">Diameter EAP</xref> + and <xref target="RFC5296">RFC 5296</xref>: the content of EAP-Payload + AVP content is forwarded to the peer, and the contents of the + Keying-Material AVP <xref target="I-D.ietf-dime-local-keytran"></xref> + is used as a shared secret for Secure Association Protocol.</t> + </section> + + <section anchor="ApplicationId" title="Application Id"> + <t>We define a new Diameter application in this document, Diameter ERP + Application, with an Application Id value of TBD. Diameter nodes + conforming to this specification in the role of ER server MUST advertise + support by including an Auth-Application-Id AVP with a value of Diameter + ERP Application in the of the Capabilities-Exchange-Request and + Capabilities-Exchange-Answer commands <xref target="RFC3588"></xref>. + <vspace blankLines="1" /> 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 <xref target="AVPs"></xref>, although these AVP have + the 'M' flag cleared.</t> + </section> + + <section anchor="AVPs" title="AVPs"> + <t>This section discusses the AVPs used by the Diameter ERP + application.</t> + + <section title="ERP-RK-Request AVP"> + <t>The ERP-RK-Request AVP (AVP Code TBD) is of type grouped AVP. This + AVP is used by the ER server to indicate its willingness to act as ER + server for a particular session. <vspace blankLines="1" /> This AVP + has the M and V bits cleared. <figure align="center" anchor="ERRABNF" + title="ERP-RK-Request ABNF"> + <artwork><![CDATA[ + ERP-RK-Request ::= < AVP Header: TBD > + { ERP-Realm } + * [ AVP ] +]]></artwork> + </figure></t> + </section> + + <section title="ERP-Realm AVP"> + <t>The ERP-Realm AVP (AVP Code TBD) is of type DiameterIdentity. It + contains the name of the realm in which the ER server is located. + <list style="hanging"> + <t hangText="FFS:"><vspace blankLines="0" /> We may re-use + Origin-Realm here instead? On the other hand, ERP-Realm may be + useful if the ER server is in a third-party realm, if this is + possible.</t> + </list> <vspace blankLines="1" /> This AVP has the M and V bits + cleared.</t> + </section> + + <section anchor="KAVP" title="Key AVP"> + <t>The Key AVP <xref target="I-D.ietf-dime-local-keytran"></xref> is + of type "Grouped" and is used to carry the rMSK and associated + attributes. The usage of the Key AVP and its constituent AVPs in this + application is specified in the following sub-sections.</t> + + <section title="Key-Type AVP"> + <t>The value of the Key-Type AVP MUST be set to 3 for rRK.</t> + </section> + + <section title="Keying-Material AVP"> + <t>The Keying-Material AVP contains rRK sent by the home EAP server + to the ER server, in answer to a request containing an + ERP-RK-Request AVP. How this material is derived and used is + specified in <xref target="RFC5296">RFC 5296</xref>.</t> + </section> + + <section title="Key-Name AVP"> + <t>This AVP contains the EMSKname which identifies the keying + material. The derivation of this name is specified in <xref + target="RFC5296">RGC 5296</xref>.</t> + </section> + + <section title="Key-Lifetime AVP"> + <t>The Key-Lifetime AVP contains the lifetime of the keying material + in seconds. It MUST NOT be greater than the remaining lifetime of + the EMSK from which the material was derived.</t> + </section> + </section> + </section> + + <section anchor="Issues" title="Open issues"> + <t>This document does not address some known issues in Diameter ERP + mechanism. The authors would like to hear ideas about how to address + them. <vspace blankLines="1" /> The main issue is the use of ERP for + authentication after a handover of the peer to a new authenticator (or + different authenticator port). Diameter ERP is not meant to be a + mobility protocol. A number of issues appear when we try to do handover + in Diameter ERP (alone): how to manage the Session-Id AVP; how does the + ER server provide the Authorization AVPs; how does the peer learn the + ERP domain of the new authenticator; how does the home server reachs the + peer to for example terminate the session; and so on... Therefore, the + management of the session for a mobile peer is not (yet) addressed in + this document. It must be studied how Diameter ERP can be for example + used in conjunction with a mobility application (Diameter MIP4, Diameter + MIP6) to support the optimized re-authentication in such situation. + <vspace blankLines="1" /> Another issue concerns the case where the home + realm contains several EAP servers. In multi rounds full EAP + authentication, the Destination-Host AVP provides the solution to reach + the same server across the exchanges. Only this server possess the EMSK + for the session. In case of explicit bootstrapping, the ER server must + therefore be able to reach the correct server to request the DSRK. A + solution might consist in saving the Origin-Host AVP of all successful + EAP/DEA in the ER server, which is a bit similar to the implicit + bootstrapping scenario described here -- only we save the server name + instead of the root key, and we must then be able to match the DSRK with + the user name. <vspace blankLines="1" /> Finally, this document + currently lacks a description of what happens when a Re-Auth-Request is + received for a peer on the authenticator.</t> + </section> + + <section anchor="Acknowledgements" title="Acknowledgements"> + <t>Hannes Tschofenig wrote the initial draft for this document and + provided useful reviews. <vspace blankLines="1" /> Vidya Narayanan + reviewed a rough draft version of the document and found some errors. + <vspace blankLines="1" /> Lakshminath Dondeti contributed to the early + versions of the document. <vspace blankLines="1" /> 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 anchor="IANA_AppId" title="Diameter Application Identifier"> + <t>This specification requires IANA to allocate a new value "Diameter + ERP" in the "Application IDs" registry <xref target="RFC3588"> using + the policy specified in Section 11.3 of RFC 3588</xref>.</t> + </section> + + <section anchor="IANA_AVP" title="New AVPs"> + <t>This specification requires IANA to allocate new values from the + "AVP Codes" registry <xref target="RFC3588">according to the policy + specified in Section 11.1 of RFC 3588</xref> for the following AVPs: + <list> + <t>ERP-RK-Request</t> + + <t>ERP-Realm</t> + </list>These AVPs are defined in <xref target="AVPs"></xref>.</t> + </section> + </section> + + <section anchor="Security" title="Security Considerations"> + <t>The security considerations from the following documents also apply + here: <list style="symbols"> + <t><xref target="RFC3588">RFC 3588</xref></t> + + <t><xref target="RFC4072">RFC 4072</xref></t> + + <t><xref target="RFC5247">RFC 5247</xref></t> + + <t><xref target="RFC5295">RFC 5295</xref></t> + + <t><xref target="RFC5296"></xref></t> + </list> <list style="hanging"> + <t hangText="FFS:"><vspace blankLines="0" /> 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?</t> + </list> 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. <list style="hanging"> + <t hangText="QUESTION:"><vspace blankLines="0" /> What does this + paragraph actually mean?</t> + </list></t> + </section> + </middle> + + <back> + <references title="Normative References"> + &RFC2119; + + &RFC3588; + + &RFC4072; + + &RFC5295; + + &RFC5296; + + &I-D.ietf-dime-local-keytran; + + &RFC3748; + </references> + + <references title="Informative References"> + &RFC5247; + </references> + </back> +</rfc>