From heer@informatik.rwth-aachen.de Thu Sep 1 00:33:32 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 5E8BC21F8AF2 for ; Thu, 1 Sep 2011 00:33:32 -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 I3FRq+rM8diu for ; Thu, 1 Sep 2011 00:33:31 -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 41A4021F8AD9 for ; Thu, 1 Sep 2011 00:33:31 -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-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LQU000OP2EERK10@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Thu, 01 Sep 2011 09:35:02 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.68,312,1312149600"; d="scan'208";a="62794379" 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, 01 Sep 2011 09:35:03 +0200 Received: from [137.226.12.158] ([unknown] [137.226.12.158]) 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 <0LQU00IF42EES970@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Thu, 01 Sep 2011 09:35:02 +0200 (CEST) From: Tobias Heer In-reply-to: <4E3F966C.2040202@ericsson.com> Date: Thu, 01 Sep 2011 09:35:04 +0200 Message-id: <10A0000D-1B75-4991-A39C-AE6B6AC37C70@cs.rwth-aachen.de> References: <4E3F966C.2040202@ericsson.com> To: HIP X-Mailer: Apple Mail (2.1084) Subject: Re: [Hipsec] Status of our milestones 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, 01 Sep 2011 07:33:32 -0000 Hello, after having put my major personal roadblock aside, I'd like to get back to RFC5201-bis and get the last issues resolved. There are still some (few) open issues we need to address. Not all of them can be addressed without any discussion. Therefore I'd like to ask for some opinions here. All tickets can be found in the ticket system. I'll start with two of the easier ones: Ticket 22: R1_COUNTER inclusion in I2 ------------------------------------- http://trac.tools.ietf.org/wg/hip/trac/ticket/22 RFC 5201 makes it optional to echo the R1 counter in the !I2!. However, when its optional, its hard to implement because you have to account for the case that the counter is present or missing in the I2. Skipping the counter all together is not an option because the Initiator uses it to sort out old R1s - so we need it in the R1. Alternatively, we could leave it out of the !I2! and the Responder could encode the required generation information into the R1 ECHO_REQUEST. It would get back the information in any case because the ECHO_RESPONSE in the !I2! is a MUST. However, we'd have some redundancy with the R1_COUNTER in the R1 then (which we can't remove because of the reasons stated above). My conclusion: I'd make it a MUST. Any comments on this? Ticket 27: IESG: allow negotiation of KDF ----------------------------------------- The IESG commented that the key distribution function should be negotiable. We defined a new and better KDF. Are we done now? I guess not. We have two options. Tie the KDF to the Diffie Hellman Group and negotiate it together with the DH group in the DH group list (my preferred option) OR negotiate it separately. As I view it, changing the KDF should only happen a) if something goes horribly wrong and the current KDF becomes insecure or b) if you want to change the scenario in which you want to apply HIP radically (e.g., if you move towards embedded systems). I think both cases will not demand high flexibility in the choice of the KDF (you don't pick another KDF just because you can). Moreover, we still have plenty of available DH_GROUP IDs left. I would opt for making the KDF exchangeable but to fix it to the DH group ID. Any objections? I'm looking forward to your feedback. Tobias Am 08.08.2011 um 09:55 schrieb Gonzalo Camarillo: > Folks, > > please, have a look at the dates of our milestones and note that we are > already a few months behind. > > https://datatracker.ietf.org/wg/hip/charter/ > > It's time to put some more energy into the bis drafts. > > With respect to the native NAT traversal draft and the RELOAD instance > draft, they are waiting for the bis drafts and the RELOAD draft to be > more mature, respectively. The good news is that the RELOAD draft is > already being reviewed by the IESG and will likely be published shortly. > > Cheers, > > Gonzalo > > _______________________________________________ > 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 From internet-drafts@ietf.org Thu Sep 1 10:27:29 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 9367121F97EE; Thu, 1 Sep 2011 10:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.419 X-Spam-Level: X-Spam-Status: No, score=-102.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 tjWfgu5AvaJt; Thu, 1 Sep 2011 10:27:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2B421F97DE; Thu, 1 Sep 2011 10:27:29 -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.60 Message-ID: <20110901172729.6480.47140.idtracker@ietfa.amsl.com> Date: Thu, 01 Sep 2011 10:27:29 -0700 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc4423-bis-03.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: Thu, 01 Sep 2011 17:27:29 -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 Architecture Author(s) : Robert Moskowitz Filename : draft-ietf-hip-rfc4423-bis-03.txt Pages : 27 Date : 2011-09-01 This memo describes a new namespace, the Host Identity namespace, and a new protocol layer, the Host Identity Protocol, between the internetworking and transport layers. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. This document obsoletes RFC 4423 and addresses the concerns raised by the IESG, particularly that of crypto agility. It incorporates lessons learned from the implementations of RFC 5201 and goes further to explain how HIP works as a secure signalling channel. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-rfc4423-bis-03.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-rfc4423-bis-03.txt From rgm@htt-consult.com Thu Sep 1 10:50: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 F1CAC21F9783 for ; Thu, 1 Sep 2011 10:50:12 -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 OuEqgOnofDER for ; Thu, 1 Sep 2011 10:50:11 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 9E30421F9768 for ; Thu, 1 Sep 2011 10:50:11 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id F150C62A8B; Thu, 1 Sep 2011 17:51:23 +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 wUmdDmvQKOVT; Thu, 1 Sep 2011 13:51:12 -0400 (EDT) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 7A5BB62A85; Thu, 1 Sep 2011 13:51:12 -0400 (EDT) Message-ID: <4E5FC610.7030504@htt-consult.com> Date: Thu, 01 Sep 2011 13:51:12 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Henderson, Thomas R" References: <7CC566635CFE364D87DC5803D4712A6C4CED25B0F2@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4CED25B0F2@XCH-NW-10V.nw.nos.boeing.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: [Hipsec] Well back at this yet again -- Re: RFC4423bis review 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, 01 Sep 2011 17:50:13 -0000 Finally completed an update of 4423-bis. now to NOT get bogged down in minutia in 5201-bis... On 04/04/2011 10:35 AM, Henderson, Thomas R wrote: > Robert, > > Here are some comments on RFC4423bis that I would be > willing to provide specific text inputs if you and others agree. > I also have editorial nits that can be handled offline. > > Section 1 > --------- > In paragraph 2, it would read better to introduce the concept of > a Host Identity before talking about the Host Identifier. Also, > clarify that there is exactly one Host Identifier for each Host > Identity, but that there can be multiple Host Identities for each > real computing platform. Also, the last sentence of this paragraph > should probably refer to Identifiers and not identities. > > Suggested text: > > The proposed Host Identity namespace fills an important gap between > the IP and DNS namespaces. A Host Identity conceptually refers > to a computing platform, and there may be multiple such Host > Identities per computing platform (because the platform may wish > to present a different identity to different communicating peers). > The Host Identity namespace consists of Host Identifiers (HI). > There is exactly one Host Identifier for each Host Identity. Is there? Can there be multiple hashes applied to a single Host Identity making for multiple Host Identifiers? > While > this text later talks about non-cryptographic Host Identifiers, > the architecture focuses on the case in which Host Identifiers are > cryptographic in nature. Specifically, the Host Identifier is the > public key of an asymmetric key-pair. Each Host Identity uniquely > identifies a single host, i.e., no two hosts have the same Host > Identity. If two or more computing platforms have the same Host > Identifier, then they are instantiating a distributed host. The Host > Identifier can either be public (e.g. published in the DNS), or > unpublished. Client systems will tend to have both public and > unpublished Host Identifiers. > > In other drafts, we have gone out of our way to avoid referring > to IPsec (because it is a whole suite of protocols) and instead > specifically refer to ESP. Suggest a global change from IPsec > to ESP in this document. IPsec left in two places. Please review these and check that all ESP usages are correct. I think I got it all. > Section 2.2 > ----------- > > I would reorder Host Identity Hash to come before Host Identity Tag. > Also, the Host Identity Tag in practice is not just the cryptographic > bits but some other bits, so the definition should reflect that it > is not soley hash bits. done. > Section 3 > --------- > I was not sure about the statement that IP addresses are a confounding > of two namespaces. I think it may be more accurate to say that > the namespaces for endpoint identifiers and interface names overlap > since IP addresses are used for both names (or that there is > no separate namespace for endpoint identifiers, for historical reasons). > > Here is suggested replacement text for paragraph 3: > > The IP addressing namespace has been overloaded to name both > interfaces (at layer-3) and endpoints (for the endpoint-specific > part of layer-3, and for layer-4). In their role as interface > names, IP addresses are sometimes called "locators" and serve > as an address within a routing topology. I grant your point. I have a particular attachment to the term 'confounding', as one of my Stat profs was always confounding us with it! But I will go with this due to the evolution of the discussion of IP address 'meaning' with one change: as an endpoint within a routing topology. > In the last paragraph of section 3, IMO these sentences needs more > clarification: > > Firstly, dynamic readdressing cannot be directly managed. Predates neighbor discovery and use of MAC addr for 64bits of IPv6 address, so not so true anymore. The impact on the app space in managing address for binding purposes. > Secondly, anonymity is not provided in a consistent, trustable manner. Use of MAC addr makes anonymity 'harder' than when this was written. An ephemeral HIT provides anonymity. > I did not try to rewrite them since I am not completely sure what > is the intended point. Given this any additional comment? > Section 3.1 > ----------- > > In Section 3.1, I would suggest to not use the terminology > "IP kernel" when in other parts of the text, this is referred to as an > endpoint. This was a 'big debate' in the Namespace Research Group: "What are you naming?" In the end the 'IP Stack' was deemed the named entity. Endpoint was considered too vague. So 'IP kernel' equates to the 'IP stack' and thus this terminology. Does anyone have any feelings on this? I did change one instant of kernel to stack. > For this bulleted list, I would preface it by saying that > these were the goals at the onset of the HIP work, since some of the > speculation in these bulleted items actually came to pass. I tried but could not come up with anything readable. > For this bullet: > o It must be possible to create names locally. This can provide > anonymity at the cost of making resolvability very difficult. > > Where names are created is not that relevant to whether they become > published or remain anonymous. So I would suggest instead: > > o It must be possible to create names locally. When such names > are not published, this can provide anonymity at the cost of > making resolvability very difficult. Done. > Section 4 > --------- > I don't know what you mean by using X.509 to notarize the identity > assertion. Do you mean to notarize the binding of an identity > to other names? X.509 to 'notarize' the identity assertion to another namespace. > Section 4.2 > ----------- > This section shouldn't be limited to DNS, but to storing in > databases and directories in general. Also, from a document flow > perspective, this section mentions HIH while Section 4.4 below it > introduces HIH, so suggest to move this after the HIH section. Fixed. > Section 4.3 > ----------- > Again, this text needs to be updated to cover the ORCHID bits. Kind of fixed. I don't say ORCHID, but include the bits. > Section 5 > --------- > > Host Identifiers are not slightly different from interface names; > I would argue that they are substantially different. (paragraph 2) > > I suggest to change "Service" in Figure 1 to "Transport association" Done. > There seem to be two concepts missing from this section. First, > the cost of moving to the right side of Figure 1 is that one needs > to be able to securely bind IP addresses to Host Identifiers, > and one may want to resolve Host Identifiers to IP addresses (the > latter issue isn't a problem with today's architecture). However, > a key aspect of this architecture is that the key management and > signaling association set up by HIP provides the security context > necessary to make this binding. > > Another subtle point with the architecture in Figure 1 is that there > needs to be a demultiplexing from incoming IP address to > host identity for incoming packets, and there is no such packet > field to do this unless fields are added. This can be later mentioned > in the IPsec section (that one fringe benefit of ESP is the > use of SPI as indicies to this context, but if ESP is not used, > something else would be needed here in this architecture). > > It probably bears mentioning somewhere in this section that > the lack of reverse lookup mechanism for HITs, if no such > infrastructure is provided, will possibly hinder referrals. > > There probably could be a section or few paragraphs here about > APIs since there was work done on both a native API and on reusing > legacy API. Help? Nothing done yet on this.... > Section 7 > -------- > > Similar comment here about "ESP" vs. "IPsec". > > It is vague to say that HIP is "friendly" to middleboxes (para. 3). > Instead, suggest to say that HIP provides mechanisms for middlebox > authentication to occur. it is very important that the HIP provides mechanisms for middlebox authentication. > In the fourth paragraph, there is some text on not setting up > more than one SA pair between the same HITs. I don't think this > is necessarily true in multihoming (especially if replay window > concerns exist along different paths). Cleaned up. Please review. > In the next paragraph, it says that HIP is not for gateways, > but at least for the VPLS implementation that we at Boeing are > interested, this is not strictly true. I have added a para: It should be noted that there are already BITW implementations. This is still consistant to the SA bindings above. > Section 9 > --------- > Should mention that RFC5770 is scheduled to be replaced; perhaps > just identify it as an "experimental" version of NAT traversal. Done. > Section 10 > ---------- > It states here that there are few concrete thoughts about HIP and > multicast, yet there have been some studies about this. Perhaps > summarize and reference? Minimal change. Please provide references to include? > Section 11 > ---------- > Probably want to mention the tension here between anonymity and > authentication, and describe how HIP provides new challenges > for systems or users to decide which type of HI to expose when > they start a new session. This is somewhat akin to source address > selection in IP, but I would argue that it is a more serious policy > concern at the HIP level than the robustness concern that exists at > the IP level. > > Probably also want to discuss in this section the policy tradeoff > for opportunistic mode (can provide some security benefits but may > be subject to MITM). Text added, please review. > Section 13 > ---------- > This section remains to be written. Even more now! > Section 14.1 > ------------ > This section should describe that the flatness of HITs makes it > a challenge for ACLs to be aggregated. Added. > Section 14.2 > ------------ > Rather than call this section "non-security considerations" I would > suggest "Alternative HI considerations". Much better! Though the thought of a non-security consideration fitted my whimsy at the time. From andrewmcgr@gmail.com Thu Sep 1 14:45:16 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 01CE221F9875 for ; Thu, 1 Sep 2011 14:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 7+3h14itGoFJ for ; Thu, 1 Sep 2011 14:45:15 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 566AE21F9873 for ; Thu, 1 Sep 2011 14:45:15 -0700 (PDT) Received: by vxi29 with SMTP id 29so2071106vxi.31 for ; Thu, 01 Sep 2011 14:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=44JTqKh7G2qJ/lcV4T4upf46o5TtPaptbyWYuS5bd7w=; b=DzpMBq/8FyMlsmW53U0IjXHdTBLnABysXMVBpt7pmwQd769NOSMGy6uR4KicYJfqWq OfYY72U5ZCYii86xmwBTMG1XI5zI97z6aKEdxcj7N7otCFKSqmSZOaxnwd5cF5R2NL5a k8GSP332olDTd0J2ug/6Z4RdNXsLpFujdctD4= Received: by 10.52.27.167 with SMTP id u7mr344261vdg.350.1314913609159; Thu, 01 Sep 2011 14:46:49 -0700 (PDT) Received: from andrewm-lo.lan (121-74-4-70.telstraclear.net [121.74.4.70]) by mx.google.com with ESMTPS id db1sm256084vdb.14.2011.09.01.14.46.46 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Sep 2011 14:46:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Andrew McGregor In-Reply-To: <4E5FC610.7030504@htt-consult.com> Date: Fri, 2 Sep 2011 09:46:42 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7CC566635CFE364D87DC5803D4712A6C4CED25B0F2@XCH-NW-10V.nw.nos.boeing.com> <4E5FC610.7030504@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.1244.3) Cc: HIP Subject: Re: [Hipsec] Well back at this yet again -- Re: RFC4423bis review 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, 01 Sep 2011 21:45:16 -0000 On 2/09/2011, at 5:51 AM, Robert Moskowitz wrote: > Finally completed an update of 4423-bis. >=20 > now to NOT get bogged down in minutia in 5201-bis... >=20 > On 04/04/2011 10:35 AM, Henderson, Thomas R wrote: >=20 >> Section 3 >> --------- >> I was not sure about the statement that IP addresses are a = confounding >> of two namespaces. I think it may be more accurate to say that >> the namespaces for endpoint identifiers and interface names overlap >> since IP addresses are used for both names (or that there is >> no separate namespace for endpoint identifiers, for historical = reasons). >>=20 >> Here is suggested replacement text for paragraph 3: >>=20 >> The IP addressing namespace has been overloaded to name both >> interfaces (at layer-3) and endpoints (for the endpoint-specific >> part of layer-3, and for layer-4). In their role as interface >> names, IP addresses are sometimes called "locators" and serve >> as an address within a routing topology. >=20 > I grant your point. I have a particular attachment to the term = 'confounding', as one of my Stat profs was always confounding us with = it! >=20 > But I will go with this due to the evolution of the discussion of IP = address 'meaning' with one change: >=20 > as an endpoint within a routing topology. Isn't the exact word you are looking for 'conflation'? As in, using the = same name for multiple different ideas? Andrew= From thomas.r.henderson@boeing.com Thu Sep 1 21:59:24 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 5B06721F9374 for ; Thu, 1 Sep 2011 21:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.414 X-Spam-Level: X-Spam-Status: No, score=-106.414 tagged_above=-999 required=5 tests=[AWL=0.185, 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 8TPAAn-IKfPq for ; Thu, 1 Sep 2011 21:59:23 -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 D5CB321F9369 for ; Thu, 1 Sep 2011 21:59:23 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p8250otX021071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 1 Sep 2011 22:00:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id p8250oMA014135; Thu, 1 Sep 2011 22:00:50 -0700 (PDT) Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p8250jKJ013523 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 1 Sep 2011 22:00:45 -0700 (PDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Thu, 1 Sep 2011 22:00:44 -0700 From: "Henderson, Thomas R" To: "'Andrew McGregor'" , Robert Moskowitz Date: Thu, 1 Sep 2011 22:00:44 -0700 Thread-Topic: [Hipsec] Well back at this yet again -- Re: RFC4423bis review Thread-Index: Acxo8KoTbfA7cxPrTd2vXScooLifvQAPGC0A Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CEFAF06B7@XCH-NW-10V.nw.nos.boeing.com> References: <7CC566635CFE364D87DC5803D4712A6C4CED25B0F2@XCH-NW-10V.nw.nos.boeing.com> <4E5FC610.7030504@htt-consult.com> In-Reply-To: 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] Well back at this yet again -- Re: RFC4423bis review 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, 02 Sep 2011 04:59:24 -0000 > >> The IP addressing namespace has been overloaded to name both > >> interfaces (at layer-3) and endpoints (for the endpoint-specific > >> part of layer-3, and for layer-4). In their role as interface > >> names, IP addresses are sometimes called "locators" and serve > >> as an address within a routing topology. > > > > I grant your point. I have a particular attachment to the term > 'confounding', as one of my Stat profs was always confounding us with > it! > > > > But I will go with this due to the evolution of the discussion of IP > address 'meaning' with one change: > > > > as an endpoint within a routing topology. >=20 > Isn't the exact word you are looking for 'conflation'? As in, using > the same name for multiple different ideas? >=20 Yes, 'conflation' works well here. - Tom From thomas.r.henderson@boeing.com Sat Sep 3 08:01:08 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 F26FB21F8BB5 for ; Sat, 3 Sep 2011 08:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.427 X-Spam-Level: X-Spam-Status: No, score=-106.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 6Y1sTuAeaf6A for ; Sat, 3 Sep 2011 08:01:07 -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 739FE21F8B75 for ; Sat, 3 Sep 2011 08:01:07 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p83F2Men012322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 3 Sep 2011 08:02:26 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p83F2LfW021798; Sat, 3 Sep 2011 08:02:21 -0700 (PDT) Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p83F2LsW021793 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Sat, 3 Sep 2011 08:02:21 -0700 (PDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Sat, 3 Sep 2011 08:02:21 -0700 From: "Henderson, Thomas R" To: "'Robert Moskowitz'" Date: Sat, 3 Sep 2011 08:02:21 -0700 Thread-Topic: Well back at this yet again -- Re: RFC4423bis review Thread-Index: Acxoz8Z0Ombg5y9TRLq7QTU+NAQzEgBcTn9g Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CEFAF06C8@XCH-NW-10V.nw.nos.boeing.com> References: <7CC566635CFE364D87DC5803D4712A6C4CED25B0F2@XCH-NW-10V.nw.nos.boeing.com> <4E5FC610.7030504@htt-consult.com> In-Reply-To: <4E5FC610.7030504@htt-consult.com> 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] Well back at this yet again -- Re: RFC4423bis review 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: Sat, 03 Sep 2011 15:01:08 -0000 > -----Original Message----- > From: Robert Moskowitz [mailto:rgm@htt-consult.com] > Sent: Thursday, September 01, 2011 10:51 AM > To: Henderson, Thomas R > Cc: HIP > Subject: Well back at this yet again -- Re: RFC4423bis review >=20 > Finally completed an update of 4423-bis. >=20 > now to NOT get bogged down in minutia in 5201-bis... >=20 > On 04/04/2011 10:35 AM, Henderson, Thomas R wrote: > > Robert, > > > > Here are some comments on RFC4423bis that I would be > > willing to provide specific text inputs if you and others agree. > > I also have editorial nits that can be handled offline. > > > > Section 1 > > --------- > > In paragraph 2, it would read better to introduce the concept of > > a Host Identity before talking about the Host Identifier. Also, > > clarify that there is exactly one Host Identifier for each Host > > Identity, but that there can be multiple Host Identities for each > > real computing platform. Also, the last sentence of this paragraph > > should probably refer to Identifiers and not identities. > > > > Suggested text: > > > > The proposed Host Identity namespace fills an important gap > between > > the IP and DNS namespaces. A Host Identity conceptually refers > > to a computing platform, and there may be multiple such Host > > Identities per computing platform (because the platform may wish > > to present a different identity to different communicating > peers). > > The Host Identity namespace consists of Host Identifiers (HI). > > There is exactly one Host Identifier for each Host Identity. >=20 > Is there? Can there be multiple hashes applied to a single Host > Identity > making for multiple Host Identifiers? This section doesn't pertain to hashes or HITs, but to the relationship bet= ween host identifier (the public key) and host identity (the abstract notio= n of identity). =20 My proposed text was trying to make this section more internally consistent= , but I think the main issue to resolve still is whether you can have multi= ple keys refer to the same identity, or just a single key per identity. Th= at is, there is already a statement in the draft that there can be multiple= host identities, in the abstract sense, (e.g. an anonymous and a public id= entity) for a computing platform. The question is whether each of these id= entities themselves can have multiple identifiers (keys). If so, is there = a need to be able to bind these host identifiers together somehow? I'll try to provide some suggested text for the other points requiring more= input by next week. - Tom From mkomu@cs.hut.fi Sun Sep 4 03:53:35 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 AC14F21F86EA for ; Sun, 4 Sep 2011 03:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.902 X-Spam-Level: X-Spam-Status: No, score=-5.902 tagged_above=-999 required=5 tests=[AWL=0.697, 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 vob7nXJh0G1q for ; Sun, 4 Sep 2011 03:53:35 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id EC4E321F85EC for ; Sun, 4 Sep 2011 03:53:34 -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 1R0AM6-0001ys-9u for hipsec@ietf.org; Sun, 04 Sep 2011 13:55:14 +0300 Message-ID: <4E635911.2040607@cs.hut.fi> Date: Sun, 04 Sep 2011 13:55:13 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: hipsec@ietf.org References: <4E3F966C.2040202@ericsson.com> <10A0000D-1B75-4991-A39C-AE6B6AC37C70@cs.rwth-aachen.de> In-Reply-To: <10A0000D-1B75-4991-A39C-AE6B6AC37C70@cs.rwth-aachen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] Status of our milestones 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: Sun, 04 Sep 2011 10:53:35 -0000 Hi Tobias, your suggestions seem reasonable to me. On 09/01/2011 10:35 AM, Tobias Heer wrote: > Hello, > > after having put my major personal roadblock aside, I'd like to get back to RFC5201-bis and get the last issues resolved. > > There are still some (few) open issues we need to address. Not all of them can be addressed without any discussion. > Therefore I'd like to ask for some opinions here. All tickets can be found in the ticket system. > > I'll start with two of the easier ones: > > Ticket 22: R1_COUNTER inclusion in I2 > ------------------------------------- > http://trac.tools.ietf.org/wg/hip/trac/ticket/22 > > RFC 5201 makes it optional to echo the R1 counter in the !I2!. However, when its > optional, its hard to implement because you have to account for the case that > the counter is present or missing in the I2. Skipping the counter all together > is not an option because the Initiator uses it to sort out old R1s - so we need > it in the R1. Alternatively, we could leave it out of the !I2! and the Responder > could encode the required generation information into the R1 ECHO_REQUEST. It > would get back the information in any case because the ECHO_RESPONSE in the !I2! is a MUST. > However, we'd have some redundancy with the R1_COUNTER in the R1 then (which we > can't remove because of the reasons stated above). > > My conclusion: I'd make it a MUST. Any comments on this? > > Ticket 27: IESG: allow negotiation of KDF > ----------------------------------------- > The IESG commented that the key distribution function should be negotiable. We > defined a new and better KDF. Are we done now? I guess not. We have two > options. Tie the KDF to the Diffie Hellman Group and negotiate it together with > the DH group in the DH group list (my preferred option) OR negotiate it > separately. As I view it, changing the KDF should only happen a) if something > goes horribly wrong and the current KDF becomes insecure or b) if you want to > change the scenario in which you want to apply HIP radically (e.g., if you move > towards embedded systems). I think both cases will not demand high flexibility > in the choice of the KDF (you don't pick another KDF just because you can). > Moreover, we still have plenty of available DH_GROUP IDs left. I would opt for > making the KDF exchangeable but to fix it to the DH group ID. > > Any objections? > > > I'm looking forward to your feedback. > > Tobias > > > > Am 08.08.2011 um 09:55 schrieb Gonzalo Camarillo: > >> Folks, >> >> please, have a look at the dates of our milestones and note that we are >> already a few months behind. >> >> https://datatracker.ietf.org/wg/hip/charter/ >> >> It's time to put some more energy into the bis drafts. >> >> With respect to the native NAT traversal draft and the RELOAD instance >> draft, they are waiting for the bis drafts and the RELOAD draft to be >> more mature, respectively. The good news is that the RELOAD draft is >> already being reviewed by the IESG and will likely be published shortly. >> >> Cheers, >> >> Gonzalo >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec > From samu.varjonen@hiit.fi Mon Sep 5 00:50:45 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 C153C21F8AD9 for ; Mon, 5 Sep 2011 00:50:45 -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 P4Nhb3Y8k6nc for ; Mon, 5 Sep 2011 00:50:45 -0700 (PDT) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1C23821F8AF0 for ; Mon, 5 Sep 2011 00:50:45 -0700 (PDT) Received: from [128.214.114.246] (wel-36.pc.hiit.fi [128.214.114.246]) by argo.otaverkko.fi (Postfix) with ESMTP id 2276C25F87D for ; Mon, 5 Sep 2011 10:52:27 +0300 (EEST) Message-ID: <4E647FBB.9050105@hiit.fi> Date: Mon, 05 Sep 2011 10:52:27 +0300 From: Samu Varjonen User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: hipsec@ietf.org References: <4D7D730F.5050800@hiit.fi> In-Reply-To: <4D7D730F.5050800@hiit.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] rfc5201-bis-04 internationalized domain names 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, 05 Sep 2011 07:50:45 -0000 Hi, I do not remember seeing any comments on this mail that I sent earlier and the issue is still there. On 14/03/11 03:44, Samu Varjonen wrote: > Hi, > > Draft-ietf-hip-rfc5201-bis includes the following text in section 5.2.8. > > "The format for the FQDN is defined in RFC 1035 [RFC1035] Section 3.1. > The format for the NAI is defined in [RFC4282]" > > From these references the RFC4282 supports internationalized usernames > and internationalization of the realm portion. RFC1035 defines the > domain names as sequences of ASCII only labels. > > I propose the addition of the support for internationalized domain names for > HOST_ID. This would mean the following modification to the > draft-ietf-hip-rfc5201-bis section 5.2.8. > It seems to be 5.2.9 now. > " > The format for the FQDN is defined in [RFC1035] Section 3.1. > Internationalized Domain Names (IDNs) MAY be included in the Domain > Identifier (DI). Conforming implementations MUST convert IDNs to the > ASCII compatible Encoding (ACE) format as specified in Section 4 of > [RFC3490] before storage to the DI. When comparing the FQDNs for > equality, conforming implementations MUST perform a case-insensitive > exact match on the entire FQDN. Conforming implementations should > convert IDNs to Unicode before display by performing the conversion > operation specified in Section 4 of [RFC3490]. The non-conforming > implementations may identify IDNs by checking the inclusion of the IDN > ACE label additional characters "xn--" in any capitalization. All > implementations MUST allow for increased space requirements for IDNs in the DI. > > The format and internationalization for NAI is defined in [RFC4282]. > " > > Comments and a sanity check would be appreciated. > > BR, > Samu Varjonen > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From thomas.r.henderson@boeing.com Tue Sep 6 08:42: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 7F8B121F8BF4 for ; Tue, 6 Sep 2011 08:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.439 X-Spam-Level: X-Spam-Status: No, score=-106.439 tagged_above=-999 required=5 tests=[AWL=0.160, 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 zBm29PvI8soR for ; Tue, 6 Sep 2011 08:42:03 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id C3FD621F8BEB for ; Tue, 6 Sep 2011 08:42:03 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p86FhYbj026225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 6 Sep 2011 10:43:39 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p86FhYPd011293; Tue, 6 Sep 2011 08:43:34 -0700 (PDT) Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p86FhXJN011274 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 6 Sep 2011 08:43:34 -0700 (PDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Tue, 6 Sep 2011 08:43:33 -0700 From: "Henderson, Thomas R" To: "'Robert Moskowitz'" Date: Tue, 6 Sep 2011 08:43:33 -0700 Thread-Topic: [Hipsec] Well back at this yet again -- Re: RFC4423bis review Thread-Index: Acxoz8Z0Ombg5y9TRLq7QTU+NAQzEgBcTn9gAJiSWOA= Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CEFAF06CD@XCH-NW-10V.nw.nos.boeing.com> References: <7CC566635CFE364D87DC5803D4712A6C4CED25B0F2@XCH-NW-10V.nw.nos.boeing.com> <4E5FC610.7030504@htt-consult.com> <7CC566635CFE364D87DC5803D4712A6C4CEFAF06C8@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4CEFAF06C8@XCH-NW-10V.nw.nos.boeing.com> 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] Well back at this yet again -- Re: RFC4423bis review 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, 06 Sep 2011 15:42:04 -0000 > -----Original Message----- > From: hipsec-bounces@ietf.org [mailto:hipsec-bounces@ietf.org] On > Behalf Of Henderson, Thomas R > Sent: Saturday, September 03, 2011 8:02 AM > To: 'Robert Moskowitz' > Cc: HIP > Subject: Re: [Hipsec] Well back at this yet again -- Re: RFC4423bis > review >=20 >=20 >=20 > > -----Original Message----- > > From: Robert Moskowitz [mailto:rgm@htt-consult.com] > > Sent: Thursday, September 01, 2011 10:51 AM > > To: Henderson, Thomas R > > Cc: HIP > > Subject: Well back at this yet again -- Re: RFC4423bis review > > > > Finally completed an update of 4423-bis. > > > > now to NOT get bogged down in minutia in 5201-bis... > > > > On 04/04/2011 10:35 AM, Henderson, Thomas R wrote: > > > Robert, > > > > > > Here are some comments on RFC4423bis that I would be > > > willing to provide specific text inputs if you and others agree. > > > I also have editorial nits that can be handled offline. > > > > > > Section 1 > > > --------- > > > In paragraph 2, it would read better to introduce the concept of > > > a Host Identity before talking about the Host Identifier. Also, > > > clarify that there is exactly one Host Identifier for each Host > > > Identity, but that there can be multiple Host Identities for each > > > real computing platform. Also, the last sentence of this paragraph > > > should probably refer to Identifiers and not identities. > > > > > > Suggested text: > > > > > > The proposed Host Identity namespace fills an important gap > > between > > > the IP and DNS namespaces. A Host Identity conceptually refers > > > to a computing platform, and there may be multiple such Host > > > Identities per computing platform (because the platform may > wish > > > to present a different identity to different communicating > > peers). > > > The Host Identity namespace consists of Host Identifiers (HI). > > > There is exactly one Host Identifier for each Host Identity. > > > > Is there? Can there be multiple hashes applied to a single Host > > Identity > > making for multiple Host Identifiers? >=20 > This section doesn't pertain to hashes or HITs, but to the relationship > between host identifier (the public key) and host identity (the > abstract notion of identity). >=20 > My proposed text was trying to make this section more internally > consistent, but I think the main issue to resolve still is whether you > can have multiple keys refer to the same identity, or just a single key > per identity. That is, there is already a statement in the draft that > there can be multiple host identities, in the abstract sense, (e.g. an > anonymous and a public identity) for a computing platform. The > question is whether each of these identities themselves can have > multiple identifiers (keys). If so, is there a need to be able to bind > these host identifiers together somehow? >=20 I had some off-list discussion of this issue over the weekend so I would li= ke to propose a resolution. The proposed text would replace the second and= third paragraphs of section 1 of rfc4423-bis-03, and it is the last paragr= aph below that tries to clarify the relationship between Host Identity and = Host Identifier: The proposed Host Identity namespace fills an important gap between the IP and DNS namespaces. A Host Identity conceptually refers to a computing platform, and there may be multiple such Host Identities per computing platform (because the platform may wish to present a different identity to different communicating peers). The Host Identity namespace consists of Host Identifiers (HI). While this text later talks about non-cryptographic Host Identifiers, the architecture focuses on the case in which Host Identifiers are cryptographic in nature. Specifically, the Host Identifier is the public key of an asymmetric key-pair. =20 There is a subtle but important difference between Host Identities and Host Identifiers. An Identity refers to the abstract entity that is identified. An Identifier, on the other hand, refers to the concrete bit pattern that is used in the identification process. It is intended that no two hosts have the same Host Identity; each=20 Host Identity and corresponding Host Identifier uniquely identifies a single host. If two or more computing platforms have the same Host Identifier, then either they are instantiating a=20 distributed host, or there has been an accidental or intentional violation of the uniqueness property of a Host Identity (e.g., due to malicious host impersonation arising from key theft). The architecture also allows for multiple Host Identifiers to be associated with the same abstract identity, such as due to=20 key revocation and renewal procedures over time. The Host Identifier can either be public (e.g. published in the DNS), or unpublished. Client systems will tend to have both public and unpublished Host Identifiers. From thomas.r.henderson@boeing.com Tue Sep 6 08:59:20 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 007B521F8C31 for ; Tue, 6 Sep 2011 08:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 G5KyQEzlEg3Z for ; Tue, 6 Sep 2011 08:59:19 -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 7C44821F8C2B for ; Tue, 6 Sep 2011 08:59:19 -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 p86G0mZT010560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 6 Sep 2011 09:00:59 -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 p86G0koj015444; Tue, 6 Sep 2011 11:00:47 -0500 (CDT) Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p86G0fJT014977 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 6 Sep 2011 11:00:46 -0500 (CDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Tue, 6 Sep 2011 09:00:45 -0700 From: "Henderson, Thomas R" To: "'Samu Varjonen'" , "hipsec@ietf.org" Date: Tue, 6 Sep 2011 09:00:44 -0700 Thread-Topic: [Hipsec] rfc5201-bis-04 internationalized domain names Thread-Index: AcxroMhVQGXN8Ni8RwiJR9sKA41j0gBDR5XQ Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CEFAF06D0@XCH-NW-10V.nw.nos.boeing.com> References: <4D7D730F.5050800@hiit.fi> <4E647FBB.9050105@hiit.fi> In-Reply-To: <4E647FBB.9050105@hiit.fi> 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] rfc5201-bis-04 internationalized domain names 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, 06 Sep 2011 15:59:20 -0000 > > " > > The format for the FQDN is defined in [RFC1035] Section 3.1. > > Internationalized Domain Names (IDNs) MAY be included in the Domain > > Identifier (DI). Conforming implementations MUST convert IDNs to the > > ASCII compatible Encoding (ACE) format as specified in Section 4 of > > [RFC3490] before storage to the DI. When comparing the FQDNs for > > equality, conforming implementations MUST perform a case-insensitive > > exact match on the entire FQDN. Conforming implementations should > > convert IDNs to Unicode before display by performing the conversion > > operation specified in Section 4 of [RFC3490]. The non-conforming > > implementations may identify IDNs by checking the inclusion of the > IDN > > ACE label additional characters "xn--" in any capitalization. All > > implementations MUST allow for increased space requirements for IDNs > in the DI. > > > > The format and internationalization for NAI is defined in [RFC4282]. > > " > > > > Comments and a sanity check would be appreciated. > > I don't have any objection to adding the above (I can't really provide a sa= nity check since I'm not familiar with IDNs and we haven't tried to impleme= nt this). - Tom From thomas.r.henderson@boeing.com Tue Sep 6 09:32:38 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 B1CE021F8B85 for ; Tue, 6 Sep 2011 09:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.458 X-Spam-Level: X-Spam-Status: No, score=-106.458 tagged_above=-999 required=5 tests=[AWL=0.142, 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 HMcw+-YSwUZa for ; Tue, 6 Sep 2011 09:32:38 -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 207CB21F8B7E for ; Tue, 6 Sep 2011 09:32:38 -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 p86GYIEr007858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 6 Sep 2011 09:34:19 -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 p86GYHWH018340; Tue, 6 Sep 2011 11:34:17 -0500 (CDT) Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p86GYGwB018311 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 6 Sep 2011 11:34:17 -0500 (CDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Tue, 6 Sep 2011 09:34:16 -0700 From: "Henderson, Thomas R" To: "'Tobias Heer'" , HIP Date: Tue, 6 Sep 2011 09:34:15 -0700 Thread-Topic: [Hipsec] Status of our milestones Thread-Index: Acxoea1Yo9FELMWeQ36ULC4rNlHPcwEOQIEA Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CEFAF06D2@XCH-NW-10V.nw.nos.boeing.com> References: <4E3F966C.2040202@ericsson.com> <10A0000D-1B75-4991-A39C-AE6B6AC37C70@cs.rwth-aachen.de> In-Reply-To: <10A0000D-1B75-4991-A39C-AE6B6AC37C70@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] Status of our milestones 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, 06 Sep 2011 16:32:38 -0000 > -----Original Message----- > From: hipsec-bounces@ietf.org [mailto:hipsec-bounces@ietf.org] On > Behalf Of Tobias Heer > Sent: Thursday, September 01, 2011 12:35 AM > To: HIP > Subject: Re: [Hipsec] Status of our milestones >=20 > Hello, >=20 > after having put my major personal roadblock aside, I'd like to get > back to RFC5201-bis and get the last issues resolved. >=20 > There are still some (few) open issues we need to address. Not all of > them can be addressed without any discussion. > Therefore I'd like to ask for some opinions here. All tickets can be > found in the ticket system. >=20 > I'll start with two of the easier ones: >=20 > Ticket 22: R1_COUNTER inclusion in I2 > ------------------------------------- > http://trac.tools.ietf.org/wg/hip/trac/ticket/22 >=20 > RFC 5201 makes it optional to echo the R1 counter in the !I2!. However, > when its > optional, its hard to implement because you have to account for the > case that > the counter is present or missing in the I2. Skipping the counter all > together > is not an option because the Initiator uses it to sort out old R1s - so > we need > it in the R1. Alternatively, we could leave it out of the !I2! and the > Responder > could encode the required generation information into the R1 > ECHO_REQUEST. It > would get back the information in any case because the ECHO_RESPONSE in > the !I2! is a MUST. > However, we'd have some redundancy with the R1_COUNTER in the R1 then > (which we > can't remove because of the reasons stated above). >=20 > My conclusion: I'd make it a MUST. Any comments on this? >=20 > Ticket 27: IESG: allow negotiation of KDF > ----------------------------------------- > The IESG commented that the key distribution function should be > negotiable. We > defined a new and better KDF. Are we done now? I guess not. We have > two > options. Tie the KDF to the Diffie Hellman Group and negotiate it > together with > the DH group in the DH group list (my preferred option) OR negotiate it > separately. As I view it, changing the KDF should only happen a) if > something > goes horribly wrong and the current KDF becomes insecure or b) if you > want to > change the scenario in which you want to apply HIP radically (e.g., if > you move > towards embedded systems). I think both cases will not demand high > flexibility > in the choice of the KDF (you don't pick another KDF just because you > can). > Moreover, we still have plenty of available DH_GROUP IDs left. I would > opt for > making the KDF exchangeable but to fix it to the DH group ID. >=20 > Any objections? >=20 >=20 > I'm looking forward to your feedback. >=20 I agree with your proposed resolutions. - Tom From heer@informatik.rwth-aachen.de Thu Sep 8 01:17: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 3774321F8B4C for ; Thu, 8 Sep 2011 01:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.056 X-Spam-Level: X-Spam-Status: No, score=-4.056 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, 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 fZ9CtdxPwU5R for ; Thu, 8 Sep 2011 01:17: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 4572321F8B0A for ; Thu, 8 Sep 2011 01:17:10 -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 <0LR70074D33OOBD0@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Thu, 08 Sep 2011 10:19:01 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.68,349,1312149600"; d="scan'208";a="63318300" 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, 08 Sep 2011 10:19:01 +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 <0LR700DUK33OA480@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Thu, 08 Sep 2011 10:19:00 +0200 (CEST) From: Tobias Heer In-reply-to: <10A0000D-1B75-4991-A39C-AE6B6AC37C70@cs.rwth-aachen.de> Date: Thu, 08 Sep 2011 10:19:03 +0200 Message-id: <3664DFA9-4880-4794-8997-1EE0EA8DDC45@cs.rwth-aachen.de> References: <4E3F966C.2040202@ericsson.com> <10A0000D-1B75-4991-A39C-AE6B6AC37C70@cs.rwth-aachen.de> To: Tobias Heer X-Mailer: Apple Mail (2.1084) Cc: HIP Subject: [Hipsec] Resolution of Ticket 22 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, 08 Sep 2011 08:17:12 -0000 Am 01.09.2011 um 09:35 schrieb Tobias Heer: > Ticket 22: R1_COUNTER inclusion in I2 > ------------------------------------- > http://trac.tools.ietf.org/wg/hip/trac/ticket/22 Old text: The R1_COUNTER parameter is optional. It SHOULD be included in the R1 (in which case, it is covered by the signature), and if present in the R1, it MAY be echoed (including the Reserved field verbatim) by the Initiator in the I2 packet. New text: Support for the R1_COUNTER parameter is mandatory. It SHOULD be included in the R1 (in which case, it is covered by the signature), and if present in the R1, it MUST be echoed (including the Reserved field verbatim) by the Initiator in the I2 packet. Implications: Making the R1 parameter mandatory requires a parameter number change from 128 to 129. Attention: This change requires implementations to change the parameter number. 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 heer@informatik.rwth-aachen.de Thu Sep 8 02:59: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 48B3021F8AD9 for ; Thu, 8 Sep 2011 02:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.429 X-Spam-Level: X-Spam-Status: No, score=-4.429 tagged_above=-999 required=5 tests=[AWL=0.372, 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 YssYdz0fyaFM for ; Thu, 8 Sep 2011 02:59:00 -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 EC63021F8B3F for ; Thu, 8 Sep 2011 02:58:59 -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 <0LR700L907TBQKI0@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Thu, 08 Sep 2011 12:00:47 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.68,349,1312149600"; d="scan'208";a="135260083" 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; Thu, 08 Sep 2011 12:00:47 +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 <0LR7006Z27TBHK10@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Thu, 08 Sep 2011 12:00:47 +0200 (CEST) From: Tobias Heer Date: Thu, 08 Sep 2011 12:00:49 +0200 Message-id: <656C55F4-F676-493B-BC64-C8F4F489F86A@cs.rwth-aachen.de> To: HIP X-Mailer: Apple Mail (2.1084) Subject: [Hipsec] Resolution of Ticket 27 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, 08 Sep 2011 09:59:04 -0000 Ticket 27: IESG: allow negotiation of KDF ----------------------------------------- The key resolution is now dependent on the Diffie Hellman Group ID. Hence, it can be changed if needed by introducing new Group IDs. For details see: http://trac.tools.ietf.org/wg/hip/trac/ticket/27#comment:1 http://www.ietf.org/mail-archive/web/hipsec/current/msg03473.html 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 heer@informatik.rwth-aachen.de Thu Sep 8 03:28:20 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 880F021F8AE1 for ; Thu, 8 Sep 2011 03:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.553 X-Spam-Level: X-Spam-Status: No, score=-4.553 tagged_above=-999 required=5 tests=[AWL=0.248, 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 sKfNHxwvMUWo for ; Thu, 8 Sep 2011 03:28:16 -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 3B5AA21F8AE6 for ; Thu, 8 Sep 2011 03:28:16 -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 <0LR700DBJ967RTH0@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Thu, 08 Sep 2011 12:30:07 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.68,349,1312149600"; d="scan'208";a="135267123" 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; Thu, 08 Sep 2011 12:30:08 +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 <0LR7006NM967HK20@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Thu, 08 Sep 2011 12:30:07 +0200 (CEST) From: Tobias Heer Date: Thu, 08 Sep 2011 12:30:09 +0200 Message-id: <8E1835DD-79E6-4A29-8D10-C84E06667D1A@cs.rwth-aachen.de> To: HIP X-Mailer: Apple Mail (2.1084) Subject: [Hipsec] Resolution of Ticket 34 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, 08 Sep 2011 10:28:20 -0000 Ticket 34: replaying CLOSE messages http://trac.tools.ietf.org/wg/hip/trac/ticket/34#comment:1 I closed the ticket because It was addressed already in the last version of the draft. 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 Sep 8 08:46: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 273EA21F84D7 for ; Thu, 8 Sep 2011 08:46: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 MVc5Vv-MyAD8 for ; Thu, 8 Sep 2011 08:46: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 7C73121F84CC for ; Thu, 8 Sep 2011 08:46:42 -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 p88FmYfX009473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 8 Sep 2011 08:48:35 -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 p88FmXES016538 for ; Thu, 8 Sep 2011 10:48:33 -0500 (CDT) Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p88FmOHa016240 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Thu, 8 Sep 2011 10:48:33 -0500 (CDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Thu, 8 Sep 2011 08:48:27 -0700 From: "Henderson, Thomas R" To: HIP Date: Thu, 8 Sep 2011 08:48:26 -0700 Thread-Topic: rfc5206-bis issue review Thread-Index: Acxoea1Yo9FELMWeQ36ULC4rNlHPcwFwQRog Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CEFAF070F@XCH-NW-10V.nw.nos.boeing.com> 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: [Hipsec] rfc5206-bis issue review 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, 08 Sep 2011 15:46:44 -0000 I would like to post a revision of draft-ietf-hip-rfc5206-bis (mobility) an= d to close these issues (tracked here: http://trac.tools.ietf.org/wg/hip/t= rac/query?component=3Drfc5206-bis) Ticket 2: inclusion of LOCATOR in R2 vs. R1 ---------------------------------------------- I previously suggested to close this without any change: http://www.ietf.or= g/mail-archive/web/hipsec/current/msg03428.html I'll do so if no further c= omments. Ticket 4: make before break use case missing -------------------------------------------- Will add this use case Ticket 6: specify peer-locator exposure policies and sending from unannoun= ced locators ----------------------------------------------- Propose to add a statement that it is possible to delay the exposure of add= itional locators, and to send data from previously unannounced locators, as= might arise in certain mobility situations. Ticket 10: LOCATOR/locator terminology ------------------------------------- I propose to resolve this by renaming the 'LOCATOR' parameter to 'LOCATOR_S= ET' Ticket 14: can actual IP addresses of UPDATEs be used as locators, even if= not in LOCATOR set? ---------------------------------------------- Propose to add a statement at the end of the section 5.3 Handling Received = LOCATOR_SETs: "A host MAY add the source IP address of a received HIP packet as a candida= te locator for the peer even if it is not listed in the peer's LOCATOR_SET,= but it SHOULD prefer locators explicitly listed in the LOCATOR_SET." I plan to handle these issues in a later revision:=20 Ticket 5: cross-family handovers missing from RFC5206-bis ----------------------------------------------------------- Extend specification to cover cross-family handovers as described in "Secur= e and Efficient IPv4/IPv6 Handovers Using Host-based Identifier-Locator Spl= it" by Varjonen et al. Ticket 8: decouple locator announcement from SA creation --------------------------------------------------------- make sure that revised specifications handle the use case of decoupling loc= ator announcements from SA creation (as well as the case of integrating the= m). Ticket 11: review ESP_INFO/SPI issues in RFC5206 -------------------------------------------------- this is a request to clarify whether the mappings of SPI to interface or lo= cator are one-one or one-many. draft-melen-hip-nat-mm-00 recommended to av= oid assigning locators on different interfaces to a single SPI (this may be= more an issue for the multihoming draft). Ticket 12: should UPDATE be sent via rendezvous server? -------------------------------------------------------- This requires coordination with RFC5204-bis but I support adding text to do= cument this. Ticket 13: SEQ/ACK handling with respect to UPDATE ---------------------------------------------------- I do not really understand the concern so would like to request specific te= xt change proposal. Ticket 15: suggestion for naming UPDATE packets ------------------------------------------------ The request here is to reduce the number of possible different UPDATE scena= rios, document them better, and modularize the separate concepts. This sho= uld probably be discussed in a separate thread. From mkomu@cs.hut.fi Thu Sep 8 23:18:28 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 104C121F8997 for ; Thu, 8 Sep 2011 23:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.134 X-Spam-Level: X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 7yDrnvpCl2pY for ; Thu, 8 Sep 2011 23:18:27 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id 50EAE21F88B6 for ; Thu, 8 Sep 2011 23:18:27 -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 1R1uRn-0007lm-Ve for hipsec@ietf.org; Fri, 09 Sep 2011 09:20:20 +0300 Message-ID: <4E69B019.7020604@cs.hut.fi> Date: Fri, 09 Sep 2011 09:20:09 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: hipsec@ietf.org References: <7CC566635CFE364D87DC5803D4712A6C4CEFAF070F@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4CEFAF070F@XCH-NW-10V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] rfc5206-bis issue review 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, 09 Sep 2011 06:18:28 -0000 Hi Tom, the changes proposed by you seem fine to me. Looking forward for a new version of the draft. I have asked separately for comments for ticket #13 from the original proposer and it can be closed if there's no additional feedback. On 08/09/11 18:48, Henderson, Thomas R wrote: > I would like to post a revision of draft-ietf-hip-rfc5206-bis (mobility) and to close these issues (tracked here: http://trac.tools.ietf.org/wg/hip/trac/query?component=rfc5206-bis) > > Ticket 2: inclusion of LOCATOR in R2 vs. R1 > ---------------------------------------------- > I previously suggested to close this without any change: http://www.ietf.org/mail-archive/web/hipsec/current/msg03428.html I'll do so if no further comments. > > Ticket 4: make before break use case missing > -------------------------------------------- > Will add this use case > > Ticket 6: specify peer-locator exposure policies and sending from unannounced locators > ----------------------------------------------- > Propose to add a statement that it is possible to delay the exposure of additional locators, and to send data from previously unannounced locators, as might arise in certain mobility situations. > > Ticket 10: LOCATOR/locator terminology > ------------------------------------- > I propose to resolve this by renaming the 'LOCATOR' parameter to 'LOCATOR_SET' > > Ticket 14: can actual IP addresses of UPDATEs be used as locators, even if not in LOCATOR set? > ---------------------------------------------- > Propose to add a statement at the end of the section 5.3 Handling Received LOCATOR_SETs: > > "A host MAY add the source IP address of a received HIP packet as a candidate locator for the peer even if it is not listed in the peer's LOCATOR_SET, but it SHOULD prefer locators explicitly listed in the LOCATOR_SET." > > > > I plan to handle these issues in a later revision: > > Ticket 5: cross-family handovers missing from RFC5206-bis > ----------------------------------------------------------- > Extend specification to cover cross-family handovers as described in "Secure and Efficient IPv4/IPv6 Handovers Using Host-based Identifier-Locator Split" by Varjonen et al. > > Ticket 8: decouple locator announcement from SA creation > --------------------------------------------------------- > make sure that revised specifications handle the use case of decoupling locator announcements from SA creation (as well as the case of integrating them). > > Ticket 11: review ESP_INFO/SPI issues in RFC5206 > -------------------------------------------------- > this is a request to clarify whether the mappings of SPI to interface or locator are one-one or one-many. draft-melen-hip-nat-mm-00 recommended to avoid assigning locators on different interfaces to a single SPI (this may be more an issue for the multihoming draft). > > Ticket 12: should UPDATE be sent via rendezvous server? > -------------------------------------------------------- > This requires coordination with RFC5204-bis but I support adding text to document this. > > Ticket 13: SEQ/ACK handling with respect to UPDATE > ---------------------------------------------------- > I do not really understand the concern so would like to request specific text change proposal. > > Ticket 15: suggestion for naming UPDATE packets > ------------------------------------------------ > The request here is to reduce the number of possible different UPDATE scenarios, document them better, and modularize the separate concepts. This should probably be discussed in a separate thread. > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From internet-drafts@ietf.org Tue Sep 13 10:36: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 7FE6011E809A; Tue, 13 Sep 2011 10:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 U7z0Uc9DyC6p; Tue, 13 Sep 2011 10:36:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD74E11E808D; Tue, 13 Sep 2011 10:36:03 -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.60 Message-ID: <20110913173603.18810.46961.idtracker@ietfa.amsl.com> Date: Tue, 13 Sep 2011 10:36:03 -0700 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc5206-bis-03.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: Tue, 13 Sep 2011 17:36:04 -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 Mobility with the Host Identity Protocol Author(s) : Thomas R. Henderson Christian Vogt Jari Arkko Filename : draft-ietf-hip-rfc5206-bis-03.txt Pages : 33 Date : 2011-09-13 This document defines mobility extensions to the Host Identity Protocol (HIP). Specifically, this document defines a general "LOCATOR_SET" parameter for HIP messages that allows for a HIP= host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host -- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR_SET parameter can also be used to support end-host multihoming, detailed procedures are out of scope for this document. This document obsoletes RFC 5206. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-rfc5206-bis-03.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-rfc5206-bis-03.txt From heer@informatik.rwth-aachen.de Mon Sep 19 08:20:53 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 BBC4E21F8C63 for ; Mon, 19 Sep 2011 08:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.615 X-Spam-Level: X-Spam-Status: No, score=-4.615 tagged_above=-999 required=5 tests=[AWL=0.186, 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 RaL7e4Pllvuf for ; Mon, 19 Sep 2011 08:20:51 -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 A67AD21F8C5E for ; Mon, 19 Sep 2011 08:20:51 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 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 <0LRS00CE202O9L60@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Mon, 19 Sep 2011 17:23:12 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.68,405,1312149600"; d="scan'208";a="64201797" 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, 19 Sep 2011 17:23:12 +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 <0LRS008SR02OUQ10@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Mon, 19 Sep 2011 17:23:12 +0200 (CEST) From: Tobias Heer In-reply-to: <7CC566635CFE364D87DC5803D4712A6C4CEFAF070F@XCH-NW-10V.nw.nos.boeing.com> Date: Mon, 19 Sep 2011 17:23:13 +0200 Content-transfer-encoding: quoted-printable Message-id: <155E3DDD-DFF7-464C-A57B-8DD4B28B05D4@cs.rwth-aachen.de> References: <7CC566635CFE364D87DC5803D4712A6C4CEFAF070F@XCH-NW-10V.nw.nos.boeing.com> To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.1084) Cc: HIP Subject: Re: [Hipsec] rfc5206-bis issue review 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, 19 Sep 2011 15:20:53 -0000 Hi Tom, sorry for the late reply. Better late then never, huh? I agree in all = points. Am 08.09.2011 um 17:48 schrieb Henderson, Thomas R: > I would like to post a revision of draft-ietf-hip-rfc5206-bis = (mobility) and to close these issues (tracked here: = http://trac.tools.ietf.org/wg/hip/trac/query?component=3Drfc5206-bis) ... > Ticket 14: can actual IP addresses of UPDATEs be used as locators, = even if not in LOCATOR set? > ---------------------------------------------- > Propose to add a statement at the end of the section 5.3 Handling = Received LOCATOR_SETs: >=20 > "A host MAY add the source IP address of a received HIP packet as a = candidate locator for the peer even if it is not listed in the peer's = LOCATOR_SET, but it SHOULD prefer locators explicitly listed in the = LOCATOR_SET." This is important. Good solution. >=20 >=20 >=20 .... > Ticket 15: suggestion for naming UPDATE packets > ------------------------------------------------ > The request here is to reduce the number of possible different UPDATE = scenarios, document them better, and modularize the separate concepts. = This should probably be discussed in a separate thread. This will probably be quite some work but I think its worth the effort. = Ren=E9 has been thinking about this. BR,=20 Tobias > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec --=20 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=20 From yaojk@cnnic.cn Mon Sep 19 20:19:25 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 1E8DE21F8634 for ; Mon, 19 Sep 2011 20:19:25 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -97.536 X-Spam-Level: X-Spam-Status: No, score=-97.536 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 cnZN3tI+3vuB for ; Mon, 19 Sep 2011 20:19:24 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id B933E21F862F for ; Mon, 19 Sep 2011 20:19:22 -0700 (PDT) Received: (eyou send program); Tue, 20 Sep 2011 11:21:46 +0800 Message-ID: <516488906.20904@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 20 Sep 2011 11:21:46 +0800 Message-ID: <8C33B509B9F24C6EBB4EF5D339EC18D6@LENOVO47E041CF> From: "Jiankang YAO" To: "Henderson, Thomas R" , "'Samu Varjonen'" , References: <4D7D730F.5050800@hiit.fi> <4E647FBB.9050105@hiit.fi> <515324874.05146@cnnic.cn> Date: Tue, 20 Sep 2011 11:21:46 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailman-Approved-At: Thu, 22 Sep 2011 23:16:33 -0700 Subject: Re: [Hipsec] rfc5201-bis-04 internationalized domain names 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, 20 Sep 2011 03:19:25 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkhlbmRlcnNvbiwgVGhvbWFz IFIiIDx0aG9tYXMuci5oZW5kZXJzb25AYm9laW5nLmNvbT4NClRvOiAiJ1NhbXUgVmFyam9uZW4n IiA8c2FtdS52YXJqb25lbkBoaWl0LmZpPjsgPGhpcHNlY0BpZXRmLm9yZz4NClNlbnQ6IFdlZG5l c2RheSwgU2VwdGVtYmVyIDA3LCAyMDExIDEyOjAwIEFNDQpTdWJqZWN0OiBSZTogW0hpcHNlY10g cmZjNTIwMS1iaXMtMDQgaW50ZXJuYXRpb25hbGl6ZWQgZG9tYWluIG5hbWVzDQoNCg0KPj4gPiAi DQo+PiA+IFRoZSBmb3JtYXQgZm9yIHRoZSBGUUROIGlzIGRlZmluZWQgaW4gW1JGQzEwMzVdIFNl Y3Rpb24gMy4xLg0KPj4gPiBJbnRlcm5hdGlvbmFsaXplZCBEb21haW4gTmFtZXMgKElETnMpIE1B WSBiZSBpbmNsdWRlZCBpbiB0aGUgRG9tYWluDQo+PiA+IElkZW50aWZpZXIgKERJKS4gQ29uZm9y bWluZyBpbXBsZW1lbnRhdGlvbnMgTVVTVCBjb252ZXJ0IElETnMgdG8gdGhlDQo+PiA+IEFTQ0lJ IGNvbXBhdGlibGUgRW5jb2RpbmcgKEFDRSkgZm9ybWF0IGFzIHNwZWNpZmllZCBpbiBTZWN0aW9u IDQgb2YNCj4+ID4gW1JGQzM0OTBdIGJlZm9yZSBzdG9yYWdlIHRvIHRoZSBESS4gV2hlbiBjb21w YXJpbmcgdGhlIEZRRE5zIGZvcg0KPj4gPiBlcXVhbGl0eSwgY29uZm9ybWluZyBpbXBsZW1lbnRh dGlvbnMgTVVTVCBwZXJmb3JtIGEgY2FzZS1pbnNlbnNpdGl2ZQ0KPj4gPiBleGFjdCBtYXRjaCBv biB0aGUgZW50aXJlIEZRRE4uIENvbmZvcm1pbmcgaW1wbGVtZW50YXRpb25zIHNob3VsZA0KPj4g PiBjb252ZXJ0IElETnMgdG8gVW5pY29kZSBiZWZvcmUgZGlzcGxheSBieSBwZXJmb3JtaW5nIHRo ZSBjb252ZXJzaW9uDQo+PiA+IG9wZXJhdGlvbiBzcGVjaWZpZWQgaW4gU2VjdGlvbiA0IG9mIFtS RkMzNDkwXS4gVGhlIG5vbi1jb25mb3JtaW5nDQo+PiA+IGltcGxlbWVudGF0aW9ucyBtYXkgaWRl bnRpZnkgSUROcyBieSBjaGVja2luZyB0aGUgaW5jbHVzaW9uIG9mIHRoZQ0KPj4gSURODQo+PiA+ IEFDRSBsYWJlbCBhZGRpdGlvbmFsIGNoYXJhY3RlcnMgInhuLS0iIGluIGFueSBjYXBpdGFsaXph dGlvbi4gQWxsDQo+PiA+IGltcGxlbWVudGF0aW9ucyBNVVNUIGFsbG93IGZvciBpbmNyZWFzZWQg c3BhY2UgcmVxdWlyZW1lbnRzIGZvciBJRE5zDQo+PiBpbiB0aGUgREkuDQo+PiA+DQo+PiA+IFRo ZSBmb3JtYXQgYW5kIGludGVybmF0aW9uYWxpemF0aW9uIGZvciBOQUkgaXMgZGVmaW5lZCBpbiBb UkZDNDI4Ml0uDQo+PiA+ICINCj4+ID4NCj4+ID4gQ29tbWVudHMgYW5kIGEgc2FuaXR5IGNoZWNr IHdvdWxkIGJlIGFwcHJlY2lhdGVkLg0KPj4gPg0KPiANCj4gSSBkb24ndCBoYXZlIGFueSBvYmpl Y3Rpb24gdG8gYWRkaW5nIHRoZSBhYm92ZSAoSSBjYW4ndCByZWFsbHkgcHJvdmlkZSBhIHNhbml0 eSBjaGVjayBzaW5jZSBJJ20gbm90IGZhbWlsaWFyIHdpdGggSUROcyBhbmQgd2UgaGF2ZW4ndCB0 cmllZCB0byBpbXBsZW1lbnQgdGhpcykuDQo+IA0KDQpJRE5BIGhhcyBiZWVuIHVwZGF0ZWQgdG8g SUROQWJpcyAoUkZDNTg5MC01ODk0KS4NClJGQzM0OTAgaXMgb2Jzb2xldGVkLg0KDQp0aGUgbmV3 IG5hbWUgZm9yIEFDRSBsYWJlbCBpcyBBLWxhYmVsIGluIFJGQzU4OTAuDQoNCg0KSmlhbmthbmcg WWFvDQoNCg0KDQo+IC0gVG9tDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IEhpcHNlYyBtYWlsaW5nIGxpc3QNCj4gSGlwc2VjQGlldGYub3JnDQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaGlwc2Vj From heer@informatik.rwth-aachen.de Fri Sep 23 09:20:58 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 21B9121F8CC4 for ; 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 ; 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 ; 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 Date: Fri, 23 Sep 2011 17:22:23 +0200 Message-id: <2D027A08-C710-422D-8BC9-99BA1E6780DD@cs.rwth-aachen.de> To: HIP 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From heer@informatik.rwth-aachen.de Fri Sep 23 16:03:01 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 60DF221F8C79 for ; Fri, 23 Sep 2011 16:03:01 -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 MiX-600wGTAQ for ; Fri, 23 Sep 2011 16:03:00 -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 6A77B21F8C6D for ; Fri, 23 Sep 2011 16:03:00 -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 <0LS000MLC05AOL20@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Sat, 24 Sep 2011 01:05:34 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.68,433,1312149600"; d="scan'208";a="137965408" 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; Sat, 24 Sep 2011 01:05:34 +0200 Received: from [192.168.3.4] ([unknown] [91.179.73.137]) 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 <0LS0003LZ058R790@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Sat, 24 Sep 2011 01:05:34 +0200 (CEST) From: Tobias Heer Date: Sat, 24 Sep 2011 01:05:32 +0200 References: <2D027A08-C710-422D-8BC9-99BA1E6780DD@cs.rwth-aachen.de> To: HIP Message-id: <68474D0D-3404-46E5-B611-153139AF6041@cs.rwth-aachen.de> X-Mailer: Apple Mail (2.1084) Subject: [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: Fri, 23 Sep 2011 23:03:01 -0000 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 -- 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