ERP extension for EAP Early-authentication Protocol (EEP) Denghui, Qin Wu,Yungui Wang IETF 76 Hiroshima, Japan November 08-13, 2009

Motivation This document is intended to propose to extend the ERP for EAP Early-authentication that is used to delivery keying materials to the target authenticator(s) prior to arrival of the peer. Assumption: The serving authenticator is unaware of the target authenticator (s).

Overview This document mostly reflects the “authenticated anticipatory keying usage model” defined in section 6.2 of [draft-ietf-hokey-preauth-ps-09].

pMSK: pre-established MSK for EAP Early-authentication Overview Peer: CA Discovery (out of scope of this document); Initiate the EAP Early-authentication exchange; SA: Serving Authenticator Trigger the EAP Early-authentication exchange; Forward the EAP Early-authentication messages transparently; CA: Candidate Authenticator Receive the EE keying materials (pMSK, etc.) from EE server; EE (EAP Early-authentication) Server: Authenticate and Authorize the CA (s) through channel binding mechanism [draft-ietf-emu-chbind]; Derive and transport the EE keying materials to CA (s); EE server is collocated with the peer’s home AAA server. pMSK: pre-established MSK for EAP Early-authentication

Informational Flow Peer SA CA1 CAx EE Server 1. CA Discovery 2. EAP-Initiate/Early-auth-Start 3. EAP-Initiate/Early-auth (CA List) 4. AAA (EAP-Initiate/Early-auth (CA List)) One or more than one CA is authorized and authenticated

Informational Flow Peer SA CA1 CAx Server 5. EE keying materials derived 6. AAA (pMSK) pMSK1 pMSK x pMSK1...x 7. AAA (EAP-Finish/Early-auth) 8. EAP-Finish/Early-auth pMSK: pre-established MSK for EAP Early-authentication

EEP re-uses ERP Packets EAP-Initiate/re-auth-Start EAP-Initiate/re-auth EAP-Finish/re-auth

EAP-Initiate/re-auth-Start Type: re-auth-Start New Flag ‘E’, to indicate early-authentication.

EAP-Initiate/Early-auth Type: re-auth-Start New Flag: ‘E' - to indicate early-authentication. NOTE: ‘B’ flag is not retained due to without bootstrapping in EEP.

New TLV: NAS-Identifier: As defined in [RFC5296], it is carried in a TLV payload. Here, the Type is TBD. It is used to indicate the identifier of CA. One or more than one NAS-Identifier may be represented in the EAP-Initiate/Early-auth packet.

EAP-Finish/Early-auth Type: re-auth New Flag: ‘E' - to indicate early-authentication. NOTE: ‘B’ flag is not retained due to without bootstrapping in EEP.

New TLV: EEP-Key: It is carried in a TLV payload for the key container. The type is TBD. One or more than one EEP-key may be present in an EAP-Finish/Early-auth packet. EEP-Key ::= { sub-TLV: NAS-Identifier } { sub-TLV: pMSK-lifetime } { sub-TLV: pRK-lifetime } { sub-TLV: Cryptosuites }

Sub-TLVs: NAS-Identifier: It is carried in a sub-TLV payload. The Type is tbd. It is used to indicate the identifier of candidate authenticator. There is exact one NAS-Identifier is represent in the EEP-Key. pMSK-lifetime: It is carried in a sub-TLV payload. The Type is TBD. The value field is a 32-bit field and contains the lifetime of the pMSK in 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 TBD. The value field is a 32-bit field and contains the lifetime of the pRK in seconds. 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. The value field contains a list of cryptosuites, each of size 1 octet. The cryptosuite values are as specified in Figure 3. The server SHOULD include this attribute if the cryptosuite used in the EAP-Initiate/Early-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.

Lower Layer Consideration Similar to ERP, the lower layer specifications may need to be revised to support EEP. That can be referred to the section 6 of [RFC5296] for additional guidance.

AAA Transport AAA transport of EEP message is the same specified as ERP [RFC5296] as well. However, in the document, AAA transport of the EEP message is separated from AAA transport of the EE keying materials which is delivered from the EAP server to the CA(s). Hence, new Diameter EEP application message and new Radius EEP message should be defined to transport EE keying materials.

Security Consideration TBD

Thanks http://www.ietf.org

Appendix A: after handover Peer SA CA1 CAx Server 9. CA selection 10. pMSK generation 11. Attachment 12. AAA user session update 13. Session Abort Request