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

["James Kempf" <[e-mail]>]

>> 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.
>

Actually, that is exactly the issue I wanted to address I just didn't 
describe it correctly. I think I could probably make this a SHOULD. Thanx!

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

RFC 3972 requires extensions to the CGA Parameters option to be concatenated 
into the calculation for verification. So what I think needs to be done is 
that, for the purposes of verification, it should not be included in the 
calculation.

This part of RFC 3972 may need some attention. I don't remember what Tuomas 
and the WG had in mind with this, but the extensions field is 
underspecified. If it is treated like a standard protocol extension field, 
there will be TLV values for the extensions, and this is how the multi-key 
CGA draft treats it. But the way it is incorporated into the verification 
calculations implies that it is rather some bits that don't have any 
specific field-like structure or any identifying information as to what the 
extension is. Should such TLV bits be included into the calculation? They 
aren't for the base key, 3792 specifies specifically when the encoded public 
key is used (c.f. Section 4, Step 2).

>>           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.
>

I think you mean 3972.

Again, it depends on how the extension field is treated.

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

Right, thanx for catching this. Also the subnet prefix, since the home link 
may support more than one subnet, and the collision count.

            jak 



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