draft-ietf-hokey-erp-aak-05.txt   draft-ietf-hokey-erp-aak-06.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: March 17, 2012 Y. Wang Expires: April 20, 2012 Y. Wang
Q. Wu Q. Wu
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
G. Zorn G. Zorn, Ed.
Network Zen Network Zen
September 14, 2011 October 18, 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-05 draft-ietf-hokey-erp-aak-06
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.
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 upon one or more
upon one or more candidate attachment points (CAPs). AAK uses the candidate attachment points (CAPs) prior to handover. AAK uses the
AAA 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 March 17, 2012. This Internet-Draft will expire on April 20, 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 2, line 32 skipping to change at page 2, line 32
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 . . . . . . . . . . . . . . . 8
5.4. TV/TLV and sub-TLV Attributes . . . . . . . . . . . . . . 10 5.4. TV and 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 . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative 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
skipping to change at page 4, line 9 skipping to change at page 4, line 9
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 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). The arrival of the MH at the Candidate Access Network (CAN).
document also specifies a method by which the SAP may send the
identities of neighboring attachment points to the peer in the EAP-
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 and the peer or SAP knows the identities of
which the keying material is established on the CAP. This document neighboring attachment points. Figure 1 shows the general protocol
only discusses the case of distributing the key to a single CAP. exchange by 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 | | Peer | | SAP | | CAP | | EA Server |
+--+---+ +--+--+ +--+--+ +-----+-----+ +--+---+ +--+--+ +--+--+ +-----+-----+
| | | | | | | |
1. | [EAP-Initiate/ | | | 1. | [EAP-Initiate/ | | |
| Re-auth-start | | | | Re-auth-start | | |
| (E-flag) | | | | (E-flag) | | |
|<---------------| | | |<---------------| | |
| | | | | | | |
skipping to change at page 5, line 9 skipping to change at page 5, line 7
| Re-auth(E-flag)| | | | 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, SAP support for ERP/AAK is assumed. If either the
If either the peer or the SAP does not support ERP/AAK, it should peer or the SAP does not support ERP/AAK, it should fall back to full
fall back to full EAP authentication. EAP authentication.
The SAP may send the identity of a candidate attachment point to the
peer in the EAP-Initiate/Re-auth-Start message. If the EAP-Initiate/
Re-auth-Start packet is not supported by the peer, it is silently
discarded.
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 CAP-
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 CAP-
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. the message. The sequence number is used for replay protection.
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 authorizes the CAP presented in the integrity and freshness, then verifies the identity of the peer by
NAS-Identifier TLV(s) via the NAS-Identifier. After the CAP is checking the username portion of the KeyName-NAI. Next, the server
authenticated and authorized successfully, the ERP/AAK server derives authenticates and authorizes the CAP specified in the CAP-Identifier
the pRK and the subsequent pMSK for the CAP. TLV. If any of the checks fail, the server sends an early-
authentication finish message (EAP-Finish/Re-auth with E-flag set)
with the Result flag set to '1'.
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 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 identity
determined CAP to the peer via the SAP. of the authorized 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 a key hierarchy similar to
of ERP. The EMSK is used to derive the ERP/AAK pre-established Root that of ERP. The EMSK is used to derive the ERP/AAK pre-established
Key (pRK). Similarly, the ERP/AAK pre-established Integrity Key Root 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 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
relationship is illustrated in Figure 2, below. relationship is illustrated in Figure 2, below.
DSRK EMSK DSRK EMSK
| | | |
+---+---+---+---+ +---+---+---+---+
| | | | | |
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 a visited realm. The DSRK is delivered from the EAP server to the
to the ERP/AAK server as specified in [I-D.ietf-dime-local-keytran]. ERP/AAK server as specified in [I-D.ietf-dime-local-keytran]. If the
If the peer has previously been authenticated by means of ERP or ERP/ peer has previously been authenticated by means of ERP or ERP/AAK,
AAK, the DSRK SHOULD be directly re-used. 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). The pRK is used to derive the pIK and pMSK for the CAP.
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 7, line 10 skipping to change at page 7, line 10
Figure 4 Figure 4
Flags Flags
'E' - The E flag is used to indicate early-authentication. 'E' - The E flag is used to indicate early-authentication.
Reserved: MUST be set to 0. Reserved: MUST be set to 0.
TVs and TLVs TVs and TLVs
NAS-Identifier: As defined in [RFC5296], it is carried in a TLV CAP-Identifier: Carried in a TLV payload. The format is identical to
payload. It is used by the SAP to advertise the identifier(s) of that of a DiameterIdentity [RFC3588]. It is used by the SAP to
CAP(s) to the peer. One or more NAS-Identifier TLVs MAY be included advertise the identity of the CAP to the peer. Exactly one CAP-
in the EAP-Initiate/Re-auth-Start packet if the SAP has performed CAP Identifier TLV MAY be included in the EAP-Initiate/Re-auth-Start
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 is discarded silently.
5.2. EAP-Initiate/Re-auth Packet Extension 5.2. EAP-Initiate/Re-auth Packet Extension
Figure 5 illustrates the changed parameters contained in the EAP- Figure 5 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
skipping to change at page 8, line 12 skipping to change at page 8, line 12
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 or the domain to which the peer is currently home domain name or the domain to which the peer is currently
attached. Exactly one keyName-NAI attribute SHALL be present in an attached. Exactly one keyName-NAI attribute SHALL be present in an
EAP-Initiate/Re-auth packet. EAP-Initiate/Re-auth packet.
NAS-Identifier: As defined in RFC 5296 [RFC5296], it is carried in a CAP-Identifier: Carried in a TLV payload. It is used to indicate the
TLV payload. It is used to indicate the identifier of a CAP. Though FQDN of a CAP.
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
identify multiple CAPs.
Sequence number: It is carried in a TV payload. The Type is TBD Sequence number: Carried in a TV payload. The Type is TBD (less than
(which is lower than 128). It is used in the derivation of the pMSK 128). It is used in the derivation of the pMSK for each CAP. Each
for each CAP. Each NAS-Identifier in the packet MUST be associated CAP-Identifier in the packet MUST be associated with a unique
with a unique sequence number. sequence 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 obvious from the lengths and output lengths are either indicated or obvious from 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
skipping to change at page 9, line 39 skipping to change at page 9, line 34
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[RFC5296], this is carried in a TLV keyName-NAI: As defined in RFC 5296 [RFC5296], this is carried in a
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. The realm part of the NAI is the home domain
name. Exactly one keyName-NAI attribute SHALL be present in an EAP- name. Exactly one keyName-NAI attribute SHALL be present in an EAP-
Finish/Re-auth packet. Finish/Re-auth packet.
ERP/AAK-Key: It is carried in a TLV payload for the key container. ERP/AAK-Key: Carried in a TLV payload for the key container. The
The type is TBD. One or more than one ERP/AAK-key may be present in type is TBD. Exactly one ERP/AAK-key SHALL be present in an EAP-
an EAP-Finish/Re-auth packet. Finish/Re-auth packet.
ERP/AAK-Key ::= ERP/AAK-Key ::=
{ sub-TLV: NAS-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 }
NAS-Identifier: It is carried in a sub-TLV payload. It is used to CAP-Identifier
indicate the identifier of candidate authenticator. There exactly Carried in a sub-TLV payload. It is used to indicate the
one instance of the NAS-Identifier TLV MUST be present in the ERP/ identifier of the candidate authenticator. There exactly one
instance of the CAP-Identifier TLV MUST be present in the ERP/
AAK-Key TLV. AAK-Key TLV.
pMSK-lifetime: It is carried in a sub-TLV payload. The Type is pMSK-lifetime
TBD. The value field is a 32-bit field and contains the lifetime Carried in a sub-TLV payload. The Type is TBD. The value field
of the pMSK in seconds. If the 'L' flag is set, the pMSK Lifetime is a 32-bit field and contains the lifetime of the pMSK in
attribute SHOULD be present. seconds. If the 'L' flag is set, the pMSK Lifetime attribute
SHOULD be present.
pRK-lifetime: It is carried in a sub-TLV payload. The Type is pRK-lifetime
TBD. The value field is a 32-bit field and contains the lifetime Carried in a sub-TLV payload. The Type is TBD. The value field
of the pRK in seconds. If the 'L' flag is set, the pRK Lifetime is a 32-bit field and contains the lifetime of the pRK in seconds.
attribute SHOULD be present. If the 'L' flag is set, the pRK Lifetime attribute SHOULD be
present.
List of Cryptosuites: This is a sub-TLV payload. The Type is TBD. List of Cryptosuites
The value field contains a list of cryptosuites, each 1 octet in Carried in a sub-TLV payload. The Type is 5 [RFC5296]. The value
length. The allowed cryptosuite values are as specified in field contains a list of cryptosuites, each 1 octet in length.
Section 5.2, above. The server SHOULD include this attribute if The allowed cryptosuite values are as specified in Section 5.2,
the cryptosuite used in the EAP-Initiate/Re-auth message was not above. The server SHOULD include this attribute if 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 obvious AAK. Key lengths and output lengths are either indicated or 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 and TLV Attributes
The TV and TLV attributes are the same specified as section 5.3.4 of
[RFC5296]. In this document, some new TLV(s) which may be present in
the EAP-Initiate or EAP-Finish messages are defined as below:
Sequence number - This is a TV payload. The type is TBD.
ERP/AAK-Key - This is a TLV payload. The type is TBD.
The format of sub-TLV attributes that may be present in the EAP- With the exception of the rRK Lifetime and rMSK Lifetime TV payloads,
Initiate or EAP-Finish messages is: the attributes specified in Section 5.3.4 of [RFC5296] also apply to
this document. In this document, new attributes which may be present
in the EAP-Initiate and EAP-Finish messages are defined as below:
0 1 2 3 o Sequence number: This is a TV payload. The type is TBD.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following types are defined in this document: o ERP/AAK-Key: This is a TLV payload. The type is TBD.
pRK Lifetime: This is a TV payload. The type of this sub-TLV is o pRK Lifetime: This is a TV payload. The type is TBD.
TBD.
pMSK Lifetime: This is a TV payload. The type of this sub-TLV is o pMSK Lifetime: This is a TV payload. The type is TBD.
TBD.
List of Cryptosuites: This is a TLV payload. The type of this o List of Cryptosuites: This is a TLV payload. The type is TBD.
sub-TLV is TBD.
6. Lower Layer Considerations 6. Lower Layer Considerations
Similar to ERP, some lower layer specifications may need to be Similar to ERP, some lower layer specifications may need to be
revised to support ERP/AAK; refer to section 6 of [RFC5296] for revised to support ERP/AAK; refer to of Section 6 [RFC5296] for
additional guidance. additional guidance.
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
This section provides an analysis of the protocol in accordance with This section provides an analysis of the protocol in accordance with
the AAA key management requirements specified in [RFC4962] the AAA key management requirements specified in RFC 4962 [RFC4962].
o Cryptographic algorithm independence: ERP-AAK satisfies this o Cryptographic algorithm independence: ERP-AAK satisfies this
requirement. The algorithm chosen by the peer is indicated in the requirement. The algorithm chosen by the peer is indicated in the
EAP-Initiate/Re-auth message. If the chosen algorithm is EAP-Initiate/Re-auth message. If the chosen algorithm is
unacceptable, the EAP server returns an EAP- Finish/Re-auth unacceptable, the EAP server returns an EAP- Finish/Re-auth
message with Failure indication message with Failure indication.
o Strong, fresh session keys: ERP-AAK results in the derivation of 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 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 always derived on-demand when the peer requires a key with a new
CAP. The derivation ensures that the compromise of one pMSK does CAP. The derivation ensures that the compromise of one pMSK does
not result in the compromise of a different pMSK at any time. 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 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 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 CAP. Different sequence numbers for each CAP MUST be used to
derive the unique pMSK. derive a 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 peer and authenticator o Peer and authenticator authorization: The peer and authenticator
skipping to change at page 12, line 38 skipping to change at page 12, line 24
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 bound to the context in
the sequence numbers are transmitted. which 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 as with the ERP
analyzed in [RFC5296]. protocol [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 to be used 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
IANA is requested to assign four TLV type values from the registry of
EAP Initiate and Finish Attributes maintained at
http://www.iana.org/assignments/eap-numbers/eap-numbers.xml.
New TLV types: New TLV types:
Sequence number o Sequence number
ERP/AAK-Key
New sub-TLV types: o ERP/AAK-Key
pRK Lifetime o pRK Lifetime
pMSK Lifetime o pMSK Lifetime
10. Acknowledgement 10. Acknowledgement
In writing this document, we have received reviews from many experts In writing this document, we have received reviews from many experts
in IETF, including Tom Taylor, Tena Zou, Tim Polk. We apologize if in the IETF, including Tom Taylor, Tena Zou, Tim Polk, Tan Zhang and
we miss some names that have helped us. Semyon Mizikovsky. We apologize if we miss some of those who have
helped us.
11. References 11. References
11.1. Normative 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
skipping to change at page 15, line 4 skipping to change at page 14, line 31
EMail: denghui02@gmail.com EMail: denghui02@gmail.com
Yungui Wang Yungui Wang
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
Floor 10, HuiHong Mansion, No.91 BaiXia Rd. Floor 10, HuiHong Mansion, No.91 BaiXia Rd.
Nanjing, Jiangsu 210001 Nanjing, Jiangsu 210001
P.R. China P.R. China
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: bill.wu@huawei.com EMail: bill.wu@huawei.com
Glen Zorn (editor)
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: glenzorn@gmail.com
 End of changes. 52 change blocks. 
115 lines changed or deleted 111 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/