Re: [Hipsec] CLOSE and identical session keys
Tobias Heer <heer@cs.rwth-aachen.de> Wed, 20 October 2010 19:21 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 606AF3A680D for <hipsec@core3.amsl.com>; Wed, 20 Oct 2010 12:21:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.368
X-Spam-Level:
X-Spam-Status: No, score=-4.368 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, 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 msInEVs-+qZJ for <hipsec@core3.amsl.com>; Wed, 20 Oct 2010 12:21:02 -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 7502D3A67DF for <hipsec@ietf.org>; Wed, 20 Oct 2010 12:21:02 -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 <0LAL005UXSHM0B60@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Wed, 20 Oct 2010 21:22:34 +0200 (CEST)
X-IronPort-AV: E=Sophos;i="4.57,356,1283724000"; d="scan'208";a="77819047"
Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Wed, 20 Oct 2010 21:22:35 +0200
Received: from [192.168.3.3] ([unknown] [91.179.7.114]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LAL00F7CSHLXI90@relay-auth-2.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Wed, 20 Oct 2010 21:22:34 +0200 (CEST)
From: Tobias Heer <heer@cs.rwth-aachen.de>
In-reply-to: <7CC566635CFE364D87DC5803D4712A6C4CEC451A22@XCH-NW-10V.nw.nos.boeing.com>
Date: Wed, 20 Oct 2010 21:22:32 +0200
Message-id: <501C3DB4-1F0B-458E-BD7A-0265E63D19CD@cs.rwth-aachen.de>
References: <7CC566635CFE364D87DC5803D4712A6C4CEC451A0E@XCH-NW-10V.nw.nos.boeing.com> <C6708DB0-5BEE-430E-B5E5-03B711F19904@cs.rwth-aachen.de> <7CC566635CFE364D87DC5803D4712A6C4CEC451A22@XCH-NW-10V.nw.nos.boeing.com>
To: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
X-Mailer: Apple Mail (2.1081)
Cc: HIP WG <hipsec@ietf.org>
Subject: Re: [Hipsec] CLOSE and identical session keys
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, 20 Oct 2010 19:21:06 -0000
Hello Tom (and everyone else involved), Am 20.10.2010 um 17:16 schrieb Henderson, Thomas R: >> [...] >> a) add a recommendation that a host SHOULD to not send the >> same puzzle to a host twice. A host can use the opaque field >> in the puzzle to generate unique puzzle parameters (e.g., by >> using a counter as input for the generation of I and by using >> the opaque field in the puzzle to remember it). >> >> or >> >> b) add MUST to use different puzzles. This may be a bit more >> costly because a host could deprive the puzzles that can be >> indexed with the opaque field with 2^16 I1 packets. In that >> case the responder would have to increase the R1 generation >> counter (and would possibly generate new DH keys and >> signatures for these). >> >> Any opinions? >> > > I had some similar thoughts when originally replying (about the possible need to detect replayed CLOSE packets) and of the two choices above, I would probably favor a). > My suggestion for the new passage for RFC5201-bis: The puzzle value I and the solution J are inputs for deriving the keying material from the Diffie Hellman key exchange (Section 6.5). Therefore, a responder SHOULD NOT use the same puzzle I with the same DH keys for the same Initiator twice to ensure that the derived keying material differs. Such uniqueness can be achieved, for example, by using a counter as input for generating I. This counter can be increased for each processed I1 packet. The state of the counter can be transmitted in the Opaque data field in the PUZZLE (Section 5.2.4), in an ECHO_REQUEST_SIGNED (Section 5.2.19) or in an ECHO_REQUEST_UNSIGNED parameter (Section 5.2.20) without the need to establish state. Any comments / suggestions? However, with this passage some other text on the puzzle requires minor changes and clarifications as well. BR, Tobias -- Dipl.-Inform. Tobias Heer, Ph.D. Student Chair of Communication and Distributed Systems - comsys RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi
- [Hipsec] (no subject) Tobias Heer
- [Hipsec] (no subject) Henderson, Thomas R
- [Hipsec] CLOSE and identical session keys Tobias Heer
- Re: [Hipsec] CLOSE and identical session keys Miika Komu
- Re: [Hipsec] CLOSE and identical session keys René Hummen
- Re: [Hipsec] CLOSE and identical session keys Henderson, Thomas R
- Re: [Hipsec] CLOSE and identical session keys Tobias Heer
- Re: [Hipsec] CLOSE and identical session keys Ari Keranen