1 IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: EAP Pre-authentication Problem Statement in IETF HOKEY WG Date Submitted: September, 14th, 2007 Presented at IEEE session #22 in Hawaii Authors or Source(s): Yoshihiro Ohba Abstract: This document explains EAP pre-authentication activity in IETF HOKEY WG. This document also describes high-level issues that need to be discussed in the Security SG about pre-authentication

2 IEEE presentation release statements This document has been prepared to assist the IEEE Working Group. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual and in Understanding Patent Issues During IEEE Standards Development Section 6.3 of the IEEE-SA Standards Board Operations Manualhttp://standards.ieee.org/guides/opman/sect6.html#6.3 IEEE presentation release statements This document has been prepared to assist the IEEE Working Group. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE The contributor is familiar with IEEE patent policy, as stated in Section 6 of the IEEE-SA Standards Board bylaws and in Understanding Patent Issues During IEEE Standards Development Section 6 of the IEEE-SA Standards Board bylawshttp://standards.ieee.org/guides/bylaws/sect6-7.html#6

3 Outline Introduction of IETF HOKEY activity about EAP pre-authentication – –The content of the preauth-ps draft is explained in this presentation Pre-authentication-related issues that need to be discussed in SSG

4 EAP pre-authentication Definition [I-D.ietf-eap-keying-15] “ The use of EAP to pre-establish EAP keying material on an authenticator prior to arrival of the peer at the access network managed by that authenticator ” Example usage of EAP pre-authentication: IEEE i pre-authentication –Defined for intra-ESS transitions

5 Scenario 1: Direct Pre-authentication mobile host Candidate Authenticator (CA) home AAA server Serving network Candidate Network home network Internet - Generate MSK with the authenticator-2 by executing EAP through it. MN-CA Signaling EAP over L2 or L3 EAP over AAA

6 Scenario 2: Indirect Pre-authentication mobile host Serving Authenticator (SA) Candidate Authenticator (CA) home AAA server Serving Network Candidate Network home network Internet - Generate MSK with the authenticator-2 by executing EAP through it. EAP over AAA MN-SA signaling EAP over L2/L3 SA-CA signaling EAP over L3

7 Indirect Pre-authentication Layering Model MN-SA Signaling Layer MN-SA Signaling Layer SA-CA Signaling Layer SA-CA Signaling Layer EAP Peer EAP Authenticator Pre-authentication Forwarding Candidate Authenticator Serving Authenticator Mobile Node

8 Pre-authentication AAA Requirements AAA requirements related to EAP pre-authentication need to be identified (See draft-nakhjiri-preauth-aaa-req-00 for details) –Distinguishing normal authentication from pre-authentication –Pre-authentication life-time –Re-pre-authentication –Post handover procedure –Session resumption or key caching –Multiple pre-authentication –Provisioning of serving network information –Network-controlled pre-authentication AAA requirements may affect MN-CA, MN-SA and SA- CA signaling design

9 HOKEY Charter in pre-authentication “EAP re-authentication and EAP pre- authentication authenticator are expected to use the same layer and the same protocol as the original EAP authentication used for the authenticator.” Reason for this restriction: Inter-technology pre- authentication has technical issues that need to be studied –Authenticator discovery –Context binding

10 Pre-authentication issue 1: Authenticator discovery In general, pre-authentication requires an address of a target authenticator to be discovered either by a mobile node or by a serving authenticator prior to handover An authenticator discovery protocol is typically defined as a separated protocol from a pre-authentication protocol When a target authenticator uses link-layer EAP transport for both normal authentication and pre-authentication, target authenticator discovery is typically defined in each link-layer technology –E.g., k and e For other cases, a mechanism for discovering an IP address of target authenticator is needed –(IP address, link-layer address) mapping needs to be resolved

11 Pre-authentication issue 2: Context binding A mechanisms is needed to bind link-layer independent context carried over pre-authentication signaling to the link-layer specific context of the link to be established between the mobile node and the target authenticator –Link-layer independent context: the identities of peer and authenticator as well as MSK –Link-layer specific context: link-layer addresses of peer and target authenticator. Two possible approaches to address the context binding issue –Approach 1: communicating the lower-layer context as opaque data via pre-authentication signaling –Approach 2: use of normal EAP authentication after handover with using the same link-layer independent context for both pre-authentication and normal authentication

12 Pre-authentication applicability (quote from I-D.hokey-preauth-ps) “This framework has general applicability to various deployment scenarios in which proactive signaling can take effect. In other words, applicability of EAP pre- authentication is limited to the scenarios where candidate authenticators can be easily discovered, an accurate prediction of movement can be easily made.” “Also the effectiveness of EAP pre-authentication may be less significant for particular inter-technology handover scenarios where simultaneous use of multiple technologies is not a major concern or where there is sufficient radio- coverage overlap among different technologies.”

13 Pre-authentication protocol work IETF HOKEY WG has decided to focus on pre- auth problem statement and not to work on actual pre-authentication protocol –L2-agnostic pre-authentication protocol is to be defined in IETF PANA WG is defining pre-authentication extension for PANA There is no context binding issue because there is no link-layer specific context –L2-aware pre-authentication protocol should be defined outside IETF IEEE may define it, with addressing authenticator discovery and context binding issues –Defining new AAA attributes for pre-auth should be done in IETF DIME and RADEXT WGs

14 High-level questions for Should a pre-authentication protocol be defined in ? Should work on an EAP pre- authentication only or non-EAP pre- authentication as well?