draft-ietf-hokey-erp-aak-03.txt   draft-ietf-hokey-erp-aak-04.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: May 12, 2011 Y. Wang Expires: September 15, 2011 Y. Wang
Q. Wu Q. Wu
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
G. Zorn G. Zorn
Network Zen Network Zen
November 8, 2010 March 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-03 draft-ietf-hokey-erp-aak-04
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 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.
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 May 12, 2011. This Internet-Draft will expire on September 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 33 skipping to change at page 2, line 33
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 3 2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 3
2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. ERP/AAK Overview . . . . . . . . . . . . . . . . . . . . . . . 4 3. ERP/AAK Overview . . . . . . . . . . . . . . . . . . . . . . . 4
4. ERP/AAK Key Hierarchy . . . . . . . . . . . . . . . . . . . . 5 4. ERP/AAK Key Hierarchy . . . . . . . . . . . . . . . . . . . . 5
5. Packet and TLV Extension . . . . . . . . . . . . . . . . . . . 6 5. Packet and TLV Extension . . . . . . . . . . . . . . . . . . . 6
5.1. EAP-Initiate/Re-auth-Start Packet Extension . . . . . . . 6 5.1. EAP-Initiate/Re-auth-Start Packet Extension . . . . . . . 6
5.2. EAP-Initiate/Re-auth Packet Extension . . . . . . . . . . 7 5.2. EAP-Initiate/Re-auth Packet Extension . . . . . . . . . . 7
5.3. EAP-Finish/Re-auth extension . . . . . . . . . . . . . . . 9 5.3. EAP-Finish/Re-auth extension . . . . . . . . . . . . . . . 9
5.4. TV/TLV and sub-TLV Attributes . . . . . . . . . . . . . . 11 5.4. TV/TLV and sub-TLV Attributes . . . . . . . . . . . . . . 10
6. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 11 6. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 11
7. AAA Transport Considerations . . . . . . . . . . . . . . . . . 11 7. AAA Transport Considerations . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The Extensible Authentication Protocol (EAP) [RFC3748] is a generic The Extensible Authentication Protocol (EAP) [RFC3748] is a generic
framework supporting multiple types of authentication methods. In framework supporting multiple types of authentication methods. In
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
skipping to change at page 4, line 8 skipping to change at page 4, line 8
EA Abbreviation for "ERP/AAK"; used in figures EA Abbreviation for "ERP/AAK"; used in figures
MH Mobile Host MH Mobile Host
SAP Serving Attachment Point [RFC5836] SAP Serving Attachment Point [RFC5836]
3. ERP/AAK Overview 3. ERP/AAK Overview
ERP/AAK is intended to allow the establishment of cryptographic ERP/AAK is intended to allow the establishment of cryptographic
keying materials on one or more Candidate Attachment Points prior to keying materials on a single Candidate Attachment Points prior to the
the arrival of the MH at the Candidate Access Network (CAN). The arrival of the MH at the Candidate Access Network (CAN). The
document also specifies a method by which the SAP may send the document also specifies a method by which the SAP may send the
identities of neighboring attachment points to the peer in the EAP- identities of neighboring attachment points to the peer in the EAP-
Initiate/Re-auth-Start message. Initiate/Re-auth-Start message.
It is assumed that the peer has previously completed full EAP It is assumed that the peer has previously completed full EAP
authentication. Figure 1 shows the general protocol exchange by authentication. Figure 1 shows the general protocol exchange by
which the keying material is established on the CAP(s). which the keying material is established on the CAP. This document
only discusses the case of distributing the key to a single CAP.
+------+ +-----+ +-----+ +-----------+
| Peer | | SAP | | CAP | | EA Server |
+--+---+ +--+--+ +--+--+ +-----+-----+
| | | |
1. | [EAP-Initiate/ | | |
| Re-auth-start | | |
| (E-flag) | | |
|<---------------| | |
| | | |
2. | EAP-Initiate/ | | |
| Re-auth | | |
| (E-flag) | | |
|--------------->| | |
3. | | AAA(EAP-Initiate/Re-auth(E-flag))|
| |--------------------------------->|
| | | +---------+---------+
| | | | CA authorized & |
4. | | | | authenticated; |
| | | | EA keying |
| | | | materials derived |
| | | +---------+---------+
5. | | | |
| | | AAA(pMSK) |
| | |<----------------->|
| | | |
6. | | AAA (EAP-Finish/Re-auth(E-flag)) |
| |<---------------------------------|
7. | EAP-Finish/ | | |
| Re-auth(E-flag)| | |
|<---------------| | |
| | | |
+------+ +-----+ +-----+ +-----+ +-----------+
| Peer | | SAP | |CAP1 | |CAPx | | EA Server |
+--+---+ +--+--+ +--+--+ +--+--+ +-----+-----+
| | | | |
1. | [EAP-Initiate/ | | |
| Re-auth-start | | |
| (E-flag) | | | |
|<----------| | | |
| | | | |
2. | EAP-Initiate/ | | |
| Re-auth | | | |
| (E-flag) | | | |
|---------->| | | |
3. | | AAA (EAP-Initiate/Re-auth(E-flag))|
| |---------------------------------->|
| | | | |
| | | | +---------+---------+
| | | | | CA authorized & |
4. | | | | | authenticated; |
| | | | | EA keying |
| | | | | materials derived |
| | | | +---------+---------+
| | | | |
5. | | | | AAA(pMSKx) |
| | |AAA(pMSK1)|<----------->|
| | |<---------------------->|
| | | | |
6. | | AAA (EAP-Finish/Re-auth(E-flag)) |
| |<----------------------------------|
| | | | |
7. | EAP-Finish/ | | |
| Re-auth(E-flag) | | |
|<----------| | | |
| | | | |
Figure 1: ERP/AAK Operation Figure 1: ERP/AAK Operation
ERP/AAK re-uses the packet format defined by ERP, but specifies a new ERP/AAK re-uses the packet format defined by ERP, but specifies a new
flag to differentiate EAP early-authentication from EAP re- flag to differentiate EAP early-authentication from EAP re-
authentication. The peer initiates ERP/AAK itself, or does so in authentication. The peer initiates ERP/AAK itself, or does so in
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(s). The rIK is used to Identifier is used to identify the CAP. The rIK is used to protect
protect the message. The sequence number is used for replay the message. The sequence number is used for replay protection. To
protection. To avoid the same pre-established Master Session Key avoid the same pre-established Master Session Key (pMSK) being
(pMSK) being derived for multiple CAPs, the sequence number MUST be derived for multiple CAPs, the sequence number MUST be unique for
unique for each CAP. 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(s) integrity and freshness, then authenticates and authorizes the CAP
presented in the NAS-Identifier TLV(s). After the CAP(s) is presented in the NAS-Identifier TLV(s). 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 each 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. After the authorized CAP(s) via AAA as described in Section 7.
keying materials are delivered, the ERP/AAK server should determine
each CA whether accepts the pMSK and whether the peer could be
attached to.
At last, 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
determinate CAP(s) to the peer via the SAP. determinated 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 8, line 26 skipping to change at page 8, line 16
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 identify the peer. The realm part of the NAI is the peer's home
domain name or the domain to which the peer is currently attached. domain name or the domain to which the peer is currently attached.
Exactly one keyName-NAI attribute SHALL be present in an EAP- Exactly one keyName-NAI attribute SHALL be present in an EAP-
Initiate/Re-auth packet. 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. One or TLV payload. It is used to indicate the identifier of a CAP. Though
more NAS-Identifier may be included in the EAP-Initiate/Re-auth this document only introduces the case of a single CAP, two or more
packet. NAS-Identifier may be included in the EAP-Initiate/Re-auth packet to
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 to avoid multiple CAP using the same pMSK. Each NAS-
Identifier in the packet MUST be associated with a unique sequence Identifier in the packet MUST be associated 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
skipping to change at page 11, line 51 skipping to change at page 11, line 43
7. AAA Transport Considerations 7. AAA Transport Considerations
AAA transport of ERP/AAK messages is the same as AAA transport of the AAA transport of ERP/AAK messages is the same as AAA transport of the
ERP message [RFC5296]. In addition, the document requires AAA ERP message [RFC5296]. In addition, the document requires AAA
transport of the ERP/AAK keying materials delivered by the ERP/AAK transport of the ERP/AAK keying materials delivered by the ERP/AAK
server to the CAP. Hence, a new Diameter ERP/AAK application message server to the CAP. Hence, a new Diameter ERP/AAK application message
should be specified to transport the keying materials. should be specified to transport the keying materials.
8. Security Considerations 8. Security Considerations
TBD. This section provides an analysis of the protocol in accordance with
the AAA key management requirements specified in [RFC4962]
o Cryptographic algorithm independence: ERP-AAK satisfies this
requirement. The algorithm chosen by the peer is indicated in the
EAP-Initiate/Re-auth message. If the chosen algorithm is
unacceptable, the EAP server returns an EAP- Finish/Re-auth
message with Failure indication
o Strong, fresh session keys: ERP-AAK results in the derivation of
strong, fresh keys that are unique for the given CAP. An pMSK is
always derived on-demand when the peer requires a key with a new
CAP. The derivation ensures that the compromise of one pMSK does
not result in the compromise of a different pMSK at any time.
o Limit key scope: The scope of all the keys derived by ERP-AAK is
well defined. The pRK is used to derive the pIK and pMSK for the
CAP. Different sequence numbers for each CAP MUST be used to
derive the unique pMSK.
o Replay detection mechanism: For replay protection of ERP-AAK
messages, a sequence number associated with the pMSK is used.
o Authenticate all parties: The EAP Re-auth Protocol provides mutual
authentication of the peer and the server. The peer and SAP are
authenticated via ERP. The CAP is authenticated and trusted by
the SAP.
o Peer and authenticator authorization: The sequence number is
maintained by the peer and the server, and incremented by them
synchronously.
o Keying material confidentiality: The peer and the server derive
the keys independently using parameters known to each entity.
o Uniquely named keys: All keys produced within the ERP context can
be referred to uniquely as specified in this document.
o Prevent the domino effect: Different sequence numbers for each CAP
MUST be used to derive the unique pMSK. So the compromise of one
pMSK does not hurt any other CAP.
o Bind key to its context: the pMSK are binded to the context where
the sequence numbers are transmitted.
o Confidentiality of identity: this is the same with ERP protocol as
analyzed in [RFC5296].
o Authorization restriction: All the keys derived are limited in
lifetime by that of the parent key or by server policy. Any
domain-specific keys are further restricted for use only in the
domain for which the keys are derived. Any other restrictions of
session keys may be imposed by the specific lower layer and are
out of scope for this specification.
9. IANA Considerations 9. IANA Considerations
New TLV types: New TLV types:
NAS-Identifier
Sequence number Sequence number
ERP/AAK-Key ERP/AAK-Key
New sub-TLV types: New sub-TLV types:
NAS-Identifier
pRK Lifetime pRK Lifetime
pMSK Lifetime pMSK Lifetime
List of Cryptosuites 10. Acknowledgement
10. References In writing this document, we have received reviews from many experts
in IETF, including Tom Taylor, Tena Zou, Tim Polk. We apologize if
we miss some names that have helped us.
10.1. Normative References 11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in [RFC2119] Bradner, S., "Key words for use in
RFCs to Indicate Requirement Levels", RFCs to Indicate Requirement Levels",
BCP 14, RFC 2119, March 1997. BCP 14, RFC 2119, March 1997.
[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 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-08 (work
in progress), October 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.
[RFC4962] Housley, R. and B. Aboba, "Guidance
for Authentication, Authorization, and
Accounting (AAA) Key Management",
BCP 132, RFC 4962, July 2007.
[RFC5836] Ohba, Y., Wu, Q., and G. Zorn, [RFC5836] Ohba, Y., Wu, Q., and G. Zorn,
"Extensible Authentication Protocol "Extensible Authentication Protocol
(EAP) Early Authentication Problem (EAP) Early Authentication Problem
Statement", RFC 5836, April 2010. Statement", RFC 5836, April 2010.
Authors' Addresses Authors' Addresses
Zhen Cao Zhen Cao
China Mobile China Mobile
53A Xibianmennei Ave., Xuanwu District 53A Xibianmennei Ave., Xuanwu District
 End of changes. 25 change blocks. 
73 lines changed or deleted 129 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/