From nobody Mon Oct 10 16:48:23 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6721297AC; Mon, 10 Oct 2016 16:48:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147614330093.31408.6738911328217834226.idtracker@ietfa.amsl.com> Date: Mon, 10 Oct 2016 16:48:20 -0700 Archived-At: Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-multihoming-12.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 10 Oct 2016 23:48:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol of the IETF. Title : Host Multihoming with the Host Identity Protocol Authors : Thomas R. Henderson Christian Vogt Jari Arkko Filename : draft-ietf-hip-multihoming-12.txt Pages : 24 Date : 2016-10-10 Abstract: This document defines host multihoming extensions to the Host Identity Protocol (HIP), by leveraging protocol components defined for host mobility. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-multihoming/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-hip-multihoming-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-multihoming-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 10 16:48:39 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A2E1297BF; Mon, 10 Oct 2016 16:48:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147614331500.31466.16243057750423431797.idtracker@ietfa.amsl.com> Date: Mon, 10 Oct 2016 16:48:35 -0700 Archived-At: Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc5206-bis-14.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 10 Oct 2016 23:48:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol of the IETF. Title : Host Mobility with the Host Identity Protocol Authors : Thomas R. Henderson Christian Vogt Jari Arkko Filename : draft-ietf-hip-rfc5206-bis-14.txt Pages : 37 Date : 2016-10-10 Abstract: This document defines a mobility extension to the Host Identity Protocol (HIP). Specifically, this document defines a "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 how the parameter can be used to preserve communications across a change to the IP address used by one or both peer hosts. The same LOCATOR_SET parameter can also be used to support end-host multihoming (specified in RFC[Replace with the RFC number for draft- ietf-hip-multihoming]). This document obsoletes RFC 5206. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5206-bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-hip-rfc5206-bis-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc5206-bis-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 10 17:23:21 2016 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 EC09E129416 for ; Mon, 10 Oct 2016 17:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.476 X-Spam-Level: X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDZb03mUtyiB for ; Mon, 10 Oct 2016 17:23:18 -0700 (PDT) Received: from mxout21.s.uw.edu (mxout21.s.uw.edu [140.142.32.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F26E129405 for ; Mon, 10 Oct 2016 17:23:18 -0700 (PDT) Received: from hymn04.u.washington.edu (hymn04.u.washington.edu [140.142.8.72]) by mxout21.s.uw.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u9B0Mjh7021193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 10 Oct 2016 17:22:46 -0700 Received: from hymn04.u.washington.edu (localhost [127.0.0.1]) by hymn04.u.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u9B0MhVk001504 for ; Mon, 10 Oct 2016 17:22:43 -0700 Received: from localhost (Unknown UID 17623@localhost) by hymn04.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id u9B0Mh9C001494 for ; Mon, 10 Oct 2016 17:22:43 -0700 X-Auth-Received: from [73.140.18.44] by hymn04.u.washington.edu via HTTP; Mon, 10 Oct 2016 17:22:42 PDT Date: Mon, 10 Oct 2016 17:22:43 -0700 (PDT) From: Tom Henderson To: hipsec@ietf.org Message-ID: User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20) MIME-Version: 1.0 Content-Type: TEXT/HTML; charset=US-ASCII Content-Transfer-Encoding: 8BIT X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.10.11.1816 X-PMX-Server: mxout21.s.uw.edu X-Uwash-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_NO_HTTP 0.1, BODYTEXTH_SIZE_10000_LESS 0, BODY_SIZE_1200_1299 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, __CT 0, __CTE 0, __CTYPE_HTML 0, __HAS_FROM 0, __HAS_HTML 0, __HAS_MSGID 0, __MIME_HTML 0, __MIME_HTML_ONLY 0, __MIME_TEXT_H 0, __MIME_TEXT_H1 0, __MIME_VERSION 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_START 0, __TAG_EXISTS_HTML 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __USER_AGENT 0' Archived-At: Subject: [Hipsec] updates to HIP mobility and multihoming drafts X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 11 Oct 2016 00:23:20 -0000 The new versions of the HIP mobility and multihoming drafts address various review comments received during IESG reviews.

Besides editorial changes, the following changes were made to RFC 5206-bis version 14:

*  Replace references to 'middleboxes' with more specific |'NATs and firewalls' and make reference to RFC 5207
*  Describe a simple heuristic for setting the credit value for Credit-Based Authorization based on sending rate and RTT.
*  Add subsection about privacy concerns of locator exposure to the Security Considerations section.
*  Clarify that a host must be able to receive and avoid reprocessing redundant LOCATOR_SET parameters that may have been sent in parallel to multiple addresses of the host.
*  Clarify that multicast or broadcast addresses must not be announced in a LOCATOR_SET.  

and the following to the multihoming draft version 12:

* Added section about locator privacy concerns ! to the Security Considerations section.
* Added section about relationship to split tunnel issues to the Security Considerations section.

I believe that all outstanding comments and issues have been addressed.

- Tom

From nobody Tue Oct 11 05:19:54 2016 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 0F843129534 for ; Tue, 11 Oct 2016 05:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.196 X-Spam-Level: X-Spam-Status: No, score=-7.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbezf4k54yQD for ; Tue, 11 Oct 2016 05:19:51 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CAF512948F for ; Tue, 11 Oct 2016 05:19:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 633BF6222D for ; Tue, 11 Oct 2016 08:19:50 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id XzzgWf2wABel for ; Tue, 11 Oct 2016 08:19:44 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 0F30E6222C for ; Tue, 11 Oct 2016 08:19:44 -0400 (EDT) References: <850ee302-0a08-178b-7a57-6387c5c54973@labs.htt-consult.com> To: HIP From: Robert Moskowitz X-Forwarded-Message-Id: <850ee302-0a08-178b-7a57-6387c5c54973@labs.htt-consult.com> Message-ID: <8a47c475-99d3-9ac5-4f03-4e25542df5f3@htt-consult.com> Date: Tue, 11 Oct 2016 08:19:42 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <850ee302-0a08-178b-7a57-6387c5c54973@labs.htt-consult.com> Content-Type: multipart/alternative; boundary="------------075D00EB2F26E747CB49481C" Archived-At: Subject: [Hipsec] Fwd: New Version Notification for draft-moskowitz-ssls-hip-00.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 11 Oct 2016 12:19:54 -0000 This is a multi-part message in MIME format. --------------075D00EB2F26E747CB49481C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit This is part of my Secure Session Layer Services effort. This draft defines how HIP manages SSLS associations. There will soon be work on PANA for SSLS (particularly with EAP-TLS). SSLS is defined in 3 IDs that now need to be revised: draft-moskowitz-sse draft-moskowitz-gpcomp draft-hares-i2nsf-ssls (<- in need or significant revisions as I moved some of its content to this ID) Sue Hares and I are working on this for a number of use cases, and will be discussing this work at IETF. One note about gpcomp. We never created support of IPcomp in ESP for HIP. Perhaps someone wants to take that, or just help me with gpcomp for ESP... Bob -------- Forwarded Message -------- Subject: New Version Notification for draft-moskowitz-ssls-hip-00.txt Date: Tue, 11 Oct 2016 05:08:13 -0700 From: internet-drafts@ietf.org To: Liang Xia , Pierpaolo Giacomin , Susan Hares , Robert Moskowitz , Liang Xia , Igor Faynberg A new version of I-D, draft-moskowitz-ssls-hip-00.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Name: draft-moskowitz-ssls-hip Revision: 00 Title: Secure Session Layer Services KMP via HIP Document date: 2016-10-11 Group: Individual Submission Pages: 13 URL:https://www.ietf.org/internet-drafts/draft-moskowitz-ssls-hip-00.txt Status:https://datatracker.ietf.org/doc/draft-moskowitz-ssls-hip/ Htmlized:https://tools.ietf.org/html/draft-moskowitz-ssls-hip-00 Abstract: This memo specifies the details for establishing and maintaining a Secure Session Layer Services (SSLS) association between two applications using the Host Identity Protocol (HIP [RFC7401]). This is primarily achieved by adding SSLS specific HIP parameters for the HIP base exchange. The SSLS association state and security boundaries are also defined. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------075D00EB2F26E747CB49481C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit This is part of my Secure Session Layer Services effort.  This draft defines how HIP manages SSLS associations.  There will soon be work on PANA for SSLS (particularly with EAP-TLS).

SSLS is defined in 3 IDs that now need to be revised:

draft-moskowitz-sse
draft-moskowitz-gpcomp
draft-hares-i2nsf-ssls  (<- in need or significant revisions as I moved some of its content to this ID)

Sue Hares and I are working on this for a number of use cases, and will be discussing this work at IETF.

One note about gpcomp.  We never created support of IPcomp in ESP for HIP.  Perhaps someone wants to take that, or just help me with gpcomp for ESP...


Bob




-------- Forwarded Message --------
Subject: New Version Notification for draft-moskowitz-ssls-hip-00.txt
Date: Tue, 11 Oct 2016 05:08:13 -0700
From: internet-drafts@ietf.org
To: Liang Xia <frank.xialiang@huawei.com>, Pierpaolo Giacomin <yrz@anche.no>, Susan Hares <shares@ndzh.com>, Robert Moskowitz <rgm@labs.htt-consult.com>, Liang Xia <Frank.xialiang@huawei.com>, Igor Faynberg <igorfaynberg@gmail.com> 


A new version of I-D, draft-moskowitz-ssls-hip-00.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name:		draft-moskowitz-ssls-hip
Revision:	00
Title:		Secure Session Layer Services KMP via HIP
Document date:	2016-10-11
Group:		Individual Submission
Pages:		13
URL:            https://www.ietf.org/internet-drafts/draft-moskowitz-ssls-hip-00.txt
Status:         https://datatracker.ietf.org/doc/draft-moskowitz-ssls-hip/
Htmlized:       https://tools.ietf.org/html/draft-moskowitz-ssls-hip-00


Abstract:
   This memo specifies the details for establishing and maintaining a
   Secure Session Layer Services (SSLS) association between two
   applications using the Host Identity Protocol (HIP [RFC7401]).  This
   is primarily achieved by adding SSLS specific HIP parameters for the
   HIP base exchange.  The SSLS association state and security
   boundaries are also defined.

                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
