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