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

arno@natisbad.org (Arnaud Ebalard) Thu, 17 September 2009 09:17 UTC

Return-Path: <arno@natisbad.org>
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 97A9128C18F for <cga-ext@core3.amsl.com>; Thu, 17 Sep 2009 02:17:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.579
X-Spam-Level:
X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 aC1dOBJCdmnq for <cga-ext@core3.amsl.com>; Thu, 17 Sep 2009 02:17:31 -0700 (PDT)
Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 2911628C16A for <cga-ext@ietf.org>; Thu, 17 Sep 2009 02:17:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=natisbad.org; s=mail; h=From:To:Cc:Subject:References:Date: In-Reply-To:Message-ID:MIME-Version:Content-Type; bh=zxtAoDhtixR 6fzfDKShzoRy760lkoa5nEteTjnjiajs=; b=vrcQu+QHu2qgeHh6LzWIkNsbqpa /HZAQEl5sbZgE/aF87IWa54yRV8ArLz0m5w3XtxZBCnXY0PLMuqB7XG2r/0ee4QK eCCRTnbHxP94o4hWULAiMX4a8ZYyYVQ41mlUtAGYzZgCqBwd8xoMd2V6wHLEC9ZT gU1yFvMHbqJVF5tc=
Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <arno@natisbad.org>) id 1MoD85-0004DJ-9v; Thu, 17 Sep 2009 11:18:17 +0200
From: arno@natisbad.org
To: Eric Levy-Abegnoli <elevyabe@cisco.com>
References: <002501ca376a$5eb39950$3a0c6f0a@china.huawei.com> <4AB1EB54.4000903@cisco.com> <871vm6q8tc.fsf@small.ssi.corp> <4AB1F701.1060805@cisco.com>
X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc
X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026
X-Hashcash: 1:20:090917:shengjiang@huawei.com::2qJSNyDATImP7HzY:00000000000000000000000000000000000000000ME9
X-Hashcash: 1:20:090917:elevyabe@cisco.com::ifITumCF3PDbkkVv:00000000000000000000000000000000000000000000I/y
X-Hashcash: 1:20:090917:cga-ext@ietf.org::VUncXEfhL00gdbA4:02NDb
X-Hashcash: 1:20:090917:wdwang@bupt.edu.cn::+clAU0gmYJVUMAiq:00000000000000000000000000000000000000000002Og8
Date: Thu, 17 Sep 2009 11:18:57 +0200
In-Reply-To: <4AB1F701.1060805@cisco.com> (Eric Levy-Abegnoli's message of "Thu, 17 Sep 2009 10:44:49 +0200")
Message-ID: <87iqfiorni.fsf@small.ssi.corp>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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:17:32 -0000

Hi,

Eric Levy-Abegnoli <elevyabe@cisco.com> writes:

>>> Currently, I see onle one possibility, which is A. It is
>>> un-ambiguously specified in rfc3971.
>>>     
>>
>> I respectfully disagree (not on the definitive solution). My previous
>> post in March 2008 and the one from Sheng just prove this is not
>> "un-ambiguously" specified. 
>>
>>   
> complicated, or not detailed enough does not mean it is ambiguous. I read:
>
>  Digital Signature
>      A variable-length field containing a PKCS#1 v1.5 signature,
>      constructed by using the sender's private key over the following
>      sequence of octets:
>
> [snip]
>
>      4. The 8-bit Type, 8-bit Code, and 16-bit Checksum fields from the
>         ICMP header.
>
> ...
> It does not say "0", it says checksum from the icmp header. How could
> "0" be the checksum of the icmp header?

Just for the discussion: Usually, the checksuming is done at the end of
option inclusion. Meanwhile (at least in most C implementations, i
guess, the checksum field is null in the structure due to an initial
memset(,0,)). But I guess one can say that "The message is constructed
in its entirety, without the RSA Signature option" must be understood as
"The message is constructed in its entirety, with the checksum field set
but without the RSA Signature"

IMHO, Changing the list in 5.2.1 to: 

   A node sending a message with the RSA Signature option MUST construct
   the message as follows:

   o  The message is constructed in its entirety, without the RSA
      Signature option. This includes usual checksum computation over
      current layout.

   o  The RSA Signature option is added as the last option in the
      message.

   o  The data to be signed is constructed as explained in Section 5.2,
      under the description of the Digital Signature field.

   o  The message, in the form defined above, is signed by using the
      configured private key, and the resulting PKCS#1 v1.5 signature is
      put in the Digital Signature field.

   o As described in [RFC2463], ICMPv6 checksum field is updated to
     reflect the addition of the RSA Signature Option.

make things clear.

> I agree clarification would be useful, given that several implementors
> are asking for it. No question on that.

yes.

BTW, while I am at it, was I the only one to read the description of the
Timestamp field multiple times (in 5.3.1. "Timestamp Option") to be sure
my code would work for various arch (endianness)?

Cheers,

a+