eap Mailing List: RE: EAP, AAA and Handovers

[Narayanan Vidya-CVN065 (vidya]

Hi Lakshminath,
Yes, I have read the key management framework - but I struggle with the text in 
that. It briefly touches on the AMSK derivation and how to derive AAA-keys for 
multiple authenticators - but how do those keys get transported to those 
authenticators ahead of time? It doesn't address any hooks in AAA protocols to 
allow that (nor should it - that is what the IRTF aaaarch-handoff draft was 
for). 

The issue I am having is the very fact that the aaa handoff architecture work 
still remains in IRTF, while we are designing handoff protocols assuming that 
such a aaa architecture is not available. 

BTW, with the new split of the EAP key management draft into two, the key 
derivation stuff I believe is out of the basic draft - it is intended to be 
part of the extended EAP keying draft. 

Regards,
Vidya

-----Original Message-----
From: Lakshminath Dondeti [mailto:ldondeti [at] qualcomm.com] 
Sent: Friday, April 29, 2005 10:09 AM
To: Narayanan Vidya-CVN065
Subject: Re: [eap] EAP, AAA and Handovers


Hi Vidya,

Have you seen the EAP keying I-D?  
http://ietfreport.isoc.org/all-ids/draft-ietf-eap-keying-05.txt  
(apologies if you already know about it).

Note: the 06 version removed the key derivation aspects.  I forget where 
it went in the reorganization of the text.

regards,
Lakshminath

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.
>  
> In my mind, there seems to be two ways of addressing this handover
> problem:
>  
> 1. Modify EAP somehow or introduce a "local" node geographically
> closer to the NAS that can receive the AAA-key. There is always the 
> question of whether this approach compromises security and whether 
> this now becomes a greater than 3-party model that is not acceptable, 
> etc. This topic is already under discussion and I don't want the 
> discussion to be repeated here.
>  
> 2. Modify AAA to allow creation of multiple AAA-keys (for multiple
> NAS-es) and send them to the respective NAS-es. This is not a novel 
> concept and has been talked about in university papers and such - but 
> I am trying to understand if this is a viable method to discuss in the 
> IETF. Basically, if the AAA server can create AAA-keys for neighbor 
> NAS entities (and not just the current requesting NAS), it keeps the 
> model of EAP intact - only the AS generates the AAA-key to be used 
> between one NAS/client pair. However, the issue with this is the 
> support for unsolicited messages in the AAA protocols - today, the AAA 
> server cannot send an unsolicited message with a AAA-key to a NAS for 
> a client that is yet to attach to it. Introducing such a model (wasn't 
> there an IRTF draft at some point talking about RADIUS Notify messages 
> or some such sort?) would allow the AAA-server to authenticate the 
> client and derive one AAA-key for the current NAS and an arbitrary 
> number of AAA-keys for potential handover target NAS-es and send them 
> down in an unsolicited manner to the target NAS devices.
>  
> Has this model been discussed before? If so, I'd appreciate if someone
> can point me to any documentation/ML thread on this. If not, I'd like 
> to understand if that is a viable option or not. I understand that AAA 
> protocols already have a widely deployed base - but, this doesn't 
> necessarily have an impact on legacy devices. It places a new 
> requirement on AAA (and possibly a minor one on EAP to carry the 
> request for multiple AAA-keys) to support handovers - but would that 
> not be acceptable? It seems to me that this would allow all the 
> Housley criteria to be satisfied and the 3-party model to be preserved 
> properly.
>  
> Maybe I am missing something fundamental here. I'd like to hear any
> thoughts on it.
>
> Thanks,
> Vidya