2006/7/10IETF66 RADEXT WG1 Pre-authentication AAA Requirements Yoshihiro Ohba Alper Yegin

2006/7/10IETF66 RADEXT WG2 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 i where the usage is intra-ESS transitions HOAKEY BOF (held in IETF65 and to be held in IETF66) is extending the notion of pre- authentication to work across multiple ESS ’ s and even across multiple access technologies

2006/7/10IETF66 RADEXT WG3 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

2006/7/10IETF66 RADEXT WG4 Other potential pre-authentication AAA requirements/issues

2006/7/10IETF66 RADEXT WG5 Extending pre-auth session lifetime Pre-authentication session lifetime may need to be extended –The MN may continue to stay in the serving network or move to some other network, while maintaining the pre-authentication session with a target authenticator Maximum pre-auth session lifetime may need to be defined in order to avoid unlimited attempts for extending pre-auth session lifetime - Is this a AAA protocol issue or a configuration issue?

2006/7/10IETF66 RADEXT WG6 Reverting to pre-auth state from full authorized state A session with a fully authorized state may need to be changed to a pre-auth state –This can happen when MN moves from network N1 to network N2, and goes back to N1 –MN may not want to perform pre-authentication again with N1 –Is this the same as key caching issue? Key caching lifetime management is not fully studied A complete solution for pre-authentication may solve key caching lifetime management issue as well

2006/7/10IETF66 RADEXT WG7 Maximum number of pre-auth sessions for different authenticators How many pre-authentication sessions for different authenticators are allowed per MN? Is this a AAA protocol issue or a configuration issue? –This may be a AAA protocol issue for indirect pre-authentication in which the serving authenticator is involved in pre-auth signaling

2006/7/10IETF66 RADEXT WG8 Information on the serving network AAA server may need information on the serving network from which a pre- authentication attempt is being made This information may affect the authorization decision made by AAA server This may apply to normal authentication and handover keying signaling as well

2006/7/10IETF66 RADEXT WG9 Calling-Station-Id What should Calling-Station-Id be in the case of inter-technology pre-authentication? –Should it be the MN’s address used for the serving network? In this case, a Calling-Station-Id may dynamically change if MN handovers to a new nerving network and still maintains the pre-authentication state with the target network –Should it be the MN’s address to be used for the target network? –Should it be null?

2006/7/10IETF66 RADEXT WG10 Network-initiated pre-authentication Are new AAA attributes needed to support network-initiated pre-authentication? –E.g., list of neighboring authenticators around the serving authenticator

2006/7/10IETF66 RADEXT WG11 Summary Pre-authentication for inter-technology handover requires thorough requirements work on both AAA and EAP lower-layer signaling –Pre-authentication is one work item of HOAKEY BOF