Pre-authentication Problem Statement (draft-ohba-hokeyp-preauth-ps-00 Pre-authentication Problem Statement (draft-ohba-hokeyp-preauth-ps-00.txt) Yoshihiro Ohba (yohba@tari.toshiba.com) Ashutosh Dutta (adutta@research.telcordia.com) Srinivas Sreemanthula (Srinivas.Sreemanthula@nokia.com) Alper Yegin (alper01.yegin@partner.samsung.com) Jul 13, 2006 IETF66 HOAKEY BOF

What is pre-authentication Pre-authentication is network access authentication by performing EAP authentication with a target authenticator via the serving network Pre-authentication was originally defined in IEEE 802.11i where the usage is intra-ESS transitions We are extending the notion of pre-authentication to work across multiple ESS’s and even across multiple access technologies

Expected Improvement with Pre-authentication Network access Authentication and Authorization L2 Handoff Without Pre-authentication Time With Pre-authentication Time Network access Authentication and Authorization with Pre-authentication Possible packet loss or interface activation delay during this period

Scenario 1: Direct Pre-authentication Serving network home network mobile host MN-TA Signaling EAP over L2 (for intra-technology, Intra-subnet pre-authentication) EAP over L3 (for other cases) Internet home AAA server EAP over AAA Target Network Target Authenticator (TA) - Generate MSK with the authenticator-2 by executing EAP through it.

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

Basic pre-auth AAA requirements Requirements identified in IETF65 HOAKEY BOF AAA needs to know that this is a pre-authentication not normal authentication User may only be allowed to have a single logon at the same time User may not be allowed pre-authentication Can pre-auth session timeout (see below) attribute serve as an indication of pre-auth or some other attribute is needed? AAA needs to know how long to hold the session before timing out Session timeout for pre-auth may be different for normal session If the mobile moves after timeout then do normal authentication Addressed in draft-aboba-radext-wlan-03.txt What would signal that the host has successfully connected to a target network? Another round of (non-blocking) Access-Req/Accept? Or do we rely on accounting messages? If latter, then they must be mandated for pre-auth case

Other potential pre-auth AAA requirements/issues (presented to RADEXT WG) Extending pre-auth session lifetime Reverting to pre-auth state from full authorized state (related to key caching) Maximum number of pre-auth sessions for different authenticators Information on the serving network Calling-Station-Id Network-initiated pre-authentication Detailed issues are available at: http://www.opendiameter.org/docs/ietf66-radext-preauth-aaa-reqs.ppt

Scope of the pre-authentication work “This group will work on pre-authentication signaling requirements including MN-TA signaling, MN-SA signaling and SA-TA signaling and new or existing attributes of AAA protocols” (from HOKEYP charter http://www.opendiameter.org/pipermail/hokeyp/2006-May/000142.html) Possible work separation: AAA signaling: RADEXT and DIME WGs MN-TA, MN-SA signaling : PANA WG (for L3), L2 SDO (for L2) SA-TA signaling: new IETF WG

Deliverables Pre-authentication problem statement draft (Informational) This draft is intended for detailed problem definition and usage scenarios for pre-authentication. [draft-ohba-hokeyp-preauth-ps-00.txt will be used as the baseline.] Pre-authentication protocol requirements draft (Informational) Requirements of new protocols or new options/attributes for existing protocols for enabling a target authenticator to authenticate the peer attached to the serving network using EAP. The requirements are for both pre-authentication protocols and AAA protocols. Following completion of requirements definitions for a pre-authentication procedure, this group will continue with developing a solution for some portion of pre-authentication signaling if it is identified that the solution needs to be defined in the group

High-Level Requirements on pre-authentication Inter-technology pre-authentication MUST be supported. Inter-subnet pre-authentication MUST be supported. Inter-administrative domain pre-authentication MUST be supported. Direct pre-authentication MUST be supported. Indirect pre-authentication MUST be supported Pre-authentication MUST work with RADIUS and Diameter