FMIPv6 Security (was Re: Confirmation on decision on HMIPv6 Security)

 
> > Alper Yegin wrote:
> > > If EAP/IKEv2 is sufficient for HMIP, why not
for FMIP as 
> well? In other
> > > words, do we still need FMIPv6 security
solutions?
> > 
> > I don't think one would ever use IKEv2 with an
> > access router.
> 
> Why? What's wrong with IKEv2?

I didn't say there is something wrong with IKEv2.
I just don't see it being used between a mobile 
node and an access router. IKEv2, like any other 
protocol has its applicability scenarios, and I 
don't see FMIPv6 being one of them.

I don't know what kind of answer you were 
expecting from me. 

Vijay

_______________________________________________
Mipshop mailing list
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop

It is not practical to run IKEv2 with every AR to create
IPsec SAs,
given that AR changes may occur frequently. The target AR
prediction
often does not happen enough in advance or with enough
accuracy to take
on such an exchange. It is also impractical to expect the MN
to have a
PSK with every AR that it might visit, which means that we
are really
talking about running IKEv2-EAP. The DH, combined with the
minimum of
6-message exchange for IKEv2-EAP with every AR is extremely
impractical.


For HMIPv6 or MIP6, the MAP/HA changes do not occur
frequently enough
for this to be an issue. Further, from a practical
deployment
perspective, it is feasible to overlap the MAP coverage
regions such
that the IPsec SA can be established with the new MAP before
the MN
starts using the new MAP. 

Vidya

> -----Original Message-----
> From: Vijay Devarapalli [mailto:Vijay.DevarapalliAzaireNet.com] 
> Sent: Tuesday, November 21, 2006 12:15 PM
> To: Alper Yegin
> Cc: mipshopietf.org
> Subject: RE: FMIPv6 Security (was Re: [Mipshop]
Confirmation 
> on decision onHMIPv6 Security)
> 
>  
> > > Alper Yegin wrote:
> > > > If EAP/IKEv2 is sufficient for HMIP, why
not for FMIP as
> > well? In other
> > > > words, do we still need FMIPv6 security
solutions?
> > > 
> > > I don't think one would ever use IKEv2 with
an access router.
> > 
> > Why? What's wrong with IKEv2?
> 
> I didn't say there is something wrong with IKEv2.
> I just don't see it being used between a mobile node
and an 
> access router. IKEv2, like any other protocol has its 
> applicability scenarios, and I don't see FMIPv6 being
one of them.
> 
> I don't know what kind of answer you were expecting
from me. 
> 
> Vijay
> 
> _______________________________________________
> Mipshop mailing list
> Mipshopietf.org
> https:
//www1.ietf.org/mailman/listinfo/mipshop
> 

_______________________________________________
Mipshop mailing list
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop

Hi,

2006/11/22, Narayanan, Vidya <vidyanqualcomm.com>:
> It is not practical to run IKEv2 with every AR to
create IPsec SAs,
> given that AR changes may occur frequently. The target
AR prediction
> often does not happen enough in advance or with enough
accuracy to take
> on such an exchange. It is also impractical to expect
the MN to have a
> PSK with every AR that it might visit, which means that
we are really
> talking about running IKEv2-EAP. The DH, combined with
the minimum of
> 6-message exchange for IKEv2-EAP with every AR is
extremely impractical.

I would prefer that we don't close the door for such a
scenario. BTW,
IPsec Pre-Auth (i.e. draft-yacine-preauth-ipsec-01) or IPsec
CxT may
help in this case.

Best regards.

JMC.

>
>
> For HMIPv6 or MIP6, the MAP/HA changes do not occur
frequently enough
> for this to be an issue. Further, from a practical
deployment
> perspective, it is feasible to overlap the MAP coverage
regions such
> that the IPsec SA can be established with the new MAP
before the MN
> starts using the new MAP.
>
> Vidya
>
> > -----Original Message-----
> > From: Vijay Devarapalli
[mailto:Vijay.DevarapalliAzaireNet.com]
> > Sent: Tuesday, November 21, 2006 12:15 PM
> > To: Alper Yegin
> > Cc: mipshopietf.org
> > Subject: RE: FMIPv6 Security (was Re: [Mipshop]
Confirmation
> > on decision onHMIPv6 Security)
> >
> >
> > > > Alper Yegin wrote:
> > > > > If EAP/IKEv2 is sufficient for
HMIP, why not for FMIP as
> > > well? In other
> > > > > words, do we still need FMIPv6
security solutions?
> > > >
> > > > I don't think one would ever use IKEv2
with an access router.
> > >
> > > Why? What's wrong with IKEv2?
> >
> > I didn't say there is something wrong with IKEv2.
> > I just don't see it being used between a mobile
node and an
> > access router. IKEv2, like any other protocol has
its
> > applicability scenarios, and I don't see FMIPv6
being one of them.
> >
> > I don't know what kind of answer you were
expecting from me. 
> >
> > Vijay
> >
> > _______________________________________________
> > Mipshop mailing list
> > Mipshopietf.org
> > https:
//www1.ietf.org/mailman/listinfo/mipshop
> >
>
> _______________________________________________
> Mipshop mailing list
> Mipshopietf.org
> https:
//www1.ietf.org/mailman/listinfo/mipshop
>

