[Mipshop] Revised I-D: draft-ietf-mipshop-cga-cba-02.txt

Christian Vogt <chvogt@tm.uka.de> Tue, 12 December 2006 19:09 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuD0V-00066y-FN; Tue, 12 Dec 2006 14:09:39 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuD0U-00066q-EW for mipshop@ietf.org; Tue, 12 Dec 2006 14:09:38 -0500
Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuD0S-00080Y-UZ for mipshop@ietf.org; Tue, 12 Dec 2006 14:09:38 -0500
Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1GuD0M-0000Hd-Cl; Tue, 12 Dec 2006 20:09:36 +0100
Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1GuD0L-00041Y-L7; Tue, 12 Dec 2006 20:09:29 +0100
Received: from [IPv6:2001:638:204:6:20c:6eff:fe40:8d95] (archimedes.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:20c:6eff:fe40:8d95]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 0B9B9B5BC; Tue, 12 Dec 2006 20:09:29 +0100 (CET)
Message-ID: <457EFE68.90209@tm.uka.de>
Date: Tue, 12 Dec 2006 20:09:28 +0100
From: Christian Vogt <chvogt@tm.uka.de>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.0.8) Gecko/20060911 SUSE/1.5.0.8-0.1 Thunderbird/1.5.0.8 Mnenhy/0.7.4.0
MIME-Version: 1.0
To: Mipshop <mipshop@ietf.org>
X-Enigmail-Version: 0.94.1.0
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit
X-Spam-Score: -4.2 (----)
X-Spam-Status: No
X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: Wassim Haddad <whaddad@tcs.hut.fi>, Jari Arkko <jari.arkko@piuha.net>, Vijay Devarapalli <vijay.devarapalli@azairenet.com>
Subject: [Mipshop] Revised I-D: draft-ietf-mipshop-cga-cba-02.txt
X-BeenThere: mipshop@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: mipshop.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mipshop>, <mailto:mipshop-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mipshop@ietf.org>
List-Help: <mailto:mipshop-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mipshop>, <mailto:mipshop-request@ietf.org?subject=subscribe>
Errors-To: mipshop-bounces@ietf.org

Hello folks,

we submitted a new version of draft-ietf-mipshop-cga-cba, which is
available at the following URL:

http://doc.tm.uka.de/2006/draft-ietf-mipshop-cga-cba-02.txt

The document includes a list of changes that we applied during the
revision in the Change Log section starting on page 55.  You may also
want to take a look at the diff's between the previous document version
and this new one, which you find here:

http://doc.tm.uka.de/2006/draft-ietf-mipshop-cga-cba-01to02.html

The new document version addresses the comments from James Kempf and
Zhen Cao.  James suggested to include time-sequence diagrams to make the
Protocol Operation section more easily understandable.  Those have been
included.

Zhen Cao addressed the issue with increasing the minimum length for CGA
keys beyond the 384-bit limit prescribed RFC 3972.  While we found
during the discussion that a higher minimum key length is not necessary,
 we agreed to document this decision in the Security Considerations
section.  This security considerations also elaborate on upcoming
changes to RFC 3972 [draft-bagnulo-multiple-hash-cga-01] and how those
might affect the CGA application in draft-ietf-mipshop-cga-cba.

An earlier mailing list discussion, which Manhee Jo had initiated,
tackled the well-known vulnerability to spoofed Binding Acknowledgment
messages from on-path attackers.  Such attackers could trick a mobile
node into accepting a bogus permanent home keygen tokens, thereby
rendering the mobile node unable to pursue further binding updates with
a correspondent node.  This vulnerability can only be fixed through
strong correspondent node authentication, e.g., by leveraging the
correspondent node's CGA public key.  We initially did not fix this
vulnerability because it exists already in the non-mobile Internet.
OTOH, there also were no objections against adding stronger
correspondent node authentication during the presentation in Montreal,
so we finally decided to add support for optional CGA-based
correspondent node authentication.  See sections 4.3, 4.4, and 6.7.

All the best,
- Christian

-- 
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/


_______________________________________________
Mipshop mailing list
Mipshop@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop