1 / 18

ERP extension for EAP Early-authentication Protocol (EEP)

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

tryna
Download Presentation

ERP extension for EAP Early-authentication Protocol (EEP)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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.

  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. 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 SA CA1 CAx EE Server Peer 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 SA CA1 CAx Server Peer 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 http://www.ietf.org

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

More Related