Subject: RE: FMIPv6 Security (was Re: [Mipshop] Confirmation on decision on HMIPv6 Security)

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 21 Nov 2006 12:15:08 -0800

> > 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 21 Nov 2006 15:26:22 -0800

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:[email-masked]] 
> Sent: Tuesday, November 21, 2006 12:15 PM
> To: Alper Yegin
> Cc: [email-masked]
> Subject: RE: FMIPv6 Security (was Re: [Mipshop] Confirmation 
> on decision onHMIPv6 Security)
> 
>  
> > > Alper Yegin wrote:
> > > I don't think one would ever use IKEv2 with an access router.
> > 
> 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
>

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Wed, 22 Nov 2006 13:47:15 +0100

Hi,

> 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.

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 22 Nov 2006 22:38:47 +0200

Vijay,

> 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

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 22 Nov 2006 22:56:35 +0200

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

Alper

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 22 Nov 2006 13:48:26 -0800

Alper,

> 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

> > > Subject: RE: FMIPv6 Security (was Re: [Mipshop] Confirmation on 
> > > decision onHMIPv6 Security)
> > >
> > >
> > > > > Alper Yegin wrote:
> > > 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.
> > >

---

From: "James Kempf" <[email-masked]>
Date: Wed, 22 Nov 2006 14:09:55 -0800

Another point to consider here is that when RFC 4068 was under review by the 
IESG, I believe Steve Bellovin, who was a Security AD at the time, requested 
that text in the Security Considerations sections about using IPsec be taken 
out. It might be a good idea to check back through Draft Tracker to see if 
Steve filed a DISCUSS comment. Though Steve is no longer on the IESG, I 
doubt the current Security ADs would change their opinion on this point.

               jak

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 22 Nov 2006 14:20:06 -0800

>From the IETF tracker, here is what Steve B said - "For an Experimental
RFC, the security discussion is adequate.  It is *not* adequate for a
standards track document.  The suggested work on security MUST take
place.  I caution the authors that many of the AH security associations
mentioned in the text are going to be very hard to set up, since the
mobile node may have no a priori way to determine the authorized Access
Routers." 

And, that applies to ESP just as much as it applies to AH. And, that is
exactly the problem we have been talking about here as well. 

Vidya 

> From: James Kempf [mailto:[email-masked]] 
> Sent: Wednesday, November 22, 2006 2:10 PM
> To: Narayanan, Vidya; Alper Yegin; Vijay Devarapalli
> Cc: [email-masked]
> Subject: Re: FMIPv6 Security (was Re: [Mipshop] Confirmation 
> on decisiononHMIPv6 Security)
> 
> Another point to consider here is that when RFC 4068 was 
> under review by the IESG, I believe Steve Bellovin, who was a 
> Security AD at the time, requested that text in the Security 
> Considerations sections about using IPsec be taken out. It 
> might be a good idea to check back through Draft Tracker to 
> see if Steve filed a DISCUSS comment. Though Steve is no 
> longer on the IESG, I doubt the current Security ADs would 
> change their opinion on this point.
> 
>                jak 
> 
>

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 23 Nov 2006 18:33:48 +0200

> mobile node may have no a priori way to determine the authorized Access

Sure that makes sense going back to RFC 4068 era. But now that we have
"discovered" use of EAP/IKEv2, I think this concern is resolved.

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 23 Nov 2006 19:16:21 +0200

Hi Vidya,

> 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.

> 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.

> 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.

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

I'd appreciate more explanation on this too. 

Alper

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 23 Nov 2006 13:24:57 -0800

Hi Vidya,

> 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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 27 Nov 2006 10:41:56 -0800

Hi Rajeev, 

> 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.
> 

I should have said that I am not aware of any operator wanting to run
FMIP at the moment. If anyone is aware of an operator thinking of FMIP,
I'm interested in hearing about it. The only reason I've heard is the
signaling part. 

> 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.
> 

I agree with the above. However, we have to look at the alternatives and
see if those are any better/faster/more efficient. I think FMIP has
value for inter-technology handoffs between border ARs. Within the same
technology, we are likely to see just network-based edge tunnels setup
and torn down quickly based on L2 IDs. There is really no reason to
involve the MN in signaling for short-lived edge tunnels. 