_______________________________________________
Mipshop mailing list
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop

Vijay,

> > > Alper Yegin wrote:
> > > > If EAP/IKEv2 is sufficient for HMIP, why
not for FMIP as
> > well? In other
> > > > words, do we still need FMIPv6 security
solutions?
> > >
> > > I don't think one would ever use IKEv2 with
an
> > > access router.
> >
> > Why? What's wrong with IKEv2?
> 
> I didn't say there is something wrong with IKEv2.
> I just don't see it being used between a mobile
> node and an access router. IKEv2, like any other
> protocol has its applicability scenarios, and I
> don't see FMIPv6 being one of them.

Could you please elaborate, so that we can understand why
you think you
don't see IKEv2 being used between a MN and AR, and why it
cannot apply to
an AR running FMIPv6?

Thanks.

Alper


_______________________________________________
Mipshop mailing list
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop

> It is not practical to run IKEv2 with every AR to
create IPsec SAs,
> given that AR changes may occur frequently. 

This is about running IKEv2 with the serving AR. If the AR
changes so
rapidly that the MN does not have a chance to complete one
IKEv2 between the
time it has established network connectivity with the AR to
the time it
disconnects, I'd say this is an extreme case. Does it make
sense to rule out
a scheme as "not practical" under this
circumstance?


> The target AR prediction
> often does not happen enough in advance or with enough
accuracy to take
> on such an exchange. It is also impractical to expect
the MN to have a
> PSK with every AR that it might visit, which means that
we are really
> talking about running IKEv2-EAP. 

I don't understand this either. Given that typically AR is
same as NAS, you
know MN and AR/NAS has a PSK (MSK) for secure network
access. So, MN and AR
sharing a PSK is indeed practical.


> The DH, combined with the minimum of
> 6-message exchange for IKEv2-EAP with every AR is
extremely impractical.
> 
> 
> For HMIPv6 or MIP6, the MAP/HA changes do not occur
frequently enough
> for this to be an issue. Further, from a practical
deployment
> perspective, it is feasible to overlap the MAP coverage
regions such
> that the IPsec SA can be established with the new MAP
before the MN
> starts using the new MAP.

Alper




> 
> Vidya
> 
> > -----Original Message-----
> > From: Vijay Devarapalli
[mailto:Vijay.DevarapalliAzaireNet.com]
> > Sent: Tuesday, November 21, 2006 12:15 PM
> > To: Alper Yegin
> > Cc: mipshopietf.org
> > Subject: RE: FMIPv6 Security (was Re: [Mipshop]
Confirmation
> > on decision onHMIPv6 Security)
> >
> >
> > > > Alper Yegin wrote:
> > > > > If EAP/IKEv2 is sufficient for
HMIP, why not for FMIP as
> > > well? In other
> > > > > words, do we still need FMIPv6
security solutions?
> > > >
> > > > I don't think one would ever use IKEv2
with an access router.
> > >
> > > Why? What's wrong with IKEv2?
> >
> > I didn't say there is something wrong with IKEv2.
> > I just don't see it being used between a mobile
node and an
> > access router. IKEv2, like any other protocol has
its
> > applicability scenarios, and I don't see FMIPv6
being one of them.
> >
> > I don't know what kind of answer you were
expecting from me. 
> >
> > Vijay
> >
> > _______________________________________________
> > Mipshop mailing list
> > Mipshopietf.org
> > https:
//www1.ietf.org/mailman/listinfo/mipshop
> >


_______________________________________________
Mipshop mailing list
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop

Alper,

> 
> > It is not practical to run IKEv2 with every AR to
create IPsec SAs, 
> > given that AR changes may occur frequently.
> 
> This is about running IKEv2 with the serving AR. If the
AR 
> changes so rapidly that the MN does not have a chance
to 
> complete one IKEv2 between the time it has established 
> network connectivity with the AR to the time it
disconnects, 
> I'd say this is an extreme case. Does it make sense to
rule 
> out a scheme as "not practical" under this
circumstance?
> 

There is no operator that currently wants to run FMIP, given
that it
introduces additional signaling over the air, every time the
AR changes.
If there is someone who wants to allow an additional
6-message exchange
with the MN to create SAs for securing FMIP, sure - that is
their call.
But, this clearly is not the typical case. 

> 
> > The target AR prediction
> > often does not happen enough in advance or with
enough accuracy to 
> > take on such an exchange. It is also impractical
to expect 
> the MN to 
> > have a PSK with every AR that it might visit,
which means 
> that we are 
> > really talking about running IKEv2-EAP.
> 
> I don't understand this either. Given that typically AR
is 
> same as NAS, 

