Re: [CGA-EXT] Comments on draft-ietf-csi-proxy-send-01

[Tony Cheneau <[e-mail]>]

Hi Julien,

Comments inline:

On Thu, 19 Nov 2009, Laganier, Julien wrote:

> Hi Tony,
>
> Thanks for reviewing the draft!
>
> Replying to your concern on the security considerations "t would be nice to have a warning text such as: "Note that if a Secure Proxy ND is corrupted, it can impersonate all the node in the subnet in which it is authorized to act as a proxy."
>
> I wouldn't use the term impersonate -- the delegation certificate doesn't allow the proxy to impersonate nodes (they're only used for SEND), only to issue ND signalling on their behalf. So a compromised proxy is able, like a compromised router, to siphon off traffic from the host, or mount a man-in-the-middle attack.
I agree that "impersonate" may be to strong as the node will likely
realise that they are processing Proxy Signature Option.

However, to me, it seems that the attack I describe and the attack you
describe (on a compromised RFC 3971) router are slightly different.

Allow me to clarify my point:
Generally, without RFC 3971, given that two hosts are on the same link
and uses two addresses with the same prefix, they will communicate
directly. 
When you use RFC 3971, the two nodes will be able to perform
a secured Address Resolution. If an attacker want to perform a MITM
attack, it will try to send NS, NA or redirect message. However, since
it does not know any of the Private Key, he will not be able to sign the
messages, and the attack will fail. This is the expected behaviour.
Even a router can not mount a MITM attack here (the worse he can do is a
DoS by announcing a Prefix Lifetime of 0).

Your draft proposes a new entity named Secure Proxy ND. If we suppose
that a Secure Proxy ND for a specific prefix is corrupted, then the two
hosts from before which are communicating using two address from the
same prefix, are vulnerable to a corrupted Secure Proxy ND that can
send NS/NA and sign using the Proxy Signature Option. Its (compromised)
certificate would authorize it to do so. Do you agree ?  On that
specific point, I think you solution provide more incentive to an
attacker to corrupt the Secure Proxy ND enabled routers. That is
perfectly fine as long as it is stated to be vulnerable to this kind of
attack.

> So maybe we want to say something like:
>
>   Thanks to the authorization certificate it is provisioned with, a proxy ND
>   is authorized to issue ND signalling on behalf of nodes on the subnet.
>   Thus, a compromised proxy is able, like a compromised router, to siphon off
>   traffic from the host, or mount a man-in-the-middle attack. As for SEND,
>   which does not protect against against compromise of the route as
>   described in Sections 9.2.4 of [RFC3971], Secure Proxy ND Support for
>   SEND does not protect against compromise of the proxy ND.
>
> What do you think?
While I agree with the general phrasing, I think that you should
emphasis that attack is "wider" that the generic SEND compromised
router, as it allows man-in-the-middle attack on node that are
communicating on the link (as stated before).

Another question that comes to my mind just now, and that may need
clarification in your document is:
Is your solution able to provide Secure Proxy ND for the fe80::/64
prefix ? I mean, a router does not announce this prefix as it not a
routable one. Then, there will be no CPS/CPA exchange for this prefix,
meaning no certificate exchange.  What is the processing of a host
receiving a ND message toward a fe80::/64 address signed with a Proxy
Signature Option ?  How can he learn the certificate of the Secure Proxy
ND ? This should be addressed as it is a use case of RFC 4389 (I think).

Feel free to ask if I'm not clear enough and you need clarifications.

Best regards,
 	Tony