Mercurial > hg > ietf
changeset 46:409fb7bb22b7
Submitted -02, prepared for new -03
author | Sebastien Decugis <sdecugis@nict.go.jp> |
---|---|
date | Thu, 08 Oct 2009 16:29:46 +0900 |
parents | 1c9b16ee3039 |
children | ac502c889840 |
files | draft-ietf-dime-erp-02.xml draft-ietf-dime-erp-03.xml |
diffstat | 2 files changed, 877 insertions(+), 877 deletions(-) [+] |
line wrap: on
line diff
--- a/draft-ietf-dime-erp-02.xml Thu Oct 08 16:23:35 2009 +0900 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,877 +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 RFC4187 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4187.xml"> -<!ENTITY RFC5247 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5247.xml"> -<!ENTITY RFC5295 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5295.xml"> -<!ENTITY RFC5296 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5296.xml"> -<!ENTITY I-D.ietf-hokey-key-mgm SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-hokey-key-mgm-06.xml"> -<!ENTITY I-D.ietf-dime-app-design-guide SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dime-app-design-guide-08.xml"> -<!ENTITY I-D.gaonkar-radext-erp-attrs SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-gaonkar-radext-erp-attrs-03.xml"> -<!ENTITY I-D.wu-dime-local-keytran SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-wu-dime-local-keytran-00.xml"> -<!ENTITY nbsp " "> -]> -<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> -<?rfc strict="yes"?> -<?rfc comments="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-02.txt" ipr="trust200902"> - <front> - <title abbrev="Diameter support for ERP">Diameter support for 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.Z." role="editor" surname="Zorn"> - <organization>Network Zen</organization> - - <address> - <postal> - <street>1310 East Thomas Street</street> - - <street>#306</street> - - <city>Seattle</city> - - <region>Washington</region> - - <code>98102</code> - - <country>USA</country> - </postal> - - <phone>+1 (206) 377-9035</phone> - - <email>gwz@net-zen.net</email> - </address> - </author> - - <date year="2009" /> - - <area>Operations & Management</area> - - <workgroup>Diameter Maintenance and Extensions (DIME)</workgroup> - - <keyword>Internet-Draft</keyword> - - <keyword>EAP</keyword> - - <keyword>Diameter</keyword> - - <keyword>Re-authentication</keyword> - - <keyword>inter-authenticator roaming</keyword> - - <abstract> - <t>EAP Re-authentication Protocol (ERP) defines extensions to the - Extensible Authentication Protocol (EAP) to support efficient - re-authentication between the 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 ER authenticator and 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"></xref> defines the EAP Re-authentication - Protocol (ERP). It consists in the following steps:<list style="numbers"> - <t>Bootstrapping: 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>Re-authentication: a one-round-trip exchange between the peer and - the ER server, resulting in mutual authentication. To accomplish the - EAP reauthentication functionality, ERP defines two new EAP codes - - EAP-Initiate and EAP-Finish.</t> - </list></t> - - <t>This document defines how Diameter transports the ERP messages - (Re-authentication step). For this purpose, we define a new Application - Id for ERP, and re-use the Diameter EAP commands (DER/DEA).</t> - - <t>This document also discusses the distribution of the root key - (bootstrapping step), either during the initial EAP authentication - (implicit bootstrapping) or during the first ERP exchange (explicit - bootstrapping). Security considerations for this key distribution are - detailed in <xref target="RFC5295"></xref>.</t> - </section> - - <section title="Terminology"> - <t>This document uses terminology defined in <xref - target="RFC3748"></xref>, <xref target="RFC5295"></xref>, <xref - target="RFC5296"></xref>, and <xref target="RFC4072"></xref>.</t> - - <t>"Root key" (RK) or "bootstrapping material" refer to the rRK or rDSRK - derived from an EMSK, depending on the location of the ER server in home - or foreign domain.</t> - - <t>We 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 makes the following assumptions.</t> - - <t>The Home EAP server of a peer that wants to use ERP is extended to - support:<list> - <t>Cryptographic operations needed to derive the ERP root key from - the EMSK. By deriving the ERP root key for a specific domain, the - home EAP server implicitly authorizes the use of ERP within this - domain.</t> - - <t>Diameter operations needed to include this root key in a response - message, when a request for this root key was received in a request - message. The two AVP that contain the request for and the root key - material are defined in this document.</t> - - <t>(recommended) Ability to answer a DER message with EAP-Payload - containing an explicit bootstrapping ERP message.</t> - </list></t> - - <t>The Authenticator (NAS) is extended to support:<list> - <t>Allow the new ERP command codes (EAP-Initiate and EAP-Finish) in - its EAP pass-through mode.</t> - - <t>(optional) Send the EAP-Initiate/Re-Auth-Start message</t> - - <t>(optional) Provide the local domain name via lower layer specific - mechanism or via TLV in the EAP-Initiate/Re-Auth-Start message.</t> - - <t>Encapsulate ERP message and receive corresponding Diameter - answer, as described in this document.</t> - </list></t> - - <t>If one of the components does not match these assumptions, the ERP - mechanism will fail. In such situation, a full EAP authentication may be - attempted as a fallback mechanism.</t> - - <t>We consider 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 several - 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.</t> - - <figure title="Figure. Diameter ERP overview."> - <artwork><![CDATA[ - Diameter +--------+ - +-------------+ ERP +-----------+ (*) | Home | -Peer <->|Authenticator|<=======>| ER server | <---> | EAP | - +-------------+ +-----------+ | server | - +--------+ - (*) Diameter EAP application, - explicit bootstraping scenario only.]]></artwork> - </figure> - - <t>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). <cref>Can the ER server be located in a third - domain (ex: broker's) according to ERP mechanism?</cref></t> - - <t>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 Diameter ERP application (code: TBD <cref>TBD IANA</cref>) in the - message. The exact processing to generate the ERP/DER message is - detailed in section <xref target="Re-authentication"></xref>.</t> - - <t>If there is an ER server in the same domain as the authenticator - (local domain), Diameter routing MUST <cref>SHOULD ? FFS...</cref> be - configured so that this ERP/DER message reachs this server, even if the - Destination-Realm is not the local domain.</t> - - <t>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"></xref>, this realm is the home domain of the peer in - case of bootstrapping exchange ('B' flag is set in ERP message) or the - domain of the bootstrapped ER server otherwise <cref>This actually might - allow the ER server to be in a third party realm</cref>.</t> - - <t>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 as specified in <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.</t> - - <t>When an ER server receives the ERP/DER message, it searches its local - database for a root key <cref>and authorization state ?</cref> 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"></xref> then creates the ERP/DEA answer as described in - <xref target="Re-authentication"></xref>. The rMSK is included in this - answer.</t> - - <t>Finally, the authenticator extracts the rMSK from the ERP/DEA as - described in <xref target="RFC5296"></xref>, and forwards the content of - the EAP-Payload AVP, the EAP-Finish/Re-Auth message, to the peer.</t> - - <t>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 <cref>This may not be true in future RFC5296bis - ?</cref>. 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.</t> - - <t>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 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 the 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.</t> - - <t>To achieve implicit bootstrapping, the ER server must act as a - Diameter EAP Proxy as defined in 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 captures this mechanism.</t> - - <figure title="Figure. 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 (which might happen if there are ER servers in the visited - and the home domains), 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 payloads.</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, extract and remove any ERP-RK-Answer AVP from the - message, 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 subsequent re-authentication attempts for this session. In - any case, the information stored SHOULD NOT have a lifetime greater - than the EMSK lifetime <cref>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 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. <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 - (also known as explicit bootstrapping) offers several advantages: it - saves resources, since we generate and cache only root key that we - actually need, and it can accomodate inter-domain handovers or ER - servers that loose their state (for example after reboot) <cref>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</cref>. 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 is different<cref>and the root key used also ?</cref> for - explicit bootstrapping exchange and for normal re-authentication, - explicit bootstrapping should not be used if implicit bootstrapping - was already performed.</t> - - <t><cref>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 ?</cref></t> - - <t>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 do the following processing in addition to standard proxy - operations:<list> - <t>Change 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. <cref>Is - it better to leave it unmodified?</cref></t> - - <t>Add the ERP-RK-Request AVP, which contains the name of the - domain where the ER server is located.</t> - - <t><cref>Add the Destination-Host to reach the appropriate EAP - server, the one with the EMSK. How does the ER server know this - information ?</cref></t> - </list>Then the server forwards the EAP/DER request, which is routed - to the home EAP server.</t> - - <t>If the home EAP 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 EAP/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. <cref>What about authorization AVPs ?</cref></t> - - <t>The ER server receives this EAP/DEA and proxies it as follow, in - addition to standard proxy operations:<list> - <t>Set the Application Id back to Diameter ERP (code TBD<cref>TBD - IANA</cref>)</t> - - <t>Extract and cache the content of the ERP-RK-Answer. <cref>And - authorization AVPs ?</cref></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 proxy behavior:</t> - - <figure title="Figure. ERP explicit bootstrapping message flow"> - <artwork><![CDATA[ -Authenticator ER server Home EAP server -============= ========= =============== - -----------------------> - Diameter ERP/DER - (EAP-Initiate) - ------------------------> - Diameter EAP/DER - (EAP-Initiate) - (ERP-RK-Request) - - <------------------------ - Diameter EAP/DEA - (EAP-Finish) - (ERP-RK-Answer) - (rMSK) - <---------------------- - Diameter ERP/DEA - (EAP-Finish) - (rMSK) -]]></artwork> - </figure> - </section> - </section> - - <section anchor="Re-authentication" title="Re-Authentication"> - <t>This section describes in detail a re-authentication exchange with a - (bootstrapped) ER server. The following figure summarizes the - re-authentication exchange.</t> - - <figure title="Figure. Diameter ERP exchange. "> - <artwork><![CDATA[ - ER server - (bootstrapped) - Peer Authenticator (local or home domain) - ==== ============= ====================== - [ <------------------------ ] - [optional EAP-Initiate/Re-auth-start] - - -----------------------> - EAP-Initiate/Re-auth - ==================================> - Diameter ERP, cmd code DER - User-Name: Keyname-NAI - EAP-Payload: EAP-Initiate/Re-auth - - <================================== - Diameter ERP, cmd code DEA - EAP-Payload: EAP-Finish/Re-auth - EAP-Master-Session-Key: rMSK - <---------------------- - EAP-Finish/Re-auth -]]></artwork> - </figure> - - <t>In ERP, the peer sends an EAP-Initiate/Re-auth message to the ER - server via the authenticator. Alternatively, the NAS may send an - EAP-Initiate/Re-auth-Start message to the peer to trigger the start of - ERP. In this case, the peer responds with an EAP-Initiate/Re-auth - message to the NAS.</t> - - <t>If the authenticator does not support ERP (pure <xref - target="RFC4072"></xref> support), it discards the EAP packets with - unknown ERP-specific code (EAP-Initiate). The peer may fallback to full - EAP authentication in such case.</t> - - <t>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">Diameter - EAP</xref>, with the following differences:<list> - <t>The Application Id in the header is set to Diameter ERP (code TBD - <cref>TBD IANA</cref>).</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><cref>FFS: What about Session-ID AVP -- in case of re-auth at the - same place, and in case of handover?</cref></t> - - <t>The Auth-Request-Type AVP content is set to [Editor's note: - FFS]<cref>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...</cref>.</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>.</t> - - <t>The ER server receives and processes this request as described in - <xref target="Overview"></xref>. It then creates a Diameter answer - ERP/DEA, following the general processing described in <xref - target="RFC4072"></xref>, with the following differences:<list> - <t>The Application Id in the header is set to Diameter ERP (code - TBD<cref>TBD IANA</cref>).</t> - - <t>The value in Auth-Application-Id AVP is also set to Diameter ERP - Application.</t> - - <t>The Result-Code AVP is set to <cref>version -00 stated a SHOULD - here, not sure why ?</cref> an error value in case ERP - authentication fails, or to DIAMETER_SUCCESS if ERP is - successful.</t> - - <t>The EAP-Payload AVP contains the ERP message, - EAP-Finish/Re-auth.</t> - - <t>In case of successful authentication, the EAP-Master-Session-Key - AVP contains the Re-authentication Master Session Key (rMSK) derived - by ERP.</t> - - <t><cref>What about all the authorization attributes? If we want to - include them, they have to be present on the ER server...</cref></t> - </list></t> - - <t>When the authenticator receives this ERP/DEA answer, it processes it - as described in <xref target="RFC4072">Diameter EAP</xref> and <xref - target="RFC5296"></xref>: the content of EAP-Payload AVP content is - forwarded to the peer, and the content of EAP-Master-Session-Key AVP 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<cref>TBD IANA</cref>. - 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, - as described in <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 - section <xref target="AVPs"></xref> , although these AVP have the 'M' - flag cleared.</t> - </section> - - <section anchor="AVPs" title="AVPs"> - <t>This specification defines the following new AVPs. <cref>FFS: to - align with draft-wu-dime-local-keytran-02 if it becomes a WG - item</cref></t> - - <section title="ERP-RK-Request AVP"> - <t>The ERP-RK-Request AVP (AVP Code TBD<cref>TBD IANA</cref>) 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.</t> - - <t>This AVP has the M and V bits cleared.</t> - - <figure title="Figure. 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 TBD<cref>TBD IANA</cref>) is of type - DiameterIdentity. 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 if the ER server is not in a third-party - realm, if this is possible.</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 TBD<cref>TBD IANA</cref>) is of - type grouped AVP. It is used by the home EAP server to provide ERP - root key material to the ER server.</t> - - <t>This AVP has the M and V bits cleared.</t> - - <figure title="Figure. 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 TBD<cref>TBD IANA</cref>) is of type - OctetString. It contains the root key (either rRK or rDSRK) sent by - the home EAP server to the ER server, in answer to request containing - an ERP-RK-Request AVP. 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 instead? Must check - the exact definition...</cref></t> - - <t>This AVP has the M and V bits cleared.</t> - </section> - - <section title="ERP-RK-Name AVP"> - <t>The ERP-RK-Name AVP (AVP Code TBD<cref>TBD IANA</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 instead ?</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 TBD<cref>TBD IANA</cref>) is of - type Unsigned32 <cref>do we really need 64 as in -00 ? 2^32 secs is - already more than 100 years, which is too long for a key lifetime - !</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>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 advertizes support for the Diameter ERP application - MUST support the new AVPs defined in this specification.</t> - - <figure title="Figure. 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="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.</t> - - <t>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.</t> - - <t>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.</t> - - <t>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.</t> - - <t>Vidya Narayanan reviewed a rough draft version of the document and - found some errors.</t> - - <t>Lakshminath Dondeti contributed to the early versions of the - document.</t> - - <t>Many thanks to these people!</t> - </section> - - <section anchor="IANA" title="IANA Considerations"> - <t>This document requires IANA registration of the following new - elements in the <eref - target="http://www.iana.org/assignments/aaa-parameters/">Authentication, - Authorization, and Accounting (AAA) Parameters</eref> registries.</t> - - <section title="Diameter ERP application"> - <t>This specification requires IANA to allocate a new value "Diameter - ERP" in the "Application IDs" registry created by in <xref - target="RFC3588"></xref>.</t> - - <figure title="IANA consideration for Diameter ERP application"> - <artwork><![CDATA[ - Application Identifier | Value - -----------------------------------+------ - Diameter ERP | TBD -]]></artwork> - </figure> - </section> - - <section title="New AVPs"> - <t>This specification requires IANA to allocate new values from the - "AVP Codes" registry defined in <xref target="RFC3588"></xref> for the - following AVPs:<list> - <t>ERP-RK-Request</t> - - <t>ERP-Realm</t> - - <t>ERP-RK-Answer</t> - - <t>ERP-RK</t> - - <t>ERP-RK-Name</t> - - <t>ERP-RK-Lifetime</t> - </list>These AVPs are defined in section <xref - target="AVPs"></xref>.</t> - </section> - </section> - - <section anchor="Security" title="Security Considerations"> - <t>The security considerations from the following RFC apply here: <xref - target="RFC3588"></xref>, <xref target="RFC4072"></xref>, <xref - target="RFC5247"></xref>, <xref target="RFC5295"></xref>, and <xref - target="RFC5296"></xref>.</t> - - <t><cref>FFS: Do we really respect these security considerations with - the mechanism we describe here? Is it safe to use ERP-RK-Request / - Answer AVPs? What is the worst case?</cref></t> - - <t>EAP channel bindings may be necessary to ensure that the Diameter - client and the server are in sync regarding the key Requesting Entity's - Identity. Specifically, the Requesting Entity advertises its identity - through the EAP lower layer, and the user or the EAP peer communicates - that identity to the EAP server (and the EAP server communicates that - identity to the Diameter server) via the EAP method for user/peer to - server verification of the Requesting Entity's Identity.<cref>Editor: I - really don't understand this paragraph ^^'...</cref></t> - </section> - </middle> - - <back> - <references title="Normative References"> - &RFC2119; - - &RFC3588; - - &RFC4072; - - &RFC5295; - - &RFC5296; - - &RFC3748; - </references> - - <references title="Informative References"> - &RFC4187; - - &RFC5247; - - &I-D.ietf-hokey-key-mgm; - - &I-D.wu-dime-local-keytran; - - &I-D.ietf-dime-app-design-guide; - </references> - </back> -</rfc>
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/draft-ietf-dime-erp-03.xml Thu Oct 08 16:29:46 2009 +0900 @@ -0,0 +1,877 @@ +<?xml version="1.0" encoding="US-ASCII"?> +<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ +<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> +<!ENTITY RFC3748 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml"> +<!ENTITY RFC3588 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml"> +<!ENTITY RFC4072 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4072.xml"> +<!ENTITY RFC4187 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4187.xml"> +<!ENTITY RFC5247 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5247.xml"> +<!ENTITY RFC5295 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5295.xml"> +<!ENTITY RFC5296 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5296.xml"> +<!ENTITY I-D.ietf-hokey-key-mgm SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-hokey-key-mgm-06.xml"> +<!ENTITY I-D.ietf-dime-app-design-guide SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dime-app-design-guide-08.xml"> +<!ENTITY I-D.gaonkar-radext-erp-attrs SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-gaonkar-radext-erp-attrs-03.xml"> +<!ENTITY I-D.wu-dime-local-keytran SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-wu-dime-local-keytran-00.xml"> +<!ENTITY nbsp " "> +]> +<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> +<?rfc strict="yes"?> +<?rfc comments="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 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.Z." role="editor" surname="Zorn"> + <organization>Network Zen</organization> + + <address> + <postal> + <street>1310 East Thomas Street</street> + + <street>#306</street> + + <city>Seattle</city> + + <region>Washington</region> + + <code>98102</code> + + <country>USA</country> + </postal> + + <phone>+1 (206) 377-9035</phone> + + <email>gwz@net-zen.net</email> + </address> + </author> + + <date year="2009" /> + + <area>Operations & Management</area> + + <workgroup>Diameter Maintenance and Extensions (DIME)</workgroup> + + <keyword>Internet-Draft</keyword> + + <keyword>EAP</keyword> + + <keyword>Diameter</keyword> + + <keyword>Re-authentication</keyword> + + <keyword>inter-authenticator roaming</keyword> + + <abstract> + <t>EAP Re-authentication Protocol (ERP) defines extensions to the + Extensible Authentication Protocol (EAP) to support efficient + re-authentication between the 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 ER authenticator and 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"></xref> defines the EAP Re-authentication + Protocol (ERP). It consists in the following steps:<list style="numbers"> + <t>Bootstrapping: 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>Re-authentication: a one-round-trip exchange between the peer and + the ER server, resulting in mutual authentication. To accomplish the + EAP reauthentication functionality, ERP defines two new EAP codes - + EAP-Initiate and EAP-Finish.</t> + </list></t> + + <t>This document defines how Diameter transports the ERP messages + (Re-authentication step). For this purpose, we define a new Application + Id for ERP, and re-use the Diameter EAP commands (DER/DEA).</t> + + <t>This document also discusses the distribution of the root key + (bootstrapping step), either during the initial EAP authentication + (implicit bootstrapping) or during the first ERP exchange (explicit + bootstrapping). Security considerations for this key distribution are + detailed in <xref target="RFC5295"></xref>.</t> + </section> + + <section title="Terminology"> + <t>This document uses terminology defined in <xref + target="RFC3748"></xref>, <xref target="RFC5295"></xref>, <xref + target="RFC5296"></xref>, and <xref target="RFC4072"></xref>.</t> + + <t>"Root key" (RK) or "bootstrapping material" refer to the rRK or rDSRK + derived from an EMSK, depending on the location of the ER server in home + or foreign domain.</t> + + <t>We 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 makes the following assumptions.</t> + + <t>The Home EAP server of a peer that wants to use ERP is extended to + support:<list> + <t>Cryptographic operations needed to derive the ERP root key from + the EMSK. By deriving the ERP root key for a specific domain, the + home EAP server implicitly authorizes the use of ERP within this + domain.</t> + + <t>Diameter operations needed to include this root key in a response + message, when a request for this root key was received in a request + message. The two AVP that contain the request for and the root key + material are defined in this document.</t> + + <t>(recommended) Ability to answer a DER message with EAP-Payload + containing an explicit bootstrapping ERP message.</t> + </list></t> + + <t>The Authenticator (NAS) is extended to support:<list> + <t>Allow the new ERP command codes (EAP-Initiate and EAP-Finish) in + its EAP pass-through mode.</t> + + <t>(optional) Send the EAP-Initiate/Re-Auth-Start message</t> + + <t>(optional) Provide the local domain name via lower layer specific + mechanism or via TLV in the EAP-Initiate/Re-Auth-Start message.</t> + + <t>Encapsulate ERP message and receive corresponding Diameter + answer, as described in this document.</t> + </list></t> + + <t>If one of the components does not match these assumptions, the ERP + mechanism will fail. In such situation, a full EAP authentication may be + attempted as a fallback mechanism.</t> + + <t>We consider 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 several + 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.</t> + + <figure title="Figure. Diameter ERP overview."> + <artwork><![CDATA[ + Diameter +--------+ + +-------------+ ERP +-----------+ (*) | Home | +Peer <->|Authenticator|<=======>| ER server | <---> | EAP | + +-------------+ +-----------+ | server | + +--------+ + (*) Diameter EAP application, + explicit bootstraping scenario only.]]></artwork> + </figure> + + <t>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). <cref>Can the ER server be located in a third + domain (ex: broker's) according to ERP mechanism?</cref></t> + + <t>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 Diameter ERP application (code: TBD <cref>TBD IANA</cref>) in the + message. The exact processing to generate the ERP/DER message is + detailed in section <xref target="Re-authentication"></xref>.</t> + + <t>If there is an ER server in the same domain as the authenticator + (local domain), Diameter routing MUST <cref>SHOULD ? FFS...</cref> be + configured so that this ERP/DER message reachs this server, even if the + Destination-Realm is not the local domain.</t> + + <t>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"></xref>, this realm is the home domain of the peer in + case of bootstrapping exchange ('B' flag is set in ERP message) or the + domain of the bootstrapped ER server otherwise <cref>This actually might + allow the ER server to be in a third party realm</cref>.</t> + + <t>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 as specified in <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.</t> + + <t>When an ER server receives the ERP/DER message, it searches its local + database for a root key <cref>and authorization state ?</cref> 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"></xref> then creates the ERP/DEA answer as described in + <xref target="Re-authentication"></xref>. The rMSK is included in this + answer.</t> + + <t>Finally, the authenticator extracts the rMSK from the ERP/DEA as + described in <xref target="RFC5296"></xref>, and forwards the content of + the EAP-Payload AVP, the EAP-Finish/Re-Auth message, to the peer.</t> + + <t>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 <cref>This may not be true in future RFC5296bis + ?</cref>. 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.</t> + + <t>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 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 the 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.</t> + + <t>To achieve implicit bootstrapping, the ER server must act as a + Diameter EAP Proxy as defined in 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 captures this mechanism.</t> + + <figure title="Figure. 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 (which might happen if there are ER servers in the visited + and the home domains), 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 payloads.</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, extract and remove any ERP-RK-Answer AVP from the + message, 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 subsequent re-authentication attempts for this session. In + any case, the information stored SHOULD NOT have a lifetime greater + than the EMSK lifetime <cref>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 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. <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 + (also known as explicit bootstrapping) offers several advantages: it + saves resources, since we generate and cache only root key that we + actually need, and it can accomodate inter-domain handovers or ER + servers that loose their state (for example after reboot) <cref>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</cref>. 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 is different<cref>and the root key used also ?</cref> for + explicit bootstrapping exchange and for normal re-authentication, + explicit bootstrapping should not be used if implicit bootstrapping + was already performed.</t> + + <t><cref>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 ?</cref></t> + + <t>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 do the following processing in addition to standard proxy + operations:<list> + <t>Change 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. <cref>Is + it better to leave it unmodified?</cref></t> + + <t>Add the ERP-RK-Request AVP, which contains the name of the + domain where the ER server is located.</t> + + <t><cref>Add the Destination-Host to reach the appropriate EAP + server, the one with the EMSK. How does the ER server know this + information ?</cref></t> + </list>Then the server forwards the EAP/DER request, which is routed + to the home EAP server.</t> + + <t>If the home EAP 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 EAP/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. <cref>What about authorization AVPs ?</cref></t> + + <t>The ER server receives this EAP/DEA and proxies it as follow, in + addition to standard proxy operations:<list> + <t>Set the Application Id back to Diameter ERP (code TBD<cref>TBD + IANA</cref>)</t> + + <t>Extract and cache the content of the ERP-RK-Answer. <cref>And + authorization AVPs ?</cref></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 proxy behavior:</t> + + <figure title="Figure. ERP explicit bootstrapping message flow"> + <artwork><![CDATA[ +Authenticator ER server Home EAP server +============= ========= =============== + -----------------------> + Diameter ERP/DER + (EAP-Initiate) + ------------------------> + Diameter EAP/DER + (EAP-Initiate) + (ERP-RK-Request) + + <------------------------ + Diameter EAP/DEA + (EAP-Finish) + (ERP-RK-Answer) + (rMSK) + <---------------------- + Diameter ERP/DEA + (EAP-Finish) + (rMSK) +]]></artwork> + </figure> + </section> + </section> + + <section anchor="Re-authentication" title="Re-Authentication"> + <t>This section describes in detail a re-authentication exchange with a + (bootstrapped) ER server. The following figure summarizes the + re-authentication exchange.</t> + + <figure title="Figure. Diameter ERP exchange. "> + <artwork><![CDATA[ + ER server + (bootstrapped) + Peer Authenticator (local or home domain) + ==== ============= ====================== + [ <------------------------ ] + [optional EAP-Initiate/Re-auth-start] + + -----------------------> + EAP-Initiate/Re-auth + ==================================> + Diameter ERP, cmd code DER + User-Name: Keyname-NAI + EAP-Payload: EAP-Initiate/Re-auth + + <================================== + Diameter ERP, cmd code DEA + EAP-Payload: EAP-Finish/Re-auth + EAP-Master-Session-Key: rMSK + <---------------------- + EAP-Finish/Re-auth +]]></artwork> + </figure> + + <t>In ERP, the peer sends an EAP-Initiate/Re-auth message to the ER + server via the authenticator. Alternatively, the NAS may send an + EAP-Initiate/Re-auth-Start message to the peer to trigger the start of + ERP. In this case, the peer responds with an EAP-Initiate/Re-auth + message to the NAS.</t> + + <t>If the authenticator does not support ERP (pure <xref + target="RFC4072"></xref> support), it discards the EAP packets with + unknown ERP-specific code (EAP-Initiate). The peer may fallback to full + EAP authentication in such case.</t> + + <t>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">Diameter + EAP</xref>, with the following differences:<list> + <t>The Application Id in the header is set to Diameter ERP (code TBD + <cref>TBD IANA</cref>).</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><cref>FFS: What about Session-ID AVP -- in case of re-auth at the + same place, and in case of handover?</cref></t> + + <t>The Auth-Request-Type AVP content is set to [Editor's note: + FFS]<cref>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...</cref>.</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>.</t> + + <t>The ER server receives and processes this request as described in + <xref target="Overview"></xref>. It then creates a Diameter answer + ERP/DEA, following the general processing described in <xref + target="RFC4072"></xref>, with the following differences:<list> + <t>The Application Id in the header is set to Diameter ERP (code + TBD<cref>TBD IANA</cref>).</t> + + <t>The value in Auth-Application-Id AVP is also set to Diameter ERP + Application.</t> + + <t>The Result-Code AVP is set to <cref>version -00 stated a SHOULD + here, not sure why ?</cref> an error value in case ERP + authentication fails, or to DIAMETER_SUCCESS if ERP is + successful.</t> + + <t>The EAP-Payload AVP contains the ERP message, + EAP-Finish/Re-auth.</t> + + <t>In case of successful authentication, the EAP-Master-Session-Key + AVP contains the Re-authentication Master Session Key (rMSK) derived + by ERP.</t> + + <t><cref>What about all the authorization attributes? If we want to + include them, they have to be present on the ER server...</cref></t> + </list></t> + + <t>When the authenticator receives this ERP/DEA answer, it processes it + as described in <xref target="RFC4072">Diameter EAP</xref> and <xref + target="RFC5296"></xref>: the content of EAP-Payload AVP content is + forwarded to the peer, and the content of EAP-Master-Session-Key AVP 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<cref>TBD IANA</cref>. + 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, + as described in <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 + section <xref target="AVPs"></xref> , although these AVP have the 'M' + flag cleared.</t> + </section> + + <section anchor="AVPs" title="AVPs"> + <t>This specification defines the following new AVPs. <cref>FFS: to + align with draft-wu-dime-local-keytran-02 if it becomes a WG + item</cref></t> + + <section title="ERP-RK-Request AVP"> + <t>The ERP-RK-Request AVP (AVP Code TBD<cref>TBD IANA</cref>) 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.</t> + + <t>This AVP has the M and V bits cleared.</t> + + <figure title="Figure. 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 TBD<cref>TBD IANA</cref>) is of type + DiameterIdentity. 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 if the ER server is not in a third-party + realm, if this is possible.</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 TBD<cref>TBD IANA</cref>) is of + type grouped AVP. It is used by the home EAP server to provide ERP + root key material to the ER server.</t> + + <t>This AVP has the M and V bits cleared.</t> + + <figure title="Figure. 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 TBD<cref>TBD IANA</cref>) is of type + OctetString. It contains the root key (either rRK or rDSRK) sent by + the home EAP server to the ER server, in answer to request containing + an ERP-RK-Request AVP. 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 instead? Must check + the exact definition...</cref></t> + + <t>This AVP has the M and V bits cleared.</t> + </section> + + <section title="ERP-RK-Name AVP"> + <t>The ERP-RK-Name AVP (AVP Code TBD<cref>TBD IANA</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 instead ?</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 TBD<cref>TBD IANA</cref>) is of + type Unsigned32 <cref>do we really need 64 as in -00 ? 2^32 secs is + already more than 100 years, which is too long for a key lifetime + !</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>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 advertizes support for the Diameter ERP application + MUST support the new AVPs defined in this specification.</t> + + <figure title="Figure. 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="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.</t> + + <t>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.</t> + + <t>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.</t> + + <t>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.</t> + + <t>Vidya Narayanan reviewed a rough draft version of the document and + found some errors.</t> + + <t>Lakshminath Dondeti contributed to the early versions of the + document.</t> + + <t>Many thanks to these people!</t> + </section> + + <section anchor="IANA" title="IANA Considerations"> + <t>This document requires IANA registration of the following new + elements in the <eref + target="http://www.iana.org/assignments/aaa-parameters/">Authentication, + Authorization, and Accounting (AAA) Parameters</eref> registries.</t> + + <section title="Diameter ERP application"> + <t>This specification requires IANA to allocate a new value "Diameter + ERP" in the "Application IDs" registry created by in <xref + target="RFC3588"></xref>.</t> + + <figure title="IANA consideration for Diameter ERP application"> + <artwork><![CDATA[ + Application Identifier | Value + -----------------------------------+------ + Diameter ERP | TBD +]]></artwork> + </figure> + </section> + + <section title="New AVPs"> + <t>This specification requires IANA to allocate new values from the + "AVP Codes" registry defined in <xref target="RFC3588"></xref> for the + following AVPs:<list> + <t>ERP-RK-Request</t> + + <t>ERP-Realm</t> + + <t>ERP-RK-Answer</t> + + <t>ERP-RK</t> + + <t>ERP-RK-Name</t> + + <t>ERP-RK-Lifetime</t> + </list>These AVPs are defined in section <xref + target="AVPs"></xref>.</t> + </section> + </section> + + <section anchor="Security" title="Security Considerations"> + <t>The security considerations from the following RFC apply here: <xref + target="RFC3588"></xref>, <xref target="RFC4072"></xref>, <xref + target="RFC5247"></xref>, <xref target="RFC5295"></xref>, and <xref + target="RFC5296"></xref>.</t> + + <t><cref>FFS: Do we really respect these security considerations with + the mechanism we describe here? Is it safe to use ERP-RK-Request / + Answer AVPs? What is the worst case?</cref></t> + + <t>EAP channel bindings may be necessary to ensure that the Diameter + client and the server are in sync regarding the key Requesting Entity's + Identity. Specifically, the Requesting Entity advertises its identity + through the EAP lower layer, and the user or the EAP peer communicates + that identity to the EAP server (and the EAP server communicates that + identity to the Diameter server) via the EAP method for user/peer to + server verification of the Requesting Entity's Identity.<cref>Editor: I + really don't understand this paragraph ^^'...</cref></t> + </section> + </middle> + + <back> + <references title="Normative References"> + &RFC2119; + + &RFC3588; + + &RFC4072; + + &RFC5295; + + &RFC5296; + + &RFC3748; + </references> + + <references title="Informative References"> + &RFC4187; + + &RFC5247; + + &I-D.ietf-hokey-key-mgm; + + &I-D.wu-dime-local-keytran; + + &I-D.ietf-dime-app-design-guide; + </references> + </back> +</rfc>