Huh? Maybe if you are running PANA, the AR will be the same
as the NAS,
but that is not a given even there. Are you saying that
802.11 devices
are the ARs that run FMIP or are you saying that the 802.11
devices are
not the ones running 802.1x and 802.11i/802.11r? I'm lost.  

Using network access authentication and worse still, using
the EAP MSK
for generating keys for FMIP is a layer violation that
doesn't fit with
most models of network access being deployed today. 

> you know MN and AR/NAS has a PSK (MSK) for 
> secure network access. So, MN and AR sharing a PSK is
indeed 
> practical.
> 

Please see the above explanation. And, the MSK is not a PSK.
Today,
IKEv2 allows the use of MSK purely for one client
authentication. An
IKEv2 PSK, OTOH, could be used repeatedly for a number of
IKEv2
exchanges between two entities. 

Vidya

> 
> > The DH, combined with the minimum of
> > 6-message exchange for IKEv2-EAP with every AR is
extremely 
> impractical.
> > 
> > 
> > For HMIPv6 or MIP6, the MAP/HA changes do not
occur 
> frequently enough 
> > for this to be an issue. Further, from a practical
deployment 
> > perspective, it is feasible to overlap the MAP
coverage 
> regions such 
> > that the IPsec SA can be established with the new
MAP before the MN 
> > starts using the new MAP.
> 
> Alper
> 
> 
> 
> 
> > 
> > Vidya
> > 
> > > -----Original Message-----
> > > From: Vijay Devarapalli
[mailto:Vijay.DevarapalliAzaireNet.com]
> > > Sent: Tuesday, November 21, 2006 12:15 PM
> > > To: Alper Yegin
> > > Cc: mipshopietf.org
> > > Subject: RE: FMIPv6 Security (was Re:
[Mipshop] Confirmation on 
> > > decision onHMIPv6 Security)
> > >
> > >
> > > > > Alper Yegin wrote:
> > > > > > If EAP/IKEv2 is sufficient for
HMIP, why not for FMIP as
> > > > well? In other
> > > > > > words, do we still need FMIPv6
security solutions?
> > > > >
> > > > > I don't think one would ever use
IKEv2 with an access router.
> > > >
> > > > Why? What's wrong with IKEv2?
> > >
> > > I didn't say there is something wrong with
IKEv2.
> > > I just don't see it being used between a
mobile node and 
> an access 
> > > router. IKEv2, like any other protocol has
its applicability 
> > > scenarios, and I don't see FMIPv6 being one
of them.
> > >
> > > I don't know what kind of answer you were
expecting from me. 
> > >
> > > Vijay
> > >
> > >
_______________________________________________
> > > Mipshop mailing list
> > > Mipshopietf.org
> > > https:
//www1.ietf.org/mailman/listinfo/mipshop
> > >
> 
> 

_______________________________________________
Mipshop mailing list
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop

Hi Vidya,

> > > It is not practical to run IKEv2 with every
AR to create IPsec SAs,
> > > given that AR changes may occur frequently.
> >
> > This is about running IKEv2 with the serving AR.
If the AR
> > changes so rapidly that the MN does not have a
chance to
> > complete one IKEv2 between the time it has
established
> > network connectivity with the AR to the time it
disconnects,
> > I'd say this is an extreme case. Does it make
sense to rule
> > out a scheme as "not practical" under
this circumstance?
> >
> 
> There is no operator that currently wants to run FMIP,
given that it
> introduces additional signaling over the air, every
time the AR changes.

If we are talking about Mobile IPv6 operators, I think we
are only talking
about 3GPP2 and WiMAX. I've never heard FMIP being turned
down because of
its over-the-air messaging. It's been always because such
architectures
already take care of fast handovers without needing
additional protocols.


> If there is someone who wants to allow an additional
6-message exchange
> with the MN to create SAs for securing FMIP, sure -
that is their call.
> But, this clearly is not the typical case.
> 
> >
> > > The target AR prediction
> > > often does not happen enough in advance or
with enough accuracy to
> > > take on such an exchange. It is also
impractical to expect
> > the MN to
> > > have a PSK with every AR that it might visit,
which means
> > that we are
> > > really talking about running IKEv2-EAP.
> >
> > I don't understand this either. Given that
typically AR is
> > same as NAS,
> 
> Huh? Maybe if you are running PANA, the AR will be the
same as the NAS,
> but that is not a given even there. Are you saying that
802.11 devices
> are the ARs that run FMIP or are you saying that the
802.11 devices are
> not the ones running 802.1x and 802.11i/802.11r? I'm
lost.

Don't be so lost. With CAPWAP and WiMAX NWG architectures,
the NAS is no
longer on the AP/BS. NAS is on the AR. Same is true for
3GPP2.