--------------075D00EB2F26E747CB49481C-- From nobody Thu Oct 13 06:53:36 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 185071298B4; Thu, 13 Oct 2016 06:53:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147636681505.2847.1726641415143154718.idtracker@ietfa.amsl.com> Date: Thu, 13 Oct 2016 06:53:35 -0700 Archived-At: Cc: hipsec@ietf.org, hip-chairs@ietf.org, draft-ietf-hip-rfc5206-bis@ietf.org Subject: [Hipsec] Alexey Melnikov's No Objection on draft-ietf-hip-rfc5206-bis-14: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 13 Oct 2016 13:53:35 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-hip-rfc5206-bis-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5206-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my comments. From nobody Fri Oct 14 16:36:30 2016 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 0261F129435; Fri, 14 Oct 2016 16:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.598 X-Spam-Level: X-Spam-Status: No, score=-105.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgSSPNXhJ7Xk; Fri, 14 Oct 2016 16:36:27 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30E2D127ABE; Fri, 14 Oct 2016 16:36:27 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 15005B8090E; Fri, 14 Oct 2016 16:36:27 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20161014233627.15005B8090E@rfc-editor.org> Date: Fri, 14 Oct 2016 16:36:27 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, hipsec@ietf.org, rfc-editor@rfc-editor.org Subject: [Hipsec] RFC 8002 on Host Identity Protocol Certificates X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 14 Oct 2016 23:36:29 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8002 Title: Host Identity Protocol Certificates Author: T. Heer, S. Varjonen Status: Standards Track Stream: IETF Date: October 2016 Mailbox: heer@hs-albsig.de, samu.varjonen@helsinki.fi Pages: 13 Characters: 26613 Obsoletes: RFC 6253 Updates: RFC 7401 I-D Tag: draft-ietf-hip-rfc6253-bis-09.txt URL: https://www.rfc-editor.org/info/rfc8002 DOI: http://dx.doi.org/10.17487/RFC8002 The Certificate (CERT) parameter is a container for digital certificates. It is used for carrying these certificates in Host Identity Protocol (HIP) control packets. This document specifies the certificate parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags (HITs) in X.509 version 3 (v3). The concrete use cases of certificates, including how certificates are obtained and requested and which actions are taken upon successful or failed verification, are specific to the scenario in which the certificates are used. Hence, the definition of these scenario-specific aspects is left to the documents that use the CERT parameter. This document updates RFC 7401 and obsoletes RFC 6253. This document is a product of the Host Identity Protocol Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Oct 14 16:37:07 2016 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 D514512968C; Fri, 14 Oct 2016 16:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.598 X-Spam-Level: X-Spam-Status: No, score=-105.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6R4GfCU7RUHU; Fri, 14 Oct 2016 16:36:41 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22A9B129683; Fri, 14 Oct 2016 16:36:40 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 162EFB809D9; Fri, 14 Oct 2016 16:36:40 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20161014233640.162EFB809D9@rfc-editor.org> Date: Fri, 14 Oct 2016 16:36:40 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, hipsec@ietf.org, rfc-editor@rfc-editor.org Subject: [Hipsec] RFC 8003 on Host Identity Protocol (HIP) Registration Extension X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 14 Oct 2016 23:36:50 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8003 Title: Host Identity Protocol (HIP) Registration Extension Author: J. Laganier, L. Eggert Status: Standards Track Stream: IETF Date: October 2016 Mailbox: julien.ietf@gmail.com, lars@netapp.com Pages: 16 Characters: 34717 Obsoletes: RFC 5203 I-D Tag: draft-ietf-hip-rfc5203-bis-11.txt URL: https://www.rfc-editor.org/info/rfc8003 DOI: http://dx.doi.org/10.17487/RFC8003 This document specifies a registration mechanism for the Host Identity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes. This document obsoletes RFC 5203. This document is a product of the Host Identity Protocol Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Oct 14 16:37:40 2016 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 0889712988E; Fri, 14 Oct 2016 16:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.598 X-Spam-Level: X-Spam-Status: No, score=-105.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPndsHaC0Cni; Fri, 14 Oct 2016 16:37:02 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2914129690; Fri, 14 Oct 2016 16:36:53 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B655FB80A26; Fri, 14 Oct 2016 16:36:53 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20161014233653.B655FB80A26@rfc-editor.org> Date: Fri, 14 Oct 2016 16:36:53 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, hipsec@ietf.org, rfc-editor@rfc-editor.org Subject: [Hipsec] RFC 8004 on Host Identity Protocol (HIP) Rendezvous Extension X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 14 Oct 2016 23:37:06 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8004 Title: Host Identity Protocol (HIP) Rendezvous Extension Author: J. Laganier, L. Eggert Status: Standards Track Stream: IETF Date: October 2016 Mailbox: julien.ietf@gmail.com, lars@netapp.com Pages: 14 Characters: 30487 Obsoletes: RFC 5204 I-D Tag: draft-ietf-hip-rfc5204-bis-08.txt URL: https://www.rfc-editor.org/info/rfc8004 DOI: http://dx.doi.org/10.17487/RFC8004 This document defines a rendezvous extension for the Host Identity Protocol (HIP). The rendezvous extension extends HIP and the HIP Registration Extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multihomed or mobile. This document obsoletes RFC 5204. This document is a product of the Host Identity Protocol Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Oct 14 16:37:45 2016 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 42176129899; Fri, 14 Oct 2016 16:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.598 X-Spam-Level: X-Spam-Status: No, score=-105.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HESjcckKc1OR; Fri, 14 Oct 2016 16:37:19 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F09ED129690; Fri, 14 Oct 2016 16:37:06 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B24D6B80AA8; Fri, 14 Oct 2016 16:37:06 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20161014233706.B24D6B80AA8@rfc-editor.org> Date: Fri, 14 Oct 2016 16:37:06 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, hipsec@ietf.org, rfc-editor@rfc-editor.org Subject: [Hipsec] RFC 8005 on Host Identity Protocol (HIP) Domain Name System (DNS) Extension X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 14 Oct 2016 23:37:33 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8005 Title: Host Identity Protocol (HIP) Domain Name System (DNS) Extension Author: J. Laganier Status: Standards Track Stream: IETF Date: October 2016 Mailbox: julien.ietf@gmail.com Pages: 18 Characters: 39146 Obsoletes: RFC 5205 I-D Tag: draft-ietf-hip-rfc5205-bis-10.txt URL: https://www.rfc-editor.org/info/rfc8005 DOI: http://dx.doi.org/10.17487/RFC8005 This document specifies a resource record (RR) for the Domain Name System (DNS) and how to use it with the Host Identity Protocol (HIP). This RR allows a HIP node to store in the DNS its Host Identity (HI), the public component of the node public-private key pair; its Host Identity Tag (HIT), a truncated hash of its public key (PK); and the domain names of its rendezvous servers (RVSs). This document obsoletes RFC 5205. This document is a product of the Host Identity Protocol Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Oct 21 00:13:12 2016 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 24A04129516 for ; Fri, 21 Oct 2016 00:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.221 X-Spam-Level: X-Spam-Status: No, score=-104.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XS6b5Ispji4j for ; Fri, 21 Oct 2016 00:13:08 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA29E129496 for ; Fri, 21 Oct 2016 00:13:07 -0700 (PDT) X-AuditID: c1b4fb25-5405a9800000793b-b0-5809c001b454 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id F8.14.31035.100C9085; Fri, 21 Oct 2016 09:13:06 +0200 (CEST) Received: from [100.94.10.182] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.3.319.2; Fri, 21 Oct 2016 09:13:05 +0200 To: Miika Komu , =?UTF-8?Q?Ren=c3=a9_Hummen?= References: <20160321203627.12199.62928.idtracker@ietfa.amsl.com> <56F98E90.10601@ericsson.com> <5756C81D.3080601@ericsson.com> <1ade65d6-187e-20e0-fb9b-c3d5b73f42df@ericsson.com> From: Gonzalo Camarillo Message-ID: Date: Fri, 21 Oct 2016 10:13:04 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1ade65d6-187e-20e0-fb9b-c3d5b73f42df@ericsson.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUyM2J7oC7TAc4Ig+eT+SymLprMbLH43Dc2 ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSvjwN9dbAUHUisO7/jO3MB40rGLkZNDQsBE YlvDcXYQW0hgPaPEhW36XYxcQPZqRolll58zgySEBawlpn64CVYkIpAgsX3uJUaIouNMElfO fgYq4uBgFhCV2D6rCqSGTcBCYsut+ywgNq+AvcSGwzvBelkEVCX2H/4GFhcViJG4/uwRG0SN oMTJmU/A4pwCDhKXF35ghBipKbF+lz5ImFlAXqJ562xmiDu1JZY/a2GZwCgwC0n3LISOWUg6 FjAyr2IULU4tTspNNzLWSy3KTC4uzs/Ty0st2cQIDMmDW36r7mC8/MbxEKMAB6MSD++DN+wR QqyJZcWVuYcYJTiYlUR4b+3ijBDiTUmsrEotyo8vKs1JLT7EKM3BoiTOa7byfriQQHpiSWp2 ampBahFMlomDU6qBMT/1Yqmj0NXG+2xNfPuvruOV2XJAdAb7AqVX95JNtv3Yz3Ux38GO7dhn wb85x6KDm+NWtN+Unrpo+7zln52jW9pepxjdTz+bGXgrTMr+Pe+1w2e/v3xct+lJ+5HioC55 uaT/Fkmu96vOcRqlxv3L6Pg6q+8OY9ODT1euXuPKyomtFlEUbvJ/qcRSnJFoqMVcVJwIAEiK 2ntFAgAA Archived-At: Cc: hipsec@ietf.org Subject: Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 21 Oct 2016 07:13:11 -0000 Hi Rene, do you intend to release a new version of the draft with this addition? What is the current status of the draft otherwise? Thanks, Gonzalo On 26/09/2016 4:46 PM, Miika Komu wrote: > Hi René, > > On 09/11/2016 11:06 PM, René Hummen wrote: >> Hello Miika, >> >> going through your email again, I saw a total of four suggestions. >> >> Three of them refer to imprecisions in the text of RFC 7401 (which I >> copy/pasted for HIP DEX). There, I understood that consistency with RFC >> 7401 has a higher priority than only fixing your comments for HIP DEX, >> but keeping the text as is for RFC 7401. This means, I will not modify >> the text in the HIP DEX draft. Is this also your intention? > > yes, 7401 takes precedence over my comments. > >> The last remaining issue is related to the UPDATE message and the >> rekeying procedure (Section 6.10.). Here, I added the following >> paragraph for clarification purposes: >> >> [RFC7402] specifies the rekeying of an existing HIP SA using the >> UPDATE message. This rekeying procedure can also be used with HIP >> DEX. However, where rekeying involves a new Diffie-Hellman key >> exchange, HIP DEX peers MUST establish a new connection in order to >> create a new Pair-wise Key SA due to the use of static ECDH key-pairs >> with HIP DEX. >> >> Does this fix your issue? > > Yes. I assume you mean a new HIP association with connection. > >> BR >> René >> >> >> >> On Tue, Jun 7, 2016 at 3:11 PM, Miika Komu > > wrote: >> >> Hi, >> >> On 06/03/2016 02:20 PM, René Hummen wrote: >> >> This is part 3 of 3. >> >> >> I am fine with your fixes. Some comments below. >> >> On Mon, Mar 28, 2016 at 10:05 PM, Miika Komu >> >> > >> wrote: >> >> > [...] >> >> > 6.2.1. CMAC Calculation >> > >> > [...] >> > >> > >> > 5. Set Checksum and Header Length fields in the HIP >> header to >> > original values. Note that the Checksum and Length fields >> > contain incorrect values after this step. >> >> I guess also the values following HIP_MAC should be restored >> since >> they were wiped in the step 2. >> >> >> I also found this description a bit imprecise, but it is taken >> from >> RFC7401. Step 2 already hints at the fact that parameters >> following >> HIP_MAC may still be of interest: >> "Remove the HIP_MAC parameter, as well as all other parameters >> that follow it with greater Type value, saving the >> contents if >> they will be needed later." >> >> The question is whether we want to fix the description for HIP >> DEX or to >> keep things as they are for consistency reasons. In the former >> case, I >> would prefer to completely rewrite the verification procedure to >> work on >> the received packet without removing any parameters. However, we >> should >> then probably also post an errata to RFC7401. If there are no >> stong >> opinions about that, I would go for the latter option. >> >> >> Latter option works for me too. >> >> > The CKDF-Extract function is the following operation: >> > >> > CKDF-Extract(I, IKM, info) -> PRK >> >> What does the arrow operator signify? I thought that it >> produces PRK, >> but PRK is actually defined below. >> >> >> The arrow is part of a basic mathematical function definition. >> So yes, >> PRK is the output (domain), but we still need to give it a >> proper name. >> I changed the artwork to clearly point out the inputs and >> outputs. >> >> >> Thanks, it is now better. >> >> Please check this section again in the updated version and get >> back to >> me if the above changes do not sufficiently help your >> understanding. >> >> >> It is good now, thanks! >> >> > L length of output keying material in octets >> > (<= 255*RHASH_len/8) >> > | denotes the concatenation >> > >> > The output keying material OKM is calculated as follows: >> > >> > N = ceil(L/RHASH_len/8) >> > T = T(1) | T(2) | T(3) | ... | T(N) >> > OKM = first L octets of T >> > >> > where >> > >> > T(0) = empty string (zero length) >> > T(1) = CMAC(PRK, T(0) | info | 0x01) >> > T(2) = CMAC(PRK, T(1) | info | 0x02) >> > T(3) = CMAC(PRK, T(2) | info | 0x03) >> > ... >> >> The Expand was a bit more clear, but still didn't understand >> how to >> get to the >> Expanded key material due the arrow notation. >> >> >> Ok, let's clarify this as several comments are related to the >> arrow >> notation. For the function definition we use the mathematical >> arrow >> notation (same as RFC 5869) and for the actual opertation we >> use the >> equals sign (same as RFC 5869). In the end, they denote the same >> thing: >> "assign X to Y". >> >> >> Ok, this is what I guessed too. >> >> > (where the constant concatenated to the end of each >> T(n) is a >> > single octet.) >> >> Is there a max value? >> >> >> I am not sure what you mean here. If you refer to the N in T(N) >> then it >> is defined above as N = ceil(L/RHASH_len/8). >> >> >> Yes, I asked about the maximum value for N (which depends on L), but >> never mind. >> >> > 8. The R1 packet may have the A-bit set - in this case, >> the system >> > MAY choose to refuse it by dropping the R1 packet and >> returning >> > to state UNASSOCIATED. The system SHOULD consider >> dropping the >> > R1 packet only if it used a NULL HIT in the I1 packet. >> >> I didn't understand the logic in the last sentence. >> >> >> Someone must have had a reason for this recommendation, but that >> someone >> wasn't me. This is text from RFC7401. Any suggestions how to >> proceed? >> >> >> Fix similarly as the other RFC7401 issue in the beginning of this >> email. >> >> > 6.7. Processing Incoming I2 Packets >> > >> > [...] >> > >> > 5. If the system's state machine is in the I2-SENT >> state, the >> > system MUST make a comparison between its local and >> sender's >> > HITs (similarly as in Section 6.3). If the local HIT is >> smaller >> > than the sender's HIT, it should drop the I2 packet, >> use the >> > peer Diffie-Hellman key, ENCRYPTED_KEY keying material >> and nonce >> > #I from the R1 packet received earlier, and get the local >> > Diffie-Hellman key, ENCRYPTED_KEY keying material, and >> nonce #J >> > from the I2 packet sent to the peer earlier. >> Otherwise, the >> > system should process the received I2 packet and drop any >> > previously derived Diffie-Hellman keying material Kij and >> > ENCRYPTED_KEY keying material it might have generated upon >> > sending the I2 packet previously. The peer >> Diffie-Hellman key, >> > ENCRYPTED_KEY, and the nonce #J are taken from the just >> arrived >> > I2 packet. The local Diffie-Hellman key, ENCRYPTED_KEY >> keying >> > material, and the nonce #I are the ones that were sent >> earlier >> > in the R1 packet. >> >> Please replace "sender" with "peer" (or remote host) in this >> section >> for more symmetric terminology. >> >> get -> obtain >> >> >> I can make these changes if you insist, but I was going for a >> minimal >> diff to RFC 7401. >> >> >> Not insisting. >> >> >> > 11. The implementation SHOULD also verify that the >> Initiator's HIT >> > in the I2 packet corresponds to the Host Identity sent in >> the I2 >> > packet. (Note: some middleboxes may not be able to >> make this >> > verification.) >> >> Why SHOULD? Why not MUST? I think we're talking about >> end-hosts here >> anyway. >> >> >> It is defined this way in RFC 7401. Do you really want to >> change the >> packet processing behavior for HIP DEX only? >> >> >> Fix similarly as the first RFC7401 issue in this email. >> >> > 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets >> >> > UPDATE, CLOSE, and CLOSE_ACK packets are handled >> similarly in HIP DEX >> > as in HIP BEX (see Sections 6.11, 6.12, 6.14, and 6.15 of >> [RFC7401]). >> > The only difference is the that the HIP_SIGNATURE is >> never present >> > and, therefore, is not required to be processed by the >> receiving >> > party. >> >> How does rekeying work with the extract and expand functions? >> >> >> Rekeying is not defined in this document, same as for RFC >> 7401. That >> being said, the rekeying procedure with reuse of the KEYMAT >> from RFC >> 7402 directly translates to HIP DEX. For new KEYMAT, the peers >> need to >> establish a new connection due to the use of static DH keys. >> >> >> Maybe this should be explicitly stated in the draft. >> >> >> >> > 7. HIP Policies >> >> > There are a number of variables that will influence the >> HIP exchanges >> > that each host must support. All HIP DEX implementations >> SHOULD >> > provide for an ACL of Initiator's HI to Responder's HI. >> This ACL >> > SHOULD also include preferred transform and local >> lifetimes. >> > Wildcards SHOULD also be supported for this ACL. >> >> Why ACLs are mandatory? >> >> >> It is not a MUST and considering that HIP DEX is primarly >> targeted at >> things, there is the need to do basic device authorizations >> (based on >> their identities) without a human in the loop. Of course you are >> also >> allowed to use more suffisticated authorization mechanisms. >> >> >> Ok. >> >> ACL -> ACL consisting of >> >> >> Changed to the following text that is closer to RFC 7401: >> " All HIP DEX implementations SHOULD provide for an Access >> Control List >> (ACL), representing for which hosts they accept HIP diet >> exchanges, >> and the preferred transport format and local lifetimes. >> Wildcarding >> SHOULD be supported for such ACLs." >> >> > 8. Security Considerations >> >> > o The HIP DEX HIT generation may present new attack >> opportunities. >> >> They cannot be used in ACLs. Maybe this could be mentioned. >> Can this >> be mitigated by always using full HIs? >> >> >> I changed the bullet-point as follows: >> "The HIP DEX HIT generation may present new attack opportunities. >> Hence, HIP DEX HITs should not be use as the only means to >> identify a peer in an ACL. Instead, the use of the >> peer's HI is >> recommended." >> >> >> Ok. >> >> Note that I added a new Section 8 "Interoperability between HIP >> DEX and >> HIPv2" to satisfy your comment on HIP DEX and HIPv2 >> compatibility. >> >> >> Thanks! >> >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec >> >> >> > From nobody Fri Oct 21 00:22:42 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 100971293D6 for ; Fri, 21 Oct 2016 00:22:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147703456106.23623.8245012840549637198.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 00:22:41 -0700 From: IETF Secretariat Archived-At: Subject: [Hipsec] Milestones changed for hip WG X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 21 Oct 2016 07:22:41 -0000 Changed milestone "WGLC the mobility portion of RFC5206bis", resolved as "Done". Changed milestone "WGLC the multihoming portion of RFC5206bis", resolved as "Done". URL: https://datatracker.ietf.org/wg/hip/charter/ From nobody Fri Oct 21 00:28:53 2016 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 B487B12951E for ; Fri, 21 Oct 2016 00:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.221 X-Spam-Level: X-Spam-Status: No, score=-104.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnwLjH6888PJ for ; Fri, 21 Oct 2016 00:28:49 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29F611293D6 for ; Fri, 21 Oct 2016 00:28:48 -0700 (PDT) X-AuditID: c1b4fb2d-1c7ff700000009f7-0a-5809c3ad2a0c Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id 04.60.02551.DA3C9085; Fri, 21 Oct 2016 09:28:47 +0200 (CEST) Received: from [100.94.10.182] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.319.2; Fri, 21 Oct 2016 09:28:45 +0200 To: Robert Moskowitz , Miika Komu From: Gonzalo Camarillo Message-ID: Date: Fri, 21 Oct 2016 10:28:44 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM2K7tO76w5wRBqdOS1tMXTSZ2aJh3WdG ByaP3ZOa2D2WLPnJFMAUxWWTkpqTWZZapG+XwJWx/Go3e8ECxoo796+yNTC2MHYxcnJICJhI PJn/Gcjm4hASWM8ocW3CfTYIZzWjxJ1dvcwgVSICQRI/u2+ygtjMApISyzf9YgOx2QQsJLbc us8CYgsLKEh8mf0WqJ6Dg1fAXuLjWSmQMIuAqsSDhtVMILaoQIzE9WePwFp5BQQlTs58wgJS ziygKbF+lz7EdHmJ7W/ngG0VEtCWWP6shWUCI98sJB2zEDpmIelYwMi8ilG0OLW4ODfdyFgv tSgzubg4P08vL7VkEyMwxA5u+a27g3H1a8dDjAIcjEo8vA/esEcIsSaWFVfmHmKU4GBWEuGd up8zQog3JbGyKrUoP76oNCe1+BCjNAeLkjiv2cr74UIC6YklqdmpqQWpRTBZJg5OqQbGBu1j 5nnWHy+zTZgzaXumyZ5Oplnrvly/ayP0vljU/l1KUXTmwsj+S9uOPZm3zP/SlG9HP0R+jlkl 6bg5JHbJvd8XTa10Oc5uPfXBjfnq9ZnHHCe8iVk2O1bN/NrZ+LlisjnfHa91rr0r+Pq7UXr/ 7zeBMcqGP//1sV580mx6XlanIuJS8uUafyWW4oxEQy3mouJEAPJY7a8tAgAA Archived-At: Cc: HIP Subject: [Hipsec] RFC 4423bis and hip-dex X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 21 Oct 2016 07:28:51 -0000 Bob, Miika, RFC 4423bis does not reference the hip-dex draft. Should it? https://tools.ietf.org/html/draft-ietf-hip-rfc4423-bis-14 Thanks, Gonzalo From nobody Fri Oct 21 00:33:16 2016 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 C8CDD129518 for ; Fri, 21 Oct 2016 00:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.221 X-Spam-Level: X-Spam-Status: No, score=-104.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXrOZIW439AZ for ; Fri, 21 Oct 2016 00:33:15 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EB3D1294F4 for ; Fri, 21 Oct 2016 00:33:14 -0700 (PDT) X-AuditID: c1b4fb30-f60a598000000cb2-ff-5809c4b83579 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id 9B.D9.03250.8B4C9085; Fri, 21 Oct 2016 09:33:12 +0200 (CEST) Received: from [100.94.10.182] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.319.2; Fri, 21 Oct 2016 09:33:11 +0200 To: HIP From: Gonzalo Camarillo Message-ID: Date: Fri, 21 Oct 2016 10:33:11 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGbE9SnfHEc4Igy+rrS2mLprM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujClL2xgLdjBVXJraydrA+Jaxi5GTQ0LAROL8nw1MXYxcHEIC 6xklbl3czAbhrGaUWPjhBBNIlYiApETP3aUsIDabgIXEllv3wWxhAUWJ5tMLgCZxcPAK2Ev8 X1YFEmYRUJVY8nkuK4gtKhAjcf3ZIzYQm1dAUOLkzCcsIOXMApoS63fpg4SZBeQltr+dwwxi CwloSyx/1sIygZF3FpKOWQgds5B0LGBkXsUoWpxanJSbbmSkl1qUmVxcnJ+nl5dasokRGDYH t/w22MH48rnjIUYBDkYlHt4Hb9gjhFgTy4orcw8xSnAwK4nwTt3PGSHEm5JYWZValB9fVJqT WnyIUZqDRUmc12zl/XAhgfTEktTs1NSC1CKYLBMHp1QDo62Kndl5bfs9zd7McQ+TWLUdz2Rf TnFkMqo/vZvJyp7pj8OzzImPZilOyHdQnBRxItn+o5PLstupkybYHS9acrHtZ4XiD4XtXK43 tBjFL12yfrWD4bX64RfLHnLfm7x9XlL0VsG2L/lW+ziDHp+XWvuoMXeH9zvDNbPfzbsybb3b +eA3PCeqmJRYijMSDbWYi4oTAfDMEfIXAgAA Archived-At: Subject: [Hipsec] Status of our milestones X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 21 Oct 2016 07:33:16 -0000 Hi, once our AD approves the mobility and multihoming drafts, which should happen shortly, we will have only three milestones left: o Native NAT Traversal o HIP DEX o HIP Architecture I have already pinged the authors of these drafts so that they keep the ball rolling. Cheers, Gonzalo From nobody Fri Oct 21 06:55:22 2016 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 9061C1297BC for ; Fri, 21 Oct 2016 06:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.631 X-Spam-Level: X-Spam-Status: No, score=-4.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWkKaKkMZSQH for ; Fri, 21 Oct 2016 06:55:19 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A24671293FE for ; Fri, 21 Oct 2016 06:55:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id D2F10623C9; Fri, 21 Oct 2016 09:55:18 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id r1mc38vU6p13; Fri, 21 Oct 2016 09:55:04 -0400 (EDT) Received: from lx120e.htt-consult.com (pool-71-246-69-74.bltmmd.east.verizon.net [71.246.69.74]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 9F859623BE; Fri, 21 Oct 2016 09:55:03 -0400 (EDT) To: Tom Henderson , hipsec@ietf.org References: From: Robert Moskowitz Message-ID: <41f2cbaa-118a-4cf8-84a8-a5201e78214a@htt-consult.com> Date: Fri, 21 Oct 2016 09:55:00 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F09DD74A5F5EA6B2E5ED67B0" Archived-At: Subject: Re: [Hipsec] updates to HIP mobility and multihoming drafts X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 21 Oct 2016 13:55:21 -0000 This is a multi-part message in MIME format. --------------F09DD74A5F5EA6B2E5ED67B0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Ver 14 of HIP mobility addresses my concerns. Tom, thank you for making the change to clarify the draft. Bob On 10/10/2016 08:22 PM, Tom Henderson wrote: > The new versions of the HIP mobility and multihoming drafts address > various review comments received during IESG reviews. > > Besides editorial changes, the following changes were made to RFC > 5206-bis version 14: > > * Replace references to 'middleboxes' with more specific |'NATs and > firewalls' and make reference to RFC 5207 > * Describe a simple heuristic for setting the credit value for > Credit-Based Authorization based on sending rate and RTT. > * Add subsection about privacy concerns of locator exposure to the > Security Considerations section. > * Clarify that a host must be able to receive and avoid reprocessing > redundant LOCATOR_SET parameters that may have been sent in parallel > to multiple addresses of the host. > * Clarify that multicast or broadcast addresses must not be announced > in a LOCATOR_SET. > > and the following to the multihoming draft version 12: > > * Added section about locator privacy concerns ! to the Security > Considerations section. > * Added section about relationship to split tunnel issues to the > Security Considerations section. > > I believe that all outstanding comments and issues have been addressed. > > - Tom > > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec --------------F09DD74A5F5EA6B2E5ED67B0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Ver 14 of HIP mobility addresses my concerns.

