Re: [CGA-EXT] CGA-EXT Digest, Vol 29, Issue 2

Sheng Jiang <shengjiang@huawei.com> Fri, 18 September 2009 10:28 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 3C5363A6972 for <cga-ext@core3.amsl.com>; Fri, 18 Sep 2009 03:28:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.319
X-Spam-Level:
X-Spam-Status: No, score=0.319 tagged_above=-999 required=5 tests=[AWL=-0.975, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, 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 bTOtRoG-uJtI for <cga-ext@core3.amsl.com>; Fri, 18 Sep 2009 03:28:53 -0700 (PDT)
Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 513C23A6A66 for <cga-ext@ietf.org>; Fri, 18 Sep 2009 03:28:53 -0700 (PDT)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ5005KQX59O5@szxga01-in.huawei.com> for cga-ext@ietf.org; Fri, 18 Sep 2009 18:29:34 +0800 (CST)
Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ5003XBX59YL@szxga01-in.huawei.com> for cga-ext@ietf.org; Fri, 18 Sep 2009 18:29:33 +0800 (CST)
Received: from j66104a ([10.111.12.58]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQ500I6XX59CE@szxml06-in.huawei.com> for cga-ext@ietf.org; Fri, 18 Sep 2009 18:29:33 +0800 (CST)
Date: Fri, 18 Sep 2009 18:29:33 +0800
From: Sheng Jiang <shengjiang@huawei.com>
In-reply-to: <7d4043110909180030l5407ad54sb0f97f45b067c825@mail.gmail.com>
To: '回全超' <huiquanchao@gmail.com>, cga-ext@ietf.org
Message-id: <004801ca384a$ea0211e0$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="gb2312"
Content-transfer-encoding: 7bit
Thread-index: Aco4Mf8592QLtM7QQDSTw1g7RForHwADL8kA
Subject: Re: [CGA-EXT] CGA-EXT Digest, Vol 29, Issue 2
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, 18 Sep 2009 10:28:54 -0000

> Secondly, nowadays security issues become more and more 
> important for Internet.

Fully agreed.

> I think authentications  
> using signature will be applied in many other scenarios in 
> future, and the cksum signature problem 
> might happen again. Shall we do something about this?

Not sure what you mean by "other scenarios". Could you be more specific
here? Like what protocol may occur such problem. Unless there are something
more specific, we do not know what to do exactly.

Cheers,

Sheng

> Best regards,
> 
> Quanchao Hui
> 
> 
> 2009/9/17 <cga-ext-request@ietf.org>
> 
> 
> 	If you have received this digest without all the 
> individual message
> 	attachments you will need to update your digest options 
> in your list
> 	subscription.  To do so, go to
> 	
> 	https://www.ietf.org/mailman/listinfo/cga-ext
> 	
> 	Click the 'Unsubscribe or edit options' button, log in, 
> and set "Get
> 	MIME or Plain Text Digests?" to MIME.  You can set this option
> 	globally for all the list digests you receive at this point.
> 	
> 	
> 	
> 	Send CGA-EXT mailing list submissions to
> 	       cga-ext@ietf.org
> 	
> 	To subscribe or unsubscribe via the World Wide Web, visit
> 	       https://www.ietf.org/mailman/listinfo/cga-ext
> 	or, via email, send a message with subject or body 'help' to
> 	       cga-ext-request@ietf.org
> 	
> 	You can reach the person managing the list at
> 	       cga-ext-owner@ietf.org
> 	
> 	When replying, please edit your Subject line so it is 
> more specific
> 	than "Re: Contents of CGA-EXT digest..."
> 	
> 	
> 	Today's Topics:
> 	
> 	  1.  SEND checksum issue in current RFC 3791 - update needed
> 	     (Sheng Jiang)
> 	
> 	
> 	
> ----------------------------------------------------------------------
> 	
> 	Message: 1
> 	Date: Thu, 17 Sep 2009 10:14:03 +0800
> 	From: Sheng Jiang <shengjiang@huawei.com>
> 	Subject: [CGA-EXT] SEND checksum issue in current RFC 
> 3791 - update
> 	       needed
> 	To: cga-ext@ietf.org
> 	Cc: 'wdwang' <wdwang@bupt.edu.cn>
> 	Message-ID: <000901ca373c$874238f0$3a0c6f0a@china.huawei.com>
> 	Content-Type: text/plain; charset=us-ascii
> 	
> 	Hi, dear CSIer,
> 	
> 	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.
> 	
> 	Best regards,
> 	
> 	Sheng
> 	
> 	
> 	
> 	------------------------------
> 	
> 	_______________________________________________
> 	CGA-EXT mailing list
> 	CGA-EXT@ietf.org
> 	https://www.ietf.org/mailman/listinfo/cga-ext
> 	
> 	
> 	End of CGA-EXT Digest, Vol 29, Issue 2
> 	**************************************
> 	
> 
> 
>