> Using network access authentication and worse still,
using the EAP MSK
> for generating keys for FMIP is a layer violation that
doesn't fit with
> most models of network access being deployed today.

This deserves another thread, if you care to explain us
why... I am not
aware of the issue.

> > you know MN and AR/NAS has a PSK (MSK) for
> > secure network access. So, MN and AR sharing a PSK
is indeed
> > practical.
> >
> 
> Please see the above explanation. And, the MSK is not a
PSK. 

As far as what goes into the IKEv2 as input, an MSK is as
good as a PSK.
Practically, there is no difference. Who cares of one is
driven from another
process, and the other is manually entered.

> Today,
> IKEv2 allows the use of MSK purely for one client
authentication. An
> IKEv2 PSK, OTOH, could be used repeatedly for a number
of IKEv2
> exchanges between two entities.

I'd appreciate more explanation on this too. 

Alper



> 
> Vidya
> 
> >
> > > The DH, combined with the minimum of
> > > 6-message exchange for IKEv2-EAP with every
AR is extremely
> > impractical.
> > >
> > >
> > > For HMIPv6 or MIP6, the MAP/HA changes do not
occur
> > frequently enough
> > > for this to be an issue. Further, from a
practical deployment
> > > perspective, it is feasible to overlap the
MAP coverage
> > regions such
> > > that the IPsec SA can be established with the
new MAP before the MN
> > > starts using the new MAP.
> >
> > Alper
> >
> >
> >
> >
> > >
> > > Vidya
> > >
> > > > -----Original Message-----
> > > > From: Vijay Devarapalli
[mailto:Vijay.DevarapalliAzaireNet.com]
> > > > Sent: Tuesday, November 21, 2006 12:15
PM
> > > > To: Alper Yegin
> > > > Cc: mipshopietf.org
> > > > Subject: RE: FMIPv6 Security (was Re:
[Mipshop] Confirmation on
> > > > decision onHMIPv6 Security)
> > > >
> > > >
> > > > > > Alper Yegin wrote:
> > > > > > > If EAP/IKEv2 is
sufficient for HMIP, why not for FMIP as
> > > > > well? In other
> > > > > > > words, do we still need
FMIPv6 security solutions?
> > > > > >
> > > > > > I don't think one would ever
use IKEv2 with an access router.
> > > > >
> > > > > Why? What's wrong with IKEv2?
> > > >
> > > > I didn't say there is something wrong
with IKEv2.
> > > > I just don't see it being used between a
mobile node and
> > an access
> > > > router. IKEv2, like any other protocol
has its applicability
> > > > scenarios, and I don't see FMIPv6 being
one of them.
> > > >
> > > > I don't know what kind of answer you
were expecting from me. 
> > > >
> > > > Vijay
> > > >
> > > >
_______________________________________________
> > > > Mipshop mailing list
> > > > Mipshopietf.org
> > > > https:
//www1.ietf.org/mailman/listinfo/mipshop
> > > >
> >
> >


_______________________________________________
Mipshop mailing list
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop

Hi Vidya,

> 
> There is no operator that currently wants to run FMIP,
given that it
> introduces additional signaling over the air, every
time the AR changes.

Where did you get such a conclusive and comprehensive
evidence? I ask
because it can be very useful if turns out to be the _only_
reason.

To put things in perspective: there is one message (FBU) to
effect route
change, and one message to announce attachment (FNA). In
fact, FNA is an ND
message with a different Type Number. The neighborhood
discovery messages
are discovery messages, which could be combined with L2
signaling or omitted
if there are other means of obtaining that information.

FYI: There is network-based FMIP signaling in
draft-ietf-mipshop-3gfh-01.txt

I think we (especially informed folks) should keep things in
perspective
while making bold statements.

I agree that adding more signaling is something we should
avoid.

-Rajeev
 

> If there is someone who wants to allow an additional
6-message exchange
> with the MN to create SAs for securing FMIP, sure -
that is their call.
> But, this clearly is not the typical case.
> 


_______________________________________________
Mipshop mailing list
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop

Hi Alper,

> -----Original Message-----
> From: Alper Yegin [mailto:alper.yeginyegin.org] 
> Sent: Thursday, November 23, 2006 9:16 AM
> To: Narayanan, Vidya; 'Vijay Devarapalli'
> Cc: mipshopietf.org
> Subject: RE: FMIPv6 Security (was Re: [Mipshop]
Confirmation 
> on decision onHMIPv6 Security)
> 
> Hi Vidya,
> 
> > > > It is not practical to run IKEv2 with
every AR to create IPsec 
> > > > SAs, given that AR changes may occur
frequently.
> > >
> > > This is about running IKEv2 with the serving
AR. If the 
> AR changes 
> > > so rapidly that the MN does not have a chance
to complete 
> one IKEv2 
> > > between the time it has established network
connectivity 
> with the AR 
> > > to the time it disconnects, I'd say this is
an extreme 
> case. Does it 
> > > make sense to rule out a scheme as "not
practical" under this 
> > > circumstance?
> > >
> > 
> > There is no operator that currently wants to run
FMIP, 
> given that it 
> > introduces additional signaling over the air,
every time 
> the AR changes.
> 
> If we are talking about Mobile IPv6 operators, I think
we are 
> only talking about 3GPP2 and WiMAX. I've never heard
FMIP 
> being turned down because of its over-the-air
messaging. It's 
> been always because such architectures already take
care of 
> fast handovers without needing additional protocols.
> 

