# HG changeset patch # User Sebastien Decugis # Date 1247800212 -32400 # Node ID e067e505c18d97ee2930d890426f88a72fdeb3ef # Parent 348f1e9e5f7358055502f770da45d896d2e4fedd Update to version -01 diff -r 348f1e9e5f73 -r e067e505c18d draft-sdecugis-dime-diameter-erp.xml --- a/draft-sdecugis-dime-diameter-erp.xml Fri Jul 17 11:44:42 2009 +0900 +++ b/draft-sdecugis-dime-diameter-erp.xml Fri Jul 17 12:10:12 2009 +0900 @@ -4,11 +4,15 @@ + + - - - + + + + + ]> @@ -26,7 +30,7 @@ - Diameter support for EAP @@ -75,36 +79,6 @@ transport of ERP using RADIUS. This document specifies the transport of ERP using Diameter.</t> </abstract> - - <note title="Foreword"> - <t>This document differs from <eref - target="http://tools.ietf.org/html/draft-ietf-dime-erp-00">draft-ietf-dime-erp-00</eref> - in its design and scope.</t> - - <t>In this new version, we use a new Diameter application id for - messages with ERP payload exchanged between authenticator and ER server. - This simplifies the routing of Diameter messages to the appropriate - server, and allows more flexibility in the deployment of ERP.</t> - - <t>The scope of previous documents (<eref - target="http://tools.ietf.org/html/draft-ietf-dime-erp-00">draft-ietf-dime-erp-00</eref> - and <eref - target="http://tools.ietf.org/html/draft-wu-dime-local-keytran-00">draft-wu-dime-local-keytran-00</eref>) - was focused on the implicit bootstrapping scenario described in <xref - target="RFC5296"></xref>. By re-using the Diameter EAP application, - these documents create implicit constraints on routing of messages that - cannot be met by standard Diameter routing algorithm defined in the - <xref target="RFC3588">Diameter Base Protocol</xref>. A separate - Diameter Id may also allow the authenticator to dynamically discover if - the local domain supports ERP or not.</t> - </note> - - <note title="Requirements Language"> - <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> - </note> </front> <middle> @@ -130,38 +104,71 @@ <t>We also discuss the key distribution (first step, bootstrapping) and propose some solutions for different architectures. Anyway, implementors are free to choose a different mechanism for key distribution, as for - example using RADIUS<xref target="I-D.ietf-hokey-key-mgm"></xref>. + example using RADIUS <xref target="I-D.ietf-hokey-key-mgm"></xref>. Security considerations for key distribution are explained in <xref target="RFC5295"></xref>.</t> + + <section title="Differences with other documents"> + <t>This document differs from <xref target="I-D.ietf-dime-erp"></xref> + in its design and scope. In this new version, we use a new Diameter + application id for messages with ERP payload exchanged between + authenticator and ER server. This simplifies the routing of Diameter + messages to the appropriate server, and allows more flexibility in the + deployment of ERP.</t> + + <t>The scope of previous documents (<xref + target="I-D.ietf-dime-erp"></xref> and <xref + target="I-D.wu-dime-local-keytran"></xref>) was focused on the + bootstrapping of the mechanism. In particular, these documents did not + consider the routing of Diameter message for re-authentication + exchanges (ERP exchange, and also <xref target="RFC4187"></xref> for + the second document). By re-using the Diameter EAP application, they + create implicit constraints on routing of messages that cannot be met + by standard Diameter routing algorithm, as defined in the <xref + target="RFC3588">Diameter Base Protocol</xref>.</t> + + <t>A separate Diameter application solves this routing issue, and can + also allow the authenticator to dynamically discover if the local + domain supports re-authentication or not.</t> + </section> </section> <section title="Terminology"> - <t>We re-use here the terminology from <xref target="RFC5296"></xref>. - In particular, the EAP server implicitely supports ERP extensions to - generate the ERP keying material and send it to the ER server. These - terms "authenticator", "ER server", "EAP server" denote logical - functional entities and make no assumption on the real implementation - and deployment.</t> + <t>We re-use in this document the terminology from <xref + target="RFC5296"></xref>. In particular, unless specified otherwise, the + EAP server has implicit support for ERP extensions for generation of ERP + keying material and its transmission to ER server. These terms + "authenticator", "ER server", "EAP server" designate logical functional + entities and make no assumption on the real implementation and + deployment.</t> - <t>"root key" or "bootstrapping material" refer to the rRK (home ER - server) or rDSRK (foreign ER server) derived from an EMSK, depending on - the context.</t> + <t>"Root key" (RK) or "bootstrapping material" refer to the rRK or rDSRK + derived from an EMSK, depending on the location of the ER server in home + or foreign domain.</t> <t>We re-use also some terminology and abbreviations from <xref target="RFC4072"></xref>, for example DER/DEA.</t> + + <section title="Requirements Language"> + <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in <xref + target="RFC2119"></xref>.</t> + </section> </section> <section anchor="Overview" title="Overview"> <t>During the lifetime of an EMSK (derived during a full EAP - authentication), a peer may attach to several authenticators. In this - case, re-authentication is more efficient than full authentication, - especially in the case of roaming. ERP provides a mechanism for - re-authentication independent of the link layer, as opposed to IEEE - 802.11r-2008 for example, so it can be used in case of multihoming or - horizontal handovers. The following figure shows the components involved - in ERP, and their interactions. When the peer attaches to a new - authenticator, the ER server involved in the transaction may change, for - example in the case of inter-domain roaming.</t> + authentication by compatible EAP methods), a peer may attach to several + authenticators. In this case, re-authentication is more efficient than + full authentication, especially in the case of roaming. ERP provides a + mechanism for re-authentication independent of the link layer, so it can + be used in case of multihoming or handovers between different access + technologies. The following figure shows the components involved in ERP, + and their interactions. When the peer attaches to a new authenticator, + the ER server involved in the transaction may change, for example in the + case of inter-domain roaming. The home EAP server is assumed to be + constant for a given peer.</t> <figure title="Figure 1. Diameter applications used in the ERP mechanism."> <artwork><![CDATA[ @@ -579,8 +586,7 @@ peer to learn the domain of the ER server attached to the authenticator.</t> - <t>The following figure describes the re-authentication exchange. - Explication follow.</t> + <t>The following figure describes the re-authentication exchange.</t> <figure title="Figure 8. Diameter ERP exchange"> <artwork><![CDATA[ @@ -652,65 +658,107 @@ <t>This section describes how sessions are handled in case of re-authentication.</t> - <t><cref anchor="Editor17">See guidelines in - I-D.ietf-dime-app-design-guide</cref></t> + <t><cref anchor="Editor17">The content of this section is to be written, + I am just listing the ideas here.</cref></t> + + <t>See guidelines in <xref + target="I-D.ietf-dime-app-design-guide"></xref>.</t> - <t><cref anchor="Editor18">During initial full EAP authentication, the - identity of the peer is used to create the Session-Id AVP, which is then - used during accounting. When the peer attaches to a new authenticator - and performs ERP, its identity is not disclosed to the authenticator. - Instead, the peer presents the Keyname-NAI. This identifiers contains - the EMSKName as user part.</cref></t> + <t>During initial full EAP authentication, the identity of the peer is + used to create the Session-Id AVP, which is then used during accounting. + When the peer attaches to a new authenticator and performs ERP, its + identity is not disclosed to the authenticator. Instead, the peer + presents the Keyname-NAI. This identifiers contains the EMSKName as user + part. The new authenticator will therefore derive the new Session-Id + from this EMSKName and use this for accounting purpose.</t> - <t><cref anchor="Editor19">The new authenticator will therefore derive - the new Session-Id from this EMSKName and use this for accounting - purpose. </cref></t> + <t>Although the home EAP server is able to link EMSKName with the peer's + identity, the other Diameter entities do not have this mapping. In + particular, the realm part of Keyname-NAI is the visited network. How + does the authenticator figures out that the account records must be sent + to the home domain of the peer?</t> - <t><cref anchor="Editor20">Although the home EAP server is able to link - EMSKName with the peer's identity, the other Diameter entities do not - have this mapping. In particular, the realm part of Keyname-NAI is the - visited network. How does the authenticator figures out that the account - records must be sent to the home domain of the peer? </cref></t> + <t>It is possible to cache the necessary information at the ER server + level. Is it useful to specify this mechanism in this document? It would + involve:<list> + <t>An additional AVP during bootstrapping of ER server, in the + ERP-RK-Answer, to pass the real User-Name and Session-Id (only in + case of explicit bootstrapping)</t> - <t><cref anchor="Editor21">It is possible to cache the necessary - information at the ER server level. Is it useful to specify this - mechanism in this document?</cref></t> + <t>An additional AVP in Diameter ERP/DEA (EAP-Finish/Re-Auth) to + pass the real Session-Id and User-Name and Destination-Realm of the + re-authenticated peer, for accounting messages.</t> + </list></t> + </section> + + <section title="Contributors"> + <t>Hannes Tschofenig, Lakshminath Dondeti, Julien Bournelle, and Lionel + Morand wrote the initial Diameter ERP draft document.</t> </section> <section anchor="Acknowledgements" title="Acknowledgements"> - <t><cref anchor="Editor22">Remember, it's important to acknowledge - people who have contributed to the work</cref></t> + <t>Vidya Narayanan reviewed a rough draft version of the previous + document and found some errors.</t> + + <t>Qin Wu and Glen Zorn actively participated in the discussions on the + design for Diameter ERP, providing the point of view and experience from + HOKEY workgroup.</t> + + <t>Hannes Tschofenig provided useful advices for the writing of this + document.</t> + + <t>Many thanks to these people!</t> </section> <section anchor="IANA" title="IANA Considerations"> - <t><cref anchor="IANA9">Request a new Application Id for Diameter - ERP.</cref></t> + <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> - <t><xref target="IANA1">Application Id</xref></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> - <t><xref target="IANA8">Reference</xref></t> - - <t><cref anchor="IANA10">Request new AVP Codes for ERP-* AVPs</cref></t> + <figure title="IANA consideration for Diameter ERP application"> + <artwork><![CDATA[ + Application Identifier | Value + -----------------------------------+------ + Diameter ERP | TBD +]]></artwork> + </figure> + </section> - <t><xref target="IANA2">AVP</xref></t> + <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><xref target="IANA3">AVP</xref></t> - - <t><xref target="IANA4">AVP</xref></t> + <t>ERP-Realm</t> - <t><xref target="IANA5">AVP</xref></t> + <t>ERP-RK-Answer</t> + + <t>ERP-RK</t> - <t><xref target="IANA6">AVP</xref></t> + <t>ERP-RK-Name</t> - <t><xref target="IANA7">AVP</xref></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><cref anchor="Editor23">Security considerations from RFC3588 (+bis), - RFC4072, RFC5247, RFC5295, and RFC5296 apply</cref></t> + <t>The security considerations from the following RFC apply here: <xref + target="RFC3588"></xref>, <xref target="RFC4072"></xref>, <xref + target="RFC5247"></xref>, <xref target="RFC5295"></xref>, and <xref + target="RFC5296"></xref>.</t> - <t><cref anchor="Editor24">Is it safe to use ERP-RK-Request / Answer - AVPs? What is the worst case?</cref></t> + <t><cref anchor="Editor18">FFS: Do we really respect these security + considerations with the mechanism we describe here? Is it safe to use + ERP-RK-Request / Answer AVPs? What is the worst case?</cref></t> </section> </middle> @@ -730,11 +778,19 @@ <references title="Informative References"> &RFC3748; - &I-D.draft-ietf-hokey-key-mgm; + &RFC4187; + + &RFC5247; + + &I-D.ietf-hokey-key-mgm; - &I-D.draft-gaonkar-radext-erp-attrs; + &I-D.gaonkar-radext-erp-attrs; + + &I-D.ietf-dime-erp; - &I-D.draft-ietf-dime-app-design-guide; + &I-D.wu-dime-local-keytran; + + &I-D.ietf-dime-app-design-guide; </references> </back> </rfc>