eap Mailing List: Re: EAP, AAA and Handovers

[Jari Arkko (jari.arkko]

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.

> 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.

Yes. And there are three variants of this, 1a where the local node is 
the first base station,
1b where it is a local AAA proxy, and 1c where its a completely new node 
in the AAA
network.

>  
> 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

Yes.

> 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.

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

>  
> 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.
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.

--Jari