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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |R|x|L|E|Resved |             SEQ               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 1 or more TVs or TLVs                         ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptosuite  |         Authentication Tag                     ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 7

Figure 7 shows the changed parameters contained in the EAP-Finish/Re-auth packet defined in [RFC5296].

Flags

'x' – The x flag is reserved. It MUST be set to 0.

‘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 reception.

SEQ

As defined in Section 5.3.2 of [RFC5296], this field is 16-bit sequence number and used for replay protection.

TVs and TLVs

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 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-Finish/Re-auth packet.

ERP/AAK-Key ::= 
     { sub-TLV: CAP-Identifier }
     { sub-TLV: pMSK-lifetime }
     { sub-TLV: pRK-lifetime }
     { sub-TLV: Cryptosuites }

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 EAP-Finish/Re-auth packet.

CAP-Identifier

Carried in a sub-TLV payload. The Type is TBD (less than 128). This field is used to indicate the identifier of the candidate authenticator. The value field MUST be encoded as specified in Section 8 of RFC 3315 [RFC3315]. There at least one instance of the CAP-Identifier TLV MUST be present in the ERP/ AAK-Key TLV.

pMSK-lifetime

Carried in a sub-TLV payload of EAP-Finish/Re-auth message. The Type is TBD. The value field is an unsigned 32-bit field and contains the lifetime of the pMSK in seconds. This value is calculated by the server after pRK-lifetime computation upon receiving EAP-Initiate/Re-auth message. The rIK SHOULD share the same lifetime as pMSK.If the 'L' flag is set, the pMSK-Lifetime attribute MUST be present.

pRK-lifetime

Carried in a sub-TLV payload of EAP-Finish/Re-auth message. The Type is TBD. The value field is an unsigned 32-bit field and contains the lifetime of the pRK in seconds. This value is calculated by the server before pMSK-lifetime computation upon receiving EAP-Initiate/Re-auth message. If the 'L' flag is set, the pRK-Lifetime attribute MUST be present.

List of Cryptosuites

Carried in a sub-TLV payload. The Type is 5 [RFC5296]. The value field contains a list of cryptosuites (at least one cryptosuite SHOULD be included), each 1 octet in length. The allowed cryptosuite values are as specified in Section 5.2, 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 include this attribute in other cases. The server MAY use this attribute to signal to the peer about its cryptographic algorithm capabilities.

Cryptosuite

This field indicates the integrity algorithm and PRF used for ERP/ AAK. HMAC-SHA256-128 is mandatory to implement and should be enabled in the default configuration. Key lengths and output lengths are either indicated or obvious from the cryptosuite name.

Authentication Tag

This field contains the integrity checksum over the ERP/AAK packet, excluding the authentication tag field itself. The value field is calculated using the integrity algorithm indicated in the Cryptosuite field and rIK [RFC5296] as the integrity key. The length of the field is indicated by the corresponding Cryptosuite.

The peer uses authentication tag to determine the validity of the EAP-Finish/Re-auth message originates at a server.

If the message doesn't pass verification or authentication tag is not 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 discarded silently.

5.4. TV and TLV Attributes

With the exception of the rRK-Lifetime and rMSK-Lifetime TV payloads, 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:

• Sequence number: This is a TV payload. The type is TBD.
• ERP/AAK-Key: This is a TLV payload. The type is TBD.
• pRK-Lifetime: This is a TV payload. The type is TBD.
• pMSK-Lifetime: This is a TV payload. The type is TBD.
• List of Cryptosuites: This is a TLV payload. The type is TBD.

6. Lower Layer Considerations

Similar to ERP, some lower layer specifications may need to be revised to support ERP/AAK; refer to of Section 6 [RFC5296] for additional guidance.

7. AAA Transport Considerations

AAA transport of ERP/AAK messages is the same as AAA transport of the ERP message [RFC5296]. In addition, the document requires AAA transport of the ERP/AAK keying materials delivered by the ERP/AAK server to the CAP. Hence, a new AAA message for ERP/AAK application should be specified to transport the keying materials.

8. Security Considerations

This section provides an analysis of the protocol in accordance with the AAA key management requirements specified in RFC 4962 [RFC4962].

• Cryptographic algorithm independence: ERP-AAK satisfies this requirement. The algorithm chosen by the peer for calculating the authentication tag 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.
• 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.
• Limit key scope: The scope of all the keys derived by ERP-AAK is well defined. The pRK is used to derive the pMSK for the CAP. Different sequence numbers for each CAP MUST be used to derive a unique pMSK.
• Replay detection mechanism: For replay protection of ERP-AAK messages, a sequence number associated with the pMSK is used.The peer increments the sequence number by one after it sends an ERP/AAK message. The server sets the expected sequence number to the received sequence number plus one after verifying the validity of the received message and responds to the message. If multiple CAP-identifier are carried, a unique sequence number for each pMSK SHOULD be associated for each CAP-Identifier.
• 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.
• Peer and authenticator authorization: The peer and authenticator demonstrate possession of the same key material without disclosing it, as part of the lower layer secure authentication protocol.
• Keying material confidentiality: The peer and the server derive the keys independently using parameters known to each entity.
• Uniquely named keys: All keys produced within the ERP context can be referred to uniquely as specified in this document.
• 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.
• Bind key to its context: the pMSK are bound to the context in which the sequence numbers are transmitted.
• Confidentiality of identity: this is the same as with the ERP protocol [RFC5296].
• 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 to be used 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

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.
with the following assigned number:

• Sequence number: This is a TV payload. The type is 7.
• ERP/AAK-Key: This is a TLV payload. The type is 8.
• pRK Lifetime: This is a TLV payload. The type is 9.
• pMSK Lifetime: This is a TLV payload. The type is 10.

This document reuses the crytosuites we have already created for 'Re-authentication Cryptosuites' in [RFC5296].

Further, this document registers a Early authentication usage label from the "USRK Key Labels" name space with a value:

• EAP Early-Authentication Root Key@ietf.org

10. Acknowledgement

In writing this document, Yungui Wang contributed to early versions of this document and we have received reviews from many experts in the IETF, including Tom Taylor, Tena Zou, Tim Polk, Tan Zhang and Semyon Mizikovsky, Stephen Farrell,Sujing Zhou. We apologize if we miss some of those who have helped us.

11. References

11.1. Normative References

[RFC2119]	Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5296]	Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re-authentication Protocol (ERP)", RFC 5296, August 2008.
[RFC3315]	Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC5295]	Salowey, J., Dondeti, L., Narayanan, V. and M. Nakhjiri, "Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)", August 2008.

11.2. Informative References

[RFC5836]	Ohba, Y., Wu, Q. and G. Zorn, "Extensible Authentication Protocol (EAP) Early Authentication Problem Statement", RFC 5836, April 2010.
[RFC2104]	Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC4868]	Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.
[RFC5890]	Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[I-D.ietf-dime-local-keytran]	Zorn, G, Wu, W and V Cakulev, "Diameter Attribute-Value Pairs for Cryptographic Key Transport", Internet-Draft draft-ietf-dime-local-keytran-14, August 2011.
[RFC3588]	Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3748]	Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, "Extensible Authentication Protocol (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.

Authors' Addresses