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

From: Jari Arkko <[email-masked]>
Date: Wed, 24 Aug 2005 14:18:10 +0300

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mobopts

---

From: "James Kempf" <[email-masked]>
Date: Wed, 24 Aug 2005 10:18:52 -0700

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

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!

>> 3971 RSA Signature Option but the CGA Parameters Option contains an RST 
>> Ring Signature Key Suboption, the node SHOULD ignore the RST Ring 

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

> value from Step 2 of RFC 3971 Section 4 algorithm, as far as

I think you mean 3972.

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

> used in the calculation of the final address, such as

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

            jak

---

From: Jari Arkko <[email-masked]>
Date: Wed, 24 Aug 2005 20:53:53 +0300

James Kempf wrote:

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

This is what RFC 3972 says:

   Note that the hash values are computed
   over the entire CGA Parameters data structure, including any
   unrecognized extension fields.

Now, the field itself is underspecified although its usage in the
address calculation is clear (above). What we would probably need
to do is to specify first a TLV structure for the extensions, and
then one extension for the purposes of MCGA. But I don't
think we need to touch the calculation rules.

Btw, it seems that if the host's key is in the place where it
should be according to RFC 3972, the other keys are in
the extensions, you could easily use the RSA Signature, too,
as long as you are not currently proxying -- just sign with
the host's key. Of course you'd lose your privacy property.
But I thought I'd mention this because it may affect whether
you really want a new CGA type value or not.

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Wed, 24 Aug 2005 11:14:01 -0700

> think we need to touch the calculation rules.

The draft has a specification for a generic TLV structure. I suppose it does 
no harm in including the TLV values into the calculation, but it is not the 
way most protocols I'm familiar with handle this. Typically, the 
semantically relevant fields are extracted and used, the identifying fields 
are discarded. But it does simplify the implementation, less parsing.

> you really want a new CGA type value or not.

You mean use an RSA signature that could have been generated by one of 
several key pairs rather than a ring signature? The location privacy aspect 
is lost as you say, but it is much more backward compatible with SEND. In 
effect, the ND options and basic address calculation would be covered by the 
existing RFCs, a new draft would only need to specify the CGA Parameters 
Extension and multi-key CGA generation. Since the address is constructed 
from multiple keys, I suppose no single key is designated as the owner, so 
an attribute cert delegating signing rights wouldn't be needed. Needs some 
thought, though, might be some subtle attack here.

         jak

PS: BTW, we implemented the RST algorithm and the performance with two keys 
is about the same as RSA for signing and about twice as slow for 
verification. Signature size and performance scales with the number of keys, 
as expected.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 24 Aug 2005 22:02:31 +0300

James Kempf wrote:

> The draft has a specification for a generic TLV structure. I suppose 
> it does no harm in including the TLV values into the calculation, but 
> it is not the way most protocols I'm familiar with handle this. 
> Typically, the semantically relevant fields are extracted and used, 
> the identifying fields are discarded. But it does simplify the 
> implementation, less parsing.

Your draft has the generic TLV thing, but RFC 3972 did not have that.
The generic TLV structure is necessary, but I see that as an add-on
to RFC 3972 rather than something that needs to change other pieces
when its specified. Your draft does this very well, as long as we
don't change the address calculation rules.

I do prefer including everything as an opaque bit string in the
calculation. First of all, this is what RFC 3972 says. Secondly,
It ensures that there are no replacement attacks where
you keep the actual value but replace its type. Thirdly, its
simpler.

--Jari