Mercurial > hg > ietf
changeset 25:1c96f5301544 -00
Some cleanups
| author | Sebastien Decugis <sdecugis@nict.go.jp> |
|---|---|
| date | Fri, 05 Jun 2009 15:23:03 +0900 |
| parents | e17057ceb2db |
| children | d98e09956d90 |
| files | draft-sdecugis-dime-diameter-erp.xml |
| diffstat | 1 files changed, 144 insertions(+), 110 deletions(-) [+] |
line wrap: on
line diff
--- a/draft-sdecugis-dime-diameter-erp.xml Fri Jun 05 14:38:08 2009 +0900 +++ b/draft-sdecugis-dime-diameter-erp.xml Fri Jun 05 15:23:03 2009 +0900 @@ -26,7 +26,7 @@ <?rfc rfcedstyle="yes"?> <?rfc rfcprocack="no"?> <?rfc tocindent="yes"?> -<rfc category="std" docName="draft-sdecugis-dime-diameter-erp" +<rfc category="std" docName="draft-sdecugis-dime-diameter-erp-00" ipr="trust200902"> <front> <title abbrev="Diameter ERP support">Diameter support for EAP @@ -163,8 +163,9 @@ authenticator, the ER server involved in the transaction may change, for example in the case of inter-domain roaming.</t> - <figure title="Diameter applications used in the ERP mechanism."> - <artwork><![CDATA[ Diameter +--------+ + <figure title="Figure 1. Diameter applications used in the ERP mechanism."> + <artwork><![CDATA[ + Diameter +--------+ +-------------+ ERP +-----------+ (*) | Home | Peer <->|Authenticator|<=======>| ER server | <---> | EAP | +-------------+ +-----------+ | server | @@ -176,8 +177,8 @@ <t>The ER server may be located in the home domain (same as EAP server) or the visited domain (same as authenticator, when it differs from the - home domain). <cref>TBD: Can the ER server be located in a third domain - (ex: broker's)?</cref></t> + home domain). <cref anchor="Editor1">Can the ER server be located in a + third domain (ex: broker's)?</cref></t> <t>The bootstrapping of the ER server has to occur sometime between the initial EAP authentication and the first ERP re-authentication with this @@ -189,8 +190,9 @@ for a detailed description, and following sections for details on the Diameter messages format.</t> - <figure title="Diameter ERP exchange. "> - <artwork><![CDATA[ ER server + <figure title="Figure 2. Diameter ERP exchange. "> + <artwork><![CDATA[ + ER server (bootstrapped) Peer Authenticator (local or home domain) ==== ============= ====================== @@ -216,11 +218,12 @@ <section anchor="ApplicationId" title="Application Id"> <t>We define a Diameter ERP Application in this document, with an - Application Id value of <cref>TBD</cref>. Diameter nodes conforming to - this specification (in the role of ER server or authenticator) MUST - advertise support by including the Diameter ERP Application ID value in - the Auth-Application-Id AVP of the Capabilities-Exchange-Request and - Capabilities-Exchange-Answer command <xref target="RFC3588"></xref>.</t> + Application Id value of <cref anchor="IANA1">TBD</cref>. Diameter nodes + conforming to this specification (in the role of ER server or + authenticator) MUST advertise support by including the Diameter ERP + Application ID value in the Auth-Application-Id AVP of the + Capabilities-Exchange-Request and Capabilities-Exchange-Answer command + <xref target="RFC3588"></xref>.</t> <t>The primary use of the Diameter ERP Application Id is to ensure proper routing of the messages, and that the nodes that advertise the @@ -232,14 +235,15 @@ <t>This specification defines the following new AVPs.</t> <section title="ERP-RK-Request AVP"> - <t>The ERP-RK-Request AVP (AVP Code <cref>TBD</cref>) is of type - grouped AVP. It is used by the ER server to request root key material - used in ERP.</t> + <t>The ERP-RK-Request AVP (AVP Code <cref anchor="IANA2">TBD</cref>) + is of type grouped AVP. It is used by the ER server to request root + key material used in ERP.</t> <t>This AVP has the M and V bits cleared.</t> - <figure title="ERP-RK-Request ABNF"> - <artwork><![CDATA[ ERP-RK-Request ::= < AVP Header: TBD > + <figure title="Figure 3. ERP-RK-Request ABNF"> + <artwork><![CDATA[ + ERP-RK-Request ::= < AVP Header: TBD > { ERP-Realm } * [ AVP ] ]]></artwork> @@ -247,25 +251,27 @@ </section> <section title="ERP-Realm AVP"> - <t>The ERP-Realm AVP (AVP Code <cref>TBD</cref>) is of type - <cref>{DiameterIdentity? OctetString?}</cref>. It contains the name of - the realm in which the ER server is located.</t> + <t>The ERP-Realm AVP (AVP Code <cref anchor="IANA3">TBD</cref>) is of + type <cref anchor="Editor2">DiameterIdentity? OctetString?</cref>. It + contains the name of the realm in which the ER server is located.</t> - <t><cref>FFS: We may re-use Origin-Realm here instead? On the other - hand, ERP-Realm may be useful in CER/CEA with a NAS...</cref></t> + <t><cref anchor="Editor3">FFS: We may re-use Origin-Realm here + instead? On the other hand, ERP-Realm may be useful in CER/CEA with a + NAS...</cref></t> <t>This AVP has the M and V bits cleared.</t> </section> <section title="ERP-RK-Answer AVP"> - <t>The ERP-RK-Answer AVP (AVP Code <cref>TBD</cref>) is of type - grouped AVP. It is used by the home EAP server to provide ERP root key - material to the ER server.</t> + <t>The ERP-RK-Answer AVP (AVP Code <cref anchor="IANA4">TBD</cref>) is + of type grouped AVP. It is used by the home EAP server to provide ERP + root key material to the ER server.</t> <t>This AVP has the M and V bits cleared.</t> - <figure title="ERP-RK-Answer ABNF"> - <artwork><![CDATA[ ERP-RK-Answer ::= < AVP Header: TBD > + <figure title="Figure 4. ERP-RK-Answer ABNF"> + <artwork><![CDATA[ + ERP-RK-Answer ::= < AVP Header: TBD > { ERP-RK } { ERP-RK-Name } { ERP-RK-Lifetime } @@ -275,34 +281,37 @@ </section> <section title="ERP-RK AVP"> - <t>The ERP-RK AVP (AVP Code <cref>TBD</cref>) is of type OctetString. - It contains the root key (either rRK or rDSRK) to be used for ERP with - the peer to which the current session belongs. How this material is - derived and used is specified in <xref target="RFC5296"></xref>.</t> + <t>The ERP-RK AVP (AVP Code <cref anchor="IANA5">TBD</cref>) is of + type OctetString. It contains the root key (either rRK or rDSRK) to be + used for ERP with the peer to which the current session belongs. How + this material is derived and used is specified in <xref + target="RFC5296"></xref>.</t> - <t><cref>Can we re-use EAP-Master-Session-Key here?</cref></t> + <t><cref anchor="Editor4">Can we re-use EAP-Master-Session-Key + here?</cref></t> <t>This AVP has the M and V bits cleared.</t> </section> <section title="ERP-RK-Name AVP"> - <t>The ERP-RK AVP (AVP Code <cref>TBD</cref>) is of type OctetString. - This AVP contains the EMSKname which identifies the keying material. - How this name is derived is beyond the scope of this document and - defined in <xref target="RFC5296"></xref>.</t> + <t>The ERP-RK AVP (AVP Code <cref anchor="IANA6">TBD</cref>) is of + type OctetString. This AVP contains the EMSKname which identifies the + keying material. How this name is derived is beyond the scope of this + document and defined in <xref target="RFC5296"></xref>.</t> - <t><cref>Can we re-use EAP-Key-Name here?</cref></t> + <t><cref anchor="Editor5">Can we re-use EAP-Key-Name here?</cref></t> <t>This AVP has the M and V bits cleared.</t> </section> <section title="ERP-RK-Lifetime AVP"> - <t>The ERP-RK-Lifetime AVP (AVP Code <cref>TBD</cref>) is of type - <cref>Unsigned64? 32?</cref> and contains the root key material - remaining lifetime in seconds. It MUST not be greater than the - remaining lifetime of the EMSK it is derived from. <cref>FFS: is it - better to pass an absolute value here, for example expiration date? - How to express it then (TZ, ...)? Synchronization problems?</cref></t> + <t>The ERP-RK-Lifetime AVP (AVP Code <cref anchor="IANA7">TBD</cref>) + is of type <cref anchor="Editor6">Unsigned64? 32?</cref> and contains + the root key material remaining lifetime in seconds. It MUST not be + greater than the remaining lifetime of the EMSK it is derived from. + <cref anchor="Editor7">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> @@ -313,21 +322,23 @@ Diameter-EAP-Request and Diameter-EAP-Answer commands defined in <xref target="RFC4072"></xref>.</t> - <t>The Application Id field in the command header <cref>and the value in - Auth-Application-Id AVP which is redundant???</cref> can be set to - Diameter EAP application or Diameter ERP application, depending on the - situation, as explained in the next sections.</t> + <t>The Application Id field in the command header <cref + anchor="Editor8">and the value in Auth-Application-Id AVP which is + redundant???</cref> can be set to Diameter EAP application or Diameter + ERP application, depending on the situation, as explained in the next + sections.</t> <t>Since the original ABNF of these commands allow other optional AVPs ("* [ AVP ]"), and the new AVPs defined in this specification do not have the 'M' flag set, the ABNF does not need any change. Anyway, a Diameter node that advertize support for the Diameter ERP application - MUST support the ERP-RK-Request and ERP-RK-Answer AVP <cref>Therefore, - in DER/DEA with Diameter ERP application ID, do we set the 'M' flag to - these AVPs?</cref>.</t> + MUST support the ERP-RK-Request and ERP-RK-Answer AVP <cref + anchor="Editor9">Therefore, in DER/DEA with Diameter ERP application ID, + do we set the 'M' flag to these AVPs?</cref>.</t> - <figure title="Command Codes"> - <artwork><![CDATA[ Command-Name Abbrev. Code Reference Application + <figure title="Figure 5. 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 @@ -388,8 +399,9 @@ and last round of exchanges of the full EAP authentication, as captured in the figure bellow.</t> - <figure title="ERP bootstrapping during full EAP authentication"> - <artwork><![CDATA[ ER server & + <figure title="Figure 6. ERP bootstrapping during full EAP authentication"> + <artwork><![CDATA[ + ER server & Authenticator EAP Proxy Home EAP server ============= =========== =============== -------------------------> @@ -429,9 +441,9 @@ compute the rRK or rDSRK (depending on the value of ERP-Realm) as specified in <xref target="RFC5296"></xref>, and add an ERP-RK-Answer AVP in the Diameter-EAP-Request message, in addition to the MSK and - EAP-Success payload. <cref>FFS: is it important to check that the - server that added the ERP-RK-Request is in the path of the answer? - What's the worst that can happen?</cref></t> + EAP-Success payload. <cref anchor="Editor10">FFS: is it important to + check that the server that added the ERP-RK-Request is in the path of + the answer? What's the worst that can happen?</cref></t> <t>When the ER server proxies a Diameter-EAP-Answer message with a Session-Id corresponding to a message to which it added an @@ -440,17 +452,17 @@ content. If the message does not contain an ERP-RK-Answer AVP, the ER server MAY save this information to avoid possible attempts later for this session. In any case, the information stored SHOULD NOT have a - lifetime greater than the EMSK lifetime <cref>FFS: how does the ER - server knows the EMSK lifetime, if there is no ERP-RK-Answer? What is - the lifetime of the MSK for example?</cref></t> + lifetime greater than the EMSK lifetime <cref anchor="Editor11">FFS: + how does the ER server knows the EMSK lifetime, if there is no + ERP-RK-Answer? What is the lifetime of the MSK for example?</cref></t> <t>If the ER server is successfully bootstrapped, it MAY also add the ERP-Realm AVP after removing the ERP-RK-Answer AVP in the Diameter-EAP-Answer message. This could be used by the authenticator to notify the peer that ERP is bootstrapped, with the ER domain information. How this information can be transmitted to the peer is - outside the scope of this document. <cref>Is it possible? It would be - useful...</cref></t> + outside the scope of this document. <cref anchor="Editor12">Is it + possible? It would be useful...</cref></t> </section> <section title="Bootstrapping during first re-authentication"> @@ -483,10 +495,10 @@ or after a first succesful re-authentication in the visited domain, the message is routed to the local ER server following normal Diameter routing. If the ER server does not have key information corresponding - to this EMSKname, <cref>return an error to the peer? proxy the request - and send ERP-RK-Request to the home EAP server? How do we learn which - is the home domain?</cref>. See the next section <xref - target="Re-authentication"></xref> for detail.</t> + to this EMSKname, <cref anchor="Editor13">return an error to the peer? + proxy the request and send ERP-RK-Request to the home EAP server? How + do we learn which is the home domain?</cref>. See the next section + <xref target="Re-authentication"></xref> for detail.</t> <t>In the case of explicit bootstrapping (the ERP message has its 'B' flag set), if an ER server exists in the visited domain, it SHOULD be @@ -496,15 +508,16 @@ the ER server in the visited domain is also valid for the ER server in the home domain.</t> - <t><cref>What should we do if the ER server receives an explicit - bootstrapping request but already possess the rDSRK?</cref></t> + <t><cref anchor="Editor14">What should we do if the ER server receives + an explicit bootstrapping request but already possess the + rDSRK?</cref></t> <t>The ER server proxies the request (DER with Diameter ERP application code) as follow, in addition to standard proxy operations:<list> <t>Change the Application Id in the header of the message to - Diameter EAP Application (code 5). <cref>What about the - Application-Auth-Id AVP?</cref></t> + Diameter EAP Application (code 5). <cref anchor="Editor15">What + about the Application-Auth-Id AVP?</cref></t> <t>Add the ERP-RK-Request AVP, which contains the name of the domain the ER server is located in (with regards to ERP).</t> @@ -522,8 +535,8 @@ <t>The ER server receives this DEA and proxies it as follow, in addition to standard proxy operations:<list> - <t>Set the Application Id back to Diameter ERP (code - <cref>TBD</cref>)</t> + <t>Set the Application Id back to Diameter ERP (code <cref + anchor="IANA8">TBD</cref>)</t> <t>Extract and cache the content of the ERP-RK-Answer.</t> </list>The DEA is then forwarded to the authenticator, that can use @@ -531,8 +544,9 @@ <t>The figure below captures this Diameter ERP Proxy behavior:</t> - <figure title="ERP explicit bootstrapping message flow"> - <artwork><![CDATA[Authenticator ER server Home EAP server + <figure title="Figure 7. ERP explicit bootstrapping message flow"> + <artwork><![CDATA[ +Authenticator ER server Home EAP server ============= ========= =============== -----------------------> Diameter ERP/DER @@ -568,15 +582,16 @@ <t>The following figure describes the re-authentication exchange. Explication follow.</t> - <figure title="Diameter ERP exchange"> - <artwork><![CDATA[ Bootstrapped ER server - Peer Authenticator (in local or home domain) - ==== ============= ========================= - [ <------------------------ ] - [optional EAP-Initiate/Re-auth-start] + <figure title="Figure 8. Diameter ERP exchange"> + <artwork><![CDATA[ + Bootstrapped ER server +Peer Authenticator (in local or home domain) +==== ============= ========================= +[ <------------------------ ] +[optional EAP-Initiate/Re-auth-start] -----------------------> - EAP-Initiate/Re-auth + EAP-Initiate/Re-auth =================================> Diameter ERP, cmd code DER User-Name: Keyname-NAI @@ -586,9 +601,8 @@ Diameter ERP, cmd code DEA EAP-Payload: EAP-Finish/Re-auth EAP-Master-Session-Key: rMSK - <---------------------- - EAP-Finish/Re-auth - + <---------------------- + EAP-Finish/Re-auth ]]></artwork> </figure> @@ -609,7 +623,8 @@ <t>The User-Name and Destination-Realm are derived from the Keyname-NAI.</t> - <t><cref>How do we create / retrieve the Session-Id?</cref></t> + <t><cref anchor="Editor16">How do we create / retrieve the + Session-Id?</cref></t> </list></t> <t>The ER server receives this request and process the ERP payload as @@ -637,46 +652,65 @@ <t>This section describes how sessions are handled in case of re-authentication.</t> - <t><cref>See guidelines in I-D.ietf-dime-app-design-guide</cref></t> + <t><cref anchor="Editor17">See guidelines in + I-D.ietf-dime-app-design-guide</cref></t> - <t><cref>During initial full EAP authentication, the identity of the - peer is used to create the Session-Id AVP, which is then used during - accounting. When the peer attaches to a new authenticator and performs - ERP, its identity is not disclosed to the authenticator. Instead, the - peer presents the Keyname-NAI. This identifiers contains the EMSKName as - user part. </cref></t> + <t><cref 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><cref>The new authenticator will therefore derive the new Session-Id - from this EMSKName and use this for accounting purpose. </cref></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><cref>Although the home EAP server is able to link EMSKName with the - peer's identity, the other Diameter entities do not have this mapping. - In particular, the realm part of Keyname-NAI is the visited network. How - does the authenticator figures out that the account records must be sent - to the home domain of the peer? </cref></t> + <t><cref 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><cref>It is possible to cache the necessary information at the ER - server level. Is it useful to specify this mechanism in this - document?</cref> </t> + <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> </section> <section anchor="Acknowledgements" title="Acknowledgements"> - <t><cref>Remember, it's important to acknowledge people who have - contributed to the work</cref></t> + <t><cref anchor="Editor22">Remember, it's important to acknowledge + people who have contributed to the work</cref></t> </section> <section anchor="IANA" title="IANA Considerations"> - <t><cref>Request a new Application Id for Diameter ERP.</cref></t> + <t><cref anchor="IANA9">Request a new Application Id for Diameter + ERP.</cref></t> + + <t><xref target="IANA1">Application Id</xref></t> + + <t><xref target="IANA8">Reference</xref></t> + + <t><cref anchor="IANA10">Request new AVP Codes for ERP-* AVPs</cref></t> - <t><cref>Request new AVP Codes for ERP-* AVPs</cref></t> + <t><xref target="IANA2">AVP</xref></t> + + <t><xref target="IANA3">AVP</xref></t> + + <t><xref target="IANA4">AVP</xref></t> + + <t><xref target="IANA5">AVP</xref></t> + + <t><xref target="IANA6">AVP</xref></t> + + <t><xref target="IANA7">AVP</xref></t> </section> <section anchor="Security" title="Security Considerations"> - <t><cref>Security considerations from RFC3588 (+bis), RFC4072, RFC5247, - RFC5295, and RFC5296 apply</cref></t> + <t><cref anchor="Editor23">Security considerations from RFC3588 (+bis), + RFC4072, RFC5247, RFC5295, and RFC5296 apply</cref></t> - <t><cref>Is it safe to use ERP-RK-Request / Answer AVPs? What is the - worst case?</cref></t> + <t><cref anchor="Editor24">Is it safe to use ERP-RK-Request / Answer + AVPs? What is the worst case?</cref></t> </section> </middle>