Yes, and the reason they take care of fast handovers by
other means,
AFAIK, is because it can be done without MN-involved
signaling. Please
see my response to Rajeev on this for more details. 

> 
> > If there is someone who wants to allow an
additional 6-message 
> > exchange with the MN to create SAs for securing
FMIP, sure 
> - that is their call.
> > But, this clearly is not the typical case.
> > 
> > >
> > > > The target AR prediction
> > > > often does not happen enough in advance
or with enough 
> accuracy to 
> > > > take on such an exchange. It is also
impractical to expect
> > > the MN to
> > > > have a PSK with every AR that it might
visit, which means
> > > that we are
> > > > really talking about running IKEv2-EAP.
> > >
> > > I don't understand this either. Given that
typically AR 
> is same as 
> > > NAS,
> > 
> > Huh? Maybe if you are running PANA, the AR will be
the same as the 
> > NAS, but that is not a given even there. Are you
saying that 802.11 
> > devices are the ARs that run FMIP or are you
saying that the 802.11 
> > devices are not the ones running 802.1x and 
> 802.11i/802.11r? I'm lost.
> 
> Don't be so lost. With CAPWAP and WiMAX NWG
architectures, 
> the NAS is no longer on the AP/BS. NAS is on the AR.
Same is 
> true for 3GPP2.
> 

I am not familiar with WiMAX, but I don't believe that
CAPWAP changes
the landscape here. CAPWAP still relies on the use of
802.11i/802.1x
between the EAP authenticator and EAP peer. The AC in CAPWAP
is still an
802.11 device. ARs don't need to be technology specific.
They can remain
one level up from the actual technology specific device. The
collocation
of an AR with the L2 device is certainly feasible, but, we
the other
model is also quite common. 

> 
> > Using network access authentication and worse
still, using 
> the EAP MSK 
> > for generating keys for FMIP is a layer violation
that doesn't fit 
> > with most models of network access being deployed
today.
> 
> This deserves another thread, if you care to explain us

> why... I am not aware of the issue.
> 

This is related to the issue that Sam raised with EMSK-based
application
keying, due to which that topic was removed from HOKEY.
MSK-based
application keying muddles it even further, given that the
MSK is slated
for a specific use, as per today's standards. 

> > > you know MN and AR/NAS has a PSK (MSK) for
secure network access. 
> > > So, MN and AR sharing a PSK is indeed
practical.
> > >
> > 
> > Please see the above explanation. And, the MSK is
not a PSK. 
> 
> As far as what goes into the IKEv2 as input, an MSK is
as 
> good as a PSK.
> Practically, there is no difference. Who cares of one
is 
> driven from another
> process, and the other is manually entered.
> 

Unfortunately, it turns out that the specs do  RFC4306
intends the use
of the EAP MSK for one purpose and for one time use - for
generation of
the AUTH payload for the IKE_SA under establishment. The EAP
keying
framework document says the following about IKEv2's use of
EAP keying
material: 

"IKEv2 as specified in [RFC4306] does
     not cache EAP keying material or parameters; once IKEv2
     authentication completes it is assumed that EAP keying
material and
     parameters are discarded. " 

So, the current understanding is that the EAP MSK is not
used like a
PSK. If you are interested in more details, please see the
messages
under the following thread on the IPsec mailing list -
http://www1.ietf.org/mail-archive/web/ipsec/cu
rrent/msg02164.html. 

> > Today,
> > IKEv2 allows the use of MSK purely for one client
authentication. An
> > IKEv2 PSK, OTOH, could be used repeatedly for a
number of IKEv2
> > exchanges between two entities.
> 
> I'd appreciate more explanation on this too. 
> 

Same as the above. 

Vidya

