[Mobopts] Comments on draft-kempf-mobopts-ringsig-ndproxy-02.txt

[Jari Arkko <[e-mail]>]

Hi James,

I read the draft... I liked it a lot, a very nice scheme for
a hard problem!

Some comments and questions, though:

> Prior to verifying the CGA or signature, the verifying node MUST 
> check that the router public key in the CGA Parameters Option matches 
> a certified public key from a router on the link. This step assures 
> that the keys used in signing the signature are both legitimate 
> members of the group, which in this case consists of the node owning 
> the address and a certified router on the link. If this step is not 
> taken, an attacker not authorized to route can sign a message with 
> its own key and the victim node's public key, then claim to securely 
> proxy the address on the victim's behalf. 
>  
>
I don't see how this attack could be done, because if both
keys are a part of the CGA parameters then changing either
one will change the address.

Of course, you may still want to check that the proxy is
a legitimate proxy from your point of view. Just because
the peer delegated the responsibility to someone may
not imply that you want to trust that someone. But this
appears to be a different issue than the one that you
talk about above.

>        If a multi-CGA capable node receives a message with a standard RFC 
>        3971 RSA Signature Option but the CGA Parameters Option contains an 
>        RST Ring Signature Key Suboption, the node SHOULD ignore the RST Ring 
>        Signature Option and treat the message like a standard RFC 3791 SEND-
>        secured message. The node SHOULD use the standard RSA signature 
>        verification algorithm and the key in the Public Key Field of the CGA 
>        Parameters Option to verify the signature. 
>  
>
Ignore? As in delete it from the contents of the CGA Parameters
Option, or keep it there but not do anything special for it?

>           concat-val =  SHA1(pk(1) | pk(2) | ... | pk(n) )  
>
Is this necessary, if the other keys are in the CGA parameters
block? They would be included as input for the same output
value from Step 2 of RFC 3971 Section 4 algorithm, as far as
I can see.

>        The Secure Proxy Mobility Option has the following format: 

Is there a need to include other information that is
used in the calculation of the final address, such as
the modifier?

Editorial:

>        and 6 in Section 5. In both steps, instead of calculating the has 
>
s/has/hash/

--Jari


_______________________________________________
Mobopts mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mobopts