[Mobopts] Re: [Mipshop] RE: Review of draft-vidya-mipshop-handover-keys-aaa -00.txt

["James Kempf" <Kempf at docomolabs-usa.com>]

Vidya,

> > Now, suppose that, instead of routing the key directly to the
> > AR, it is routed through the NAS instead. If the key is
> > end-to-end encrypted, how does that violate the Housley
> > critera? The NAS is acting like a proxy AAA server and
> > doesn't ever get to look at the key.
> >
>
>
> I thought that the idea of coupling this with network access is (also) so
that you only need an SA between the AAA server and the NAS. If you also
have an SA with the AR, this is feasible. But, here are some problems I see
with this approach:
>

No, the idea is to minimize the different protocols on the host, and to
align the signaling for the handover key exchange with network access
authentication. There's no way to get around having the AAA-AR SA if you
want to do key exchange with it.

> - the NAS is potentially different upon every handoff; depending on the
scenario, the NAS is an AP, an 802.16 BS, a PAA located at the AR, a PAA
separate from the AR, etc. So, this means, the NAS may be doing 802.11i,
802.11r, 802.16 or PANA.
Even though it is still EAP in all these cases, I am not sure how a common
design can solve this - for e.g., once the NAS gets an EAP-AMSK (that is
supposed to serve as the HK), how does it get that to the AR and the
corresponding keying material to the MN - that protocol, if implemented
using PANA, is unique to PANA and won't be available when the NAS is not a
PAA, but an 802.1x authenticator. This is why I was asking if you envision a
second EAP-method exchange with a PAA after 802.1x is done, just to derive
HKs. Or, I must be missing something.
>
I think I see your point. Your point is that the EAP is end to end, host to
AAA server, and that the EAP-AMSK will end up at the NAS when it needs to be
at the AR.

Here is a possibility. The pAR asks the NAS for the key when the FBU arrives
from the MN the first time the MN hands over. If the NAS is co-located with
the pAR, then this is just an API call within the router, and fast. If the
NAS is at an AP (such as 802.11) then it would require a Radius transaction,
which will be slow and undesirable since it is part of the handover path.
But note that this need only occur the first time the MN hands over. Since
nAR also handles the FBU and the MN must authenticate through the NAS on nAP
first in order to be able to send the FBU (in which case the new EAP-AMSK
will be at the NAS prior to the FBU  being sent), nAR can ask the NAS for
the MN's handover key when the FBU goes by. This need not delay the FBU,
since nAR doesn't need the handover key for processing it, because the FBU
is going to pAR. Later, when the MN hands over from nAR, the key will
already be there when the FBU arrives from the yet newer AR.

There are also a couple other ways the NAS could get the key to the first AR
prior to the first handover. Unfortunately, Radius isn't one of them,
because Radius doesn't allow push. Diameter would work, however. Also, if
the NAS sends some kind of COPS or SNMP message to the AR to unblock
Internet routing, that would provide another vehicle. The AR could also ask
for the key using Radius after performing the first NS/NA (aka ARP) to get
the MN's IPv6 address to link address mapping, if it doesn't have the key,
or upon reception of an outbound packet with no neighbor cache entry for the
IPv6 address, or upon reception of an RS from the MN with a SLLAO.
Triggering on link address to IPv6 address mapping would probably be best,
because it allows the AR to establish the linking between the address as the
name for the key and the key itself.

Also, I think that the extension in this case would be for Radius not EAP
(sorry about that) because EAP is end to end and the host isn't getting the
key. The Radius extension would work for both the link authentication and
PANA case. In the link authentication case, the handover key would end up on
the NAS, in the PANA case, it would end up on the PAA. In either case, the
AR would need to know the relevant gateway to ask, of course, but the same
Radius handover key extension could be used to ask the router.

> - Along the same lines, I especially see a problem when 802.11r is used -
in this case, there may not be an EAP exchange when the MN hands off. What
happens then?

I think preauthentication is an option for 802.11r. If preauthentication is
used, the key can be distributed to the NASes during the preauthenication
phase. The nAR can fetch the key from its local NAS when the FBU for pAR
goes by, or on NS/NA if its the first time, as above.

>
> - This method, as Rajeev pointed out, puts HK derivation in the critical
handoff path. That seems unncessary. The MN should be able to hand off with
only the essential steps and nothing else.
>

Only for some specific  and very limited cases (i.e. if the pAR needs to ask
the NAS for the key when the FBU arrives on the very first handover in the
access network). And if the bootstrapping procedure using NS/NA described
above is used, then it need not even happen then.

How does that sound?

                jak



_______________________________________________
Mobopts mailing list
Mobopts at irtf.org
https://www1.ietf.org/mailman/listinfo/mobopts