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/