[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Non-member submission from ["Narayanan, Vidya" <vidyan@qualcomm.com>]
-----Original Message-----
From: owner-aaa-doctors@ops.ietf.org
[mailto:owner-aaa-doctors@ops.ietf.org]
Sent: Thursday, September 21, 2006 3:37 AM
To: aaa-doctors-approval@psg.com
Subject: BOUNCE aaa-doctors@ops.ietf.org: Non-member submission from
["Narayanan, Vidya" <vidyan@qualcomm.com>]
From vidyan@qualcomm.com Thu Sep 21 00:36:46 2006
autolearn=ham
version=3.1.1
[129.46.61.151])
by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
k8L0acNr013409
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256
verify=FAIL);
Wed, 20 Sep 2006 17:36:39 -0700
[129.46.134.172])
by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
k8L0Z9IT008937;
Wed, 20 Sep 2006 17:36:35 -0700 (PDT)
NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830);
Wed, 20 Sep 2006 17:36:23 -0700
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: New Radius/Diameter authentication and key delivery for
FMIP application
Date: Wed, 20 Sep 2006 17:36:22 -0700
Message-ID:
<C24CB51D5AA800449982D9BCB90325131A28DD@NAEX13.na.qualcomm.com>
In-Reply-To: <4511972B.6060700@piuha.net>
FMIP application
From: "Narayanan, Vidya" <vidyan@qualcomm.com>
To: "Jari Arkko" <jari.arkko@piuha.net>, "Sam Hartman"
<hartmans-ietf@mit.edu>
Cc: "AAA Doctors" <aaa-doctors@ops.ietf.org>,
"Russ Housley" <housley@vigilsec.com>, <dromasca@avaya.com>,
<david.kessens@nokia.com>, <mipshop-chairs@tools.ietf.org>
FILETIME=[F6C623F0:01C6DD15]
>=20
> Sam Hartman wrote:
>=20
> >Whatever we are discussing here will require new code be deployed
> >at=20 the radius and diameter servers.
> > =20
> >
> Possibly. I guess part of my question was whether that's=20 true. For
>instance, is there a way to do this with existing=20 authentication
>schemes in AAA?
>=20
Let me summarize some alternatives and why those are not quite suitable
for this particular use case. We had a similar discussion way back on
the MIPSHOP mailing list, but will provide a summary here for the
benefit of everyone on this list.=20
Option 1 - Keying FMIP SAs at the time of network access
--------------------------------------------------------
This was the first debated option and this is about tying FMIP keying
with EAP keying. This is a bad idea for several reasons:=20
1. Using the MSK to derive a key to be given to the AR is clearly not an
option (although at the time of the debate, it took a lot of effort to
convince folks on why this is bad idea) - this results in violated uses
of the MSK among other issues of key transport from the EAP
authenticator to the AR, etc.=20
2. It is plausible to support something like this with EMSK-based
keying, but we have had several discussions on that front and proven
that option is not quite clear either. Plus, the other issues below
still apply.=20
3. Clearly, the approach assumes EAP is universally used - sadly, not
true just yet :) MNs using GPRS, for instance, are toast. So are MNs
using WLANs with open authentication. But, bottomline is that IP level
operation must not mandate or assume a certain protocol to be used for
link layer security.=20
4. This gets really ugly really fast depending on the lower layer -
802.11i vs 802.11r vs 802.16e vs whatever. The main issue here is this -
L2 handoffs don't always imply L3 handoffs, but L3 handoffs almost
always imply L2 handoffs. So, this gets into things like - is EAP
performed at every L2 handoff? If so, what is the tie between lifetimes
of the EAP keys and keys derived for L3 handoffs? Etc.=20
This approach was finally ruled out as not a practical one.=20
Option 2 - IKEv2/IPsec
----------------------
The idea here would be that the MN ultimately shares an IPsec SA with
the AR, with which it can protect the signaling. This mechanism has the
following drawbacks:=20
1. Realistically, the MN cannot be assumed to share a PSK with every AR
it attaches to, in order to perform IKEv2 using PSKs.
2. Requiring certs on the MN is also not an option.=20
3. The alternative is to use IKEv2-EAP, which is considered way too
expensive to be performed with every AR. Even if we say that this
exchange is not in the critical path (actually, in the event of
ping-ponging between ARs and such, this won't be totally true), it
simply introduces unacceptable number of messages OTA at every AR. The 2
messages needed to perform FMIP itself are not viewed as being
acceptable in many systems that resort to network-based edge tunnels,
even though it is kludgy. Even in the systems that actually want to use
FMIP to handle handoff latency, to say that we are adding another 4-10
roundtrips to perform IKEv2-EAP to set up the SA for FMIP will clearly
remove FMIP from any deployment considerations.=20
4. Manually keyed IPsec is not an option for the same reason why IKEv2
PSKs is not an option.=20
There is a need for a AAA-based simple and efficient protocol for IP
mobility keying in general - even with MIP6, I keep hearing how it is a
nightmare to do IKEv2-EAP to establish the IPsec SAs in a system failure
recovery type of scenario. But, in general though, for protocols like
MIP6 and HMIP6, the SA setup is between MN and HA or MN and MAP, which
occurs much less frequently and hence, I would contend that IKEv2-EAP is
perfectly acceptable. For FMIP, where the MN frequently moves across
ARs, this case cannot be made. This is too transient to consider
elaborate message exchanges.=20
Ideally, I would like to see a generic lightweight keying protocol for
IP mobility. For instance, there is nothing FMIP-specific in the
proposed protocol in draft-vidya-mipshop-handover-keys-aaa. If RFC4004
and RFC3957 were written more generically, we could potentially just use
that and not have to have another spec here. I was hoping to at least
have something generic to local mobility protocols - - however, the WG
only wanted to focus on this for FMIP and here we are with it.=20
> But lets start with an even more fundamental question.
> Vidya, is it the intention that there are new credentials=20 deployed
> for the FMIP authentication purpose?
The current proposal is based on a PSK (termed Handover Master Key -
HMK). It is possible to bootstrap this PSK dynamically, but we have
pending debates on that in other parts of the IETF - for the draft
itself, how the HMK is bootstrapped is outside the scope.=20
Thanks,
Vidya
>=20
> --Jari
>=20
>=20