Re: [CGA-EXT] SEND checksum issue in current RFC 3791 - update needed

Sheng Jiang <shengjiang@huawei.com> Thu, 17 September 2009 09:41 UTC

Return-Path: <shengjiang@huawei.com>
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 32C753A68C0 for <cga-ext@core3.amsl.com>; Thu, 17 Sep 2009 02:41:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.372
X-Spam-Level:
X-Spam-Status: No, score=-0.372 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 ZUXURt2-NN5n for <cga-ext@core3.amsl.com>; Thu, 17 Sep 2009 02:41:26 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 80CFB3A6894 for <cga-ext@ietf.org>; Thu, 17 Sep 2009 02:41:24 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ40051U08AJI@szxga04-in.huawei.com> for cga-ext@ietf.org; Thu, 17 Sep 2009 17:40:58 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ4008V408AF0@szxga04-in.huawei.com> for cga-ext@ietf.org; Thu, 17 Sep 2009 17:40:58 +0800 (CST)
Received: from j66104a ([10.111.12.58]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQ400BA1089FU@szxml04-in.huawei.com> for cga-ext@ietf.org; Thu, 17 Sep 2009 17:40:58 +0800 (CST)
Date: Thu, 17 Sep 2009 17:40:57 +0800
From: Sheng Jiang <shengjiang@huawei.com>
In-reply-to: <4AB1EB54.4000903@cisco.com>
To: 'Eric Levy-Abegnoli' <elevyabe@cisco.com>
Message-id: <002901ca377a$f5b9c210$3a0c6f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: quoted-printable
Thread-index: Aco3bDpxCgCHkO3OQimJiLeQFVTa1wADPYXQ
Cc: 'wdwang' <wdwang@bupt.edu.cn>, cga-ext@ietf.org
Subject: Re: [CGA-EXT] SEND checksum issue in current RFC 3791 - update needed
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: Thu, 17 Sep 2009 09:41:27 -0000

Eric,

I agree that we should stick on A. However, it is that obvious from the
current RFC 3791. Clarification/update will help on this.

Sheng

> -----Original Message-----
> From: Eric Levy-Abegnoli [mailto:elevyabe@cisco.com] 
> Sent: Thursday, September 17, 2009 3:55 PM
> To: Sheng Jiang
> Cc: 'Arnaud Ebalard'; 'wdwang'; cga-ext@ietf.org
> Subject: Re: [CGA-EXT] SEND checksum issue in current RFC 
> 3791 - update needed
> 
> Sheng,
> Currently, I see onle one possibility, which is A. It is 
> un-ambiguously specified in rfc3971. And it has been 
> implemented by multiple vendors. Moving to B would not be 
> backward compatible and would create inter-operability issues. 
> Eric
> 
> Sheng Jiang a écrit :
> > Hi, Arnaud,
> >
> > Yes, it is an issue must be clearly clarified in the specification.
> > Actually, there are two possibility here (which makes more 
> important 
> > that specification should be clearly follow only one of them):
> >
> > A, if we would like to follow the drscription in Section 5.2.1 RFC 
> > 3791, the input of RSA signature should be a checksum calculated 
> > without RSA signature and it will be recalculated after signature 
> > attached. On the receiver side, ICMP checksum should be validated, 
> > then signature validate, then maybe checksum validate again.
> >
> > B, more efficiently, on the sender side, as you said, the 
> input of RSA 
> > signature should be a checksum with all 0, and after signature 
> > attached, the checksim is computed over the whole packet. However, 
> > this makes the signature over checksum totally meaningless. 
> > Alternatively, we may take checksum bits out from the RSA 
> signature input.
> >
> > Additionally, there are intercommunication issues if a sender use A 
> > implementation and a receiver uses B implementation.
> >
> > Sum up, an update over the current definition RFC 3791 is needed on 
> > this issue.
> >
> > Cheers,
> >
> > Sheng
> >
> >   
> >> -----Original Message-----
> >> From: Arnaud Ebalard [mailto:arno@natisbad.org]
> >> Sent: Thursday, September 17, 2009 2:02 PM
> >> To: Sheng Jiang
> >> Cc: cga-ext@ietf.org; 'wdwang'
> >> Subject: Re: [CGA-EXT] SEND checksum issue in current RFC
> >> 3791 - update needed
> >>
> >> Hi,
> >>
> >> Sheng Jiang <shengjiang@huawei.com> writes:
> >>
> >>     
> >>> During our implementation of SEND & CGA, we discovered an
> >>>       
> >> issue in the
> >>     
> >>> current RFC 3791, described as the following. An update is
> >>>       
> >> needed to
> >>     
> >>> solve this issue.
> >>>
> >>> Checksum issue in the current SEND definition RFC 3791.
> >>>
> >>> In Section 5.2, RFC3791, digital signature is defined to 
> sign data 
> >>> include checksum fieds from ICMP header (bullet item 4),
> >>>       
> >> which should
> >>     
> >>> already be calculated during the construction of message 
> (the first 
> >>> step in Section 5.2.1). After RSA signature is attached,
> >>>       
> >> the original
> >>     
> >>> checksum value is no longer valid. It should be
> >>>       
> >> recalsulated. However,
> >>     
> >>> this was not clearly defined in RFC 3791. More importantly, the 
> >>> correspondent validation rule must be defined on the
> >>>       
> >> receiver side too.
> >>
> >> I already reported that same issue some time ago and the 
> good way to 
> >> understand the spec is to compute the signature over the 
> packet with 
> >> the checksum field to 0. Then, the checksum is computed over the 
> >> whole packet. But I agree that the spec is unclear on that.
> >>
> >> See my post and Eric's reply here:
> >>
> >>   
> http://www.ietf.org/mail-archive/web/cga-ext/current/msg00098.html
> >>
> >> Cheers,
> >>
> >> a+
> >>     
> >
> > _______________________________________________
> > CGA-EXT mailing list
> > CGA-EXT@ietf.org
> > https://www.ietf.org/mailman/listinfo/cga-ext
> >
> >   
>