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