draft-ietf-dime-erp-11.txt | draft-ietf-dime-erp-12.txt | |||
---|---|---|---|---|
skipping to change at page 1, line 15 | skipping to change at page 1, line 15 | |||
Intended status: Standards Track Orange Labs | Intended status: Standards Track Orange Labs | |||
Expires: February 1, 2013 S. Decugis | Expires: February 1, 2013 S. Decugis | |||
INSIDE Secure | INSIDE Secure | |||
Q. Wu | Q. Wu | |||
Huawei | Huawei | |||
G. Zorn | G. Zorn | |||
Network Zen | Network Zen | |||
July 31, 2012 | July 31, 2012 | |||
Diameter Support for the EAP Re-authentication Protocol (ERP) | Diameter Support for the EAP Re-authentication Protocol (ERP) | |||
draft-ietf-dime-erp-11 .txt | draft-ietf-dime-erp-12.txt | |||
Abstract | Abstract | |||
The EAP Re-authentication Protocol (ERP) defines extensions to the | The EAP Re-authentication Protocol (ERP) defines extensions to the | |||
Extensible Authentication Protocol (EAP) to support efficient re- | Extensible Authentication Protocol (EAP) to support efficient re- | |||
authentication between the peer and an EAP Re-authentication (ER) | authentication between the peer and an EAP Re-authentication (ER) | |||
server through a compatible authenticator. This document specifies | server through a compatible authenticator. This document specifies | |||
Diameter support for ERP. It defines a new Diameter ERP application | Diameter support for ERP. It defines a new Diameter ERP application | |||
to transport ERP messages between an ER authenticator and the ER | to transport ERP messages between an ER authenticator and the ER | |||
server, and a set of new AVPs that can be used to transport the | server, and a set of new AVPs that can be used to transport the | |||
skipping to change at page 3, line 7 | skipping to change at page 3, line 7 | |||
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 | 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | |||
12.1. Diameter Application Identifier . . . . . . . . . . . . . 14 | 12.1. Diameter Application Identifier . . . . . . . . . . . . . 14 | |||
12.2. New AVPs . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 12.2. New AVPs . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
12.3. New Permanent Failures Result-Code AVP Values . . . . . . 14 | 12.3. New Permanent Failures Result-Code AVP Values . . . . . . 14 | |||
13. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | 13. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | |||
14. Normative References . . . . . . . . . . . . . . . . . . . . . 15 | 14. Normative References . . . . . . . . . . . . . . . . . . . . . 15 | |||
1. Introduction | 1. Introduction | |||
RFC5296 [RFC5296] defines the EAP Re-authentication Protocol (ERP). | RFC6696 [RFC6696] defines the EAP Re-authentication Protocol (ERP). | |||
It consists of the following steps: | It consists of the following steps: | |||
Bootstrapping | Bootstrapping | |||
A root key for re-authentication is derived from the Extended | A root key for re-authentication is derived from the Extended | |||
Master Session Key (EMSK) created during EAP authentication | Master Session Key (EMSK) created during EAP authentication | |||
[RFC5295]. This root key is transported from the EAP server to | [RFC5295]. This root key is transported from the EAP server to | |||
the ER server. | the ER server. | |||
Re-authentication | Re-authentication | |||
skipping to change at page 3, line 38 | skipping to change at page 3, line 38 | |||
This document also discusses the distribution of the root key during | This document also discusses the distribution of the root key during | |||
bootstrapping, in conjunction with either the initial EAP | bootstrapping, in conjunction with either the initial EAP | |||
authentication (implicit bootstrapping) or the first ERP exchange | authentication (implicit bootstrapping) or the first ERP exchange | |||
(explicit bootstrapping). Security considerations for this key | (explicit bootstrapping). Security considerations for this key | |||
distribution are detailed in RFC 5295 [RFC5295]. | distribution are detailed in RFC 5295 [RFC5295]. | |||
2. Terminology | 2. Terminology | |||
This document uses terminology defined in RFC3748 [RFC3748], RFC5295 | This document uses terminology defined in RFC3748 [RFC3748], RFC5295 | |||
[RFC5295], RFC5296 [RFC5296], and RFC4072 [RFC4072]. | [RFC5295], RFC6696 [RFC6696], and RFC4072 [RFC4072]. | |||
"Root key" (RK) or "bootstrapping material" refer to the rRK or rDSRK | "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 | derived from an EMSK, depending on the location of the ER server in | |||
home or foreign domain. | home or foreign domain. | |||
We use the notation "ERP/DER" and "ERP/DEA" in this document to refer | We use the notation "ERP/DER" and "ERP/DEA" in this document to refer | |||
to Diameter-EAP-Request and Diameter-EAP-Answer commands with the | to Diameter-EAP-Request and Diameter-EAP-Answer commands with the | |||
Application Id set to <Diameter ERP Application> Section 12.1; the | Application Id set to <Diameter ERP Application> Section 12.1; the | |||
same commands are denoted "EAP/DER" and "EAP/DEA" when the | same commands are denoted "EAP/DER" and "EAP/DEA" when the | |||
Application Id in the message is set to <Diameter EAP Application> | Application Id in the message is set to <Diameter EAP Application> | |||
skipping to change at page 5, line 12 | skipping to change at page 5, line 12 | |||
Section 12.1 in the message. The generation of the ERP/DER message | Section 12.1 in the message. The generation of the ERP/DER message | |||
is detailed in Section 6. | is detailed in Section 6. | |||
If there is an ER server in the same domain as the authenticator | If there is an ER server in the same domain as the authenticator | |||
(i.e., the local domain), Diameter routing MUST be configured so that | (i.e., the local domain), Diameter routing MUST be configured so that | |||
this ERP/DER message reaches that server, even if the Destination- | this ERP/DER message reaches that server, even if the Destination- | |||
Realm is not the same as local domain. | Realm is not the same as local domain. | |||
If there is no local ER server, the message is routed according to | If there is no local ER server, the message is routed according to | |||
its Destination-Realm AVP content, extracted from the realm component | its Destination-Realm AVP content, extracted from the realm component | |||
of the keyName-NAI attribute. As specified in RFC5296 [RFC5296], | of the keyName-NAI attribute. As specified in RFC6696 [RFC6696], | |||
this realm is the home domain of the peer in the case of | this realm is the home domain of the peer in the case of | |||
bootstrapping exchange ('B' flag is set in ERP message) or the domain | bootstrapping exchange ('B' flag is set in ERP message) or the domain | |||
of the bootstrapped ER server otherwise . | of the bootstrapped ER server otherwise . | |||
If no ER server is available in the home domain either, the ERP/DER | 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 | message cannot be delivered, and an error DIAMETER_UNABLE_TO_DELIVER | |||
MUST be generated as specified in [I-D.ietf-dime-rfc3588bis] and | MUST be generated as specified in [I-D.ietf-dime-rfc3588bis] and | |||
returned to the authenticator. The authenticator MAY cache this | returned to the authenticator. The authenticator MAY cache this | |||
information (with limited duration) to avoid further attempts to | information (with limited duration) to avoid further attempts to | |||
execute ERP with this realm. It MAY also fallback to full EAP | execute ERP with this realm. It MAY also fallback to full EAP | |||
authentication to authenticate the peer. | authentication to authenticate the peer. | |||
When an ER server receives the ERP/DER message, it searches its local | When an ER server receives the ERP/DER message, it searches its local | |||
database for a valid, unexpired root key matching the keyName part of | database for a valid, unexpired root key matching the keyName part of | |||
the User-Name AVP. If such key is found, the ER server processes the | the User-Name AVP. If such key is found, the ER server processes the | |||
ERP message as described in [RFC5296] then creates the ERP/DEA answer | ERP message as described in [RFC6696] then creates the ERP/DEA answer | |||
as described in Section 6. The rMSK is included in this answer. | as described in Section 6. The rMSK is included in this answer. | |||
Finally, the authenticator extracts the rMSK from the ERP/DEA as | Finally, the authenticator extracts the rMSK from the ERP/DEA as | |||
described in RFC5296 [RFC5296], and forwards the content of the EAP- | described in RFC6696 [RFC6696], and forwards the content of the EAP- | |||
Payload AVP, the EAP-Finish/Re-Auth message, to the peer. | Payload AVP, the EAP-Finish/Re-Auth message, to the peer. | |||
The ER server may or may not possess the root key in its local | The ER server may or may not possess the root key in its local | |||
database. If the EAP-Initiate/Re-Auth message has its 'B' flag set | database. If the EAP-Initiate/Re-Auth message has its 'B' flag set | |||
(Bootstrapping exchange) and the ER server possesses the root key, | (Bootstrapping exchange) and the ER server possesses the root key, | |||
the ER server SHOULD respond directly to the peer that initiated the | the ER server SHOULD respond directly to the peer that initiated the | |||
ERP exchange. Otherwise, the ER server SHOULD act as a proxy and | ERP exchange. Otherwise, the ER server SHOULD act as a proxy and | |||
forward the message to the home EAP server after changing its | forward the message to the home EAP server after changing its | |||
Application Id to Diameter EAP and adding the ERP-RK-Request AVP to | Application Id to Diameter EAP and adding the ERP-RK-Request AVP to | |||
request the root key. See Section 5 for more detail on this process. | request the root key. See Section 5 for more detail on this process. | |||
skipping to change at page 7, line 21 | skipping to change at page 7, line 21 | |||
the first DER of the full EAP authentication and adds the ERP-RK- | the first DER of the full EAP authentication and adds the ERP-RK- | |||
Request AVP inside, then forwards the request to the home EAP server. | Request AVP inside, then forwards the request to the home EAP server. | |||
If the home Diameter server does not support the Diameter ERP | If the home Diameter server does not support the Diameter ERP | |||
extensions, it simply ignores the ERP-RK-Request AVP and continues as | extensions, it simply ignores the ERP-RK-Request AVP and continues as | |||
specified in RFC 4072 [RFC4072]. If the server supports the ERP | specified in RFC 4072 [RFC4072]. If the server supports the ERP | |||
extensions, it saves the value of the ERP-Realm AVP found inside the | extensions, it saves the value of the ERP-Realm AVP found inside the | |||
ERP-RK-Request AVP, and continues with the EAP authentication. When | ERP-RK-Request AVP, and continues with the EAP authentication. When | |||
the authentication completes, if it is successful and the EAP method | the authentication completes, if it is successful and the EAP method | |||
has generated an EMSK, the server MUST derive the rRK as specified in | has generated an EMSK, the server MUST derive the rRK as specified in | |||
RFC 5296 [RFC5296], using the saved domain name. It then includes | RFC 6696 [RFC6696], using the saved domain name. It then includes | |||
the rRK inside a Key AVP (Section 8.3) with the Key-Type AVP set to | the rRK inside a Key AVP (Section 8.3) with the Key-Type AVP set to | |||
rRK, before sending the DEA as usual. | rRK, before sending the DEA as usual. | |||
When the ER server proxies a Diameter-EAP-Answer message with a | 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- | Session-Id corresponding to a message to which it added an ERP-RK- | |||
Request AVP, and the Result-Code is DIAMETER_SUCCESS, it MUST examine | Request AVP, and the Result-Code is DIAMETER_SUCCESS, it MUST examine | |||
the message and save and remove any Key AVP (Section 8.3) with Key- | the message and save and remove any Key AVP (Section 8.3) with Key- | |||
Type AVP set to rRK. If the message does not contain such Key AVP, | Type AVP set to rRK. If the message does not contain such Key AVP, | |||
the ER server may cache the information that ERP is not possible for | the ER server may cache the information that ERP is not possible for | |||
this session to avoid possible subsequent attempts. In any case, the | this session to avoid possible subsequent attempts. In any case, the | |||
skipping to change at page 8, line 33 | skipping to change at page 8, line 33 | |||
Then the newly created EAP/DER is sent and routed to the home | Then the newly created EAP/DER is sent and routed to the home | |||
Diameter EAP application server. | Diameter EAP application server. | |||
If the home Diameter EAP server does not support ERP extensions, EAP | If the home Diameter EAP server does not support ERP extensions, EAP | |||
packets with an unknown ERP-specific code (EAP-Initiate) will not be | packets with an unknown ERP-specific code (EAP-Initiate) will not be | |||
understood. In such a case, the home Diameter EAP server MUST send | understood. In such a case, the home Diameter EAP server MUST send | |||
an EAP/DEA with a Result-Code indicating a Permanent Failure (for | an EAP/DEA with a Result-Code indicating a Permanent Failure (for | |||
example, DIAMETER_ERROR_EAP_CODE_UNKNOWN or | example, DIAMETER_ERROR_EAP_CODE_UNKNOWN or | |||
DIAMETER_UNABLE_TO_COMPLY). The Failed-AVP AVP MUST be included and | DIAMETER_UNABLE_TO_COMPLY). The Failed-AVP AVP MUST be included and | |||
contain a copy of the EAP-Payload AVP. Otherwise, it processes the | contain a copy of the EAP-Payload AVP. Otherwise, it processes the | |||
DSRK request as described in [RFC5296]. In particular, it includes | DSRK request as described in [RFC6696]. In particular, it includes | |||
the Domain- Name TLV attribute with the content from the ERP-Realm | the Domain- Name TLV attribute with the content from the ERP-Realm | |||
AVP. The server creates the EAP/DEA reply message [RFC4072] | AVP. The server creates the EAP/DEA reply message [RFC4072] | |||
including an instance of the Key AVP (Section 8.3) with Key-Type AVP | including an instance of the Key AVP (Section 8.3) with Key-Type AVP | |||
set to rRK and an instance of the Domain-Name TLV attribute with the | set to rRK and an instance of the Domain-Name TLV attribute with the | |||
content from the ERP-Realm AVP. | content from the ERP-Realm AVP. | |||
The ER server receives this EAP/DEA and proxies it as follows, in | The ER server receives this EAP/DEA and proxies it as follows, in | |||
addition to standard proxy operations: | addition to standard proxy operations: | |||
Set the Application Id back to Diameter ERP Application Id | Set the Application Id back to Diameter ERP Application Id | |||
(Section 12.1 ) | (Section 12.1 ) | |||
Extract and cache the content of the Key AVP with Key-Type set to | Extract and cache the content of the Key AVP with Key-Type set to | |||
rRK, as described in the implicit scenario (Section 5.1). | rRK, as described in the implicit scenario (Section 5.1). | |||
The ERP/DEA message is then forwarded to the authenticator, that can | The ERP/DEA message is then forwarded to the authenticator, that can | |||
use the rMSK as described in RFC 5296 [RFC5296]. | use the rMSK as described in RFC 6696 [RFC6696]. | |||
The figure below captures this proxy behavior: | The figure below captures this proxy behavior: | |||
Authenticator ER server Home Diameter server | Authenticator ER server Home Diameter server | |||
============= ========= ==================== | ============= ========= ==================== | |||
-----------------------> | -----------------------> | |||
Diameter ERP/DER | Diameter ERP/DER | |||
(EAP-Initiate) | (EAP-Initiate) | |||
------------------------> | ------------------------> | |||
Diameter EAP/DER | Diameter EAP/DER | |||
skipping to change at page 10, line 45 | skipping to change at page 10, line 45 | |||
the authenticator. Alternatively, the authenticator may send an EAP- | the authenticator. Alternatively, the authenticator may send an EAP- | |||
Initiate/Re-auth-Start message to the peer to trigger the mechanism. | Initiate/Re-auth-Start message to the peer to trigger the mechanism. | |||
In this case, the peer responds with an EAP-Initiate/Re-auth message. | In this case, the peer responds with an EAP-Initiate/Re-auth message. | |||
If the authenticator does not support ERP (pure Diameter EAP | If the authenticator does not support ERP (pure Diameter EAP | |||
[RFC4072] support), it discards the EAP packets with an unknown ERP- | [RFC4072] support), it discards the EAP packets with an unknown ERP- | |||
specific code (EAP-Initiate). The peer should fallback to full EAP | specific code (EAP-Initiate). The peer should fallback to full EAP | |||
authentication in this case. | authentication in this case. | |||
When the authenticator receives an EAP-Initiate/Re-auth message from | When the authenticator receives an EAP-Initiate/Re-auth message from | |||
the peer, the message is processed as described in [RFC5296] with | the peer, the message is processed as described in [RFC6696] with | |||
regard to the EAP state machine. It creates a Diameter ERP/DER | regard to the EAP state machine. It creates a Diameter ERP/DER | |||
message following the general process of Diameter EAP [RFC4072], with | message following the general process of Diameter EAP [RFC4072], with | |||
the following differences: | the following differences: | |||
The Application Id in the header is set to <Diameter ERP> (code | The Application Id in the header is set to <Diameter ERP> (code | |||
TBD ). | TBD ). | |||
The value in Auth-Application-Id AVP is also set to <Diameter | The value in Auth-Application-Id AVP is also set to <Diameter | |||
ERP>. | ERP>. | |||
skipping to change at page 11, line 35 | skipping to change at page 11, line 35 | |||
The value of the Auth-Application-Id AVP is also set to <Diameter | The value of the Auth-Application-Id AVP is also set to <Diameter | |||
ERP>. | ERP>. | |||
The EAP-Payload AVP contains the EAP-Finish/Re-auth message. | The EAP-Payload AVP contains the EAP-Finish/Re-auth message. | |||
If authentication is successful, an instance of the Key AVP | If authentication is successful, an instance of the Key AVP | |||
containing the Re-authentication Master Session Key (rMSK) derived | containing the Re-authentication Master Session Key (rMSK) derived | |||
by ERP is included. | by ERP is included. | |||
When the authenticator receives this ERP/DEA answer, it processes it | When the authenticator receives this ERP/DEA answer, it processes it | |||
as described in Diameter EAP [RFC4072] and RFC5296 [RFC5296]: the | as described in Diameter EAP [RFC4072] and RFC 6696 [RFC6696]: the | |||
content of the EAP-Payload AVP is forwarded to the peer, and the | content of the EAP-Payload AVP is forwarded to the peer, and the | |||
contents of the Keying-Material AVP [I-D.ietf-dime-local-keytran] is | contents of the Keying-Material AVP [I-D.ietf-dime-local-keytran] is | |||
used as a shared secret for a secure association protocol specific to | used as a shared secret for a secure association protocol specific to | |||
the lower-layer in use. | the lower-layer in use. | |||
7. Application Id | 7. Application Id | |||
We define a new Diameter application in this document, Diameter ERP | We define a new Diameter application in this document, Diameter ERP | |||
Application, with an Application Id value of TBD. Diameter nodes | Application, with an Application Id value of TBD. Diameter nodes | |||
conforming to this specification in the role of ER server MUST | conforming to this specification in the role of ER server MUST | |||
skipping to change at page 12, line 48 | skipping to change at page 12, line 48 | |||
8.3.1. Key-Type AVP | 8.3.1. Key-Type AVP | |||
The value of the Key-Type AVP MUST be set to 2 for rRK or 3 for rMSK. | The value of the Key-Type AVP MUST be set to 2 for rRK or 3 for rMSK. | |||
8.3.2. Keying-Material AVP | 8.3.2. Keying-Material AVP | |||
The Keying-Material AVP contains the rRK sent by the home EAP server | The Keying-Material AVP contains the rRK sent by the home EAP server | |||
to the ER server, in answer to a request containing an ERP-RK-Request | to the ER server, in answer to a request containing an ERP-RK-Request | |||
AVP, or the rMSK sent by the ER server to the authenticator. How | AVP, or the rMSK sent by the ER server to the authenticator. How | |||
this material is derived and used is specified in RFC 5296 [RFC5296]. | this material is derived and used is specified in RFC 6696 [RFC6696]. | |||
8.3.3. Key-Name AVP | 8.3.3. Key-Name AVP | |||
This AVP contains the EMSKname which identifies the keying material. | This AVP contains the EMSKname which identifies the keying material. | |||
The derivation of this name is specified in RGC 5296 [RFC5296]. | The derivation of this name is specified in RGC 6696 [RFC6696]. | |||
8.3.4. Key-Lifetime AVP | 8.3.4. Key-Lifetime AVP | |||
The Key-Lifetime AVP contains the lifetime of the keying material in | The Key-Lifetime AVP contains the lifetime of the keying material in | |||
seconds. It MUST NOT be greater than the remaining lifetime of the | seconds. It MUST NOT be greater than the remaining lifetime of the | |||
EMSK from which the material was derived. | EMSK from which the material was derived. | |||
9. Result-Code AVP Values | 9. Result-Code AVP Values | |||
This section defines new Result-Code [I-D.ietf-dime-rfc3588bis] | This section defines new Result-Code [I-D.ietf-dime-rfc3588bis] | |||
skipping to change at page 14, line 48 | skipping to change at page 14, line 48 | |||
This result-code value is defined in Section 9. | This result-code value is defined in Section 9. | |||
13. Security Considerations | 13. Security Considerations | |||
The security considerations from the following documents apply here: | The security considerations from the following documents apply here: | |||
o Fajardo, et al. [I-D.ietf-dime-rfc3588bis] | o Fajardo, et al. [I-D.ietf-dime-rfc3588bis] | |||
o RFC 4072 [RFC4072] | o RFC 4072 [RFC4072] | |||
o RFC 5296 [RFC5296] | o RFC 6696 [RFC6696] | |||
o Zorn, Wu and Cakulev [I-D.ietf-dime-local-keytran] | o Zorn, Wu and Cakulev [I-D.ietf-dime-local-keytran] | |||
14. Normative References | 14. Normative References | |||
[I-D.ietf-dime-local-keytran] Zorn, G., Wu, W., and V. Cakulev, | [I-D.ietf-dime-local-keytran] Zorn, G., Wu, W., and V. Cakulev, | |||
"Diameter Attribute-Value Pairs for | "Diameter Attribute-Value Pairs for | |||
Cryptographic Key Transport", | Cryptographic Key Transport", | |||
draft-ietf-dime-local-keytran-14 (work | draft-ietf-dime-local-keytran-14 (work | |||
in progress), August 2011. | in progress), August 2011. | |||
skipping to change at page 15, line 43 | skipping to change at page 15, line 43 | |||
"Diameter Extensible Authentication | "Diameter Extensible Authentication | |||
Protocol (EAP) Application", RFC 4072, | Protocol (EAP) Application", RFC 4072, | |||
August 2005. | August 2005. | |||
[RFC5295] Salowey, J., Dondeti, L., Narayanan, | [RFC5295] Salowey, J., Dondeti, L., Narayanan, | |||
V., and M. Nakhjiri, "Specification | V., and M. Nakhjiri, "Specification | |||
for the Derivation of Root Keys from | for the Derivation of Root Keys from | |||
an Extended Master Session Key | an Extended Master Session Key | |||
(EMSK)", RFC 5295, August 2008. | (EMSK)", RFC 5295, August 2008. | |||
[RFC5296] Narayanan, V. and L. Dondeti, "EAP | [RFC6696] Cao, Z., He, B., Shi, Y., Wu, Q., and | |||
Extensions for EAP Re-authentication | G. Zorn, "EAP Extensions for the EAP | |||
Protocol (ERP)", RFC 5296, | Re-authentication Protocol (ERP)", | |||
August 2008. | RFC 6696, July 2012. | |||
[1] <http://www.iana.org/assignments/aaa-parameters/> | [1] <http://www.iana.org/assignments/aaa-parameters/> | |||
Authors' Addresses | Authors' Addresses | |||
Julien Bournelle | Julien Bournelle | |||
Orange Labs | Orange Labs | |||
38-40 rue du general Leclerc | 38-40 rue du general Leclerc | |||
Issy-Les-Moulineaux 92794 | Issy-Les-Moulineaux 92794 | |||
France | France | |||
End of changes. 15 change blocks. | ||||
18 lines changed or deleted | 18 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |