[Hipsec] RFC5201 Ticket #32:
Tobias Heer <heer@cs.rwth-aachen.de> Fri, 23 September 2011 16:20 UTC
Return-Path: <heer@informatik.rwth-aachen.de>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B9121F8CC4 for <hipsec@ietfa.amsl.com>; Fri, 23 Sep 2011 09:20:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.652
X-Spam-Level:
X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znp7x1UvyKnY for <hipsec@ietfa.amsl.com>; Fri, 23 Sep 2011 09:20:57 -0700 (PDT)
Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2C30F21F8CBD for <hipsec@ietf.org>; Fri, 23 Sep 2011 09:20:57 -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-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LRZ00AXSHJ6RAF0@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Fri, 23 Sep 2011 18:23:30 +0200 (CEST)
X-IronPort-AV: E=Sophos;i="4.68,431,1312149600"; d="scan'208";a="137927543"
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; Fri, 23 Sep 2011 18:23:24 +0200
Received: from umic-i4-137-226-45-197.nn.rwth-aachen.de ([unknown] [137.226.45.197]) 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 <0LRZ003KEEP8R730@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Fri, 23 Sep 2011 17:22:20 +0200 (CEST)
From: Tobias Heer <heer@cs.rwth-aachen.de>
Date: Fri, 23 Sep 2011 17:22:23 +0200
Message-id: <2D027A08-C710-422D-8BC9-99BA1E6780DD@cs.rwth-aachen.de>
To: HIP <hipsec@ietf.org>
X-Mailer: Apple Mail (2.1084)
Subject: [Hipsec] RFC5201 Ticket #32:
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Fri, 23 Sep 2011 16:20:58 -0000
Hello, I did a literature search and the only problem I found was the "small subroup" attack. The attack is described in RFC2785 (http://tools.ietf.org/html/rfc2785) and was recently brought up again in [1]. The issue is that an attacker (Initiator) can use a DH key with a smaller subgroup. This makes finding the private key easier if this process can be repeated (the Initiator repeats this procedure with different keys for the same Responder key). Therefore, using a static Responder key can create vulnerabilities against this attack. As described in RFC2785 and [1], validating the Initiator key according to RFC2631 (http://tools.ietf.org/html/rfc2631#section-2.1.5) avoids this issue. The validation process is simple: " 1. Verify that y lies within the interval [2,p-1]. If it does not, the key is invalid. 2. Compute y^q mod p. If the result == 1, the key is valid. Otherwise the key is invalid. "[RFC2785] TLS (RFC5246) addresses the very same issue by stating: "If the same DH keypair is to be used for multiple handshakes, either because the client or server has a certificate containing a fixed DH keypair or because the server is reusing DH keys, care must be taken to prevent small subgroup attacks. Implementations SHOULD follow the guidelines found in [SUBGROUP]." [SUBGROUP] = [RFC2785]. I propose to add a similar wording to the text passage in RFC5201-bis that discusses repeated use of the Responder's DH key. ############### Text for RFC5201-bis ############### "If the Responder uses the same DH keypair for multiple handshakes. It must take care to avoid small subgroup attacks [RFC2785]. To avoid these attacks, when receiving the I2 message, the Responder SHOULD validate the Initiators DH public key as described in [RFC2785] Section 3.1. In case the validation fails, the Responder MUST NOT generate a DH shared key and MUST silently abort the HIP BEX." ############### /Text for RFC5201-bis ############### Do you have comments or suggestions? Cheers! Tobias References: [1] Alfred Menezes and Berkant Ustaoglu. "On reusing ephemeral keys in Diffie-Hellman key agreement protocols". International Journal of Applied Cryptography (January 2010), pp. 154-158. -- 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://www.comsys.rwth-aachen.de/team/tobias-heer/ blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi pgp id: AEECA5BF
- [Hipsec] RFC5201 Ticket #32: Tobias Heer
- [Hipsec] Fwd: RFC5201 Ticket #33: Tobias Heer
- Re: [Hipsec] Fwd: RFC5201 Ticket #33: Miika Komu
- Re: [Hipsec] Fwd: RFC5201 Ticket #33: Henderson, Thomas R
- Re: [Hipsec] Fwd: RFC5201 Ticket #33: Tobias Heer
- Re: [Hipsec] Fwd: RFC5201 Ticket #33: Henderson, Thomas R