> Alper
> 
> 
> 
> > 
> > Vidya
> > 
> > >
> > > > The DH, combined with the minimum of
> > > > 6-message exchange for IKEv2-EAP with
every AR is extremely
> > > impractical.
> > > >
> > > >
> > > > For HMIPv6 or MIP6, the MAP/HA changes
do not occur
> > > frequently enough
> > > > for this to be an issue. Further, from a
practical deployment
> > > > perspective, it is feasible to overlap
the MAP coverage
> > > regions such
> > > > that the IPsec SA can be established
with the new MAP 
> before the MN
> > > > starts using the new MAP.
> > >
> > > Alper
> > >
> > >
> > >
> > >
> > > >
> > > > Vidya
> > > >
> > > > > -----Original Message-----
> > > > > From: Vijay Devarapalli 
> [mailto:Vijay.DevarapalliAzaireNet.com]
> > > > > Sent: Tuesday, November 21, 2006
12:15 PM
> > > > > To: Alper Yegin
> > > > > Cc: mipshopietf.org
> > > > > Subject: RE: FMIPv6 Security (was
Re: [Mipshop] 
> Confirmation on
> > > > > decision onHMIPv6 Security)
> > > > >
> > > > >
> > > > > > > Alper Yegin wrote:
> > > > > > > > If EAP/IKEv2 is
sufficient for HMIP, why not for FMIP as
> > > > > > well? In other
> > > > > > > > words, do we still
need FMIPv6 security solutions?
> > > > > > >
> > > > > > > I don't think one would
ever use IKEv2 with an 
> access router.
> > > > > >
> > > > > > Why? What's wrong with IKEv2?
> > > > >
> > > > > I didn't say there is something
wrong with IKEv2.
> > > > > I just don't see it being used
between a mobile node and
> > > an access
> > > > > router. IKEv2, like any other
protocol has its applicability
> > > > > scenarios, and I don't see FMIPv6
being one of them.
> > > > >
> > > > > I don't know what kind of answer
you were expecting 
> from me. 
> > > > >
> > > > > Vijay
> > > > >
> > > > >
_______________________________________________
> > > > > Mipshop mailing list
> > > > > Mipshopietf.org
> > > > > https:
//www1.ietf.org/mailman/listinfo/mipshop
> > > > >
> > >
> > >
> 
> 

_______________________________________________
Mipshop mailing list
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop

> > > Huh? Maybe if you are running PANA, the AR
will be the same as the
> > > NAS, but that is not a given even there. Are
you saying that 802.11
> > > devices are the ARs that run FMIP or are you
saying that the 802.11
> > > devices are not the ones running 802.1x and
> > 802.11i/802.11r? I'm lost.
> >
> > Don't be so lost. With CAPWAP and WiMAX NWG
architectures,
> > the NAS is no longer on the AP/BS. NAS is on the
AR. Same is
> > true for 3GPP2.
> >
> 
> I am not familiar with WiMAX, but I don't believe that
CAPWAP changes
> the landscape here. CAPWAP still relies on the use of
802.11i/802.1x
> between the EAP authenticator and EAP peer. The AC in
CAPWAP is still an
> 802.11 device. ARs don't need to be technology
specific. They can remain
> one level up from the actual technology specific
device. The collocation
> of an AR with the L2 device is certainly feasible, but,
we the other
> model is also quite common.

See RFC 4118 for CAPWAP:

   The survey data shows that some vendors choose to tunnel
or encapsulate
   all the station traffic to or from the ACs, implying that
the AC also
   acts as the access router for this WLAN access network.


> > > > you know MN and AR/NAS has a PSK (MSK)
for secure network access.
> > > > So, MN and AR sharing a PSK is indeed
practical.
> > > >
> > >
> > > Please see the above explanation. And, the
MSK is not a PSK.
> >
> > As far as what goes into the IKEv2 as input, an
MSK is as
> > good as a PSK.
> > Practically, there is no difference. Who cares of
one is
> > driven from another
> > process, and the other is manually entered.
> >
> 
> Unfortunately, it turns out that the specs do  RFC4306
intends the use
> of the EAP MSK for one purpose and for one time use -
for generation of
> the AUTH payload for the IKE_SA under establishment.
The EAP keying
> framework document says the following about IKEv2's use
of EAP keying
> material:
> 
> "IKEv2 as specified in [RFC4306] does
>      not cache EAP keying material or parameters; once
IKEv2
>      authentication completes it is assumed that EAP
keying material and
>      parameters are discarded. "
> 
> So, the current understanding is that the EAP MSK is
not used like a
> PSK. If you are interested in more details, please see
the messages
> under the following thread on the IPsec mailing list -
> http://www1.ietf.org/mail-archive/web/ipsec/cu
rrent/msg02164.html.

You are talking about MSK generated by
"EAP/IKEv2".
I am talking about MSK generated from EAP-based network
access
authentication. By the time we generate a key from MSK and
feed that as a
PSK to the IKEv2, for all practical purposes, that key is a
pre-shared key
(between the two end-points).


Alper


