draft-ietf-hokey-erp-aak-02.txt | draft-ietf-hokey-erp-aak-03.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: November 12, 2010 Y. Wang | Expires: May 12, 2011 Y. Wang | |||
Q. Wu | Q. Wu | |||
Huawei Technologies Co., Ltd. | Huawei Technologies Co., Ltd. | |||
G. Zorn, Ed. | G. Zorn | |||
Network Zen | Network Zen | |||
May 11, 2010 | November 8, 2010 | |||
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-02 | draft-ietf-hokey-erp-aak-03 | |||
Abstract | Abstract | |||
The Extensible Authentication Protocol (EAP) is a generic framework | The Extensible Authentication Protocol (EAP) is a generic framework | |||
supporting multiple types of authentication methods. | supporting multiple 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 AAA | upon one or more candidate attachment points (CAPs). AAK uses the | |||
infrastructure for key transport. | 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. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
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 November 12, 2010. | This Internet-Draft will expire on May 12, 2011. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2010 IETF Trust and the persons identified as the | Copyright (c) 2010 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 32 | skipping to change at page 3, line 32 | |||
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 | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in RFC 2119 [RFC2119] | document are to be interpreted as described in RFC 2119 [RFC2119]. | |||
2.2. Acronyms | 2.2. Acronyms | |||
The following acronyms are used in this document; see the references | The following acronyms are used in this document; see the references | |||
for more details. | for more details. | |||
AAA Authentication, Authorization and Accounting [RFC3588] | AAA Authentication, Authorization and Accounting [RFC3588] | |||
CAP Candidate Attachment Point [RFC5836] | CAP Candidate Attachment Point [RFC5836] | |||
skipping to change at page 4, line 37 | skipping to change at page 4, line 37 | |||
2. | EAP-Initiate/ | | | | 2. | EAP-Initiate/ | | | | |||
| Re-auth | | | | | | Re-auth | | | | | |||
| (E-flag) | | | | | | (E-flag) | | | | | |||
|---------->| | | | | |---------->| | | | | |||
3. | | AAA (EAP-Initiate/Re-auth(E-flag))| | 3. | | AAA (EAP-Initiate/Re-auth(E-flag))| | |||
| |---------------------------------->| | | |---------------------------------->| | |||
| | | | | | | | | | | | |||
| | | | +---------+---------+ | | | | | +---------+---------+ | |||
| | | | | CA authorized & | | | | | | | CA authorized & | | |||
4. | | | | | authenticated; | | 4. | | | | | authenticated; | | |||
| | | | | EE keying | | | | | | | EA keying | | |||
| | | | | materials derived | | | | | | | materials derived | | |||
| | | | +---------+---------+ | | | | | +---------+---------+ | |||
| | | | | | | | | | | | |||
5. | | | | AAA(pMSKx) | | 5. | | | | AAA(pMSKx) | | |||
| | |AAA(pMSK1)|<----------->| | | | |AAA(pMSK1)|<----------->| | |||
| | |<---------------------->| | | | |<---------------------->| | |||
| | | | | | | | | | | | |||
6. | | AAA (EAP-Finish/Re-auth(E-flag)) | | 6. | | AAA (EAP-Finish/Re-auth(E-flag)) | | |||
| |<----------------------------------| | | |<----------------------------------| | |||
| | | | | | | | | | | | |||
skipping to change at page 5, line 41 | skipping to change at page 5, line 41 | |||
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 each CAP. | the pRK and the subsequent pMSK for each 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. After the | authorized CAP(s) via AAA as described in Section 7. After the | |||
keying materials are delivered, the ERP/AAK server should determine | keying materials are delivered, the ERP/AAK server should determine | |||
each CA whether accepts the pMSK and whether the peer could be | each CA whether accepts the pMSK and whether the peer could be | |||
attached to. | attached to. | |||
At last, the ERP/AAK server sends the early-authentication finish | At last, the ERP/AAK server sends the early-authentication finish | |||
message (EAP-Finish/Re-auth with E-flag) containing the determinate | message (EAP-Finish/Re-auth with E-flag set) containing the | |||
CAP(s) to the peer via the SAP. | determinate CAP(s) 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 12, line 43 | skipping to change at page 12, 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. | |||
10.2. Informative References | 10.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-03 (work | draft-ietf-dime-local-keytran-08 (work | |||
in progress), May 2010. | in progress), October 2010. | |||
[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 14, line 4 | skipping to change at page 14, line 4 | |||
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: sunseawq@huawei.com | |||
Glen Zorn (editor) | Glen Zorn | |||
Network Zen | Network Zen | |||
1463 East Republican Street | 227/358 Thanon Sanphawut | |||
#358 | Bang Na, Bangkok 10260 | |||
Seattle, Washington 98112 | Thailand | |||
USA | ||||
Phone: +66 (0) 87-040-4617 | ||||
EMail: gwz@net-zen.net | EMail: gwz@net-zen.net | |||
End of changes. 14 change blocks. | ||||
19 lines changed or deleted | 19 lines changed or added | |||
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |