Subject: [Mipshop] RE: +AFs-Mipshop+AF0- Comments on drafts of hmip sa and hmipv6 security

From: "DENG, HUI -HCHBJ" <[email-masked]>
Date: Mon, 30 Oct 2006 18:17:07 +0800

Hello, Alper

Thanks for your reply.

> > draft-yegin-hmip-sa-00.txt defined HMIP-SPI and increase by 1 per 
> > authentication, so how to get the common initial SPI which 
> could not 
> > be out of the scope of this draft.
> 
> It is already defined in Section 2.
> 
>    HMIP-SPI value MUST be set to 1 upon initial EAP 
> authentication with
>    the authenticator, increased by 1 for each subsequent EAP re-
>    authentication with the same authenticator, and set back to 1 after
>    wrapping around.
Sorry for my previous explanation is not clear, here I want to ask
how the first SPD include ciphersuite are made from?

> 
> > Furthermore draft-yegin-hmip-sa-00.txt, whether we need dervie 
> > hmip-key from MSK will be the question. isn't USRK better than MSK?
> 
> The advantage of using MSK is, it is already available to the 
> access networks. All the necessary protocol extensions can be 
> limited to the access network that hosts the mobiles, NAS, 
> and the MAP. Unless there are technical problems with using 
> MSK, this approach is more readily deployable than relying on 
> yet-to-be defined USRK and its delivery across the Internet.
Normally MSK will be used to derive TSK, if we use MSK in other scenario.
it may leak some security issue.

> > Regarding to security guarantee of HMIP, and if EAP is 
> considered, a 
> > full eap authentication procedure is not necessary each handover, a 
> > handover key could be used to enhance this performance, 
> which has been 
> > described in our draft: draft-deng-mipshop-hmip-hhokey-00.txt
> 
> Do you see any specific reason for doing it otherwise with 
> the draft-yegin-hmip-sa-00.txt?
We both assume EAP is needed.

Many thanks

-Hui

Disclaimer:
The contents of this e-mail, and its attachments, if any, are confidential and may be protected
by law against any unauthorized use.  If you have received this e-mail by mistake or have
reason to believe that you are not the intended recipient, please notify the sender by reply
e-mail as soon as possible and delete it from your computer system immediately thereafter.
If you are not the intended recipient, you must not copy this e-mail or attachment or disclose
the contents to any other person.  While we have made every effort to keep our network virus free,
we take no responsibility for any computer virus which might be transferred by way of this e-mail.

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 30 Oct 2006 12:38:41 +0200

Hui,

> how the first SPD include ciphersuite are made from?

Dynamic negotiation of ciphersuite should be handled by IKE for MIP6/HMIP6.

> it may leak some security issue.

MSK would be the parent key. With the proper key derivation, presence of
other children keys (e.g., TSK) shall not weaken the strength of HMIP-key. 

Alper

---

From: "CAO, ZHEN" <[email-masked]>
Date: Mon, 30 Oct 2006 21:22:52 +0800

Hi Alper and Hui,

I have questions related to your discussion inline. Could you help to
clarify?

Many thanks,
Zhen

> Dynamic negotiation of ciphersuite should be handled by IKE for

You mean use IKE to negotiate the SA, then what is the usage of your
protocol? Again, IMO, IKE needs preshared keys deployed on the two entities
envolved, how to arrive at the preshared keys?

> > The contents of this e-mail, and its attachments, if any, are
> confidential
> > and may be protected
> > by law against any unauthorized use.  If you have received this e-mail
> by
> > mistake or have
> > the contents to any other person.  While we have made every effort to
> keep
> > our network virus free,

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 30 Oct 2006 17:48:13 +0200

Hi Zhen,

protocol? 

   The current Hierarchical Mobile IPv6 (HMIP) protocol [RFC4140] lacks
   a mechanism to secure the signaling between the mobile node (MN) and
   the mobility anchor point (MAP).  At the core of this problem is the
   absence of a security association (SA) between the two nodes.  When
   the SA is present, it can be utilized along with IKEv2/IPsec
   [I-D.ietf-mip6-ikev2-ipsec] or the mobility authentication option
   [RFC4285] to provide authentication and integrity protection for the
   protocol messages.

Alper> So, the I-D describes how the SA required by the IKE is generated.

Again, IMO, IKE needs preshared keys deployed on the two entities envolved,
how to arrive at the preshared keys?  

Alper> As described in Section 2.1

Alper

MSK would be the parent key. With the proper key derivation, presence of
other children keys ( e.g., TSK) shall not weaken the strength of HMIP-key.

Alper

> The contents of this e-mail, and its attachments, if any, are confidential

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 30 Oct 2006 07:59:30 -0800

hi Alper,

please allow me to re-phrase some of the questions.

IKEv2 is a key negotiation protocol. what is needed in
the context of HMIPv6 is a way for the MN and the MAP
to mutually authenticate each other. does
draft-yegin-hmip-sa-00.txt describe a mechanism to
dynamically provision the MN and the MAP with a shared
key that can be used later in IKEv2 authentication?

or is the idea to use the HMIP-key
[draft-yegin-hmip-sa-00.txt] directly in an IPsec SA?
in this case, there is no need to run IKEv2 between
the MN and the MAP.

Vijay

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 31 Oct 2006 01:02:06 +0200

> key that can be used later in IKEv2 authentication?

Yes.

> in this case, there is no need to run IKEv2 between

No.

Alper

> >> reason to believe that you are not the intended recipient, please
> notify
> >> the sender by reply

---

From: "CAO, ZHEN" <[email-masked]>
Date: Tue, 31 Oct 2006 16:53:15 +0800

Hi Alper,

> Alper> So, the I-D describes how the SA required by the IKE is generated.

then, IKE relies on the scheme specified in your I-D?

> Dynamic negotiation of ciphersuite should be handled by IKE for

then, the scheme specified in your I-D relies on the IKE?

Many thanks,
Zhen

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 31 Oct 2006 14:37:12 +0200

Alper2> Yes. 

Alper2> No. Or scheme is not the one that relies on IKE. It's the "HMIP6"
specification that relies on IKE.

Alper

Many thanks,

Zhen