Mercurial > hg > ietf
changeset 52:1cf2e1a5365f
Added tag
| author | Sebastien Decugis <sdecugis@nict.go.jp> |
|---|---|
| date | Mon, 08 Mar 2010 17:02:46 +0900 |
| parents | 95c760def8b9 |
| children | 6fb888615123 |
| files | draft-ietf-dime-erp-03.xml |
| diffstat | 1 files changed, 0 insertions(+), 888 deletions(-) [+] |
line wrap: on
line diff
--- a/draft-ietf-dime-erp-03.xml Mon Mar 08 17:02:07 2010 +0900 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,888 +0,0 @@ -<?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-02.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-03.txt" ipr="trust200902"> - <front> - <title abbrev="Diameter support for ERP">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." surname="Zorn" role="editor"> - <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>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" in this document to refer to a - Diameter-EAP-Request command with its Application Id set to Diameter ERP - application. Similarly, we use the "ERP/DEA", "EAP/DER", and - "EAP/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 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, as described in Diameter EAP application - <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 section <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"/> 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 section - <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 - subsections. - </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"/> - 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"/> - 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"/>. - <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"/> - 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 - section <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"/> 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 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 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 section <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>