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

["Laganier, Julien" <[e-mail]>]

Tony,

If a router is compromised, it can send a RA containing a PIO with the L bit set to zero, and thus two hosts on the link trying to communicate will sends their packets to the router and will not attempt to resolve each others' address. Doing so, it can mount a MiTM attack of siphon off packets sent by a host. This is acknowledged in section 4.2.1. of RFC 3756.

Regarding the fe80::/64 prefix, it does not need to be advertized by the router or proxy. It should be assumed that a ND proxy is always authorized to proxy signaling for the fe80::/64 prefix. That does not need to be signaled in the certificate, it has to be written down in the draft however :)

--julien

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Tony Cheneau
> Sent: Friday, November 20, 2009 7:06 AM
> To: Laganier, Julien
> Cc: [e-mail]; [e-mail]
> Subject: Re: [CGA-EXT] Comments on draft-ietf-csi-proxy-send-01
> 
> 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
> 
> 
> _______________________________________________
> CGA-EXT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cga-ext