[Mipshop] Re: AD review of draft-ietf-mipshop-handover-key

This is very problematic. If I understand this correctly, it means that
the MN can pick a key pair and address and defend them in the
RtPrSol, but is unable to do so for regular ND operations on the
link. And you need to use ND operations on the link. Also, at
the same time any use of the given care of address with CGA
based techniques (SHIM6, RFC 4866) becomes impossible.

Did I get this correctly? If yes, I think we need to do something
about it.

jak>> No, that is not the case. The intent is that the MN uses SEND NS/NA to 
defend the address, generates the address with the SEND public key, then 
uses the CGA as a source address in the RtPrSol . The signature on the 
RtPrSol ensure that the message came from the claimed address. The handover 
key encryption public key is included for the router to use only in 
encrypting the return key. In effect, the use of the CGA and SEND signature 
on the RtPrSol is no different than it would be on, for example, RS.

jak>> It is not the intent of handover keys to provide an alternate 
mechanism for claiming and defending an address. The CGA must be one that is 
generated with the SEND key and defended in the usual SEND fashion.

jak>> If this is not clear from the current text, then perhaps you can 
suggest a place where some additional text could be added to clarify?

Is the RSA vulnerability an issue for the key in question? What
if there was key pair P that was used to derive the care of address,
and to certify key pair Q. Both P and Q were included in RtPrSol,
and only Q would be used for encryption in RtPrAdv? But I'm
just thinking aloud here...

jak>> The RSA vulnerability is only an issue if the same key pair is used 
for encryption and authentication, regardless of the key pair. The reason 
why we changed the design to use a different key from the SEND key was 
because of this vulnerability.

jak>> I suppose we could use both keys to generate the address, but that 
would change SEND, and I don't see any need for it. As long as the router 
has cryptographic assurance that the RtPrSol originated from the claimed 
source address and that the originator is the owner of that source address 
(which is provided by the CGA and SEND signature) then it can couple the 
shared handover key to the address. The encryption key is just used for 
security on the transport of the shared handover key, it plays no other 
role. Or am I missing something?

No. I don't remember if RFC 4866 had something similar, you may
want to copy from there if it did.

jak>> OK, I'll check that.

                 jak 

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