Hello,
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.
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.
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.
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?
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?"
MN MAP1 MAP2 AAA
| HoReq | | |
|------------->| HokeyReq |
| |---------------------------->|
| | | HokeyRep |
| | HokeyConf |<-------------|
| HoAck |<-------------| |
|<-------------| | |
| | | |
| | | |
|<========== SAP ==========>| |
| | | |
So, this scheme relies on Ho* messages. Where are they
defined?
Alper
_______________________________________________
Mipshop mailing list
Mipshop ietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop
|