add and change

CAO, ZHEN caozhenpku at gmail.com
Thu Nov 2 09:54:35 EST 2006


I have add and change some words. see "add" and "change"

Thanks
Zhen

Thanks for reading our draft and providing valuable feedbacks.



I've read the I-D draft-deng-mipshop-hmip-hhokey-00.txt. Here is my
feedback.

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 has been chartered in the security area, there should 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.

There appears to be dependency on yet-to-be-designed protocols.



Yes, we will add some details of our mechanism if the experts in this WG
feel that the handover key is really a problem in mipshop.



Add:  Yes, many keys are used in our draft without detailed definition
because we assume the readers are familiar with the handover key ps draft
(draft-nakhjiri-aaa-hokey-ps-03)


See below for more details.





The handover within one MAP is described 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.



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

Change: 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
(draft-nakhjiri-aaa-hokey-ps-03). 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.




So, this scheme relies on Ho* messages. Where are they defined?
we will define them in the later version of this draft.


Alper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20061102/bd5ef58a/attachment.htm 


More information about the HostAP mailing list