Tom, thank you for making the change to clarify the draft.

Bob

On 10/10/2016 08:22 PM, Tom Henderson wrote:
The new versions of the HIP mobility and multihoming drafts address various review comments received during IESG reviews.

Besides editorial changes, the following changes were made to RFC 5206-bis version 14:

*  Replace references to 'middleboxes' with more specific |'NATs and firewalls' and make reference to RFC 5207
*  Describe a simple heuristic for setting the credit value for Credit-Based Authorization based on sending rate and RTT.
*  Add subsection about privacy concerns of locator exposure to the Security Considerations section.
*  Clarify that a host must be able to receive and avoid reprocessing redundant LOCATOR_SET parameters that may have been sent in parallel to multiple addresses of the host.
*  Clarify that multicast or broadcast addresses must not be announced in a LOCATOR_SET.  

and the following to the multihoming draft version 12:

* Added section about locator privacy concerns ! to the Security Considerations section.
* Added section about relationship to split tunnel issues to the Security Considerations section.

I believe that all outstanding comments and issues have been addressed.

- Tom



_______________________________________________
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

--------------F09DD74A5F5EA6B2E5ED67B0-- From nobody Sat Oct 22 01:15:42 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 734261293D6; Sat, 22 Oct 2016 01:15:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147712414143.27921.9792375210726188340.idtracker@ietfa.amsl.com> Date: Sat, 22 Oct 2016 01:15:41 -0700 Archived-At: Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-dex-04.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 22 Oct 2016 08:15:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol of the IETF. Title : HIP Diet EXchange (DEX) Authors : Robert Moskowitz Rene Hummen Filename : draft-ietf-hip-dex-04.txt Pages : 49 Date : 2016-10-22 Abstract: This document specifies the Host Identity Protocol Diet EXchange (HIP DEX), a variant of the Host Identity Protocol Version 2 (HIPv2). The HIP DEX protocol design aims at reducing the overhead of the employed cryptographic primitives by omitting public-key signatures and hash functions. In doing so, the main goal is to still deliver similar security properties to HIPv2. The HIP DEX protocol is primarily designed for computation or memory- constrained sensor/actuator devices. Like HIPv2, it is expected to be used together with a suitable security protocol such as the Encapsulated Security Payload (ESP) for the protection of upper layer protocol data. In addition, HIP DEX can also be used as a keying mechanism for security primitives at the MAC layer, e.g., for IEEE 802.15.4 networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-dex/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-hip-dex-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Oct 22 01:22:38 2016 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 7D1E1129498 for ; Sat, 22 Oct 2016 01:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TW95Hu0XfljQ for ; Sat, 22 Oct 2016 01:22:34 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60B051293D6 for ; Sat, 22 Oct 2016 01:22:34 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id 198so17055012itw.0 for ; Sat, 22 Oct 2016 01:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9yLBi34A/m0hkk7VFaiuFYdev+hqzADSVZAy3Wan7F0=; b=X+mKAehXmtadd7auze5ZqLldNjXZeFkrEoHpqGPGl8fh69fHIetDuFwVva/RKdlTVF dPmH0SGuBTUHZrdzyLwzpLvSFnmaty7ralu/KWSgV6cxSyahPJ9UV7dyMYBmqaNO4ai8 K6gp4t6kV+rU7JbhQydPI/zG3VDhsqYDe+07KS1z4GJJ02DWzuxQNillla5U9rvuDWof Rxj4WIVEoqyT5V7rLSprM01XgrauyWT9MbAUHEARLhj9YtnpMjAqGhzqyi88fWnGqJjW rvI3Hip4GP5qmRb60x/tT1wbRXPbAPWAl9sI9gV/PPHezngxPeMCZZ1tYmj2We/qd6R/ +N1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9yLBi34A/m0hkk7VFaiuFYdev+hqzADSVZAy3Wan7F0=; b=UzU90HCo6kyzLsKljI1y16PpOXEN5bhTbCFlmlhmwJtH08kBYj3p19c6CwrQ9gSYUH /AvDFk8X+zD4HSwbXytE+hVWAVTIcvUxoiqjSAOAqmGh1UGYRYPV+O8DyqjAE+6/1j0h Ui5TLorKzAnyufn1xCuKfgLDxGRkhLpWJKuaLb3O8I2DTaGelAafXs1R84tdMEt+N9rV KzY1Xnf/C0vdDes5CMk2z7pjBd4aYePmOngRhOUm1qHVuk6dHxZbbQBuRmKDWTvMgDeU 3kyDAFfkHoEvlb21kp0Ru6JXpuz+xUrJEgzgXMwgJZRg5ivRcEdHFvSmNv7tdzlL5Nuk mvnQ== X-Gm-Message-State: AA6/9RnOALIwbGiWJ41HX92TDYHMDNOOnAmJgw4lEFvi3NM68FXY23/DSmk0xTGZL3bhDm9vSMc2UwXMQhEXcg== X-Received: by 10.202.207.151 with SMTP id f145mr14035626oig.45.1477124553640; Sat, 22 Oct 2016 01:22:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.92.229 with HTTP; Sat, 22 Oct 2016 01:22:32 -0700 (PDT) In-Reply-To: References: <20160321203627.12199.62928.idtracker@ietfa.amsl.com> <56F98E90.10601@ericsson.com> <5756C81D.3080601@ericsson.com> <1ade65d6-187e-20e0-fb9b-c3d5b73f42df@ericsson.com> From: =?UTF-8?B?UmVuw6kgSHVtbWVu?= Date: Sat, 22 Oct 2016 10:22:32 +0200 Message-ID: To: Gonzalo Camarillo Content-Type: multipart/alternative; boundary=001a113b047c4f0f95053f6fdca2 Archived-At: Cc: =?UTF-8?B?UmVuw6kgSHVtbWVu?= , hipsec@ietf.org Subject: Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 22 Oct 2016 08:22:37 -0000 --001a113b047c4f0f95053f6fdca2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I just uploaded draft version 04, where I addressed Miika's comments as discussed in the previous emails. >From my point of view, this document is ready to proceed. BR Ren=C3=A9 2016-10-21 9:13 GMT+02:00 Gonzalo Camarillo : > Hi Rene, > > do you intend to release a new version of the draft with this addition? > What is the current status of the draft otherwise? > > Thanks, > > Gonzalo > > On 26/09/2016 4:46 PM, Miika Komu wrote: > > Hi Ren=C3=A9, > > > > On 09/11/2016 11:06 PM, Ren=C3=A9 Hummen wrote: > >> Hello Miika, > >> > >> going through your email again, I saw a total of four suggestions. > >> > >> Three of them refer to imprecisions in the text of RFC 7401 (which I > >> copy/pasted for HIP DEX). There, I understood that consistency with RF= C > >> 7401 has a higher priority than only fixing your comments for HIP DEX, > >> but keeping the text as is for RFC 7401. This means, I will not modify > >> the text in the HIP DEX draft. Is this also your intention? > > > > yes, 7401 takes precedence over my comments. > > > >> The last remaining issue is related to the UPDATE message and the > >> rekeying procedure (Section 6.10.). Here, I added the following > >> paragraph for clarification purposes: > >> > >> [RFC7402] specifies the rekeying of an existing HIP SA using the > >> UPDATE message. This rekeying procedure can also be used with HIP > >> DEX. However, where rekeying involves a new Diffie-Hellman key > >> exchange, HIP DEX peers MUST establish a new connection in order to > >> create a new Pair-wise Key SA due to the use of static ECDH key-pai= rs > >> with HIP DEX. > >> > >> Does this fix your issue? > > > > Yes. I assume you mean a new HIP association with connection. > > > >> BR > >> Ren=C3=A9 > >> > >> > >> > >> On Tue, Jun 7, 2016 at 3:11 PM, Miika Komu >> > wrote: > >> > >> Hi, > >> > >> On 06/03/2016 02:20 PM, Ren=C3=A9 Hummen wrote: > >> > >> This is part 3 of 3. > >> > >> > >> I am fine with your fixes. Some comments below. > >> > >> On Mon, Mar 28, 2016 at 10:05 PM, Miika Komu > >> > >> >> >> wrote: > >> > >> > [...] > >> > >> > 6.2.1. CMAC Calculation > >> > > >> > [...] > >> > > >> > > >> > 5. Set Checksum and Header Length fields in the HIP > >> header to > >> > original values. Note that the Checksum and Length > fields > >> > contain incorrect values after this step. > >> > >> I guess also the values following HIP_MAC should be restor= ed > >> since > >> they were wiped in the step 2. > >> > >> > >> I also found this description a bit imprecise, but it is taken > >> from > >> RFC7401. Step 2 already hints at the fact that parameters > >> following > >> HIP_MAC may still be of interest: > >> "Remove the HIP_MAC parameter, as well as all other parameters > >> that follow it with greater Type value, saving the > >> contents if > >> they will be needed later." > >> > >> The question is whether we want to fix the description for HIP > >> DEX or to > >> keep things as they are for consistency reasons. In the former > >> case, I > >> would prefer to completely rewrite the verification procedure = to > >> work on > >> the received packet without removing any parameters. However, = we > >> should > >> then probably also post an errata to RFC7401. If there are no > >> stong > >> opinions about that, I would go for the latter option. > >> > >> > >> Latter option works for me too. > >> > >> > The CKDF-Extract function is the following operation: > >> > > >> > CKDF-Extract(I, IKM, info) -> PRK > >> > >> What does the arrow operator signify? I thought that it > >> produces PRK, > >> but PRK is actually defined below. > >> > >> > >> The arrow is part of a basic mathematical function definition. > >> So yes, > >> PRK is the output (domain), but we still need to give it a > >> proper name. > >> I changed the artwork to clearly point out the inputs and > >> outputs. > >> > >> > >> Thanks, it is now better. > >> > >> Please check this section again in the updated version and get > >> back to > >> me if the above changes do not sufficiently help your > >> understanding. > >> > >> > >> It is good now, thanks! > >> > >> > L length of output keying material in octets > >> > (<=3D 255*RHASH_len/8) > >> > | denotes the concatenation > >> > > >> > The output keying material OKM is calculated as follows= : > >> > > >> > N =3D ceil(L/RHASH_len/8) > >> > T =3D T(1) | T(2) | T(3) | ... | T(N) > >> > OKM =3D first L octets of T > >> > > >> > where > >> > > >> > T(0) =3D empty string (zero length) > >> > T(1) =3D CMAC(PRK, T(0) | info | 0x01) > >> > T(2) =3D CMAC(PRK, T(1) | info | 0x02) > >> > T(3) =3D CMAC(PRK, T(2) | info | 0x03) > >> > ... > >> > >> The Expand was a bit more clear, but still didn't understa= nd > >> how to > >> get to the > >> Expanded key material due the arrow notation. > >> > >> > >> Ok, let's clarify this as several comments are related to the > >> arrow > >> notation. For the function definition we use the mathematical > >> arrow > >> notation (same as RFC 5869) and for the actual opertation we > >> use the > >> equals sign (same as RFC 5869). In the end, they denote the sa= me > >> thing: > >> "assign X to Y". > >> > >> > >> Ok, this is what I guessed too. > >> > >> > (where the constant concatenated to the end of each > >> T(n) is a > >> > single octet.) > >> > >> Is there a max value? > >> > >> > >> I am not sure what you mean here. If you refer to the N in T(N= ) > >> then it > >> is defined above as N =3D ceil(L/RHASH_len/8). > >> > >> > >> Yes, I asked about the maximum value for N (which depends on L), b= ut > >> never mind. > >> > >> > 8. The R1 packet may have the A-bit set - in this cas= e, > >> the system > >> > MAY choose to refuse it by dropping the R1 packet and > >> returning > >> > to state UNASSOCIATED. The system SHOULD consider > >> dropping the > >> > R1 packet only if it used a NULL HIT in the I1 packet. > >> > >> I didn't understand the logic in the last sentence. > >> > >> > >> Someone must have had a reason for this recommendation, but th= at > >> someone > >> wasn't me. This is text from RFC7401. Any suggestions how to > >> proceed? > >> > >> > >> Fix similarly as the other RFC7401 issue in the beginning of this > >> email. > >> > >> > 6.7. Processing Incoming I2 Packets > >> > > >> > [...] > >> > > >> > 5. If the system's state machine is in the I2-SENT > >> state, the > >> > system MUST make a comparison between its local and > >> sender's > >> > HITs (similarly as in Section 6.3). If the local HIT i= s > >> smaller > >> > than the sender's HIT, it should drop the I2 packet, > >> use the > >> > peer Diffie-Hellman key, ENCRYPTED_KEY keying material > >> and nonce > >> > #I from the R1 packet received earlier, and get the loc= al > >> > Diffie-Hellman key, ENCRYPTED_KEY keying material, and > >> nonce #J > >> > from the I2 packet sent to the peer earlier. > >> Otherwise, the > >> > system should process the received I2 packet and drop a= ny > >> > previously derived Diffie-Hellman keying material Kij a= nd > >> > ENCRYPTED_KEY keying material it might have generated > upon > >> > sending the I2 packet previously. The peer > >> Diffie-Hellman key, > >> > ENCRYPTED_KEY, and the nonce #J are taken from the just > >> arrived > >> > I2 packet. The local Diffie-Hellman key, ENCRYPTED_KEY > >> keying > >> > material, and the nonce #I are the ones that were sent > >> earlier > >> > in the R1 packet. > >> > >> Please replace "sender" with "peer" (or remote host) in th= is > >> section > >> for more symmetric terminology. > >> > >> get -> obtain > >> > >> > >> I can make these changes if you insist, but I was going for a > >> minimal > >> diff to RFC 7401. > >> > >> > >> Not insisting. > >> > >> > >> > 11. The implementation SHOULD also verify that the > >> Initiator's HIT > >> > in the I2 packet corresponds to the Host Identity sent = in > >> the I2 > >> > packet. (Note: some middleboxes may not be able to > >> make this > >> > verification.) > >> > >> Why SHOULD? Why not MUST? I think we're talking about > >> end-hosts here > >> anyway. > >> > >> > >> It is defined this way in RFC 7401. Do you really want to > >> change the > >> packet processing behavior for HIP DEX only? > >> > >> > >> Fix similarly as the first RFC7401 issue in this email. > >> > >> > 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets > >> > >> > UPDATE, CLOSE, and CLOSE_ACK packets are handled > >> similarly in HIP DEX > >> > as in HIP BEX (see Sections 6.11, 6.12, 6.14, and 6.15 = of > >> [RFC7401]). > >> > The only difference is the that the HIP_SIGNATURE is > >> never present > >> > and, therefore, is not required to be processed by the > >> receiving > >> > party. > >> > >> How does rekeying work with the extract and expand > functions? > >> > >> > >> Rekeying is not defined in this document, same as for RFC > >> 7401. That > >> being said, the rekeying procedure with reuse of the KEYMAT > >> from RFC > >> 7402 directly translates to HIP DEX. For new KEYMAT, the peers > >> need to > >> establish a new connection due to the use of static DH keys. > >> > >> > >> Maybe this should be explicitly stated in the draft. > >> > >> > >> > >> > 7. HIP Policies > >> > >> > There are a number of variables that will influence the > >> HIP exchanges > >> > that each host must support. All HIP DEX implementatio= ns > >> SHOULD > >> > provide for an ACL of Initiator's HI to Responder's HI. > >> This ACL > >> > SHOULD also include preferred transform and local > >> lifetimes. > >> > Wildcards SHOULD also be supported for this ACL. > >> > >> Why ACLs are mandatory? > >> > >> > >> It is not a MUST and considering that HIP DEX is primarly > >> targeted at > >> things, there is the need to do basic device authorizations > >> (based on > >> their identities) without a human in the loop. Of course you a= re > >> also > >> allowed to use more suffisticated authorization mechanisms. > >> > >> > >> Ok. > >> > >> ACL -> ACL consisting of > >> > >> > >> Changed to the following text that is closer to RFC 7401: > >> " All HIP DEX implementations SHOULD provide for an Access > >> Control List > >> (ACL), representing for which hosts they accept HIP diet > >> exchanges, > >> and the preferred transport format and local lifetimes. > >> Wildcarding > >> SHOULD be supported for such ACLs." > >> > >> > 8. Security Considerations > >> > >> > o The HIP DEX HIT generation may present new attack > >> opportunities. > >> > >> They cannot be used in ACLs. Maybe this could be mentioned= . > >> Can this > >> be mitigated by always using full HIs? > >> > >> > >> I changed the bullet-point as follows: > >> "The HIP DEX HIT generation may present new attack > opportunities. > >> Hence, HIP DEX HITs should not be use as the only means > to > >> identify a peer in an ACL. Instead, the use of the > >> peer's HI is > >> recommended." > >> > >> > >> Ok. > >> > >> Note that I added a new Section 8 "Interoperability between HI= P > >> DEX and > >> HIPv2" to satisfy your comment on HIP DEX and HIPv2 > >> compatibility. > >> > >> > >> Thanks! > >> > >> > >> _______________________________________________ > >> Hipsec mailing list > >> Hipsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/hipsec > >> > >> > >> > > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > --001a113b047c4f0f95053f6fdca2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I just uploaded = draft version 04, where I addressed Miika's comments as discussed in th= e previous emails.