For inter-technology handoffs, that is normally facilitated by having
multiple radios on the mobile - if so, there needs to be overlapping
coverage areas between those technologies to even have a seamless
handoff to begin with (if there are gaps at the PHY layer, nothing we do
will make the handoff seamless). If there is overlapping coverage, one
can envision setting up the FMIP tunnel and then using the new
interface. Even there, it needs to be rather quick - but, something at
the IP layer is needed, since the L2 IDs are not compatible across
technologies. One could argue that if the inter-technology coverage is
overlapping, there may be sufficient time to update the MIP binding and
hence, no FMIP is needed. That remains to be seen. But, I do think that
FMIP is a good candidate for inter-technology fast handoffs. 

> draft-ietf-mipshop-3gfh-01.txt

IMHO, that is not FMIP. It is a new protocol with its own messages. It
doesn't seem to have anything in common with RFC4068. I do think that a
network-based flavor of FMIP would be useful to standardize, but, that's
not RFC4068 or rfc4068bis. 

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

Yes, this was the ultimate message I was trying to convey :) 

Vidya

> -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.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 27 Nov 2006 10:48:01 -0800

> 
> > From the IETF tracker, here is what Steve B said - "For an 
> > Experimental RFC, the security discussion is adequate.  It is *not* 
> > adequate for a standards track document.  The suggested work on 
> > security MUST take place.  I caution the authors that many 
> of the AH 
> > security associations mentioned in the text are going to be 
> very hard 
> > to set up, since the mobile node may have no a priori way 
> to determine 
> > the authorized Access Routers."
> 
> Sure that makes sense going back to RFC 4068 era. But now 
> that we have "discovered" use of EAP/IKEv2, I think this 
> concern is resolved.
> 

No. As per RFC4306, EAP is only a form of client (IKEv2 initiator)
authentication. IKEv2 responders are supposed to use certificates. So,
there is nothing that EAP/IKEv2 does to allieviate this specific
concern. 

Vidya

> > And, that applies to ESP just as much as it applies to AH. 
> And, that 
> > is exactly the problem we have been talking about here as well.
> 
> Alper
> 
> 
> 
> > 
> > Vidya
> > 
> > > Subject: Re: FMIPv6 Security (was Re: [Mipshop] Confirmation on 
> > > decisiononHMIPv6 Security)
> > >
> > > Another point to consider here is that when RFC 4068 was under 
> > > review by the IESG, I believe Steve Bellovin, who was a 
> Security AD 
> > > at the time, requested that text in the Security Considerations 
> > > sections about using IPsec be taken out. It might be a 
> good idea to 
> > > check back through Draft Tracker to see if Steve filed a DISCUSS 
> > > comment. Though Steve is no longer on the IESG, I doubt 
> the current 
> > > Security ADs would change their opinion on this point.
> > >
> > >                jak
> > >
> > >
> 
>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 27 Nov 2006 11:09:11 -0800

Hi Alper,

> From: Alper Yegin [mailto:[email-masked]] 
> Sent: Thursday, November 23, 2006 9:16 AM
> To: Narayanan, Vidya; 'Vijay Devarapalli'
> Cc: [email-masked]
> > > > 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?
> > >
> > 
> 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. 

> > > 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. 

> > 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.
> > >
> > 

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/current/msg02164.html. 

> I'd appreciate more explanation on this too. 

Same as the above. 

Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 27 Nov 2006 11:29:38 -0800

Hi Rajeev,

> From: Rajeev Koodli [mailto:[email-masked]] 
> Sent: Monday, November 27, 2006 11:23 AM
> We have some results on WLAN and EV-DO VoIP handovers which 
> suggest the need for something faster than MIP Binding 
> Update. The paper is under submission.
> 

When you have it, I'd be interested in reading the paper. Also, I agree
that we need something faster than MIP for seamless handoffs. The
question was about whether we need MN involvement and I think we are in
agreement about that. 

> The decision to involve a MN in signaling is 
> deployment-specific (which includes "market dynamics", case 
> in point PMIP). I am okay with taking the base FMIP protocol 
> and adapting it as such. It would not be desirable to go off 
> and spend many months (or years) re-designing a "new 
> protocol" under the pretext of network-based signaling. If 
> you think through it, you will perhaps realize that there is 
> not much more to do from a protocol design standpoint. So, I 
> hope we pool our energies together to standardize one good 
> design and let the industry take its own course on deployment.
> 

