From mkomu@cs.hut.fi Mon Oct 3 07:18:10 2011 Return-Path: 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 68F2F21F8A57 for ; Mon, 3 Oct 2011 07:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.25 X-Spam-Level: X-Spam-Status: No, score=-6.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, 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 UCd+wjlqRnSV for ; Mon, 3 Oct 2011 07:18:06 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id E006921F8997 for ; Mon, 3 Oct 2011 07:18:05 -0700 (PDT) Received: from hutcs.cs.hut.fi ([130.233.192.10] helo=[127.0.0.1]) by mail.cs.hut.fi with esmtp (Exim 4.54) id 1RAjOF-0001ew-Mb for hipsec@ietf.org; Mon, 03 Oct 2011 17:21:07 +0300 Message-ID: <4E89C4D3.6020201@cs.hut.fi> Date: Mon, 03 Oct 2011 17:21:07 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: hipsec@ietf.org References: <2D027A08-C710-422D-8BC9-99BA1E6780DD@cs.rwth-aachen.de> <68474D0D-3404-46E5-B611-153139AF6041@cs.rwth-aachen.de> In-Reply-To: <68474D0D-3404-46E5-B611-153139AF6041@cs.rwth-aachen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] Fwd: RFC5201 Ticket #33: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 14:18:10 -0000 Hi Tobias, I support your proposal. On 09/24/2011 02:05 AM, Tobias Heer wrote: > Sorry, I just realized that the previous mail was missing an important part: the problem description. > > Here is the description from the tracker: > > Issue 33: reusing DH public values > http://trac.tools.ietf.org/wg/hip/trac/ticket/33 > ---------------------------------------------------------------- > > 5201 states in the R1 processing section, regarding DH reuse: > " If a future version of this protocol is considered, we strongly > recommend that these issues be studied again." > Has this issue been studied again? Should this text be replaced? > > ---------------------------------------------------------------- > > > Anfang der weitergeleiteten E-Mail: > >> Von: Tobias Heer >> Datum: 23. September 2011 17:22:23 MESZ >> An: HIP >> Betreff: [Hipsec] RFC5201 Ticket #32: >> >> 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 mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec > From thomas.r.henderson@boeing.com Mon Oct 3 11:27:44 2011 Return-Path: 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 83DCE21F8C1D for ; Mon, 3 Oct 2011 11:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.472 X-Spam-Level: X-Spam-Status: No, score=-106.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 asnM65rKA+vN for ; Mon, 3 Oct 2011 11:27:43 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id 56A2D21F8C13 for ; Mon, 3 Oct 2011 11:27:43 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p93IUVRK019414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 3 Oct 2011 11:30:32 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p93IUR0u011360; Mon, 3 Oct 2011 13:30:28 -0500 (CDT) Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p93IUAca010589 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 3 Oct 2011 13:30:23 -0500 (CDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Mon, 3 Oct 2011 11:30:15 -0700 From: "Henderson, Thomas R" To: "'Tobias Heer'" , HIP Date: Mon, 3 Oct 2011 11:30:14 -0700 Thread-Topic: [Hipsec] Fwd: RFC5201 Ticket #33: Thread-Index: Acx6RVBsQchfej1jR7qT+u68bsHfvAHs4ftw Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CEFAF0862@XCH-NW-10V.nw.nos.boeing.com> References: <2D027A08-C710-422D-8BC9-99BA1E6780DD@cs.rwth-aachen.de> <68474D0D-3404-46E5-B611-153139AF6041@cs.rwth-aachen.de> In-Reply-To: <68474D0D-3404-46E5-B611-153139AF6041@cs.rwth-aachen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Hipsec] Fwd: RFC5201 Ticket #33: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 18:27:44 -0000 > > > > ############### 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." I am fine with the above, but what about possibly generating a new NOTIFY i= n response to this (such as: INVALID_PUBLIC_KEY 13 The received public key is considered to be invalid. These notifications can sometimes be more helpful to debugging things than = trying to interpret silent discards. Note that RFC 2631 hints of IPR on the proposed mechanism: http://tools.ietf.org/html/rfc2631#section-2.1.5 From heer@informatik.rwth-aachen.de Thu Oct 6 03:52:41 2011 Return-Path: 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 B9F2F21F8AF7 for ; Thu, 6 Oct 2011 03:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.677 X-Spam-Level: X-Spam-Status: No, score=-4.677 tagged_above=-999 required=5 tests=[AWL=0.124, 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 TyrbOEXn60yp for ; Thu, 6 Oct 2011 03:52:40 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by ietfa.amsl.com (Postfix) with ESMTP id BA80321F8A35 for ; Thu, 6 Oct 2011 03:52:40 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) 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 <0LSN009ER5118N70@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Thu, 06 Oct 2011 12:55:49 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.68,495,1312149600"; d="scan'208";a="65637631" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Thu, 06 Oct 2011 12:55:50 +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 <0LSN00JT85113F60@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Thu, 06 Oct 2011 12:55:49 +0200 (CEST) From: Tobias Heer In-reply-to: <7CC566635CFE364D87DC5803D4712A6C4CEFAF0862@XCH-NW-10V.nw.nos.boeing.com> Date: Thu, 06 Oct 2011 12:55:49 +0200 Message-id: <2A80CC62-58E5-45C8-A98D-A103076FE63E@cs.rwth-aachen.de> References: <2D027A08-C710-422D-8BC9-99BA1E6780DD@cs.rwth-aachen.de> <68474D0D-3404-46E5-B611-153139AF6041@cs.rwth-aachen.de> <7CC566635CFE364D87DC5803D4712A6C4CEFAF0862@XCH-NW-10V.nw.nos.boeing.com> To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.1084) Cc: HIP Subject: Re: [Hipsec] Fwd: RFC5201 Ticket #33: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 10:52:41 -0000 Am 03.10.2011 um 20:30 schrieb Henderson, Thomas R: >>> >>> ############### 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." > > I am fine with the above, but what about possibly generating a new NOTIFY in response to this (such as: > > INVALID_PUBLIC_KEY 13 > > The received public key is considered to be invalid. > > These notifications can sometimes be more helpful to debugging things than trying to interpret silent discards. > Thanks. Since the verification happens after the puzzle verification and the return routability check, it should be safe to send a response. However, since there is no existing HIP association at that point, an ICMP message would be better (see RFC5201 Section 4.3). Did you have a specific reason to suggest a NOTIFY? 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://www.comsys.rwth-aachen.de/team/tobias-heer/ blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi pgp id: AEECA5BF From thomas.r.henderson@boeing.com Thu Oct 6 10:45:44 2011 Return-Path: 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 A894E11E80C2 for ; Thu, 6 Oct 2011 10:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.477 X-Spam-Level: X-Spam-Status: No, score=-106.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 2WGrf8r0Op7Q for ; Thu, 6 Oct 2011 10:45:44 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id 20E9D11E80B7 for ; Thu, 6 Oct 2011 10:45:44 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p96HmfmO014098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Oct 2011 10:48:43 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p96HmfZ1015482; Thu, 6 Oct 2011 12:48:41 -0500 (CDT) Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p96HmeQY015460 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 6 Oct 2011 12:48:41 -0500 (CDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Thu, 6 Oct 2011 10:48:40 -0700 From: "Henderson, Thomas R" To: "'Tobias Heer'" Date: Thu, 6 Oct 2011 10:48:40 -0700 Thread-Topic: [Hipsec] Fwd: RFC5201 Ticket #33: Thread-Index: AcyEFoXx2h7MuTjFSfmTmGTL7JYXHAAN/KqQ Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CF0E94595@XCH-NW-10V.nw.nos.boeing.com> References: <2D027A08-C710-422D-8BC9-99BA1E6780DD@cs.rwth-aachen.de> <68474D0D-3404-46E5-B611-153139AF6041@cs.rwth-aachen.de> <7CC566635CFE364D87DC5803D4712A6C4CEFAF0862@XCH-NW-10V.nw.nos.boeing.com> <2A80CC62-58E5-45C8-A98D-A103076FE63E@cs.rwth-aachen.de> In-Reply-To: <2A80CC62-58E5-45C8-A98D-A103076FE63E@cs.rwth-aachen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: HIP Subject: Re: [Hipsec] Fwd: RFC5201 Ticket #33: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 17:45:44 -0000 > -----Original Message----- > From: Tobias Heer [mailto:heer@cs.rwth-aachen.de] > Sent: Thursday, October 06, 2011 3:56 AM > To: Henderson, Thomas R > Cc: HIP > Subject: Re: [Hipsec] Fwd: RFC5201 Ticket #33: >=20 >=20 > Am 03.10.2011 um 20:30 schrieb Henderson, Thomas R: >=20 > >>> > >>> ############### 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." > > > > I am fine with the above, but what about possibly generating a new > NOTIFY in response to this (such as: > > > > INVALID_PUBLIC_KEY 13 > > > > The received public key is considered to be invalid. > > > > These notifications can sometimes be more helpful to debugging things > than trying to interpret silent discards. > > > Thanks. >=20 > Since the verification happens after the puzzle verification and the > return routability check, it should be safe to send a response. > However, since there is no existing HIP association at that point, an > ICMP message would be better (see RFC5201 Section 4.3). Did you have a > specific reason to suggest a NOTIFY? >=20 I don't care strongly, but I would note that the current specification seem= s to limit the generation of ICMP to the case of the host not wanting to en= ter into HIP association at all due to policy. The above seemed to me to b= e a case of signaling a parameter problem with the peer's key, which seemed= to be covered under the range of NOTIFICATION values between 11-20. It seems to me that the last sentence of section 4.1.5 " A HIP NOTIFY messa= ge is not used because no HIP session exists between the two hosts at that = time." is not consistent with some cases already defined for sending a NOTI= FY (some of which are sent despite no HIP session existing). Perhaps it co= uld be changed to "A HIP NOTIFY message is not used because an ICMP message= could be generated without further involvement of the HIP process, particu= larly if policy filtering is performed separately from HIP processing." =20 - Tom From internet-drafts@ietf.org Fri Oct 28 08:03:07 2011 Return-Path: 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 A7D7521F8B64; Fri, 28 Oct 2011 08:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 6yKCFY3PvJdX; Fri, 28 Oct 2011 08:03:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E2421F853A; Fri, 28 Oct 2011 08:03:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111028150307.27000.65790.idtracker@ietfa.amsl.com> Date: Fri, 28 Oct 2011 08:03:07 -0700 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-reload-instance-04.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 15:03:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Host Identity Protocol Working Group = of the IETF. Title : Host Identity Protocol-Based Overlay Networking Environm= ent (HIP BONE) Instance Specification for REsource LOcation And Discovery (= RELOAD) Author(s) : Ari Keranen Gonzalo Camarillo Jouni Maenpaa Filename : draft-ietf-hip-reload-instance-04.txt Pages : 10 Date : 2011-10-28 This document is the Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) instance specification for the REsource LOcation And Discovery (RELOAD) protocol. The document provides the details needed to build a RELOAD-based overlay that uses HIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-reload-instance-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-hip-reload-instance-04.txt From ari.keranen@nomadiclab.com Fri Oct 28 08:10:04 2011 Return-Path: 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 C978321F848F for ; Fri, 28 Oct 2011 08:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 JdmNH9Aimftg for ; Fri, 28 Oct 2011 08:10:03 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id E24A021F88B6 for ; Fri, 28 Oct 2011 08:10:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id A1FE34E6D3 for ; Fri, 28 Oct 2011 18:10:01 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6x7uccWUOBa4 for ; Fri, 28 Oct 2011 18:10:01 +0300 (EEST) Received: from n212.nomadiclab.com (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 189AE4E6E8 for ; Fri, 28 Oct 2011 18:09:57 +0300 (EEST) Message-ID: <4EAAC5C4.5010900@nomadiclab.com> Date: Fri, 28 Oct 2011 18:09:56 +0300 From: Ari Keranen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: hipsec@ietf.org References: <20111028150307.27000.65790.idtracker@ietfa.amsl.com> In-Reply-To: <20111028150307.27000.65790.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-reload-instance-04.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 15:10:04 -0000 Hi all, This was a minor update on the enrollment/configuration: instead of using HIP BONE specific DNS SRV type we use "HIP" in the overlay-link-protocol config element (as suggested by the RELOAD spec). We are still waiting for the base RELOAD draft to pass the IESG review and become an RFC before making final round of edits to the instance spec. Cheers, Ari On 10/28/11 6:03 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. > > Title : Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD) > Author(s) : Ari Keranen > Gonzalo Camarillo > Jouni Maenpaa > Filename : draft-ietf-hip-reload-instance-04.txt > Pages : 10 > Date : 2011-10-28 > > This document is the Host Identity Protocol-Based Overlay Networking > Environment (HIP BONE) instance specification for the REsource > LOcation And Discovery (RELOAD) protocol. The document provides the > details needed to build a RELOAD-based overlay that uses HIP. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-hip-reload-instance-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-hip-reload-instance-04.txt > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From internet-drafts@ietf.org Mon Oct 31 08:36:09 2011 Return-Path: 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 00CC721F8CCB; Mon, 31 Oct 2011 08:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 INSx7tbKF0XV; Mon, 31 Oct 2011 08:36:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6802721F8CC2; Mon, 31 Oct 2011 08:36:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031153608.21467.42534.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 08:36:08 -0700 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc5201-bis-07.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 15:36:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Host Identity Protocol Working Group = of the IETF. Title : Host Identity Protocol Version 2 (HIPv2) Author(s) : Robert Moskowitz Tobias Heer Petri Jokela Thomas R. Henderson Filename : draft-ietf-hip-rfc5201-bis-07.txt Pages : 124 Date : 2011-10-31 This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a SIGMA- compliant Diffie-Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper-layer protocols, such as TCP and UDP. This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-rfc5201-bis-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-hip-rfc5201-bis-07.txt From heer@informatik.rwth-aachen.de Mon Oct 31 08:40:12 2011 Return-Path: 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 5E98121F86DD for ; Mon, 31 Oct 2011 08:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[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 qy8SsM3WMFkj for ; Mon, 31 Oct 2011 08:40:11 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7676421F84BB for ; Mon, 31 Oct 2011 08:40:11 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) 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 <0LTX00HJLSUY2YH0@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Mon, 31 Oct 2011 16:40:10 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.69,432,1315173600"; d="scan'208";a="67759766" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Mon, 31 Oct 2011 16:40:10 +0100 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 <0LTX00C5ESUYLM10@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Mon, 31 Oct 2011 16:40:10 +0100 (CET) From: Tobias Heer Date: Mon, 31 Oct 2011 16:40:16 +0100 Message-id: <4273E2D0-C0EB-4E9F-B238-699FB24F53B0@cs.rwth-aachen.de> References: <20111031153608.21467.42534.idtracker@ietfa.amsl.com> To: HIP X-Mailer: Apple Mail (2.1084) Subject: [Hipsec] Fwd: I-D Action: draft-ietf-hip-rfc5201-bis-07.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 15:40:12 -0000 Hi, as you may have noticed, we have submitted a new version of RFC5201-bis. The short changelog indicates: there are only few changes left. Here is the changelog: 11.1. Changes from draft-ietf-hip-rfc5201-bis-06 o Made echoing the R1_COUNTER in the I2 mandatory if the R1 contains an R1_COUNTER. This required to make the R1 counter a critical parameter. Hence, the parameter type number of the R1_COUNTER changed from 128 to 129. o Made KDF dependent on DH Group to enable negotiation of the KDF. Right now the two main blockers are comments from the IESG on the choice of cryptographic algorithms for RSA (PSS) and randomized hashing. I hope we can get these resolved really soon so that we can proceed. Best regards, Tobias Anfang der weitergeleiteten E-Mail: > Von: internet-drafts@ietf.org > Datum: 31. Oktober 2011 16:36:08 MEZ > An: i-d-announce@ietf.org > Kopie: hipsec@ietf.org > Betreff: [Hipsec] I-D Action: draft-ietf-hip-rfc5201-bis-07.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. > > Title : Host Identity Protocol Version 2 (HIPv2) > Author(s) : Robert Moskowitz > Tobias Heer > Petri Jokela > Thomas R. Henderson > Filename : draft-ietf-hip-rfc5201-bis-07.txt > Pages : 124 > Date : 2011-10-31 > > This document specifies the details of the Host Identity Protocol > (HIP). HIP allows consenting hosts to securely establish and > maintain shared IP-layer state, allowing separation of the identifier > and locator roles of IP addresses, thereby enabling continuity of > communications across IP address changes. HIP is based on a SIGMA- > compliant Diffie-Hellman key exchange, using public key identifiers > from a new Host Identity namespace for mutual peer authentication. > The protocol is designed to be resistant to denial-of-service (DoS) > and man-in-the-middle (MitM) attacks. When used together with > another suitable security protocol, such as the Encapsulated Security > Payload (ESP), it provides integrity protection and optional > encryption for upper-layer protocols, such as TCP and UDP. > > This document obsoletes RFC 5201 and addresses the concerns raised by > the IESG, particularly that of crypto agility. It also incorporates > lessons learned from the implementations of RFC 5201. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-hip-rfc5201-bis-07.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-hip-rfc5201-bis-07.txt > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec -- 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