From my point of view, this document is ready to pro= ceed.

BR
Ren=C3=A9

2016-10-21 9:13 GMT+02= :00 Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>= :
Hi Rene,

do you intend to release a new version of the draft with this addition?
What is the current status of the draft otherwise?

Thanks,

Gonzalo

On 26/09/2016 4:46 PM, Miika Komu wrote:
> Hi Ren=C3=A9,
>
> On 09/11/2016 11:06 PM, Ren=C3=A9 Hummen wrote:
>> Hello Miika,
>>
>> going through your email again, I saw a total of four suggestions.=
>>
>> Three of them refer to imprecisions in the text of RFC 7401 (which= I
>> copy/pasted for HIP DEX). There, I understood that consistency wit= h RFC
>> 7401 has a higher priority than only fixing your comments for HIP = DEX,
>> but keeping the text as is for RFC 7401. This means, I will not mo= dify
>> the text in the HIP DEX draft. Is this also your intention?
>
> yes, 7401 takes precedence over my comments.
>
>> The last remaining issue is related to the UPDATE message and the<= br> >> rekeying procedure (Section 6.10.). Here, I added the following >> paragraph for clarification purposes:
>>
>>=C2=A0 =C2=A0 [RFC7402] specifies the rekeying of an existing HIP S= A using the
>>=C2=A0 =C2=A0 UPDATE message.=C2=A0 This rekeying procedure can als= o be used with HIP
>>=C2=A0 =C2=A0 DEX.=C2=A0 However, where rekeying involves a new Dif= fie-Hellman key
>>=C2=A0 =C2=A0 exchange, HIP DEX peers MUST establish a new connecti= on in order to
>>=C2=A0 =C2=A0 create a new Pair-wise Key SA due to the use of stati= c ECDH key-pairs
>>=C2=A0 =C2=A0 with HIP DEX.
>>
>> Does this fix your issue?
>
> Yes. I assume you mean a new HIP association with connection.
>
>> BR
>> Ren=C3=A9
>>
>>
>>
>> On Tue, Jun 7, 2016 at 3:11 PM, Miika Komu <miika.komu@ericsson.com
>> <mailto:miika.komu@e= ricsson.com>> wrote:
>>
>>=C2=A0 =C2=A0 =C2=A0Hi,
>>
>>=C2=A0 =C2=A0 =C2=A0On 06/03/2016 02:20 PM, Ren=C3=A9 Hummen wrote:=
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This is part 3 of 3.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0I am fine with your fixes. Some comments below.=
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Mon, Mar 28, 2016 at 10:05 PM,= Miika Komu
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<miika.komu@ericsson.com <mailto:miika.komu@ericsson.com>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:miika.komu@ericsson.com
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:miika.komu@ericsson.com>>> wrote: >>
>>=C2=A0 =C2=A0 =C2=A0> [...]
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > 6.2.1.=C2=A0 = CMAC Calculation
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > [...]
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > 5.=C2=A0 Set = Checksum and Header Length fields in the HIP
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0header to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > original valu= es.=C2=A0 Note that the Checksum and Length fields
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > contain incor= rect values after this step.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I guess also the va= lues following HIP_MAC should be restored
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0since
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0they were wiped in = the step 2.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I also found this description a b= it imprecise, but it is taken
>> from
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RFC7401. Step 2 already hints at = the fact that parameters
>> following
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0HIP_MAC may still be of interest:=
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Remove the HIP_MAC paramete= r, as well as all other parameters
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that = follow it with greater Type value, saving the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0contents if
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0they = will be needed later."
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The question is whether we want t= o fix the description for HIP
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DEX or to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0keep things as they are for consi= stency reasons. In the former
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case, I
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0would prefer to completely rewrit= e the verification procedure to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0work on
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the received packet without remov= ing any parameters. However, we
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0should
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0then probably also post an errata= to RFC7401. If there are no
>> stong
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opinions about that, I would go f= or the latter option.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0Latter option works for me too.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > The CKDF-Extr= act function is the following operation:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > CKDF-Extract(= I, IKM, info) -> PRK
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0What does the arrow= operator signify? I thought that it
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0produces PRK,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0but PRK is actually= defined below.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The arrow is part of a basic math= ematical function definition.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0So yes,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PRK is the output (domain), but w= e still need to give it a
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proper name.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I changed the artwork to clearly = point out the inputs and
>> outputs.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0Thanks, it is now better.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Please check this section again i= n the updated version and get
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0back to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0me if the above changes do not su= fficiently help your
>> understanding.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0It is good now, thanks!
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > L=C2=A0 =C2= =A0 =C2=A0 =C2=A0 length of output keying material in octets
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 (<=3D 255*RHASH_len/8)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 denotes the concatenation
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > The output ke= ying material OKM is calculated as follows:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > N=C2=A0 =C2= =A0 =C2=A0 =C2=A0=3D=C2=A0 ceil(L/RHASH_len/8)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > T=C2=A0 =C2= =A0 =C2=A0 =C2=A0=3D=C2=A0 T(1) | T(2) | T(3) | ... | T(N)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > OKM=C2=A0 =C2= =A0 =C2=A0=3D=C2=A0 first L octets of T
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > where
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > T(0) =3D empt= y string (zero length)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > T(1) =3D CMAC= (PRK, T(0) | info | 0x01)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > T(2) =3D CMAC= (PRK, T(1) | info | 0x02)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > T(3) =3D CMAC= (PRK, T(2) | info | 0x03)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > ...
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The Expand was a bi= t more clear, but still didn't understand
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0how to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0get to the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expanded key materi= al due the arrow notation.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ok, let's clarify this as sev= eral comments are related to the
>> arrow
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0notation. For the function defini= tion we use the mathematical
>> arrow
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0notation (same as RFC 5869) and f= or the actual opertation we
>> use the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0equals sign (same as RFC 5869). I= n the end, they denote the same
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0thing:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"assign X to Y".
>>
>>
>>=C2=A0 =C2=A0 =C2=A0Ok, this is what I guessed too.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > (where the co= nstant concatenated to the end of each
>> T(n) is a
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > single octet.= )
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Is there a max valu= e?
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I am not sure what you mean here.= If you refer to the N in T(N)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0then it
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is defined above as N =3D ceil(L/= RHASH_len/8).
>>
>>
>>=C2=A0 =C2=A0 =C2=A0Yes, I asked about the maximum value for N (whi= ch depends on L), but
>>=C2=A0 =C2=A0 =C2=A0never mind.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > 8.=C2=A0 =C2= =A0The R1 packet may have the A-bit set - in this case,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the system
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > MAY choose to= refuse it by dropping the R1 packet and
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0returning
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > to state UNAS= SOCIATED.=C2=A0 The system SHOULD consider
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dropping the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > R1 packet onl= y if it used a NULL HIT in the I1 packet.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I didn't unders= tand the logic in the last sentence.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Someone must have had a reason fo= r this recommendation, but that
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0someone
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wasn't me. This is text from = RFC7401. Any suggestions how to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proceed?
>>
>>
>>=C2=A0 =C2=A0 =C2=A0Fix similarly as the other RFC7401 issue in the= beginning of this
>> email.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > 6.7.=C2=A0 Pr= ocessing Incoming I2 Packets
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > [...]
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > 5.=C2=A0 =C2= =A0If the system's state machine is in the I2-SENT
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0state, the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > system MUST m= ake a comparison between its local and
>> sender's
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > HITs (similar= ly as in Section 6.3).=C2=A0 If the local HIT is
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0smaller
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > than the send= er's HIT, it should drop the I2 packet,
>> use the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > peer Diffie-H= ellman key, ENCRYPTED_KEY keying material
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and nonce
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > #I from the R= 1 packet received earlier, and get the local
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Diffie-Hellma= n key, ENCRYPTED_KEY keying material, and
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0nonce #J
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > from the I2 p= acket sent to the peer earlier.
>> Otherwise, the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > system should= process the received I2 packet and drop any
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > previously de= rived Diffie-Hellman keying material Kij and
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > ENCRYPTED_KEY= keying material it might have generated upon
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > sending the I= 2 packet previously.=C2=A0 The peer
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Diffie-Hellman key,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > ENCRYPTED_KEY= , and the nonce #J are taken from the just
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0arrived
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > I2 packet.=C2= =A0 The local Diffie-Hellman key, ENCRYPTED_KEY
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0keying
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > material, and= the nonce #I are the ones that were sent
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0earlier
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > in the R1 pac= ket.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Please replace &quo= t;sender" with "peer" (or remote host) in this
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0section
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for more symmetric = terminology.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0get -> obtain >>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I can make these changes if you i= nsist, but I was going for a
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0minimal
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0diff to RFC 7401.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0Not insisting.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > 11.=C2=A0 The= implementation SHOULD also verify that the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Initiator's HIT
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > in the I2 pac= ket corresponds to the Host Identity sent in
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the I2
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > packet.=C2=A0= (Note: some middleboxes may not be able to
>> make this
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > verification.= )
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Why SHOULD? Why not= MUST? I think we're talking about
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0end-hosts here
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0anyway.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It is defined this way in RFC 740= 1. Do you really want to
>> change the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0packet processing behavior for HI= P DEX only?
>>
>>
>>=C2=A0 =C2=A0 =C2=A0Fix similarly as the first RFC7401 issue in thi= s email.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > 6.10.=C2=A0 P= rocessing UPDATE, CLOSE, and CLOSE_ACK Packets
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > UPDATE, CLOSE= , and CLOSE_ACK packets are handled
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0similarly in HIP DEX
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > as in HIP BEX= (see Sections 6.11, 6.12, 6.14, and 6.15 of
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC7401]).
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > The only diff= erence is the that the HIP_SIGNATURE is
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0never present
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > and, therefor= e, is not required to be processed by the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0receiving
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > party.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0How does rekeying w= ork with the extract and expand functions?
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Rekeying is not defined in this d= ocument, same as for RFC
>> 7401. That
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0being said, the rekeying procedur= e with reuse of the KEYMAT
>> from RFC
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A07402 directly translates to HIP D= EX. For new KEYMAT, the peers
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0need to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0establish a new connection due to= the use of static DH keys.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0Maybe this should be explicitly stated in the d= raft.
>>
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > 7.=C2=A0 HIP = Policies
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > There are a n= umber of variables that will influence the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0HIP exchanges
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > that each hos= t must support.=C2=A0 All HIP DEX implementations
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SHOULD
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > provide for a= n ACL of Initiator's HI to Responder's HI.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This ACL
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > SHOULD also i= nclude preferred transform and local
>> lifetimes.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Wildcards SHO= ULD also be supported for this ACL.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Why ACLs are mandat= ory?
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It is not a MUST and considering = that HIP DEX is primarly
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0targeted at
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0things, there is the need to do b= asic device authorizations
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(based on
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0their identities) without a human= in the loop. Of course you are
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0also
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0allowed to use more suffisticated= authorization mechanisms.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0Ok.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ACL -> ACL consi= sting of
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Changed to the following text tha= t is closer to RFC 7401:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"=C2=A0 =C2=A0All HIP DEX im= plementations SHOULD provide for an Access
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Control List
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(ACL), representing= for which hosts they accept HIP diet
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0exchanges,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and the preferred t= ransport format and local lifetimes.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Wildcarding
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SHOULD be supported= for such ACLs."
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > 8.=C2=A0 Secu= rity Considerations
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > o=C2=A0 The H= IP DEX HIT generation may present new attack
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opportunities.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0They cannot be used= in ACLs. Maybe this could be mentioned.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Can this
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be mitigated by alw= ays using full HIs?
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I changed the bullet-point as fol= lows:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"The HIP DEX HIT generation = may present new attack opportunities.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hence, HIP = DEX HITs should not be use as the only means to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 identify a = peer in an ACL.=C2=A0 Instead, the use of the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0peer's HI is
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 recommended= ."
>>
>>
>>=C2=A0 =C2=A0 =C2=A0Ok.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Note that I added a new Section 8= "Interoperability between HIP
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DEX and
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0HIPv2" to satisfy your comme= nt on HIP DEX and HIPv2
>> compatibility.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0Thanks!
>>
>>
>>=C2=A0 =C2=A0 =C2=A0__________________________________________= _____
>>=C2=A0 =C2=A0 =C2=A0Hipsec mailing list
>>=C2=A0 =C2=A0 =C2=A0Hipsec@ietf.= org <mailto:Hipsec@ietf.org&g= t;
>>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman= /listinfo/hipsec
>>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mai= lman/listinfo/hipsec>
>>
>>
>

