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

2. 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).

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

4. 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

5. 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

6. 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

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

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

9. 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.

10. 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.

11. 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.

12. 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 }

13. 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.

14. 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.

15. 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.

16. Security Consideration
TBD

17. Thanks

18. 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