[Hipsec] Conflicting text in RFC5201 - RFC5201-bis
Tobias Heer <heer@cs.rwth-aachen.de> Wed, 26 May 2010 10:37 UTC
Return-Path: <heer@informatik.rwth-aachen.de>
X-Original-To: hipsec@core3.amsl.com
Delivered-To: hipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10E8F3A68C1 for <hipsec@core3.amsl.com>; Wed, 26 May 2010 03:37:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level:
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4]
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 fuViCTFInDc1 for <hipsec@core3.amsl.com>; Wed, 26 May 2010 03:37:14 -0700 (PDT)
Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 9BD283A68CE for <hipsec@ietf.org>; Wed, 26 May 2010 03:37:14 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="us-ascii"
Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0L30004KPW5S6830@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Wed, 26 May 2010 12:37:04 +0200 (CEST)
X-IronPort-AV: E=Sophos;i="4.53,303,1272837600"; d="scan'208";a="58966111"
Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Wed, 26 May 2010 12:37:04 +0200
Received: from umic-137-226-154-185.nn.rwth-aachen.de ([unknown] [137.226.154.185]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L3000AR2W5SL050@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Wed, 26 May 2010 12:37:04 +0200 (CEST)
From: Tobias Heer <heer@cs.rwth-aachen.de>
Date: Wed, 26 May 2010 12:37:10 +0200
Message-id: <AB42DFE2-0673-41DE-A40D-7D727D4A6BF3@cs.rwth-aachen.de>
To: HIP WG <hipsec@ietf.org>
X-Mailer: Apple Mail (2.1078)
Subject: [Hipsec] Conflicting text in RFC5201 - RFC5201-bis
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hipsec>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 May 2010 10:37:16 -0000
Hello, I have a question regarding some text in RFC5201 that conflicts with the crypto agility that we envisioned. The new BEX will have to start the negotiations of the DH groups already in I1 to allow the Responder to pick a sensible DH group (there are simple countermeasures against downgrade attacks, too, so don't worry). Therefore, the I1 becomes slightly more important than it was (although it stays unsigned and cheap). In Section 4.1 RFC5201 states: ... 705 The Initiator first sends a trigger packet, I1, to the 706 Responder. The packet contains the HIT of the Initiator 707 and possibly the HIT of the Responder, if it is known. 708 Moreover, it contains a list of Diffie Hellman Group IDs 709 supported by the Initiator. Note 710 that in some cases it may be possible to replace this trigger 711 packet by some other form of a trigger, in which case the 712 protocol starts with the Responder sending the R1 packet. ... With the DH group negotiations already starting in I1 it becomes difficult to omit the I1 (you can do it but you lose DH crypto agility). Moreover, I doubt that omitting the I1 works well even without considering the DH group negotiations because some of the measures to keep the Responder stateless until I2 rely on having information from the I1 (IP address or HIT) for the puzzle/ opaque data field. My questions are: Is anyone using or does anyone intent to use this omission of the I1? Is there any specification on how to do it (at least this is the only place in 5201 where it is mentioned). Do we need this feature because there are cases where you cannot send an I1? And finally: can we live without that note? Of course, even if we skip it there is nothing that will keep someone defining it as an extension to the base specs if it is needed in the future. Thanks for any input. Tobias -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer
- [Hipsec] Conflicting text in RFC5201 - RFC5201-bis Tobias Heer
- Re: [Hipsec] Conflicting text in RFC5201 - RFC520… Samu Varjonen
- Re: [Hipsec] Conflicting text in RFC5201 - RFC520… René Hummen
- Re: [Hipsec] Conflicting text in RFC5201 - RFC520… Tobias Heer
- Re: [Hipsec] Conflicting text in RFC5201 - RFC520… Ari Keranen
- Re: [Hipsec] Conflicting text in RFC5201 - RFC520… Tobias Heer
- Re: [Hipsec] Conflicting text in RFC5201 - RFC520… Ari Keranen
- Re: [Hipsec] Conflicting text in RFC5201 - RFC520… Tobias Heer