> 
> > > Today,
> > > IKEv2 allows the use of MSK purely for one
client authentication. An
> > > IKEv2 PSK, OTOH, could be used repeatedly for
a number of IKEv2
> > > exchanges between two entities.
> >
> > I'd appreciate more explanation on this too.
> >
> 
> Same as the above.
> 
> Vidya
> 
> > Alper
> >
> >
> >
> > >
> > > Vidya
> > >
> > > >
> > > > > The DH, combined with the minimum
of
> > > > > 6-message exchange for IKEv2-EAP
with every AR is extremely
> > > > impractical.
> > > > >
> > > > >
> > > > > For HMIPv6 or MIP6, the MAP/HA
changes do not occur
> > > > frequently enough
> > > > > for this to be an issue. Further,
from a practical deployment
> > > > > perspective, it is feasible to
overlap the MAP coverage
> > > > regions such
> > > > > that the IPsec SA can be
established with the new MAP
> > before the MN
> > > > > starts using the new MAP.
> > > >
> > > > Alper
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > > Vidya
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Vijay Devarapalli
> > [mailto:Vijay.DevarapalliAzaireNet.com]
> > > > > > Sent: Tuesday, November 21,
2006 12:15 PM
> > > > > > To: Alper Yegin
> > > > > > Cc: mipshopietf.org
> > > > > > Subject: RE: FMIPv6 Security
(was Re: [Mipshop]
> > Confirmation on
> > > > > > decision onHMIPv6 Security)
> > > > > >
> > > > > >
> > > > > > > > Alper Yegin wrote:
> > > > > > > > > If EAP/IKEv2 is
sufficient for HMIP, why not for FMIP as
> > > > > > > well? In other
> > > > > > > > > words, do we
still need FMIPv6 security solutions?
> > > > > > > >
> > > > > > > > I don't think one
would ever use IKEv2 with an
> > access router.
> > > > > > >
> > > > > > > Why? What's wrong with
IKEv2?
> > > > > >
> > > > > > I didn't say there is
something wrong with IKEv2.
> > > > > > I just don't see it being used
between a mobile node and
> > > > an access
> > > > > > router. IKEv2, like any other
protocol has its applicability
> > > > > > scenarios, and I don't see
FMIPv6 being one of them.
> > > > > >
> > > > > > I don't know what kind of
answer you were expecting
> > from me. 
> > > > > >
> > > > > > Vijay
> > > > > >
> > > > > >
_______________________________________________
> > > > > > Mipshop mailing list
> > > > > > Mipshopietf.org
> > > > > > https:
//www1.ietf.org/mailman/listinfo/mipshop
> > > > > >
> > > >
> > > >
> >
> >


_______________________________________________
Mipshop mailing list
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop

> > > Using network access authentication and worse
still, using
> > the EAP MSK
> > > for generating keys for FMIP is a layer
violation that doesn't fit
> > > with most models of network access being
deployed today.
> >
> > This deserves another thread, if you care to
explain us
> > why... I am not aware of the issue.
> >
> 
> This is related to the issue that Sam raised with
EMSK-based application
> keying, due to which that topic was removed from HOKEY.


EMSK-based application keying is removed from HOKEY charter?
Then, why are
the Hokey chairs soliciting input on WG adoption of
http://tools.ietf.org/wg/eap/draft-salowey-eap-
emsk-deriv-01.txt?


> MSK-based
> application keying muddles it even further, given that
the MSK is slated
> for a specific use, as per today's standards. 

All of the current specs using MSK take it as input and
generate other keys.
I understand that people claim this is potentially
problematic (key
collision???). But looking at the current standards using
MSK, I don't see
such a problem. 

Sorry, I really didn't understand your explanation of
"layer violation"
here.

Alper










_______________________________________________
Mipshop mailing list
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop

Hi Alper,
This will be the last message I send on this topic, since I
don't want
to be repeating myself here. Some points inline below. 

> -----Original Message-----
> From: Alper Yegin [mailto:alper.yeginyegin.org] 
> Sent: Monday, November 27, 2006 12:38 PM
> To: Narayanan, Vidya
> Cc: mipshopietf.org
> Subject: MSK and layer violation (was RE: FMIPv6
Security)
> 
> > > > Using network access authentication and
worse still, using
> > > the EAP MSK
> > > > for generating keys for FMIP is a layer
violation that 
> doesn't fit 
> > > > with most models of network access being
deployed today.
> > >
> > > This deserves another thread, if you care to
explain us 
> why... I am 
> > > not aware of the issue.
> > >
> > 
> > This is related to the issue that Sam raised with
EMSK-based 
> > application keying, due to which that topic was
removed from HOKEY.
> 
> EMSK-based application keying is removed from HOKEY
charter? 
> Then, why are the Hokey chairs soliciting input on WG 
> adoption of 
> http://tools.ietf.org/wg/eap/draft-salowey-eap-
emsk-deriv-01.txt?
> 

EMSK-based keying hierarchy is envisioned for EAP efficient
re-authentication purposes, which is one of the main charter
items for
HOKEY. This is the parent document for any such key
derivations and this
was work spilled over from the EAP WG. This document has a
bigger scope
than re-authentication and rightfully so (we want to make
the EMSK
hierarchy extensible for future uses). This has nothing to
do with
EMSK-based application keying itself and yes, EMSK-based
*application*
keying itself is not in the charter of HOKEY. I don't wish
to discuss
this further on the MIPSHOP list - please feel free to check
on the
HOKEY list. 

