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

Tony Cheneau <tony.cheneau@it-sudparis.eu> Fri, 09 April 2010 22: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 6B3C33A68C2 for <cga-ext@core3.amsl.com>; Fri, 9 Apr 2010 15:05:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level:
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
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 Zkgfi2flTSsq for <cga-ext@core3.amsl.com>; Fri, 9 Apr 2010 15:05:41 -0700 (PDT)
Received: from smtp4.int-evry.fr (smtp4.int-evry.fr [157.159.10.71]) by core3.amsl.com (Postfix) with ESMTP id 573F93A68B3 for <cga-ext@ietf.org>; Fri, 9 Apr 2010 15:05:41 -0700 (PDT)
Received: from smtp2.int-evry.fr (smtp2.int-evry.fr [157.159.10.45]) by smtp4.int-evry.fr (Postfix) with ESMTP id 11FD6FE427A; Sat, 10 Apr 2010 00:05:37 +0200 (CEST)
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 D673E404FA5; Sat, 10 Apr 2010 00:05:31 +0200 (CEST)
Received: from alf94-6-82-226-232-167.fbx.proxad.net (alf94-6-82-226-232-167.fbx.proxad.net [82.226.232.167]) (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 916F4900DC; Sat, 10 Apr 2010 00:05:31 +0200 (CEST)
Date: Sat, 10 Apr 2010 00:05:36 +0200 (CEST)
From: Tony Cheneau <tony.cheneau@it-sudparis.eu>
X-X-Sender: shad@localhost.localdomain
To: =?ISO-8859-15?Q?Alberto_Garc=EDa?= <alberto@it.uc3m.es>
In-Reply-To: <383E40D32F394FB398521C398A133C68@bombo>
Message-ID: <alpine.LNX.2.00.1004100001050.9516@localhost.localdomain>
References: <alpine.LNX.2.00.1004091544180.9490@whitebox> <383E40D32F394FB398521C398A133C68@bombo>
User-Agent: Alpine 2.00 (LNX 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-489404613-1270850736=:9516"
X-INT-MailScanner-Information: Please contact the ISP for more information
X-INT-MailScanner-ID: D673E404FA5.AB1A6
X-INT-MailScanner: Found to be clean
X-INT-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=0.805, requis 6.01, BAYES_00 -2.60, FH_HELO_EQ_D_D_D_D 0.00, HELO_DYNAMIC_IPADDR 2.43, RCVD_IN_SORBS_DUL 0.88, RDNS_DYNAMIC 0.10)
X-INT-MailScanner-From: tony.cheneau@it-sudparis.eu
Cc: draft-ietf-csi-proxy-send@tools.ietf.org, CGA-EXT@ietf.org
Subject: Re: [CGA-EXT] Comments on draft-ietf-csi-proxy-send-03
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, 09 Apr 2010 22:05:42 -0000

Hello Alberto,

Answers inline.

On Fri, 9 Apr 2010, Alberto García wrote:

[...]

> Yes, I see the problem, good point.
> This may also occur for MIPv6 when a node switches from communicating with
> the MN to the Secure Proxy ND, and viceversa.
>
> I think the solution is to assume that timestamp checking must be performed
> independently for the different possible sources (the MN, the Secure Proxy
> ND, the MAG), i.e. process the timestamp of a message received for the first
> time from a proxy as if it were the first message of a communication.
> Therefore, I would replace rule 5 in 5.2.2 of draft-ietf-csi-proxy-send-03
> with two rules (which separate timestamp and nonce for the sake of clarity):
>
> "5. The Timestamp option MUST be processed as specified in
>       [RFC3971] Section 5.3.4, except for replacing 'RSA Signature
>       option' by 'PS option'. The receiver SHOULD store the peer-related
> timing information specified in [RFC3971] Section 5.3.4.1 and 5.3.4.2
> (RDlast, TSlast) separately for each different proxy (which can be
> identified by the different Key Hash values of the proxied message) and
> separately from the timing information associated to the IP of node for
> which the message is proxied. In this way, a message received for the first
> time from a proxy (i.e. for which there is no information stored in the
> cache) SHOULD be checked as messages received from new peers (as in
> [RFC3971] section 5.3.4.2).
>
> 6. The Nonce option MUST be processed as specified in
>       [RFC3971] Section 5.3.4, except for replacing 'RSA Signature
>       option' by 'PS option'. "
> [...]"
>
> I think it is not necessary to say that if the message is later received
> from the original host (not from the proxy), the Timestamp is checked with
> the time values specific to the host (not with the values specific to the
> proxy).
>
> I think this does not introduce new security considerations: on one hand,
> caches from previous sending nodes communicating don't need to be deleted,
> so old messages cannot be replied; and on the other hand, security
> considerations on RFC 3971 section 9.2.5 apply to the messages sent for the
> first time from the proxies.
>
> What do you think?
I think this is OK (the wording and the solution). IMHO, having separate
(RDlast, TSlast) for each entity (be it proxy or proxied node) is the
right thing to do.

I also do not see any new security concerns here.

> |  Or maybe I missed the part that says the clocks are implicitly
> |  synchronised (or something else) ? Either way, could you clarify the
> |  situation for me and maybe add some text in the draft about this ?
>
> I hope the previous solution is cleaner than requiring synchronization.
Yes, way cleaner. :)

Regards,
 	Tony