eap Mailing List: RE: EAP, AAA and Handovers

[Narayanan Vidya-CVN065 (vidya]

Jari,
Thanks for responding. Please see some questions inline below. 

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko [at] piuha.net] 
> Sent: Monday, May 02, 2005 4:15 AM
> To: Narayanan Vidya-CVN065
> Cc: eap [at] frascone.com
> Subject: Re: [eap] EAP, AAA and Handovers
> 
> 
> Narayanan Vidya-CVN065 wrote:
> 
> > All,
> > There has been discussion on handovers and EAP lately on 
> the list, so
> > I thought I'd post this question to the group. There is general 
> > agreement that handovers require faster re-authentication 
> and that EAP 
> > doesn't necessarily provide that by default, as the 
> roundtrip to the 
> > AAA server and the number of messages involved may take away from 
> > that. Pre-authentication helps, but not all that much if the AAA 
> > server is many, many hops away and is also dependent on how far in 
> > advance of the handover the client initiates the pre-authentication.
> >
> Yes. There seems to be many different cases and environments 
> here, alternative solutions are likely to work best in 
> different cases. In any case, we are talking about a fairly 
> complicated piece of functionality. Lets be careful to not 
> make this too complicated, using the simpler techniques until 
> it is shown that they are insufficient for important cases.
> 


Agreed. Simpler the better - but, we do need to ensure that the approach 
satisfies the security criteria required. 

<snip>


> 
> Server-initiated RADIUS is possible, I believe, but I'm not 
> sure if it 
> works for
> this particular case where no prior contact exists.
> 


As described in the aaaarch-handoff draft, it seems feasible to me. I am 
assuming, however, that there exists SAs between the AAA server and all the 
NAS-es in the domain. Am I missing something else? 

<snip>

> >
> I believe there are two parts in your approach #2: the 
> separate keys and the delivery. The keying framework supports 
> the separate key approach, for security reasons. It doesn't 
> talk much about the delivery part. Obviously, various 
> delivery options are possible, such as fast-reauth and 
> delivery of key, plain key request without auth, and 
> proactive key distribution.
> 

Yes. In order to support something like proactive key distribution, we would 
need something similar to the aaaarch-handoff draft to  be advanced, right? I 
am not sure if that draft will entirely solve the issue at hand, but it seems 
like a good starting point. But, I have not seen any activity in that space. Is 
this because there is sufficient risk and/or complexity in such an approach? 
Or, is it because the alternatives are more attractive? Or perhaps some other 
reason that I am missing? 

Thanks,
Vidya