[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: AAA for Handovers



Title: Message
Hi Vidya,
 
This is a topic that has been discussed over many mailing lists and not sure if a long thread on this topic is something people like to relive. However, unfortunately, I for one have not found a recipe from IETF yet (or at least a simply digestible for an amateur EAPer like myself). So non-IETF bodies are starting to do their own methods with varying degree of regard for Housely criteria, because the limited understanding of the specification and frankly in my believe limited IETF specifications.
 
Issues that I see:
 
1) As you mentioned, the common understanding of RADIUS being incapable of doing server-initiated messaging. This seems to not be the case anymore with CoA RFC, but I am not sure if CoA messaging can be used to push keys to multiple NASes.
 
2) A related issues is EAP's limited capability in key transport (AAA key or MSKs are only sent to the authenticator and no other entities). Also key transport and encryption standards are generally not well understood.
 
3) Micro mobility in many systems forces people to have base stations or access points to work at a level below the NAS for a variety of reasons, from no need for RADIUS client in the BS, to not sharing the EAP master keys at a BS that can be easily hacked. This means people are inventing key hierarchies that feed off the EAP master keys and generated BS-specific keys to prevent "domino effects". so this can't even be solved by AAA server proactively pushing keys. and Going back to AAA server for each key generation is not desirable.
 
4) Lack of standardized authorization attributes and messaging to allow the EAP keys to bootstrap other mechanisms such as Mobile IP and so on. People invent bootstrapping mechanisms without regard to the initial EAP key lifetimes or authorizations or without the ability to cross check these life times. The AAA community needs to simply take control by providing authorization directives to the NAS on what it can and cannot do with the keys.
 
5) Channel binding is a very hard topic to understand and to provide a cure for.
 
I tried to start a discussion on this topic in the EAP group by sending a draft talking about EAP and handover support,
http://www.ietf.org/internet-drafts/draft-nakhjiri-eap-ho-00.txt
 
but seeing your email and doing the short list above, I think both EAP and RADIUS need to be worked together.
 
 
One of the major issues is that there are people on the list that do not think there are any problems with the existing specification, so I would say the more constructive thing to do (instead of engaging in intractable debates on the list) is to work on a draft that lists the issues (I tried both above and in my draft) and then solicit answers to see if the issues have convincing answers, if not try to solve it either in EAP or in RADext or find the right IETF venue to solve the problems, unless IETF does not want to deal with this and will rather have IEEE work on it.
 
Madjid


From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Narayanan Vidya-CVN065
Sent: Wednesday, August 10, 2005 9:57 AM
To: radiusext@ops.ietf.org
Cc: aaa-wg@merit.edu; Korus Mike-CMK013
Subject: AAA for Handovers

All,
I had a brief chat with Jari Arkko on this topic in Paris and he suggested I bring it up on the RADEXT mailing list.
 
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. Currently, there seems to be no efforts to advance such work in the IETF or IRTF. I was wondering if reviving some work along the same lines might be an option people would support or desire.
 
Some thoughts on why this work would be useful:
 
It is quite evident that performing an entire EAP method exchange upon handoff introduces significant increase in handoff times. It seems that people are getting around going to the AAA server every time by defining evolving keys and introducing local KDCs. An example is the path 802.11r is taking. 802.11r has introduced an evolving key hierarchy that allows the STA to handoff without having to perform a full EAP exchange. It is generally accepted (at least seems to be) that this is inherently less secure than performing regular EAP - however, this is viewed as important to be able to have acceptable handoff times. Being of the IETF mentality, to me, these mechanisms do not seem to satisfy all the Housley criteria as they should. However, without changes in AAA, I don't have a better answer to reducing handoff times.
 
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. If there was a way to do this, it would be possible to derive multiple keys at the AAA server for a mobile node corresponding to target NAS devices and proactively push the keys to those devices without the need for a complete authentication and key derivation upon handoff. It would allow significant reduction in the signaling required to establish keys at NAS-es.
 
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. 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.
 
Any thoughts?
 
Thanks,
Vidya