_______________________________________________
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/h= ipsec

--001a113b047c4f0f95053f6fdca2-- From nobody Sat Oct 22 18:23:02 2016 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 C90A5129579 for ; Sat, 22 Oct 2016 18:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.631 X-Spam-Level: X-Spam-Status: No, score=-4.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0YPMpWEoEdi for ; Sat, 22 Oct 2016 18:22:55 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5665712945A for ; Sat, 22 Oct 2016 18:22:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 9ED7862306; Sat, 22 Oct 2016 21:22:53 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0xZsV+d7Wunh; Sat, 22 Oct 2016 21:22:39 -0400 (EDT) Received: from lx120e.htt-consult.com (pool-71-246-64-145.bltmmd.east.verizon.net [71.246.64.145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id CC94062310; Sat, 22 Oct 2016 21:22:37 -0400 (EDT) To: =?UTF-8?Q?Ren=c3=a9_Hummen?= , Gonzalo Camarillo References: <20160321203627.12199.62928.idtracker@ietfa.amsl.com> <56F98E90.10601@ericsson.com> <5756C81D.3080601@ericsson.com> <1ade65d6-187e-20e0-fb9b-c3d5b73f42df@ericsson.com> From: Robert Moskowitz Message-ID: Date: Sat, 22 Oct 2016 21:22:31 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6E6D59C01A5CF6E91BB4F845" Archived-At: Cc: hipsec@ietf.org, =?UTF-8?Q?Ren=c3=a9_Hummen?= Subject: Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 23 Oct 2016 01:22:59 -0000 This is a multi-part message in MIME format. --------------6E6D59C01A5CF6E91BB4F845 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I am in agreement with Rene that this version meets the comments here that do not add new features. As much as I would like to add new things, like a PAKE process, I would do that as separate document(s). In fact that is what I am doing with drafts like my fast-mobility. So please start last call on this draft. Bob On 10/22/2016 04:22 AM, René Hummen wrote: > Hi, > > I just uploaded draft version 04, where I addressed Miika's comments > as discussed in the previous emails. > > From my point of view, this document is ready to proceed. > > BR > René > > 2016-10-21 9:13 GMT+02:00 Gonzalo Camarillo > >: > > Hi Rene, > > do you intend to release a new version of the draft with this > addition? > What is the current status of the draft otherwise? > > Thanks, > > Gonzalo > > On 26/09/2016 4:46 PM, Miika Komu wrote: > > Hi René, > > > > On 09/11/2016 11:06 PM, René Hummen wrote: > >> Hello Miika, > >> > >> going through your email again, I saw a total of four suggestions. > >> > >> Three of them refer to imprecisions in the text of RFC 7401 > (which I > >> copy/pasted for HIP DEX). There, I understood that consistency > with RFC > >> 7401 has a higher priority than only fixing your comments for > HIP DEX, > >> but keeping the text as is for RFC 7401. This means, I will not > modify > >> the text in the HIP DEX draft. Is this also your intention? > > > > yes, 7401 takes precedence over my comments. > > > >> The last remaining issue is related to the UPDATE message and the > >> rekeying procedure (Section 6.10.). Here, I added the following > >> paragraph for clarification purposes: > >> > >> [RFC7402] specifies the rekeying of an existing HIP SA using the > >> UPDATE message. This rekeying procedure can also be used > with HIP > >> DEX. However, where rekeying involves a new Diffie-Hellman key > >> exchange, HIP DEX peers MUST establish a new connection in > order to > >> create a new Pair-wise Key SA due to the use of static ECDH > key-pairs > >> with HIP DEX. > >> > >> Does this fix your issue? > > > > Yes. I assume you mean a new HIP association with connection. > > > >> BR > >> René > >> > >> > >> > >> On Tue, Jun 7, 2016 at 3:11 PM, Miika Komu > > >> >> wrote: > >> > >> Hi, > >> > >> On 06/03/2016 02:20 PM, René Hummen wrote: > >> > >> This is part 3 of 3. > >> > >> > >> I am fine with your fixes. Some comments below. > >> > >> On Mon, Mar 28, 2016 at 10:05 PM, Miika Komu > >> > > >> > >> >>> wrote: > >> > >> > [...] > >> > >> > 6.2.1. CMAC Calculation > >> > > >> > [...] > >> > > >> > > >> > 5. Set Checksum and Header Length fields in the HIP > >> header to > >> > original values. Note that the Checksum and > Length fields > >> > contain incorrect values after this step. > >> > >> I guess also the values following HIP_MAC should be > restored > >> since > >> they were wiped in the step 2. > >> > >> > >> I also found this description a bit imprecise, but it > is taken > >> from > >> RFC7401. Step 2 already hints at the fact that parameters > >> following > >> HIP_MAC may still be of interest: > >> "Remove the HIP_MAC parameter, as well as all other > parameters > >> that follow it with greater Type value, saving the > >> contents if > >> they will be needed later." > >> > >> The question is whether we want to fix the description > for HIP > >> DEX or to > >> keep things as they are for consistency reasons. In the > former > >> case, I > >> would prefer to completely rewrite the verification > procedure to > >> work on > >> the received packet without removing any parameters. > However, we > >> should > >> then probably also post an errata to RFC7401. If there > are no > >> stong > >> opinions about that, I would go for the latter option. > >> > >> > >> Latter option works for me too. > >> > >> > The CKDF-Extract function is the following > operation: > >> > > >> > CKDF-Extract(I, IKM, info) -> PRK > >> > >> What does the arrow operator signify? I thought that it > >> produces PRK, > >> but PRK is actually defined below. > >> > >> > >> The arrow is part of a basic mathematical function > definition. > >> So yes, > >> PRK is the output (domain), but we still need to give it a > >> proper name. > >> I changed the artwork to clearly point out the inputs and > >> outputs. > >> > >> > >> Thanks, it is now better. > >> > >> Please check this section again in the updated version > and get > >> back to > >> me if the above changes do not sufficiently help your > >> understanding. > >> > >> > >> It is good now, thanks! > >> > >> > L length of output keying material in octets > >> > (<= 255*RHASH_len/8) > >> > | denotes the concatenation > >> > > >> > The output keying material OKM is calculated as > follows: > >> > > >> > N = ceil(L/RHASH_len/8) > >> > T = T(1) | T(2) | T(3) | ... | T(N) > >> > OKM = first L octets of T > >> > > >> > where > >> > > >> > T(0) = empty string (zero length) > >> > T(1) = CMAC(PRK, T(0) | info | 0x01) > >> > T(2) = CMAC(PRK, T(1) | info | 0x02) > >> > T(3) = CMAC(PRK, T(2) | info | 0x03) > >> > ... > >> > >> The Expand was a bit more clear, but still didn't > understand > >> how to > >> get to the > >> Expanded key material due the arrow notation. > >> > >> > >> Ok, let's clarify this as several comments are related > to the > >> arrow > >> notation. For the function definition we use the > mathematical > >> arrow > >> notation (same as RFC 5869) and for the actual > opertation we > >> use the > >> equals sign (same as RFC 5869). In the end, they denote > the same > >> thing: > >> "assign X to Y". > >> > >> > >> Ok, this is what I guessed too. > >> > >> > (where the constant concatenated to the end of each > >> T(n) is a > >> > single octet.) > >> > >> Is there a max value? > >> > >> > >> I am not sure what you mean here. If you refer to the N > in T(N) > >> then it > >> is defined above as N = ceil(L/RHASH_len/8). > >> > >> > >> Yes, I asked about the maximum value for N (which depends > on L), but > >> never mind. > >> > >> > 8. The R1 packet may have the A-bit set - in > this case, > >> the system > >> > MAY choose to refuse it by dropping the R1 > packet and > >> returning > >> > to state UNASSOCIATED. The system SHOULD consider > >> dropping the > >> > R1 packet only if it used a NULL HIT in the I1 > packet. > >> > >> I didn't understand the logic in the last sentence. > >> > >> > >> Someone must have had a reason for this recommendation, > but that > >> someone > >> wasn't me. This is text from RFC7401. Any suggestions > how to > >> proceed? > >> > >> > >> Fix similarly as the other RFC7401 issue in the beginning > of this > >> email. > >> > >> > 6.7. Processing Incoming I2 Packets > >> > > >> > [...] > >> > > >> > 5. If the system's state machine is in the I2-SENT > >> state, the > >> > system MUST make a comparison between its local and > >> sender's > >> > HITs (similarly as in Section 6.3). If the > local HIT is > >> smaller > >> > than the sender's HIT, it should drop the I2 packet, > >> use the > >> > peer Diffie-Hellman key, ENCRYPTED_KEY keying > material > >> and nonce > >> > #I from the R1 packet received earlier, and get > the local > >> > Diffie-Hellman key, ENCRYPTED_KEY keying > material, and > >> nonce #J > >> > from the I2 packet sent to the peer earlier. > >> Otherwise, the > >> > system should process the received I2 packet and > drop any > >> > previously derived Diffie-Hellman keying > material Kij and > >> > ENCRYPTED_KEY keying material it might have > generated upon > >> > sending the I2 packet previously. The peer > >> Diffie-Hellman key, > >> > ENCRYPTED_KEY, and the nonce #J are taken from > the just > >> arrived > >> > I2 packet. The local Diffie-Hellman key, > ENCRYPTED_KEY > >> keying > >> > material, and the nonce #I are the ones that > were sent > >> earlier > >> > in the R1 packet. > >> > >> Please replace "sender" with "peer" (or remote > host) in this > >> section > >> for more symmetric terminology. > >> > >> get -> obtain > >> > >> > >> I can make these changes if you insist, but I was going > for a > >> minimal > >> diff to RFC 7401. > >> > >> > >> Not insisting. > >> > >> > >> > 11. The implementation SHOULD also verify that the > >> Initiator's HIT > >> > in the I2 packet corresponds to the Host > Identity sent in > >> the I2 > >> > packet. (Note: some middleboxes may not be able to > >> make this > >> > verification.) > >> > >> Why SHOULD? Why not MUST? I think we're talking about > >> end-hosts here > >> anyway. > >> > >> > >> It is defined this way in RFC 7401. Do you really want to > >> change the > >> packet processing behavior for HIP DEX only? > >> > >> > >> Fix similarly as the first RFC7401 issue in this email. > >> > >> > 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK > Packets > >> > >> > UPDATE, CLOSE, and CLOSE_ACK packets are handled > >> similarly in HIP DEX > >> > as in HIP BEX (see Sections 6.11, 6.12, 6.14, > and 6.15 of > >> [RFC7401]). > >> > The only difference is the that the HIP_SIGNATURE is > >> never present > >> > and, therefore, is not required to be processed > by the > >> receiving > >> > party. > >> > >> How does rekeying work with the extract and expand > functions? > >> > >> > >> Rekeying is not defined in this document, same as for RFC > >> 7401. That > >> being said, the rekeying procedure with reuse of the KEYMAT > >> from RFC > >> 7402 directly translates to HIP DEX. For new KEYMAT, > the peers > >> need to > >> establish a new connection due to the use of static DH > keys. > >> > >> > >> Maybe this should be explicitly stated in the draft. > >> > >> > >> > >> > 7. HIP Policies > >> > >> > There are a number of variables that will > influence the > >> HIP exchanges > >> > that each host must support. All HIP DEX > implementations > >> SHOULD > >> > provide for an ACL of Initiator's HI to > Responder's HI. > >> This ACL > >> > SHOULD also include preferred transform and local > >> lifetimes. > >> > Wildcards SHOULD also be supported for this ACL. > >> > >> Why ACLs are mandatory? > >> > >> > >> It is not a MUST and considering that HIP DEX is primarly > >> targeted at > >> things, there is the need to do basic device authorizations > >> (based on > >> their identities) without a human in the loop. Of > course you are > >> also > >> allowed to use more suffisticated authorization mechanisms. > >> > >> > >> Ok. > >> > >> ACL -> ACL consisting of > >> > >> > >> Changed to the following text that is closer to RFC 7401: > >> " All HIP DEX implementations SHOULD provide for an > Access > >> Control List > >> (ACL), representing for which hosts they accept HIP > diet > >> exchanges, > >> and the preferred transport format and local lifetimes. > >> Wildcarding > >> SHOULD be supported for such ACLs." > >> > >> > 8. Security Considerations > >> > >> > o The HIP DEX HIT generation may present new attack > >> opportunities. > >> > >> They cannot be used in ACLs. Maybe this could be > mentioned. > >> Can this > >> be mitigated by always using full HIs? > >> > >> > >> I changed the bullet-point as follows: > >> "The HIP DEX HIT generation may present new attack > opportunities. > >> Hence, HIP DEX HITs should not be use as the > only means to > >> identify a peer in an ACL. Instead, the use of the > >> peer's HI is > >> recommended." > >> > >> > >> Ok. > >> > >> Note that I added a new Section 8 "Interoperability > between HIP > >> DEX and > >> HIPv2" to satisfy your comment on HIP DEX and HIPv2 > >> compatibility. > >> > >> > >> Thanks! > >> > >> > >> _______________________________________________ > >> Hipsec mailing list > >> Hipsec@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/hipsec > > >> > > >> > >> > > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > > > > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec --------------6E6D59C01A5CF6E91BB4F845 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I am in agreement with Rene that this version meets the comments here that do not add new features.  As much as I would like to add new things, like a PAKE process, I would do that as separate document(s).  In fact that is what I am doing with drafts like my fast-mobility.

So please start last call on this draft.

Bob

On 10/22/2016 04:22 AM, René Hummen wrote:
Hi,

I just uploaded draft version 04, where I addressed Miika's comments as discussed in the previous emails.

From my point of view, this document is ready to proceed.

BR
René

2016-10-21 9:13 GMT+02:00 Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>:
Hi Rene,

do you intend to release a new version of the draft with this addition?
What is the current status of the draft otherwise?

Thanks,

Gonzalo

On 26/09/2016 4:46 PM, Miika Komu wrote:
> Hi René,
>
> On 09/11/2016 11:06 PM, René Hummen wrote:
>> Hello Miika,
>>
>> going through your email again, I saw a total of four suggestions.
>>
>> Three of them refer to imprecisions in the text of RFC 7401 (which I
>> copy/pasted for HIP DEX). There, I understood that consistency with RFC
>> 7401 has a higher priority than only fixing your comments for HIP DEX,
>> but keeping the text as is for RFC 7401. This means, I will not modify
>> the text in the HIP DEX draft. Is this also your intention?
>
> yes, 7401 takes precedence over my comments.
>
>> The last remaining issue is related to the UPDATE message and the
>> rekeying procedure (Section 6.10.). Here, I added the following
>> paragraph for clarification purposes:
>>
>>    [RFC7402] specifies the rekeying of an existing HIP SA using the
>>    UPDATE message.  This rekeying procedure can also be used with HIP
>>    DEX.  However, where rekeying involves a new Diffie-Hellman key
>>    exchange, HIP DEX peers MUST establish a new connection in order to
>>    create a new Pair-wise Key SA due to the use of static ECDH key-pairs
>>    with HIP DEX.
>>
>> Does this fix your issue?
>
> Yes. I assume you mean a new HIP association with connection.
>
>> BR
>> René
>>
>>
>>
>> On Tue, Jun 7, 2016 at 3:11 PM, Miika Komu <miika.komu@ericsson.com
>> <mailto:miika.komu@ericsson.com>> wrote:
>>
>>     Hi,
>>
>>     On 06/03/2016 02:20 PM, René Hummen wrote:
>>
>>         This is part 3 of 3.
>>
>>
>>     I am fine with your fixes. Some comments below.
>>
>>         On Mon, Mar 28, 2016 at 10:05 PM, Miika Komu
>>         <miika.komu@ericsson.com <mailto:miika.komu@ericsson.com>
>>         <mailto:miika.komu@ericsson.com
>>         <mailto:miika.komu@ericsson.com>>> wrote:
>>
>>     > [...]
>>
>>              > 6.2.1.  CMAC Calculation
>>              >
>>              > [...]
>>              >
>>              >
>>              > 5.  Set Checksum and Header Length fields in the HIP
>>         header to
>>              > original values.  Note that the Checksum and Length fields
>>              > contain incorrect values after this step.
>>
>>             I guess also the values following HIP_MAC should be restored
>>         since
>>             they were wiped in the step 2.
>>
>>
>>         I also found this description a bit imprecise, but it is taken
>> from
>>         RFC7401. Step 2 already hints at the fact that parameters
>> following
>>         HIP_MAC may still be of interest:
>>         "Remove the HIP_MAC parameter, as well as all other parameters
>>                 that follow it with greater Type value, saving the
>>         contents if
>>                 they will be needed later."
>>
>>         The question is whether we want to fix the description for HIP
>>         DEX or to
>>         keep things as they are for consistency reasons. In the former
>>         case, I
>>         would prefer to completely rewrite the verification procedure to
>>         work on
>>         the received packet without removing any parameters. However, we
>>         should
>>         then probably also post an errata to RFC7401. If there are no
>> stong
>>         opinions about that, I would go for the latter option.
>>
>>
>>     Latter option works for me too.
>>
>>              > The CKDF-Extract function is the following operation:
>>              >
>>              > CKDF-Extract(I, IKM, info) -> PRK
>>
>>             What does the arrow operator signify? I thought that it
>>         produces PRK,
>>             but PRK is actually defined below.
>>
>>
>>         The arrow is part of a basic mathematical function definition.
>>         So yes,
>>         PRK is the output (domain), but we still need to give it a
>>         proper name.
>>         I changed the artwork to clearly point out the inputs and
>> outputs.
>>
>>
>>     Thanks, it is now better.
>>
>>         Please check this section again in the updated version and get
>>         back to
>>         me if the above changes do not sufficiently help your
>> understanding.
>>
>>
>>     It is good now, thanks!
>>
>>              > L        length of output keying material in octets
>>              >          (<= 255*RHASH_len/8)
>>              > |        denotes the concatenation
>>              >
>>              > The output keying material OKM is calculated as follows:
>>              >
>>              > N       =  ceil(L/RHASH_len/8)
>>              > T       =  T(1) | T(2) | T(3) | ... | T(N)
>>              > OKM     =  first L octets of T
>>              >
>>              > where
>>              >
>>              > T(0) = empty string (zero length)
>>              > T(1) = CMAC(PRK, T(0) | info | 0x01)
>>              > T(2) = CMAC(PRK, T(1) | info | 0x02)
>>              > T(3) = CMAC(PRK, T(2) | info | 0x03)
>>              > ...
>>
>>             The Expand was a bit more clear, but still didn't understand
>>         how to
>>             get to the
>>             Expanded key material due the arrow notation.
>>
>>
>>         Ok, let's clarify this as several comments are related to the
>> arrow
>>         notation. For the function definition we use the mathematical
>> arrow
>>         notation (same as RFC 5869) and for the actual opertation we
>> use the
>>         equals sign (same as RFC 5869). In the end, they denote the same
>>         thing:
>>         "assign X to Y".
>>
>>
>>     Ok, this is what I guessed too.
>>
>>              > (where the constant concatenated to the end of each
>> T(n) is a
>>              > single octet.)
>>
>>             Is there a max value?
>>
>>
>>         I am not sure what you mean here. If you refer to the N in T(N)
>>         then it
>>         is defined above as N = ceil(L/RHASH_len/8).
>>
>>
>>     Yes, I asked about the maximum value for N (which depends on L), but
>>     never mind.
>>
>>              > 8.   The R1 packet may have the A-bit set - in this case,
>>         the system
>>              > MAY choose to refuse it by dropping the R1 packet and
>>         returning
>>              > to state UNASSOCIATED.  The system SHOULD consider
>>         dropping the
>>              > R1 packet only if it used a NULL HIT in the I1 packet.
>>
>>             I didn't understand the logic in the last sentence.
>>
>>
>>         Someone must have had a reason for this recommendation, but that
>>         someone
>>         wasn't me. This is text from RFC7401. Any suggestions how to
>>         proceed?
>>
>>
>>     Fix similarly as the other RFC7401 issue in the beginning of this
>> email.
>>
>>              > 6.7.  Processing Incoming I2 Packets
>>              >
>>              > [...]
>>              >
>>              > 5.   If the system's state machine is in the I2-SENT
>>         state, the
>>              > system MUST make a comparison between its local and
>> sender's
>>              > HITs (similarly as in Section 6.3).  If the local HIT is
>>         smaller
>>              > than the sender's HIT, it should drop the I2 packet,
>> use the
>>              > peer Diffie-Hellman key, ENCRYPTED_KEY keying material
>>         and nonce
>>              > #I from the R1 packet received earlier, and get the local
>>              > Diffie-Hellman key, ENCRYPTED_KEY keying material, and
>>         nonce #J
>>              > from the I2 packet sent to the peer earlier.
>> Otherwise, the
>>              > system should process the received I2 packet and drop any
>>              > previously derived Diffie-Hellman keying material Kij and
>>              > ENCRYPTED_KEY keying material it might have generated upon
>>              > sending the I2 packet previously.  The peer
>>         Diffie-Hellman key,
>>              > ENCRYPTED_KEY, and the nonce #J are taken from the just
>>         arrived
>>              > I2 packet.  The local Diffie-Hellman key, ENCRYPTED_KEY
>>         keying
>>              > material, and the nonce #I are the ones that were sent
>>         earlier
>>              > in the R1 packet.
>>
>>             Please replace "sender" with "peer" (or remote host) in this
>>         section
>>             for more symmetric terminology.
>>
>>             get -> obtain
>>
>>
>>         I can make these changes if you insist, but I was going for a
>>         minimal
>>         diff to RFC 7401.
>>
>>
>>     Not insisting.
>>
>>
>>              > 11.  The implementation SHOULD also verify that the
>>         Initiator's HIT
>>              > in the I2 packet corresponds to the Host Identity sent in
>>         the I2
>>              > packet.  (Note: some middleboxes may not be able to
>> make this
>>              > verification.)
>>
>>             Why SHOULD? Why not MUST? I think we're talking about
>>         end-hosts here
>>             anyway.
>>
>>
>>         It is defined this way in RFC 7401. Do you really want to
>> change the
>>         packet processing behavior for HIP DEX only?
>>
>>
>>     Fix similarly as the first RFC7401 issue in this email.
>>
>>              > 6.10.  Processing UPDATE, CLOSE, and CLOSE_ACK Packets
>>
>>              > UPDATE, CLOSE, and CLOSE_ACK packets are handled
>>         similarly in HIP DEX
>>              > as in HIP BEX (see Sections 6.11, 6.12, 6.14, and 6.15 of
>>         [RFC7401]).
>>              > The only difference is the that the HIP_SIGNATURE is
>>         never present
>>              > and, therefore, is not required to be processed by the
>>         receiving
>>              > party.
>>
>>             How does rekeying work with the extract and expand functions?
>>
>>
>>         Rekeying is not defined in this document, same as for RFC
>> 7401. That
>>         being said, the rekeying procedure with reuse of the KEYMAT
>> from RFC
>>         7402 directly translates to HIP DEX. For new KEYMAT, the peers
>>         need to
>>         establish a new connection due to the use of static DH keys.
>>
>>
>>     Maybe this should be explicitly stated in the draft.
>>
>>
>>
>>              > 7.  HIP Policies
>>
>>              > There are a number of variables that will influence the
>>         HIP exchanges
>>              > that each host must support.  All HIP DEX implementations
>>         SHOULD
>>              > provide for an ACL of Initiator's HI to Responder's HI.
>>         This ACL
>>              > SHOULD also include preferred transform and local
>> lifetimes.
>>              > Wildcards SHOULD also be supported for this ACL.
>>
>>             Why ACLs are mandatory?
>>
>>
>>         It is not a MUST and considering that HIP DEX is primarly
>>         targeted at
>>         things, there is the need to do basic device authorizations
>>         (based on
>>         their identities) without a human in the loop. Of course you are
>>         also
>>         allowed to use more suffisticated authorization mechanisms.
>>
>>
>>     Ok.
>>
>>             ACL -> ACL consisting of
>>
>>
>>         Changed to the following text that is closer to RFC 7401:
>>         "   All HIP DEX implementations SHOULD provide for an Access
>>         Control List
>>             (ACL), representing for which hosts they accept HIP diet
>>         exchanges,
>>             and the preferred transport format and local lifetimes.
>>         Wildcarding
>>             SHOULD be supported for such ACLs."
>>
>>              > 8.  Security Considerations
>>
>>              > o  The HIP DEX HIT generation may present new attack
>>         opportunities.
>>
>>             They cannot be used in ACLs. Maybe this could be mentioned.
>>         Can this
>>             be mitigated by always using full HIs?
>>
>>
>>         I changed the bullet-point as follows:
>>         "The HIP DEX HIT generation may present new attack opportunities.
>>                Hence, HIP DEX HITs should not be use as the only means to
>>                identify a peer in an ACL.  Instead, the use of the
>>         peer's HI is
>>                recommended."
>>
>>
>>     Ok.
>>
>>         Note that I added a new Section 8 "Interoperability between HIP
>>         DEX and
>>         HIPv2" to satisfy your comment on HIP DEX and HIPv2
>> compatibility.
>>
>>
>>     Thanks!
>>
>>
>>     _______________________________________________
>>     Hipsec mailing list
>>     Hipsec@ietf.org <mailto:Hipsec@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/hipsec
>>     <https://www.ietf.org/mailman/listinfo/hipsec>
>>
>>
>

_______________________________________________
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec



_______________________________________________
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

--------------6E6D59C01A5CF6E91BB4F845-- From nobody Wed Oct 26 23:39:13 2016 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 830451296BB for ; Wed, 26 Oct 2016 23:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.221 X-Spam-Level: X-Spam-Status: No, score=-104.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyOkPZ7kzQBl for ; Wed, 26 Oct 2016 23:39:08 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6C911296A6 for ; Wed, 26 Oct 2016 23:39:07 -0700 (PDT) X-AuditID: c1b4fb25-953ff70000001e3e-8c-5811a109ae18 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by (Symantec Mail Security) with SMTP id C4.78.07742.901A1185; Thu, 27 Oct 2016 08:39:06 +0200 (CEST) Received: from [100.94.10.26] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.319.2; Thu, 27 Oct 2016 08:39:04 +0200 To: HIP From: Gonzalo Camarillo Message-ID: Date: Thu, 27 Oct 2016 09:39:04 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGbHdQ5droWCEwZ8pvBZTF01mdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvpTD9kLNjJWLNn1kr2BsZexi5GTQ0LARGJfyy2WLkYuDiGB 9YwS/34tYgZJCAmsYpTouxYPYosISEr03F3KAmKzCVhIbLl1H8wWFlCReHpoNhOIzStgL7Hs 6BIwm0VAVWL68k5WEFtUIEbi+rNHbBA1ghInZz4B6uXgYBbQlFi/Sx8kzCwgL7H97RyotdoS y5+1sExg5J2FpGMWQscsJB0LGJlXMYoWpxYn5aYbGeulFmUmFxfn5+nlpZZsYgSGzcEtv1V3 MF5+43iIUYCDUYmH98E2gQgh1sSy4srcQ4wSHMxKIrz1UwQjhHhTEiurUovy44tKc1KLDzFK c7AoifOarbwfLiSQnliSmp2aWpBaBJNl4uCUamBsWPGNsXPTIsajW4X+Luq/WLRro+H01znT snlvzyu+m/lbfr796TNJVUb3wv7s/rP0stiEiC75Zd6Tb8ypuFaplSJVHTl7UY4F15ZH7Kvn 7UtSbTBQ5trCV5DzrEFtzgTdtY3tIjNqp3cfzvo272OWkNa0f/vjNNYK/rI6pOJk9ufl7SkZ EQ+blViKMxINtZiLihMBzGzWXhcCAAA= Archived-At: Subject: [Hipsec] WGLC: draft-ietf-hip-dex-04 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 27 Oct 2016 06:39:09 -0000 Folks, I would like to start a WGLC on the following draft. This WGLC will end on November 20th: https://tools.ietf.org/html/draft-ietf-hip-dex-04 Thanks, Gonzalo From nobody Thu Oct 27 03:57:23 2016 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 6539A129C78 for ; Thu, 27 Oct 2016 03:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90vpZlXdpjRk for ; Thu, 27 Oct 2016 03:57:14 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72515129A73 for ; Thu, 27 Oct 2016 03:57:14 -0700 (PDT) X-AuditID: c1b4fb30-f60a598000000cb2-be-5811dd880e65 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id BC.79.03250.88DD1185; Thu, 27 Oct 2016 12:57:12 +0200 (CEST) Received: from [131.160.51.186] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.3.319.2; Thu, 27 Oct 2016 12:57:10 +0200 To: Gonzalo Camarillo References: From: Miika Komu Organization: Ericsson AB Message-ID: <05261b68-ce2d-f6cc-7ce9-807b64151a4f@ericsson.com> Date: Thu, 27 Oct 2016 13:57:09 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080109030206080204080503" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyM2K7t27HXcEIg/0fzS2mLprMbNGw7jOj A5PH7klN7B5LlvxkCmCK4rJJSc3JLEst0rdL4Mq4e/ISU8FEo4qHFzYyNjD2GXQxcnJICJhI HP21grGLkYtDSGA9o8TWFRehnDWMEp2XbrCBVAkLqEhMujGXFcQWETCTeP9vFROILSRgL/Hi 6msWEJtZwFFi0vtHYDVsAloSq+5cZwax+QUkJTY07AazeYHqW369AqtnEVCVuH12HVi9qECE xK2HHSwQNYISJ2c+AbM5BRwkTl+9xg5yELNAN6PExUsXgRo4gBarSFw8FjyBUWAWkpZZyMpm gd1kJjFv80NmCFtbYtnC11C2tcSMXwfZIGxFiSndD9khbFOJ10c/MkLYxhLL1v1lW8DIsYpR tDi1OCk33chIL7UoM7m4OD9PLy+1ZBMjMCYObvltsIPx5XPHQ4wCHIxKPLwPtglECLEmlhVX 5h5iVAGa82jD6guMUix5+XmpSiK84XcEI4R4UxIrq1KL8uOLSnNSiw8xSnOwKInzmq28Hy4k kJ5YkpqdmlqQWgSTZeLglGpg1L5u2bXtq0+n0UoR9pV6X2Vu3/s6r5NVzaxJyvUHrz3zyx2W rm8ddxnuuz8p53Ez5yXFj///Z776pWl9O81JTtY76bhsknsNq+us1YdYN++8Urd6kdApTmPn ZSm/I3+qpd4wdyw4fdwuQ/9KTNycSZ8ON27lWfVnXcfNs8zybIdCX8XdfnrrmBJLcUaioRZz UXEiAJqjFKWRAgAA Archived-At: Cc: HIP Subject: Re: [Hipsec] RFC 4423bis and hip-dex X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 27 Oct 2016 10:57:22 -0000 --------------ms080109030206080204080503 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Gonzalo, On 10/21/2016 10:28 AM, Gonzalo Camarillo wrote: > Bob, Miika, > > RFC 4423bis does not reference the hip-dex draft. Should it? > > https://tools.ietf.org/html/draft-ietf-hip-rfc4423-bis-14 we can add it if needed. The only problem is that we should push back=20 the 4423bis draft in the IETF queue since dex creates an additional=20 dependency. --------------ms080109030206080204080503 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp 0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1 c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg 6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6 CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP 1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u 6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0 6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8 GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME 2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq 5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2 ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7 QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz 9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYxMDI3MTA1NzA5 WjAvBgkqhkiG9w0BCQQxIgQgqIg7nUeZfyonjLH+PHGNjYL+whxe6e6BIwJ7xSKrKswwXQYJ KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQA4PmiXH5qa yrbxhvFntR48snU6gjW8PJHd0MZ/7PYLLb0HeYKAAsnd6L1yA95DJZx0+AQsuHAcCodTDLN0 WGGu+D2BQtk2GtYE4WA3Z1AXkompH7Pi52J4jVQm03hWIBHmpr7M3u+hLgD/uZ/zHvojWQ4U aRNkGl2AWGUUFCVnOjRfLjywIBRIUzeSY1J9ZzWpVJDHosMTCIQ+DO4NMcPUeK1LHVwag63X R/ELLPLifH2/mN8FfJ1WbNh6lEmip7pwJ2sFi47zi6x8W/Euuce4hU2/RAk3MIhg13nSSXoz 2/G5QpuynViNfoa1pC0pzJT9eIISnXAnzZ7gb3z7JMiWAAAAAAAA --------------ms080109030206080204080503-- From nobody Thu Oct 27 04:07:10 2016 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 7EAFE129445 for ; Thu, 27 Oct 2016 04:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.221 X-Spam-Level: X-Spam-Status: No, score=-104.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzcTa96C77KH for ; Thu, 27 Oct 2016 04:07:04 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 539C2129A67 for ; Thu, 27 Oct 2016 04:07:04 -0700 (PDT) X-AuditID: c1b4fb25-93fff70000001e3e-fe-5811dfd61cc9 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id 19.79.07742.6DFD1185; Thu, 27 Oct 2016 13:07:02 +0200 (CEST) Received: from [100.94.10.26] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.3.319.2; Thu, 27 Oct 2016 13:07:02 +0200 To: Miika Komu References: <05261b68-ce2d-f6cc-7ce9-807b64151a4f@ericsson.com> From: Gonzalo Camarillo Message-ID: <66ff7348-c953-9f76-af59-68e1fbac56db@ericsson.com> Date: Thu, 27 Oct 2016 14:07:01 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <05261b68-ce2d-f6cc-7ce9-807b64151a4f@ericsson.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM2K7k+61+4IRBpfmGVhMXTSZ2aJh3WdG ByaP3ZOa2D2WLPnJFMAUxWWTkpqTWZZapG+XwJUxfe5s9oIu1orurs1MDYxNLF2MnBwSAiYS 86Y/Ze9i5OIQEljPKPF42W42CGcVo8Tu7f8YQaqEBVQkJt2YywpiiwhoSDSe3ARmCwmUSnw4 OQushlnAUWLS+0dgcTYBC4ktt+6DbeAVsJe48HouE4jNIqAqsfP3WWYQW1QgRuL6s0dsEDWC EidnPgGr5xRwkFjS+wBoDgfQTE2J9bv0IcbLS2x/O4cZYq22xPJnLSwTGAVmIemehdAxC0nH AkbmVYyixanFSbnpRsZ6qUWZycXF+Xl6eaklmxiBQXlwy2/VHYyX3zgeYhTgYFTi4X2wTSBC iDWxrLgy9xCjBAezkghv7l3BCCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8ZivvhwsJpCeWpGan phakFsFkmTg4pRoYQz6dmaNX9SxtrZHnb+U/MyOVGOf+vPH9qMiu93Pk1D/smpBw9fT1Cfqy PwymXhdj2GpgZqnyLMvTMH7eSn6GV0zhlo9qJmodDPuY/oiR4ZegofXZzVZST1jK80483fk8 7PqF0B+XlnyZtbWn5HbP1+NXFk8P2fDnZXBPWL0aF6P4uyP/pwmLMiqxFGckGmoxFxUnAgAS FU1TRgIAAA== Archived-At: Cc: HIP Subject: Re: [Hipsec] RFC 4423bis and hip-dex X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 27 Oct 2016 11:07:08 -0000 Hi Miika, the plan is to publish rfc4423bis last, after all other drafts in our charter (including HIP DEX) have been published. So, this would not have any influence in the planned queue. Cheers, Gonzalo On 27/10/2016 1:57 PM, Miika Komu wrote: > Hi Gonzalo, > > On 10/21/2016 10:28 AM, Gonzalo Camarillo wrote: >> Bob, Miika, >> >> RFC 4423bis does not reference the hip-dex draft. Should it? >> >> https://tools.ietf.org/html/draft-ietf-hip-rfc4423-bis-14 > > we can add it if needed. The only problem is that we should push back > the 4423bis draft in the IETF queue since dex creates an additional > dependency. > From nobody Thu Oct 27 17:31:43 2016 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 0462912987B for ; Thu, 27 Oct 2016 17:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.632 X-Spam-Level: X-Spam-Status: No, score=-4.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhyvavAqXYl5 for ; Thu, 27 Oct 2016 17:31:41 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF3641295D9 for ; Thu, 27 Oct 2016 17:31:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id A964562435 for ; Thu, 27 Oct 2016 20:31:39 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0o9VTLBIg1Ii for ; Thu, 27 Oct 2016 20:31:35 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 1539D62434 for ; Thu, 27 Oct 2016 20:31:35 -0400 (EDT) To: HIP From: Robert Moskowitz Message-ID: <521c8747-2653-b1be-aa58-3c3e79410beb@htt-consult.com> Date: Thu, 27 Oct 2016 20:31:29 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Hipsec] Updated hip drafts X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 00:31:43 -0000 I just updated a a set of drafts: These define a Secure Session Layer Service. The last has how to manage it with HIP and defines some new HIP parameters to negotiate sse and gpcomp: https://www.ietf.org/internet-drafts/draft-moskowitz-sse-04.txt https://www.ietf.org/internet-drafts/draft-moskowitz-gpcomp-01.txt https://www.ietf.org/internet-drafts/draft-moskowitz-ssls-hip-01.txt These propose a hip-based mobility solution for 5gpp. IPnHIP can use gpcomp: https://www.ietf.org/internet-drafts/draft-moskowitz-hierarchical-hip-02.txt https://www.ietf.org/internet-drafts/draft-moskowitz-hip-ipnhip-01.txt https://www.ietf.org/internet-drafts/draft-moskowitz-hip-fast-mobility-01.txt https://www.ietf.org/internet-drafts/draft-moskowitz-hip-based-5gpp-ip-mobility-01.txt I welcome all comments. Thank you Robert Moskowitz