+AFs-Mipshop+AF0- Comments on drafts of hmip sa and hmipv6 security

Hello, Alper

Thanks for your reply.

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

+AD4- 
+AD4- +AD4- Furthermore draft-yegin-hmip-sa-00.txt, whether
we need dervie 
+AD4- +AD4- hmip-key from MSK will be the question. isn't
USRK better than MSK?
+AD4- 
+AD4- The advantage of using MSK is, it is already available
to the 
+AD4- access networks. All the necessary protocol extensions
can be 
+AD4- limited to the access network that hosts the mobiles,
NAS, 
+AD4- and the MAP. Unless there are technical problems with
using 
+AD4- MSK, this approach is more readily deployable than
relying on 
+AD4- 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.

+AD4- +AD4- Regarding to security guarantee of HMIP, and if
EAP is 
+AD4- considered, a 
+AD4- +AD4- full eap authentication procedure is not
necessary each handover, a 
+AD4- +AD4- handover key could be used to enhance this
performance, 
+AD4- which has been 
+AD4- +AD4- described in our draft:
draft-deng-mipshop-hmip-hhokey-00.txt
+AD4- 
+AD4- Do you see any specific reason for doing it otherwise
with 
+AD4- 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
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop

Hui,

> Sorry for my previous explanation is not clear, here I
want to ask
> how the first SPD include ciphersuite are made from?

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

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

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


> > > 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
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop

Hi Zhen,

 
You mean use IKE to negotiate the SA, then what is the usage
of your
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



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

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


> > > 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
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop 



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

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

Alper Yegin wrote:
> Hi Zhen,
> 
>  
> You mean use IKE to negotiate the SA, then what is the
usage of your
> 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
> 
> 
> 
>>>> 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.
> 
> 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
> 
> 
>>>> 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
> 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

Hi Zhen,

 
You mean use IKE to negotiate the SA, then what is the usage
of your
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



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

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


> > > 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
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop 



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

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

Alper Yegin wrote:
> Hi Zhen,
> 
>  
> You mean use IKE to negotiate the SA, then what is the
usage of your
> 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
> 
> 
> 
>>>> 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.
> 
> 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
> 
> 
>>>> 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
> 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

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

Yes.

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

No.

Alper


> 
> Vijay
> 
> Alper Yegin wrote:
> > Hi Zhen,
> >
> >
> > You mean use IKE to negotiate the SA, then what is
the usage of your
> > 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
> >
> >
> >
> >>>> 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.
> >
> > 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
> >
> >
> >>>> 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
> > 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

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

Yes.

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

No.

Alper


> 
> Vijay
> 
> Alper Yegin wrote:
> > Hi Zhen,
> >
> >
> > You mean use IKE to negotiate the SA, then what is
the usage of your
> > 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
> >
> >
> >
> >>>> 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.
> >
> > 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
> >
> >
> >>>> 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
> > 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