No disagreement here. I also think that a network-based design doesn't
require too much more - it is a question of adapting FMIP for such a
design. 

> I agree that the messages in network-controlled signaling in 
> draft-3gfh need to be harmonized with FMIP signaling; I don't 
> understand why they are not HI and HAck. 
> 
> Finally, we should work on IP-based protocols here, 
> acknowledging and even adapting such protocols over some 
> specific link layers of interest. That's what we are doing 
> here in MIPSHOP (bis, fmip-over-XX). That's what we in an 
> IETF WG are arguably capable of doing. Deployments are 
> another thing and while they clearly matter to us, the 
> parameters there are far broader than we can effectively 
> address here. So, I would not want to be all carried away by 
> that. Let's stick to good protocol design, making use of 
> meaningful input.
> 

Agreed. I was only trying to stress that we should not be requiring 6
messages to establish FMIPv6 security. 

Regards,
Vidya

> Thanks,
> 
> -Rajeev
> 
> 
> 
> On 11/27/06 10:41 AM, "ext Narayanan, Vidya" 
> <[email-masked]> wrote:
> 
> > Hi Rajeev,
> > 
> >> 
> >> Hi Vidya,
> >> 
> >>> 
> evidence? I ask 
> > FMIP at the moment. If anyone is aware of an operator thinking of 
> > FMIP, I'm interested in hearing about it. The only reason 
> I've heard 
> > is the signaling part.
> > 
> >> 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.
> >> 
> > 
> > I agree with the above. However, we have to look at the 
> alternatives 
> > and see if those are any better/faster/more efficient. I think FMIP 
> > has value for inter-technology handoffs between border ARs. 
> Within the 
> > same technology, we are likely to see just network-based 
> edge tunnels 
> > setup and torn down quickly based on L2 IDs. There is 
> really no reason 
> > to involve the MN in signaling for short-lived edge tunnels.
> > 
> > handoff to begin with (if there are gaps at the PHY layer, 
> nothing we 
> > do will make the handoff seamless). If there is overlapping 
> coverage, 
> > one can envision setting up the FMIP tunnel and then using the new 
> > overlapping, there may be sufficient time to update the MIP binding 
> > and hence, no FMIP is needed. That remains to be seen. But, 
> I do think 
> > that FMIP is a good candidate for inter-technology fast handoffs.
> > 
> > doesn't seem to have anything in common with RFC4068. I do 
> think that 
> > a network-based flavor of FMIP would be useful to standardize, but, 
> > that's not RFC4068 or rfc4068bis.
> >

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 27 Nov 2006 22:15:46 +0200

> there is nothing that EAP/IKEv2 does to allieviate this specific

EAP usage in this particular scenario provides assurance of "AR
authorization" as much as any other EAP-based architecture/deployment
provides assurance of "NAS/access network authorization" for simple network
access service. If you claim we don't have former, we can't have latter
either -- hence we should have a much bigger fish to fry. But that's not the
case. Through the trust between the AAA client (AR) and AAA server (HAAA),
deployments achieve AR/NAS/authenticator authorization.

Alper

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 27 Nov 2006 12:25:55 -0800

> EAP usage in this particular scenario provides assurance of 
> "AR authorization" as much as any other EAP-based 
> architecture/deployment provides assurance of "NAS/access 
> network authorization" for simple network access service. If 
> you claim we don't have former, we can't have latter either 

No, this is not true. When EAP methods with mutual authentication
capabilities are used, the peer and server authenticate each other and
the authenticator is indirectly authenticated (although without channel
bindings, this is somewhat loose). But, most importantly, when key
generating EAP methods are used for access control, the MSK is used to
derive a TSK that is then used by the peer and authenticator to prove
possession of the same MSK (which is what makes channel binding not so
crucial). However, in the case of IKEv2, the MSK is only used for
generating the AUTH payload by the client. The server uses its
public/private key pair to generate the AUTH payload - so, there is no
symmetric proof of possession of the MSK in the case of IKEv2 by both
parties. 

Vidya

> -- hence we should have a much bigger fish to fry. But that's 
> not the case. Through the trust between the AAA client (AR) 
> and AAA server (HAAA), deployments achieve 
> AR/NAS/authenticator authorization.
> 
> Alper
> 
> 
> 
> > 
> > Vidya
> > 
> >

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 27 Nov 2006 22:27:21 +0200