> 
> > MSK-based
> > application keying muddles it even further, given
that the MSK is 
> > slated for a specific use, as per today's
standards.
> 
> All of the current specs using MSK take it as input and

> generate other keys.
> I understand that people claim this is potentially 
> problematic (key collision???). But looking at the
current 
> standards using MSK, I don't see such a problem. 
> 
> Sorry, I really didn't understand your explanation of
"layer 
> violation"
> here.
> 

I will just reiterate that using an MSK meant for network
access to
generate keys for other purposes, IMHO, is a bad approach
and has
several issues. For one, the MSK is also used by the lower
layer. There
can be no co-ordinated key derivation between the lower
layer and
another layer that generates this key intended to be used
for IKEv2 or
FMIP. This is a big problem, since this means that using the
same root
key, different PRFs may be applied to arrive at child keys
for different
purposes - the lower layer will negotiate/use its own
algorithm for the
PRF it uses for TSK generation and we cannot possibly
specify something
that will work with any lower layer for IKEv2/FMIP use. 

There are other major issues as well, such as implications
to current
MSK usages, etc.  

OTOH, we are trying to define a co-ordinated key derivation
mechanism
for EMSK-based keys so that such a keying hierarchy can be
used in
future to derive other keys without an issue. MSK usage is
what it is
and there is nothing we can do about it. 

Vidya 

_______________________________________________
Mipshop mailing list
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop

> > > This is related to the issue that Sam raised
with EMSK-based
> > > application keying, due to which that topic
was removed from HOKEY.
> >
> > EMSK-based application keying is removed from
HOKEY charter?
> > Then, why are the Hokey chairs soliciting input on
WG
> > adoption of
> > http://tools.ietf.org/wg/eap/draft-salowey-eap-
emsk-deriv-01.txt?
> >
> 
> EMSK-based keying hierarchy is envisioned for EAP
efficient
> re-authentication purposes, which is one of the main
charter items for
> HOKEY. This is the parent document for any such key
derivations and this
> was work spilled over from the EAP WG. This document
has a bigger scope
> than re-authentication and rightfully so (we want to
make the EMSK
> hierarchy extensible for future uses). This has nothing
to do with
> EMSK-based application keying itself 

You are a co-author of that document and it says:

   Different applications for keys derived from the EMSK
have been
   proposed.  Some examples include hand off across access
points in
   various mobile technologies, mobile IP authentication and
higher
   layer application authentication.

> and yes, EMSK-based *application*
> keying itself is not in the charter of HOKEY. I don't
wish to discuss
> this further on the MIPSHOP list - please feel free to
check on the
> HOKEY list.

Sure, we can continue there. 

> > > MSK-based
> > > application keying muddles it even further,
given that the MSK is
> > > slated for a specific use, as per today's
standards.
> >
> > All of the current specs using MSK take it as
input and
> > generate other keys.
> > I understand that people claim this is potentially
> > problematic (key collision???). But looking at the
current
> > standards using MSK, I don't see such a problem.
> >
> > Sorry, I really didn't understand your explanation
of "layer
> > violation"
> > here.
> >
> 
> I will just reiterate that using an MSK meant for
network access to

MSK is typically used for network access. But I don't see
any spec limiting
its use to network access. 


> generate keys for other purposes, IMHO, is a bad
approach and has
> several issues. For one, the MSK is also used by the
lower layer. There
> can be no co-ordinated key derivation between the lower
layer and
> another layer that generates this key intended to be
used for IKEv2 or
> FMIP. 

What kind of coordination are we seeking? We'd like to
ensure that each
consumer ends up with different keys, right? Anything else?
If that's it, as
far as I know, the existing MSK consumers are already using
PRFs that take
some unique string into account. We could have had a problem
there. But by
design, there is no such problem.

 
> This is a big problem, since this means that using the
same root
> key, different PRFs may be applied to arrive at child
keys for different
> purposes - the lower layer will negotiate/use its own
algorithm for the
> PRF it uses for TSK generation and we cannot possibly
specify something
> that will work with any lower layer for IKEv2/FMIP use.
> 
> There are other major issues as well, such as
implications to current
> MSK usages, etc.

Please elaborate. It's hard for us to agree with your
conclusion unless you
substantiate your claims.


> OTOH, we are trying to define a co-ordinated key
derivation mechanism
> for EMSK-based keys so that such a keying hierarchy can
be used in
> future to derive other keys without an issue. MSK usage
is what it is
> and there is nothing we can do about it.

I think what we are aiming to do with EMSK is good. But I'm
not convinced
that MSK is dead for all such purposes. And relying on EMSK
has additional
cost (e.g., due to its unavailability to NAS, there is
additional signaling
required between the NAS and HAAA even if the child key is
needed locally at
the NAS).

Alper



> 
> Vidya


_______________________________________________
Mipshop mailing list
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop