Subject: [Mipshop] RE: +AFs-Mipshop+AF0- Review draft-deng-mipshop-hmip-hhokey-00

From: "DENG, HUI -HCHBJ" <[email-masked]>
Date: Thu, 2 Nov 2006 23:05:57 +0800

Hello, Alper

> I've read the I-D draft-deng-mipshop-hmip-hhokey-00.txt. Here 
> is my feedback.
==>Thanks for reading our draft and providing valuable feedbacks.

> Overall, I'm not sure we are talking about the same problem 
> space. For example, sending keys to AR does not appear 
> relevant to me if we are talking about HMIP security.

==>Yes, we are not talking about the same problem space. 
What we want to do is put some insight on the handover problem
 in the scenario of mip, since a new working group Hokey 
has been chartered in the security area, there might be some place
to discuss the applicability of their mechanisms. 

> There are many "keys" being passed around. But there are not 
> enough details to know what those keys are used for, let 
> alone the formula to compute the keys.
==>we will update that in the next version.

> There appears to be dependency on yet-to-be-designed protocols.
==>Yes, but all are processing now.

> See below for more details.
> 
> 
>    The handover within one MAP is decribed in Figure 1.  The MN was
>    originally authenticated to AR1 with a full EAP exchange.  Then the
>    AAA server pushes the corresponding key to the MAP.  
> 
> What's that "corresponding key?" MAP is not on-path with the 
> AAA signaling. Therefore, there needs to be additional 
> protocol design to accommodate such an operation. This has 
> impact on RADIUS/Diameter.

==>The corresponding key refers to the key delivered from the AAA
 to the MAP (ADMSK in draft-nakhjiri-aaa-hokey-ps-03). 
We put some considerations in section 4. When the MAP is off-path
 with respect to EAP signaling, there needs to be additional protocol. 

> 
> 
>    According to its
>    configuration, the MAP pushes the keys to the ARs within its
>    administrative domain.  
> 
> What are those keys? What are they used for? In the context 
> of "HMIP6" where MAP is not on the AR, why do we need to deal 
> with any keys going to the ARs?

==>The MAP pushes the master keys (LSAP_MK) for the ARs,
 so that the MN can authenticate to the AR when it moves to the target AR. 

> 
>    When the MN attaches to another AR (e.g.  AR2
>    in Figure 1), the MN and AR2 assert their knowledge of the
>    corresponding LSAP_MK by exchanges of the Secure 
> Association Protocol
>    (SAP), after which they arrive at the consensus of the LSK.
> 
> 
> What's LSAP_MK, LSK? Are they really relevant to "HMIP6 security?"

==> They are terminologies in the handover key hierarchy. 
LSAP_MK is short for Link Secure Associate Protocol Master Key, 
and LSK is short for Link Session Key. They are used to authenticate
 the MN to the AR in a security association protocol. Actually they are 
not relevant to HMIPv6 security now, but may be in the future. 

> 
> 
> 
>    MN           MAP1           MAP2            AAA
>    |    HoReq     |              |              |
>    |------------->|          HokeyReq           |
>    |              |---------------------------->|
>    |              |              |   HokeyRep   |
>    |              |   HokeyConf  |<-------------|
>    |    HoAck     |<-------------|              |
>    |<-------------|              |              |
>    |              |              |              |
>    |              |              |              |
>    |<==========  SAP  ==========>|              |
>    |              |              |              |
> 
> 
> 
> So, this scheme relies on Ho* messages. Where are they defined? 
==> we will define them in the later version of this draft. 

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