draft-ietf-hokey-erp-aak-07.txt   draft-ietf-hokey-erp-aak-08.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: July 20, 2012 Q. Wu Expires: August 11, 2012 Q. Wu
Huawei Huawei
G. Zorn G. Zorn
Network Zen Network Zen
January 17, 2012 February 8, 2012
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-07 draft-ietf-hokey-erp-aak-08
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 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.
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 July 20, 2012. This Internet-Draft will expire on August 11, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 2, line 26 skipping to change at page 2, line 26
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
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 Description . . . . . . . . . . . . . . . . . . . . . 4
4. ERP/AAK Key Hierarchy . . . . . . . . . . . . . . . . . . . . 6 4. ERP/AAK Key Hierarchy . . . . . . . . . . . . . . . . . . . . 6
4.1. pRK, pMSK derivation . . . . . . . . . . . . . . . . . . . 7 4.1. pRK, pMSK derivation . . . . . . . . . . . . . . . . . . . 7
5. Packet and TLV Extension . . . . . . . . . . . . . . . . . . . 8 5. Packet and TLV Extension . . . . . . . . . . . . . . . . . . . 8
5.1. EAP-Initiate/Re-auth-Start Packet and TLV Extension . . . 8 5.1. EAP-Initiate/Re-auth-Start Packet and TLV Extension . . . 8
5.2. EAP-Initiate/Re-auth Packet and TLV Extension . . . . . . 8 5.2. EAP-Initiate/Re-auth Packet and TLV Extension . . . . . . 8
5.3. EAP-Finish/Re-auth packet and TLV extension . . . . . . . 10 5.3. EAP-Finish/Re-auth packet and TLV extension . . . . . . . 10
5.4. TV and TLV Attributes . . . . . . . . . . . . . . . . . . 13 5.4. TV and TLV Attributes . . . . . . . . . . . . . . . . . . 13
6. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 13 6. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 13
7. AAA Transport Considerations . . . . . . . . . . . . . . . . . 13 7. AAA Transport Considerations . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
skipping to change at page 4, line 5 skipping to change at page 4, line 5
AAA Authentication, Authorization and Accounting [RFC3588] AAA Authentication, Authorization and Accounting [RFC3588]
CAP Candidate Attachment Point [RFC5836] CAP Candidate Attachment Point [RFC5836]
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 Description
ERP/AAK is intended to allow the establishment of cryptographic ERP/AAK is intended to allow the establishment of cryptographic
keying materials on a single Candidate Attachment Points prior to the keying materials on a single Candidate Attachment Points prior to the
arrival of the MH at the Candidate Access Network (CAN). arrival of the MH at the Candidate Access Network (CAN) upon request
by the peer.
In this document, ERP/AAK support for the peer is assumed. Also it In this document, ERP/AAK support for the peer is assumed. Also it
is assumed that the peer has previously completed full EAP is assumed that the peer has previously completed full EAP
authentication and the peer or SAP knows the identities of authentication and the peer or SAP knows the identities of
neighboring attachment points. Note that the behavior of the peer neighboring attachment points. Note that the behavior of the peer
that does not support the ERP-AAK scheme defined in this that does not support the ERP-AAK scheme defined in this
specification is out of the scope of this document.Figure 1 shows the specification is out of the scope of this document.Figure 1 shows the
general protocol exchange by which the keying material is established general protocol exchange by which the keying material is established
on the CAP. on the CAP.
skipping to change at page 5, line 51 skipping to change at page 5, line 51
RFC5296 and used to protect the integrity of the message. The RFC5296 and used to protect the integrity of the message. The
sequence number is used for replay protection. sequence number is used for replay protection.
The SAP SHOULD verify the integrity of the message at step b. If The SAP SHOULD verify the integrity of the message at step b. If
This verifications fail, the SAP MUST send an EAP- Finish/Re-auth This verifications fail, the SAP MUST send an EAP- Finish/Re-auth
message with the Result flag set to '1' (Failure).In success case, message with the Result flag set to '1' (Failure).In success case,
the SAP SHOULD encapsulate the early-authentication message into a the SAP SHOULD encapsulate the early-authentication message into a
AAA message and send it to the peer's ERP/AAK server in the realm AAA message and send it to the peer's ERP/AAK server in the realm
indicated in the keyName-NAI field (see c. in the figure 1). indicated in the keyName-NAI field (see c. in the figure 1).
Upon receiving the message, the ERP/AAK server first uses the keyName Upon receiving the message, the ERP/AAK server MUST first use the
indicated in the keyName-NAI to look up the rIK and checks the keyName indicated in the keyName-NAI to look up the rIK and MUST
integrity and freshness of the message, then verifies the identity of check the integrity and freshness of the message. Then the ERP/AAK
the peer by checking the username portion of the KeyName-NAI. If any server MUST verify the identity of the peer by checking the username
of the checks fail, the server SHOULD send an early- authentication portion of the KeyName-NAI. If any of the checks fail, the server
finish message (EAP-Finish/Re-auth with E-flag set) with the Result MUST send an early- authentication finish message (EAP-Finish/Re-auth
flag set to '1'. Next, the server SHOULD authorize the CAP specified with E-flag set) with the Result flag set to '1'. Next, the server
in the CAP-Identifier TLV. In success case, the server derives a MUST authorize the CAP specified in the CAP-Identifier TLV. In
pMSK from the pRK for each CAP carried in the the CAP-Identifier success case, the server MUST derive a pMSK from the pRK for each CAP
field using the sequence number associated with CAP-Identifier as an carried in the the CAP-Identifier field using the sequence number
input to the key derivation. (see d. in the figure 1) associated with CAP-Identifier as an input to the key derivation.
(see d. in the figure 1)
Then The ERP/AAK server transports the pMSK to the authorized CAP via Then The ERP/AAK server MUST transport the pMSK to the authorized CAP
AAA Section 7 as described in figure 2 (see e.1,e.2 in the figure 2). via AAA Section 7 as described in figure 2 (see e.1,e.2 in the figure
Note that key distribution in the figure 2 is one part of step d. in 2). Note that key distribution in the figure 2 is one part of step
the figure 1. d. in the figure 1.
Finally, in response to the EAP-Initiate/Re-auth message, the ERP/AAK Finally, in response to the EAP-Initiate/Re-auth message, the ERP/AAK
server sends the early-authentication finish message (EAP-Finish/ server SHOULD send the early-authentication finish message (EAP-
Re-auth with E-flag set) containing the identity of the authorized Finish/ Re-auth with E-flag set) containing the identity of the
CAP to the peer via the SAP and associated lifetime of pMSK, authorized CAP to the peer via the SAP and associated lifetime of
Optionally, if the peer also requests the server for the rRK pMSK, OPTIONALLY, if the peer also requests the server for the rRK
lifetime, the EA server SHOULD send the rRK lifetime in the EAP- lifetime, the ERP/AAK server SHOULD send the rRK lifetime in the EAP-
Finish/Re-auth message. (see f.,g. in the figure 1). Finish/Re-auth message. (see f.,g. in the figure 1).
4. ERP/AAK Key Hierarchy 4. ERP/AAK Key Hierarchy
As an extension of ERP, ERP/AAK uses a key hierarchy similar to that As an extension of ERP, ERP/AAK uses a key hierarchy similar to that
of ERP. The ERP/AAK pre-established Root Key (pRK) is derived from of ERP. The ERP/AAK pre-established Root Key (pRK) is derived from
either EMSK or DSRK as specified in the section 4.1. In general, the either EMSK or DSRK as specified in the section 4.1. In general, the
pRK is derived from the EMSK in case of the peer moving in the home 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 in a AAA realm and derived from the DRSK in case of the peer moving in a
visited realm. The DSRK is delivered from the EAP server to the ERP/ visited realm. The DSRK is delivered from the EAP server to the ERP/
skipping to change at page 8, line 43 skipping to change at page 8, line 43
TVs and TLVs TVs and TLVs
CAP-Identifier: Carried in a TLV payload. The format is identical to CAP-Identifier: Carried in a TLV payload. The format is identical to
that of a DiameterIdentity [RFC3588]. It is used by the SAP to that of a DiameterIdentity [RFC3588]. It is used by the SAP to
advertise the identity of the CAP to the peer. Exactly one CAP- advertise the identity of the CAP to the peer. Exactly one CAP-
Identifier TLV MAY be included in the EAP-Initiate/Re-auth-Start Identifier TLV MAY be included in the EAP-Initiate/Re-auth-Start
packet if the SAP has performed CAP discovery. packet if the SAP has performed CAP discovery.
If the EAP-Initiate/Re-auth-Start packet is not supported by the If the EAP-Initiate/Re-auth-Start packet is not supported by the
peer, it is discarded silently. peer, it SHOULD be discarded silently.
5.2. EAP-Initiate/Re-auth Packet and TLV Extension 5.2. EAP-Initiate/Re-auth Packet and TLV Extension
Figure 6 illustrates the changed parameters contained in the EAP- Figure 6 illustrates the changed parameters contained in the EAP-
Initiate/Re-auth packet defined in RFC 5296 [RFC5296]. Initiate/Re-auth packet defined in RFC 5296 [RFC5296].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length | | Code | Identifier | Length |
skipping to change at page 9, line 42 skipping to change at page 9, line 42
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 to identify the peer. The realm part of the NAI is the peer's used to identify the peer. The realm part of the NAI is the peer's
home domain name if the peer communicates with the home EA server or home domain name if the peer communicates with the home EA server or
the domain to which the peer is currently attached (i.e., local the domain to which the peer is currently attached (i.e., local
domain name) if the peer communicates with the local EA server. The domain name) if the peer communicates with the local EA server. The
SAP knows if the KeyName-NAI carry local domain name by comparing the SAP knows whether the KeyName-NAI carries the local domain name by
domain name carried in KeyName-NAI with local domain name which is comparing the domain name carried in KeyName-NAI with local domain
associated with the SAP and SAP has already known. Exactly one name which is associated with the SAP and SAP has already known.
keyName-NAI attribute SHALL be present in an EAP-Initiate/Re-auth Exactly one keyName-NAI attribute SHALL be present in an EAP-
packet and The realm part of it SHOULD follows the use of Initiate/Re-auth packet and The realm part of it SHOULD follows the
internationalized domain names defined in the RFC5890 [RFC5890]. use of internationalized domain names defined in the RFC5890
[RFC5890].
CAP-Identifier: Carried in a TLV payload.The Type is TBD (less than CAP-Identifier: Carried in a TLV payload.The Type is TBD (less than
128). This field is used to indicate the FQDN of a CAP. The value 128). This field is used to indicate the FQDN of a CAP. The value
field MUST be encoded as specified in Section 8 of RFC 3315 field MUST be encoded as specified in Section 8 of RFC 3315
[RFC3315]. There at least one instance of the CAP-Identifier TLV [RFC3315]. There at least one instance of the CAP-Identifier TLV
MUST be present in the ERP/AAK-Key TLV. MUST be present in the ERP/AAK-Key TLV.
Sequence number: The Type is TBD (less than 128). The value field is Sequence number: The Type is TBD (less than 128). The value field is
a 16-bit field and used in the derivation of the pMSK for a CAP. If a 16-bit field and used in the derivation of the pMSK for a CAP. If
multiple CAP-Identifiers are carried,each CAP-Identifier in the multiple CAP-Identifiers are carried,each CAP-Identifier in the
packet MUST be associated with a unique sequence number and followed packet MUST be associated with a unique sequence number and followed
by that sequence number. by that sequence number.
Cryptosuite Cryptosuite
skipping to change at page 10, line 27 skipping to change at page 10, line 29
the SHA-256 function [RFC4868] and with the 256 bit key length and the SHA-256 function [RFC4868] and with the 256 bit key length and
output truncated to 128 bits [RFC2104]. We specify some cryptosuites output truncated to 128 bits [RFC2104]. We specify some cryptosuites
below: below:
0~1 RESERVED 0~1 RESERVED
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 REQUIRED to implement and SHOULD be enabled in the
the default configuration. default configuration.
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 value field is excluding the authentication tag field itself. The value field is
calculated using the integrity algorithm indicated in the Cryptosuite calculated using the integrity algorithm indicated in the Cryptosuite
field and rIK specified in [RFC5296] as the secret key. The length field and rIK specified in [RFC5296] as the secret key. The length
of the field is indicated by the Cryptosuite. of the field is indicated by the Cryptosuite.
The peer uses authentication tag to determine the validity of the The peer uses authentication tag to determine the validity of the
EAP-Finish/Re-auth message originates at a server. EAP-Finish/Re-auth message originates at a server.
If the message doesn't pass verification or authentication tag is not If the message doesn't pass verification or authentication tag is not
included in the message, the message SHOULD be discarded silently. included in the message, the message SHOULD be discarded silently.
If the EAP-Initiate/Re-auth packet is not supported by the SAP, it is If the EAP-Initiate/Re-auth packet is not supported by the SAP, it
discarded silently. SHOULD be discarded silently.
5.3. EAP-Finish/Re-auth packet and TLV extension 5.3. EAP-Finish/Re-auth packet and TLV extension
Figure 7 shows the changed parameters contained in the EAP-Finish/ Figure 7 shows the changed parameters contained in the EAP-Finish/
Re-auth packet defined in [RFC5296]. Re-auth packet defined in [RFC5296].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length | | Code | Identifier | Length |
skipping to change at page 11, line 37 skipping to change at page 11, line 37
SEQ SEQ
As defined in Section 5.3.2 of [RFC5296], this field is 16-bit As defined in Section 5.3.2 of [RFC5296], this field is 16-bit
sequence number and used for replay protection. sequence number and 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 realm part of the NAI is the home domain exceeding 253 octets. Exactly one keyName-NAI attribute SHALL be
name. Exactly one keyName-NAI attribute SHALL be present in an EAP- present in an EAP-Finish/Re-auth packet.
Finish/Re-auth packet.
ERP/AAK-Key: Carried in a TLV payload for the key container. The ERP/AAK-Key: Carried in a TLV payload for the key container. The
type is TBD. Exactly one ERP/AAK-key SHALL only be present in an type is TBD. Exactly one ERP/AAK-key SHALL only be present in an
EAP-Finish/Re-auth packet. EAP-Finish/Re-auth packet.
ERP/AAK-Key ::= ERP/AAK-Key ::=
{ sub-TLV: CAP-Identifier } { sub-TLV: CAP-Identifier }
{ sub-TLV: pMSK-lifetime } { sub-TLV: pMSK-lifetime }
{ sub-TLV: pRK-lifetime } { sub-TLV: pRK-lifetime }
{ sub-TLV: Cryptosuites } { sub-TLV: Cryptosuites }
skipping to change at page 15, line 33 skipping to change at page 15, line 33
o ERP/AAK-Key: This is a TLV payload. The type is 8. o ERP/AAK-Key: This is a TLV payload. The type is 8.
o pRK Lifetime: This is a TLV payload. The type is 9. o pRK Lifetime: This is a TLV payload. The type is 9.
o pMSK Lifetime: This is a TLV payload. The type is 10. o pMSK Lifetime: This is a TLV payload. The type is 10.
This document reuses the crytosuites we have already created for 'Re- This document reuses the crytosuites we have already created for 'Re-
authentication Cryptosuites' in [RFC5296]. authentication Cryptosuites' in [RFC5296].
Further, this document registers a Early authentication usage label Further, this document instructs IANA to add a new label in the User
from the "USRK Key Labels" name space with a value: Specific Root Keys (USRK) Key Labels of the Extended Master Session
Key (EMSK) Parameters registry, as follows:
EAP Early-Authentication Root Key@ietf.org EAP Early-Authentication Root Key@ietf.org
10. Acknowledgement 10. Acknowledgement
In writing this document, Yungui Wang contributed to early versions In writing this document, Yungui Wang contributed to early versions
of this document and we have received reviews from many experts in of this document and we have received reviews from many experts in
the IETF, including Tom Taylor, Tena Zou, Tim Polk, Tan Zhang and the IETF, including Tom Taylor, Tena Zou, Tim Polk, Tan Zhang and
Semyon Mizikovsky, Stephen Farrell,Sujing Zhou. We apologize if we Semyon Mizikovsky, Stephen Farrell,Sujing Zhou. We apologize if we
miss some of those who have helped us. miss some of those who have helped us.
 End of changes. 17 change blocks. 
43 lines changed or deleted 47 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/