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

Tony Cheneau <tony.cheneau@it-sudparis.eu> Fri, 20 November 2009 15:05 UTC

Return-Path: <tony.cheneau@it-sudparis.eu>
X-Original-To: cga-ext@core3.amsl.com
Delivered-To: cga-ext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E93E3A6AC9 for <cga-ext@core3.amsl.com>; Fri, 20 Nov 2009 07:05:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yq0hn+-9tzFs for <cga-ext@core3.amsl.com>; Fri, 20 Nov 2009 07:05:35 -0800 (PST)
Received: from smtp4.int-evry.fr (smtp4.int-evry.fr [157.159.10.71]) by core3.amsl.com (Postfix) with ESMTP id E0F063A6A85 for <cga-ext@ietf.org>; Fri, 20 Nov 2009 07:05:34 -0800 (PST)
Received: from smtp2.int-evry.fr (smtp2.int-evry.fr [157.159.10.45]) by smtp4.int-evry.fr (Postfix) with ESMTP id 7A925FE1951; Fri, 20 Nov 2009 16:05:31 +0100 (CET)
Received: from smtp-ext.int-evry.fr (smtp-ext.int-evry.fr [157.159.11.17]) by smtp2.int-evry.fr (Postfix) with ESMTP id 576944050C5; Fri, 20 Nov 2009 16:05:25 +0100 (CET)
Received: from pat4661.micro.int-evry.fr (unknown [157.159.103.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-ext.int-evry.fr (Postfix) with ESMTP id 4268D90011; Fri, 20 Nov 2009 16:05:25 +0100 (CET)
Date: Fri, 20 Nov 2009 16:05:37 +0100 (CET)
From: Tony Cheneau <tony.cheneau@it-sudparis.eu>
X-X-Sender: shad@whitebox
To: "Laganier, Julien" <julienl@qualcomm.com>
In-Reply-To: <BF345F63074F8040B58C00A186FCA57F1C66087842@NALASEXMB04.na.qualcomm.com>
Message-ID: <alpine.LNX.2.00.0911201144010.7546@whitebox>
References: <alpine.LNX.2.00.0911191100150.7833@whitebox> <BF345F63074F8040B58C00A186FCA57F1C66087842@NALASEXMB04.na.qualcomm.com>
User-Agent: Alpine 2.00 (LNX 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-INT-MailScanner-Information: Please contact the ISP for more information
X-INT-MailScanner-ID: 576944050C5.A85A8
X-INT-MailScanner: Found to be clean
X-INT-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=-4.399, requis 6.01, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60)
X-INT-MailScanner-From: tony.cheneau@it-sudparis.eu
Cc: "draft-ietf-csi-proxy-send@tools.ietf.org" <draft-ietf-csi-proxy-send@tools.ietf.org>, "cga-ext@ietf.org" <cga-ext@ietf.org>
Subject: Re: [CGA-EXT] Comments on draft-ietf-csi-proxy-send-01
X-BeenThere: cga-ext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: CGA and SeND Extensions <cga-ext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cga-ext>
List-Post: <mailto:cga-ext@ietf.org>
List-Help: <mailto:cga-ext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Nov 2009 15:05:36 -0000

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