From internet-drafts@ietf.org Thu Sep 5 21:48:30 2013 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 C4C0711E8126; Thu, 5 Sep 2013 21:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 Kwt9dGTTEyIw; Thu, 5 Sep 2013 21:48:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A33D21F9FE7; Thu, 5 Sep 2013 21:48:27 -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: 4.70.p1 Message-ID: <20130906044827.26847.74192.idtracker@ietfa.amsl.com> Date: Thu, 05 Sep 2013 21:48:27 -0700 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc5201-bis-13.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, 06 Sep 2013 04:48:30 -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 t= he 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-13.txt Pages : 126 Date : 2013-09-05 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5201-bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-rfc5201-bis-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Sep 5 22:42:31 2013 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 251DE21E81B3; Thu, 5 Sep 2013 22:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 LEC0tMpJ8S5r; Thu, 5 Sep 2013 22:42:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A898F21E8053; Thu, 5 Sep 2013 22:42:30 -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: 4.70.p1 Message-ID: <20130906054230.22781.2155.idtracker@ietfa.amsl.com> Date: Thu, 05 Sep 2013 22:42:30 -0700 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc5202-bis-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, 06 Sep 2013 05:42:31 -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 t= he IETF. Title : Using the Encapsulating Security Payload (ESP) Transport= Format with the Host Identity Protocol (HIP) Author(s) : Petri Jokela Robert Moskowitz Jan Melen Filename : draft-ietf-hip-rfc5202-bis-04.txt Pages : 37 Date : 2013-09-05 Abstract: This memo specifies an Encapsulated Security Payload (ESP) based mechanism for transmission of user data packets, to be used with the Host Identity Protocol (HIP). This document obsoletes RFC 5202. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5202-bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-rfc5202-bis-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-rfc5202-bis-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From thomas.r.henderson@boeing.com Sun Sep 8 21:50:47 2013 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 0684E21F8CB4 for ; Sun, 8 Sep 2013 21:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104 X-Spam-Level: X-Spam-Status: No, score=-104 tagged_above=-999 required=5 tests=[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 xgrLM8NVr9DP for ; Sun, 8 Sep 2013 21:50:35 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 725FE21F8443 for ; Sun, 8 Sep 2013 21:50:26 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r894oPUE019972 for ; Sun, 8 Sep 2013 23:50:25 -0500 Received: from XCH-PHX-509.sw.nos.boeing.com (xch-phx-509.sw.nos.boeing.com [10.57.37.31]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r894oOX0019964 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Sun, 8 Sep 2013 23:50:24 -0500 Received: from XCH-BLV-104.nw.nos.boeing.com ([169.254.4.224]) by XCH-PHX-509.sw.nos.boeing.com ([169.254.9.215]) with mapi id 14.02.0328.011; Sun, 8 Sep 2013 21:50:23 -0700 From: "Henderson, Thomas R" To: HIP Thread-Topic: additional comments on latest RFC5201-bis draft Thread-Index: Ac6tGBeXPhwtszT9RXOaOpOyeT+93A== Date: Mon, 9 Sep 2013 04:50:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "'Anders_Brandt@sigmadesigns.com'" Subject: [Hipsec] additional comments on latest RFC5201-bis draft 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, 09 Sep 2013 04:50:47 -0000 Last week I published a new version of RFC5201-bis: http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-13 This was mainly to address ID-nits and prepare the draft for the next stage= of the review process. However, I also received a number of comments from= Anders Brandt (cc'ed) on the version-12 draft. The purely editorial ones = were included in version-13, but I decided to post a few for review on the = list. In the interest of expediency, I'd like to suggest that we aim for resolvin= g all of these within the next two weeks. 1) Section 4.1, the statement is made: "As a result, it is believed that the HIP opportunistic mode is at least as= secure as current IP." Anders questioned what this statement means. Further clarifications are ne= eded here. 2) Section 5.1 "Since all HIP headers MUST contain the sender's and receiver's HIT fields,= the minimum value for this field is 4, and conversely, the maximum length = of the HIP parameters filed is (255*8-32 =3D 2008 bytes." Anders asks "and IPv6 says 1280 bytes?" which I believe perhaps needs clari= fication or reference to the discussion on HIP fragmentation in Section 5.1= .3. 3) Section 5.3.2 "If the Responder uses the same DH keypair for multiple handshakes. It mus= t take care to avoid small subgroup attacks [RFC2785]." These sentences ar= e marked by Anders, perhaps for grammatical reasons (they should at least b= e combined). 4) Section 6.7.1, R1 Management Anders asks whether it is allowed to make an initiator-only device, if ther= e is a MUST in this section to be able to produce R1s. I do not believe th= at the current protocol allows one to make an initiator-only device; perhap= s this could be clarified. - Tom From rgm@htt-consult.com Mon Sep 9 10:47:27 2013 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 E69B721F9B4D for ; Mon, 9 Sep 2013 10:47:27 -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 mxrStoMAiqSk for ; Mon, 9 Sep 2013 10:47:27 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [IPv6:2607:f4b8:3:0:218:71ff:fe83:66b9]) by ietfa.amsl.com (Postfix) with ESMTP id 14EC521F9A96 for ; Mon, 9 Sep 2013 10:47:27 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 876CD62BA5; Mon, 9 Sep 2013 17:47:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHdkIbuQSPYb; Mon, 9 Sep 2013 13:47:16 -0400 (EDT) Received: from lx120e2.htt-consult.com (lx120e2.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 1E86C633F2; Mon, 9 Sep 2013 13:47:16 -0400 (EDT) Message-ID: <522E09A3.1080605@htt-consult.com> Date: Mon, 09 Sep 2013 13:47:15 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Henderson, Thomas R" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP , "'Anders_Brandt@sigmadesigns.com'" Subject: Re: [Hipsec] additional comments on latest RFC5201-bis draft 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, 09 Sep 2013 17:47:28 -0000 On 09/09/2013 12:50 AM, Henderson, Thomas R wrote: > Last week I published a new version of RFC5201-bis: > http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-13 > > This was mainly to address ID-nits and prepare the draft for the next stage of the review process. However, I also received a number of comments from Anders Brandt (cc'ed) on the version-12 draft. The purely editorial ones were included in version-13, but I decided to post a few for review on the list. > > In the interest of expediency, I'd like to suggest that we aim for resolving all of these within the next two weeks. > > 1) Section 4.1, the statement is made: > > "As a result, it is believed that the HIP opportunistic mode is at least as secure as current IP." > > Anders questioned what this statement means. Further clarifications are needed here. > > 2) Section 5.1 > > "Since all HIP headers MUST contain the sender's and receiver's HIT fields, the minimum value for this field is 4, and conversely, the maximum length of the HIP parameters filed is (255*8-32 = 2008 bytes." > > Anders asks "and IPv6 says 1280 bytes?" which I believe perhaps needs clarification or reference to the discussion on HIP fragmentation in Section 5.1.3. > > 3) Section 5.3.2 > > "If the Responder uses the same DH keypair for multiple handshakes. It must take care to avoid small subgroup attacks [RFC2785]." These sentences are marked by Anders, perhaps for grammatical reasons (they should at least be combined). > > 4) Section 6.7.1, R1 Management > > Anders asks whether it is allowed to make an initiator-only device, if there is a MUST in this section to be able to produce R1s. I do not believe that the current protocol allows one to make an initiator-only device; perhaps this could be clarified. I can think of two reasons that R1 should be supported in all devices: Loss of state. If a device receives a datagram protected with a HIP SPI, but lacks that SPI, perhaps this is due to loss of state by that device (post reboot condition). Sending an I1 to the other party is the way to recover state. Of course we allow for a receiver of an I1 to turn around and send an I1 itself, forcing the R1 generation back on the party that loss state. Rekey. Key exhaustion MAY be addressed by an UPDATE or reruning HIP exchange. Thus either party could force the exchange. Just some quick thoughts. From mkomu@cs.hut.fi Tue Sep 10 00:56:43 2013 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 DCB3021E8137 for ; Tue, 10 Sep 2013 00:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 2ih+b5y9d57n for ; Tue, 10 Sep 2013 00:56:39 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id 20EE811E8100 for ; Tue, 10 Sep 2013 00:56:19 -0700 (PDT) Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTP id D36F83089D7; Tue, 10 Sep 2013 10:56:02 +0300 (EEST) Message-ID: <522ED092.2070402@cs.hut.fi> Date: Tue, 10 Sep 2013 10:56:02 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Henderson, Thomas R" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP , "'Anders_Brandt@sigmadesigns.com'" Subject: Re: [Hipsec] additional comments on latest RFC5201-bis draft 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: Tue, 10 Sep 2013 07:56:44 -0000 Hi, On 09/09/2013 07:50 AM, Henderson, Thomas R wrote: > Last week I published a new version of RFC5201-bis: > http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-13 > > This was mainly to address ID-nits and prepare the draft for the next stage of the review process. However, I also received a number of comments from Anders Brandt (cc'ed) on the version-12 draft. The purely editorial ones were included in version-13, but I decided to post a few for review on the list. > > In the interest of expediency, I'd like to suggest that we aim for resolving all of these within the next two weeks. > > 1) Section 4.1, the statement is made: > > "As a result, it is believed that the HIP opportunistic mode is at least as secure as current IP." > > Anders questioned what this statement means. Further clarifications are needed here. I would just suggest combining this sentence with the previous paragraph. Alternatively, this could perhaps be rephrased as: As a result, opportunistic mode in HIP offers a "better than nothing" security model. Initially, a base exchange authenticated in the opportunistic mode involves a leap of faith subject man-in-the-middle attacks, but subsequent datagrams related to the same HIP association cannot be compromised by a new man-in-the-middle attack. Thus, it can be stated that opportunistic mode in HIP is at least as secure as unprotected IP-based communications. From rgm@htt-consult.com Tue Sep 10 13:01:05 2013 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 27B6C11E8101 for ; Tue, 10 Sep 2013 13:01:05 -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 3sUvpRNzz5H3 for ; Tue, 10 Sep 2013 13:01:03 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [IPv6:2607:f4b8:3:0:218:71ff:fe83:66b9]) by ietfa.amsl.com (Postfix) with ESMTP id CCD9C11E8125 for ; Tue, 10 Sep 2013 12:59:57 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 4092C62A7A; Tue, 10 Sep 2013 19:59:44 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8F2AKb-yCFt; Tue, 10 Sep 2013 15:59:33 -0400 (EDT) Received: from lx120e2.htt-consult.com (lx120e2.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id F29D76340F; Tue, 10 Sep 2013 15:59:29 -0400 (EDT) Message-ID: <522F7A21.5040301@htt-consult.com> Date: Tue, 10 Sep 2013 15:59:29 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Miika Komu References: <522ED092.2070402@cs.hut.fi> In-Reply-To: <522ED092.2070402@cs.hut.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP , "'Anders_Brandt@sigmadesigns.com'" Subject: Re: [Hipsec] additional comments on latest RFC5201-bis draft 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: Tue, 10 Sep 2013 20:01:05 -0000 On 09/10/2013 03:56 AM, Miika Komu wrote: > Hi, > > On 09/09/2013 07:50 AM, Henderson, Thomas R wrote: >> Last week I published a new version of RFC5201-bis: >> http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-13 >> >> This was mainly to address ID-nits and prepare the draft for the next >> stage of the review process. However, I also received a number of >> comments from Anders Brandt (cc'ed) on the version-12 draft. The >> purely editorial ones were included in version-13, but I decided to >> post a few for review on the list. >> >> In the interest of expediency, I'd like to suggest that we aim for >> resolving all of these within the next two weeks. >> >> 1) Section 4.1, the statement is made: >> >> "As a result, it is believed that the HIP opportunistic mode is at >> least as secure as current IP." >> >> Anders questioned what this statement means. Further clarifications >> are needed here. > > I would just suggest combining this sentence with the previous > paragraph. Alternatively, this could perhaps be rephrased as: > > As a result, opportunistic mode in HIP offers a "better than nothing" > security model. Initially, a base exchange authenticated in the > opportunistic mode involves a leap of faith subject man-in-the-middle > attacks, but subsequent datagrams related to the same HIP association > cannot be compromised by a new man-in-the-middle attack. Thus, it can > be stated that opportunistic mode in HIP is at least as secure as > unprotected IP-based communications. +10000 :) I really like this way of putting it. The MITM has one chance only and then must ALWAYS be in the middle. So maybe something else is needed that if the MITM "steps away", the attack is exposed after the fact? From rgm@htt-consult.com Fri Sep 13 08:48:08 2013 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 6E69121E80D3 for ; Fri, 13 Sep 2013 08:48:08 -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 FGSSfpP8SrLL for ; Fri, 13 Sep 2013 08:48:07 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [IPv6:2607:f4b8:3:0:218:71ff:fe83:66b9]) by ietfa.amsl.com (Postfix) with ESMTP id D1D1321E80CA for ; Fri, 13 Sep 2013 08:48:06 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id E1A4262A6D; Fri, 13 Sep 2013 15:48:00 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3IfhyIWCbE7; Fri, 13 Sep 2013 11:47:50 -0400 (EDT) Received: from lx120e2.htt-consult.com (lx120e2.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id D6EFA62A91; Fri, 13 Sep 2013 11:47:49 -0400 (EDT) Message-ID: <523333A0.2040409@htt-consult.com> Date: Fri, 13 Sep 2013 11:47:44 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Gonzalo Camarillo References: <4DB9D913.1070805@htt-consult.com> <4DCAF664.8020506@htt-consult.com> <51E517AE.3030400@ericsson.com> In-Reply-To: <51E517AE.3030400@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] Fwd: IPR Disclosure: Certicom Corp's Statement of IPR Related todraft-ietf-hip-rfc5201-bis-05 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, 13 Sep 2013 15:48:08 -0000 On 07/16/2013 05:51 AM, Gonzalo Camarillo wrote: > Hi Bob, > > following up on this old IPR disclosure, even though the spec now > mandates a co-factor of 1, I have not seen any updated to the IPR > disclosure. Do you know anything else about this? What about the other > two patents referenced in the disclosure? I believe that 5201-bis is technically correct and independent of the disclosed IPR. > > Thanks, > > Gonzalo > > On 11/05/2011 11:49 PM, Robert Moskowitz wrote: >> In some conversations here at IEEE 802 wireless interim, we have 'worked >> out' that the first patent deals with EC co-factors greater than 1. >> Although all of the curves we currently specify have a co-factor of 1, >> we do not state anything about the co-factor in the standard. >> >> We only need to explicitly limit 5201-bis (and HIP-DEX) to curves with a >> co-factor of 1 and avoid the first patent. >> >> Once we work out text on the co-factor, I guess I will send it to my old >> IPsec buddy, Tony Rosati, and see if it addresses their position (I >> understand other standards limit the co-factor to a value of 1). >> >> We are still trying to figure out the others. I hope I can get help on >> working through them. >> >> On 04/28/2011 02:16 PM, Robert Moskowitz wrote: >>> I just received the following: >>> >>> -----Original Message----- >>> From: IETF Secretariat [mailto:ietf-ipr@ietf.org] >>> Sent: Thursday, April 28, 2011 4:50 PM >>> To: robert.moskowitz@icsalabs.com; heer@cs.rwth-aachen.de; >>> petri.jokela@nomadiclab.com; thomas.r.henderson@boeing.com >>> Cc: rdroms.ietf@gmail.com; jari.arkko@piuha.net; >>> "hipsec@ietf.orgdward"@juniper.net; gonzalo.camarillo@ericsson.com; >>> ipr-announce@ietf.org; housley@vigilsec.com >>> Subject: IPR Disclosure: Certicom Corp's Statement of IPR Related >>> todraft-ietf-hip-rfc5201-bis-05 >>> >>> >>> Dear Robert Moskowitz, Tobias Heer, Petri Jokela, Tom Henderson: >>> >>> An IPR disclosure that pertains to your Internet-Draft entitled "Host >>> Identity >>> Protocol Version 2 (HIPv2)" (draft-ietf-hip-rfc5201-bis) was submitted >>> to the >>> IETF Secretariat on 2011-04-17 and has been posted on the "IETF Page of >>> Intellectual Property Rights Disclosures" >>> (https://datatracker.ietf.org/ipr/1541/). The title of the IPR >>> disclosure is >>> "Certicom Corp's Statement of IPR Related to >>> draft-ietf-hip-rfc5201-bis-05.""); >>> >>> The IETF Secretariat >>> >>> >>> >>> _______________________________________________ >>> Hipsec mailing list >>> Hipsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/hipsec >>> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec >> > From iesg-secretary@ietf.org Mon Sep 16 06:43:29 2013 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 35C2011E8257; Mon, 16 Sep 2013 06:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 fSkBnUd-YELw; Mon, 16 Sep 2013 06:43:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF4F11E826D; Mon, 16 Sep 2013 06:43:25 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20130916134325.31446.63326.idtracker@ietfa.amsl.com> Date: Mon, 16 Sep 2013 06:43:25 -0700 X-Mailman-Approved-At: Thu, 19 Sep 2013 00:35:38 -0700 Cc: hipsec@ietf.org Subject: [Hipsec] Last Call: (Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD)) to Experimental RFC X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ietf@ietf.org 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, 16 Sep 2013 13:43:29 -0000 The IESG has received a request from the Host Identity Protocol WG (hip) to consider the following document: - 'Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD)' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-09-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-hip-reload-instance/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-hip-reload-instance/ballot/ No IPR declarations have been submitted directly on this I-D. From thomas.r.henderson@boeing.com Thu Sep 26 13:45:23 2013 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 CEF2021F9E7C for ; Thu, 26 Sep 2013 13:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.3 X-Spam-Level: X-Spam-Status: No, score=-105.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 U8p8qMqzeHj7 for ; Thu, 26 Sep 2013 13:45:18 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 0402D21E8053 for ; Thu, 26 Sep 2013 13:45:14 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r8QKjEG4017668 for ; Thu, 26 Sep 2013 13:45:14 -0700 Received: from XCH-PHX-411.sw.nos.boeing.com (xch-phx-411.sw.nos.boeing.com [10.57.37.42]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r8QKjCmq017655 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 26 Sep 2013 13:45:13 -0700 Received: from XCH-BLV-104.nw.nos.boeing.com ([169.254.4.224]) by XCH-PHX-411.sw.nos.boeing.com ([169.254.11.100]) with mapi id 14.02.0328.011; Thu, 26 Sep 2013 13:45:11 -0700 From: "Henderson, Thomas R" To: HIP Thread-Topic: additional comments on latest RFC5201-bis draft Thread-Index: Ac6tGBeXPhwtszT9RXOaOpOyeT+93AN36k6w Date: Thu, 26 Sep 2013 20:45:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "'Anders_Brandt@sigmadesigns.com'" Subject: Re: [Hipsec] additional comments on latest RFC5201-bis draft 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, 26 Sep 2013 20:45:23 -0000 I'll try to wrap up the inputs and post a revision over the weekend, if no = further comments. Please see inline below. > -----Original Message----- > From: hipsec-bounces@ietf.org [mailto:hipsec-bounces@ietf.org] On > Behalf Of Henderson, Thomas R > Sent: Sunday, September 08, 2013 9:50 PM > To: HIP > Cc: 'Anders_Brandt@sigmadesigns.com' > Subject: [Hipsec] additional comments on latest RFC5201-bis draft >=20 > Last week I published a new version of RFC5201-bis: > http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-13 >=20 > This was mainly to address ID-nits and prepare the draft for the next > stage of the review process. However, I also received a number of > comments from Anders Brandt (cc'ed) on the version-12 draft. The > purely editorial ones were included in version-13, but I decided to > post a few for review on the list. >=20 > In the interest of expediency, I'd like to suggest that we aim for > resolving all of these within the next two weeks. >=20 > 1) Section 4.1, the statement is made: >=20 > "As a result, it is believed that the HIP opportunistic mode is at > least as secure as current IP." >=20 > Anders questioned what this statement means. Further clarifications > are needed here. I propose to address this with the union of Miika and Robert's comments: As a result, opportunistic mode in HIP offers a "better than nothing"=20 security model. Initially, a base exchange authenticated in the opportunist= ic mode involves a leap of faith subject to man-in-the-middle attacks, but = subsequent datagrams related to the same HIP association cannot be compromi= sed by a new man-in-the-middle attack, and further, if the man-in-the-middl= e moves away from the path of the active association, the attack would be e= xposed after the fact. Thus, it can be stated that opportunistic mode in HI= P is at least as secure as unprotected IP-based communications. >=20 > 2) Section 5.1 >=20 > "Since all HIP headers MUST contain the sender's and receiver's HIT > fields, the minimum value for this field is 4, and conversely, the > maximum length of the HIP parameters filed is (255*8-32 =3D 2008 bytes." >=20 > Anders asks "and IPv6 says 1280 bytes?" which I believe perhaps needs > clarification or reference to the discussion on HIP fragmentation in > Section 5.1.3. I propose to add a reference here to the later section on fragmentation req= uirements. >=20 > 3) Section 5.3.2 >=20 > "If the Responder uses the same DH keypair for multiple handshakes. It > must take care to avoid small subgroup attacks [RFC2785]." These > sentences are marked by Anders, perhaps for grammatical reasons (they > should at least be combined). I will just repair the grammatical error (make into one sentence), since no= other comments were received. >=20 > 4) Section 6.7.1, R1 Management >=20 > Anders asks whether it is allowed to make an initiator-only device, if > there is a MUST in this section to be able to produce R1s. I do not > believe that the current protocol allows one to make an initiator-only > device; perhaps this could be clarified. >=20 My view is in line with Robert's on this, so I propose: Old text: All compliant implementations MUST be able to produce R1 packets. New text: All compliant implementations MUST be able to produce R1 packets; even if a= device is configured by policy to only initiate associations, it must be a= ble to process I1s in case of recovery from loss of state or key exhaustion= .