> 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.

> http://www1.ietf.org/mail-archive/web/ipsec/current/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

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 27 Nov 2006 22:37:41 +0200

> 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

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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 27 Nov 2006 12:45:30 -0800

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. 

> Sent: Monday, November 27, 2006 12:38 PM
> To: Narayanan, Vidya
> Cc: [email-masked]
> Subject: MSK and layer violation (was RE: FMIPv6 Security)
> 
> > 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 

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.
> 
> 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. 
> 

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 27 Nov 2006 16:30:39 -0500

On Mon, Nov 27, 2006 at 12:25:55PM -0800, Narayanan, Vidya wrote:
(snip)
> symmetric proof of possession of the MSK in the case of IKEv2 by both

This is not correct reading of RFC 4306.  There is mutual proof of
possession of the MSK in the case of IKEv2.  The initiator and the
responder use MSK to generate the AUTH payload in messages 7 and 8,
while the responder uses public/private key pair to generate the AUTH
payload in message 4.

Yoshihiro Ohba

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 27 Nov 2006 13:46:36 -0800

Hi Yoshi,
 
> This is not correct reading of RFC 4306.  There is mutual 
> proof of possession of the MSK in the case of IKEv2.  The 
> initiator and the responder use MSK to generate the AUTH 
> payload in messages 7 and 8, while the responder uses 
> public/private key pair to generate the AUTH payload in message 4.
> 

Yes, you are right. Thanks for pointing this out - I missed the AUTH
payload in message 8. 

Regardless, the other issues with running IKEv2 with ARs still remain. 

Thanks,
Vidya

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 27 Nov 2006 11:23:23 -0800

Hi Vidya,

We have some results on WLAN and EV-DO VoIP handovers which suggest the need
for something faster than MIP Binding Update. The paper is under submission.

The decision to involve a MN in signaling is deployment-specific (which
includes "market dynamics", case in point PMIP). I am okay with taking the
base FMIP protocol and adapting it as such. It would not be desirable to go
off and spend many months (or years) re-designing a "new protocol" under the
pretext of network-based signaling. If you think through it, you will
perhaps realize that there is not much more to do from a protocol design
standpoint. So, I hope we pool our energies together to standardize one good
design and let the industry take its own course on deployment.

I agree that the messages in network-controlled signaling in draft-3gfh need
to be harmonized with FMIP signaling; I don't understand why they are not HI
and HAck. 

Finally, we should work on IP-based protocols here, acknowledging and even
adapting such protocols over some specific link layers of interest. That's
what we are doing here in MIPSHOP (bis, fmip-over-XX). That's what we in an
IETF WG are arguably capable of doing. Deployments are another thing and
while they clearly matter to us, the parameters there are far broader than
we can effectively address here. So, I would not want to be all carried away
by that. Let's stick to good protocol design, making use of meaningful
input.

Thanks,

-Rajeev

---

From: Ashutosh Dutta <[email-masked]>
Date: Mon, 27 Nov 2006 19:19:09 -0500

Rajeev,
         I think use of FMIP for a mobile with a single interface would 
be more compelling than  use of  FMIP with a mobile with dual interface 
(e.g., WLAN and EV-DO)using make-before-break mode. I am assuming the 
neighboring cells are overlapping in both the cases.

In earlier days, I have done some experiment using MIPv4 and SIP 
mobility to move between 802.11 and CDMA network using make-before-break 
technique and we did not notice any packet loss during the handover 
between 802.11 and CDMA networks. We however noticed packets getting 
delayed at the start of CDMA connection because of dormant mode. I have 
not tried similar experiment using MIPv6 however.

Results of your experiment must be interesting and would be of value to 
the community.

Regards
Ashutosh

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 27 Nov 2006 20:22:19 -0800

> by that. Let's stick to good protocol design, making use of meaningful

strongly agree.

Vijay

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 28 Nov 2006 16:56:43 +0200

> 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*

Sure, we can continue there. 

> 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. 

> 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

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

> 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

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 28 Nov 2006 16:58:13 +0200

> Regardless, the other issues with running IKEv2 with ARs still remain.

What issues are left in your mind? We went over all of them and I don't see
any outstanding issue.

Alper