RE: AAA for Handovers

[Narayanan Vidya-CVN065 <vidya@motorola.com>]

Hi Bernard,
Thanks for the detailed explanation. This was very helpful to me. Please see some questions/comments inline. 

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com]
> Sent: Wednesday, August 10, 2005 11:38 AM
> To: Narayanan Vidya-CVN065
> Cc: radiusext@ops.ietf.org; aaa-wg@merit.edu; Korus Mike-CMK013
> Subject: Re: AAA for Handovers
> 
> 
> > A while ago, some work was done in the IRTF on RADIUS for
> handovers in
> > the aaaarch-handoff draft, but it seems to have rather died now.
> 
> The extension specified in the draft was implemented, and
> experimental measurements were made that showed that the 
> technique was effective in intra-domain use.
> 
> However, in other scenarios there are potential efficiency
> issues since in 802.11 handoff is station-initiated and yet 
> pre-emptive keying does not allow the station to know where 
> keys have been sent.  As a result, the key state between the 
> peer, authenticator and server is not kept in sync and the 
> station may not be able to make effective roaming decisions.  
> For example, in roaming scenarios the server would be 
> unlikely to have a complete knowledge of the topology and 
> thus would be unable to determine where to send keying material.
> 

Can this not be addressed by providing a mechanism in AAA to carry target NAS-IDs from the current NAS through which the STA is authenticating? I agree that it is unrealistic to expect the AAA server to have complete knowledge of the topology. By allowing this information to be carried in RADIUS to the server, the topology information can still come from the STA - of course, this will require some support from EAP as well to get this from the STA to the current NAS, but it still seems like it can be done. So, in this model, the AAA server will only derive keys for the requested target NAS devices - so, the station will know where the keys are sent. Am I missing something? 


> This causes pre-emptive keying to be ineffective in 
> inter-domain use.  There are also concerns about intra-domain 
> deployments because pre-emptive keying requires RFC 
> 3576-style server-initiated messages.
> 

Yes, true. I have wondered why RFC3576 wasn't made a bit more generic, with "disconnect" being one type of message. But, why is this style bad? 

> Finally, questions were also raised about whether the 
> mechanism satisfied the criteria in draft-housley since the 
> pre-emptive keying scheme does not authenticate the user 
> through the NAS that it will connect to.
> 


Maybe I'm not remembering draft-housley properly - what threat does this introduce? If the AAA server shares an SA with the target NAS, and the MN can be properly authenticated, why is it important that the MN be authenticated through that NAS? 


> As a result, the focus of work on fast handoff has shifted 
> away from pre-emptive keying schemes initiated by the server, 
> toward "key request" schemes initiated by the peer.  
> Advantages of "Key Request" include:
> 
> a. The station can send an authenticated "Key Request" via 
> the target NAS, sychronizing the key state between the peer, 
> NAS and server and enabling integration between roaming and 
> key management on the peer.
> 

Obviously, this is straightforward - but, are there security reasons why this is better? 

> b. A conventional AAA Request/Response conversation is 
> sufficient; server initiated messages are not required.
> 

I guess I am trying to see if by adding new AAA messages, we can achieve better security along with faster handoffs. 

> c. "Key Request" relies on local information available to the 
> station rather than a global map of the topology kept on the 
> AAA server, so that it scales better in roaming scenarios.
> 

As I mentioned above, perhaps this model can still be preserved? 

> > Thinking about this a little further, it seems like such a 
> design is 
> >becoming popular due to the lack of a method in AAA to 
> pre-authenticate 
> >to multiple authenticators (NAS-es) and proactively 
> distribute keys to 
> >the NAS-es.
> 
> As I understand it, IEEE 802.11r supports both conventional 
> pre-authentication as well as a "Key Request" mode.  However, 
> it does not support pre-emptive keying.
> 
> Note that the terms "pre-authentication" and "proactive" are 
> mutually exclusive. Pre-authentication schemes (such as Key 
> Request) are station initiated; "proactive" schemes are 
> server-initiated.  Typically a given approach will do one or 
> the other, but not both.  My understanding is that IEEE 
> 802.11r has rejected the "proactive" approach.


Yes, since pre-authentication and proactive aren't the same thing, I included both terms in my statement above :) I was not aware that a proactive approach was considered by 802.11r - any particular reason why it was rejected? Is it simply to avoid making changes to AAA or due to other reasons? 

> 
> Note that "Key Request" schemes do not eliminate the need for 
> a conversation between the NAS and AAA server, they merely 
> shorten it.  For example, a "fast resume" typically requires 
> 2.5 roundtrips, while a Key Request might be completed in a 
> single round-trip.
> 

Yes, and therein lies the problem. At least for requirements we have on handoff times for some of the applications we are seeing, it seems rather unacceptable to have any need for conversation with the AAA server at the time of handoff. This is leading to designs that include intermediate key hierarchy branches off the MSK as Madjid pointed out. 

> >It seems to me that if the IETF worked on this and matured 
> it enough, 
> >people would be willing to use it to provide more secure faster 
> >handoffs.
> 
> Dorothy Stanley the IEEE 802.11 liaison has mentioned that 
> IEEE 802.11r may make a liaison request for work on fast 
> handoff.  However, based on the discussion that has occurred 
> so far, it seems unlikely that such a request will relate to 
> pre-emptive keying.  "Key Request" approaches have a lot more 
> support at this point.
> 

This is true. However, is it because AAA lacks support for this or is it the "key request" approach is technically a better one? 


> >Especially since some work was done in this space earlier 
> on, it seems 
> >like it might be worth looking into. The IRTF draft was ahead of its 
> >time when it was written - but, it seems like the timing for such a 
> >task would be perfect now.
> 
> As mentioned earlier, the IRTF work on pre-emptive handoff is 
> not moving forward because it does not satisfy the problem 
> requirements as they are currently understood.  

I do realize that the pre-emptive handoff work as written in the IRTF draft does not satisfy all requirements. Is it worth looking at whether it will be more applicable with some changes, such as a method to send multiple NAS-IDs to the AAA server? 

Thanks,
Vidya


> Current work 
> is focused on "Key Request" approaches. However, some 
> fundamental questions remain about how "Key Request" would work:
> 
> a. How are the keys to be named?  Can the key naming scheme 
> used in the EAP key management framework be used?
> 
> b. Can different media simultaneously use the key request 
> scheme?  If so, does the AAA server need to maintain a 
> different cache for each media or can a single cache be supported?
> 
> c. How is the key request authenticated?
> 
> d. How does the peer direct the key request to the correct 
> AAA server? How does this work if the EAP method in question 
> does not provide a Server-ID so that the peer is unaware of 
> where its keys are being cached?
> 



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>