draft-ietf-hokey-erp-aak-04.txt | draft-ietf-hokey-erp-aak-05.txt | |||
---|---|---|---|---|
Network Working Group Z. Cao | Network Working Group Z. Cao | |||
Internet-Draft H. Deng | Internet-Draft H. Deng | |||
Intended status: Standards Track China Mobile | Intended status: Standards Track China Mobile | |||
Expires: September 15, 2011 Y. Wang | Expires: March 17, 2012 Y. Wang | |||
Q. Wu | Q. Wu | |||
Huawei Technologies Co., Ltd. | Huawei Technologies Co., Ltd. | |||
G. Zorn | G. Zorn | |||
Network Zen | Network Zen | |||
March 14, 2011 | September 14, 2011 | |||
EAP Re-authentication Protocol Extensions for Authenticated Anticipatory | EAP Re-authentication Protocol Extensions for Authenticated Anticipatory | |||
Keying (ERP/AAK) | Keying (ERP/AAK) | |||
draft-ietf-hokey-erp-aak-04 | draft-ietf-hokey-erp-aak-05 | |||
Abstract | Abstract | |||
The Extensible Authentication Protocol (EAP) is a generic framework | The Extensible Authentication Protocol (EAP) is a generic framework | |||
supporting multiple of authentication methods. | supporting multiple types of authentication methods. | |||
The EAP Re-authentication Protocol (ERP) specifies extensions to EAP | The EAP Re-authentication Protocol (ERP) specifies extensions to EAP | |||
and the EAP keying hierarchy to support an EAP method-independent | and the EAP keying hierarchy to support an EAP method-independent | |||
protocol for efficient re-authentication between the peer and an EAP | protocol for efficient re-authentication between the peer and an EAP | |||
re-authentication server through any authenticator. | re-authentication server through any authenticator. | |||
Authenticated Anticipatory Keying (AAK) is a method by which | Authenticated Anticipatory Keying (AAK) is a method by which | |||
cryptographic keying material may be established prior to handover | cryptographic keying material may be established prior to handover | |||
upon one or more candidate attachment points (CAPs). AAK uses the | upon one or more candidate attachment points (CAPs). AAK uses the | |||
AAA infrastructure for key transport. | AAA infrastructure for key transport. | |||
skipping to change at page 2, line 4 | skipping to change at page 2, line 4 | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on September 15, 2011. | This Internet-Draft will expire on March 17, 2012. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2011 IETF Trust and the persons identified as the | Copyright (c) 2011 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 3, line 19 | skipping to change at page 3, line 19 | |||
systems where EAP is used for authentication, it is desirable to not | systems where EAP is used for authentication, it is desirable to not | |||
repeat the entire EAP exchange with another authenticator. The EAP | repeat the entire EAP exchange with another authenticator. The EAP | |||
Re-authentication Protocol (ERP) [RFC5296] specifies extensions to | Re-authentication Protocol (ERP) [RFC5296] specifies extensions to | |||
EAP and the EAP keying hierarchy to support an EAP method-independent | EAP and the EAP keying hierarchy to support an EAP method-independent | |||
protocol for efficient re-authentication between the peer and an EAP | protocol for efficient re-authentication between the peer and an EAP | |||
re-authentication server through any authenticator. The re- | re-authentication server through any authenticator. The re- | |||
authentication server may be in the home network or in the local | authentication server may be in the home network or in the local | |||
network to which the peer is connecting. | network to which the peer is connecting. | |||
Authenticated Anticipatory Keying (AAK) [RFC5836] is a method by | Authenticated Anticipatory Keying (AAK) [RFC5836] is a method by | |||
which cryptographic keying material may be established prior to | which cryptographic keying materials may be established prior to | |||
handover upon one or more candidate attachment points (CAPs). AAK | handover upon one or more candidate attachment points (CAPs). AAK | |||
utilizes the AAA infrastructure for key transport. | utilizes the AAA infrastructure for key transport. | |||
This document specifies the extensions necessary to enable AAK | This document specifies the extensions necessary to enable AAK | |||
support in ERP. | support in ERP. | |||
2. Terminology | 2. Terminology | |||
2.1. Standards Language | 2.1. Standards Language | |||
skipping to change at page 5, line 18 | skipping to change at page 5, line 18 | |||
response to an EAP-Initiate/Re-Auth-Start message from the SAP. In | response to an EAP-Initiate/Re-Auth-Start message from the SAP. In | |||
this document, it is required that the SAP should support ERP/AAK. | this document, it is required that the SAP should support ERP/AAK. | |||
If either the peer or the SAP does not support ERP/AAK, it should | If either the peer or the SAP does not support ERP/AAK, it should | |||
fall back to full EAP authentication. | fall back to full EAP authentication. | |||
The peer sends an early-authentication request message (EAP-Initiate/ | The peer sends an early-authentication request message (EAP-Initiate/ | |||
Re-auth with the 'E' flag set) containing the keyName-NAI, the NAS- | Re-auth with the 'E' flag set) containing the keyName-NAI, the NAS- | |||
Identifier, rIK and sequence number. The realm in the keyName-NAI | Identifier, rIK and sequence number. The realm in the keyName-NAI | |||
field is used to locate the peer's ERP/AAK server. The NAS- | field is used to locate the peer's ERP/AAK server. The NAS- | |||
Identifier is used to identify the CAP. The rIK is used to protect | Identifier is used to identify the CAP. The rIK is used to protect | |||
the message. The sequence number is used for replay protection. To | the message. The sequence number is used for replay protection. | |||
avoid the same pre-established Master Session Key (pMSK) being | ||||
derived for multiple CAPs, the sequence number MUST be unique for | ||||
each CAP. | ||||
The SAP encapsulates the early-authentication message into a AAA | The SAP encapsulates the early-authentication message into a AAA | |||
message and sends it to the peer's ERP/AAK server in the realm | message and sends it to the peer's ERP/AAK server in the realm | |||
indicated in the keyName-NAI field. | indicated in the keyName-NAI field. | |||
Upon receiving the message, the ERP/AAK server first checks its | Upon receiving the message, the ERP/AAK server first checks its | |||
integrity and freshness, then authenticates and authorizes the CAP | integrity and freshness, then authorizes the CAP presented in the | |||
presented in the NAS-Identifier TLV(s). After the CAP is | NAS-Identifier TLV(s) via the NAS-Identifier. After the CAP is | |||
authenticated and authorized successfully, the ERP/AAK server derives | authenticated and authorized successfully, the ERP/AAK server derives | |||
the pRK and the subsequent pMSK for the CAP. | the pRK and the subsequent pMSK for the CAP. | |||
The ERP/AAK server transports the pMSK to the authenticated and | The ERP/AAK server transports the pMSK to the authenticated and | |||
authorized CAP(s) via AAA as described in Section 7. | authorized CAP(s) via AAA as described in Section 7. | |||
Finally, the ERP/AAK server sends the early-authentication finish | Finally, the ERP/AAK server sends the early-authentication finish | |||
message (EAP-Finish/Re-auth with E-flag set) containing the | message (EAP-Finish/Re-auth with E-flag set) containing the | |||
determinated CAP to the peer via the SAP. | determined CAP to the peer via the SAP. | |||
4. ERP/AAK Key Hierarchy | 4. ERP/AAK Key Hierarchy | |||
As an optimization of ERP, ERP/AAK uses key hierarchy similar to that | As an optimization of ERP, ERP/AAK uses key hierarchy similar to that | |||
of ERP. The EMSK is used to derive the ERP/AAK pre-established Root | of ERP. The EMSK is used to derive the ERP/AAK pre-established Root | |||
Key (pRK). Similarly, the ERP/AAK pre-established Integrity Key | Key (pRK). Similarly, the ERP/AAK pre-established Integrity Key | |||
(pIK) and the pre-established Master Session Key (pMSK) are derived | (pIK) and the pre-established Master Session Key (pMSK) are derived | |||
from the pRK. The pMSK is established for the CAP(s) when the peer | from the pRK. The pMSK is established for the CAP(s) when the peer | |||
early authenticates to the network. The pIK is established for the | early authenticates to the network. The pIK is established for the | |||
peer to re-authenticate the network after handover. The hierarchy | peer to re-authenticate the network after handover. The hierarchy | |||
skipping to change at page 6, line 18 | skipping to change at page 6, line 18 | |||
| | | | | | | | |||
pRK rRK ... | pRK rRK ... | |||
Figure 2 | Figure 2 | |||
The EMSK and DSRK both can be used to derive the pRK. In general, | The EMSK and DSRK both can be used to derive the pRK. In general, | |||
the pRK is derived from the EMSK in case of the peer moving in the | the pRK is derived from the EMSK in case of the peer moving in the | |||
home AAA realm and derived from the DRSK in case of the peer moving | home AAA realm and derived from the DRSK in case of the peer moving | |||
in the visited AAA realm. The DSRK is delivered from the EAP server | in the visited AAA realm. The DSRK is delivered from the EAP server | |||
to the ERP/AAK server as specified in [I-D.ietf-dime-local-keytran]. | to the ERP/AAK server as specified in [I-D.ietf-dime-local-keytran]. | |||
If the peer has previously authenticated by means of ERP or ERP/AAK, | If the peer has previously been authenticated by means of ERP or ERP/ | |||
the DSRK SHOULD be directly re-used. | AAK, the DSRK SHOULD be directly re-used. | |||
pRK | pRK | |||
| | | | |||
+--------+--------+ | +--------+--------+ | |||
| | | | | | | | |||
pIK pMSK ... | pIK pMSK ... | |||
Figure 3 | Figure 3 | |||
The pRK is used to derive the pIK and pMSK for the CAP(s). Different | The pRK is used to derive the pIK and pMSK for the CAP(s). | |||
sequence numbers for each CAP MUST be used to derive the unique | ||||
pMSK(s). | ||||
5. Packet and TLV Extension | 5. Packet and TLV Extension | |||
This section describes the packet and TLV extensions for the ERP/AAK | This section describes the packet and TLV extensions for the ERP/AAK | |||
exchange. | exchange. | |||
5.1. EAP-Initiate/Re-auth-Start Packet Extension | 5.1. EAP-Initiate/Re-auth-Start Packet Extension | |||
Figure 4 shows the changed parameters contained in the EAP-Initiate/ | Figure 4 shows the changed parameters contained in the EAP-Initiate/ | |||
Re-auth-Start packet defined in RFC 5296 [RFC5296]. | Re-auth-Start packet defined in RFC 5296 [RFC5296]. | |||
skipping to change at page 8, line 6 | skipping to change at page 8, line 4 | |||
'E' - The E flag is used to indicate early-authentication. | 'E' - The E flag is used to indicate early-authentication. | |||
The rest of the 4 bits (Resved) MUST be set to 0 and ignored on | The rest of the 4 bits (Resved) MUST be set to 0 and ignored on | |||
reception. | reception. | |||
SEQ | SEQ | |||
A 16-bit sequence number is used for replay protection. | A 16-bit sequence number is used for replay protection. | |||
TVs and TLVs | TVs and TLVs | |||
keyName-NAI: As defined in RFC 5296 [RFC5296], this is carried in a | keyName-NAI: As defined in RFC 5296 [RFC5296], this is carried in a | |||
TLV payload. The Type is 1. The NAI is variable in length, not | TLV payload. The Type is 1. The NAI is variable in length, not | |||
exceeding 253 octets. The username part of the NAI is the EMSKname | exceeding 253 octets. The username part of the NAI is the EMSKname | |||
used identify the peer. The realm part of the NAI is the peer's home | used to identify the peer. The realm part of the NAI is the peer's | |||
domain name or the domain to which the peer is currently attached. | home domain name or the domain to which the peer is currently | |||
Exactly one keyName-NAI attribute SHALL be present in an EAP- | attached. Exactly one keyName-NAI attribute SHALL be present in an | |||
Initiate/Re-auth packet. | EAP-Initiate/Re-auth packet. | |||
NAS-Identifier: As defined in RFC 5296 [RFC5296], it is carried in a | NAS-Identifier: As defined in RFC 5296 [RFC5296], it is carried in a | |||
TLV payload. It is used to indicate the identifier of a CAP. Though | TLV payload. It is used to indicate the identifier of a CAP. Though | |||
this document only introduces the case of a single CAP, two or more | this document only introduces the case of a single CAP, two or more | |||
NAS-Identifier may be included in the EAP-Initiate/Re-auth packet to | NAS-Identifier may be included in the EAP-Initiate/Re-auth packet to | |||
identify multiple CAPs. | identify multiple CAPs. | |||
Sequence number: It is carried in a TV payload. The Type is TBD | Sequence number: It is carried in a TV payload. The Type is TBD | |||
(which is lower than 128). It is used in the derivation of the pMSK | (which is lower than 128). It is used in the derivation of the pMSK | |||
for each CAP to avoid multiple CAP using the same pMSK. Each NAS- | for each CAP. Each NAS-Identifier in the packet MUST be associated | |||
Identifier in the packet MUST be associated with a unique sequence | with a unique sequence number. | |||
number. | ||||
Cryptosuite | Cryptosuite | |||
This field indicates the integrity algorithm used for ERP/AAK. Key | This field indicates the integrity algorithm used for ERP/AAK. Key | |||
lengths and output lengths are either indicated or are obvious from | lengths and output lengths are either indicated or obvious from the | |||
the cryptosuite name. We specify some cryptosuites below: | cryptosuite name. We specify some cryptosuites below: | |||
0 RESERVED | 0 RESERVED | |||
1 HMAC-SHA256-64 | 1 HMAC-SHA256-64 | |||
2 HMAC-SHA256-128 | 2 HMAC-SHA256-128 | |||
3 HMAC-SHA256-256 | 3 HMAC-SHA256-256 | |||
HMAC-SHA256-128 is mandatory to implement and should be enabled in | HMAC-SHA256-128 is mandatory to implement and should be enabled in | |||
skipping to change at page 10, line 34 | skipping to change at page 10, line 34 | |||
Section 5.2, above. The server SHOULD include this attribute if | Section 5.2, above. The server SHOULD include this attribute if | |||
the cryptosuite used in the EAP-Initiate/Re-auth message was not | the cryptosuite used in the EAP-Initiate/Re-auth message was not | |||
acceptable and the message is being rejected. The server MAY | acceptable and the message is being rejected. The server MAY | |||
include this attribute in other cases. The server MAY use this | include this attribute in other cases. The server MAY use this | |||
attribute to signal to the peer about its cryptographic algorithm | attribute to signal to the peer about its cryptographic algorithm | |||
capabilities. | capabilities. | |||
Cryptosuite | Cryptosuite | |||
This field indicates the integrity algorithm and PRF used for ERP/ | This field indicates the integrity algorithm and PRF used for ERP/ | |||
AAK. Key lengths and output lengths are either indicated or are | AAK. Key lengths and output lengths are either indicated or obvious | |||
obvious from the cryptosuite name. | from the cryptosuite name. | |||
Authentication Tag | Authentication Tag | |||
This field contains the integrity checksum over the ERP/AAK packet, | This field contains the integrity checksum over the ERP/AAK packet, | |||
excluding the authentication tag field itself. The length of the | excluding the authentication tag field itself. The length of the | |||
field is indicated by the Cryptosuite. | field is indicated by the Cryptosuite. | |||
5.4. TV/TLV and sub-TLV Attributes | 5.4. TV/TLV and sub-TLV Attributes | |||
The TV and TLV attributes are the same specified as section 5.3.4 of | The TV and TLV attributes are the same specified as section 5.3.4 of | |||
skipping to change at page 12, line 24 | skipping to change at page 12, line 24 | |||
derive the unique pMSK. | derive the unique pMSK. | |||
o Replay detection mechanism: For replay protection of ERP-AAK | o Replay detection mechanism: For replay protection of ERP-AAK | |||
messages, a sequence number associated with the pMSK is used. | messages, a sequence number associated with the pMSK is used. | |||
o Authenticate all parties: The EAP Re-auth Protocol provides mutual | o Authenticate all parties: The EAP Re-auth Protocol provides mutual | |||
authentication of the peer and the server. The peer and SAP are | authentication of the peer and the server. The peer and SAP are | |||
authenticated via ERP. The CAP is authenticated and trusted by | authenticated via ERP. The CAP is authenticated and trusted by | |||
the SAP. | the SAP. | |||
o Peer and authenticator authorization: The sequence number is | o Peer and authenticator authorization: The peer and authenticator | |||
maintained by the peer and the server, and incremented by them | demonstrate possession of the same key material without disclosing | |||
synchronously. | it, as part of the lower layer secure authentication protocol. | |||
o Keying material confidentiality: The peer and the server derive | o Keying material confidentiality: The peer and the server derive | |||
the keys independently using parameters known to each entity. | the keys independently using parameters known to each entity. | |||
o Uniquely named keys: All keys produced within the ERP context can | o Uniquely named keys: All keys produced within the ERP context can | |||
be referred to uniquely as specified in this document. | be referred to uniquely as specified in this document. | |||
o Prevent the domino effect: Different sequence numbers for each CAP | o Prevent the domino effect: Different sequence numbers for each CAP | |||
MUST be used to derive the unique pMSK. So the compromise of one | MUST be used to derive the unique pMSK. So the compromise of one | |||
pMSK does not hurt any other CAP. | pMSK does not hurt any other CAP. | |||
o Bind key to its context: the pMSK are binded to the context where | o Bind key to its context: the pMSK are binded to the context where | |||
the sequence numbers are transmitted. | the sequence numbers are transmitted. | |||
o Confidentiality of identity: this is the same with ERP protocol as | o Confidentiality of identity: this is the same with ERP protocol as | |||
analyzed in [RFC5296]. | analyzed in [RFC5296]. | |||
o Authorization restriction: All the keys derived are limited in | o Authorization restriction: All the keys derived are limited in | |||
lifetime by that of the parent key or by server policy. Any | lifetime by that of the parent key or by server policy. Any | |||
domain-specific keys are further restricted for use only in the | domain-specific keys are further restricted to be used only in the | |||
domain for which the keys are derived. Any other restrictions of | domain for which the keys are derived. Any other restrictions of | |||
session keys may be imposed by the specific lower layer and are | session keys may be imposed by the specific lower layer and are | |||
out of scope for this specification. | out of scope for this specification. | |||
9. IANA Considerations | 9. IANA Considerations | |||
New TLV types: | New TLV types: | |||
Sequence number | Sequence number | |||
skipping to change at page 13, line 43 | skipping to change at page 13, line 43 | |||
[RFC5296] Narayanan, V. and L. Dondeti, "EAP | [RFC5296] Narayanan, V. and L. Dondeti, "EAP | |||
Extensions for EAP Re-authentication | Extensions for EAP Re-authentication | |||
Protocol (ERP)", RFC 5296, | Protocol (ERP)", RFC 5296, | |||
August 2008. | August 2008. | |||
11.2. Informative References | 11.2. Informative 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-08 (work | draft-ietf-dime-local-keytran-14 (work | |||
in progress), October 2010. | in progress), August 2011. | |||
[RFC3588] Calhoun, P., Loughney, J., Guttman, | [RFC3588] Calhoun, P., Loughney, J., Guttman, | |||
E., Zorn, G., and J. Arkko, "Diameter | E., Zorn, G., and J. Arkko, "Diameter | |||
Base Protocol", RFC 3588, | Base Protocol", RFC 3588, | |||
September 2003. | September 2003. | |||
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., | [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., | |||
Carlson, J., and H. Levkowetz, | Carlson, J., and H. Levkowetz, | |||
"Extensible Authentication Protocol | "Extensible Authentication Protocol | |||
(EAP)", RFC 3748, June 2004. | (EAP)", RFC 3748, June 2004. | |||
skipping to change at page 15, line 11 | skipping to change at page 15, line 11 | |||
Phone: +86 25 84565893 | Phone: +86 25 84565893 | |||
EMail: w52006@huawei.com | EMail: w52006@huawei.com | |||
Qin Wu | Qin Wu | |||
Huawei Technologies Co., Ltd. | Huawei Technologies Co., Ltd. | |||
Floor 12, HuiHong Mansion, No.91 BaiXia Rd. | Floor 12, HuiHong Mansion, No.91 BaiXia Rd. | |||
Nanjing, Jiangsu 210001 | Nanjing, Jiangsu 210001 | |||
P.R. China | P.R. China | |||
Phone: +86 25 84565892 | Phone: +86 25 84565892 | |||
EMail: sunseawq@huawei.com | EMail: bill.wu@huawei.com | |||
Glen Zorn | Glen Zorn | |||
Network Zen | Network Zen | |||
227/358 Thanon Sanphawut | 227/358 Thanon Sanphawut | |||
Bang Na, Bangkok 10260 | Bang Na, Bangkok 10260 | |||
Thailand | Thailand | |||
Phone: +66 (0) 87-040-4617 | Phone: +66 (0) 87-040-4617 | |||
EMail: gwz@net-zen.net | EMail: gwz@net-zen.net | |||
End of changes. 20 change blocks. | ||||
37 lines changed or deleted | 30 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/ |