From nobody Tue Mar 3 13:48:39 2020 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 802B23A0A82; Tue, 3 Mar 2020 13:48:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-hip-native-nat-traversal@ietf.org, hip-chairs@ietf.org, hipsec@ietf.org, Gonzalo Camarillo , gonzalo.camarillo@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <158327210243.7870.10766874805525371271@ietfa.amsl.com> Date: Tue, 03 Mar 2020 13:48:22 -0800 Archived-At: Subject: [Hipsec] Roman Danyliw's No Objection on draft-ietf-hip-native-nat-traversal-30: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 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, 03 Mar 2020 21:48:23 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-hip-native-nat-traversal-30: 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-native-nat-traversal/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ** Section 6.1. Per “Also, revealing host addresses exposes information about the local topology that may not be allowed in all corporate environments.”, concur with the sentiment. However, this desire to reduce exposure may be beyond just “corporate” environment – recommend dropping the “corporate” modifier. ** Section 6.1. Per “For these two local policy reasons, an end-host MAY exclude certain host addresses from its LOCATOR_SET parameter, but this requires further experimentation.”, what actions should implementers take from the “this requires further experimentation”? ** Section 6.2. Per “In opportunistic HIP mode (cf. Section 4.1.8 in [RFC7401]), an Initiator sends an I1 with without setting the destination HIT of the Responder”, the text conflicts on whether to send the destination HIT – it likely should say “without the destination HIT” (i.e., “initial I1 packet contains all zeros as the destination HIT” per RFC7401). ** Section 6.3. Could the reference to [HIP-MIDDLE] be clarified: -- The reference says its: “Heer, T., Wehrle, K., and M. Komu, "End-Host Authentication for HIP Middleboxes", Work in Progress, February 2009”. Is that the same as draft-heer-hip-middle-auth-04, from October 2011? -- How much confidence is there in making this recommendation to an unpublished, expired experimental draft? ** Editorial Nits important for clarity in security considerations: -- Section 5.8. s/Similarly as with RVS_HMAC, also RELAY_HMAC is keyed .../Similarly as with RVS_HMAC, RELAY_HMAC .../ -- Section 6.1. Editorial. s/Especially, this could be problematic with a …/This could be especially problematic with a …/ Section 6.1. Recommend being clearing on the privacy and DoS protection by: s/This partially protects the …/This use also partially protects the …/ -- Section 6.7 Editorial. Recommend clarification how HIP is immune to the Section 19.2 of RFC8445 attack with: s/HIP bases its control plane security on Diffie-Hellman key exchange, public keys and Hashed Message Authentication codes, meaning that the mentioned security concerns do not apply to HIP either./ As HIP bases its control plane security on Diffie-Hellman key exchange, public keys and Hashed Message Authentication codes, this attack is mitigated in this protocol./ -- Section 6.7. Editorial. s/The mentioned section discusses also of …/ Section 19.2 of [RFC8445] also mentioned also discusses …/ -- Section 6.7. Editorial. Recommend referencing the text of the connectivity check that prevents the MiTM replay attack: s/The connectivity checks in this protocol are immune … and send back as a response./ The connectivity checks in this protocol are immune … and send back as a response per Section 4.6.1./ Editorial Nits -- Section 1. Editorial. Per “Also, especially NATs usually …” reads awkwardly to me – perhaps “Also, NATs usually ..” -- Section 1. Editorial. Per “… so that basically ICE is responsible for NAT traversal …” reads colloquially – perhaps “so that ICE is responsible for NAT traversal …” -- Section 1. Editorial. Per “Similarly as Legacy ICE-HIP, also this specification …”, it might be more readable as “As with Legacy ICE-HIP, this specification …” -- Section 2. Typo. s/prodecure/procedure/ -- Section 2. Typo. s/the the/the/ -- Section 3. Typo. s/Cotrol/Control/ -- Section 5.6. Typo. s/reserved/reserved/ -- Section 6.5. Typo. s/a another/another/ -- Section 7. Typo. s/emphemeral/ephemeral/ From nobody Tue Mar 3 20:09:07 2020 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 CE4013A0D79; Tue, 3 Mar 2020 20:09:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-hip-native-nat-traversal@ietf.org, hip-chairs@ietf.org, hipsec@ietf.org, Gonzalo Camarillo , gonzalo.camarillo@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <158329494071.7765.9192526076932474796@ietfa.amsl.com> Date: Tue, 03 Mar 2020 20:09:00 -0800 Archived-At: Subject: [Hipsec] Benjamin Kaduk's Discuss on draft-ietf-hip-native-nat-traversal-30: (with DISCUSS and COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 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: Wed, 04 Mar 2020 04:09:01 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-hip-native-nat-traversal-30: Discuss 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-native-nat-traversal/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- One fairly minor point to start: Section 4.3 says that we define a new mode (ICE-HIP-UDP) for the NAT_TRAVERSAL_MODE parameter type, but then goes on to say that "the presence of the parameter in a HIP base exchange means that the end-host supports NAT traversal extensions defined in this document". If I undrestand correctly, only the specific presence of the ICE-HIP-UDP mode of the NAT_TRAVERSAL_MODE parameter does so, and so to say that the presence of "the [NAT_TRAVERSAL_MODE] parameter" indicates support for this document would be backwards incompatible with RFC 5770. I'd also like to delve a little further into the potential "cross-protocol" attack (same protocol, really, but the same attack) that Ekr raised, between RVS_HMAC and RELAY_HMAC. This is probably a "discuss discuss", so let's see where it leads... The semantics for either type of HMAC is that it is an HMAC over the HIP packet excluding itself and subsequent parameters. Pulling up the HIP packet format from RFC 7401, that looks like: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Header Length |0| Packet Type |Version| RES.|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Controls | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender's Host Identity Tag (HIT) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver's Host Identity Tag (HIT) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / HIP Parameters / / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The HMAC key is the integrity key for that direction of traffic between HITs, so the "cross-protocol" part can only come in by confusing the packet recipient into confusion as to whether it is processing an RVS_HMAC or a RELAY_HMAC (but any other entity will reject the packet by virtue of it using the wrong key). Modern best practices are to go through a key derivation step that incorporates as much information as possible about what the derived key will be used for, which would in this case include the TLV type of the HMAC parameter and presumably the HITs in question as well. In particular, the TLV type of the HMAC parameter is *not* input into the HMAC calculation (at least for RVS_HMAC), so the trivial discriminator is not present. The "packet type" in the header in the header is potentially going to differ across usages, so I think that's a good place to focus discussion. Unfortunately, Section 4.2.1 of RFC 8004 suggests that RVS_HMAC is going to be present a lot of the time, so it's not really clear to me what packet types either RVS_HMAC and/or REPLAY_HMAC are expected to occur in. Could a HIP expert please jump in and help clarify? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [My latest reply to the ballot thread for my previous ballot position, https://mailarchive.ietf.org/arch/msg/hipsec/iP_of3P2RfxJIbeVDz2qGonO8nY/ , seems to have not gotten a response] Why did some rfc5245bis references get converted to RFC5245 and others to RFC8445? The phrase "Control Data Relay" occurs just five times in the document (vs. over a hundred for "Control Relay") and seems to needlessly conflate "Control Relay" and "Data Relay". I'd suggest rewording to avoid this phrase. Abstract and UDP encapsulation of data and signaling traffic. The main difference from the previously specified modes is the use of HIP messages instead of ICE for all NAT traversal procedures due to its kernel-space dependencies. It might be worth disambiguating what "its" refers to. Section 1 messages tunneled over a single UDP flow. The benefit of using ICE and its STUN/TURN messaging formats is that one can re-use the NAT traversal infrastructure already available in the Internet, such as STUN and TURN servers. Also, some middleboxes may be STUN-aware and may be able to do something "smart" when they see STUN being used for NAT traversal. Don't we go on to say that we can't actually use stock TURN infrastructure since we'd need extra encapsulation for the HIP bits? Section 2 HIP offer: Before two end-hosts can establish a communication channel using the NAT traversal procedures defined in this document, they need exchange their locators (i.e. candidates) with each other. In ICE, this procedure is called Candidate Exchange and it does specify how the candidates are exchanged but Session Description nit: s/does specify/does not specify/ handover. Following [RFC5770] and Session Description Protocol (SDP) [RFC3264] naming conventions, "HIP offer" is the the nit: we just expanded SDP a few lines previously; we probably don't need to do it again. Section 3 connected to the public Internet. To be contacted from behind a NAT, at least the Responder must be registered with is own Control Relay Server reachable on the public Internet. The Responder may have also nit: "is own" is not right; I'm not sure whether "his own" or "its own" was intended (but the "a Control Relay Server in the -28 didn't seem wrong to me either). Section 4.1 In step 3, the Relay Client selects the services for which it registers and lists them in the REG_REQ parameter. The Relay Client registers for the Control Data Relay service by listing the RELAY_UDP_HIP value in the request parameter. If the Relay Client requires also ESP relaying over UDP, it lists also RELAY_UDP_ESP. (This is one of the five "Control Data Relay"s I mention previously.) I'd suggest using "Data Relay Service" in combination with RELAY_UDP_ESP to reinforce the link between the two terms. The current "mix and match" of "Control [...] Relay" and "RELAY_UDP_ESP" requires more effort to understand than using a uniform set of terminology would. ECHO_REQUEST_SIGNED . In case the Data Relay Server admitted a new relayed UDP port for the Data Relay Client, the REG_RES parameter MUST list RELAY_UDP_ESP as a service and the UPDATE message MUST also include a RELAYED_ADDRESS parameter describing the relayed UDP port. nit: "admitted" is a surprising word choice, to me. Section 4.2 local preference value MUST be unique. Dual-stack considerations for IPv6 apply also here as defined in [RFC8445] in section 5.1.2.2. It looks like this should be 5.1.2.1, not 5.1.2.2. where Ta is the value used for the connectivity check pacing and Num- Of-Cands is the sum of server-reflexive and relay candidates. A smaller value than 500 ms for the RTO MUST NOT be used. nit: I don't think addition is defined on (set-of-server-reflexive candidates, set-of-relay candidates); presumably there's some missing "number of"s here. Section 4.3 In step 4, the Responder concludes the base exchange with an R2 packet. If the Initiator chose ICE NAT traversal mode, the Responder nit(?): s/ICE NAT/ICE-HIP-UDP/? Section 4.5 repeated here. Similarly, the NAT traversal mode negotiation process (denoted as NAT_TM in the example) was described in Section 4.3 and is neither repeated here. If a Control Relay Server receives an R1 nit: AFAIK this is not a correct usage of "neither". It is RECOMMENDED that the Initiator send an I1 packet encapsulated in UDP when it is destined to an IPv4 address of the Responder. Respectively, the Responder MUST respond to such an I1 packet with a UDP-encapsulated R1 packet, and also the rest of the communication related to the HIP association MUST also use UDP encapsulation. Is this Responder behavior also restricted to IPv4? Server. The Control Relay Server protects the I1 packet with RELAY_HMAC as described in [RFC8004], except that the parameter type is different (see Section 5.8). The Control Relay Server changes the I suggest dropping the 8004 reference and just using Section 5.8 of this document. In step 3, the Responder receives the I1 packet. The Responder processes it according to the rules in [RFC7401]. In addition, the Responder validates the RELAY_HMAC according to [RFC8004] and silently drops the packet if the validation fails. The Responder [likewise here] In step 7, the Responder receives the I2 packet and processes it according to [RFC7401]. The Responder validates the RELAY_HMAC according to [RFC8004] and silently drops the packet if the validation fails. It replies with an R2 packet and includes a [and here] Hosts MUST include the address of one or more Control Relay Servers (including the one that is being used for the initial signaling) in the LOCATOR_SET parameter in I2 and R2 if they intend to use such servers for relaying HIP signaling immediately after the base exchange completes. The traffic type of these addresses MUST be "HIP signaling" and they MUST NOT be used as HIP candidates. If the I'm not sure I understand how the recipient will know that a given "HIP signaling" candidate is intended only for signaling and is not to be used as a HIP candidate. Is that inherent to the "HIP signaling" traffic type (vs. ESP)? (We don't seem to define "HIP candidate" specifically", which probably contributes to my confusion.) Section 4.6.2 All of the connectivity check packets MUST be protected with HMACs and signatures (even though the illustrations in this specification omit them for simplicity). Each connectivity check sent by a host Are these the RELAY_HMACs defined by this document or the normal HIP_MAC? [RFC7401] states that UPDATE packets have to include either a SEQ or ACK parameter (or both). According to the RFC, each SEQ parameter should be acknowledged separately. In the context of NATs, this I'm not finding where RFC 7401 says that each SEQ parameter should be "acknowledged separately". (A few sentences later we say that an ACK parameter may acknowledge multiple sequence identifiers, too...) Full ICE procedures for prioritizing candidates, eliminating redundant candidates, forming check lists (including pruning) and triggered check-queues MUST be followed as specified in section 6.1 [RFC8445], with the exception that the foundation, frozen candidates nit: missing "of" Section 4.7.2 traversal mode as one of the supported modes in the R1 packet. If the Responder has registered to a Control Relay Server in order to discover its address candidates, it MUST also include a LOCATOR_SET parameter in R1 that contains a preferred address where the Responder Previous mentions of LOCATOR_SET have mandated an ENCRYPTED container. If this instance is notable in its exception from that, I suggest calling it out explicitly as not encrypted; otherwise, I think a reminder might be in order. is able to receive UDP-encapsulated ESP and HIP packets. This locator MUST be of type "Transport address", its Traffic type MUST be "both", and it MUST have the "Preferred bit" set (see Table 1). If there is no such locator in R1, the source address of R1 is used as the Responder's preferred address. Given the last sentence, it seems like the "MUST also include [...] preferred address" is unenforceable by the Initiator. Section 4.9 responds with an UPDATE with ECHO_REQ_SIGN as described in step 3 in Figure 6. Upon receiving the valid response from host M as described in step 6, the peer host MUST restart the connectivity checks with host M. This way, both hosts start the connectivity checks roughly in a synchronized way. It is also important that peer host does not restart the connectivity checks until it has received a valid "fresh" confirmation from host M because the UPDATE message carrying locators could be replayed by an attacker. Can you remind me which step this "fresh" confirmation is in? Step 6 doesn't really seem to match that description... Section 5.4 The format of NAT traversal mode parameter is borrowed from Legacy ICE-HIP [RFC5770]. The format of the NAT_TRAVERSAL_MODE parameter is "Borrowed from"? It had darn well better be *the same as* (i.e., "retained from") the RFC 5770 format, the way we're using the IANA registry for NAT traversal modes... (The "defined in [RFC5770]. but repeated for completeness" language we use for TRANSACTION_PACING seems much better.) Section 5.7 Should we say that the LOCATOR_SET must always appear within an ENCRYPTED wrapper? Section 6.1 It's hard to see the phrase "requires further experimentation" in a proposed standard. (Maybe it shouldn't be, given the "proposed" part, but in practice it seems to be.) Perhaps we could just say that which host addresses to exclude from the LOCATOR_SET is a matter of local policy? This scenario is referred to as the hairpin problem [RFC5128]. With such a legacy NAT, the only option left would be to use a relayed transport address from an Control Relay Server server. Data Relay Server, no? (Also, nit: "Server server".) Section 6.7 replay attacks that are difficult to prevent. The connectivity checks in this protocol are immune against replay attacks because a connectivity request includes a random nonce that the recipient must sign and send back as a response. If I was feeling particularly pedantic I'd request "effectively immune", since there is the minor risk of collision in the random nonce values. Section 10.1 RFC 5766 could probably be just an informative reference; RFCs 6146 and 6147 as well. Section 10.2 I'm not sure that we still need to reference RFC 5245 (vs. 8445)? The status of RFC 5770 is less clear; in Section 5 we note that "most of the parameters are shown for the sake of completeness", implying that not all are shown, which would in theory leave a normative dependency on RFC 5770 for those parameters' interpretation. Similarly, the status of RFC 3948 is also less clear; we do use a fair bit of machinery from it and it's not trivially clear that we reproduce everything that is needed. Could we get "draft-rosenberg-mmusic-ice-nonsip" included in the [MMUSIC-ICE] reference, assuming that's the right I-D? Similarly, a draft name for [HIP-MIDDLE] would be helpful. Appendix A ["further experimentation" here as well] From nobody Tue Mar 3 20:48:01 2020 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 E1AD03A0E15; Tue, 3 Mar 2020 20:47:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan via Datatracker To: "The IESG" Cc: draft-ietf-hip-dex@ietf.org, hip-chairs@ietf.org, hipsec@ietf.org, Gonzalo Camarillo , gonzalo.camarillo@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Suresh Krishnan Message-ID: <158329724383.7687.5696211532188484676@ietfa.amsl.com> Date: Tue, 03 Mar 2020 20:47:23 -0800 Archived-At: Subject: [Hipsec] Suresh Krishnan's Discuss on draft-ietf-hip-dex-13: (with DISCUSS) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 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: Wed, 04 Mar 2020 04:47:24 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-hip-dex-13: Discuss 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-dex/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This should be pretty straightforward to resolve. * Section 5.4.: The ICMPv6 Parameter Problem messages to be sent need a Code field to be set in addition to the Pointer. What Code should be used in this message? Please specify this. From nobody Wed Mar 4 05:19:39 2020 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 B4AED3A0EB2; Wed, 4 Mar 2020 05:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 fKmaCrtsDS6F; Wed, 4 Mar 2020 05:19:29 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 13B563A0EB7; Wed, 4 Mar 2020 05:19:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id A3CA86220F; Wed, 4 Mar 2020 08:19:26 -0500 (EST) 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 iqm8-HmFOhSH; Wed, 4 Mar 2020 08:19:20 -0500 (EST) Received: from lx140e.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 D09F8621FB; Wed, 4 Mar 2020 08:19:18 -0500 (EST) To: Suresh Krishnan , The IESG Cc: draft-ietf-hip-dex@ietf.org, hip-chairs@ietf.org, hipsec@ietf.org, Gonzalo Camarillo References: <158329724383.7687.5696211532188484676@ietfa.amsl.com> From: Robert Moskowitz Message-ID: Date: Wed, 4 Mar 2020 08:19:09 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <158329724383.7687.5696211532188484676@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------EA7300C6F4E59892A02924E0" Content-Language: en-US Archived-At: Subject: Re: [Hipsec] Suresh Krishnan's Discuss on draft-ietf-hip-dex-13: (with DISCUSS) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 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: Wed, 04 Mar 2020 13:19:32 -0000 This is a multi-part message in MIME format. --------------EA7300C6F4E59892A02924E0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit This looks more like an RFC 7401 problem than a HIP-DEX problem; as DEX inherits this from 7401.  In fact it is an RFC 5201 problem! It looks like Suresh is correct that a code is needed and in sec 3.4 of RFC 2463 a code is need.. I looked at: https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-codes-5 And nothing there that looks right. So what is done in HIP BEX implementations?  Both v1 and v2? And should this be fixed in DEX or an errata for 5201 and 7401?  And if we do an errata, do we still specify the code in DEX? Nothing is ever "straightforward to resolve" ... On 3/3/20 11:47 PM, Suresh Krishnan via Datatracker wrote: > Suresh Krishnan has entered the following ballot position for > draft-ietf-hip-dex-13: Discuss > > 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-dex/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This should be pretty straightforward to resolve. > > * Section 5.4.: > > The ICMPv6 Parameter Problem messages to be sent need a Code field to be set in > addition to the Pointer. What Code should be used in this message? Please > specify this. > > > > > -- Standard Robert Moskowitz Owner HTT Consulting C:248-219-2059 F:248-968-2824 E:rgm@labs.htt-consult.com There's no limit to what can be accomplished if it doesn't matter who gets the credit --------------EA7300C6F4E59892A02924E0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit This looks more like an RFC 7401 problem than a HIP-DEX problem; as DEX inherits this from 7401.  In fact it is an RFC 5201 problem! 

It looks like Suresh is correct that a code is needed and in sec 3.4 of RFC 2463 a code is need..

I looked at:

https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-codes-5

And nothing there that looks right.

So what is done in HIP BEX implementations?  Both v1 and v2?

And should this be fixed in DEX or an errata for 5201 and 7401?  And if we do an errata, do we still specify the code in DEX?

Nothing is ever "straightforward to resolve" ...

On 3/3/20 11:47 PM, Suresh Krishnan via Datatracker wrote:
Suresh Krishnan has entered the following ballot position for
draft-ietf-hip-dex-13: Discuss

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-dex/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This should be pretty straightforward to resolve.

* Section 5.4.:

The ICMPv6 Parameter Problem messages to be sent need a Code field to be set in
addition to the Pointer. What Code should be used in this message? Please
specify this.

--
Standard Robert Moskowitz
Owner
HTT Consulting
C:      248-219-2059
F:      248-968-2824
E:      rgm@labs.htt-consult.com

There's no limit to what can be accomplished if it doesn't matter who gets the credit
--------------EA7300C6F4E59892A02924E0-- From nobody Wed Mar 4 07:53:27 2020 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 31F6A3A11B7; Wed, 4 Mar 2020 07:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 uATL-3pAfI75; Wed, 4 Mar 2020 07:53:16 -0800 (PST) Received: from out.west.exch081.serverdata.net (cas081-co-8.exch081.serverdata.net [199.193.204.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A5EF3A1152; Wed, 4 Mar 2020 07:53:16 -0800 (PST) Received: from MBX081-W5-CO-2.exch081.serverpod.net (10.224.129.85) by MBX081-W5-CO-1 (10.224.129.84) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 4 Mar 2020 07:53:15 -0800 Received: from MBX081-W5-CO-2.exch081.serverpod.net ([10.224.129.85]) by MBX081-W5-CO-2.exch081.serverpod.net ([10.224.129.85]) with mapi id 15.00.1497.006; Wed, 4 Mar 2020 07:53:15 -0800 From: Jeff Ahrenholz To: Robert Moskowitz , Suresh Krishnan , The IESG CC: "draft-ietf-hip-dex@ietf.org" , "hip-chairs@ietf.org" , Gonzalo Camarillo , "hipsec@ietf.org" Thread-Topic: [Hipsec] Suresh Krishnan's Discuss on draft-ietf-hip-dex-13: (with DISCUSS) Thread-Index: AQHV8eAGgMkmjXilYEGkvJM2YzFVyag48VWA//+k8QA= Date: Wed, 4 Mar 2020 15:53:15 +0000 Message-ID: <820F683A-84D6-4BC2-B980-04DD45191EFA@tempered.io> References: <158329724383.7687.5696211532188484676@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [216.168.34.194] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Hipsec] Suresh Krishnan's Discuss on draft-ietf-hip-dex-13: (with DISCUSS) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 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: Wed, 04 Mar 2020 15:53:19 -0000 Pg0KPiBodHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9pY21wdjYtcGFyYW1ldGVycy9p Y21wdjYtcGFyYW1ldGVycy54aHRtbCNpY21wdjYtcGFyYW1ldGVycy1jb2Rlcy01DQo+DQo+IEFu ZCBub3RoaW5nIHRoZXJlIHRoYXQgbG9va3MgcmlnaHQuIA0KPiANCj4gU28gd2hhdCBpcyBkb25l IGluIEhJUCBCRVggaW1wbGVtZW50YXRpb25zP8KgIEJvdGggdjEgYW5kIHYyPw0KDQpGb3Igb3Vy IEhJUHYxIGltcGxlbWVudGF0aW9uOg0KSVB2NCBwYWNrZXRzIC0gd2Ugc2VuZCBJQ01QdjQtaW4t VURQIHdpdGggdHlwZSAxMiAicGFyYW1ldGVyIHByb2JsZW0iIGNvZGUgMCAicG9pbnRlciBpbmRp Y2F0ZXMgdGhlIGVycm9yIiBhbmQgcG9pbnQgdG8gdGhlIGZpcnN0IGJ5dGVzIG9mIFVEUCBwYXls b2FkLiAoaHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvaWNtcC1wYXJhbWV0ZXJzL2lj bXAtcGFyYW1ldGVycy54aHRtbCNpY21wLXBhcmFtZXRlcnMtY29kZXMtMTIpDQoNCklQdjYgcGFj a2V0cyAtIHdlIHNlbmQgSUNNUHY2LWluLVVEUCB3aXRoIHR5cGUgNCAicGFyYW1ldGVyIHByb2Js ZW0iIGNvZGUgMCAiZXJyb25lb3VzIGhlYWRlciBmaWVsZCBlbmNvdW50ZXJlZCIgYW5kIHBvaW50 IHRvIHRoZSBmaXJzdCBieXRlcyBvZiBVRFAgcGF5bG9hZC4gDQoNCk5vcm1hbGx5IHRoaXMgd291 bGQgYmUgaWYgdGhlIFNQSSBpcyB1bmtub3duIChlLmcuIG9uZSBzaWRlIGZvcmNlZnVsbHkgcmVi b290cyB3aGlsZSB0aGUgb3RoZXIgY29udGludWVzIHRvIHNlbmQgaXQgRVNQLWluLVVEUCBkYXRh LikgVGhlIHBvaW50ZXIgaW5jbHVkZXMgdGhlIGZpcnN0IDggYnl0ZXMgb2YgdGhlIFVEUCBwYXls b2FkIHNvIHRoYXQgdGhlIFNQSSBpcyBpbmNsdWRlZCBpbiB0aGUgSUNNUCBtZXNzYWdlLg0KDQpG b3IgSVB2NiB5b3UgY291bGQgY29uc2lkZXIgdGhlICJlcnJvbmVvdXMgaGVhZGVyIGZpZWxkIiB0 byBiZSB0aGUgaW52YWxpZCBTUEkgbnVtYmVyLCB3aGljaCBpcyB0aGUgYnl0ZXMgd2UgcG9pbnQg dG8uDQoNCi1KZWZmDQoNCg== From nobody Wed Mar 4 08:09:31 2020 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 39D943A11CE; Wed, 4 Mar 2020 08:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 GpWjT2ul-ucC; Wed, 4 Mar 2020 08:09:23 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 574C63A1118; Wed, 4 Mar 2020 08:09:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 605796220F; Wed, 4 Mar 2020 11:09:21 -0500 (EST) 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 1P5f02K2dtTp; Wed, 4 Mar 2020 11:09:14 -0500 (EST) Received: from lx140e.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 B7DF7621CB; Wed, 4 Mar 2020 11:09:11 -0500 (EST) To: Jeff Ahrenholz , Robert Moskowitz , Suresh Krishnan , The IESG Cc: "draft-ietf-hip-dex@ietf.org" , "hipsec@ietf.org" , "hip-chairs@ietf.org" , Gonzalo Camarillo References: <158329724383.7687.5696211532188484676@ietfa.amsl.com> <820F683A-84D6-4BC2-B980-04DD45191EFA@tempered.io> From: Robert Moskowitz Message-ID: Date: Wed, 4 Mar 2020 11:09:04 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <820F683A-84D6-4BC2-B980-04DD45191EFA@tempered.io> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Hipsec] Suresh Krishnan's Discuss on draft-ietf-hip-dex-13: (with DISCUSS) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 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: Wed, 04 Mar 2020 16:09:26 -0000 On 3/4/20 10:53 AM, Jeff Ahrenholz wrote: >> https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-codes-5 >> >> And nothing there that looks right. >> >> So what is done in HIP BEX implementations?  Both v1 and v2? > For our HIPv1 implementation: > IPv4 packets - we send ICMPv4-in-UDP with type 12 "parameter problem" code 0 "pointer indicates the error" and point to the first bytes of UDP payload. (https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml#icmp-parameters-codes-12) > > IPv6 packets - we send ICMPv6-in-UDP with type 4 "parameter problem" code 0 "erroneous header field encountered" and point to the first bytes of UDP payload. > > Normally this would be if the SPI is unknown (e.g. one side forcefully reboots while the other continues to send it ESP-in-UDP data.) The pointer includes the first 8 bytes of the UDP payload so that the SPI is included in the ICMP message. > > For IPv6 you could consider the "erroneous header field" to be the invalid SPI number, which is the bytes we point to. > > -Jeff > Suresh, How would you recommend handling this?  It seems the text in all docs (5201, 7401, and DEX) might be: In most cases, the ICMP packet has the Parameter Problem type (12 for ICMPv4, 4 with code=0 for ICMPv6), Please advise. From nobody Wed Mar 4 09:45:07 2020 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 1B39C3A1377; Wed, 4 Mar 2020 09:44:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-hip-dex@ietf.org, hip-chairs@ietf.org, hipsec@ietf.org, Gonzalo Camarillo , gonzalo.camarillo@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <158334389700.29463.11015652778464092751@ietfa.amsl.com> Date: Wed, 04 Mar 2020 09:44:57 -0800 Archived-At: Subject: [Hipsec] Benjamin Kaduk's Discuss on draft-ietf-hip-dex-13: (with DISCUSS and COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 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: Wed, 04 Mar 2020 17:44:58 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-hip-dex-13: Discuss 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-dex/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is a placeholder discuss, intended to illustrate several key omissions from the current document and as an indication that it is not yet ready for full IESG Evaluation. In that vein, I will defer the evaluation shortly, to attempt to short-circuit the current round of evaluation while the draft improves. In particular, this is not intended to be a complete review of the document. The FOLD scheme for compressing full host identities into ORCHIDs/HITs is pretty problematic. The current text acknowledges that collisions are possible and attempts to justify the scheme by pointing out that no collision-free scheme is possible absent a cryptographic hash, which is an appeal to authority ("we can't use a cryptographic hash on constrained systems") that does not attempt to answer the question of whether it is actually reasonable to use a mechanism that allows collisions for this purpose (vs. just not being able to do anything). Additionally, there is not any discussion of second-preimage resistance, which is the more important property here, in terms of an attacker being able to construct a collision with an existing HIT of an honest node. In a related vein, Section 3.2.1 claims that the above concerns can be remediated by deployment of a collision detection scheme, "achieved here through either an ACL or some other lookup process". This process is vital to the security of the system as a whole, and it would be irresponsible to publish this document without a precise specification of what properties are needed in order to perform this process, as well as a worked example that can be used absent other considerations. Given that the applicability statement ("in communicating with such constrained devices") implies that there is intent to have full-featured nodes that implement both HIP DEX and HIP BEX, I think we need significantly more discussion of how such nodes avoid using DEX in situations where it was not appropriate. That is, how is it known that the peer should be using DEX vs. BEX? Yes, the HIT includes an indication of whether the identity is for use with DEX vs. BEX, but that does not seem like quite the relevant property. Do we envision scenarios where a node is positioned somewhat like a gateway, using DEX on one interface and BEX to the broader internet? Using AES-CTR with the long-term static-static master key requires careful tracking of counter (sequence) number to nonvolatile storage. I did not see discussion of the security consequences of inadvertent counter reuse. I appreciate the design to limit use of the long-term static-static master key to essentially just key-wrap operations, but this seems to require the presence of a CSPRNG in order to obtain secure session keys. Expecting a strong CSPRNG on a node so constrained that DEX is necessary seems to be a questionable assumption, and I see no discussion of the need for a good RNG. (Relying on the full-featured peer to contribute good entropy to the key derivation is not an option, since DEX is allowed to be used between two nodes that are both constrained.) The default KEYMAT algorithm uses the "CKDF" (CMAC-based KDF) construction, analogous to HKDF (RFC 5869). However, the paper motivating 5869's design choices does not seem to justify the usage of CMAC instead of HMAC, since the proof requires a PRF* but CMAC (with AES) is only a PRP. Absent some detailed justification or prior art it does not seem prudent to use such a novel construction for security-critical functionality. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Some additional comments (also incomplete), since they were already written. It would be reasonable to ignore for now any that don't make sense or are on parts of the text likely to change as a result of the higher-level discussion. Abstract My preference is to just use "forward secrecy" rather than "perfect forward secrecy", as perfection is hard to attain. Section 1.1 HIP DEX operationally is very similar to HIP BEX. Moreover, the employed model is also fairly equivalent to 802.11-2007 [IEEE.802-11.2007] Master Key and Pair-wise Transient Key, but handled in a single exchange. 802.11 security does not exactly have a shiny track record... HIP DEX does not have the option to encrypt the Host Identity of the Initiator in the I2 packet. The Responder's Host Identity also is not protected. Thus, contrary to HIPv2, HIP DEX does not provide for end-point anonymity and any signaling (i.e., HOST_ID parameter contained with an ENCRYPTED parameter) that indicates such anonymity should be ignored. What would you do if you didn't ignore such signalling? Drop the connection as being with a misbehaving peer? As in [RFC7401], data packets start to flow after the R2 packet. The I2 and R2 packets may carry a data payload in the future. The details of this may be defined later. I'm not sure what value is added by mentioning the possibility of data payload in I2/R2. An existing HIP association can be updated with the update mechanism defined in [RFC7401]. Likewise, the association can be torn down with the defined closing mechanism for HIPv2 if it is no longer needed. In doing so, HIP DEX omits the HIP_SIGNATURE parameters of the original HIPv2 specification. I think the intent here is more along the lines of "HIP DEX does so even in the absence of the HIP_SIGNATURE that is used in standard HIPv2". (I also note that there's some subtle semantic mismatch between DEX as "diet exchange" and its used to indicate continuing lack of security functionality throughout the extent of the association, after the exchange is completed.) Finally, HIP DEX is designed as an end-to-end authentication and key establishment protocol. As such, it can be used in combination with Don't we have a LAKE WG now? How does DEX compare to what they are working on? Section 1.2 In lieu of detailed comments, allow me to propose a rewrite of the whole section: % HIP DEX achieves its lightweight nature in large part due to the % intentional removal of Forward Secrecy (FS) from the key exchange. Current % mechanisms to achieve FS use an authenticated ephemeral Diffie-Hellman % exchange (e.g., SIGMA or PAKE). HIP DEX targets usage on devices where % even the most lightweight ECDH exchange is prohibitively expensive for % recurring (ephemeral) use. For example, experience with the 8-bit % 8051-based ZWAWVE ZW0500 microprocessor has shown that EC25519 keypair % generation exceeds 10 seconds and consumes significant energy (i.e., % battery resources). Even the ECDH multiplication for the HIP DEX % static-static key exchange takes 8-9 seconds, again with measurable % energy consumption. This resource consumption is tolerable as a % one-time event during provisioning, but would render the protocol % unsuitable for use on these devices if it was required to be a % recurring part of the protocol. For devices constrained in this % manner, a FS-enabled protocol will likely provide little gain. The % resulting "FS" key, likely produced during device provisioning, would % typically end up being used for the remainder of the device's % lifetime. With such a usage pattern, the inherent benefit of % ephemeral keys is not realized. The security properties of such usage % are very similar to those of using a statically provisioned symmetric % pre-shared key, in that there remains a single PSK in static storage % that is susceptible to exfiltration/compromise, and compromise of that % key in effect compromises the entire protocol for that node. HIP DEX % achieves marginally better security properties by computing the % effective long-term PSK from a DH exchange, so that the provisioning % service is not required to be part of the risk surface due to also % possessing the PSK. % % Due to the substantially reduced security guarantees of HIP DEX % compared to HIP BEX, HIP DEX MUST only be used when at least one of % the two endpoints is a class 0 or 1 constrained device defined in % Section 3 of [RFC7228]). HIP DEX MUST NOT be used when both endpoints % are class 2 devices or unconstrained. Section 2.2 Ltrunc (M(x), K) denotes the lowest order K bits of the result of the MAC function M on the input x. I'm not sure I'm going to interpret the "lowest order K bits" the same way that everyone else will. I think "leftmost" or "first" are more common terms for describing this sort of truncation. Section 2.3 CMAC: The Cipher-based Message Authentication Code with the 128-bit Advanced Encryption Standard (AES) defined in RFC 4493 [RFC4493]. I would suggest just using CMAC as the acronym and not trying to overload it to also be AES-specific. HIT Suite: A HIT Suite groups all algorithms that are required to generate and use an HI and its HIT. In particular, these algorithms are: 1) ECDH and 2) FOLD. For DEX. For normal HIPv2 we wouldn't touch FOLD with a long pole. HI (Host Identity): The static ECDH public key that represents the identity of the host. In HIP DEX, a host proves ownership of the private key belonging to its HI by creating a HIP_MAC with the derived ECDH key (see Section 3). This may sound pedantic, but this doesn't actually prove ownership of the private key. Someone who knows the private key of the other party and the public key of the host in question would be able to produce the same MAC from the corresponding derived ECDH key. I think the most we can say here is that a host authenticates itself as that host identity [with that HIP_MAC]. There's the corresponding trust of the recipient that its own private key remains secure and thus that no party other than itself or the peer identity could have generated that message. Initiator: The host that initiates the HIP DEX handshake. This role is typically forgotten once the handshake is completed. "typically"? Perhaps it's best to say that the role is not used or needed after the handshake is completed. KEYMAT: Keying material. That is, the bit string(s) used as cryptographic keys. I'm surprised we need an abbreviation for this. Length of the Responder's HIT Hash Algorithm (RHASH_len): The natural output length of RHASH in bits. [this doesn't really fit the pattern of "definition"s] Responder: The host that responds to the Initiator in the HIP DEX handshake. This role is typically forgotten once the handshake is completed. [same thing re "typically"] Section 3 HIP DEX implementations MUST support the Elliptic Curve Diffie- Hellman (ECDH) [RFC6090] key exchange for generating the HI as defined in Section 5.2.3. No additional algorithms are supported at this time. It's kind of weird to see a "MUST" for "RFC6090 key exchange"; 6090 discusses the general class of things but is not a specific key exchange algorithm (e.g., curve). I'd also consider s/supported/defined/. Due to the latter property, an attacker may be able to find a collision with a HIT that is in use. Hence, policy decisions such as access control MUST NOT be based solely on the HIT. Instead, the HI of a host SHOULD be considered. I don't think this is correct or a strong enough statement. In particular, I don't think access control should be based on the HIT at all, so strike "solely". Also, the "SHOULD" seems too week. I can understand that "MUST use the HI" could be overly constraining, but "access control decisions MUST be made on the actual identity of the host, e.g., the full HI" should allow for sufficient flexibility. Carrying HIs and HITs in the header of user data packets would increase the overhead of packets. Thus, it is not expected that s/and/or/? association. When other user data packet formats are used, the corresponding extensions need to define a replacement for the ESP_TRANSFORM [RFC7402] parameter along with associated semantics, but this procedure is outside the scope of this document. Why is ESP_TRANSFORM the most important parameter here, when we talk about mapping a packet to the HIP association? I thought ESP_TRANSFORM was literally about the encryption mechanics, not metadata around it. Section 3.2 ORCHID claims to provide statistical uniqueness and routability at some overlay layer, neither of which this FOLD procedure provides, due to easily-generatable second preimages. Section 3.2.1 Since collision-resistance is not possible with the tools at hand, any reasonable function (e.g. FOLD) that takes the full value of the HI into generating the HIT can be used, provided that collision detection is part of the HIP-DEX deployment design. This is achieved This is not an argument that this is a reasonable thing to do; it's merely an argument that it's a thing that can be done that has the same claimed properties as the only type of thing that could be done. It might be a bad idea to do the only type of thing that can be done, and you have not convinced me otherwise. (See also the distinction between collision-resistance and second-preimage-resistance alluded to in my comment on the previous section.) here through either an ACL or some other lookup process that externally binds the HIT and HI. Without at least one well-specified mechanism for actually doing this and clear documentation of what precise properties such a mechanism needs to provide, I think it's irresponsible to publish this document. Section 4.1 By definition, the system initiating a HIP Diet EXchange is the Initiator, and the peer is the Responder. This distinction is typically forgotten once the handshake completes, and either party can become the Initiator in future communications. ["typically" again] Diffie-Hellman Group IDs supported by the Initiator. Note that in some cases it may be possible to replace this trigger packet by some other form of a trigger, in which case the protocol starts with the Responder sending the R1 packet. In such cases, another mechanism to convey the Initiator's supported DH Groups (e.g., by using a default group) must be specified. This seems under-specified for a proposed standard and is probably better off omitted entirely. The second packet, R1, starts the actual authenticated Diffie-Hellman key exchange. It contains a puzzle - a cryptographic challenge that the Initiator must solve before continuing the exchange. The level of difficulty of the puzzle can be adjusted based on level of trust with the Initiator, current load, or other factors. In addition, the The Initiator is unauthenticated at this point, so "level of trust" seems to not really be defined... Section 4.1.1 If an unconstrained (DoSing) attacker is competing with a constrained honest initiator to solve puzzles during an attack, it seems like the honest initiator is going to lose out pretty badly. Section 4.1.4 There are security considerations for serializing the HIP state to nonvolatile storage! From nobody Wed Mar 4 09:57:28 2020 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 17F713A13A8; Wed, 4 Mar 2020 09:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 uNo9-1_XZty1; Wed, 4 Mar 2020 09:57:20 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 1D0153A13A5; Wed, 4 Mar 2020 09:57:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 7CB87621CB; Wed, 4 Mar 2020 12:57:18 -0500 (EST) 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 8q-q5A17gcKc; Wed, 4 Mar 2020 12:56:53 -0500 (EST) Received: from lx140e.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 DEC156213A; Wed, 4 Mar 2020 12:56:52 -0500 (EST) To: Benjamin Kaduk , The IESG Cc: draft-ietf-hip-dex@ietf.org, hip-chairs@ietf.org, hipsec@ietf.org, Gonzalo Camarillo References: <158334389700.29463.11015652778464092751@ietfa.amsl.com> From: Robert Moskowitz Message-ID: <0f351ab3-561b-b2e5-9ef1-4f75bcc09f98@labs.htt-consult.com> Date: Wed, 4 Mar 2020 12:56:42 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <158334389700.29463.11015652778464092751@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------312EB6EA53320246E053E15C" Content-Language: en-US Archived-At: Subject: Re: [Hipsec] Benjamin Kaduk's Discuss on draft-ietf-hip-dex-13: (with DISCUSS and COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 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: Wed, 04 Mar 2020 17:57:24 -0000 This is a multi-part message in MIME format. --------------312EB6EA53320246E053E15C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Ben, thank you for the serious, in-depth, review.  It will take a bit to work through your comments. vis-a-vis, LAKE. It would be seriously challenging, and interesting, to review the long-standing work on HIP-DEX with the new work on LAKE.  If so, I would end up throwing in to remove all AES constructs for KECCAK alternatives with small sponges.  Maybe.  This would be a serious piece of work.  But I will think on it. And I AM doing KECCAK in the hip-new-crypto draft.  But it is not an alternative to DEX. On 3/4/20 12:44 PM, Benjamin Kaduk via Datatracker wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-hip-dex-13: Discuss > > 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-dex/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This is a placeholder discuss, intended to illustrate several key > omissions from the current document and as an indication that it is not > yet ready for full IESG Evaluation. In that vein, I will defer the > evaluation shortly, to attempt to short-circuit the current round of > evaluation while the draft improves. In particular, this is not > intended to be a complete review of the document. > > The FOLD scheme for compressing full host identities into ORCHIDs/HITs > is pretty problematic. The current text acknowledges that collisions > are possible and attempts to justify the scheme by pointing out that no > collision-free scheme is possible absent a cryptographic hash, which is > an appeal to authority ("we can't use a cryptographic hash on > constrained systems") that does not attempt to answer the question of > whether it is actually reasonable to use a mechanism that allows > collisions for this purpose (vs. just not being able to do anything). > Additionally, there is not any discussion of second-preimage resistance, > which is the more important property here, in terms of an attacker being > able to construct a collision with an existing HIT of an honest node. > > In a related vein, Section 3.2.1 claims that the above concerns can be > remediated by deployment of a collision detection scheme, "achieved here > through either an ACL or some other lookup process". This process is > vital to the security of the system as a whole, and it would be > irresponsible to publish this document without a precise specification > of what properties are needed in order to perform this process, as well > as a worked example that can be used absent other considerations. > > Given that the applicability statement ("in communicating with such > constrained devices") implies that there is intent to have full-featured > nodes that implement both HIP DEX and HIP BEX, I think we need > significantly more discussion of how such nodes avoid using DEX in > situations where it was not appropriate. That is, how is it known that > the peer should be using DEX vs. BEX? Yes, the HIT includes an > indication of whether the identity is for use with DEX vs. BEX, but that > does not seem like quite the relevant property. Do we envision > scenarios where a node is positioned somewhat like a gateway, using DEX > on one interface and BEX to the broader internet? > > Using AES-CTR with the long-term static-static master key requires > careful tracking of counter (sequence) number to nonvolatile storage. I > did not see discussion of the security consequences of inadvertent > counter reuse. > > I appreciate the design to limit use of the long-term static-static > master key to essentially just key-wrap operations, but this seems to > require the presence of a CSPRNG in order to obtain secure session keys. > Expecting a strong CSPRNG on a node so constrained that DEX is necessary > seems to be a questionable assumption, and I see no discussion of the > need for a good RNG. (Relying on the full-featured peer to contribute > good entropy to the key derivation is not an option, since DEX is > allowed to be used between two nodes that are both constrained.) > > The default KEYMAT algorithm uses the "CKDF" (CMAC-based KDF) > construction, analogous to HKDF (RFC 5869). However, the paper > motivating 5869's design choices does not seem to justify the usage of > CMAC instead of HMAC, since the proof requires a PRF* but CMAC (with > AES) is only a PRP. Absent some detailed justification or prior art it > does not seem prudent to use such a novel construction for > security-critical functionality. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Some additional comments (also incomplete), since they were already written. > It would be reasonable to ignore for now any that don't make sense or > are on parts of the text likely to change as a result of the higher-level discussion. > > Abstract > > My preference is to just use "forward secrecy" rather than "perfect > forward secrecy", as perfection is hard to attain. > > Section 1.1 > > HIP DEX operationally is very similar to HIP BEX. Moreover, the > employed model is also fairly equivalent to 802.11-2007 > [IEEE.802-11.2007] Master Key and Pair-wise Transient Key, but > handled in a single exchange. > > 802.11 security does not exactly have a shiny track record... > > HIP DEX does not have the option to encrypt the Host Identity of the > Initiator in the I2 packet. The Responder's Host Identity also is > not protected. Thus, contrary to HIPv2, HIP DEX does not provide for > end-point anonymity and any signaling (i.e., HOST_ID parameter > contained with an ENCRYPTED parameter) that indicates such anonymity > should be ignored. > > What would you do if you didn't ignore such signalling? Drop the > connection as being with a misbehaving peer? > > As in [RFC7401], data packets start to flow after the R2 packet. The > I2 and R2 packets may carry a data payload in the future. The > details of this may be defined later. > > I'm not sure what value is added by mentioning the possibility of data > payload in I2/R2. > > An existing HIP association can be updated with the update mechanism > defined in [RFC7401]. Likewise, the association can be torn down > with the defined closing mechanism for HIPv2 if it is no longer > needed. In doing so, HIP DEX omits the HIP_SIGNATURE parameters of > the original HIPv2 specification. > > I think the intent here is more along the lines of "HIP DEX does so even > in the absence of the HIP_SIGNATURE that is used in standard HIPv2". > (I also note that there's some subtle semantic mismatch between DEX as > "diet exchange" and its used to indicate continuing lack of security > functionality throughout the extent of the association, after the > exchange is completed.) > > Finally, HIP DEX is designed as an end-to-end authentication and key > establishment protocol. As such, it can be used in combination with > > Don't we have a LAKE WG now? How does DEX compare to what they are > working on? > > Section 1.2 > > In lieu of detailed comments, allow me to propose a rewrite of the whole > section: > > % HIP DEX achieves its lightweight nature in large part due to the > % intentional removal of Forward Secrecy (FS) from the key exchange. Current > % mechanisms to achieve FS use an authenticated ephemeral Diffie-Hellman > % exchange (e.g., SIGMA or PAKE). HIP DEX targets usage on devices where > % even the most lightweight ECDH exchange is prohibitively expensive for > % recurring (ephemeral) use. For example, experience with the 8-bit > % 8051-based ZWAWVE ZW0500 microprocessor has shown that EC25519 keypair > % generation exceeds 10 seconds and consumes significant energy (i.e., > % battery resources). Even the ECDH multiplication for the HIP DEX > % static-static key exchange takes 8-9 seconds, again with measurable > % energy consumption. This resource consumption is tolerable as a > % one-time event during provisioning, but would render the protocol > % unsuitable for use on these devices if it was required to be a > % recurring part of the protocol. For devices constrained in this > % manner, a FS-enabled protocol will likely provide little gain. The > % resulting "FS" key, likely produced during device provisioning, would > % typically end up being used for the remainder of the device's > % lifetime. With such a usage pattern, the inherent benefit of > % ephemeral keys is not realized. The security properties of such usage > % are very similar to those of using a statically provisioned symmetric > % pre-shared key, in that there remains a single PSK in static storage > % that is susceptible to exfiltration/compromise, and compromise of that > % key in effect compromises the entire protocol for that node. HIP DEX > % achieves marginally better security properties by computing the > % effective long-term PSK from a DH exchange, so that the provisioning > % service is not required to be part of the risk surface due to also > % possessing the PSK. > % > % Due to the substantially reduced security guarantees of HIP DEX > % compared to HIP BEX, HIP DEX MUST only be used when at least one of > % the two endpoints is a class 0 or 1 constrained device defined in > % Section 3 of [RFC7228]). HIP DEX MUST NOT be used when both endpoints > % are class 2 devices or unconstrained. > > Section 2.2 > > Ltrunc (M(x), K) denotes the lowest order K bits of the result of > the MAC function M on the input x. > > I'm not sure I'm going to interpret the "lowest order K bits" the same > way that everyone else will. I think "leftmost" or "first" are more > common terms for describing this sort of truncation. > > Section 2.3 > > CMAC: The Cipher-based Message Authentication Code with the 128-bit > Advanced Encryption Standard (AES) defined in RFC 4493 [RFC4493]. > > I would suggest just using CMAC as the acronym and not trying to > overload it to also be AES-specific. > > HIT Suite: A HIT Suite groups all algorithms that are required to > generate and use an HI and its HIT. In particular, these > algorithms are: 1) ECDH and 2) FOLD. > > For DEX. For normal HIPv2 we wouldn't touch FOLD with a long pole. > > HI (Host Identity): The static ECDH public key that represents the > identity of the host. In HIP DEX, a host proves ownership of the > private key belonging to its HI by creating a HIP_MAC with the > derived ECDH key (see Section 3). > > This may sound pedantic, but this doesn't actually prove ownership of > the private key. Someone who knows the private key of the other party > and the public key of the host in question would be able to produce the > same MAC from the corresponding derived ECDH key. I think the most we > can say here is that a host authenticates itself as that host identity > [with that HIP_MAC]. There's the corresponding trust of the recipient > that its own private key remains secure and thus that no party other > than itself or the peer identity could have generated that message. > > Initiator: The host that initiates the HIP DEX handshake. This role > is typically forgotten once the handshake is completed. > > "typically"? Perhaps it's best to say that the role is not used or > needed after the handshake is completed. > > KEYMAT: Keying material. That is, the bit string(s) used as > cryptographic keys. > > I'm surprised we need an abbreviation for this. > > Length of the Responder's HIT Hash Algorithm (RHASH_len): The > natural output length of RHASH in bits. > > [this doesn't really fit the pattern of "definition"s] > > Responder: The host that responds to the Initiator in the HIP DEX > handshake. This role is typically forgotten once the handshake is > completed. > > [same thing re "typically"] > > Section 3 > > HIP DEX implementations MUST support the Elliptic Curve Diffie- > Hellman (ECDH) [RFC6090] key exchange for generating the HI as > defined in Section 5.2.3. No additional algorithms are supported at > this time. > > It's kind of weird to see a "MUST" for "RFC6090 key exchange"; 6090 > discusses the general class of things but is not a specific key exchange > algorithm (e.g., curve). > I'd also consider s/supported/defined/. > > Due to the latter property, an attacker may be able to find a > collision with a HIT that is in use. Hence, policy decisions such as > access control MUST NOT be based solely on the HIT. Instead, the HI > of a host SHOULD be considered. > > I don't think this is correct or a strong enough statement. In > particular, I don't think access control should be based on the HIT at > all, so strike "solely". Also, the "SHOULD" seems too week. I can > understand that "MUST use the HI" could be overly constraining, but > "access control decisions MUST be made on the actual identity of the > host, e.g., the full HI" should allow for sufficient flexibility. > > Carrying HIs and HITs in the header of user data packets would > increase the overhead of packets. Thus, it is not expected that > > s/and/or/? > > association. When other user data packet formats are used, the > corresponding extensions need to define a replacement for the > ESP_TRANSFORM [RFC7402] parameter along with associated semantics, > but this procedure is outside the scope of this document. > > Why is ESP_TRANSFORM the most important parameter here, when we talk > about mapping a packet to the HIP association? I thought ESP_TRANSFORM > was literally about the encryption mechanics, not metadata around it. > > Section 3.2 > > ORCHID claims to provide statistical uniqueness and routability at some > overlay layer, neither of which this FOLD procedure provides, due to > easily-generatable second preimages. > > Section 3.2.1 > > Since collision-resistance is not possible with the tools at hand, > any reasonable function (e.g. FOLD) that takes the full value of the > HI into generating the HIT can be used, provided that collision > detection is part of the HIP-DEX deployment design. This is achieved > > This is not an argument that this is a reasonable thing to do; it's > merely an argument that it's a thing that can be done that has the same > claimed properties as the only type of thing that could be done. It > might be a bad idea to do the only type of thing that can be done, and > you have not convinced me otherwise. (See also the distinction between > collision-resistance and second-preimage-resistance alluded to in my > comment on the previous section.) > > here through either an ACL or some other lookup process that > externally binds the HIT and HI. > > Without at least one well-specified mechanism for actually doing this > and clear documentation of what precise properties such a mechanism > needs to provide, I think it's irresponsible to publish this document. > > Section 4.1 > > By definition, the system initiating a HIP Diet EXchange is the > Initiator, and the peer is the Responder. This distinction is > typically forgotten once the handshake completes, and either party > can become the Initiator in future communications. > > ["typically" again] > > Diffie-Hellman Group IDs supported by the Initiator. Note that in > some cases it may be possible to replace this trigger packet by some > other form of a trigger, in which case the protocol starts with the > Responder sending the R1 packet. In such cases, another mechanism to > convey the Initiator's supported DH Groups (e.g., by using a default > group) must be specified. > > This seems under-specified for a proposed standard and is probably > better off omitted entirely. > > The second packet, R1, starts the actual authenticated Diffie-Hellman > key exchange. It contains a puzzle - a cryptographic challenge that > the Initiator must solve before continuing the exchange. The level > of difficulty of the puzzle can be adjusted based on level of trust > with the Initiator, current load, or other factors. In addition, the > > The Initiator is unauthenticated at this point, so "level of trust" > seems to not really be defined... > > Section 4.1.1 > > If an unconstrained (DoSing) attacker is competing with a constrained > honest initiator to solve puzzles during an attack, it seems like the > honest initiator is going to lose out pretty badly. > > Section 4.1.4 > > There are security considerations for serializing the HIP state to > nonvolatile storage! > > > -- Standard Robert Moskowitz Owner HTT Consulting C:248-219-2059 F:248-968-2824 E:rgm@labs.htt-consult.com There's no limit to what can be accomplished if it doesn't matter who gets the credit --------------312EB6EA53320246E053E15C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Ben,

thank you for the serious, in-depth, review.  It will take a bit to work through your comments.

vis-a-vis, LAKE.

It would be seriously challenging, and interesting, to review the long-standing work on HIP-DEX with the new work on LAKE.  If so, I would end up throwing in to remove all AES constructs for KECCAK alternatives with small sponges.  Maybe.  This would be a serious piece of work.  But I will think on it.

And I AM doing KECCAK in the hip-new-crypto draft.  But it is not an alternative to DEX.

On 3/4/20 12:44 PM, Benjamin Kaduk via Datatracker wrote:
Benjamin Kaduk has entered the following ballot position for
draft-ietf-hip-dex-13: Discuss

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-dex/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is a placeholder discuss, intended to illustrate several key
omissions from the current document and as an indication that it is not
yet ready for full IESG Evaluation.  In that vein, I will defer the
evaluation shortly, to attempt to short-circuit the current round of
evaluation while the draft improves.  In particular, this is not
intended to be a complete review of the document.

The FOLD scheme for compressing full host identities into ORCHIDs/HITs
is pretty problematic.  The current text acknowledges that collisions
are possible and attempts to justify the scheme by pointing out that no
collision-free scheme is possible absent a cryptographic hash, which is
an appeal to authority ("we can't use a cryptographic hash on
constrained systems") that does not attempt to answer the question of
whether it is actually reasonable to use a mechanism that allows
collisions for this purpose (vs. just not being able to do anything).
Additionally, there is not any discussion of second-preimage resistance,
which is the more important property here, in terms of an attacker being
able to construct a collision with an existing HIT of an honest node.

In a related vein, Section 3.2.1 claims that the above concerns can be
remediated by deployment of a collision detection scheme, "achieved here
through either an ACL or some other lookup process".  This process is
vital to the security of the system as a whole, and it would be
irresponsible to publish this document without a precise specification
of what properties are needed in order to perform this process, as well
as a worked example that can be used absent other considerations.

Given that the applicability statement ("in communicating with such
constrained devices") implies that there is intent to have full-featured
nodes that implement both HIP DEX and HIP BEX, I think we need
significantly more discussion of how such nodes avoid using DEX in
situations where it was not appropriate.  That is, how is it known that
the peer should be using DEX vs. BEX?  Yes, the HIT includes an
indication of whether the identity is for use with DEX vs. BEX, but that
does not seem like quite the relevant property.  Do we envision
scenarios where a node is positioned somewhat like a gateway, using DEX
on one interface and BEX to the broader internet?

Using AES-CTR with the long-term static-static master key requires
careful tracking of counter (sequence) number to nonvolatile storage.  I
did not see discussion of the security consequences of inadvertent
counter reuse.

I appreciate the design to limit use of the long-term static-static
master key to essentially just key-wrap operations, but this seems to
require the presence of a CSPRNG in order to obtain secure session keys.
Expecting a strong CSPRNG on a node so constrained that DEX is necessary
seems to be a questionable assumption, and I see no discussion of the
need for a good RNG.  (Relying on the full-featured peer to contribute
good entropy to the key derivation is not an option, since DEX is
allowed to be used between two nodes that are both constrained.)

The default KEYMAT algorithm uses the "CKDF" (CMAC-based KDF)
construction, analogous to HKDF (RFC 5869).  However, the paper
motivating 5869's design choices does not seem to justify the usage of
CMAC instead of HMAC, since the proof requires a PRF* but CMAC (with
AES) is only a PRP.  Absent some detailed justification or prior art it
does not seem prudent to use such a novel construction for
security-critical functionality.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Some additional comments (also incomplete), since they were already written.
It would be reasonable to ignore for now any that don't make sense or
are on parts of the text likely to change as a result of the higher-level discussion.

Abstract

My preference is to just use "forward secrecy" rather than "perfect
forward secrecy", as perfection is hard to attain.

Section 1.1

   HIP DEX operationally is very similar to HIP BEX.  Moreover, the
   employed model is also fairly equivalent to 802.11-2007
   [IEEE.802-11.2007] Master Key and Pair-wise Transient Key, but
   handled in a single exchange.

802.11 security does not exactly have a shiny track record...

   HIP DEX does not have the option to encrypt the Host Identity of the
   Initiator in the I2 packet.  The Responder's Host Identity also is
   not protected.  Thus, contrary to HIPv2, HIP DEX does not provide for
   end-point anonymity and any signaling (i.e., HOST_ID parameter
   contained with an ENCRYPTED parameter) that indicates such anonymity
   should be ignored.

What would you do if you didn't ignore such signalling?  Drop the
connection as being with a misbehaving peer?

   As in [RFC7401], data packets start to flow after the R2 packet.  The
   I2 and R2 packets may carry a data payload in the future.  The
   details of this may be defined later.

I'm not sure what value is added by mentioning the possibility of data
payload in I2/R2.

   An existing HIP association can be updated with the update mechanism
   defined in [RFC7401].  Likewise, the association can be torn down
   with the defined closing mechanism for HIPv2 if it is no longer
   needed.  In doing so, HIP DEX omits the HIP_SIGNATURE parameters of
   the original HIPv2 specification.

I think the intent here is more along the lines of "HIP DEX does so even
in the absence of the HIP_SIGNATURE that is used in standard HIPv2".
(I also note that there's some subtle semantic mismatch between DEX as
"diet exchange" and its used to indicate continuing lack of security
functionality throughout the extent of the association, after the
exchange is completed.)

   Finally, HIP DEX is designed as an end-to-end authentication and key
   establishment protocol.  As such, it can be used in combination with

Don't we have a LAKE WG now?  How does DEX compare to what they are
working on?

Section 1.2

In lieu of detailed comments, allow me to propose a rewrite of the whole
section:

% HIP DEX achieves its lightweight nature in large part due to the
% intentional removal of Forward Secrecy (FS) from the key exchange.  Current
% mechanisms to achieve FS use an authenticated ephemeral Diffie-Hellman
% exchange (e.g., SIGMA or PAKE).  HIP DEX targets usage on devices where
% even the most lightweight ECDH exchange is prohibitively expensive for
% recurring (ephemeral) use.  For example, experience with the 8-bit
% 8051-based ZWAWVE ZW0500 microprocessor has shown that EC25519 keypair
% generation exceeds 10 seconds and consumes significant energy (i.e.,
% battery resources).  Even the ECDH multiplication for the HIP DEX
% static-static key exchange takes 8-9 seconds, again with measurable
% energy consumption.  This resource consumption is tolerable as a
% one-time event during provisioning, but would render the protocol
% unsuitable for use on these devices if it was required to be a
% recurring part of the protocol.  For devices constrained in this
% manner, a FS-enabled protocol will likely provide little gain.  The
% resulting "FS" key, likely produced during device provisioning, would
% typically end up being used for the remainder of the device's
% lifetime.  With such a usage pattern, the inherent benefit of
% ephemeral keys is not realized.  The security properties of such usage
% are very similar to those of using a statically provisioned symmetric
% pre-shared key, in that there remains a single PSK in static storage
% that is susceptible to exfiltration/compromise, and compromise of that
% key in effect compromises the entire protocol for that node.  HIP DEX
% achieves marginally better security properties by computing the
% effective long-term PSK from a DH exchange, so that the provisioning
% service is not required to be part of the risk surface due to also
% possessing the PSK.
%
% Due to the substantially reduced security guarantees of HIP DEX
% compared to HIP BEX, HIP DEX MUST only be used when at least one of
% the two endpoints is a class 0 or 1 constrained device defined in
% Section 3 of [RFC7228]).  HIP DEX MUST NOT be used when both endpoints
% are class 2 devices or unconstrained.

Section 2.2

   Ltrunc (M(x), K)   denotes the lowest order K bits of the result of
      the MAC function M on the input x.

I'm not sure I'm going to interpret the "lowest order K bits" the same
way that everyone else will.  I think "leftmost" or "first" are more
common terms for describing this sort of truncation.

Section 2.3

   CMAC:  The Cipher-based Message Authentication Code with the 128-bit
      Advanced Encryption Standard (AES) defined in RFC 4493 [RFC4493].

I would suggest just using CMAC as the acronym and not trying to
overload it to also be AES-specific.

   HIT Suite:  A HIT Suite groups all algorithms that are required to
      generate and use an HI and its HIT.  In particular, these
      algorithms are: 1) ECDH and 2) FOLD.

For DEX.  For normal HIPv2 we wouldn't touch FOLD with a long pole.

   HI (Host Identity):  The static ECDH public key that represents the
      identity of the host.  In HIP DEX, a host proves ownership of the
      private key belonging to its HI by creating a HIP_MAC with the
      derived ECDH key (see Section 3).

This may sound pedantic, but this doesn't actually prove ownership of
the private key.  Someone who knows the private key of the other party
and the public key of the host in question would be able to produce the
same MAC from the corresponding derived ECDH key.  I think the most we
can say here is that a host authenticates itself as that host identity
[with that HIP_MAC].  There's the corresponding trust of the recipient
that its own private key remains secure and thus that no party other
than itself or the peer identity could have generated that message.

   Initiator:  The host that initiates the HIP DEX handshake.  This role
      is typically forgotten once the handshake is completed.

"typically"?  Perhaps it's best to say that the role is not used or
needed after the handshake is completed.

   KEYMAT:  Keying material.  That is, the bit string(s) used as
      cryptographic keys.

I'm surprised we need an abbreviation for this.

   Length of the Responder's HIT Hash Algorithm (RHASH_len):  The
      natural output length of RHASH in bits.

[this doesn't really fit the pattern of "definition"s]

   Responder:  The host that responds to the Initiator in the HIP DEX
      handshake.  This role is typically forgotten once the handshake is
      completed.

[same thing re "typically"]

Section 3

   HIP DEX implementations MUST support the Elliptic Curve Diffie-
   Hellman (ECDH) [RFC6090] key exchange for generating the HI as
   defined in Section 5.2.3.  No additional algorithms are supported at
   this time.

It's kind of weird to see a "MUST" for "RFC6090 key exchange"; 6090
discusses the general class of things but is not a specific key exchange
algorithm (e.g., curve).
I'd also consider s/supported/defined/.

   Due to the latter property, an attacker may be able to find a
   collision with a HIT that is in use.  Hence, policy decisions such as
   access control MUST NOT be based solely on the HIT.  Instead, the HI
   of a host SHOULD be considered.

I don't think this is correct or a strong enough statement.  In
particular, I don't think access control should be based on the HIT at
all, so strike "solely".  Also, the "SHOULD" seems too week.  I can
understand that "MUST use the HI" could be overly constraining, but
"access control decisions MUST be made on the actual identity of the
host, e.g., the full HI" should allow for sufficient flexibility.

   Carrying HIs and HITs in the header of user data packets would
   increase the overhead of packets.  Thus, it is not expected that

s/and/or/?

   association.  When other user data packet formats are used, the
   corresponding extensions need to define a replacement for the
   ESP_TRANSFORM [RFC7402] parameter along with associated semantics,
   but this procedure is outside the scope of this document.

Why is ESP_TRANSFORM the most important parameter here, when we talk
about mapping a packet to the HIP association?  I thought ESP_TRANSFORM
was literally about the encryption mechanics, not metadata around it.

Section 3.2

ORCHID claims to provide statistical uniqueness and routability at some
overlay layer, neither of which this FOLD procedure provides, due to
easily-generatable second preimages.

Section 3.2.1

   Since collision-resistance is not possible with the tools at hand,
   any reasonable function (e.g.  FOLD) that takes the full value of the
   HI into generating the HIT can be used, provided that collision
   detection is part of the HIP-DEX deployment design.  This is achieved

This is not an argument that this is a reasonable thing to do; it's
merely an argument that it's a thing that can be done that has the same
claimed properties as the only type of thing that could be done.  It
might be a bad idea to do the only type of thing that can be done, and
you have not convinced me otherwise.  (See also the distinction between
collision-resistance and second-preimage-resistance alluded to in my
comment on the previous section.)

   here through either an ACL or some other lookup process that
   externally binds the HIT and HI.

Without at least one well-specified mechanism for actually doing this
and clear documentation of what precise properties such a mechanism
needs to provide, I think it's irresponsible to publish this document.

Section 4.1

   By definition, the system initiating a HIP Diet EXchange is the
   Initiator, and the peer is the Responder.  This distinction is
   typically forgotten once the handshake completes, and either party
   can become the Initiator in future communications.

["typically" again]

   Diffie-Hellman Group IDs supported by the Initiator.  Note that in
   some cases it may be possible to replace this trigger packet by some
   other form of a trigger, in which case the protocol starts with the
   Responder sending the R1 packet.  In such cases, another mechanism to
   convey the Initiator's supported DH Groups (e.g., by using a default
   group) must be specified.

This seems under-specified for a proposed standard and is probably
better off omitted entirely.

   The second packet, R1, starts the actual authenticated Diffie-Hellman
   key exchange.  It contains a puzzle - a cryptographic challenge that
   the Initiator must solve before continuing the exchange.  The level
   of difficulty of the puzzle can be adjusted based on level of trust
   with the Initiator, current load, or other factors.  In addition, the

The Initiator is unauthenticated at this point, so "level of trust"
seems to not really be defined...

Section 4.1.1

If an unconstrained (DoSing) attacker is competing with a constrained
honest initiator to solve puzzles during an attack, it seems like the
honest initiator is going to lose out pretty badly.

Section 4.1.4

There are security considerations for serializing the HIP state to
nonvolatile storage!

--
Standard Robert Moskowitz
Owner
HTT Consulting
C:      248-219-2059
F:      248-968-2824
E:      rgm@labs.htt-consult.com

There's no limit to what can be accomplished if it doesn't matter who gets the credit
--------------312EB6EA53320246E053E15C-- From nobody Wed Mar 4 10:11:27 2020 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 61F463A13EF; Wed, 4 Mar 2020 10:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kaloom.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 kGwQbJ-PBI0f; Wed, 4 Mar 2020 10:11:19 -0800 (PST) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670109.outbound.protection.outlook.com [40.107.67.109]) (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 3B5863A13EA; Wed, 4 Mar 2020 10:11:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=X6Aa5nvr8efpHl0cpB+rDEkh8SHIYOFQMYSP4b7RyM6qY00uUsVU4fxBawr/sgidCoEIPyvQ8/i//NS3AOEkFn7zvzMT4Apbv9A3aGayWS35/8dIDyXz3fzwdMzR+mdKd357iESZDqrnbskCLa4h1VqKmWAAEJ/hnoXwBKLANohLGsZX2tuo3cTccBlKGEpcsfX0ooi5RDhkw7s5S72B0BfgGaSFSfDvDoDo3ma1eRd2Ndz1aOrBBSz9cFblPx+lMjfkEydtY4rQUGgAyqf150leQRL/0J1rFh2HpG/nF7e8vFgE1E1S4IXiMn9yiXoEl6C8dp/ZwYx4Zvuv9eKEFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gmmfLZ5fQ8I7rPTyCyVtlJc5WdJPEo4qJyuR5pexpPM=; b=jaU547vEZ4ITk+N08v7MkV47HYlaFTSKYm4BHhdYngHO8iqpE/ezvOrcv2IievipgxwdjFdydeJH71A4F71FzNTTq5q3UbgUQhk9kOT/cBOJaW2SNx75b3aqtmFG5WFRleQNCob+dHnA3GIlS+yj6IKR+3Y8XRYRUoXusDOUgxMMY5l49VXWWrCChWarVQL+jYYqMe8FqyFsj6CLdJdZBxyZkYWMlRKmdjCZHXq8S14MDJNMfSOG1znd5F7Io3f2EAOGSrUeazHiCMo8UNTk+qNA0mTGY8qBfCVdARjzBeRrNFLqW4B0Oaw5uFf+nNsuFuTI7EkYzxzl4FCmHWBrMw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=kaloom.com; dmarc=pass action=none header.from=kaloom.com; dkim=pass header.d=kaloom.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaloom.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gmmfLZ5fQ8I7rPTyCyVtlJc5WdJPEo4qJyuR5pexpPM=; b=aS+TDsgkjHReUN5B9GkOLv1EO1mDkVydOdvhXF1ZDNN4UkTMs511cUx+E5/cvU+36YL24g3jbF/j+6Q8I0Jg/iJRjLikFqsN3DEVEsb3R8dQcbhCojDVTauFDRGD86cnLHkeW8Z9inBHIBn64mK4YS+9yEYluluIDYs8LdcuoPA= Received: from QB1PR01MB3219.CANPRD01.PROD.OUTLOOK.COM (52.132.84.225) by QB1PR01MB2418.CANPRD01.PROD.OUTLOOK.COM (52.132.84.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15; Wed, 4 Mar 2020 18:11:16 +0000 Received: from QB1PR01MB3219.CANPRD01.PROD.OUTLOOK.COM ([fe80::88eb:95a3:1188:b54a]) by QB1PR01MB3219.CANPRD01.PROD.OUTLOOK.COM ([fe80::88eb:95a3:1188:b54a%6]) with mapi id 15.20.2772.019; Wed, 4 Mar 2020 18:11:16 +0000 From: Suresh Krishnan To: Robert Moskowitz CC: Jeff Ahrenholz , Robert Moskowitz , The IESG , "draft-ietf-hip-dex@ietf.org" , "hipsec@ietf.org" , "hip-chairs@ietf.org" , Gonzalo Camarillo Thread-Topic: [Hipsec] Suresh Krishnan's Discuss on draft-ietf-hip-dex-13: (with DISCUSS) Thread-Index: AQHV8ieJ/KY/NzbOrUi2xrBWanKnkag4lbiAgAAEbACAACIjgA== Date: Wed, 4 Mar 2020 18:11:16 +0000 Message-ID: References: <158329724383.7687.5696211532188484676@ietfa.amsl.com> <820F683A-84D6-4BC2-B980-04DD45191EFA@tempered.io> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Suresh@kaloom.com; x-originating-ip: [49.206.124.53] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7b14ba25-21b1-435c-571f-08d7c0676e69 x-ms-traffictypediagnostic: QB1PR01MB2418: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0332AACBC3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39850400004)(376002)(346002)(136003)(366004)(189003)(199004)(66476007)(91956017)(53546011)(6506007)(2906002)(76116006)(66446008)(64756008)(8936002)(6916009)(86362001)(33656002)(36756003)(8676002)(966005)(66946007)(66556008)(508600001)(26005)(55236004)(81166006)(6512007)(4326008)(186003)(81156014)(54906003)(316002)(6486002)(5660300002)(2616005)(71200400001); DIR:OUT; SFP:1102; SCL:1; SRVR:QB1PR01MB2418; H:QB1PR01MB3219.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: kaloom.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RpBIl4gcX1pyHCYUtslDkV0en1zHKdS/7s+99OWkLoeDGenwlRI2+QbMa7KvAl5+RRxVZDN/QjulZuF9sW3VzKxbDyPo2DFmw7lxZpYMlHl0ZPh2R/PSMv+69g51+iVGlMkBjNlAYa7t+ssf8DHqkbixCFGFcJMm49YO1YsvJgMqrEGhArip88z6JjF48fMJGB6mJN8sZGd/djNDiq2QDC0F9WdV46Si5jix7MhYZg+xTkLd9FYs311vgqi0h4KK8qAIpSU8n3gZSvwdQilQSo+0TP4r+WmrDLzlzt5uKNBCDsb7UtUzEJw0paP7dEXf7NkjSrkDNfPOcBunOaY64RHyxiOXgNaudnfPQDXc7uVrrNOhUxhaVZ0fczO0ih3QxO2PvFh9f2V3FzLkJvaC0qh9xPkoyuupD/YlHlOzhxtX8mJwRBDOq/xkxaneaVtSIL0/46+9LpxvsLKxdbG54uyuxn4D8nwmaLYM6Z99rTK97qiKCF3tDZkLY67YOhCPeHryJhgaaVCP7qZU+F4/oQ== x-ms-exchange-antispam-messagedata: TeCAQzST3zsh1IPe/d9MWcjgP+7gPexmCQS5ErBBrXgqSYko3wB3U6sBVvZzxUKRGWUFlibPpPpIstZcawIndJKvCHRag0tDA6x+ywbYUuxgfnfxijtbB3b8WeLGR31JmrTP3bJEvvG+irkmnibDtw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: <25A155C07E431F40AFA85052486C9345@CANPRD01.PROD.OUTLOOK.COM> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: kaloom.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7b14ba25-21b1-435c-571f-08d7c0676e69 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2020 18:11:16.1996 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 47d58e26-f796-48e8-ac40-1c365c204513 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: lm7GHjFGqeVS+EHzy+31YbyCjU7Eq5HFwASSPnOam8SdiYlETlG77amhE8UCStaz0szpTQBmVJ8z9eID6ERc4w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: QB1PR01MB2418 Archived-At: Subject: Re: [Hipsec] Suresh Krishnan's Discuss on draft-ietf-hip-dex-13: (with DISCUSS) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 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: Wed, 04 Mar 2020 18:11:25 -0000 Hi Bob/Jeff, > On Mar 4, 2020, at 11:09 AM, Robert Moskowitz wrote= : >=20 >=20 >=20 > On 3/4/20 10:53 AM, Jeff Ahrenholz wrote: >>> https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xh= tml#icmpv6-parameters-codes-5 >>>=20 >>> And nothing there that looks right. >>>=20 >>> So what is done in HIP BEX implementations? Both v1 and v2? >> For our HIPv1 implementation: >> IPv4 packets - we send ICMPv4-in-UDP with type 12 "parameter problem" co= de 0 "pointer indicates the error" and point to the first bytes of UDP payl= oad. (https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtm= l#icmp-parameters-codes-12) >>=20 >> IPv6 packets - we send ICMPv6-in-UDP with type 4 "parameter problem" cod= e 0 "erroneous header field encountered" and point to the first bytes of UD= P payload. >>=20 >> Normally this would be if the SPI is unknown (e.g. one side forcefully r= eboots while the other continues to send it ESP-in-UDP data.) The pointer i= ncludes the first 8 bytes of the UDP payload so that the SPI is included in= the ICMP message. >>=20 >> For IPv6 you could consider the "erroneous header field" to be the inval= id SPI number, which is the bytes we point to. >>=20 >> -Jeff >>=20 >=20 > Suresh, >=20 > How would you recommend handling this? It seems the text in all docs (52= 01, 7401, and DEX) might be: >=20 > In most cases, the ICMP packet has the Parameter Problem type (12 for ICM= Pv4, 4 with code=3D0 for ICMPv6), I am happy with the Code being set to 0 for ICMPv6 and the Pointer being se= t as Jeff proposed above. Regards Suresh From nobody Wed Mar 4 10:28:10 2020 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 3AA993A143C; Wed, 4 Mar 2020 10:28:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-hip-dex@ietf.org, hip-chairs@ietf.org, hipsec@ietf.org, Gonzalo Camarillo , gonzalo.camarillo@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <158334648514.29413.16902420341202011591@ietfa.amsl.com> Date: Wed, 04 Mar 2020 10:28:05 -0800 Archived-At: Subject: [Hipsec] Roman Danyliw's Discuss on draft-ietf-hip-dex-13: (with DISCUSS and COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 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: Wed, 04 Mar 2020 18:28:05 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-hip-dex-13: Discuss 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-dex/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (initial ballot now that this draft is deferred) ** Section 1.2. Thanks for the scoping provided by this applicability statement. Given the reduced security that DEX will provide, IMO it needs a bit more precision (and caution). OLD HIP DEX MUST only be used in communicating with such constrained devices (e.g., class 0 and 1 devices as defined in section 3 in [RFC7228]). NEW HIP DEX MUST only be when one of the peers if a class 0 or 1 constrained device as defined in Section 3 of [RFC7228]. HIP DEX MUST NOT be used if both peers are class 2 constrained devices or have greater capability. ** Section 3.2.1, Per “Since collision-resistance is not possible with the tools at hand, any reasonable function (e.g. FOLD) that takes the full value of the HI into generating the HIT can be used, provided that collision detection is part of the HIP-DEX deployment design. This is achieved here through either an ACL or some other lookup process that externally binds the HIT and HI.”, when exactly should this ACL lookup occur? Please provide guidance in an explicit step in the appropriate packet processing section (i.e., in Section 6.*) on when this should be. ** Section 5.2.1 – Is this list of DH Group IDs intended to be a subset of the HIP Group ID sub-registry? If so, Curve25519 and Curve448 don’t appear to be in the https://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml#hip-parameters-5? Should they be registered? ** Section 6.3. Per “Some payload protection mechanisms have their own Key Derivation Function, and if so this mechanism SHOULD be used.”, if the payload protection mechanisms have their own KDF, how would their security properties be trusted if their KDF is NOT used? Why is this SHOULD not a MUST? ** Section 6.3. The input to CKDR-Extract seems underspecified: -- Per the definition of IKM, when should these different inputs be used (at least two appear to be specified)? References to Kij are made in this section and in other parts of the document, but they aren’t input for CKDR-Extract()? -- Per “where ‘CKDF-Extract’ is an octet string “ in the definition of “info” in CKDR-Extract(), what encoding should be used to convert that into an octet string? Is it ASCII, as in 067 075 068 070 045 069 120 116 114 097 099 116? ** Section 9. Please add language to the effect that “production deployments of this specification MUST NOT use the NULL-ENCRYPT HIP_CIPHER” (to mirror the language already stated in Section 5.2.2 on the topic). ** Section 9.2. This mandatory guidance to validate public keys is helpful. Please provide guidance in an explicit step in the appropriate packet processing section (i.e., in Section 6.*) on when this should be done. Two “discuss discuss”-es with the caveat that I didn’t follow the WG discussions. ** The following seems to indicate we don’t have everything we need to publish a standards track document: -- Section 6. “It should be noted that many of the packet processing rules are denoted here with "SHOULD" but may be updated to "MUST" when further implementation experience provides better guidance.” -- Section 9. “o The puzzle mechanism using CMAC explained in Section 4.1.1 may need further study regarding the level of difficulty in order to establish best practices with current generation of constrained devices.” If there isn’t sufficient implementation experience, why isn’t this document experimental? What is the plan for getting better guidance? Is there a risk in not having this clarity? ** Section 9.1. Thanks for this section. However, I’m not convinced that SECP160R1 is needed. DEX is already selectively profiling RFC7401 (i.e., its already choosing to exclude certain things) and there are “no production” implementation of DEX. What is the rationale for keeping it? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ** Section 3.0. Per “Thus, it is not expected that these parameters are carried in every packet, but other methods are used to map the data packets to the corresponding His”, what are these other methods? ** Section 3.1. Per “There are two advantages of using a hashed encoding over the actual variable-sized public key in protocols.”, perhaps as a reminder is in order that in this document the HIT isn’t a hashed encoding but a compressed. ** Section 4.1. Per “Note that in some cases it may be possible to replace this trigger packet by some other form of a trigger, in which case the protocol starts with the Responder sending the R1 packet.”, how does this additional trigger occur? ** Section 4.1. Per “In such cases, another mechanism to convey the Initiator's supported DH Groups (e.g., by using a default group) must be specified.”, where/how would it be specified? ** Section 4.1.2.1. Per “This strategy is based on a timeout that is set to a value larger than the worst-case anticipated round-trip time (RTT ).”, how is the worst case RTT computed? ** Section 5.3.2. Per “Responder sets the source HIT in the R2 packet based on the destination HIT from the I1 packet”, shouldn’t this say “Responder sets the source HIT in the _R1_ packet …”? ** Section 5.3.2. Per “Based on the deviating DH group ID in the HOST_ID parameter, the Initiator then SHOULD abort …”, why not MUST abort? ** Section 6.8. Step 5. Per “5. If any of the checks above fail, there is a high probability of an ongoing man-in-the-middle or other security attack. The system SHOULD act accordingly, based on its local policy.”, this guidance seems underspecified. Could the text at least provide a recommendation of aborting and logging? ** Section 9. Per “The strength of the keys for the Pair-wise Key SA is based on the quality of the random keying material. As either peer may be a sensor or an actuator device, there is a natural concern about the quality of its random number generator.”, this is helpful caution. What guidance can be given to ameliorate the concern? ** Editorial -- Section 1.2. The sentence “Also, it is often the case that HIP DEX …” is repeated twice. -- Section 4.1. s/the the/the/ -- Section 6.3. Typo. s/The HIP DEX KEYMAT process is based on the is the/ The HIP DEX KEYMAT process is based on the/ -- Section 9.2. Editorial. Per “With the curves specified here, there is a straightforward key extraction attack, which is a very serious problem the use of static keys in HIP-DEX”, there appears to be some missing words – perhaps “… with the use of static keys by HIP-DEX”. From nobody Wed Mar 4 10:28:52 2020 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 395A43A143D; Wed, 4 Mar 2020 10:28:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-hip-dex@ietf.org, hip-chairs@ietf.org, hipsec@ietf.org, Gonzalo Camarillo , gonzalo.camarillo@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <158334652621.29471.12249385526499303915@ietfa.amsl.com> Date: Wed, 04 Mar 2020 10:28:46 -0800 Archived-At: Subject: [Hipsec] Roman Danyliw's Discuss on draft-ietf-hip-dex-13: (with DISCUSS and COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 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: Wed, 04 Mar 2020 18:28:47 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-hip-dex-13: Discuss 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-dex/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (initial ballot now that this draft is deferred) ** Section 1.2. Thanks for the scoping provided by this applicability statement. Given the reduced security that DEX will provide, IMO it needs a bit more precision (and caution). OLD HIP DEX MUST only be used in communicating with such constrained devices (e.g., class 0 and 1 devices as defined in section 3 in [RFC7228]). NEW HIP DEX MUST only be used when one of the peers is a class 0 or 1 constrained device as defined in Section 3 of [RFC7228]. HIP DEX MUST NOT be used if both peers are class 2 constrained devices or have greater capability. ** Section 3.2.1, Per “Since collision-resistance is not possible with the tools at hand, any reasonable function (e.g. FOLD) that takes the full value of the HI into generating the HIT can be used, provided that collision detection is part of the HIP-DEX deployment design. This is achieved here through either an ACL or some other lookup process that externally binds the HIT and HI.”, when exactly should this ACL lookup occur? Please provide guidance in an explicit step in the appropriate packet processing section (i.e., in Section 6.*) on when this should be. ** Section 5.2.1 – Is this list of DH Group IDs intended to be a subset of the HIP Group ID sub-registry? If so, Curve25519 and Curve448 don’t appear to be in the https://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml#hip-parameters-5? Should they be registered? ** Section 6.3. Per “Some payload protection mechanisms have their own Key Derivation Function, and if so this mechanism SHOULD be used.”, if the payload protection mechanisms have their own KDF, how would their security properties be trusted if their KDF is NOT used? Why is this SHOULD not a MUST? ** Section 6.3. The input to CKDR-Extract seems underspecified: -- Per the definition of IKM, when should these different inputs be used (at least two appear to be specified)? References to Kij are made in this section and in other parts of the document, but they aren’t input for CKDR-Extract()? -- Per “where ‘CKDF-Extract’ is an octet string “ in the definition of “info” in CKDR-Extract(), what encoding should be used to convert that into an octet string? Is it ASCII, as in 067 075 068 070 045 069 120 116 114 097 099 116? ** Section 9. Please add language to the effect that “production deployments of this specification MUST NOT use the NULL-ENCRYPT HIP_CIPHER” (to mirror the language already stated in Section 5.2.2 on the topic). ** Section 9.2. This mandatory guidance to validate public keys is helpful. Please provide guidance in an explicit step in the appropriate packet processing section (i.e., in Section 6.*) on when this should be done. Two “discuss discuss”-es with the caveat that I didn’t follow the WG discussions. ** The following seems to indicate we don’t have everything we need to publish a standards track document: -- Section 6. “It should be noted that many of the packet processing rules are denoted here with "SHOULD" but may be updated to "MUST" when further implementation experience provides better guidance.” -- Section 9. “o The puzzle mechanism using CMAC explained in Section 4.1.1 may need further study regarding the level of difficulty in order to establish best practices with current generation of constrained devices.” If there isn’t sufficient implementation experience, why isn’t this document experimental? What is the plan for getting better guidance? Is there a risk in not having this clarity? ** Section 9.1. Thanks for this section. However, I’m not convinced that SECP160R1 is needed. DEX is already selectively profiling RFC7401 (i.e., its already choosing to exclude certain things) and there are “no production” implementation of DEX. What is the rationale for keeping it? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ** Section 3.0. Per “Thus, it is not expected that these parameters are carried in every packet, but other methods are used to map the data packets to the corresponding His”, what are these other methods? ** Section 3.1. Per “There are two advantages of using a hashed encoding over the actual variable-sized public key in protocols.”, perhaps as a reminder is in order that in this document the HIT isn’t a hashed encoding but a compressed. ** Section 4.1. Per “Note that in some cases it may be possible to replace this trigger packet by some other form of a trigger, in which case the protocol starts with the Responder sending the R1 packet.”, how does this additional trigger occur? ** Section 4.1. Per “In such cases, another mechanism to convey the Initiator's supported DH Groups (e.g., by using a default group) must be specified.”, where/how would it be specified? ** Section 4.1.2.1. Per “This strategy is based on a timeout that is set to a value larger than the worst-case anticipated round-trip time (RTT ).”, how is the worst case RTT computed? ** Section 5.3.2. Per “Responder sets the source HIT in the R2 packet based on the destination HIT from the I1 packet”, shouldn’t this say “Responder sets the source HIT in the _R1_ packet …”? ** Section 5.3.2. Per “Based on the deviating DH group ID in the HOST_ID parameter, the Initiator then SHOULD abort …”, why not MUST abort? ** Section 6.8. Step 5. Per “5. If any of the checks above fail, there is a high probability of an ongoing man-in-the-middle or other security attack. The system SHOULD act accordingly, based on its local policy.”, this guidance seems underspecified. Could the text at least provide a recommendation of aborting and logging? ** Section 9. Per “The strength of the keys for the Pair-wise Key SA is based on the quality of the random keying material. As either peer may be a sensor or an actuator device, there is a natural concern about the quality of its random number generator.”, this is helpful caution. What guidance can be given to ameliorate the concern? ** Editorial -- Section 1.2. The sentence “Also, it is often the case that HIP DEX …” is repeated twice. -- Section 4.1. s/the the/the/ -- Section 6.3. Typo. s/The HIP DEX KEYMAT process is based on the is the/ The HIP DEX KEYMAT process is based on the/ -- Section 9.2. Editorial. Per “With the curves specified here, there is a straightforward key extraction attack, which is a very serious problem the use of static keys in HIP-DEX”, there appears to be some missing words – perhaps “… with the use of static keys by HIP-DEX”. From nobody Wed Mar 4 21:07:12 2020 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 313273A0C32; Wed, 4 Mar 2020 21:07:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-hip-native-nat-traversal@ietf.org, hip-chairs@ietf.org, hipsec@ietf.org, Gonzalo Camarillo , gonzalo.camarillo@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <158338482498.29408.1849982962699257652@ietfa.amsl.com> Date: Wed, 04 Mar 2020 21:07:05 -0800 Archived-At: Subject: [Hipsec] Barry Leiba's No Objection on draft-ietf-hip-native-nat-traversal-30: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 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, 05 Mar 2020 05:07:06 -0000 Barry Leiba has entered the following ballot position for draft-ietf-hip-native-nat-traversal-30: 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-native-nat-traversal/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Given this document’s dependency on concepts and terminology from 5770, I think that document has to be a normative reference. Can someone really understand and implement this without any reference to 5770? — Abstract — The main difference from the previously specified modes is the use of HIP messages instead of ICE for all NAT traversal procedures due to its kernel-space dependencies. The antecedent to “its” is unclear: it could be “use of HIP messages”, or “ICE”, or “NAT traversal”. Please rephrase to clarify. — Section 1 — Also, especially NATs usually require the host behind a NAT to create a forwarding state in the NAT before other hosts outside of the NAT can contact the What does “especially” mean in this sentence? It doesn’t make sense to me. Does it add anything? which will be referred as "Legacy ICE-HIP" in this document. Nit: “referred to” HIP poses a unique challenge to using standard ICE, due not only to its kernel-space implementation, but also due to its close Same comment about “its” as in the abstract: please replace “its” with what you’re talking about, as it isn’t clear. From nobody Thu Mar 5 03:08:12 2020 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 C84E83A12BF; Thu, 5 Mar 2020 03:08:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Westerlund via Datatracker To: "The IESG" Cc: draft-ietf-hip-native-nat-traversal@ietf.org, hip-chairs@ietf.org, hipsec@ietf.org, Gonzalo Camarillo , gonzalo.camarillo@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <158340648969.14566.11476213026719970345@ietfa.amsl.com> Date: Thu, 05 Mar 2020 03:08:09 -0800 Archived-At: Subject: [Hipsec] Magnus Westerlund's Discuss on draft-ietf-hip-native-nat-traversal-30: (with DISCUSS and COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 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, 05 Mar 2020 11:08:10 -0000 Magnus Westerlund has entered the following ballot position for draft-ietf-hip-native-nat-traversal-30: Discuss 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-native-nat-traversal/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- So I think the below are important things that needs to be discussed before proceeding. However, I might have missed things as I didn't have time to read the whole document in detail. Several of the issues are pieces for discussion to ensure that the right thing really is done. 1. So this document recommends the usage of port 10500 as default listening port. A port registered by Ari and also used for RFC 5770. I get the impression that the port was registered separately from RFC 5770. So the port is assigned to Ari. Would Ari be willing to release the port for re-assignment to IESG control. RFC 6335 has the recommendation for ports for IETF protocols that the assignee is IESG and the contact chair@ietf.org. This to have the change control with IETF as body rather than with individuals. If Ari agrees to this, I think it would be good to have the IANA section be updated to note the re-assignment and provide the necessary information. 2. Secondly, as this solution is different from the RFC 5770 should this solution have a different service name? The reason I am asking is that it depends on how for example how an initiator determine which of the NAT traversal solution. If there is any intention to use DNS SRV for example different service name would make sense. This is primarily to verify that this has been considered. 3. So I don't quite understand what the co-existance story are for the relay having an listener on port 10500? Is that port only used for UDP/HIPv1 (RFC5770) and UDP/HIPv2 (This doc). And the listening stack can determine which version is used to determine which of the protocol is run. And the issue with multiplexing is only existing for the ports that one gathers? Can you please add a paragraph or two somewhere in the document. I think it should be referenced by the port registration update. 4. MTU impact of NAT traversal. Section 5.1 states "It is worth noting that UDP encapsulation of HIP packets reduces the Maximum Transfer Unit (MTU) size of the control plane by 12 bytes." There is also a similar text in Section 5.11: It is worth noting that UDP encapsulation of ESP reduces the MTU size of data plane by 8 bytes. I think the document needs a discussion and impact on MTU which this NAT traversal has on the HIP packets being sent. - First of all there appears to be more packet expansions happening in some cases, for example the RELAY_HMAC option expands packets on one leg. - Secondly, HIP requires IP fragementation support, however IP fragmentation through NAT is commonly not working. Thus an HIP packet being UDP encapsulated that results in packet exceeding MTU will likely end up in an MTU black hole on path. The addition of the NAT traversal encapsulation actually increases the need for MTU discovery or care in MTU handling by the HIP initiator. I think there need to be discussion of that in the document. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- May I inquire about the reasoning why this document do not obsolete RFC 5770? From nobody Thu Mar 5 04:13:57 2020 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 65A263A13BB; Thu, 5 Mar 2020 04:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 fL8qn-VlwnOY; Thu, 5 Mar 2020 04:13:42 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2086.outbound.protection.outlook.com [40.107.21.86]) (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 6F5213A13C5; Thu, 5 Mar 2020 04:13:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HTgofXPyK6X2xjZGLPpiOPMQLQ6L8dEzpUP1183w2uX3olaQQvuhpBtqUHoDiBTLOJu8nUwA9fvkbsbzvFcM4jh68A6nhH3vXMCd6g3Nx2U/BW+8ulI5Ez58wixQFU3sX9pU1dNE5stBOmmdYq3Inj9zI1xDdtsSycfj8yGiHujOh1izKuLf/p6/vC9FYK8HqheQAcjDrCOogFaXwYqpbVL+YqThyGm5ES6d4IWwL9qMsK/9s5VKKH3EfGpWMDHS5qp6ssg2mhGNOTWw6oOpkDg3+R0fqoNA+LUgOjZttIdyx9THdpKB7gViBEobrrlTo+87VZ09+aaeH9y5d4t8Vg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tJ8B4G97Eos6aVyB7Y82o1DEBsHSr7Q1TPrxbNYieeY=; b=XEKYWE3lfLNBCuht0L/Qxu8Vl+3BRKDxJkMth8VX2i4SSR5XjdS2piNfqPw9c+tdKcZlaaCgD033lS4oBTVBE7cCpeQ2LhIT/vLt9Xtq9KHA+tKCPmtL5HFyabo2dgT7POnN1WAdFJdYnOtatUrgXxhZoH6Ga58KB8Vwk9nCHg0ZlJS8XbUGFQWmON8QEMLQnfpQ1OpWQvdwfa2v1tJP+LwqABpIZsmTZG59CAojDLYVklyl4/QNiSk/AZtI+8SY4V4BuTEAdiXxzndLkJTzQ5j7+YSld6luA3vmv5re3EzeXhAVWdO4a14FvNo/yHWYQpHph4VE9SvWND5iFSR7PA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tJ8B4G97Eos6aVyB7Y82o1DEBsHSr7Q1TPrxbNYieeY=; b=VrXPYNIc7MxkQULq+YAsPX+2fKerKBc5tUs2i6dvbvuVAQ6NdY4kE1U1bybRi7za6rLDJaRe2dbD0S+7mEDUtYDn8YqSGMb2IHmZOksQw5z2iWUR+l1xcMbn7D0ltfSn9HrQ/PWxpyjcb+zCzTX7fxw+RZMz/Zxfp/uV7t/6j08= Received: from HE1PR07MB4236.eurprd07.prod.outlook.com (20.176.166.145) by HE1PR07MB3193.eurprd07.prod.outlook.com (10.170.243.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.5; Thu, 5 Mar 2020 12:13:37 +0000 Received: from HE1PR07MB4236.eurprd07.prod.outlook.com ([fe80::f901:618:7da9:efda]) by HE1PR07MB4236.eurprd07.prod.outlook.com ([fe80::f901:618:7da9:efda%7]) with mapi id 15.20.2793.011; Thu, 5 Mar 2020 12:13:37 +0000 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Magnus Westerlund CC: The IESG , "draft-ietf-hip-native-nat-traversal@ietf.org" , "hip-chairs@ietf.org" , "hipsec@ietf.org" , Gonzalo Camarillo Thread-Topic: Magnus Westerlund's Discuss on draft-ietf-hip-native-nat-traversal-30: (with DISCUSS and COMMENT) Thread-Index: AQHV8t5gh54OXaipAE60Q4kWnBCkxqg555sA Date: Thu, 5 Mar 2020 12:13:37 +0000 Message-ID: <82BD4D83-3256-4DA5-9518-C51DF01BCA39@ericsson.com> References: <158340648969.14566.11476213026719970345@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=ari.keranen@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 97adaffb-cf10-4d9b-9df3-08d7c0fea27d x-ms-traffictypediagnostic: HE1PR07MB3193:|HE1PR07MB3193: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03333C607F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(39860400002)(346002)(136003)(396003)(376002)(189003)(199004)(66476007)(8676002)(66556008)(64756008)(81156014)(81166006)(6512007)(2906002)(186003)(66946007)(450100002)(2616005)(6506007)(85182001)(6636002)(66446008)(33656002)(8936002)(6862004)(966005)(85202003)(76116006)(4326008)(107886003)(6486002)(91956017)(478600001)(71200400001)(316002)(26005)(37006003)(5660300002)(36756003)(54906003)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3193; H:HE1PR07MB4236.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: rlA2GzuuUyqKRqHiRtlhIT/LR6XvyqyjYUpQ7UTMLcM6AcswFJeQd+dwA4RTuX5ipWK/1uOZIMCvroh8phcoPq/6b4G1+nYS0/V6VI90omwVjyNHKFSdsMD+2KWdoA6u8FspPfF6semqGKCQqUGd62vqU+mDuCTADvIJp96vgO6c/Pa+Fom8COOVXr69iWzV3kZuDrS+/gijWgoim1rXt/Y/qkF6LDhYGnzOoMwjRGyHWPzqCa4T4rbWOfI06ewwnh/OfFy5ZLpGgyo/LrLDj5CuXe74RYYjqCsuxWtg2WnDQ2Gd10kOAAFPjmoXbApwbMpIaXJq+a0+bucb8Pp+bPsATqMTfQj5J8OC+mF5WRaAK/cErxmmgw/Jt5lQ+STTh75t6UHve3uQEtRvL3OLUGNKFGB8PgJ2yoNLO9+rEV61gE21Q11PadyxaACJXvWSGTJLdKBd9M8wliH90gShXPZOJeceT0IHrIsLzU58vMn2HbysUqqjhnB2Zg3Q38W90EnozXyrLrEPrCVwnXLoGA== x-ms-exchange-antispam-messagedata: rgGT16sZt51YrCzfP5b1Sx92KAC4/6D5XB+vVNlktOPtmmQqbTQiB4VuDaw8Me6H35tT/Emylo620kKQVwb7f8+mZSES5u19srW61MGV+v6Ze/xbQ2KGMPcGeumiPiD5ybfh2hyZyQek3WXcQDcxZw== Content-Type: text/plain; charset="utf-8" Content-ID: <507A10E2407904468B2ADB5FE7A9DCB4@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 97adaffb-cf10-4d9b-9df3-08d7c0fea27d X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2020 12:13:37.4703 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1nIb6gKDIozqpOt0IentyMnqvtM+U59xXeYanNQV0dOdTv/+xDsOzvDXfb9w1gf80v0SgIpYCEJPGfdHvT/yXAOY2iMxyETClN99mVcjhhg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3193 Archived-At: Subject: Re: [Hipsec] Magnus Westerlund's Discuss on draft-ietf-hip-native-nat-traversal-30: (with DISCUSS and COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 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, 05 Mar 2020 12:13:51 -0000 VGhhbmsgeW91IGZvciB0aGUgcmV2aWV3IE1hZ251cyEgU2VlIGJlbG93IGFuc3dlciB0byB5b3Vy IGZpcnN0IHF1ZXN0aW9uICh0aGUgb3RoZXJzIG5lZWQgYSBiaXQgbW9yZSB0aW1lIHRvIGFuc3dl cikuDQoNCj4gT24gNS4gTWFyIDIwMjAsIGF0IDEzLjA4LCBNYWdudXMgV2VzdGVybHVuZCB2aWEg RGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc+IHdyb3RlOg0KPiANCj4gTWFnbnVzIFdlc3Rl cmx1bmQgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+IGRy YWZ0LWlldGYtaGlwLW5hdGl2ZS1uYXQtdHJhdmVyc2FsLTMwOiBEaXNjdXNzDQo+IA0KPiBXaGVu IHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBs eSB0byBhbGwNCj4gZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGlu ZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCj4gaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93 ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2ll c2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlv biBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRo ZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91 bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1o aXAtbmF0aXZlLW5hdC10cmF2ZXJzYWwvDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g RElTQ1VTUzoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gU28gSSB0aGluayB0aGUgYmVsb3cgYXJl IGltcG9ydGFudCB0aGluZ3MgdGhhdCBuZWVkcyB0byBiZSBkaXNjdXNzZWQgYmVmb3JlDQo+IHBy b2NlZWRpbmcuIEhvd2V2ZXIsIEkgbWlnaHQgaGF2ZSBtaXNzZWQgdGhpbmdzIGFzIEkgZGlkbid0 IGhhdmUgdGltZSB0byByZWFkDQo+IHRoZSB3aG9sZSBkb2N1bWVudCBpbiBkZXRhaWwuIFNldmVy YWwgb2YgdGhlIGlzc3VlcyBhcmUgcGllY2VzIGZvciBkaXNjdXNzaW9uDQo+IHRvIGVuc3VyZSB0 aGF0IHRoZSByaWdodCB0aGluZyByZWFsbHkgaXMgZG9uZS4NCj4gDQo+IDEuIFNvIHRoaXMgZG9j dW1lbnQgcmVjb21tZW5kcyB0aGUgdXNhZ2Ugb2YgcG9ydCAxMDUwMCBhcyBkZWZhdWx0IGxpc3Rl bmluZw0KPiBwb3J0LiBBIHBvcnQgcmVnaXN0ZXJlZCBieSBBcmkgYW5kIGFsc28gdXNlZCBmb3Ig UkZDIDU3NzAuIEkgZ2V0IHRoZSBpbXByZXNzaW9uDQo+IHRoYXQgdGhlIHBvcnQgd2FzIHJlZ2lz dGVyZWQgc2VwYXJhdGVseSBmcm9tIFJGQyA1NzcwLiBTbyB0aGUgcG9ydCBpcyBhc3NpZ25lZA0K PiB0byBBcmkuIFdvdWxkIEFyaSBiZSB3aWxsaW5nIHRvIHJlbGVhc2UgdGhlIHBvcnQgZm9yIHJl LWFzc2lnbm1lbnQgdG8gSUVTRw0KPiBjb250cm9sLiBSRkMgNjMzNSBoYXMgdGhlIHJlY29tbWVu ZGF0aW9uIGZvciBwb3J0cyBmb3IgSUVURiBwcm90b2NvbHMgdGhhdCB0aGUNCj4gYXNzaWduZWUg aXMgSUVTRyBhbmQgdGhlIGNvbnRhY3QgY2hhaXJAaWV0Zi5vcmcuIFRoaXMgdG8gaGF2ZSB0aGUg Y2hhbmdlDQo+IGNvbnRyb2wgd2l0aCBJRVRGIGFzIGJvZHkgcmF0aGVyIHRoYW4gd2l0aCBpbmRp dmlkdWFscy4NCj4gDQo+IElmIEFyaSBhZ3JlZXMgdG8gdGhpcywgSSB0aGluayBpdCB3b3VsZCBi ZSBnb29kIHRvIGhhdmUgdGhlIElBTkEgc2VjdGlvbiBiZQ0KPiB1cGRhdGVkIHRvIG5vdGUgdGhl IHJlLWFzc2lnbm1lbnQgYW5kIHByb3ZpZGUgdGhlIG5lY2Vzc2FyeSBpbmZvcm1hdGlvbi4NCg0K SSBkb24ndCBxdWl0ZSByZW1lbWJlciB0aGUgaGlzdG9yeSBmb3IgdGhpcyBwb3J0IHJlZ2lzdHJh dGlvbiBhbnltb3JlLCBidXQgeWVzLCBJRVNHIGNvbnRyb2wgZm9yIHRoaXMgc291bmRzIGdvb2Qg dG8gbWUuDQogDQoNCkNoZWVycywNCkFyaQ0KDQo= From nobody Thu Mar 5 08:05:28 2020 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 874BC3A16D0; Thu, 5 Mar 2020 08:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 KvV-pYjqoE2A; Thu, 5 Mar 2020 08:05:24 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 CDA803A16D1; Thu, 5 Mar 2020 08:05:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 9338F621FB; Thu, 5 Mar 2020 11:05:21 -0500 (EST) 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 9GBch-bD6oGB; Thu, 5 Mar 2020 11:04:32 -0500 (EST) Received: from lx140e.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 D2E4962156; Thu, 5 Mar 2020 11:04:31 -0500 (EST) To: Suresh Krishnan , The IESG Cc: draft-ietf-hip-dex@ietf.org, hip-chairs@ietf.org, hipsec@ietf.org, Gonzalo Camarillo , j.ahrenholz@tempered.io References: <158329724383.7687.5696211532188484676@ietfa.amsl.com> From: Robert Moskowitz Message-ID: Date: Thu, 5 Mar 2020 11:04:22 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <158329724383.7687.5696211532188484676@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Hipsec] Suresh Krishnan's Discuss on draft-ietf-hip-dex-13: (with DISCUSS) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 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, 05 Mar 2020 16:05:27 -0000 Here is the text I put together for revising sec 5.4 (see below). On 3/3/20 11:47 PM, Suresh Krishnan via Datatracker wrote: > Suresh Krishnan has entered the following ballot position for > draft-ietf-hip-dex-13: Discuss > > 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-dex/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This should be pretty straightforward to resolve. > > * Section 5.4.: > > The ICMPv6 Parameter Problem messages to be sent need a Code field to be set in > addition to the Pointer. What Code should be used in this message? Please > specify this. > > > > > 5.4.  ICMP Messages    When a HIP implementation detects a problem with an incoming packet,    and it either cannot determine the identity of the sender of the    packet or does not have any existing HIP association with the sender    of the packet, it MAY respond with an ICMP packet.  Any such reply    MUST be rate-limited as described in [RFC4443].  In most cases, the    ICMP packet has the Parameter Problem type (12 for ICMPv4, 4 for    ICMPv6) and Code of 0.  The Pointer field pointing to the field that    caused the ICMP message to be generated, for example to the first 8    bytes of a UDP payload for "SPI is Unknown".  The problem cases    specified in Section 5.4. of [RFC7401] also apply to HIP DEX. From nobody Thu Mar 5 08:13:39 2020 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 22B353A175F; Thu, 5 Mar 2020 08:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 9hsghfrDHAAP; Thu, 5 Mar 2020 08:13:30 -0800 (PST) Received: from out.west.exch081.serverdata.net (cas081-co-7.exch081.serverdata.net [199.193.204.188]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F223C3A173E; Thu, 5 Mar 2020 08:13:29 -0800 (PST) Received: from MBX081-W5-CO-2.exch081.serverpod.net (10.224.129.85) by MBX081-W5-CO-1 (10.224.129.84) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 5 Mar 2020 08:13:28 -0800 Received: from MBX081-W5-CO-2.exch081.serverpod.net ([10.224.129.85]) by MBX081-W5-CO-2.exch081.serverpod.net ([10.224.129.85]) with mapi id 15.00.1497.006; Thu, 5 Mar 2020 08:13:28 -0800 From: Jeff Ahrenholz To: Robert Moskowitz , Suresh Krishnan , The IESG CC: "draft-ietf-hip-dex@ietf.org" , "hip-chairs@ietf.org" , "hipsec@ietf.org" , Gonzalo Camarillo Thread-Topic: Suresh Krishnan's Discuss on draft-ietf-hip-dex-13: (with DISCUSS) Thread-Index: AQHV8wfjCPEM4F3esUex4sMd5JPDOag6K/IA Date: Thu, 5 Mar 2020 16:13:28 +0000 Message-ID: References: <158329724383.7687.5696211532188484676@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [216.168.34.194] Content-Type: text/plain; charset="utf-8" Content-ID: <18CFFBE0A4D3474A8A65A315E63A19B4@exch081.serverpod.net> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Hipsec] Suresh Krishnan's Discuss on draft-ietf-hip-dex-13: (with DISCUSS) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 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, 05 Mar 2020 16:13:37 -0000 PiAgSGVyZSBpcyB0aGUgdGV4dCBJIHB1dCB0b2dldGhlciBmb3IgcmV2aXNpbmcgc2VjIDUuNCAo c2VlIGJlbG93KS4NCg0KSXQgc2VlbXMgZ29vZCB0byBtZS4NCg0KLUplZmYNCiANCg0K From nobody Thu Mar 5 11:00:31 2020 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 BA2513A09AF; Thu, 5 Mar 2020 11:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kaloom.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 vU-hpRpxs24j; Thu, 5 Mar 2020 11:00:25 -0800 (PST) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660103.outbound.protection.outlook.com [40.107.66.103]) (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 7C9003A09A9; Thu, 5 Mar 2020 11:00:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Talp6PXFcruZF7mKjDpziJqrVrQT9ahhGEMD+TN4mS6BGXAdC68ygQkXeS9ZnAe0SWq054N4tSt6Hj7t5EFoIz/x1WLq0YmWe+qDkUpr5v34gSI+5a+lFaO+CzFYMveW2X1EchgQQSqfgyt0tdhwdG6zGRS3Ae9U7uGV/o7bf8gV7oLr1Zt0UQ45VZe39KCowXrtXRFL2pm55rhqfUdQ+VI+gJqhes3Jlj4NfJAiTc8CSsRdYhc3yyL5lM4MNaX+54hOwzkSqfu1wKVIYNN50kZK7e+sZSx2l359PT67/zoqYlHziRGAxpoZUeOvvfiDKp+p7EVo5DMHK2cVzBNEYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7C1VhL5MOKXbm6VpeQQrQZQTMK2P1BYIemRMPTK+NuI=; b=YxXgC9gMHbp3W5cHkIOlvLitEeMK9fpsJYXi7/uaPvnfg7Cr6fINPVbb7HaFfXvuCZtNahUdrgzCOD+9RWEab/03ZJ/TltMM2MZiNLuLfwrAovmyRLMcHElmAlVI2xWTTgZ2MOu5oMf9ZLkfcm1VLBXsHM+NhRNMlgjM+ziqvUn1veVBFz5IEtzaW/rvpdgLkvF55G89wI/syf7rv+j+NYOfkzLMdV/nn3w+HkIl9iNktLb/QEoDEIXpKAgCkOXZHNfC1KY5oWh+6Sd7PZqYrARc7Mza7GSNht8LJozChTDwDJQ2KKmteBD71KoP8jjyXG2VtoNceP2okmYKYpkE+A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=kaloom.com; dmarc=pass action=none header.from=kaloom.com; dkim=pass header.d=kaloom.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaloom.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7C1VhL5MOKXbm6VpeQQrQZQTMK2P1BYIemRMPTK+NuI=; b=oH0mMwPyJLd0XkTkJd9EEYzkY7uYMcxKzYsniEweahYF6UZY2dfElzXQP+iN3yd08YFiExVmfkInHjro2wI8N1um6cxqDeEXJzZW9kAwn7DeDXzA6JBvz4s9MJ4dlHyb6KpOIYspF+3pnj7lgwekl59znCCd4erL6bnSPYiyiQM= Received: from QB1PR01MB3219.CANPRD01.PROD.OUTLOOK.COM (52.132.84.225) by QB1PR01MB2386.CANPRD01.PROD.OUTLOOK.COM (52.132.86.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14; Thu, 5 Mar 2020 19:00:22 +0000 Received: from QB1PR01MB3219.CANPRD01.PROD.OUTLOOK.COM ([fe80::88eb:95a3:1188:b54a]) by QB1PR01MB3219.CANPRD01.PROD.OUTLOOK.COM ([fe80::88eb:95a3:1188:b54a%6]) with mapi id 15.20.2772.019; Thu, 5 Mar 2020 19:00:22 +0000 From: Suresh Krishnan To: Robert Moskowitz CC: The IESG , "draft-ietf-hip-dex@ietf.org" , "j.ahrenholz@tempered.io" , "hip-chairs@ietf.org" , Gonzalo Camarillo , "hipsec@ietf.org" Thread-Topic: Suresh Krishnan's Discuss on draft-ietf-hip-dex-13: (with DISCUSS) Thread-Index: AQHV8we7/KY/NzbOrUi2xrBWanKnkag6WpOA Date: Thu, 5 Mar 2020 19:00:22 +0000 Message-ID: <9336814E-6390-47B1-AD35-38F09A6147AE@kaloom.com> References: <158329724383.7687.5696211532188484676@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Suresh@kaloom.com; x-originating-ip: [118.185.168.202] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 78889f38-466b-4007-7376-08d7c13774d7 x-ms-traffictypediagnostic: QB1PR01MB2386: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03333C607F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(366004)(396003)(39850400004)(136003)(199004)(189003)(81166006)(5660300002)(91956017)(66946007)(6486002)(508600001)(33656002)(36756003)(76116006)(81156014)(316002)(86362001)(64756008)(8676002)(66556008)(6512007)(966005)(66476007)(66446008)(2906002)(4326008)(2616005)(8936002)(26005)(6506007)(6916009)(71200400001)(54906003)(53546011)(186003); DIR:OUT; SFP:1102; SCL:1; SRVR:QB1PR01MB2386; H:QB1PR01MB3219.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: kaloom.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Scgs1JqeX0gqAtMoU6MaJDzqvt2rWDWe7gQ5ymeA1nO2HyNo9fncAeWwciTbIBENfqjmelN9aNOl/GG6yBxL/3I+0KiKY/XQ5egML7wD11ZddsbT2N9WpCBqcLo20puYg+TohDtsUUMTJeHr2kQHBTNzM0Ean6sCmNwirREFu5XDmwLhf4GV6QLC2CCbV0whdYNNoEdkF4dcHa4k6wkfeS6KQJ3bLWYvsqfSB45wjNiicTnVKoo8n+dLjaGldOSCYsMPCPia8TFs7fH4GVCh4zMGc8fY9vD5qFAp3cb3yWmkRSr5BqHRnGxdxh+03VCt/rB+rvJVMTDkqE+kzdAoVHMknqVa9cbfbbX6lSNAUu8Mlb8kmB++SSkPPFwfooWLx0+XhvKRZpjtHbOX/bveGptO9kcmELmTGDWQV7xMbp+DyBPIMGTEpUYfr/7Dq/ljX42w+5c9YRA6cPvRjvubwh20oWr8xml6/W5FacjTV+VeI6vx0BHUJDXtLYNjyk3O9cB8rg3hNQyoHjXGL2rRiA== x-ms-exchange-antispam-messagedata: vLtnsfkWiuWR15Oao01zRuxp+hGc4GCbDeSgt6zGByt728blkBGLG8kxF55lpaNNEM/uJTuvHGvNsWNoiySbhZa0PkX6SmDuKCdzMPlTswnuLc/+eJmnTm5hBViKGTDC8xL7qCVxEJM5LqGoGRKIXQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: kaloom.com X-MS-Exchange-CrossTenant-Network-Message-Id: 78889f38-466b-4007-7376-08d7c13774d7 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2020 19:00:22.3193 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 47d58e26-f796-48e8-ac40-1c365c204513 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZjliqF0QIUrOqzFI3ZscgtD6+Q2CEFSqdDzknKmjms4+gq0re3PfUpV24dwm7eevDQmWhP8TOl2O6c1tpq1mMQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: QB1PR01MB2386 Archived-At: Subject: Re: [Hipsec] Suresh Krishnan's Discuss on draft-ietf-hip-dex-13: (with DISCUSS) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 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, 05 Mar 2020 19:00:29 -0000 Hi Bob, This text works for me. I will clear as soon as the new revision hits. Regards Suresh > On Mar 5, 2020, at 11:04 AM, Robert Moskowitz = wrote: >=20 > Here is the text I put together for revising sec 5.4 (see below). >=20 > On 3/3/20 11:47 PM, Suresh Krishnan via Datatracker wrote: >> Suresh Krishnan has entered the following ballot position for >> draft-ietf-hip-dex-13: Discuss >>=20 >> 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.) >>=20 >>=20 >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htm= l >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-hip-dex/ >>=20 >>=20 >>=20 >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >>=20 >> This should be pretty straightforward to resolve. >>=20 >> * Section 5.4.: >>=20 >> The ICMPv6 Parameter Problem messages to be sent need a Code field to be= set in >> addition to the Pointer. What Code should be used in this message? Pleas= e >> specify this. >>=20 >>=20 >>=20 >>=20 >>=20 >=20 > 5.4. ICMP Messages >=20 > When a HIP implementation detects a problem with an incoming packet, > and it either cannot determine the identity of the sender of the > packet or does not have any existing HIP association with the sender > of the packet, it MAY respond with an ICMP packet. Any such reply > MUST be rate-limited as described in [RFC4443]. In most cases, the > ICMP packet has the Parameter Problem type (12 for ICMPv4, 4 for > ICMPv6) and Code of 0. The Pointer field pointing to the field that > caused the ICMP message to be generated, for example to the first 8 > bytes of a UDP payload for "SPI is Unknown". The problem cases > specified in Section 5.4. of [RFC7401] also apply to HIP DEX. >=20 From nobody Fri Mar 6 06:21:38 2020 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 F41E03A07A0; Fri, 6 Mar 2020 06:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 lqfMzAJpfdgu; Fri, 6 Mar 2020 06:21:27 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 9F2433A079E; Fri, 6 Mar 2020 06:21:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 545FC621CB; Fri, 6 Mar 2020 09:21:24 -0500 (EST) 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 kDeiZ-3fcFn1; Fri, 6 Mar 2020 09:21:10 -0500 (EST) Received: from lx140e.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 06D0B6211C; Fri, 6 Mar 2020 09:21:10 -0500 (EST) To: Roman Danyliw , The IESG Cc: draft-ietf-hip-dex@ietf.org, hip-chairs@ietf.org, hipsec@ietf.org, Gonzalo Camarillo References: <158334648514.29413.16902420341202011591@ietfa.amsl.com> From: Robert Moskowitz Message-ID: Date: Fri, 6 Mar 2020 09:21:07 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <158334648514.29413.16902420341202011591@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------3568D62A4D0C1684DB93C042" Content-Language: en-US Archived-At: Subject: Re: [Hipsec] Roman Danyliw's Discuss on draft-ietf-hip-dex-13: (with DISCUSS and COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2020 14:21:31 -0000 This is a multi-part message in MIME format. --------------3568D62A4D0C1684DB93C042 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 3/4/20 1:28 PM, Roman Danyliw via Datatracker wrote: > Roman Danyliw has entered the following ballot position for > draft-ietf-hip-dex-13: Discuss > > 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-dex/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > (initial ballot now that this draft is deferred) > > ** Section 1.2. Thanks for the scoping provided by this applicability > statement. Given the reduced security that DEX will provide, IMO it needs a > bit more precision (and caution). And I should point out it gives more security that has been provided in these classes of devices in the past. > OLD > HIP DEX MUST only be used in communicating with such constrained > devices (e.g., class 0 and 1 devices as defined in section 3 in > [RFC7228]). > > NEW > > HIP DEX MUST only be used when one of the peers is a class 0 or 1 constrained > device as defined in Section 3 of [RFC7228]. HIP DEX MUST NOT be used if both > peers are class 2 constrained devices or have greater capability. Done. > ** Section 3.2.1, Per “Since collision-resistance is not possible with the > tools at hand, any reasonable function (e.g. FOLD) that takes the full value > of the HI into generating the HIT can be used, provided that collision > detection is part of the HIP-DEX deployment design. This is achieved here > through either an ACL or some other lookup process that externally binds the > HIT and HI.”, when exactly should this ACL lookup occur? Please provide > guidance in an explicit step in the appropriate packet processing section > (i.e., in Section 6.*) on when this should be. I will look into this.  It is during I2 and R2 processing as that is when the recipient can trust that the HI is for the HIT. There is also a ACL check for I1 and R1, but that is just to limit who to talk to, not is the who claim valid. Also the constrained device may not have ACL checking capability. No way to update the ACL in a sensor, for example.  In this case the password authentication is required. I will look at the places to make sure this is covered. > ** Section 5.2.1 – Is this list of DH Group IDs intended to be a subset of the > HIP Group ID sub-registry? If so, Curve25519 and Curve448 don’t appear to be > in the > https://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml#hip-parameters-5? > Should they be registered? Hmmm. for some reason I thought this was handled.  I will check it out and if I am missed it, I will update the IANA section. > ** Section 6.3. Per “Some payload protection mechanisms have their own Key > Derivation Function, and if so this mechanism SHOULD be used.”, if the payload > protection mechanisms have their own KDF, how would their security properties > be trusted if their KDF is NOT used? Why is this SHOULD not a MUST? I need to reread this section before commenting.  If I remember right, this is a dodge clause that someone wanted.  I may just end up pulling it. > ** Section 6.3. The input to CKDR-Extract seems underspecified: > -- Per the definition of IKM, when should these different inputs be used (at > least two appear to be specified)? References to Kij are made in this section > and in other parts of the document, but they aren’t input for CKDR-Extract()? Will research this and see if more text is needed and how. > -- Per “where ‘CKDF-Extract’ is an octet string “ in the definition of “info” > in CKDR-Extract(), what encoding should be used to convert that into an octet > string? Is it ASCII, as in 067 075 068 070 045 069 120 116 114 097 099 116? Will check this too. > ** Section 9. Please add language to the effect that “production deployments > of this specification MUST NOT use the NULL-ENCRYPT HIP_CIPHER” (to mirror the > language already stated in Section 5.2.2 on the topic). Good point.  Will do. > ** Section 9.2. This mandatory guidance to validate public keys is helpful. > Please provide guidance in an explicit step in the appropriate packet > processing section (i.e., in Section 6.*) on when this should be done. I thought I did.  Grumble.  Will take care of this too. > Two “discuss discuss”-es with the caveat that I didn’t follow the WG > discussions. > > ** The following seems to indicate we don’t have everything we need to publish > a standards track document: -- Section 6. “It should be noted that many of the > packet processing rules are denoted here with "SHOULD" but may be updated to > "MUST" when further implementation experience provides better guidance.” I did not want this, if I recall correctly.  It was something of a standard wording back when this was first done.  At this point, I will pull this.  It is not uncommon that a standard goes out and then some years later deployment teaches us things about what SHOULD and what MUST. > -- Section 9. “o The puzzle mechanism using CMAC explained in Section 4.1.1 > may need further study regarding the level of difficulty in order to establish > best practices with current generation of constrained devices.” > > If there isn’t sufficient implementation experience, why isn’t this document > experimental? What is the plan for getting better guidance? Is there a risk > in not having this clarity? Actually this is another area that can be pulled now.  Rene did testing on the difficulty and I believe we captured his experiences.  I will look at this and clarify. > ** Section 9.1. Thanks for this section. However, I’m not convinced that > SECP160R1 is needed. DEX is already selectively profiling RFC7401 (i.e., its > already choosing to exclude certain things) and there are “no production” > implementation of DEX. What is the rationale for keeping it? In the workgroup I was asked to keep it in?  To /harmonize/ with other areas of constrained security?  This is some years back though, and it is another area where by this time, we have enough to drop it?  I am willing to, but I should ask on the HIPSEC list and see what private replies I get. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > ** Section 3.0. Per “Thus, it is not expected that these parameters are > carried in every packet, but other methods are used to map the data packets to > the corresponding His”, what are these other methods? This text is lifted right out of sec 3 of rfc7401.  ESP SPIs are a stated example further in that paragraph. > ** Section 3.1. Per “There are two advantages of using a hashed encoding over > the actual variable-sized public key in protocols.”, perhaps as a reminder is > in order that in this document the HIT isn’t a hashed encoding but a compressed. A case of lifting text from 7401 where it needs to be adjusted a bit.  I will make the change. > ** Section 4.1. Per “Note that in some cases it may be possible to replace > this trigger packet by some other form of a trigger, in which case the > protocol starts with the Responder sending the R1 packet.”, how does this > additional trigger occur? Some packet that has enough information for the receiver to deduce that an I1 COULD have been sent and to then respond with an R1 to see if the sender supports HIP. None have been defined.  This actually goes back to 5201.  More of a placeholder to allow others to make adjustments in their implementation. > ** Section 4.1. Per “In such cases, another mechanism to convey the Initiator's > supported DH Groups (e.g., by using a default group) must be specified.”, > where/how would it be specified? Again, nothing has been specified, but in a closed environment it was thought that an ACL or other data store would contain enough information, like the supported DH Groups to successfully trigger an R1 without receiving an I1.  This is more a placeholder for any developer that is working on an alternative to using the I1 to note all that must be done if something other than an I1 is used. "If you are going to try and optimize this protocol, remember all that you have to include" kind of thing. > ** Section 4.1.2.1. Per “This strategy is based on a timeout that is set to a > value larger than the worst-case anticipated round-trip time (RTT ).”, how is > the worst case RTT computed? IIRC, the implementers want this in.  It goes back to 5201, sec 6.6.  Perhaps one that is still around (hint, Jeff or Tom) can comment. > ** Section 5.3.2. Per “Responder sets the source HIT in the R2 packet based on > the destination HIT from the I1 packet”, shouldn’t this say “Responder sets the > source HIT in the _R1_ packet …”? OOPS!  Good catch.  Fixed.  Probably some poor job (by me!) in copying and pasting text. > ** Section 5.3.2. Per “Based on the deviating DH group ID in the HOST_ID > parameter, the Initiator then SHOULD abort …”, why not MUST abort? A MUST costs a round trip.  It is possible that the Initiator, based on local policy, can make a decision to go with the received R1 rather than restart the exchange.  Thus we chose SHOULD here over MUST. > ** Section 6.8. Step 5. Per “5. If any of the checks above fail, there is a > high probability of an ongoing man-in-the-middle or other security attack. The > system SHOULD act accordingly, based on its local policy.”, this guidance seems > underspecified. Could the text at least provide a recommendation of aborting > and logging? Seems reasonable request.  But this text goes back to 5201.  Perhaps some of the HIPv1 and/or v2 implementors can tell want they do here. > ** Section 9. Per “The strength of the keys for the Pair-wise Key SA is based > on the quality of the random keying material. As either peer may be a sensor > or an actuator device, there is a natural concern about the quality of its > random number generator.”, this is helpful caution. What guidance can be given > to ameliorate the concern? When we did IEEE 802.11i, we actually had an annex giving pseudo code for gathering entropy by listening to the radio noise or how to build an ring-occilator on your chip. Is there any good IETF RFC recommendation on a good RND for constrained devices?  I would be happy to include copied text or a reference. > ** Editorial > -- Section 1.2. The sentence “Also, it is often the case that HIP DEX …” is > repeated twice. Thanks.   Fixed.  I kept the 2nd one as the separate para.  Reads better in my opinion. > -- Section 4.1. s/the the/the/ fixed. > -- Section 6.3. Typo. > s/The HIP DEX KEYMAT process is based on the is the/ > The HIP DEX KEYMAT process is based on the/ fixed. > -- Section 9.2. Editorial. Per “With the curves specified here, there is a > straightforward key extraction attack, which is a very serious problem the use > of static keys in HIP-DEX”, there appears to be some missing words – perhaps “… > with the use of static keys by HIP-DEX”. thanks.  Yes, I have added "with" --------------3568D62A4D0C1684DB93C042 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 3/4/20 1:28 PM, Roman Danyliw via Datatracker wrote:
Roman Danyliw has entered the following ballot position for
draft-ietf-hip-dex-13: Discuss

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-dex/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(initial ballot now that this draft is deferred)

** Section 1.2.  Thanks for the scoping provided by this applicability
statement.  Given the reduced security that DEX will provide, IMO it needs a
bit more precision (and caution).

And I should point out it gives more security that has been provided in these classes of devices in the past.

OLD
   HIP DEX MUST  only be used in communicating with such constrained
   devices (e.g., class 0 and 1 devices as defined in section 3 in
   [RFC7228]).

NEW

HIP DEX MUST only be used when one of the peers is a class 0 or 1 constrained
device as defined in Section 3 of [RFC7228].  HIP DEX MUST NOT be used if both
peers are class 2 constrained devices or have greater capability.

Done.

** Section 3.2.1, Per “Since collision-resistance is not possible with the
tools at hand, any reasonable function (e.g.  FOLD) that takes the full value
of the HI into generating the HIT can be used, provided that collision
detection is part of the HIP-DEX deployment design.  This is achieved here
through either an ACL or some other lookup process that externally binds the
HIT and HI.”, when exactly should this ACL lookup occur?  Please provide
guidance in an explicit step in the appropriate packet processing section
(i.e., in Section 6.*) on when this should be.

I will look into this.  It is during I2 and R2 processing as that is when the recipient can trust that the HI is for the HIT.

There is also a ACL check for I1 and R1, but that is just to limit who to talk to, not is the who claim valid.

Also the constrained device may not have ACL checking capability.  No way to update the ACL in a sensor, for example.  In this case the password authentication is required.

I will look at the places to make sure this is covered.


** Section 5.2.1 – Is this list of DH Group IDs intended to be a subset of the
HIP Group ID sub-registry?  If so, Curve25519 and Curve448 don’t appear to be
in the
https://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml#hip-parameters-5?
 Should they be registered?


Hmmm. for some reason I thought this was handled.  I will check it out and if I am missed it, I will update the IANA section.

** Section 6.3.  Per “Some payload protection mechanisms have their own Key
Derivation Function, and if so this mechanism SHOULD be used.”, if the payload
protection mechanisms have their own KDF, how would their security properties
be trusted if their KDF is NOT used?  Why is this SHOULD not a MUST?

I need to reread this section before commenting.  If I remember right, this is a dodge clause that someone wanted.  I may just end up pulling it.

** Section 6.3.  The input to CKDR-Extract seems underspecified:
-- Per the definition of IKM, when should these different inputs be used (at
least two appear to be specified)?  References to Kij are made in this section
and in other parts of the document, but they aren’t input for CKDR-Extract()?

Will research this and see if more text is needed and how.

-- Per “where ‘CKDF-Extract’ is an octet string “ in the definition of “info”
in CKDR-Extract(), what encoding should be used to convert that into an octet
string?  Is it ASCII, as in 067 075 068 070 045 069 120 116 114 097 099 116?

Will check this too.

** Section 9.  Please add language to the effect that “production deployments
of this specification MUST NOT use the NULL-ENCRYPT HIP_CIPHER” (to mirror the
language already stated in Section 5.2.2 on the topic).

Good point.  Will do.

** Section 9.2.  This mandatory guidance to validate public keys is helpful. 
Please provide guidance in an explicit step in the appropriate packet
processing section (i.e., in Section 6.*) on when this should be done.

I thought I did.  Grumble.  Will take care of this too.

Two “discuss discuss”-es with the caveat that I didn’t follow the WG
discussions.

** The following seems to indicate we don’t have everything we need to publish
a standards track document: -- Section 6.  “It should be noted that many of the
packet processing rules are denoted here with "SHOULD" but may be updated to
"MUST" when further implementation experience provides better guidance.”

I did not want this, if I recall correctly.  It was something of a standard wording back when this was first done.  At this point, I will pull this.  It is not uncommon that a standard goes out and then some years later deployment teaches us things about what SHOULD and what MUST.


-- Section 9.  “o  The puzzle mechanism using CMAC explained in Section 4.1.1
may need further study regarding the level of difficulty in order to establish
best practices with current generation of  constrained devices.”

If there isn’t sufficient implementation experience, why isn’t this document
experimental?  What is the plan for getting better guidance?  Is there a risk
in not having this clarity?

Actually this is another area that can be pulled now.  Rene did testing on the difficulty and I believe we captured his experiences.  I will look at this and clarify.

** Section 9.1.  Thanks for this section.  However, I’m not convinced that
SECP160R1 is needed.  DEX is already selectively profiling RFC7401 (i.e., its
already choosing to exclude certain things) and there are “no production”
implementation of DEX.  What is the rationale for keeping it?

In the workgroup I was asked to keep it in?  To harmonize with other areas of constrained security?  This is some years back though, and it is another area where by this time, we have enough to drop it?  I am willing to, but I should ask on the HIPSEC list and see what private replies I get.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** Section 3.0.  Per “Thus, it is not expected that these parameters are
carried in every packet, but other methods are used to map the data packets to
the corresponding His”, what are these other methods?

This text is lifted right out of sec 3 of rfc7401.  ESP SPIs are a stated example further in that paragraph.

** Section 3.1.  Per “There are two advantages of using a hashed encoding  over
the actual variable-sized public key in protocols.”, perhaps as a reminder is
in order that in this document the HIT isn’t a hashed encoding but a compressed.

A case of lifting text from 7401 where it needs to be adjusted a bit.  I will make the change.

** Section 4.1.  Per “Note that in some cases it may be possible to replace
this trigger packet by some  other form of a trigger, in which case the
protocol starts with the Responder sending the R1 packet.”, how does this
additional trigger occur?

Some packet that has enough information for the receiver to deduce that an I1 COULD have been sent and to then respond with an R1 to see if the sender supports HIP.

None have been defined.  This actually goes back to 5201.  More of a placeholder to allow others to make adjustments in their implementation. 

** Section 4.1. Per “In such cases, another mechanism to convey the Initiator's
supported DH Groups (e.g., by using a default group) must be specified.”,
where/how would it be specified?

Again, nothing has been specified, but in a closed environment it was thought that an ACL or other data store would contain enough information, like the supported DH Groups to successfully trigger an R1 without receiving an I1.  This is more a placeholder for any developer that is working on an alternative to using the I1 to note all that must be done if something other than an I1 is used.

"If you are going to try and optimize this protocol, remember all that you have to include" kind of thing.

** Section 4.1.2.1. Per “This strategy is based on a timeout that is set to a
value larger than the worst-case anticipated round-trip time (RTT ).”, how is
the worst case RTT computed?

IIRC, the implementers want this in.  It goes back to 5201, sec 6.6.  Perhaps one that is still around (hint, Jeff or Tom) can comment.


** Section 5.3.2.  Per “Responder sets the source HIT in the R2 packet based on
the destination HIT from the I1 packet”, shouldn’t this say “Responder sets the
source HIT in the _R1_ packet …”?

OOPS!  Good catch.  Fixed.  Probably some poor job (by me!) in copying and pasting text.

** Section 5.3.2.  Per “Based on the deviating DH group ID in the HOST_ID
parameter, the Initiator then SHOULD abort …”, why not MUST abort?

A MUST costs a round trip.  It is possible that the Initiator, based on local policy, can make a decision to go with the received R1 rather than restart the exchange.  Thus we chose SHOULD here over MUST.

** Section 6.8. Step 5.  Per “5.  If any of the checks above fail, there is a
high probability of an ongoing man-in-the-middle or other security attack.  The
system SHOULD act accordingly, based on its local policy.”, this guidance seems
underspecified.  Could the text at least provide a recommendation of aborting
and logging?

Seems reasonable request.  But this text goes back to 5201.  Perhaps some of the HIPv1 and/or v2 implementors can tell want they do here.

** Section 9.  Per “The strength of the keys for the Pair-wise Key SA is based
on the quality of the random keying material.  As either peer may be a sensor
or an actuator device, there is a natural concern about the quality of its
random number generator.”, this is helpful caution. What guidance can be given
to ameliorate the concern?

When we did IEEE 802.11i, we actually had an annex giving pseudo code for gathering entropy by listening to the radio noise or how to build an ring-occilator on your chip.

Is there any good IETF RFC recommendation on a good RND for constrained devices?  I would be happy to include copied text or a reference.

** Editorial
-- Section 1.2.  The sentence “Also, it is often the case that HIP DEX …” is
repeated twice.

Thanks.   Fixed.  I kept the 2nd one as the separate para.  Reads better in my opinion.

-- Section 4.1. s/the the/the/

fixed.

-- Section 6.3.  Typo.
s/The HIP DEX KEYMAT process is based on the is the/
The HIP DEX KEYMAT process is based on the/

fixed.

-- Section 9.2.  Editorial.  Per “With the curves specified here, there is a
straightforward key extraction attack, which is a very serious problem the use
of static keys in HIP-DEX”, there appears to be some missing words – perhaps “…
with the use of static keys by HIP-DEX”.

thanks.  Yes, I have added "with"


--------------3568D62A4D0C1684DB93C042-- From nobody Fri Mar 6 06:33:25 2020 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 BCC2A3A07DF; Fri, 6 Mar 2020 06:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 fXpzkB9t-L1Y; Fri, 6 Mar 2020 06:33:11 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2082.outbound.protection.outlook.com [40.107.21.82]) (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 D5C633A07D6; Fri, 6 Mar 2020 06:33:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Hx3zMpdXc9+m2Qj9YdjcMVA2vtfSo0/sdA4qmrivfLW+uRfzcq+boleRmMlA4eNFoyehfaXyT/lAPAf4lZ2Esit+kwRAfT/t8si36AB7mV7hg8xwtp/7VwQwUwRR911ZjR19f5hrZ2LgW/Wc4ht8YAek8N581SeA2gqaj7rv3MbGpAi075SWk0tND2rYjpoMMbcozMu+ub5DyOsMiDEO2BocbysflY6JixqbFeJY84ADSfwsZBkeNRHuD7RmWki2jhUyd8b/GNgdY6YPZlU6HlXZ7nftu2zBlW3MUinIcTLgS2wPPyP6cLPqblYAJD42TdzfsbIAVM8woLUcPJWxNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ylwn5E0kG9s07GF9O1jA/0y4hj+wmMa1wcYYwdSNQ3s=; b=GgPLkdfvEI4fh+iMRO2L+wmnWGZjEC5W5VQHnDe6tLbcoXWPhmQL8CoA2agbFWq0U0zCSuZBJ09gNdGhjbco534m4I65+JysSJ+k7STgqS0FhoQ1Kg3WLCENAdG542l30xHNDr9btM16g1tG2qKjJv3LYFfaxQvTKQfPi5nr7q0wjj5mhkdsDQjEyt9VA53J+prV0aNBy0HRsHoFXLr9ySilszphIJEkyoZGCXy1SJeOA6asiMKnHzRsrSCJgJ/ZB6SYFjNSbi9PmhzHS4cpgj/a63mXey12pOw/rdSWV6Qsl+wlUqWb0nQljqMNG7t/H1znlTow86FFrQfqOYWAkA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ylwn5E0kG9s07GF9O1jA/0y4hj+wmMa1wcYYwdSNQ3s=; b=dKA+vBO0dlxofHx0HgRlZEnxqRjvc5O3Ef/mY2BtIUAsdZGQ18boRhZl1AwvwPShBiYptjeC8CO9JZCpDZiDkhDRQlHsESDGC6lu2jC7lwYxB1bUNO/AT1fgSFyunpxeIk9pOk01lJVYl6GntVVsqgrdHCgzqdmcD7n0OKswRSQ= Received: from AM0PR07MB3876.eurprd07.prod.outlook.com (52.134.81.144) by AM0PR07MB4308.eurprd07.prod.outlook.com (52.133.60.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.11; Fri, 6 Mar 2020 14:33:06 +0000 Received: from AM0PR07MB3876.eurprd07.prod.outlook.com ([fe80::790c:4b51:77d2:7767]) by AM0PR07MB3876.eurprd07.prod.outlook.com ([fe80::790c:4b51:77d2:7767%5]) with mapi id 15.20.2793.013; Fri, 6 Mar 2020 14:33:06 +0000 From: Miika Komu To: "iesg@ietf.org" , "adam@nostrum.com" CC: "draft-ietf-hip-native-nat-traversal@ietf.org" , "hip-chairs@ietf.org" , Gonzalo Camarillo , "hipsec@ietf.org" Thread-Topic: Adam Roach's No Objection on draft-ietf-hip-native-nat-traversal-30: (with COMMENT) Thread-Index: AQHV6zYXYqOBrY11mU6Er/aZUfyTv6g7seAA Date: Fri, 6 Mar 2020 14:33:06 +0000 Message-ID: References: <158256455409.5317.3970484745957517223.idtracker@ietfa.amsl.com> In-Reply-To: <158256455409.5317.3970484745957517223.idtracker@ietfa.amsl.com> Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.1 authentication-results: spf=none (sender IP is ) smtp.mailfrom=miika.komu@ericsson.com; x-originating-ip: [88.148.205.35] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 98d1d649-96e1-4118-221f-08d7c1db494e x-ms-traffictypediagnostic: AM0PR07MB4308: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0334223192 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(366004)(346002)(376002)(136003)(189003)(199004)(6512007)(478600001)(966005)(316002)(2906002)(86362001)(8676002)(44832011)(4326008)(8936002)(5660300002)(81156014)(81166006)(2616005)(6486002)(110136005)(54906003)(6506007)(186003)(76116006)(36756003)(26005)(64756008)(66946007)(66446008)(91956017)(66476007)(66556008)(71200400001)(99106002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB4308; H:AM0PR07MB3876.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Ummhma+UvyJIFD2/Jvlu6VN1MdKgU1/+UNpdzuaJNrlDBu906NS/gR49AMoTzAUi1D6wg3ux1ONsmRym7RAVMjA6o0P3nJ0bRPwFsO5YsASSjPEXuDnY57nXmig9wmDZ9c5mpy0RKVTHocvw09uMkcjSyI7oeqS30D+yr7bmfo8ZF/zjqAyQHhl+Ykn7NE51ufQV06LDke7CGF+ythRL8MCqTmdtl+BiDn13s7bNSojr33pLjXvlh1UAIcmpjHF5ld1XboFZD4jyjzB34kOO785zhFvHjEQan1kEKMf8peojFWm7cRPVhx0NhtgeidW8q0JkXqIW0/Pp2h1zcSpK6KON4fVfPT6DZEBhDVPabbbdMIBnQDdjZB2VhalPAoXn/EHzuuKK0FlOj+GymqQZbRfimO6PStBKgH8NyhLYIhdB3ok9E2gDUuDXGPRK1sDbI//ae08bx/tWHyTtieFrwmeMJ9lYdTG7+4lG23F6LUfFbBm+eAQuFh0jx3N/wx9hQj+wPrTMW2llAvYPTr2hVxO8+tHzwx+vaK8oNtDCX6ZNoCiqm56GSE+bGkk7q6lW x-ms-exchange-antispam-messagedata: d0qm/VGYvo89/eCiGAtJpqCm64Zyaw5pA5bfPRwPn80G6qU+06DtQsblD7+zqbfxwuqbulVmK41YPpSsDVed5a1IBzHWv89rKGbQciImUy97AIfBghaUMyDAZ8Cur+wH3mSsEoxrw+DrTE+oSJv22g== Content-Type: text/plain; charset="utf-8" Content-ID: <8AA2453DD18F234BBDEFDE75C9480479@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 98d1d649-96e1-4118-221f-08d7c1db494e X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2020 14:33:06.7300 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4lXX4SILecPmF1MIXeFHI+d7uFxKXDXgbmP465yK85y/MkSsneVfUmZxIGd+r9BfEdCZpj8GYRaTRMtEb50sJA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4308 Archived-At: Subject: Re: [Hipsec] Adam Roach's No Objection on draft-ietf-hip-native-nat-traversal-30: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2020 14:33:19 -0000 SGkgQWRhbSwNCg0KbWEsIDIwMjAtMDItMjQga2VsbG8gMDk6MTUgLTA4MDAsIEFkYW0gUm9hY2gg dmlhIERhdGF0cmFja2VyIGtpcmpvaXR0aToNCj4gQWRhbSBSb2FjaCBoYXMgZW50ZXJlZCB0aGUg Zm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gZHJhZnQtaWV0Zi1oaXAtbmF0aXZlLW5h dC10cmF2ZXJzYWwtMzA6IE5vIE9iamVjdGlvbg0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVh c2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+IGVtYWls IGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRv IGN1dA0KPiB0aGlzDQo+IGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4g DQo+IFBsZWFzZSByZWZlciB0byANCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1l bnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElF U0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+IA0KPiANCj4gVGhlIGRvY3VtZW50 LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0K PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWhpcC1uYXRpdmUt bmF0LXRyYXZlcnNhbC8NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0NCj4gQ09NTUVO VDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0NCj4gDQo+IFRoYW5rcyB0byB0aGUgYXV0aG9ycyBmb3Ig dGFraW5nIHNvbWUgb2YgdGhlIGNvbmNlcm5zIEkgbGFpZCBvdXQgaW4NCj4gbXkgb3JpZ2luYWwN Cj4gYmFsbG90IGludG8gYWNjb3VudC4gSSBzdGlsbCBkbyBub3QgYmVsaWV2ZSB0aGlzIGFwcHJv YWNoIGlzIGdvb2QgZm9yDQo+IEhJUCdzDQo+IGJlbmVmaXQsIGJ1dCBhbSBubyBsb25nZXIgd29y cmllZCBhYm91dCBjb2xsYXRlcmFsIGRhbWFnZSBmcm9tIG90aGVyDQo+IHByb3RvY29scw0KPiBp bWl0YXRpbmcgdGhpcyBhcHByb2FjaC4gQWNjb3JkaW5nbHksIEkgYW0gYmFsbG90aW5nICJObyBP YmplY3Rpb24uIg0KPiANCj4gVGhlcmUgaXMgb25lIHJlbWFpbmluZyBjb21tZW50IGZyb20gbXkg aW5pdGlhbCByZXZpZXcgdGhhdCBJIHRoaW5rDQo+IGNhbiBhbmQNCj4gc2hvdWxkIGJlIGFkZHJl c3NlZCBwcmlvciB0byBwdWJsaWNhdGlvbjoNCj4gDQo+IEFwcGVuZGl4IEI6DQo+IA0KPiA+ICBv ICBVbmxpa2UgaW4gSUNFLCB0aGUgYWRkcmVzc2VzIGFyZSBub3QgWE9SLWVkIGluIE5hdGl2ZSBJ Q0UtSElQDQo+ID4gICAgIHByb3RvY29sIGluIG9yZGVyIHRvIGF2b2lkIG1pZGRsZWJveCB0YW1w ZXJpbmcuDQo+IA0KPiBUaGlzIGJ1bGxldCBzaG91bGQgZXhwbGFpbiB3aHkgc3VjaCBvYmZ1c2Nh dGlvbiBpcyB1bm5lY2Vzc2FyeS4NCg0KYmFzZWQgb24gZGlzY3Vzc2lvbiB3aXRoIFJlc2NvbGFy bGEsIGl0IGFjdHVhbGx5IHNheXM6DQoNCiJVbmxpa2UgaW4gSUNFLCB0aGUgYWRkcmVzc2VzIGFy ZSBub3QgWE9SLWVkIGluIE5hdGl2ZSBJQ0UtSElQIHByb3RvY29sDQpidXQgcmF0aGVyIGVuY3J5 cHRlZCB0byBhdm9pZCBtaWRkbGVib3ggdGFtcGVyaW5nLiINCg0KDQpodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1oaXAtbmF0aXZlLW5hdC10cmF2ZXJzYWwtMzAjYXBwZW5k aXgtQg0KDQpQLlMuIFRoYW5rcyBhZ2FpbiBmb3IgeW91ciB0aW1lIGFuZCBlZmZvcnQgaW4gcmV2 aWV3aW5nIHRoZSBkb2N1bWVudCENCg== From nobody Mon Mar 9 07:04:30 2020 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 6066D3A1046 for ; Mon, 9 Mar 2020 07:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 lC2bjrx8yzo0 for ; Mon, 9 Mar 2020 07:04:26 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 8D18B3A103E for ; Mon, 9 Mar 2020 07:04:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id E5CFC62129 for ; Mon, 9 Mar 2020 10:04:25 -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 GiTpGgdAU2B4 for ; Mon, 9 Mar 2020 10:04:22 -0400 (EDT) Received: from lx140e.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 E3C8062115 for ; Mon, 9 Mar 2020 10:04:21 -0400 (EDT) To: HIP From: Robert Moskowitz Message-ID: <62940b4e-f861-9915-cac3-1189b35dfc83@htt-consult.com> Date: Mon, 9 Mar 2020 10:04:15 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------0C1CE64CDBB97F0C2C0F4328" Content-Language: en-US Archived-At: Subject: [Hipsec] Fwd: New Version Notification for draft-moskowitz-hip-hhit-registries-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 14:04:28 -0000 This is a multi-part message in MIME format. --------------0C1CE64CDBB97F0C2C0F4328 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit This is a clean up draft.  Nothing much added. -------- Forwarded Message -------- Subject: New Version Notification for draft-moskowitz-hip-hhit-registries-02.txt Date: Mon, 09 Mar 2020 06:49:31 -0700 From: internet-drafts@ietf.org To: Robert Moskowitz , Adam Wiethuechter , Stuart Card , Stuart W. Card A new version of I-D, draft-moskowitz-hip-hhit-registries-02.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Name: draft-moskowitz-hip-hhit-registries Revision: 02 Title: Hierarchical HIT Registries Document date: 2020-03-09 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-moskowitz-hip-hhit-registries-02.txt Status: https://datatracker.ietf.org/doc/draft-moskowitz-hip-hhit-registries/ Htmlized: https://tools.ietf.org/html/draft-moskowitz-hip-hhit-registries-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-hhit-registries Diff: https://www.ietf.org/rfcdiff?url2=draft-moskowitz-hip-hhit-registries-02 Abstract: This document describes using the registration protocol and registries to support hierarchical HITs (HHITs). New and existing HIP parameters are used to communicate Registry Policies and data about the HHIT device and the Registries. Further Registries are expected to provide RVS services for registered HHIT devices. 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 --------------0C1CE64CDBB97F0C2C0F4328 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
This is a clean up draft.  Nothing much added.


-------- Forwarded Message --------
Subject: New Version Notification for draft-moskowitz-hip-hhit-registries-02.txt
Date: Mon, 09 Mar 2020 06:49:31 -0700
From: internet-drafts@ietf.org
To: Robert Moskowitz <rgm@labs.htt-consult.com>, Adam Wiethuechter <adam.wiethuechter@axenterprize.com>, Stuart Card <stu.card@axenterprize.com>, Stuart W. Card <stu.card@axenterprize.com>



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

Name: draft-moskowitz-hip-hhit-registries
Revision: 02
Title: Hierarchical HIT Registries
Document date: 2020-03-09
Group: Individual Submission
Pages: 13
URL: https://www.ietf.org/internet-drafts/draft-moskowitz-hip-hhit-registries-02.txt
Status: https://datatracker.ietf.org/doc/draft-moskowitz-hip-hhit-registries/
Htmlized: https://tools.ietf.org/html/draft-moskowitz-hip-hhit-registries-02
Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-hhit-registries
Diff: https://www.ietf.org/rfcdiff?url2=draft-moskowitz-hip-hhit-registries-02

Abstract:
This document describes using the registration protocol and
registries to support hierarchical HITs (HHITs). New and existing
HIP parameters are used to communicate Registry Policies and data
about the HHIT device and the Registries. Further Registries are
expected to provide RVS services for registered HHIT devices.



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


--------------0C1CE64CDBB97F0C2C0F4328-- From nobody Mon Mar 9 13:01:20 2020 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 56D663A168C; Mon, 9 Mar 2020 13:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 2rEt-v7Vexje; Mon, 9 Mar 2020 13:01:03 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 E8F8B3A16AD; Mon, 9 Mar 2020 13:01:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id EE51B62115; Mon, 9 Mar 2020 16:01:00 -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 whBK6HGO2SaD; Mon, 9 Mar 2020 16:00:41 -0400 (EDT) Received: from lx140e.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 9710E62113; Mon, 9 Mar 2020 16:00:41 -0400 (EDT) To: Benjamin Kaduk , The IESG Cc: draft-ietf-hip-dex@ietf.org, hip-chairs@ietf.org, hipsec@ietf.org, Gonzalo Camarillo References: <158334389700.29463.11015652778464092751@ietfa.amsl.com> From: Robert Moskowitz Message-ID: <2b32b723-65f1-12f1-9531-fc81528a207f@labs.htt-consult.com> Date: Mon, 9 Mar 2020 16:00:33 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <158334389700.29463.11015652778464092751@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Hipsec] Benjamin Kaduk's Discuss on draft-ietf-hip-dex-13: (with DISCUSS and COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 20:01:14 -0000 On 3/4/20 12:44 PM, Benjamin Kaduk via Datatracker wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-hip-dex-13: Discuss > > 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-dex/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This is a placeholder discuss, intended to illustrate several key > omissions from the current document and as an indication that it is not > yet ready for full IESG Evaluation. In that vein, I will defer the > evaluation shortly, to attempt to short-circuit the current round of > evaluation while the draft improves. In particular, this is not > intended to be a complete review of the document. > > The FOLD scheme for compressing full host identities into ORCHIDs/HITs > is pretty problematic. The current text acknowledges that collisions > are possible and attempts to justify the scheme by pointing out that no > collision-free scheme is possible absent a cryptographic hash, which is > an appeal to authority ("we can't use a cryptographic hash on > constrained systems") that does not attempt to answer the question of > whether it is actually reasonable to use a mechanism that allows > collisions for this purpose (vs. just not being able to do anything). > Additionally, there is not any discussion of second-preimage resistance, > which is the more important property here, in terms of an attacker being > able to construct a collision with an existing HIT of an honest node. In my humble opinion, second-preimage attack defense will be the same as any attack against the HI -> HIT mapping function. The only place HITs are used in HIP unauthenticated is in the initial I1 - I2 part of the exchange.  By the R2, everything is authenticated.  All other HIP messages containing HITs are authenticated. So the attack is slipping in a HI-HIT mapping that is malicious. Per Roman's comments, I will be adding to the I2 and R2 processing to validate this mapping. HIP has always had to handle probabilistic collisions.  DEX now requires checking for collisions as critical (via ACLs or other mechanisms).  I will see to adding text. Operationally, the challenge is in those low level sensors that have no way to have an ACL set up for the servers/gateways that they are connected to.  But this is true even for BEX.  So inclusion of the password authentication is part of the critical behavior is ACL or similar HI-HIT mappings are not possible (sensors with no out-of-band update mechanism).  We are always twisting ourselves in the chicken-and-egg problem with these devices. > In a related vein, Section 3.2.1 claims that the above concerns can be > remediated by deployment of a collision detection scheme, "achieved here > through either an ACL or some other lookup process". This process is > vital to the security of the system as a whole, and it would be > irresponsible to publish this document without a precise specification > of what properties are needed in order to perform this process, as well > as a worked example that can be used absent other considerations. I will be adding this per Roman's comments.  Most will be in the I2 and R2 processing. > Given that the applicability statement ("in communicating with such > constrained devices") implies that there is intent to have full-featured > nodes that implement both HIP DEX and HIP BEX, I think we need > significantly more discussion of how such nodes avoid using DEX in > situations where it was not appropriate. That is, how is it known that > the peer should be using DEX vs. BEX? Yes, the HIT includes an > indication of whether the identity is for use with DEX vs. BEX, but that > does not seem like quite the relevant property. Do we envision > scenarios where a node is positioned somewhat like a gateway, using DEX > on one interface and BEX to the broader internet? Yes to the gateway situation.  Or the sensor has E2E DEX connection to the central server somewhere on the greater Internet. Perhaps text that limits DEX on non-constrained nodes for use with peers in the DEX ACL (or other equivalent control mechanism). > Using AES-CTR with the long-term static-static master key requires > careful tracking of counter (sequence) number to nonvolatile storage. I > did not see discussion of the security consequences of inadvertent > counter reuse. I will look at this and see what I can add. > I appreciate the design to limit use of the long-term static-static > master key to essentially just key-wrap operations, but this seems to > require the presence of a CSPRNG in order to obtain secure session keys. > Expecting a strong CSPRNG on a node so constrained that DEX is necessary > seems to be a questionable assumption, and I see no discussion of the > need for a good RNG. (Relying on the full-featured peer to contribute > good entropy to the key derivation is not an option, since DEX is > allowed to be used between two nodes that are both constrained.) The current text is:    o  The strength of the keys for the Pair-wise Key SA is based on the       quality of the random keying material generated by the Initiator       and the Responder.  As either peer may be a sensor or an actuator       device, there is a natural concern about the quality of its random       number generator. Changed to:    o  The strength of the keys for both the Master and Pair-wise Key SAs       is based on the quality of the random keying material generated by       the Initiator and the Responder.  As either peer may be a sensor       or an actuator device, there is a natural concern about the       quality of its random number generator.  Thus at least a CSPRNG       SHOULD be used. > The default KEYMAT algorithm uses the "CKDF" (CMAC-based KDF) > construction, analogous to HKDF (RFC 5869). However, the paper > motivating 5869's design choices does not seem to justify the usage of > CMAC instead of HMAC, since the proof requires a PRF* but CMAC (with > AES) is only a PRP. Absent some detailed justification or prior art it > does not seem prudent to use such a novel construction for > security-critical functionality. The CKDF design comes from NIST SP800-108.  I had extensive discussions with NIST and the 5869 authors at the DEX design time. These points were discussed and considered that CKDF is a prudent design. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Some additional comments (also incomplete), since they were already written. > It would be reasonable to ignore for now any that don't make sense or > are on parts of the text likely to change as a result of the higher-level discussion. > > Abstract > > My preference is to just use "forward secrecy" rather than "perfect > forward secrecy", as perfection is hard to attain. I am all for that!  My Jewish Orthodox background makes me cringe at the use of PFS.  No such thing in this world (btw, I also cringe at the common use of "awesome")... If there is consensus to drop PFS from all IETF standards, I will replace "perfect forward secrecy" with "forward secrecy" and PFS with just the full verbiage as FS does not seem to be meaningful. > Section 1.1 > > HIP DEX operationally is very similar to HIP BEX. Moreover, the > employed model is also fairly equivalent to 802.11-2007 > [IEEE.802-11.2007] Master Key and Pair-wise Transient Key, but > handled in a single exchange. > > 802.11 security does not exactly have a shiny track record... You want to see the "smoking gun" document on WEP design from Nov '94?  I have it. The point is the Master key and Pair-wise key design.  Not necessarily how they were constructed.  I also published the initial paper on the attack on WPA-PSK. > HIP DEX does not have the option to encrypt the Host Identity of the > Initiator in the I2 packet. The Responder's Host Identity also is > not protected. Thus, contrary to HIPv2, HIP DEX does not provide for > end-point anonymity and any signaling (i.e., HOST_ID parameter > contained with an ENCRYPTED parameter) that indicates such anonymity > should be ignored. > > What would you do if you didn't ignore such signalling? Drop the > connection as being with a misbehaving peer? Probably more like a ill thought-out implementation.  Right now I am of the opinion of leaving this as is.  But I can be convinced to add a drop connection. > As in [RFC7401], data packets start to flow after the R2 packet. The > I2 and R2 packets may carry a data payload in the future. The > details of this may be defined later. > > I'm not sure what value is added by mentioning the possibility of data > payload in I2/R2. This is carried over from 5201.  There were ideas pointing how the 3-way TCP setup can become a 5-way HIP - TCPinESP setup. A few other were discussed in HIPRG, but no one has proposed to actually use this feature.  It stays for some future thinker to tinker with. > An existing HIP association can be updated with the update mechanism > defined in [RFC7401]. Likewise, the association can be torn down > with the defined closing mechanism for HIPv2 if it is no longer > needed. In doing so, HIP DEX omits the HIP_SIGNATURE parameters of > the original HIPv2 specification. > > I think the intent here is more along the lines of "HIP DEX does so even > in the absence of the HIP_SIGNATURE that is used in standard HIPv2". > (I also note that there's some subtle semantic mismatch between DEX as > "diet exchange" and its used to indicate continuing lack of security > functionality throughout the extent of the association, after the > exchange is completed.) Changed to:    An existing HIP association can be updated with the update mechanism    defined in [RFC7401].  Likewise, the association can be torn down    with the defined closing mechanism for HIPv2 if it is no longer    needed.  In doing so, HIP DEX does so even in the absence of the    HIP_SIGNATURE that is used in standard HIPv2. > Finally, HIP DEX is designed as an end-to-end authentication and key > establishment protocol. As such, it can be used in combination with > > Don't we have a LAKE WG now? How does DEX compare to what they are > working on? I looked some more at LAKE.  They are proposing to use ephemeral DH as part of the exchange.  That goes counter to sec 1.2 of HIP-DEX. If they come up with an approach that performs "acceptably", then I will be looking at it. > Section 1.2 > > In lieu of detailed comments, allow me to propose a rewrite of the whole > section: > > % HIP DEX achieves its lightweight nature in large part due to the > % intentional removal of Forward Secrecy (FS) from the key exchange. Current > % mechanisms to achieve FS use an authenticated ephemeral Diffie-Hellman > % exchange (e.g., SIGMA or PAKE). HIP DEX targets usage on devices where > % even the most lightweight ECDH exchange is prohibitively expensive for > % recurring (ephemeral) use. For example, experience with the 8-bit > % 8051-based ZWAWVE ZW0500 microprocessor has shown that EC25519 keypair > % generation exceeds 10 seconds and consumes significant energy (i.e., > % battery resources). Even the ECDH multiplication for the HIP DEX > % static-static key exchange takes 8-9 seconds, again with measurable > % energy consumption. This resource consumption is tolerable as a > % one-time event during provisioning, but would render the protocol > % unsuitable for use on these devices if it was required to be a > % recurring part of the protocol. For devices constrained in this > % manner, a FS-enabled protocol will likely provide little gain. The > % resulting "FS" key, likely produced during device provisioning, would > % typically end up being used for the remainder of the device's > % lifetime. With such a usage pattern, the inherent benefit of > % ephemeral keys is not realized. The security properties of such usage > % are very similar to those of using a statically provisioned symmetric > % pre-shared key, in that there remains a single PSK in static storage > % that is susceptible to exfiltration/compromise, and compromise of that > % key in effect compromises the entire protocol for that node. HIP DEX > % achieves marginally better security properties by computing the > % effective long-term PSK from a DH exchange, so that the provisioning > % service is not required to be part of the risk surface due to also > % possessing the PSK. > % > % Due to the substantially reduced security guarantees of HIP DEX > % compared to HIP BEX, HIP DEX MUST only be used when at least one of > % the two endpoints is a class 0 or 1 constrained device defined in > % Section 3 of [RFC7228]). HIP DEX MUST NOT be used when both endpoints > % are class 2 devices or unconstrained. I have accepted your text with one typo and some formatting.  Of course this text uses FS rather than PFS so that is a mis-match for now. 1.2.  Applicability    HIP DEX achieves its lightweight nature in large part due to the    intentional removal of Forward Secrecy (FS) from the key exchange.    Current mechanisms to achieve FS use an authenticated ephemeral    Diffie-Hellman exchange (e.g., SIGMA or PAKE).  HIP DEX targets usage    on devices where even the most lightweight ECDH exchange is    prohibitively expensive for recurring (ephemeral) use.  For example,    experience with the 8-bit 8051-based ZWAVE ZW0500 microprocessor has    shown that EC25519 keypair generation exceeds 10 seconds and consumes    significant energy (i.e., battery resources).  Even the ECDH    multiplication for the HIP DEX static-static key exchange takes 8-9    seconds, again with measurable energy consumption.  This resource    consumption is tolerable as a one-time event during provisioning, but    would render the protocol unsuitable for use on these devices if it    was required to be a recurring part of the protocol.  For devices    constrained in this manner, a FS-enabled protocol will likely provide    little gain.  The resulting "FS" key, likely produced during device    provisioning, would typically end up being used for the remainder of    the device's lifetime.    With such a usage pattern, the inherent benefit of ephemeral keys is    not realized.  The security properties of such usage are very similar    to those of using a statically provisioned symmetric pre-shared key,    in that there remains a single PSK in static storage that is    susceptible to exfiltration/compromise, and compromise of that key in    effect compromises the entire protocol for that node.  HIP DEX    achieves marginally better security properties by computing the    effective long-term PSK from a DH exchange, so that the provisioning    service is not required to be part of the risk surface due to also    possessing the PSK.    Due to the substantially reduced security guarantees of HIP DEX    compared to HIP BEX, HIP DEX MUST only be used when at least one of    the two endpoints is a class 0 or 1 constrained device defined in    Section 3 of [RFC7228]).  HIP DEX MUST NOT be used when both    endpoints are class 2 devices or unconstrained. > Section 2.2 > > Ltrunc (M(x), K) denotes the lowest order K bits of the result of > the MAC function M on the input x. > > I'm not sure I'm going to interpret the "lowest order K bits" the same > way that everyone else will. I think "leftmost" or "first" are more > common terms for describing this sort of truncation. This text goes back to 5201.  Implementors of 5201 did not have a problem with this, in fact probably one of them supplied the text. But I am open to change based on consensus. > Section 2.3 > > CMAC: The Cipher-based Message Authentication Code with the 128-bit > Advanced Encryption Standard (AES) defined in RFC 4493 [RFC4493]. > > I would suggest just using CMAC as the acronym and not trying to > overload it to also be AES-specific. Do you recommend I just reference SP800-38B? > HIT Suite: A HIT Suite groups all algorithms that are required to > generate and use an HI and its HIT. In particular, these > algorithms are: 1) ECDH and 2) FOLD. > > For DEX. For normal HIPv2 we wouldn't touch FOLD with a long pole. :)    HIT Suite:  A HIT Suite groups all algorithms that are required to       generate and use an HI and its HIT.  In particular for HIP DEX,       these algorithms are: 1) ECDH and 2) FOLD. BTW, I once DID use a 10' pole to chase a family of raccoons out of my garage.  Really, it WAS 10' long, I had just gotten it from the lumber yard.  Came home and there were a bunch of beady eyes in the garage.. > HI (Host Identity): The static ECDH public key that represents the > identity of the host. In HIP DEX, a host proves ownership of the > private key belonging to its HI by creating a HIP_MAC with the > derived ECDH key (see Section 3). > > This may sound pedantic, but this doesn't actually prove ownership of > the private key. Someone who knows the private key of the other party > and the public key of the host in question would be able to produce the > same MAC from the corresponding derived ECDH key. I think the most we > can say here is that a host authenticates itself as that host identity > [with that HIP_MAC]. There's the corresponding trust of the recipient > that its own private key remains secure and thus that no party other > than itself or the peer identity could have generated that message. I will think on this one.  See what verbiage helps. > Initiator: The host that initiates the HIP DEX handshake. This role > is typically forgotten once the handshake is completed. > > "typically"? Perhaps it's best to say that the role is not used or > needed after the handshake is completed. I the HIP state machine, either peer can be the Initiator.  Roles can be reversed.  If one party looses state, it can then become the Initiator regardless of what role it had in the original exchange. This is the text used in 7401. > KEYMAT: Keying material. That is, the bit string(s) used as > cryptographic keys. > > I'm surprised we need an abbreviation for this. I got comments in early drafts of 5201-bis.  Put it in.  Take it out.  So for now, I leave it in. > Length of the Responder's HIT Hash Algorithm (RHASH_len): The > natural output length of RHASH in bits. > > [this doesn't really fit the pattern of "definition"s] It is in 7401.  If the AD says pull it.  It goes. Though perhaps the definition is of RHASH_len? > Responder: The host that responds to the Initiator in the HIP DEX > handshake. This role is typically forgotten once the handshake is > completed. > > [same thing re "typically"] Same response. > Section 3 > > HIP DEX implementations MUST support the Elliptic Curve Diffie- > Hellman (ECDH) [RFC6090] key exchange for generating the HI as > defined in Section 5.2.3. No additional algorithms are supported at > this time. > > It's kind of weird to see a "MUST" for "RFC6090 key exchange"; 6090 > discusses the general class of things but is not a specific key exchange > algorithm (e.g., curve). > I'd also consider s/supported/defined/. Good point.  Changed to:    HIP DEX implementations use the Elliptic Curve Diffie-Hellman (ECDH)    [RFC6090] key exchange for generating the HI as defined in    Section 5.2.3.  No alternative algorithms are defined at this time. > Due to the latter property, an attacker may be able to find a > collision with a HIT that is in use. Hence, policy decisions such as > access control MUST NOT be based solely on the HIT. Instead, the HI > of a host SHOULD be considered. > > I don't think this is correct or a strong enough statement. In > particular, I don't think access control should be based on the HIT at > all, so strike "solely". Also, the "SHOULD" seems too week. I can > understand that "MUST use the HI" could be overly constraining, but > "access control decisions MUST be made on the actual identity of the > host, e.g., the full HI" should allow for sufficient flexibility. I will see how this changes with the ACL additions. > Carrying HIs and HITs in the header of user data packets would > increase the overhead of packets. Thus, it is not expected that > > s/and/or/? fixed. > association. When other user data packet formats are used, the > corresponding extensions need to define a replacement for the > ESP_TRANSFORM [RFC7402] parameter along with associated semantics, > but this procedure is outside the scope of this document. > > Why is ESP_TRANSFORM the most important parameter here, when we talk > about mapping a packet to the HIP association? I thought ESP_TRANSFORM > was literally about the encryption mechanics, not metadata around it. Again, this goes back to 5201.  We are talking about ~20 years of discussions. We are discussing HIs and HITs, but that SPIs are used in everyday packets as the pointer to the HIs and HITs involved.  I will think on this, but it is down the list on things to change that were inherited from 5201. > Section 3.2 > > ORCHID claims to provide statistical uniqueness and routability at some > overlay layer, neither of which this FOLD procedure provides, due to > easily-generatable second preimages. > > Section 3.2.1 > > Since collision-resistance is not possible with the tools at hand, > any reasonable function (e.g. FOLD) that takes the full value of the > HI into generating the HIT can be used, provided that collision > detection is part of the HIP-DEX deployment design. This is achieved > > This is not an argument that this is a reasonable thing to do; it's > merely an argument that it's a thing that can be done that has the same > claimed properties as the only type of thing that could be done. It > might be a bad idea to do the only type of thing that can be done, and > you have not convinced me otherwise. (See also the distinction between > collision-resistance and second-preimage-resistance alluded to in my > comment on the previous section.) Other changes may help, or not.  We can rejoin this point after draft 14 (note I will be pushing out draft 13 today for the publish deadline for changes done so far). > here through either an ACL or some other lookup process that > externally binds the HIT and HI. > > Without at least one well-specified mechanism for actually doing this > and clear documentation of what precise properties such a mechanism > needs to provide, I think it's irresponsible to publish this document. In the works. > Section 4.1 > > By definition, the system initiating a HIP Diet EXchange is the > Initiator, and the peer is the Responder. This distinction is > typically forgotten once the handshake completes, and either party > can become the Initiator in future communications. > > ["typically" again] same response. > Diffie-Hellman Group IDs supported by the Initiator. Note that in > some cases it may be possible to replace this trigger packet by some > other form of a trigger, in which case the protocol starts with the > Responder sending the R1 packet. In such cases, another mechanism to > convey the Initiator's supported DH Groups (e.g., by using a default > group) must be specified. > > This seems under-specified for a proposed standard and is probably > better off omitted entirely. This is carried over from 5201, which WAS experimental.  So I can see it as reasonable to drop this as no one proposed another mechanism.    The Initiator first sends a trigger packet, I1, to the Responder.    This packet contains the HIT of the Initiator and the HIT of the    Responder, if it is known.  Moreover, the I1 packet initializes the    negotiation of the Diffie-Hellman group that is used for generating    the Master Key SA.  Therefore, the I1 packet contains a list of    Diffie-Hellman Group IDs supported by the Initiator. > The second packet, R1, starts the actual authenticated Diffie-Hellman > key exchange. It contains a puzzle - a cryptographic challenge that > the Initiator must solve before continuing the exchange. The level > of difficulty of the puzzle can be adjusted based on level of trust > with the Initiator, current load, or other factors. In addition, the > > The Initiator is unauthenticated at this point, so "level of trust" > seems to not really be defined... Changed to "knowledge of the".  If the Responder "knows" that the Initiator is a sensor, using a smaller puzzle may be preferred. there is discussion about large puzzles being an attack on sensors. > Section 4.1.1 > > If an unconstrained (DoSing) attacker is competing with a constrained > honest initiator to solve puzzles during an attack, it seems like the > honest initiator is going to lose out pretty badly. You do what you can that makes some degree of sense.  You just don't walk away from the problem. > Section 4.1.4 > > There are security considerations for serializing the HIP state to > nonvolatile storage! Do you want text about this in the Securities Considerations? And with this I am pushing out ver 13. From nobody Mon Mar 9 13:04:57 2020 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 414743A16B5; Mon, 9 Mar 2020 13:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 9QGuVWFsmtab; Mon, 9 Mar 2020 13:04:45 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 A93A03A16B1; Mon, 9 Mar 2020 13:04:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 46AD462113; Mon, 9 Mar 2020 16:04:44 -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 E5hmbdef-Ubn; Mon, 9 Mar 2020 16:04:42 -0400 (EDT) Received: from lx140e.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 6A86862129; Mon, 9 Mar 2020 16:04:40 -0400 (EDT) From: Robert Moskowitz To: Benjamin Kaduk , The IESG Cc: draft-ietf-hip-dex@ietf.org, hip-chairs@ietf.org, hipsec@ietf.org, Gonzalo Camarillo References: <158334389700.29463.11015652778464092751@ietfa.amsl.com> <2b32b723-65f1-12f1-9531-fc81528a207f@labs.htt-consult.com> Message-ID: <16701d9f-ce1d-52be-1ea2-a06f0f532c60@labs.htt-consult.com> Date: Mon, 9 Mar 2020 16:04:38 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <2b32b723-65f1-12f1-9531-fc81528a207f@labs.htt-consult.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Hipsec] Benjamin Kaduk's Discuss on draft-ietf-hip-dex-13: (with DISCUSS and COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 20:04:55 -0000 On 3/9/20 4:00 PM, Robert Moskowitz wrote: > > > > And with this I am pushing out ver 13. > > Oops.  That is ver 14 coming out now before the submit deadline. From nobody Mon Mar 9 13:09:11 2020 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 537F93A1666; Mon, 9 Mar 2020 13:09:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: hipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.120.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: hipsec@ietf.org Message-ID: <158378454926.5523.3656648079891289261@ietfa.amsl.com> Date: Mon, 09 Mar 2020 13:09:09 -0700 Archived-At: Subject: [Hipsec] I-D Action: draft-ietf-hip-dex-14.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 20:09:09 -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 WG of the IETF. Title : HIP Diet EXchange (DEX) Authors : Robert Moskowitz Rene Hummen Miika Komu Filename : draft-ietf-hip-dex-14.txt Pages : 58 Date : 2020-03-09 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. 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. Unlike HIPv2, HIP DEX does not support Perfect Forward Secrecy (PFS), and MUST only be used on devices where PFS is prohibitively expensive. 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-hip-dex-14 https://datatracker.ietf.org/doc/html/draft-ietf-hip-dex-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-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 Fri Mar 13 10:45:39 2020 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 33EB93A0404; Fri, 13 Mar 2020 10:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 TSTfc731fm2k; Fri, 13 Mar 2020 10:45:34 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 C4ACB3A0402; Fri, 13 Mar 2020 10:45:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 79C166212C; Fri, 13 Mar 2020 13:45:31 -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 2RFxHLY1bdku; Fri, 13 Mar 2020 13:45:12 -0400 (EDT) Received: from lx140e.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 E246762111; Fri, 13 Mar 2020 13:45:11 -0400 (EDT) From: Robert Moskowitz To: Roman Danyliw , The IESG Cc: draft-ietf-hip-dex@ietf.org, hip-chairs@ietf.org, hipsec@ietf.org, Gonzalo Camarillo References: <158334648514.29413.16902420341202011591@ietfa.amsl.com> Message-ID: Date: Fri, 13 Mar 2020 13:45:06 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3E58DD0C462A35E0235A32D7" Content-Language: en-US Archived-At: Subject: Re: [Hipsec] Roman Danyliw's Discuss on draft-ietf-hip-dex-13: (with DISCUSS and COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2020 17:45:37 -0000 This is a multi-part message in MIME format. --------------3E58DD0C462A35E0235A32D7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I will be pushing out v 15 shortly with some more fixes.  This way you can review them as I go, rather in one go.  The items I previously said 'fixed' were in ver 14. On 3/6/20 9:21 AM, Robert Moskowitz wrote: > > > On 3/4/20 1:28 PM, Roman Danyliw via Datatracker wrote: >> Roman Danyliw has entered the following ballot position for >> draft-ietf-hip-dex-13: Discuss >> >> 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 tohttps://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-dex/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> (initial ballot now that this draft is deferred) >> >> ** Section 1.2. Thanks for the scoping provided by this applicability >> statement. Given the reduced security that DEX will provide, IMO it needs a >> bit more precision (and caution). > > And I should point out it gives more security that has been provided > in these classes of devices in the past. > >> OLD >> HIP DEX MUST only be used in communicating with such constrained >> devices (e.g., class 0 and 1 devices as defined in section 3 in >> [RFC7228]). >> >> NEW >> >> HIP DEX MUST only be used when one of the peers is a class 0 or 1 constrained >> device as defined in Section 3 of [RFC7228]. HIP DEX MUST NOT be used if both >> peers are class 2 constrained devices or have greater capability. > > Done. > >> ** Section 3.2.1, Per “Since collision-resistance is not possible with the >> tools at hand, any reasonable function (e.g. FOLD) that takes the full value >> of the HI into generating the HIT can be used, provided that collision >> detection is part of the HIP-DEX deployment design. This is achieved here >> through either an ACL or some other lookup process that externally binds the >> HIT and HI.”, when exactly should this ACL lookup occur? Please provide >> guidance in an explicit step in the appropriate packet processing section >> (i.e., in Section 6.*) on when this should be. > > I will look into this.  It is during I2 and R2 processing as that is > when the recipient can trust that the HI is for the HIT. > > There is also a ACL check for I1 and R1, but that is just to limit who > to talk to, not is the who claim valid. > > Also the constrained device may not have ACL checking capability. No > way to update the ACL in a sensor, for example.  In this case the > password authentication is required. > > I will look at the places to make sure this is covered. See sec 7.1 > > >> ** Section 5.2.1 – Is this list of DH Group IDs intended to be a subset of the >> HIP Group ID sub-registry? If so, Curve25519 and Curve448 don’t appear to be >> in the >> https://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml#hip-parameters-5? >> Should they be registered? > > > Hmmm. for some reason I thought this was handled.  I will check it out > and if I am missed it, I will update the IANA section. Done.  I think. > >> ** Section 6.3. Per “Some payload protection mechanisms have their own Key >> Derivation Function, and if so this mechanism SHOULD be used.”, if the payload >> protection mechanisms have their own KDF, how would their security properties >> be trusted if their KDF is NOT used? Why is this SHOULD not a MUST? > > I need to reread this section before commenting.  If I remember right, > this is a dodge clause that someone wanted.  I may just end up pulling it. I pulled this text, but kept it as a comment in the XML if someone later things it is needed.  ;) And with this I am pushing out ver 15 for you to review.  As you said in the DOTS wg, version numbers are free. > >> ** Section 6.3. The input to CKDR-Extract seems underspecified: >> -- Per the definition of IKM, when should these different inputs be used (at >> least two appear to be specified)? References to Kij are made in this section >> and in other parts of the document, but they aren’t input for CKDR-Extract()? > > Will research this and see if more text is needed and how. > >> -- Per “where ‘CKDF-Extract’ is an octet string “ in the definition of “info” >> in CKDR-Extract(), what encoding should be used to convert that into an octet >> string? Is it ASCII, as in 067 075 068 070 045 069 120 116 114 097 099 116? > > Will check this too. > >> ** Section 9. Please add language to the effect that “production deployments >> of this specification MUST NOT use the NULL-ENCRYPT HIP_CIPHER” (to mirror the >> language already stated in Section 5.2.2 on the topic). > > Good point.  Will do. > >> ** Section 9.2. This mandatory guidance to validate public keys is helpful. >> Please provide guidance in an explicit step in the appropriate packet >> processing section (i.e., in Section 6.*) on when this should be done. > > I thought I did.  Grumble.  Will take care of this too. > >> Two “discuss discuss”-es with the caveat that I didn’t follow the WG >> discussions. >> >> ** The following seems to indicate we don’t have everything we need to publish >> a standards track document: -- Section 6. “It should be noted that many of the >> packet processing rules are denoted here with "SHOULD" but may be updated to >> "MUST" when further implementation experience provides better guidance.” > > I did not want this, if I recall correctly.  It was something of a > standard wording back when this was first done.  At this point, I will > pull this.  It is not uncommon that a standard goes out and then some > years later deployment teaches us things about what SHOULD and what MUST. > > >> -- Section 9. “o The puzzle mechanism using CMAC explained in Section 4.1.1 >> may need further study regarding the level of difficulty in order to establish >> best practices with current generation of constrained devices.” >> >> If there isn’t sufficient implementation experience, why isn’t this document >> experimental? What is the plan for getting better guidance? Is there a risk >> in not having this clarity? > > Actually this is another area that can be pulled now.  Rene did > testing on the difficulty and I believe we captured his experiences.  > I will look at this and clarify. > >> ** Section 9.1. Thanks for this section. However, I’m not convinced that >> SECP160R1 is needed. DEX is already selectively profiling RFC7401 (i.e., its >> already choosing to exclude certain things) and there are “no production” >> implementation of DEX. What is the rationale for keeping it? > > In the workgroup I was asked to keep it in?  To /harmonize/ with other > areas of constrained security?  This is some years back though, and it > is another area where by this time, we have enough to drop it?  I am > willing to, but I should ask on the HIPSEC list and see what private > replies I get. > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> ** Section 3.0. Per “Thus, it is not expected that these parameters are >> carried in every packet, but other methods are used to map the data packets to >> the corresponding His”, what are these other methods? > > This text is lifted right out of sec 3 of rfc7401.  ESP SPIs are a > stated example further in that paragraph. > >> ** Section 3.1. Per “There are two advantages of using a hashed encoding over >> the actual variable-sized public key in protocols.”, perhaps as a reminder is >> in order that in this document the HIT isn’t a hashed encoding but a compressed. > > A case of lifting text from 7401 where it needs to be adjusted a bit.  > I will make the change. > >> ** Section 4.1. Per “Note that in some cases it may be possible to replace >> this trigger packet by some other form of a trigger, in which case the >> protocol starts with the Responder sending the R1 packet.”, how does this >> additional trigger occur? > > Some packet that has enough information for the receiver to deduce > that an I1 COULD have been sent and to then respond with an R1 to see > if the sender supports HIP. > > None have been defined.  This actually goes back to 5201.  More of a > placeholder to allow others to make adjustments in their implementation. > >> ** Section 4.1. Per “In such cases, another mechanism to convey the Initiator's >> supported DH Groups (e.g., by using a default group) must be specified.”, >> where/how would it be specified? > > Again, nothing has been specified, but in a closed environment it was > thought that an ACL or other data store would contain enough > information, like the supported DH Groups to successfully trigger an > R1 without receiving an I1.  This is more a placeholder for any > developer that is working on an alternative to using the I1 to note > all that must be done if something other than an I1 is used. > > "If you are going to try and optimize this protocol, remember all that > you have to include" kind of thing. > >> ** Section 4.1.2.1. Per “This strategy is based on a timeout that is set to a >> value larger than the worst-case anticipated round-trip time (RTT ).”, how is >> the worst case RTT computed? > > IIRC, the implementers want this in.  It goes back to 5201, sec 6.6.  > Perhaps one that is still around (hint, Jeff or Tom) can comment. > > >> ** Section 5.3.2. Per “Responder sets the source HIT in the R2 packet based on >> the destination HIT from the I1 packet”, shouldn’t this say “Responder sets the >> source HIT in the _R1_ packet …”? > > OOPS!  Good catch.  Fixed.  Probably some poor job (by me!) in copying > and pasting text. > >> ** Section 5.3.2. Per “Based on the deviating DH group ID in the HOST_ID >> parameter, the Initiator then SHOULD abort …”, why not MUST abort? > > A MUST costs a round trip.  It is possible that the Initiator, based > on local policy, can make a decision to go with the received R1 rather > than restart the exchange.  Thus we chose SHOULD here over MUST. > >> ** Section 6.8. Step 5. Per “5. If any of the checks above fail, there is a >> high probability of an ongoing man-in-the-middle or other security attack. The >> system SHOULD act accordingly, based on its local policy.”, this guidance seems >> underspecified. Could the text at least provide a recommendation of aborting >> and logging? > > Seems reasonable request.  But this text goes back to 5201. Perhaps > some of the HIPv1 and/or v2 implementors can tell want they do here. > >> ** Section 9. Per “The strength of the keys for the Pair-wise Key SA is based >> on the quality of the random keying material. As either peer may be a sensor >> or an actuator device, there is a natural concern about the quality of its >> random number generator.”, this is helpful caution. What guidance can be given >> to ameliorate the concern? > > When we did IEEE 802.11i, we actually had an annex giving pseudo code > for gathering entropy by listening to the radio noise or how to build > an ring-occilator on your chip. > > Is there any good IETF RFC recommendation on a good RND for > constrained devices?  I would be happy to include copied text or a > reference. > >> ** Editorial >> -- Section 1.2. The sentence “Also, it is often the case that HIP DEX …” is >> repeated twice. > > Thanks.   Fixed.  I kept the 2nd one as the separate para.  Reads > better in my opinion. > >> -- Section 4.1. s/the the/the/ > > fixed. > >> -- Section 6.3. Typo. >> s/The HIP DEX KEYMAT process is based on the is the/ >> The HIP DEX KEYMAT process is based on the/ > > fixed. > >> -- Section 9.2. Editorial. Per “With the curves specified here, there is a >> straightforward key extraction attack, which is a very serious problem the use >> of static keys in HIP-DEX”, there appears to be some missing words – perhaps “… >> with the use of static keys by HIP-DEX”. > > thanks.  Yes, I have added "with" > > -- Standard Robert Moskowitz Owner HTT Consulting C:248-219-2059 F:248-968-2824 E:rgm@labs.htt-consult.com There's no limit to what can be accomplished if it doesn't matter who gets the credit --------------3E58DD0C462A35E0235A32D7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I will be pushing out v 15 shortly with some more fixes.  This way you can review them as I go, rather in one go.  The items I previously said 'fixed' were in ver 14.

On 3/6/20 9:21 AM, Robert Moskowitz wrote:


On 3/4/20 1:28 PM, Roman Danyliw via Datatracker wrote:
Roman Danyliw has entered the following ballot position for
draft-ietf-hip-dex-13: Discuss

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-dex/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(initial ballot now that this draft is deferred)

** Section 1.2.  Thanks for the scoping provided by this applicability
statement.  Given the reduced security that DEX will provide, IMO it needs a
bit more precision (and caution).

And I should point out it gives more security that has been provided in these classes of devices in the past.

OLD
   HIP DEX MUST  only be used in communicating with such constrained
   devices (e.g., class 0 and 1 devices as defined in section 3 in
   [RFC7228]).

NEW

HIP DEX MUST only be used when one of the peers is a class 0 or 1 constrained
device as defined in Section 3 of [RFC7228].  HIP DEX MUST NOT be used if both
peers are class 2 constrained devices or have greater capability.

Done.

** Section 3.2.1, Per “Since collision-resistance is not possible with the
tools at hand, any reasonable function (e.g.  FOLD) that takes the full value
of the HI into generating the HIT can be used, provided that collision
detection is part of the HIP-DEX deployment design.  This is achieved here
through either an ACL or some other lookup process that externally binds the
HIT and HI.”, when exactly should this ACL lookup occur?  Please provide
guidance in an explicit step in the appropriate packet processing section
(i.e., in Section 6.*) on when this should be.

I will look into this.  It is during I2 and R2 processing as that is when the recipient can trust that the HI is for the HIT.

There is also a ACL check for I1 and R1, but that is just to limit who to talk to, not is the who claim valid.

Also the constrained device may not have ACL checking capability.  No way to update the ACL in a sensor, for example.  In this case the password authentication is required.

I will look at the places to make sure this is covered.

See sec 7.1



** Section 5.2.1 – Is this list of DH Group IDs intended to be a subset of the
HIP Group ID sub-registry?  If so, Curve25519 and Curve448 don’t appear to be
in the
https://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml#hip-parameters-5?
 Should they be registered?


Hmmm. for some reason I thought this was handled.  I will check it out and if I am missed it, I will update the IANA section.

Done.  I think.


** Section 6.3.  Per “Some payload protection mechanisms have their own Key
Derivation Function, and if so this mechanism SHOULD be used.”, if the payload
protection mechanisms have their own KDF, how would their security properties
be trusted if their KDF is NOT used?  Why is this SHOULD not a MUST?

I need to reread this section before commenting.  If I remember right, this is a dodge clause that someone wanted.  I may just end up pulling it.

I pulled this text, but kept it as a comment in the XML if someone later things it is needed.  ;)

And with this I am pushing out ver 15 for you to review.  As you said in the DOTS wg, version numbers are free.


** Section 6.3.  The input to CKDR-Extract seems underspecified:
-- Per the definition of IKM, when should these different inputs be used (at
least two appear to be specified)?  References to Kij are made in this section
and in other parts of the document, but they aren’t input for CKDR-Extract()?

Will research this and see if more text is needed and how.

-- Per “where ‘CKDF-Extract’ is an octet string “ in the definition of “info”
in CKDR-Extract(), what encoding should be used to convert that into an octet
string?  Is it ASCII, as in 067 075 068 070 045 069 120 116 114 097 099 116?

Will check this too.

** Section 9.  Please add language to the effect that “production deployments
of this specification MUST NOT use the NULL-ENCRYPT HIP_CIPHER” (to mirror the
language already stated in Section 5.2.2 on the topic).

Good point.  Will do.

** Section 9.2.  This mandatory guidance to validate public keys is helpful. 
Please provide guidance in an explicit step in the appropriate packet
processing section (i.e., in Section 6.*) on when this should be done.

I thought I did.  Grumble.  Will take care of this too.

Two “discuss discuss”-es with the caveat that I didn’t follow the WG
discussions.

** The following seems to indicate we don’t have everything we need to publish
a standards track document: -- Section 6.  “It should be noted that many of the
packet processing rules are denoted here with "SHOULD" but may be updated to
"MUST" when further implementation experience provides better guidance.”

I did not want this, if I recall correctly.  It was something of a standard wording back when this was first done.  At this point, I will pull this.  It is not uncommon that a standard goes out and then some years later deployment teaches us things about what SHOULD and what MUST.


-- Section 9.  “o  The puzzle mechanism using CMAC explained in Section 4.1.1
may need further study regarding the level of difficulty in order to establish
best practices with current generation of  constrained devices.”

If there isn’t sufficient implementation experience, why isn’t this document
experimental?  What is the plan for getting better guidance?  Is there a risk
in not having this clarity?

Actually this is another area that can be pulled now.  Rene did testing on the difficulty and I believe we captured his experiences.  I will look at this and clarify.

** Section 9.1.  Thanks for this section.  However, I’m not convinced that
SECP160R1 is needed.  DEX is already selectively profiling RFC7401 (i.e., its
already choosing to exclude certain things) and there are “no production”
implementation of DEX.  What is the rationale for keeping it?

In the workgroup I was asked to keep it in?  To harmonize with other areas of constrained security?  This is some years back though, and it is another area where by this time, we have enough to drop it?  I am willing to, but I should ask on the HIPSEC list and see what private replies I get.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** Section 3.0.  Per “Thus, it is not expected that these parameters are
carried in every packet, but other methods are used to map the data packets to
the corresponding His”, what are these other methods?

This text is lifted right out of sec 3 of rfc7401.  ESP SPIs are a stated example further in that paragraph.

** Section 3.1.  Per “There are two advantages of using a hashed encoding  over
the actual variable-sized public key in protocols.”, perhaps as a reminder is
in order that in this document the HIT isn’t a hashed encoding but a compressed.

A case of lifting text from 7401 where it needs to be adjusted a bit.  I will make the change.

** Section 4.1.  Per “Note that in some cases it may be possible to replace
this trigger packet by some  other form of a trigger, in which case the
protocol starts with the Responder sending the R1 packet.”, how does this
additional trigger occur?

Some packet that has enough information for the receiver to deduce that an I1 COULD have been sent and to then respond with an R1 to see if the sender supports HIP.

None have been defined.  This actually goes back to 5201.  More of a placeholder to allow others to make adjustments in their implementation. 

** Section 4.1. Per “In such cases, another mechanism to convey the Initiator's
supported DH Groups (e.g., by using a default group) must be specified.”,
where/how would it be specified?

Again, nothing has been specified, but in a closed environment it was thought that an ACL or other data store would contain enough information, like the supported DH Groups to successfully trigger an R1 without receiving an I1.  This is more a placeholder for any developer that is working on an alternative to using the I1 to note all that must be done if something other than an I1 is used.

"If you are going to try and optimize this protocol, remember all that you have to include" kind of thing.

** Section 4.1.2.1. Per “This strategy is based on a timeout that is set to a
value larger than the worst-case anticipated round-trip time (RTT ).”, how is
the worst case RTT computed?

IIRC, the implementers want this in.  It goes back to 5201, sec 6.6.  Perhaps one that is still around (hint, Jeff or Tom) can comment.


** Section 5.3.2.  Per “Responder sets the source HIT in the R2 packet based on
the destination HIT from the I1 packet”, shouldn’t this say “Responder sets the
source HIT in the _R1_ packet …”?

OOPS!  Good catch.  Fixed.  Probably some poor job (by me!) in copying and pasting text.

** Section 5.3.2.  Per “Based on the deviating DH group ID in the HOST_ID
parameter, the Initiator then SHOULD abort …”, why not MUST abort?

A MUST costs a round trip.  It is possible that the Initiator, based on local policy, can make a decision to go with the received R1 rather than restart the exchange.  Thus we chose SHOULD here over MUST.

** Section 6.8. Step 5.  Per “5.  If any of the checks above fail, there is a
high probability of an ongoing man-in-the-middle or other security attack.  The
system SHOULD act accordingly, based on its local policy.”, this guidance seems
underspecified.  Could the text at least provide a recommendation of aborting
and logging?

Seems reasonable request.  But this text goes back to 5201.  Perhaps some of the HIPv1 and/or v2 implementors can tell want they do here.

** Section 9.  Per “The strength of the keys for the Pair-wise Key SA is based
on the quality of the random keying material.  As either peer may be a sensor
or an actuator device, there is a natural concern about the quality of its
random number generator.”, this is helpful caution. What guidance can be given
to ameliorate the concern?

When we did IEEE 802.11i, we actually had an annex giving pseudo code for gathering entropy by listening to the radio noise or how to build an ring-occilator on your chip.

Is there any good IETF RFC recommendation on a good RND for constrained devices?  I would be happy to include copied text or a reference.

** Editorial
-- Section 1.2.  The sentence “Also, it is often the case that HIP DEX …” is
repeated twice.

Thanks.   Fixed.  I kept the 2nd one as the separate para.  Reads better in my opinion.

-- Section 4.1. s/the the/the/

fixed.

-- Section 6.3.  Typo.
s/The HIP DEX KEYMAT process is based on the is the/
The HIP DEX KEYMAT process is based on the/

fixed.

-- Section 9.2.  Editorial.  Per “With the curves specified here, there is a
straightforward key extraction attack, which is a very serious problem the use
of static keys in HIP-DEX”, there appears to be some missing words – perhaps “…
with the use of static keys by HIP-DEX”.

thanks.  Yes, I have added "with"



--
Standard Robert Moskowitz
Owner
HTT Consulting
C:      248-219-2059
F:      248-968-2824
E:      rgm@labs.htt-consult.com

There's no limit to what can be accomplished if it doesn't matter who gets the credit
--------------3E58DD0C462A35E0235A32D7-- From nobody Fri Mar 13 10:47:42 2020 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 1F6253A040C; Fri, 13 Mar 2020 10:47:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: hipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.121.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: hipsec@ietf.org Message-ID: <158412165804.3058.1689911274575116355@ietfa.amsl.com> Date: Fri, 13 Mar 2020 10:47:38 -0700 Archived-At: Subject: [Hipsec] I-D Action: draft-ietf-hip-dex-15.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2020 17:47:38 -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 WG of the IETF. Title : HIP Diet EXchange (DEX) Authors : Robert Moskowitz Rene Hummen Miika Komu Filename : draft-ietf-hip-dex-15.txt Pages : 59 Date : 2020-03-13 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. 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. Unlike HIPv2, HIP DEX does not support Perfect Forward Secrecy (PFS), and MUST only be used on devices where PFS is prohibitively expensive. 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-hip-dex-15 https://datatracker.ietf.org/doc/html/draft-ietf-hip-dex-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-15 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 Fri Mar 13 11:43:46 2020 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 B576C3A08F4; Fri, 13 Mar 2020 11:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 2NO8ZyViO6Ec; Fri, 13 Mar 2020 11:43:42 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 8F28E3A08F0; Fri, 13 Mar 2020 11:43:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id BF7086212C; Fri, 13 Mar 2020 14:43: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 7SHfuzjye9Wv; Fri, 13 Mar 2020 14:43:34 -0400 (EDT) Received: from lx140e.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 DFA8862113; Fri, 13 Mar 2020 14:43:33 -0400 (EDT) To: Suresh Krishnan Cc: The IESG , "draft-ietf-hip-dex@ietf.org" , "j.ahrenholz@tempered.io" , "hip-chairs@ietf.org" , Gonzalo Camarillo , "hipsec@ietf.org" References: <158329724383.7687.5696211532188484676@ietfa.amsl.com> <9336814E-6390-47B1-AD35-38F09A6147AE@kaloom.com> From: Robert Moskowitz Message-ID: <222afffb-896c-3124-997d-99119166ed82@labs.htt-consult.com> Date: Fri, 13 Mar 2020 14:43:16 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <9336814E-6390-47B1-AD35-38F09A6147AE@kaloom.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Hipsec] Suresh Krishnan's Discuss on draft-ietf-hip-dex-13: (with DISCUSS) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2020 18:43:44 -0000 Suresh, Your text appeared in ver 14.  Please check it out. thank you. Bob On 3/5/20 2:00 PM, Suresh Krishnan wrote: > Hi Bob, > This text works for me. I will clear as soon as the new revision hits. > > Regards > Suresh > >> On Mar 5, 2020, at 11:04 AM, Robert Moskowitz wrote: >> >> Here is the text I put together for revising sec 5.4 (see below). >> >> On 3/3/20 11:47 PM, Suresh Krishnan via Datatracker wrote: >>> Suresh Krishnan has entered the following ballot position for >>> draft-ietf-hip-dex-13: Discuss >>> >>> 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-dex/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> This should be pretty straightforward to resolve. >>> >>> * Section 5.4.: >>> >>> The ICMPv6 Parameter Problem messages to be sent need a Code field to be set in >>> addition to the Pointer. What Code should be used in this message? Please >>> specify this. >>> >>> >>> >>> >>> >> 5.4. ICMP Messages >> >> When a HIP implementation detects a problem with an incoming packet, >> and it either cannot determine the identity of the sender of the >> packet or does not have any existing HIP association with the sender >> of the packet, it MAY respond with an ICMP packet. Any such reply >> MUST be rate-limited as described in [RFC4443]. In most cases, the >> ICMP packet has the Parameter Problem type (12 for ICMPv4, 4 for >> ICMPv6) and Code of 0. The Pointer field pointing to the field that >> caused the ICMP message to be generated, for example to the first 8 >> bytes of a UDP payload for "SPI is Unknown". The problem cases >> specified in Section 5.4. of [RFC7401] also apply to HIP DEX. >> From nobody Fri Mar 13 11:46:03 2020 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 BD0EA3A0908; Fri, 13 Mar 2020 11:46:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan via Datatracker To: "The IESG" Cc: draft-ietf-hip-dex@ietf.org, hip-chairs@ietf.org, hipsec@ietf.org, Gonzalo Camarillo , gonzalo.camarillo@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 6.121.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Suresh Krishnan Message-ID: <158412516069.3078.6778344229402146247@ietfa.amsl.com> Date: Fri, 13 Mar 2020 11:46:00 -0700 Archived-At: Subject: [Hipsec] Suresh Krishnan's No Objection on draft-ietf-hip-dex-15: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2020 18:46:01 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-hip-dex-15: 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-dex/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS. From nobody Tue Mar 17 06:04:01 2020 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 416ED3A1E5B; Tue, 17 Mar 2020 06:03:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: hipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.121.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: hipsec@ietf.org Message-ID: <158445023917.32033.3959551768859762395@ietfa.amsl.com> Date: Tue, 17 Mar 2020 06:03:59 -0700 Archived-At: Subject: [Hipsec] I-D Action: draft-ietf-hip-dex-16.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 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, 17 Mar 2020 13:04:00 -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 WG of the IETF. Title : HIP Diet EXchange (DEX) Authors : Robert Moskowitz Rene Hummen Miika Komu Filename : draft-ietf-hip-dex-16.txt Pages : 59 Date : 2020-03-17 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. 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. Unlike HIPv2, HIP DEX does not support Perfect Forward Secrecy (PFS), and MUST only be used on devices where PFS is prohibitively expensive. 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-hip-dex-16 https://datatracker.ietf.org/doc/html/draft-ietf-hip-dex-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-16 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 Tue Mar 17 06:11:58 2020 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 61EFB3A00AD; Tue, 17 Mar 2020 06:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 JjFnfEbyXtBW; Tue, 17 Mar 2020 06:11:51 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 011243A0064; Tue, 17 Mar 2020 06:11:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 61FC1621AA; Tue, 17 Mar 2020 09:11:48 -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 aY+6dIzE4lqO; Tue, 17 Mar 2020 09:11:31 -0400 (EDT) Received: from lx140e.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 4B3BA621A0; Tue, 17 Mar 2020 09:11:31 -0400 (EDT) From: Robert Moskowitz To: Roman Danyliw , The IESG Cc: draft-ietf-hip-dex@ietf.org, hip-chairs@ietf.org, hipsec@ietf.org, Gonzalo Camarillo References: <158334648514.29413.16902420341202011591@ietfa.amsl.com> Message-ID: <5ada15b1-0a2d-589e-4f4c-744124b5c479@labs.htt-consult.com> Date: Tue, 17 Mar 2020 09:11:24 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------37086C965156FEBA0BB7D793" Content-Language: en-US Archived-At: Subject: Re: [Hipsec] Roman Danyliw's Discuss on draft-ietf-hip-dex-13: (with DISCUSS and COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 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, 17 Mar 2020 13:11:55 -0000 This is a multi-part message in MIME format. --------------37086C965156FEBA0BB7D793 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I am cutting off all I have responded to in v 14 & 15. I have posted ver 16. there is one outstanding issue about the proper octet encoding, see below.  I am open to what to use for that. Otherwise, I believe I have addressed all of Roman's comments either with changes to the draft of explanations in my email responses. On 3/6/20 9:21 AM, Robert Moskowitz wrote: > > > On 3/4/20 1:28 PM, Roman Danyliw via Datatracker wrote: >> Roman Danyliw has entered the following ballot position for >> draft-ietf-hip-dex-13: Discuss >> >> 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 tohttps://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-dex/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> (initial ballot now that this draft is deferred) >> >> > >> ** Section 6.3. The input to CKDR-Extract seems underspecified: >> -- Per the definition of IKM, when should these different inputs be used (at >> least two appear to be specified)? References to Kij are made in this section >> and in other parts of the document, but they aren’t input for CKDR-Extract()? > > Will research this and see if more text is needed and how. KEYMAT is used for both the Master Key and Pair-wise Key.    The key derivation for the Master Key SA employs always both the    Extract and Expand phases.  The Pair-wise Key SA needs only the    Extract phase when the key is smaller or equal to 128 bits, but    otherwise requires also the Expand phase. So there are 2 IKMs:        IKM       Input keying material                    the Diffie-Hellman derived key, concatenated with the                      random I_NONCE value for the Master Key SA                    the Diffie-Hellman derived key, concatenated with the                      random values of the ENCRYPTED_KEY parameters in                      the same order as the HITs with sort(HIT-I | HIT-R)                      for the Pair-wise Key SA If you want the IKM better explained, I will expand the text somehow.  This is in an artwork block right now. And yes, Kij is used in both places.  This is the result of extensive discussions with Hugo Krawczyk and Lily Chen on how to safely use CMAC.  Or as safe as possible and within the bounds of this application.  Those discussions are somewhere back in my archives... > >> -- Per “where ‘CKDF-Extract’ is an octet string “ in the definition of “info” >> in CKDR-Extract(), what encoding should be used to convert that into an octet >> string? Is it ASCII, as in 067 075 068 070 045 069 120 116 114 097 099 116? > > Will check this too. This approach I have historically seen a lot in standards.  The character string is supplied with the instruction to use the octet equiv.  You make a very valid point.  In fact NIST SP800-185 is very explicit in supplying the text string and then the bit representation. Using an online text to octet converter (https://www.browserling.com/tools/text-to-octal) I got: 103 113 104 106 55 105 170 164 162 141 143 164 So WHAT IS the proper value?  Can an Implementer jump in here?  I will specify whatever binary is agreed on... > >> ** Section 9. Please add language to the effect that “production deployments >> of this specification MUST NOT use the NULL-ENCRYPT HIP_CIPHER” (to mirror the >> language already stated in Section 5.2.2 on the topic). > > Good point.  Will do. Done.  See sec 9.3 > >> ** Section 9.2. This mandatory guidance to validate public keys is helpful. >> Please provide guidance in an explicit step in the appropriate packet >> processing section (i.e., in Section 6.*) on when this should be done. > > I thought I did.  Grumble.  Will take care of this too. Done. Sec 6.7 step 4 and 6.8 step 5. > >> Two “discuss discuss”-es with the caveat that I didn’t follow the WG >> discussions. >> >> ** The following seems to indicate we don’t have everything we need to publish >> a standards track document: -- Section 6. “It should be noted that many of the >> packet processing rules are denoted here with "SHOULD" but may be updated to >> "MUST" when further implementation experience provides better guidance.” > > I did not want this, if I recall correctly.  It was something of a > standard wording back when this was first done.  At this point, I will > pull this.  It is not uncommon that a standard goes out and then some > years later deployment teaches us things about what SHOULD and what MUST. I have pulled this para. > >> -- Section 9. “o The puzzle mechanism using CMAC explained in Section 4.1.1 >> may need further study regarding the level of difficulty in order to establish >> best practices with current generation of constrained devices.” >> >> If there isn’t sufficient implementation experience, why isn’t this document >> experimental? What is the plan for getting better guidance? Is there a risk >> in not having this clarity? > > Actually this is another area that can be pulled now.  Rene did > testing on the difficulty and I believe we captured his experiences.  > I will look at this and clarify. I have dropped this paragraph.  The proper behavior, based on testing, is described in sec 7.  This was old text that should have been pulled versions ago. > >> ** Section 9.1. Thanks for this section. However, I’m not convinced that >> SECP160R1 is needed. DEX is already selectively profiling RFC7401 (i.e., its >> already choosing to exclude certain things) and there are “no production” >> implementation of DEX. What is the rationale for keeping it? > > In the workgroup I was asked to keep it in?  To /harmonize/ with other > areas of constrained security?  This is some years back though, and it > is another area where by this time, we have enough to drop it?  I am > willing to, but I should ask on the HIPSEC list and see what private > replies I get. I have removed SECP160R1.  I have kept the text as comments in the XML if there is later pushback for including it. > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> ** Section 3.0. Per “Thus, it is not expected that these parameters are >> carried in every packet, but other methods are used to map the data packets to >> the corresponding His”, what are these other methods? > > This text is lifted right out of sec 3 of rfc7401.  ESP SPIs are a > stated example further in that paragraph. > >> ** Section 3.1. Per “There are two advantages of using a hashed encoding over >> the actual variable-sized public key in protocols.”, perhaps as a reminder is >> in order that in this document the HIT isn’t a hashed encoding but a compressed. > > A case of lifting text from 7401 where it needs to be adjusted a bit.  > I will make the change. Change made. > >> ** Section 4.1. Per “Note that in some cases it may be possible to replace >> this trigger packet by some other form of a trigger, in which case the >> protocol starts with the Responder sending the R1 packet.”, how does this >> additional trigger occur? > > Some packet that has enough information for the receiver to deduce > that an I1 COULD have been sent and to then respond with an R1 to see > if the sender supports HIP. > > None have been defined.  This actually goes back to 5201.  More of a > placeholder to allow others to make adjustments in their implementation. > >> ** Section 4.1. Per “In such cases, another mechanism to convey the Initiator's >> supported DH Groups (e.g., by using a default group) must be specified.”, >> where/how would it be specified? > > Again, nothing has been specified, but in a closed environment it was > thought that an ACL or other data store would contain enough > information, like the supported DH Groups to successfully trigger an > R1 without receiving an I1.  This is more a placeholder for any > developer that is working on an alternative to using the I1 to note > all that must be done if something other than an I1 is used. > > "If you are going to try and optimize this protocol, remember all that > you have to include" kind of thing. > >> ** Section 4.1.2.1. Per “This strategy is based on a timeout that is set to a >> value larger than the worst-case anticipated round-trip time (RTT ).”, how is >> the worst case RTT computed? > > IIRC, the implementers want this in.  It goes back to 5201, sec 6.6.  > Perhaps one that is still around (hint, Jeff or Tom) can comment. I am leaving this as is.  I am open to changes, if someone provides me with actual numbers. > >> ** Section 5.3.2. Per “Based on the deviating DH group ID in the HOST_ID >> parameter, the Initiator then SHOULD abort …”, why not MUST abort? > > A MUST costs a round trip.  It is possible that the Initiator, based > on local policy, can make a decision to go with the received R1 rather > than restart the exchange.  Thus we chose SHOULD here over MUST. > >> ** Section 6.8. Step 5. Per “5. If any of the checks above fail, there is a >> high probability of an ongoing man-in-the-middle or other security attack. The >> system SHOULD act accordingly, based on its local policy.”, this guidance seems >> underspecified. Could the text at least provide a recommendation of aborting >> and logging? > > Seems reasonable request.  But this text goes back to 5201. Perhaps > some of the HIPv1 and/or v2 implementors can tell want they do here. > >> ** Section 9. Per “The strength of the keys for the Pair-wise Key SA is based >> on the quality of the random keying material. As either peer may be a sensor >> or an actuator device, there is a natural concern about the quality of its >> random number generator.”, this is helpful caution. What guidance can be given >> to ameliorate the concern? > > When we did IEEE 802.11i, we actually had an annex giving pseudo code > for gathering entropy by listening to the radio noise or how to build > an ring-occilator on your chip. > > Is there any good IETF RFC recommendation on a good RND for > constrained devices?  I would be happy to include copied text or a > reference. Additional text has been added. --------------37086C965156FEBA0BB7D793 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I am cutting off all I have responded to in v 14 & 15.

I have posted ver 16. 

there is one outstanding issue about the proper octet encoding, see below.  I am open to what to use for that.

Otherwise, I believe I have addressed all of Roman's comments either with changes to the draft of explanations in my email responses.


On 3/6/20 9:21 AM, Robert Moskowitz wrote:


On 3/4/20 1:28 PM, Roman Danyliw via Datatracker wrote:
Roman Danyliw has entered the following ballot position for
draft-ietf-hip-dex-13: Discuss

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-dex/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(initial ballot now that this draft is deferred)

   

** Section 6.3.  The input to CKDR-Extract seems underspecified:
-- Per the definition of IKM, when should these different inputs be used (at
least two appear to be specified)?  References to Kij are made in this section
and in other parts of the document, but they aren’t input for CKDR-Extract()?

Will research this and see if more text is needed and how.

KEYMAT is used for both the Master Key and Pair-wise Key.

   The key derivation for the Master Key SA employs always both the
   Extract and Expand phases.  The Pair-wise Key SA needs only the
   Extract phase when the key is smaller or equal to 128 bits, but
   otherwise requires also the Expand phase.

So there are 2 IKMs:

       IKM       Input keying material
                   the Diffie-Hellman derived key, concatenated with the
                     random I_NONCE value for the Master Key SA
                   the Diffie-Hellman derived key, concatenated with the
                     random values of the ENCRYPTED_KEY parameters in
                     the same order as the HITs with sort(HIT-I | HIT-R)
                     for the Pair-wise Key SA

If you want the IKM better explained, I will expand the text somehow.  This is in an artwork block right now.


And yes, Kij is used in both places.  This is the result of extensive discussions with Hugo Krawczyk and Lily Chen on how to safely use CMAC.  Or as safe as possible and within the bounds of this application.  Those discussions are somewhere back in my archives...


-- Per “where ‘CKDF-Extract’ is an octet string “ in the definition of “info”
in CKDR-Extract(), what encoding should be used to convert that into an octet
string?  Is it ASCII, as in 067 075 068 070 045 069 120 116 114 097 099 116?

Will check this too.

This approach I have historically seen a lot in standards.  The character string is supplied with the instruction to use the octet equiv.  You make a very valid point.  In fact NIST SP800-185 is very explicit in supplying the text string and then the bit representation.

Using an online text to octet converter (https://www.browserling.com/tools/text-to-octal) I got:

103 113 104 106 55 105 170 164 162 141 143 164

So WHAT IS the proper value?  Can an Implementer jump in here?  I will specify whatever binary is agreed on...


** Section 9.  Please add language to the effect that “production deployments
of this specification MUST NOT use the NULL-ENCRYPT HIP_CIPHER” (to mirror the
language already stated in Section 5.2.2 on the topic).

Good point.  Will do.

Done.  See sec 9.3


** Section 9.2.  This mandatory guidance to validate public keys is helpful. 
Please provide guidance in an explicit step in the appropriate packet
processing section (i.e., in Section 6.*) on when this should be done.

I thought I did.  Grumble.  Will take care of this too.

Done. Sec 6.7 step 4 and 6.8 step 5.


Two “discuss discuss”-es with the caveat that I didn’t follow the WG
discussions.

** The following seems to indicate we don’t have everything we need to publish
a standards track document: -- Section 6.  “It should be noted that many of the
packet processing rules are denoted here with "SHOULD" but may be updated to
"MUST" when further implementation experience provides better guidance.”

I did not want this, if I recall correctly.  It was something of a standard wording back when this was first done.  At this point, I will pull this.  It is not uncommon that a standard goes out and then some years later deployment teaches us things about what SHOULD and what MUST.

I have pulled this para.


-- Section 9.  “o  The puzzle mechanism using CMAC explained in Section 4.1.1
may need further study regarding the level of difficulty in order to establish
best practices with current generation of  constrained devices.”

If there isn’t sufficient implementation experience, why isn’t this document
experimental?  What is the plan for getting better guidance?  Is there a risk
in not having this clarity?

Actually this is another area that can be pulled now.  Rene did testing on the difficulty and I believe we captured his experiences.  I will look at this and clarify.

I have dropped this paragraph.  The proper behavior, based on testing, is described in sec 7.  This was old text that should have been pulled versions ago.


** Section 9.1.  Thanks for this section.  However, I’m not convinced that
SECP160R1 is needed.  DEX is already selectively profiling RFC7401 (i.e., its
already choosing to exclude certain things) and there are “no production”
implementation of DEX.  What is the rationale for keeping it?

In the workgroup I was asked to keep it in?  To harmonize with other areas of constrained security?  This is some years back though, and it is another area where by this time, we have enough to drop it?  I am willing to, but I should ask on the HIPSEC list and see what private replies I get.

I have removed SECP160R1.  I have kept the text as comments in the XML if there is later pushback for including it.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** Section 3.0.  Per “Thus, it is not expected that these parameters are
carried in every packet, but other methods are used to map the data packets to
the corresponding His”, what are these other methods?

This text is lifted right out of sec 3 of rfc7401.  ESP SPIs are a stated example further in that paragraph.

** Section 3.1.  Per “There are two advantages of using a hashed encoding  over
the actual variable-sized public key in protocols.”, perhaps as a reminder is
in order that in this document the HIT isn’t a hashed encoding but a compressed.

A case of lifting text from 7401 where it needs to be adjusted a bit.  I will make the change.

Change made.


** Section 4.1.  Per “Note that in some cases it may be possible to replace
this trigger packet by some  other form of a trigger, in which case the
protocol starts with the Responder sending the R1 packet.”, how does this
additional trigger occur?

Some packet that has enough information for the receiver to deduce that an I1 COULD have been sent and to then respond with an R1 to see if the sender supports HIP.

None have been defined.  This actually goes back to 5201.  More of a placeholder to allow others to make adjustments in their implementation. 

** Section 4.1. Per “In such cases, another mechanism to convey the Initiator's
supported DH Groups (e.g., by using a default group) must be specified.”,
where/how would it be specified?

Again, nothing has been specified, but in a closed environment it was thought that an ACL or other data store would contain enough information, like the supported DH Groups to successfully trigger an R1 without receiving an I1.  This is more a placeholder for any developer that is working on an alternative to using the I1 to note all that must be done if something other than an I1 is used.

"If you are going to try and optimize this protocol, remember all that you have to include" kind of thing.

** Section 4.1.2.1. Per “This strategy is based on a timeout that is set to a
value larger than the worst-case anticipated round-trip time (RTT ).”, how is
the worst case RTT computed?

IIRC, the implementers want this in.  It goes back to 5201, sec 6.6.  Perhaps one that is still around (hint, Jeff or Tom) can comment.

I am leaving this as is.  I am open to changes, if someone provides me with actual numbers.


** Section 5.3.2.  Per “Based on the deviating DH group ID in the HOST_ID
parameter, the Initiator then SHOULD abort …”, why not MUST abort?

A MUST costs a round trip.  It is possible that the Initiator, based on local policy, can make a decision to go with the received R1 rather than restart the exchange.  Thus we chose SHOULD here over MUST.

** Section 6.8. Step 5.  Per “5.  If any of the checks above fail, there is a
high probability of an ongoing man-in-the-middle or other security attack.  The
system SHOULD act accordingly, based on its local policy.”, this guidance seems
underspecified.  Could the text at least provide a recommendation of aborting
and logging?

Seems reasonable request.  But this text goes back to 5201.  Perhaps some of the HIPv1 and/or v2 implementors can tell want they do here.

** Section 9.  Per “The strength of the keys for the Pair-wise Key SA is based
on the quality of the random keying material.  As either peer may be a sensor
or an actuator device, there is a natural concern about the quality of its
random number generator.”, this is helpful caution. What guidance can be given
to ameliorate the concern?

When we did IEEE 802.11i, we actually had an annex giving pseudo code for gathering entropy by listening to the radio noise or how to build an ring-occilator on your chip.

Is there any good IETF RFC recommendation on a good RND for constrained devices?  I would be happy to include copied text or a reference.

Additional text has been added.


--------------37086C965156FEBA0BB7D793-- From nobody Wed Mar 18 08:48:43 2020 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 D23C73A17D8; Wed, 18 Mar 2020 08:48:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: hipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.121.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: hipsec@ietf.org Message-ID: <158454652175.29929.3568426357846029551@ietfa.amsl.com> Date: Wed, 18 Mar 2020 08:48:41 -0700 Archived-At: Subject: [Hipsec] I-D Action: draft-ietf-hip-dex-17.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 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: Wed, 18 Mar 2020 15:48:42 -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 WG of the IETF. Title : HIP Diet EXchange (DEX) Authors : Robert Moskowitz Rene Hummen Miika Komu Filename : draft-ietf-hip-dex-17.txt Pages : 59 Date : 2020-03-18 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. 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. Unlike HIPv2, HIP DEX does not support Perfect Forward Secrecy (PFS), and MUST only be used on devices where PFS is prohibitively expensive. 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-hip-dex-17 https://datatracker.ietf.org/doc/html/draft-ietf-hip-dex-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-17 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 Wed Mar 18 08:52:37 2020 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 1D4983A17DC; Wed, 18 Mar 2020 08:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ljm70DBgsf9T; Wed, 18 Mar 2020 08:51:26 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 418B13A17DB; Wed, 18 Mar 2020 08:51:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 3728B6212E; Wed, 18 Mar 2020 11:51:24 -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 QtH3-F+xu2aK; Wed, 18 Mar 2020 11:51:04 -0400 (EDT) Received: from lx140e.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 9060162111; Wed, 18 Mar 2020 11:51:04 -0400 (EDT) From: Robert Moskowitz To: Benjamin Kaduk , The IESG Cc: draft-ietf-hip-dex@ietf.org, hip-chairs@ietf.org, hipsec@ietf.org, Gonzalo Camarillo References: <158334389700.29463.11015652778464092751@ietfa.amsl.com> <2b32b723-65f1-12f1-9531-fc81528a207f@labs.htt-consult.com> Message-ID: Date: Wed, 18 Mar 2020 11:50:57 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <2b32b723-65f1-12f1-9531-fc81528a207f@labs.htt-consult.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Hipsec] Benjamin Kaduk's Discuss on draft-ietf-hip-dex-13: (with DISCUSS and COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 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: Wed, 18 Mar 2020 15:51:36 -0000 I have pushed out ver 17 I believe with this I have done my best at answering all the AD questions/comments. At least one open item on the octet encoding. Please review this version and my responses to Roman and Ben and let's collect the last set of changes to wrap this up. On 3/9/20 4:00 PM, Robert Moskowitz wrote: > > > On 3/4/20 12:44 PM, Benjamin Kaduk via Datatracker wrote: >> Benjamin Kaduk has entered the following ballot position for >> draft-ietf-hip-dex-13: Discuss >> >> 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-dex/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> This is a placeholder discuss, intended to illustrate several key >> omissions from the current document and as an indication that it is not >> yet ready for full IESG Evaluation.  In that vein, I will defer the >> evaluation shortly, to attempt to short-circuit the current round of >> evaluation while the draft improves.  In particular, this is not >> intended to be a complete review of the document. >> >> The FOLD scheme for compressing full host identities into ORCHIDs/HITs >> is pretty problematic.  The current text acknowledges that collisions >> are possible and attempts to justify the scheme by pointing out that no >> collision-free scheme is possible absent a cryptographic hash, which is >> an appeal to authority ("we can't use a cryptographic hash on >> constrained systems") that does not attempt to answer the question of >> whether it is actually reasonable to use a mechanism that allows >> collisions for this purpose (vs. just not being able to do anything). >> Additionally, there is not any discussion of second-preimage resistance, >> which is the more important property here, in terms of an attacker being >> able to construct a collision with an existing HIT of an honest node. > > In my humble opinion, second-preimage attack defense will be the same > as any attack against the HI -> HIT mapping function. > > The only place HITs are used in HIP unauthenticated is in the initial > I1 - I2 part of the exchange.  By the R2, everything is > authenticated.  All other HIP messages containing HITs are authenticated. > > So the attack is slipping in a HI-HIT mapping that is malicious. Per > Roman's comments, I will be adding to the I2 and R2 processing to > validate this mapping. > > HIP has always had to handle probabilistic collisions.  DEX now > requires checking for collisions as critical (via ACLs or other > mechanisms).  I will see to adding text. > > Operationally, the challenge is in those low level sensors that have > no way to have an ACL set up for the servers/gateways that they are > connected to.  But this is true even for BEX.  So inclusion of the > password authentication is part of the critical behavior is ACL or > similar HI-HIT mappings are not possible (sensors with no out-of-band > update mechanism).  We are always twisting ourselves in the > chicken-and-egg problem with these devices. > >> In a related vein, Section 3.2.1 claims that the above concerns can be >> remediated by deployment of a collision detection scheme, "achieved here >> through either an ACL or some other lookup process".  This process is >> vital to the security of the system as a whole, and it would be >> irresponsible to publish this document without a precise specification >> of what properties are needed in order to perform this process, as well >> as a worked example that can be used absent other considerations. > > I will be adding this per Roman's comments.  Most will be in the I2 > and R2 processing. Done.  See 7.1 > > >> Given that the applicability statement ("in communicating with such >> constrained devices") implies that there is intent to have full-featured >> nodes that implement both HIP DEX and HIP BEX, I think we need >> significantly more discussion of how such nodes avoid using DEX in >> situations where it was not appropriate.  That is, how is it known that >> the peer should be using DEX vs. BEX?  Yes, the HIT includes an >> indication of whether the identity is for use with DEX vs. BEX, but that >> does not seem like quite the relevant property.  Do we envision >> scenarios where a node is positioned somewhat like a gateway, using DEX >> on one interface and BEX to the broader internet? > > > Yes to the gateway situation.  Or the sensor has E2E DEX connection to > the central server somewhere on the greater Internet. > > Perhaps text that limits DEX on non-constrained nodes for use with > peers in the DEX ACL (or other equivalent control mechanism). See 7.1 and last sentence of 1.2 > >> Using AES-CTR with the long-term static-static master key requires >> careful tracking of counter (sequence) number to nonvolatile storage.  I >> did not see discussion of the security consequences of inadvertent >> counter reuse. > > I will look at this and see what I can add. See changes to 6.11 and last bullet point in Sec Considerations. > >> I appreciate the design to limit use of the long-term static-static >> master key to essentially just key-wrap operations, but this seems to >> require the presence of a CSPRNG in order to obtain secure session keys. >> Expecting a strong CSPRNG on a node so constrained that DEX is necessary >> seems to be a questionable assumption, and I see no discussion of the >> need for a good RNG.  (Relying on the full-featured peer to contribute >> good entropy to the key derivation is not an option, since DEX is >> allowed to be used between two nodes that are both constrained.) > > The current text is: > >    o  The strength of the keys for the Pair-wise Key SA is based on the >       quality of the random keying material generated by the Initiator >       and the Responder.  As either peer may be a sensor or an actuator >       device, there is a natural concern about the quality of its random >       number generator. > > Changed to: > >    o  The strength of the keys for both the Master and Pair-wise Key SAs >       is based on the quality of the random keying material generated by >       the Initiator and the Responder.  As either peer may be a sensor >       or an actuator device, there is a natural concern about the >       quality of its random number generator.  Thus at least a CSPRNG >       SHOULD be used. > >> The default KEYMAT algorithm uses the "CKDF" (CMAC-based KDF) >> construction, analogous to HKDF (RFC 5869).  However, the paper >> motivating 5869's design choices does not seem to justify the usage of >> CMAC instead of HMAC, since the proof requires a PRF* but CMAC (with >> AES) is only a PRP.  Absent some detailed justification or prior art it >> does not seem prudent to use such a novel construction for >> security-critical functionality. > > The CKDF design comes from NIST SP800-108.  I had extensive > discussions with NIST and the 5869 authors at the DEX design time. > These points were discussed and considered that CKDF is a prudent design. > > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Some additional comments (also incomplete), since they were already >> written. >> It would be reasonable to ignore for now any that don't make sense or >> are on parts of the text likely to change as a result of the >> higher-level discussion. >> >> Abstract >> >> My preference is to just use "forward secrecy" rather than "perfect >> forward secrecy", as perfection is hard to attain. > > I am all for that!  My Jewish Orthodox background makes me cringe at > the use of PFS.  No such thing in this world (btw, I also cringe at > the common use of "awesome")... > > If there is consensus to drop PFS from all IETF standards, I will > replace "perfect forward secrecy" with "forward secrecy" and PFS with > just the full verbiage as FS does not seem to be meaningful. It is too late in IETF usage to change.  We live with it. > > >> Section 1.1 >> >>     HIP DEX operationally is very similar to HIP BEX.  Moreover, the >>     employed model is also fairly equivalent to 802.11-2007 >>     [IEEE.802-11.2007] Master Key and Pair-wise Transient Key, but >>     handled in a single exchange. >> >> 802.11 security does not exactly have a shiny track record... > > You want to see the "smoking gun" document on WEP design from Nov > '94?  I have it. > > The point is the Master key and Pair-wise key design.  Not necessarily > how they were constructed.  I also published the initial paper on the > attack on WPA-PSK. > >>     HIP DEX does not have the option to encrypt the Host Identity of the >>     Initiator in the I2 packet.  The Responder's Host Identity also is >>     not protected.  Thus, contrary to HIPv2, HIP DEX does not provide >> for >>     end-point anonymity and any signaling (i.e., HOST_ID parameter >>     contained with an ENCRYPTED parameter) that indicates such anonymity >>     should be ignored. >> >> What would you do if you didn't ignore such signalling?  Drop the >> connection as being with a misbehaving peer? > > Probably more like a ill thought-out implementation.  Right now I am > of the opinion of leaving this as is.  But I can be convinced to add a > drop connection. > >>     As in [RFC7401], data packets start to flow after the R2 packet.  >> The >>     I2 and R2 packets may carry a data payload in the future. The >>     details of this may be defined later. >> >> I'm not sure what value is added by mentioning the possibility of data >> payload in I2/R2. > > This is carried over from 5201.  There were ideas pointing how the > 3-way TCP setup can become a 5-way HIP - TCPinESP setup. A few other > were discussed in HIPRG, but no one has proposed to actually use this > feature.  It stays for some future thinker to tinker with. > > >>     An existing HIP association can be updated with the update mechanism >>     defined in [RFC7401].  Likewise, the association can be torn down >>     with the defined closing mechanism for HIPv2 if it is no longer >>     needed.  In doing so, HIP DEX omits the HIP_SIGNATURE parameters of >>     the original HIPv2 specification. >> >> I think the intent here is more along the lines of "HIP DEX does so even >> in the absence of the HIP_SIGNATURE that is used in standard HIPv2". >> (I also note that there's some subtle semantic mismatch between DEX as >> "diet exchange" and its used to indicate continuing lack of security >> functionality throughout the extent of the association, after the >> exchange is completed.) > > Changed to: > >    An existing HIP association can be updated with the update mechanism >    defined in [RFC7401].  Likewise, the association can be torn down >    with the defined closing mechanism for HIPv2 if it is no longer >    needed.  In doing so, HIP DEX does so even in the absence of the >    HIP_SIGNATURE that is used in standard HIPv2. > > >>     Finally, HIP DEX is designed as an end-to-end authentication and key >>     establishment protocol.  As such, it can be used in combination with >> >> Don't we have a LAKE WG now?  How does DEX compare to what they are >> working on? > > I looked some more at LAKE.  They are proposing to use ephemeral DH as > part of the exchange.  That goes counter to sec 1.2 of HIP-DEX. If > they come up with an approach that performs "acceptably", then I will > be looking at it. > >> Section 1.2 >> >> In lieu of detailed comments, allow me to propose a rewrite of the whole >> section: >> >> % HIP DEX achieves its lightweight nature in large part due to the >> % intentional removal of Forward Secrecy (FS) from the key exchange.  >> Current >> % mechanisms to achieve FS use an authenticated ephemeral Diffie-Hellman >> % exchange (e.g., SIGMA or PAKE).  HIP DEX targets usage on devices >> where >> % even the most lightweight ECDH exchange is prohibitively expensive for >> % recurring (ephemeral) use.  For example, experience with the 8-bit >> % 8051-based ZWAWVE ZW0500 microprocessor has shown that EC25519 keypair >> % generation exceeds 10 seconds and consumes significant energy (i.e., >> % battery resources).  Even the ECDH multiplication for the HIP DEX >> % static-static key exchange takes 8-9 seconds, again with measurable >> % energy consumption.  This resource consumption is tolerable as a >> % one-time event during provisioning, but would render the protocol >> % unsuitable for use on these devices if it was required to be a >> % recurring part of the protocol.  For devices constrained in this >> % manner, a FS-enabled protocol will likely provide little gain.  The >> % resulting "FS" key, likely produced during device provisioning, would >> % typically end up being used for the remainder of the device's >> % lifetime.  With such a usage pattern, the inherent benefit of >> % ephemeral keys is not realized.  The security properties of such usage >> % are very similar to those of using a statically provisioned symmetric >> % pre-shared key, in that there remains a single PSK in static storage >> % that is susceptible to exfiltration/compromise, and compromise of that >> % key in effect compromises the entire protocol for that node. HIP DEX >> % achieves marginally better security properties by computing the >> % effective long-term PSK from a DH exchange, so that the provisioning >> % service is not required to be part of the risk surface due to also >> % possessing the PSK. >> % >> % Due to the substantially reduced security guarantees of HIP DEX >> % compared to HIP BEX, HIP DEX MUST only be used when at least one of >> % the two endpoints is a class 0 or 1 constrained device defined in >> % Section 3 of [RFC7228]).  HIP DEX MUST NOT be used when both endpoints >> % are class 2 devices or unconstrained. > > I have accepted your text with one typo and some formatting.  Of > course this text uses FS rather than PFS so that is a mis-match for now. > > 1.2.  Applicability > >    HIP DEX achieves its lightweight nature in large part due to the >    intentional removal of Forward Secrecy (FS) from the key exchange. >    Current mechanisms to achieve FS use an authenticated ephemeral >    Diffie-Hellman exchange (e.g., SIGMA or PAKE).  HIP DEX targets usage >    on devices where even the most lightweight ECDH exchange is >    prohibitively expensive for recurring (ephemeral) use.  For example, >    experience with the 8-bit 8051-based ZWAVE ZW0500 microprocessor has >    shown that EC25519 keypair generation exceeds 10 seconds and consumes >    significant energy (i.e., battery resources).  Even the ECDH >    multiplication for the HIP DEX static-static key exchange takes 8-9 >    seconds, again with measurable energy consumption.  This resource >    consumption is tolerable as a one-time event during provisioning, but >    would render the protocol unsuitable for use on these devices if it >    was required to be a recurring part of the protocol.  For devices >    constrained in this manner, a FS-enabled protocol will likely provide >    little gain.  The resulting "FS" key, likely produced during device >    provisioning, would typically end up being used for the remainder of >    the device's lifetime. > >    With such a usage pattern, the inherent benefit of ephemeral keys is >    not realized.  The security properties of such usage are very similar >    to those of using a statically provisioned symmetric pre-shared key, >    in that there remains a single PSK in static storage that is >    susceptible to exfiltration/compromise, and compromise of that key in >    effect compromises the entire protocol for that node.  HIP DEX >    achieves marginally better security properties by computing the >    effective long-term PSK from a DH exchange, so that the provisioning >    service is not required to be part of the risk surface due to also >    possessing the PSK. > >    Due to the substantially reduced security guarantees of HIP DEX >    compared to HIP BEX, HIP DEX MUST only be used when at least one of >    the two endpoints is a class 0 or 1 constrained device defined in >    Section 3 of [RFC7228]).  HIP DEX MUST NOT be used when both >    endpoints are class 2 devices or unconstrained. > > >> Section 2.2 >> >>     Ltrunc (M(x), K)   denotes the lowest order K bits of the result of >>        the MAC function M on the input x. >> >> I'm not sure I'm going to interpret the "lowest order K bits" the same >> way that everyone else will.  I think "leftmost" or "first" are more >> common terms for describing this sort of truncation. > > This text goes back to 5201.  Implementors of 5201 did not have a > problem with this, in fact probably one of them supplied the text. But > I am open to change based on consensus. > >> Section 2.3 >> >>     CMAC:  The Cipher-based Message Authentication Code with the 128-bit >>        Advanced Encryption Standard (AES) defined in RFC 4493 [RFC4493]. >> >> I would suggest just using CMAC as the acronym and not trying to >> overload it to also be AES-specific. > > Do you recommend I just reference SP800-38B? > >>     HIT Suite:  A HIT Suite groups all algorithms that are required to >>        generate and use an HI and its HIT.  In particular, these >>        algorithms are: 1) ECDH and 2) FOLD. >> >> For DEX.  For normal HIPv2 we wouldn't touch FOLD with a long pole. > > :) > >    HIT Suite:  A HIT Suite groups all algorithms that are required to >       generate and use an HI and its HIT.  In particular for HIP DEX, >       these algorithms are: 1) ECDH and 2) FOLD. > > BTW, I once DID use a 10' pole to chase a family of raccoons out of my > garage.  Really, it WAS 10' long, I had just gotten it from the lumber > yard.  Came home and there were a bunch of beady eyes in the garage.. > >>     HI (Host Identity):  The static ECDH public key that represents the >>        identity of the host.  In HIP DEX, a host proves ownership of the >>        private key belonging to its HI by creating a HIP_MAC with the >>        derived ECDH key (see Section 3). >> >> This may sound pedantic, but this doesn't actually prove ownership of >> the private key.  Someone who knows the private key of the other party >> and the public key of the host in question would be able to produce the >> same MAC from the corresponding derived ECDH key.  I think the most we >> can say here is that a host authenticates itself as that host identity >> [with that HIP_MAC].  There's the corresponding trust of the recipient >> that its own private key remains secure and thus that no party other >> than itself or the peer identity could have generated that message. > > I will think on this one.  See what verbiage helps. So I need to reference the proper HIP_MAC.  Initiator's private key in I2 and Responder's in R2.    HI (Host Identity):  The static ECDH public key that represents the       identity of the host.  In HIP DEX, a host proves ownership of the       private key belonging to its HI by creating a HIP_MAC with the       derived ECDH key (see Section 3) in the appropriate I2 or R2       packet. > >>     Initiator:  The host that initiates the HIP DEX handshake.  This >> role >>        is typically forgotten once the handshake is completed. >> >> "typically"?  Perhaps it's best to say that the role is not used or >> needed after the handshake is completed. > > I the HIP state machine, either peer can be the Initiator.  Roles can > be reversed.  If one party looses state, it can then become the > Initiator regardless of what role it had in the original exchange. > > This is the text used in 7401. > >>     KEYMAT:  Keying material.  That is, the bit string(s) used as >>        cryptographic keys. >> >> I'm surprised we need an abbreviation for this. > > I got comments in early drafts of 5201-bis.  Put it in.  Take it out.  > So for now, I leave it in. > >>     Length of the Responder's HIT Hash Algorithm (RHASH_len):  The >>        natural output length of RHASH in bits. >> >> [this doesn't really fit the pattern of "definition"s] > > It is in 7401.  If the AD says pull it.  It goes. > > Though perhaps the definition is of RHASH_len?    RHASH_len:  The natural length of the RHASH Algorithm in bits. But that really should be clear in its name.  I am leaving this in unless someone says to pull it. > >>     Responder:  The host that responds to the Initiator in the HIP DEX >>        handshake.  This role is typically forgotten once the >> handshake is >>        completed. >> >> [same thing re "typically"] > > Same response. > >> Section 3 >> >>     HIP DEX implementations MUST support the Elliptic Curve Diffie- >>     Hellman (ECDH) [RFC6090] key exchange for generating the HI as >>     defined in Section 5.2.3.  No additional algorithms are supported at >>     this time. >> >> It's kind of weird to see a "MUST" for "RFC6090 key exchange"; 6090 >> discusses the general class of things but is not a specific key exchange >> algorithm (e.g., curve). >> I'd also consider s/supported/defined/. > > Good point.  Changed to: > >    HIP DEX implementations use the Elliptic Curve Diffie-Hellman (ECDH) >    [RFC6090] key exchange for generating the HI as defined in >    Section 5.2.3.  No alternative algorithms are defined at this time. > >>     Due to the latter property, an attacker may be able to find a >>     collision with a HIT that is in use.  Hence, policy decisions >> such as >>     access control MUST NOT be based solely on the HIT. Instead, the HI >>     of a host SHOULD be considered. >> >> I don't think this is correct or a strong enough statement.  In >> particular, I don't think access control should be based on the HIT at >> all, so strike "solely".  Also, the "SHOULD" seems too week.  I can >> understand that "MUST use the HI" could be overly constraining, but >> "access control decisions MUST be made on the actual identity of the >> host, e.g., the full HI" should allow for sufficient flexibility. > > I will see how this changes with the ACL additions. See sec 71. and this text changed to:    Due to the latter property, an attacker may be able to find a    collision with a HIT that is in use.  Hence, policy decisions such as    access control MUST NOT be based solely on the HIT.  Instead, the HI    of a host SHOULD be considered (see Section 7.1). > >>     Carrying HIs and HITs in the header of user data packets would >>     increase the overhead of packets.  Thus, it is not expected that >> >> s/and/or/? > > fixed. > >>     association.  When other user data packet formats are used, the >>     corresponding extensions need to define a replacement for the >>     ESP_TRANSFORM [RFC7402] parameter along with associated semantics, >>     but this procedure is outside the scope of this document. >> >> Why is ESP_TRANSFORM the most important parameter here, when we talk >> about mapping a packet to the HIP association?  I thought ESP_TRANSFORM >> was literally about the encryption mechanics, not metadata around it. > > Again, this goes back to 5201.  We are talking about ~20 years of > discussions. > > We are discussing HIs and HITs, but that SPIs are used in everyday > packets as the pointer to the HIs and HITs involved.  I will think on > this, but it is down the list on things to change that were inherited > from 5201. > >> Section 3.2 >> >> ORCHID claims to provide statistical uniqueness and routability at some >> overlay layer, neither of which this FOLD procedure provides, due to >> easily-generatable second preimages. >> >> Section 3.2.1 >> >>     Since collision-resistance is not possible with the tools at hand, >>     any reasonable function (e.g.  FOLD) that takes the full value of >> the >>     HI into generating the HIT can be used, provided that collision >>     detection is part of the HIP-DEX deployment design.  This is >> achieved >> >> This is not an argument that this is a reasonable thing to do; it's >> merely an argument that it's a thing that can be done that has the same >> claimed properties as the only type of thing that could be done.  It >> might be a bad idea to do the only type of thing that can be done, and >> you have not convinced me otherwise.  (See also the distinction between >> collision-resistance and second-preimage-resistance alluded to in my >> comment on the previous section.) > > Other changes may help, or not.  We can rejoin this point after draft > 14 (note I will be pushing out draft 13 today for the publish deadline > for changes done so far). > >>     here through either an ACL or some other lookup process that >>     externally binds the HIT and HI. >> >> Without at least one well-specified mechanism for actually doing this >> and clear documentation of what precise properties such a mechanism >> needs to provide, I think it's irresponsible to publish this document. > > In the works. sec 7.1 > >> Section 4.1 >> >>     By definition, the system initiating a HIP Diet EXchange is the >>     Initiator, and the peer is the Responder.  This distinction is >>     typically forgotten once the handshake completes, and either party >>     can become the Initiator in future communications. >> >> ["typically" again] > > same response. > >>     Diffie-Hellman Group IDs supported by the Initiator.  Note that in >>     some cases it may be possible to replace this trigger packet by some >>     other form of a trigger, in which case the protocol starts with the >>     Responder sending the R1 packet.  In such cases, another >> mechanism to >>     convey the Initiator's supported DH Groups (e.g., by using a default >>     group) must be specified. >> >> This seems under-specified for a proposed standard and is probably >> better off omitted entirely. > > This is carried over from 5201, which WAS experimental.  So I can see > it as reasonable to drop this as no one proposed another mechanism. dropped. > >    The Initiator first sends a trigger packet, I1, to the Responder. >    This packet contains the HIT of the Initiator and the HIT of the >    Responder, if it is known.  Moreover, the I1 packet initializes the >    negotiation of the Diffie-Hellman group that is used for generating >    the Master Key SA.  Therefore, the I1 packet contains a list of >    Diffie-Hellman Group IDs supported by the Initiator. > > >>     The second packet, R1, starts the actual authenticated >> Diffie-Hellman >>     key exchange.  It contains a puzzle - a cryptographic challenge that >>     the Initiator must solve before continuing the exchange. The level >>     of difficulty of the puzzle can be adjusted based on level of trust >>     with the Initiator, current load, or other factors.  In addition, >> the >> >> The Initiator is unauthenticated at this point, so "level of trust" >> seems to not really be defined... > > Changed to "knowledge of the".  If the Responder "knows" that the > Initiator is a sensor, using a smaller puzzle may be preferred. there > is discussion about large puzzles being an attack on sensors. > >> Section 4.1.1 >> >> If an unconstrained (DoSing) attacker is competing with a constrained >> honest initiator to solve puzzles during an attack, it seems like the >> honest initiator is going to lose out pretty badly. > > You do what you can that makes some degree of sense.  You just don't > walk away from the problem. > >> Section 4.1.4 >> >> There are security considerations for serializing the HIP state to >> nonvolatile storage! > > Do you want text about this in the Securities Considerations? > From nobody Wed Mar 18 19:48:07 2020 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 51CC73A2069 for ; Wed, 18 Mar 2020 19:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 M490t1dftdRo for ; Wed, 18 Mar 2020 19:48:04 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 1052B3A2068 for ; Wed, 18 Mar 2020 19:48:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id BF8C56212E for ; Wed, 18 Mar 2020 22:48:02 -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 g2ZeANvf6uMF for ; Wed, 18 Mar 2020 22:47:59 -0400 (EDT) Received: from lx140e.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 C383162111 for ; Wed, 18 Mar 2020 22:47:56 -0400 (EDT) To: HIP From: Robert Moskowitz Message-ID: <1e300767-361a-9032-80a3-2a5ec205af77@htt-consult.com> Date: Wed, 18 Mar 2020 22:47:48 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Hipsec] Help needed - text to octet for HIP-DEX X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 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, 19 Mar 2020 02:48:06 -0000 There are two strings used in the KEYMAT process i HIP-DEX: CKDF-Extract and CKDF-Expand The draft says that they are "an octet string". Thing is that depending on which google found tool, I get different text to octet values! So to those implementors out there: What is the proper octet strings for the above two text strings? thanks. From nobody Thu Mar 19 14:55:47 2020 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 193F03A1095 for ; Thu, 19 Mar 2020 14:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.615 X-Spam-Level: X-Spam-Status: No, score=-1.615 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.274, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01] autolearn=no 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 VBre8cuyqF2v for ; Thu, 19 Mar 2020 14:55:42 -0700 (PDT) Received: from out.west.exch081.serverdata.net (cas081-co-3.exch081.serverdata.net [199.193.204.184]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7E913A108E for ; Thu, 19 Mar 2020 14:55:31 -0700 (PDT) Received: from MBX081-W5-CO-1.exch081.serverpod.net (10.224.129.84) by MBX081-W5-CO-1 (10.224.129.84) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 19 Mar 2020 14:55:30 -0700 Received: from MBX081-W5-CO-1.exch081.serverpod.net ([10.224.129.84]) by MBX081-W5-CO-1.exch081.serverpod.net ([10.224.129.84]) with mapi id 15.00.1497.006; Thu, 19 Mar 2020 14:55:30 -0700 From: Jeff Ahrenholz To: Robert Moskowitz , HIP Thread-Topic: [Hipsec] Help needed - text to octet for HIP-DEX Thread-Index: AQHV/ZjXAISjdNAlOUqdqcAW/hK2nahQdwOA Date: Thu, 19 Mar 2020 21:55:30 +0000 Message-ID: References: <1e300767-361a-9032-80a3-2a5ec205af77@htt-consult.com> In-Reply-To: <1e300767-361a-9032-80a3-2a5ec205af77@htt-consult.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [73.254.156.159] Content-Type: text/plain; charset="utf-8" Content-ID: <6771BE333FA87F40A6A3BD79077EDE67@exch081.serverpod.net> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Hipsec] Help needed - text to octet for HIP-DEX X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 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, 19 Mar 2020 21:55:46 -0000 Qm9iIGV0IGFsLiwNCg0KPiAgICBUaGVyZSBhcmUgdHdvIHN0cmluZ3MgdXNlZCBpbiB0aGUgS0VZ TUFUIHByb2Nlc3MgaSBISVAtREVYOg0KPiAgICANCj4gICAgQ0tERi1FeHRyYWN0DQo+ICAgIGFu ZA0KPiAgICBDS0RGLUV4cGFuZA0KPiAgICANCj4gICAgVGhlIGRyYWZ0IHNheXMgdGhhdCB0aGV5 IGFyZSAiYW4gb2N0ZXQgc3RyaW5nIi4NCj4gICAgDQo+ICAgIFRoaW5nIGlzIHRoYXQgZGVwZW5k aW5nIG9uIHdoaWNoIGdvb2dsZSBmb3VuZCB0b29sLCBJIGdldCBkaWZmZXJlbnQgdGV4dCANCj4g ICAgdG8gb2N0ZXQgdmFsdWVzIQ0KPiAgICANCj4gICAgU28gdG8gdGhvc2UgaW1wbGVtZW50b3Jz IG91dCB0aGVyZToNCj4gICAgDQo+ICAgIFdoYXQgaXMgdGhlIHByb3BlciBvY3RldCBzdHJpbmdz IGZvciB0aGUgYWJvdmUgdHdvIHRleHQgc3RyaW5ncz8NCg0KRnJvbSBhbiBpbXBsZW1lbnRhdGlv biBwZXJzcGVjdGl2ZSwgaGVyZSBhcmUgc29tZSBQeXRob24zIHNuaXBwZXRzOg0KKG9yZCgpIHJl dHVybnMgdGhlIFVuaWNvZGUgY29kZXBvaW50IGZvciBhIGNoYXJhY3RlciwgDQogb2N0KCkgcmV0 dXJucyB0aGUgb2N0YWwgcmVwcmVzZW50YXRpb24sIGFuZA0KIGhleCgpIHJldHVybnMgdGhlIGhl eGFkZWNpbWFsIHJlcHJlc2VudGF0aW9uKQ0KDQppbnB1dD0iQ0tERi1FeHRyYWN0Ig0KDQojIHRo ZSB2YWx1ZXMgUm9tYW4gc3VnZ2VzdGVkLCBzaG93biBhcyBBU0NJSSBkZWNpbWFsIHZhbHVlczoN Cj4+PiBsaXN0KG1hcChsYW1iZGEgaTogb3JkKGkpLCBpbnB1dCkpDQpbNjcsIDc1LCA2OCwgNzAs IDQ1LCA2OSwgMTIwLCAxMTYsIDExNCwgOTcsIDk5LCAxMTZdDQoNCiMgdGhlIHRvb2wgeW91IHdl cmUgdXNpbmcgc2hvd2VkIG9jdGFsIHZhbHVlczoNCj4+PiBsaXN0KG1hcChsYW1iZGEgaTogb2N0 KG9yZChpKSksIGlucHV0KSkNClsnMG8xMDMnLCAnMG8xMTMnLCAnMG8xMDQnLCAnMG8xMDYnLCAn MG81NScsICcwbzEwNScsICcwbzE3MCcsICcwbzE2NCcsICcwbzE2MicsICcwbzE0MScsICcwbzE0 MycsICcwbzE2NCddDQoNCiMgaGV4IHJlcHJlc2VudGF0aW9uIG9mIHRoZSBhYm92ZToNCj4+PiBs aXN0KG1hcChsYW1iZGEgaTogaGV4KG9yZChpKSksIGlucHV0KSkNClsnMHg0MycsICcweDRiJywg JzB4NDQnLCAnMHg0NicsICcweDJkJywgJzB4NDUnLCAnMHg3OCcsICcweDc0JywgJzB4NzInLCAn MHg2MScsICcweDYzJywgJzB4NzQnXQ0KDQpJbiB0aGUgYXBwZW5kaXggb2YgZS5nLiBSRkMgNTIw MSwgd2Ugc2hvdyBoZXhhZGVjaW1hbCB2YWx1ZXMuLi4gaW4gdGhpcyBjYXNlIHlvdSBjb3VsZCBw dXQ6DQppbnB1dCB0ZXh0OiAiQ0tERi1FeHRyYWN0Ig0KaGV4IHN0cmluZzogMHg0MzRiNDQ0NjJk NDU3ODc0NzI2MTYzNzQNCg0KaW5wdXQgdGV4dDogIkNLREYtRXhwYW5kIg0KaGV4IHN0cmluZzog MHg0MzRiNDQ0NjJkNDU3ODcwNjE2ZTY0DQoNClNvIHRoZSBoZXggbG9va3MgZ29vZCB0byBtZSwg YnV0IHlvdSBjb3VsZCB1c2UgZWl0aGVyIG9mIHRoZSBvdGhlciByZXByZXNlbnRhdGlvbnMgYXMg bG9uZyBhcyB3ZSBleHBsaWNpdGx5IHN0YXRlIHdoYXQgdGhleSBhcmUuDQoNCi1KZWZmDQoNCg== From nobody Fri Mar 20 11:26:22 2020 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 F2A873A0DAF; Fri, 20 Mar 2020 11:26:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: hipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.121.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: hipsec@ietf.org Message-ID: <158472877183.13492.10529519349723097234@ietfa.amsl.com> Date: Fri, 20 Mar 2020 11:26:11 -0700 Archived-At: Subject: [Hipsec] I-D Action: draft-ietf-hip-dex-18.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 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, 20 Mar 2020 18:26:21 -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 WG of the IETF. Title : HIP Diet EXchange (DEX) Authors : Robert Moskowitz Rene Hummen Miika Komu Filename : draft-ietf-hip-dex-18.txt Pages : 59 Date : 2020-03-20 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. 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. Unlike HIPv2, HIP DEX does not support Forward Secrecy (FS), and MUST only be used on devices where FS is prohibitively expensive. 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-hip-dex-18 https://datatracker.ietf.org/doc/html/draft-ietf-hip-dex-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-18 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 Fri Mar 20 11:32:03 2020 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 A03BC3A0DBD; Fri, 20 Mar 2020 11:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 fDXU-A0iwCo4; Fri, 20 Mar 2020 11:31:43 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 73F243A0DF4; Fri, 20 Mar 2020 11:31:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id A2E02621A0; Fri, 20 Mar 2020 14:31:41 -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 c+39Nnr2G8js; Fri, 20 Mar 2020 14:31:20 -0400 (EDT) Received: from lx140e.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 55C126212E; Fri, 20 Mar 2020 14:31:20 -0400 (EDT) From: Robert Moskowitz To: Benjamin Kaduk , The IESG Cc: draft-ietf-hip-dex@ietf.org, hip-chairs@ietf.org, hipsec@ietf.org, Gonzalo Camarillo References: <158334389700.29463.11015652778464092751@ietfa.amsl.com> <2b32b723-65f1-12f1-9531-fc81528a207f@labs.htt-consult.com> Message-ID: <4a14fab8-fbb2-0d86-8a7f-7635bc457af0@labs.htt-consult.com> Date: Fri, 20 Mar 2020 14:31:13 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Hipsec] Benjamin Kaduk's Discuss on draft-ietf-hip-dex-13: (with DISCUSS and COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 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, 20 Mar 2020 18:32:02 -0000 Ben, In ver 18 I have replaced "Perfect Forward Secrecy" with "Forward Secrecy". That seems to be a consensus on saag. Please let me know where you stand on my various responses. Thank you Bob On 3/18/20 11:50 AM, Robert Moskowitz wrote: > I have pushed out ver 17 > > I believe with this I have done my best at answering all the AD > questions/comments. > > At least one open item on the octet encoding. > > Please review this version and my responses to Roman and Ben and let's > collect the last set of changes to wrap this up. > > > > On 3/9/20 4:00 PM, Robert Moskowitz wrote: >> >> >> On 3/4/20 12:44 PM, Benjamin Kaduk via Datatracker wrote: >>> Benjamin Kaduk has entered the following ballot position for >>> draft-ietf-hip-dex-13: Discuss >>> >>> 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-dex/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> This is a placeholder discuss, intended to illustrate several key >>> omissions from the current document and as an indication that it is not >>> yet ready for full IESG Evaluation.  In that vein, I will defer the >>> evaluation shortly, to attempt to short-circuit the current round of >>> evaluation while the draft improves.  In particular, this is not >>> intended to be a complete review of the document. >>> >>> The FOLD scheme for compressing full host identities into ORCHIDs/HITs >>> is pretty problematic.  The current text acknowledges that collisions >>> are possible and attempts to justify the scheme by pointing out that no >>> collision-free scheme is possible absent a cryptographic hash, which is >>> an appeal to authority ("we can't use a cryptographic hash on >>> constrained systems") that does not attempt to answer the question of >>> whether it is actually reasonable to use a mechanism that allows >>> collisions for this purpose (vs. just not being able to do anything). >>> Additionally, there is not any discussion of second-preimage >>> resistance, >>> which is the more important property here, in terms of an attacker >>> being >>> able to construct a collision with an existing HIT of an honest node. >> >> In my humble opinion, second-preimage attack defense will be the same >> as any attack against the HI -> HIT mapping function. >> >> The only place HITs are used in HIP unauthenticated is in the initial >> I1 - I2 part of the exchange.  By the R2, everything is >> authenticated.  All other HIP messages containing HITs are >> authenticated. >> >> So the attack is slipping in a HI-HIT mapping that is malicious. Per >> Roman's comments, I will be adding to the I2 and R2 processing to >> validate this mapping. >> >> HIP has always had to handle probabilistic collisions.  DEX now >> requires checking for collisions as critical (via ACLs or other >> mechanisms).  I will see to adding text. >> >> Operationally, the challenge is in those low level sensors that have >> no way to have an ACL set up for the servers/gateways that they are >> connected to.  But this is true even for BEX.  So inclusion of the >> password authentication is part of the critical behavior is ACL or >> similar HI-HIT mappings are not possible (sensors with no out-of-band >> update mechanism).  We are always twisting ourselves in the >> chicken-and-egg problem with these devices. >> >>> In a related vein, Section 3.2.1 claims that the above concerns can be >>> remediated by deployment of a collision detection scheme, "achieved >>> here >>> through either an ACL or some other lookup process".  This process is >>> vital to the security of the system as a whole, and it would be >>> irresponsible to publish this document without a precise specification >>> of what properties are needed in order to perform this process, as well >>> as a worked example that can be used absent other considerations. >> >> I will be adding this per Roman's comments.  Most will be in the I2 >> and R2 processing. > > Done.  See 7.1 > >> >> >>> Given that the applicability statement ("in communicating with such >>> constrained devices") implies that there is intent to have >>> full-featured >>> nodes that implement both HIP DEX and HIP BEX, I think we need >>> significantly more discussion of how such nodes avoid using DEX in >>> situations where it was not appropriate.  That is, how is it known that >>> the peer should be using DEX vs. BEX?  Yes, the HIT includes an >>> indication of whether the identity is for use with DEX vs. BEX, but >>> that >>> does not seem like quite the relevant property.  Do we envision >>> scenarios where a node is positioned somewhat like a gateway, using DEX >>> on one interface and BEX to the broader internet? >> >> >> Yes to the gateway situation.  Or the sensor has E2E DEX connection >> to the central server somewhere on the greater Internet. >> >> Perhaps text that limits DEX on non-constrained nodes for use with >> peers in the DEX ACL (or other equivalent control mechanism). > > See 7.1 and last sentence of 1.2 > >> >>> Using AES-CTR with the long-term static-static master key requires >>> careful tracking of counter (sequence) number to nonvolatile >>> storage.  I >>> did not see discussion of the security consequences of inadvertent >>> counter reuse. >> >> I will look at this and see what I can add. > > See changes to 6.11 and last bullet point in Sec Considerations. > >> >>> I appreciate the design to limit use of the long-term static-static >>> master key to essentially just key-wrap operations, but this seems to >>> require the presence of a CSPRNG in order to obtain secure session >>> keys. >>> Expecting a strong CSPRNG on a node so constrained that DEX is >>> necessary >>> seems to be a questionable assumption, and I see no discussion of the >>> need for a good RNG.  (Relying on the full-featured peer to contribute >>> good entropy to the key derivation is not an option, since DEX is >>> allowed to be used between two nodes that are both constrained.) >> >> The current text is: >> >>    o  The strength of the keys for the Pair-wise Key SA is based on the >>       quality of the random keying material generated by the Initiator >>       and the Responder.  As either peer may be a sensor or an actuator >>       device, there is a natural concern about the quality of its random >>       number generator. >> >> Changed to: >> >>    o  The strength of the keys for both the Master and Pair-wise Key SAs >>       is based on the quality of the random keying material generated by >>       the Initiator and the Responder.  As either peer may be a sensor >>       or an actuator device, there is a natural concern about the >>       quality of its random number generator.  Thus at least a CSPRNG >>       SHOULD be used. >> >>> The default KEYMAT algorithm uses the "CKDF" (CMAC-based KDF) >>> construction, analogous to HKDF (RFC 5869).  However, the paper >>> motivating 5869's design choices does not seem to justify the usage of >>> CMAC instead of HMAC, since the proof requires a PRF* but CMAC (with >>> AES) is only a PRP.  Absent some detailed justification or prior art it >>> does not seem prudent to use such a novel construction for >>> security-critical functionality. >> >> The CKDF design comes from NIST SP800-108.  I had extensive >> discussions with NIST and the 5869 authors at the DEX design time. >> These points were discussed and considered that CKDF is a prudent >> design. >> >> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> Some additional comments (also incomplete), since they were already >>> written. >>> It would be reasonable to ignore for now any that don't make sense or >>> are on parts of the text likely to change as a result of the >>> higher-level discussion. >>> >>> Abstract >>> >>> My preference is to just use "forward secrecy" rather than "perfect >>> forward secrecy", as perfection is hard to attain. >> >> I am all for that!  My Jewish Orthodox background makes me cringe at >> the use of PFS.  No such thing in this world (btw, I also cringe at >> the common use of "awesome")... >> >> If there is consensus to drop PFS from all IETF standards, I will >> replace "perfect forward secrecy" with "forward secrecy" and PFS with >> just the full verbiage as FS does not seem to be meaningful. > > It is too late in IETF usage to change.  We live with it. > >> >> >>> Section 1.1 >>> >>>     HIP DEX operationally is very similar to HIP BEX. Moreover, the >>>     employed model is also fairly equivalent to 802.11-2007 >>>     [IEEE.802-11.2007] Master Key and Pair-wise Transient Key, but >>>     handled in a single exchange. >>> >>> 802.11 security does not exactly have a shiny track record... >> >> You want to see the "smoking gun" document on WEP design from Nov >> '94?  I have it. >> >> The point is the Master key and Pair-wise key design.  Not >> necessarily how they were constructed.  I also published the initial >> paper on the attack on WPA-PSK. >> >>>     HIP DEX does not have the option to encrypt the Host Identity of >>> the >>>     Initiator in the I2 packet.  The Responder's Host Identity also is >>>     not protected.  Thus, contrary to HIPv2, HIP DEX does not >>> provide for >>>     end-point anonymity and any signaling (i.e., HOST_ID parameter >>>     contained with an ENCRYPTED parameter) that indicates such >>> anonymity >>>     should be ignored. >>> >>> What would you do if you didn't ignore such signalling?  Drop the >>> connection as being with a misbehaving peer? >> >> Probably more like a ill thought-out implementation.  Right now I am >> of the opinion of leaving this as is.  But I can be convinced to add >> a drop connection. >> >>>     As in [RFC7401], data packets start to flow after the R2 >>> packet.  The >>>     I2 and R2 packets may carry a data payload in the future. The >>>     details of this may be defined later. >>> >>> I'm not sure what value is added by mentioning the possibility of data >>> payload in I2/R2. >> >> This is carried over from 5201.  There were ideas pointing how the >> 3-way TCP setup can become a 5-way HIP - TCPinESP setup. A few other >> were discussed in HIPRG, but no one has proposed to actually use this >> feature.  It stays for some future thinker to tinker with. >> >> >>>     An existing HIP association can be updated with the update >>> mechanism >>>     defined in [RFC7401].  Likewise, the association can be torn down >>>     with the defined closing mechanism for HIPv2 if it is no longer >>>     needed.  In doing so, HIP DEX omits the HIP_SIGNATURE parameters of >>>     the original HIPv2 specification. >>> >>> I think the intent here is more along the lines of "HIP DEX does so >>> even >>> in the absence of the HIP_SIGNATURE that is used in standard HIPv2". >>> (I also note that there's some subtle semantic mismatch between DEX as >>> "diet exchange" and its used to indicate continuing lack of security >>> functionality throughout the extent of the association, after the >>> exchange is completed.) >> >> Changed to: >> >>    An existing HIP association can be updated with the update mechanism >>    defined in [RFC7401].  Likewise, the association can be torn down >>    with the defined closing mechanism for HIPv2 if it is no longer >>    needed.  In doing so, HIP DEX does so even in the absence of the >>    HIP_SIGNATURE that is used in standard HIPv2. >> >> >>>     Finally, HIP DEX is designed as an end-to-end authentication and >>> key >>>     establishment protocol.  As such, it can be used in combination >>> with >>> >>> Don't we have a LAKE WG now?  How does DEX compare to what they are >>> working on? >> >> I looked some more at LAKE.  They are proposing to use ephemeral DH >> as part of the exchange.  That goes counter to sec 1.2 of HIP-DEX. If >> they come up with an approach that performs "acceptably", then I will >> be looking at it. >> >>> Section 1.2 >>> >>> In lieu of detailed comments, allow me to propose a rewrite of the >>> whole >>> section: >>> >>> % HIP DEX achieves its lightweight nature in large part due to the >>> % intentional removal of Forward Secrecy (FS) from the key >>> exchange.  Current >>> % mechanisms to achieve FS use an authenticated ephemeral >>> Diffie-Hellman >>> % exchange (e.g., SIGMA or PAKE).  HIP DEX targets usage on devices >>> where >>> % even the most lightweight ECDH exchange is prohibitively expensive >>> for >>> % recurring (ephemeral) use.  For example, experience with the 8-bit >>> % 8051-based ZWAWVE ZW0500 microprocessor has shown that EC25519 >>> keypair >>> % generation exceeds 10 seconds and consumes significant energy (i.e., >>> % battery resources).  Even the ECDH multiplication for the HIP DEX >>> % static-static key exchange takes 8-9 seconds, again with measurable >>> % energy consumption.  This resource consumption is tolerable as a >>> % one-time event during provisioning, but would render the protocol >>> % unsuitable for use on these devices if it was required to be a >>> % recurring part of the protocol.  For devices constrained in this >>> % manner, a FS-enabled protocol will likely provide little gain.  The >>> % resulting "FS" key, likely produced during device provisioning, would >>> % typically end up being used for the remainder of the device's >>> % lifetime.  With such a usage pattern, the inherent benefit of >>> % ephemeral keys is not realized.  The security properties of such >>> usage >>> % are very similar to those of using a statically provisioned symmetric >>> % pre-shared key, in that there remains a single PSK in static storage >>> % that is susceptible to exfiltration/compromise, and compromise of >>> that >>> % key in effect compromises the entire protocol for that node. HIP DEX >>> % achieves marginally better security properties by computing the >>> % effective long-term PSK from a DH exchange, so that the provisioning >>> % service is not required to be part of the risk surface due to also >>> % possessing the PSK. >>> % >>> % Due to the substantially reduced security guarantees of HIP DEX >>> % compared to HIP BEX, HIP DEX MUST only be used when at least one of >>> % the two endpoints is a class 0 or 1 constrained device defined in >>> % Section 3 of [RFC7228]).  HIP DEX MUST NOT be used when both >>> endpoints >>> % are class 2 devices or unconstrained. >> >> I have accepted your text with one typo and some formatting.  Of >> course this text uses FS rather than PFS so that is a mis-match for now. >> >> 1.2.  Applicability >> >>    HIP DEX achieves its lightweight nature in large part due to the >>    intentional removal of Forward Secrecy (FS) from the key exchange. >>    Current mechanisms to achieve FS use an authenticated ephemeral >>    Diffie-Hellman exchange (e.g., SIGMA or PAKE).  HIP DEX targets usage >>    on devices where even the most lightweight ECDH exchange is >>    prohibitively expensive for recurring (ephemeral) use.  For example, >>    experience with the 8-bit 8051-based ZWAVE ZW0500 microprocessor has >>    shown that EC25519 keypair generation exceeds 10 seconds and consumes >>    significant energy (i.e., battery resources).  Even the ECDH >>    multiplication for the HIP DEX static-static key exchange takes 8-9 >>    seconds, again with measurable energy consumption.  This resource >>    consumption is tolerable as a one-time event during provisioning, but >>    would render the protocol unsuitable for use on these devices if it >>    was required to be a recurring part of the protocol.  For devices >>    constrained in this manner, a FS-enabled protocol will likely provide >>    little gain.  The resulting "FS" key, likely produced during device >>    provisioning, would typically end up being used for the remainder of >>    the device's lifetime. >> >>    With such a usage pattern, the inherent benefit of ephemeral keys is >>    not realized.  The security properties of such usage are very similar >>    to those of using a statically provisioned symmetric pre-shared key, >>    in that there remains a single PSK in static storage that is >>    susceptible to exfiltration/compromise, and compromise of that key in >>    effect compromises the entire protocol for that node.  HIP DEX >>    achieves marginally better security properties by computing the >>    effective long-term PSK from a DH exchange, so that the provisioning >>    service is not required to be part of the risk surface due to also >>    possessing the PSK. >> >>    Due to the substantially reduced security guarantees of HIP DEX >>    compared to HIP BEX, HIP DEX MUST only be used when at least one of >>    the two endpoints is a class 0 or 1 constrained device defined in >>    Section 3 of [RFC7228]).  HIP DEX MUST NOT be used when both >>    endpoints are class 2 devices or unconstrained. >> >> >>> Section 2.2 >>> >>>     Ltrunc (M(x), K)   denotes the lowest order K bits of the result of >>>        the MAC function M on the input x. >>> >>> I'm not sure I'm going to interpret the "lowest order K bits" the same >>> way that everyone else will.  I think "leftmost" or "first" are more >>> common terms for describing this sort of truncation. >> >> This text goes back to 5201.  Implementors of 5201 did not have a >> problem with this, in fact probably one of them supplied the text. >> But I am open to change based on consensus. >> >>> Section 2.3 >>> >>>     CMAC:  The Cipher-based Message Authentication Code with the >>> 128-bit >>>        Advanced Encryption Standard (AES) defined in RFC 4493 >>> [RFC4493]. >>> >>> I would suggest just using CMAC as the acronym and not trying to >>> overload it to also be AES-specific. >> >> Do you recommend I just reference SP800-38B? >> >>>     HIT Suite:  A HIT Suite groups all algorithms that are required to >>>        generate and use an HI and its HIT.  In particular, these >>>        algorithms are: 1) ECDH and 2) FOLD. >>> >>> For DEX.  For normal HIPv2 we wouldn't touch FOLD with a long pole. >> >> :) >> >>    HIT Suite:  A HIT Suite groups all algorithms that are required to >>       generate and use an HI and its HIT.  In particular for HIP DEX, >>       these algorithms are: 1) ECDH and 2) FOLD. >> >> BTW, I once DID use a 10' pole to chase a family of raccoons out of >> my garage.  Really, it WAS 10' long, I had just gotten it from the >> lumber yard.  Came home and there were a bunch of beady eyes in the >> garage.. >> >>>     HI (Host Identity):  The static ECDH public key that represents the >>>        identity of the host.  In HIP DEX, a host proves ownership of >>> the >>>        private key belonging to its HI by creating a HIP_MAC with the >>>        derived ECDH key (see Section 3). >>> >>> This may sound pedantic, but this doesn't actually prove ownership of >>> the private key.  Someone who knows the private key of the other party >>> and the public key of the host in question would be able to produce the >>> same MAC from the corresponding derived ECDH key.  I think the most we >>> can say here is that a host authenticates itself as that host identity >>> [with that HIP_MAC].  There's the corresponding trust of the recipient >>> that its own private key remains secure and thus that no party other >>> than itself or the peer identity could have generated that message. >> >> I will think on this one.  See what verbiage helps. > > So I need to reference the proper HIP_MAC.  Initiator's private key in > I2 and Responder's in R2. > >    HI (Host Identity):  The static ECDH public key that represents the >       identity of the host.  In HIP DEX, a host proves ownership of the >       private key belonging to its HI by creating a HIP_MAC with the >       derived ECDH key (see Section 3) in the appropriate I2 or R2 >       packet. > > >> >>>     Initiator:  The host that initiates the HIP DEX handshake.  This >>> role >>>        is typically forgotten once the handshake is completed. >>> >>> "typically"?  Perhaps it's best to say that the role is not used or >>> needed after the handshake is completed. >> >> I the HIP state machine, either peer can be the Initiator. Roles can >> be reversed.  If one party looses state, it can then become the >> Initiator regardless of what role it had in the original exchange. >> >> This is the text used in 7401. >> >>>     KEYMAT:  Keying material.  That is, the bit string(s) used as >>>        cryptographic keys. >>> >>> I'm surprised we need an abbreviation for this. >> >> I got comments in early drafts of 5201-bis.  Put it in.  Take it >> out.  So for now, I leave it in. >> >>>     Length of the Responder's HIT Hash Algorithm (RHASH_len):  The >>>        natural output length of RHASH in bits. >>> >>> [this doesn't really fit the pattern of "definition"s] >> >> It is in 7401.  If the AD says pull it.  It goes. >> >> Though perhaps the definition is of RHASH_len? > >    RHASH_len:  The natural length of the RHASH Algorithm in bits. > > > But that really should be clear in its name.  I am leaving this in > unless someone says to pull it. > >> >>>     Responder:  The host that responds to the Initiator in the HIP DEX >>>        handshake.  This role is typically forgotten once the >>> handshake is >>>        completed. >>> >>> [same thing re "typically"] >> >> Same response. >> >>> Section 3 >>> >>>     HIP DEX implementations MUST support the Elliptic Curve Diffie- >>>     Hellman (ECDH) [RFC6090] key exchange for generating the HI as >>>     defined in Section 5.2.3.  No additional algorithms are >>> supported at >>>     this time. >>> >>> It's kind of weird to see a "MUST" for "RFC6090 key exchange"; 6090 >>> discusses the general class of things but is not a specific key >>> exchange >>> algorithm (e.g., curve). >>> I'd also consider s/supported/defined/. >> >> Good point.  Changed to: >> >>    HIP DEX implementations use the Elliptic Curve Diffie-Hellman (ECDH) >>    [RFC6090] key exchange for generating the HI as defined in >>    Section 5.2.3.  No alternative algorithms are defined at this time. >> >>>     Due to the latter property, an attacker may be able to find a >>>     collision with a HIT that is in use.  Hence, policy decisions >>> such as >>>     access control MUST NOT be based solely on the HIT. Instead, the HI >>>     of a host SHOULD be considered. >>> >>> I don't think this is correct or a strong enough statement. In >>> particular, I don't think access control should be based on the HIT at >>> all, so strike "solely".  Also, the "SHOULD" seems too week. I can >>> understand that "MUST use the HI" could be overly constraining, but >>> "access control decisions MUST be made on the actual identity of the >>> host, e.g., the full HI" should allow for sufficient flexibility. >> >> I will see how this changes with the ACL additions. > > See sec 71. and this text changed to: > >    Due to the latter property, an attacker may be able to find a >    collision with a HIT that is in use.  Hence, policy decisions such as >    access control MUST NOT be based solely on the HIT.  Instead, the HI >    of a host SHOULD be considered (see Section 7.1). > > >> >>>     Carrying HIs and HITs in the header of user data packets would >>>     increase the overhead of packets.  Thus, it is not expected that >>> >>> s/and/or/? >> >> fixed. >> >>>     association.  When other user data packet formats are used, the >>>     corresponding extensions need to define a replacement for the >>>     ESP_TRANSFORM [RFC7402] parameter along with associated semantics, >>>     but this procedure is outside the scope of this document. >>> >>> Why is ESP_TRANSFORM the most important parameter here, when we talk >>> about mapping a packet to the HIP association?  I thought ESP_TRANSFORM >>> was literally about the encryption mechanics, not metadata around it. >> >> Again, this goes back to 5201.  We are talking about ~20 years of >> discussions. >> >> We are discussing HIs and HITs, but that SPIs are used in everyday >> packets as the pointer to the HIs and HITs involved.  I will think on >> this, but it is down the list on things to change that were inherited >> from 5201. >> >>> Section 3.2 >>> >>> ORCHID claims to provide statistical uniqueness and routability at some >>> overlay layer, neither of which this FOLD procedure provides, due to >>> easily-generatable second preimages. >>> >>> Section 3.2.1 >>> >>>     Since collision-resistance is not possible with the tools at hand, >>>     any reasonable function (e.g.  FOLD) that takes the full value >>> of the >>>     HI into generating the HIT can be used, provided that collision >>>     detection is part of the HIP-DEX deployment design.  This is >>> achieved >>> >>> This is not an argument that this is a reasonable thing to do; it's >>> merely an argument that it's a thing that can be done that has the same >>> claimed properties as the only type of thing that could be done.  It >>> might be a bad idea to do the only type of thing that can be done, and >>> you have not convinced me otherwise.  (See also the distinction between >>> collision-resistance and second-preimage-resistance alluded to in my >>> comment on the previous section.) >> >> Other changes may help, or not.  We can rejoin this point after draft >> 14 (note I will be pushing out draft 13 today for the publish >> deadline for changes done so far). >> >>>     here through either an ACL or some other lookup process that >>>     externally binds the HIT and HI. >>> >>> Without at least one well-specified mechanism for actually doing this >>> and clear documentation of what precise properties such a mechanism >>> needs to provide, I think it's irresponsible to publish this document. >> >> In the works. > > sec 7.1 > >> >>> Section 4.1 >>> >>>     By definition, the system initiating a HIP Diet EXchange is the >>>     Initiator, and the peer is the Responder.  This distinction is >>>     typically forgotten once the handshake completes, and either party >>>     can become the Initiator in future communications. >>> >>> ["typically" again] >> >> same response. >> >>>     Diffie-Hellman Group IDs supported by the Initiator.  Note that in >>>     some cases it may be possible to replace this trigger packet by >>> some >>>     other form of a trigger, in which case the protocol starts with the >>>     Responder sending the R1 packet.  In such cases, another >>> mechanism to >>>     convey the Initiator's supported DH Groups (e.g., by using a >>> default >>>     group) must be specified. >>> >>> This seems under-specified for a proposed standard and is probably >>> better off omitted entirely. >> >> This is carried over from 5201, which WAS experimental.  So I can see >> it as reasonable to drop this as no one proposed another mechanism. > > dropped. > >> >>    The Initiator first sends a trigger packet, I1, to the Responder. >>    This packet contains the HIT of the Initiator and the HIT of the >>    Responder, if it is known.  Moreover, the I1 packet initializes the >>    negotiation of the Diffie-Hellman group that is used for generating >>    the Master Key SA.  Therefore, the I1 packet contains a list of >>    Diffie-Hellman Group IDs supported by the Initiator. >> >> >>>     The second packet, R1, starts the actual authenticated >>> Diffie-Hellman >>>     key exchange.  It contains a puzzle - a cryptographic challenge >>> that >>>     the Initiator must solve before continuing the exchange. The level >>>     of difficulty of the puzzle can be adjusted based on level of trust >>>     with the Initiator, current load, or other factors.  In >>> addition, the >>> >>> The Initiator is unauthenticated at this point, so "level of trust" >>> seems to not really be defined... >> >> Changed to "knowledge of the".  If the Responder "knows" that the >> Initiator is a sensor, using a smaller puzzle may be preferred. there >> is discussion about large puzzles being an attack on sensors. >> >>> Section 4.1.1 >>> >>> If an unconstrained (DoSing) attacker is competing with a constrained >>> honest initiator to solve puzzles during an attack, it seems like the >>> honest initiator is going to lose out pretty badly. >> >> You do what you can that makes some degree of sense.  You just don't >> walk away from the problem. >> >>> Section 4.1.4 >>> >>> There are security considerations for serializing the HIP state to >>> nonvolatile storage! >> >> Do you want text about this in the Securities Considerations? >> From nobody Fri Mar 20 11:33:40 2020 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 B90FA3A0CF8; Fri, 20 Mar 2020 11:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 EsuNl9IGfhvv; Fri, 20 Mar 2020 11:33:14 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 EF5D53A0DD2; Fri, 20 Mar 2020 11:33:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 3F299621A0; Fri, 20 Mar 2020 14:33:13 -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 yh8S7bFf1at7; Fri, 20 Mar 2020 14:32:54 -0400 (EDT) Received: from lx140e.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 311A66212E; Fri, 20 Mar 2020 14:32:54 -0400 (EDT) From: Robert Moskowitz To: Roman Danyliw , The IESG Cc: draft-ietf-hip-dex@ietf.org, hip-chairs@ietf.org, hipsec@ietf.org, Gonzalo Camarillo References: <158334648514.29413.16902420341202011591@ietfa.amsl.com> <5ada15b1-0a2d-589e-4f4c-744124b5c479@labs.htt-consult.com> Message-ID: <17f31790-9f5a-daad-2702-a96a6899d6d6@labs.htt-consult.com> Date: Fri, 20 Mar 2020 14:32:53 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <5ada15b1-0a2d-589e-4f4c-744124b5c479@labs.htt-consult.com> Content-Type: multipart/alternative; boundary="------------E0ACCAA8F0B262735F78ADBA" Content-Language: en-US Archived-At: Subject: Re: [Hipsec] Roman Danyliw's Discuss on draft-ietf-hip-dex-13: (with DISCUSS and COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 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, 20 Mar 2020 18:33:32 -0000 This is a multi-part message in MIME format. --------------E0ACCAA8F0B262735F78ADBA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Roman, In ver -17, I have added the hex values for CKDF-Extract and CKDF-Expand. Please let me know where you stand on my various responses. Bob On 3/17/20 9:11 AM, Robert Moskowitz wrote: > I am cutting off all I have responded to in v 14 & 15. > > I have posted ver 16. > > there is one outstanding issue about the proper octet encoding, see > below.  I am open to what to use for that. > > Otherwise, I believe I have addressed all of Roman's comments either > with changes to the draft of explanations in my email responses. > > > On 3/6/20 9:21 AM, Robert Moskowitz wrote: >> >> >> On 3/4/20 1:28 PM, Roman Danyliw via Datatracker wrote: >>> Roman Danyliw has entered the following ballot position for >>> draft-ietf-hip-dex-13: Discuss >>> >>> 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 tohttps://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-dex/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> (initial ballot now that this draft is deferred) >>> >>> >> >>> ** Section 6.3. The input to CKDR-Extract seems underspecified: >>> -- Per the definition of IKM, when should these different inputs be used (at >>> least two appear to be specified)? References to Kij are made in this section >>> and in other parts of the document, but they aren’t input for CKDR-Extract()? >> >> Will research this and see if more text is needed and how. > > KEYMAT is used for both the Master Key and Pair-wise Key. > >    The key derivation for the Master Key SA employs always both the >    Extract and Expand phases.  The Pair-wise Key SA needs only the >    Extract phase when the key is smaller or equal to 128 bits, but >    otherwise requires also the Expand phase. > > So there are 2 IKMs: > >        IKM       Input keying material >                    the Diffie-Hellman derived key, concatenated with the >                      random I_NONCE value for the Master Key SA >                    the Diffie-Hellman derived key, concatenated with the >                      random values of the ENCRYPTED_KEY parameters in >                      the same order as the HITs with sort(HIT-I | HIT-R) >                      for the Pair-wise Key SA > > If you want the IKM better explained, I will expand the text somehow.  > This is in an artwork block right now. > > > And yes, Kij is used in both places.  This is the result of extensive > discussions with Hugo Krawczyk and Lily Chen on how to safely use > CMAC.  Or as safe as possible and within the bounds of this > application.  Those discussions are somewhere back in my archives... > >> >>> -- Per “where ‘CKDF-Extract’ is an octet string “ in the definition of “info” >>> in CKDR-Extract(), what encoding should be used to convert that into an octet >>> string? Is it ASCII, as in 067 075 068 070 045 069 120 116 114 097 099 116? >> >> Will check this too. > > This approach I have historically seen a lot in standards.  The > character string is supplied with the instruction to use the octet > equiv.  You make a very valid point.  In fact NIST SP800-185 is very > explicit in supplying the text string and then the bit representation. > > Using an online text to octet converter > (https://www.browserling.com/tools/text-to-octal) I got: > > 103 113 104 106 55 105 170 164 162 141 143 164 > > So WHAT IS the proper value?  Can an Implementer jump in here?  I will > specify whatever binary is agreed on... > >> >>> ** Section 9. Please add language to the effect that “production deployments >>> of this specification MUST NOT use the NULL-ENCRYPT HIP_CIPHER” (to mirror the >>> language already stated in Section 5.2.2 on the topic). >> >> Good point.  Will do. > > Done.  See sec 9.3 > >> >>> ** Section 9.2. This mandatory guidance to validate public keys is helpful. >>> Please provide guidance in an explicit step in the appropriate packet >>> processing section (i.e., in Section 6.*) on when this should be done. >> >> I thought I did.  Grumble.  Will take care of this too. > > Done. Sec 6.7 step 4 and 6.8 step 5. > >> >>> Two “discuss discuss”-es with the caveat that I didn’t follow the WG >>> discussions. >>> >>> ** The following seems to indicate we don’t have everything we need to publish >>> a standards track document: -- Section 6. “It should be noted that many of the >>> packet processing rules are denoted here with "SHOULD" but may be updated to >>> "MUST" when further implementation experience provides better guidance.” >> >> I did not want this, if I recall correctly.  It was something of a >> standard wording back when this was first done.  At this point, I >> will pull this.  It is not uncommon that a standard goes out and then >> some years later deployment teaches us things about what SHOULD and >> what MUST. > > I have pulled this para. > >> >>> -- Section 9. “o The puzzle mechanism using CMAC explained in Section 4.1.1 >>> may need further study regarding the level of difficulty in order to establish >>> best practices with current generation of constrained devices.” >>> >>> If there isn’t sufficient implementation experience, why isn’t this document >>> experimental? What is the plan for getting better guidance? Is there a risk >>> in not having this clarity? >> >> Actually this is another area that can be pulled now.  Rene did >> testing on the difficulty and I believe we captured his experiences.  >> I will look at this and clarify. > > I have dropped this paragraph.  The proper behavior, based on testing, > is described in sec 7.  This was old text that should have been pulled > versions ago. > >> >>> ** Section 9.1. Thanks for this section. However, I’m not convinced that >>> SECP160R1 is needed. DEX is already selectively profiling RFC7401 (i.e., its >>> already choosing to exclude certain things) and there are “no production” >>> implementation of DEX. What is the rationale for keeping it? >> >> In the workgroup I was asked to keep it in?  To /harmonize/ with >> other areas of constrained security?  This is some years back though, >> and it is another area where by this time, we have enough to drop >> it?  I am willing to, but I should ask on the HIPSEC list and see >> what private replies I get. > > I have removed SECP160R1.  I have kept the text as comments in the XML > if there is later pushback for including it. > >> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> ** Section 3.0. Per “Thus, it is not expected that these parameters are >>> carried in every packet, but other methods are used to map the data packets to >>> the corresponding His”, what are these other methods? >> >> This text is lifted right out of sec 3 of rfc7401.  ESP SPIs are a >> stated example further in that paragraph. >> >>> ** Section 3.1. Per “There are two advantages of using a hashed encoding over >>> the actual variable-sized public key in protocols.”, perhaps as a reminder is >>> in order that in this document the HIT isn’t a hashed encoding but a compressed. >> >> A case of lifting text from 7401 where it needs to be adjusted a >> bit.  I will make the change. > > Change made. > >> >>> ** Section 4.1. Per “Note that in some cases it may be possible to replace >>> this trigger packet by some other form of a trigger, in which case the >>> protocol starts with the Responder sending the R1 packet.”, how does this >>> additional trigger occur? >> >> Some packet that has enough information for the receiver to deduce >> that an I1 COULD have been sent and to then respond with an R1 to see >> if the sender supports HIP. >> >> None have been defined.  This actually goes back to 5201.  More of a >> placeholder to allow others to make adjustments in their implementation. >> >>> ** Section 4.1. Per “In such cases, another mechanism to convey the Initiator's >>> supported DH Groups (e.g., by using a default group) must be specified.”, >>> where/how would it be specified? >> >> Again, nothing has been specified, but in a closed environment it was >> thought that an ACL or other data store would contain enough >> information, like the supported DH Groups to successfully trigger an >> R1 without receiving an I1.  This is more a placeholder for any >> developer that is working on an alternative to using the I1 to note >> all that must be done if something other than an I1 is used. >> >> "If you are going to try and optimize this protocol, remember all >> that you have to include" kind of thing. >> >>> ** Section 4.1.2.1. Per “This strategy is based on a timeout that is set to a >>> value larger than the worst-case anticipated round-trip time (RTT ).”, how is >>> the worst case RTT computed? >> >> IIRC, the implementers want this in.  It goes back to 5201, sec 6.6.  >> Perhaps one that is still around (hint, Jeff or Tom) can comment. > > I am leaving this as is.  I am open to changes, if someone provides me > with actual numbers. > >> >>> ** Section 5.3.2. Per “Based on the deviating DH group ID in the HOST_ID >>> parameter, the Initiator then SHOULD abort …”, why not MUST abort? >> >> A MUST costs a round trip.  It is possible that the Initiator, based >> on local policy, can make a decision to go with the received R1 >> rather than restart the exchange.  Thus we chose SHOULD here over MUST. >> >>> ** Section 6.8. Step 5. Per “5. If any of the checks above fail, there is a >>> high probability of an ongoing man-in-the-middle or other security attack. The >>> system SHOULD act accordingly, based on its local policy.”, this guidance seems >>> underspecified. Could the text at least provide a recommendation of aborting >>> and logging? >> >> Seems reasonable request.  But this text goes back to 5201. Perhaps >> some of the HIPv1 and/or v2 implementors can tell want they do here. >> >>> ** Section 9. Per “The strength of the keys for the Pair-wise Key SA is based >>> on the quality of the random keying material. As either peer may be a sensor >>> or an actuator device, there is a natural concern about the quality of its >>> random number generator.”, this is helpful caution. What guidance can be given >>> to ameliorate the concern? >> >> When we did IEEE 802.11i, we actually had an annex giving pseudo code >> for gathering entropy by listening to the radio noise or how to build >> an ring-occilator on your chip. >> >> Is there any good IETF RFC recommendation on a good RND for >> constrained devices?  I would be happy to include copied text or a >> reference. > > Additional text has been added. > > --------------E0ACCAA8F0B262735F78ADBA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Roman,

In ver -17, I have added the hex values for CKDF-Extract and CKDF-Expand.

Please let me know where you stand on my various responses.

Bob

On 3/17/20 9:11 AM, Robert Moskowitz wrote:
I am cutting off all I have responded to in v 14 & 15.

I have posted ver 16. 

there is one outstanding issue about the proper octet encoding, see below.  I am open to what to use for that.

Otherwise, I believe I have addressed all of Roman's comments either with changes to the draft of explanations in my email responses.


On 3/6/20 9:21 AM, Robert Moskowitz wrote:


On 3/4/20 1:28 PM, Roman Danyliw via Datatracker wrote:
Roman Danyliw has entered the following ballot position for
draft-ietf-hip-dex-13: Discuss

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-dex/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(initial ballot now that this draft is deferred)

   

** Section 6.3.  The input to CKDR-Extract seems underspecified:
-- Per the definition of IKM, when should these different inputs be used (at
least two appear to be specified)?  References to Kij are made in this section
and in other parts of the document, but they aren’t input for CKDR-Extract()?

Will research this and see if more text is needed and how.

KEYMAT is used for both the Master Key and Pair-wise Key.

   The key derivation for the Master Key SA employs always both the
   Extract and Expand phases.  The Pair-wise Key SA needs only the
   Extract phase when the key is smaller or equal to 128 bits, but
   otherwise requires also the Expand phase.

So there are 2 IKMs:

       IKM       Input keying material
                   the Diffie-Hellman derived key, concatenated with the
                     random I_NONCE value for the Master Key SA
                   the Diffie-Hellman derived key, concatenated with the
                     random values of the ENCRYPTED_KEY parameters in
                     the same order as the HITs with sort(HIT-I | HIT-R)
                     for the Pair-wise Key SA

If you want the IKM better explained, I will expand the text somehow.  This is in an artwork block right now.


And yes, Kij is used in both places.  This is the result of extensive discussions with Hugo Krawczyk and Lily Chen on how to safely use CMAC.  Or as safe as possible and within the bounds of this application.  Those discussions are somewhere back in my archives...


-- Per “where ‘CKDF-Extract’ is an octet string “ in the definition of “info”
in CKDR-Extract(), what encoding should be used to convert that into an octet
string?  Is it ASCII, as in 067 075 068 070 045 069 120 116 114 097 099 116?

Will check this too.

This approach I have historically seen a lot in standards.  The character string is supplied with the instruction to use the octet equiv.  You make a very valid point.  In fact NIST SP800-185 is very explicit in supplying the text string and then the bit representation.

Using an online text to octet converter (https://www.browserling.com/tools/text-to-octal) I got:

103 113 104 106 55 105 170 164 162 141 143 164

So WHAT IS the proper value?  Can an Implementer jump in here?  I will specify whatever binary is agreed on...


** Section 9.  Please add language to the effect that “production deployments
of this specification MUST NOT use the NULL-ENCRYPT HIP_CIPHER” (to mirror the
language already stated in Section 5.2.2 on the topic).

Good point.  Will do.

Done.  See sec 9.3


** Section 9.2.  This mandatory guidance to validate public keys is helpful. 
Please provide guidance in an explicit step in the appropriate packet
processing section (i.e., in Section 6.*) on when this should be done.

I thought I did.  Grumble.  Will take care of this too.

Done. Sec 6.7 step 4 and 6.8 step 5.


Two “discuss discuss”-es with the caveat that I didn’t follow the WG
discussions.

** The following seems to indicate we don’t have everything we need to publish
a standards track document: -- Section 6.  “It should be noted that many of the
packet processing rules are denoted here with "SHOULD" but may be updated to
"MUST" when further implementation experience provides better guidance.”

I did not want this, if I recall correctly.  It was something of a standard wording back when this was first done.  At this point, I will pull this.  It is not uncommon that a standard goes out and then some years later deployment teaches us things about what SHOULD and what MUST.

I have pulled this para.


-- Section 9.  “o  The puzzle mechanism using CMAC explained in Section 4.1.1
may need further study regarding the level of difficulty in order to establish
best practices with current generation of  constrained devices.”

If there isn’t sufficient implementation experience, why isn’t this document
experimental?  What is the plan for getting better guidance?  Is there a risk
in not having this clarity?

Actually this is another area that can be pulled now.  Rene did testing on the difficulty and I believe we captured his experiences.  I will look at this and clarify.

I have dropped this paragraph.  The proper behavior, based on testing, is described in sec 7.  This was old text that should have been pulled versions ago.


** Section 9.1.  Thanks for this section.  However, I’m not convinced that
SECP160R1 is needed.  DEX is already selectively profiling RFC7401 (i.e., its
already choosing to exclude certain things) and there are “no production”
implementation of DEX.  What is the rationale for keeping it?

In the workgroup I was asked to keep it in?  To harmonize with other areas of constrained security?  This is some years back though, and it is another area where by this time, we have enough to drop it?  I am willing to, but I should ask on the HIPSEC list and see what private replies I get.

I have removed SECP160R1.  I have kept the text as comments in the XML if there is later pushback for including it.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** Section 3.0.  Per “Thus, it is not expected that these parameters are
carried in every packet, but other methods are used to map the data packets to
the corresponding His”, what are these other methods?

This text is lifted right out of sec 3 of rfc7401.  ESP SPIs are a stated example further in that paragraph.

** Section 3.1.  Per “There are two advantages of using a hashed encoding  over
the actual variable-sized public key in protocols.”, perhaps as a reminder is
in order that in this document the HIT isn’t a hashed encoding but a compressed.

A case of lifting text from 7401 where it needs to be adjusted a bit.  I will make the change.

Change made.


** Section 4.1.  Per “Note that in some cases it may be possible to replace
this trigger packet by some  other form of a trigger, in which case the
protocol starts with the Responder sending the R1 packet.”, how does this
additional trigger occur?

Some packet that has enough information for the receiver to deduce that an I1 COULD have been sent and to then respond with an R1 to see if the sender supports HIP.

None have been defined.  This actually goes back to 5201.  More of a placeholder to allow others to make adjustments in their implementation. 

** Section 4.1. Per “In such cases, another mechanism to convey the Initiator's
supported DH Groups (e.g., by using a default group) must be specified.”,
where/how would it be specified?

Again, nothing has been specified, but in a closed environment it was thought that an ACL or other data store would contain enough information, like the supported DH Groups to successfully trigger an R1 without receiving an I1.  This is more a placeholder for any developer that is working on an alternative to using the I1 to note all that must be done if something other than an I1 is used.

"If you are going to try and optimize this protocol, remember all that you have to include" kind of thing.

** Section 4.1.2.1. Per “This strategy is based on a timeout that is set to a
value larger than the worst-case anticipated round-trip time (RTT ).”, how is
the worst case RTT computed?

IIRC, the implementers want this in.  It goes back to 5201, sec 6.6.  Perhaps one that is still around (hint, Jeff or Tom) can comment.

I am leaving this as is.  I am open to changes, if someone provides me with actual numbers.


** Section 5.3.2.  Per “Based on the deviating DH group ID in the HOST_ID
parameter, the Initiator then SHOULD abort …”, why not MUST abort?

A MUST costs a round trip.  It is possible that the Initiator, based on local policy, can make a decision to go with the received R1 rather than restart the exchange.  Thus we chose SHOULD here over MUST.

** Section 6.8. Step 5.  Per “5.  If any of the checks above fail, there is a
high probability of an ongoing man-in-the-middle or other security attack.  The
system SHOULD act accordingly, based on its local policy.”, this guidance seems
underspecified.  Could the text at least provide a recommendation of aborting
and logging?

Seems reasonable request.  But this text goes back to 5201.  Perhaps some of the HIPv1 and/or v2 implementors can tell want they do here.

** Section 9.  Per “The strength of the keys for the Pair-wise Key SA is based
on the quality of the random keying material.  As either peer may be a sensor
or an actuator device, there is a natural concern about the quality of its
random number generator.”, this is helpful caution. What guidance can be given
to ameliorate the concern?

When we did IEEE 802.11i, we actually had an annex giving pseudo code for gathering entropy by listening to the radio noise or how to build an ring-occilator on your chip.

Is there any good IETF RFC recommendation on a good RND for constrained devices?  I would be happy to include copied text or a reference.

Additional text has been added.



--------------E0ACCAA8F0B262735F78ADBA-- From nobody Sun Mar 22 09:58:05 2020 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 F199C3A086A; Sun, 22 Mar 2020 09:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 OWZcn-IjasfC; Sun, 22 Mar 2020 09:57:30 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2060b.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e1a::60b]) (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 C616C3A086C; Sun, 22 Mar 2020 09:57:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RLsER3MMJzgRI7xETR962To0qEkiBwjHjzpyEHEkks9X+ahDEZRCrlNpSYLw0Xr+jjM8+1wWWE+yEtFsAQGZSAwpVMs10PhvimBLfJ9kWIywC+DdP00qSB86Af6s2oy10EoODq7kJLZpQkMA2msT2Q7oSwbTOIBBIcaBMFNoq+wij6z0abCTbC+khVR2cJgFJ7ITL9bNoSO4C66nZGhEFs8U08ZidFTP6ev4Nu/stUEpijTmqMKJ2JJ0tZPA2/8jK7whGv8iwpQSrkMVKVZZSyCVho2Tk2NB5IlR8i0jehh8nwoS8mMsVXNZVr7HZHQfCz0qsiw/OxoEcT6ffajdlQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6lZQTXUdCEiIyEYqAi/WD3NoEpXNmxKnHOkSkqp94bU=; b=aCS4Wv3DOJQUygYxZGiRkXdedZTQyup0/yU9F+lLw//0wFbcDMgeK/phgd2SLxGiLN+qAnirgNAgvQjxT7LP6slxJLyqOTy7ySEGzf/bkXJt4k3+wRrLA0+2dtShTkQWdJz7ItlEBXH1SeLP8AdZguWKkbd0Jq2cFsXEWnmwuGToX3vI40weItFnVVUJCqFMMKc2iCEi/W/ILXSCZ5Vyv5CSrseW/MrfF+lLpryeT5XgB8LQlK+JFFS5fX/68ahmpzan1PQsoDRk4ZuK9WaC/tjurguKZbEr5HisUkpn51FNFe8aj6VIMgWFxvYFnXl3uaPyYR7EuStjjTzMt+2D0w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6lZQTXUdCEiIyEYqAi/WD3NoEpXNmxKnHOkSkqp94bU=; b=LZ+xjEdPbHIIb8D4PeTzlMOsNsy8wn7F/++ah1uYBmIh7M1C4ZeZhYyhH3CK6Latw8JGWTlEofTyVEgCTspG3o8cE+3rrADsqn5C9MIRNzj4WKZNjfTTNoSDP/5MdAnEuqC1n4t3tsqfUMS3dW1d28qqOqcCPCd5PcfCFm5nbOs= Received: from AM0PR07MB3876.eurprd07.prod.outlook.com (52.134.81.144) by AM0PR07MB4019.eurprd07.prod.outlook.com (52.134.83.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.12; Sun, 22 Mar 2020 16:57:27 +0000 Received: from AM0PR07MB3876.eurprd07.prod.outlook.com ([fe80::c93a:7b44:e182:cef6]) by AM0PR07MB3876.eurprd07.prod.outlook.com ([fe80::c93a:7b44:e182:cef6%6]) with mapi id 15.20.2856.003; Sun, 22 Mar 2020 16:57:27 +0000 From: Miika Komu To: "kaduk@mit.edu" CC: "draft-ietf-hip-native-nat-traversal@ietf.org" , "iesg@ietf.org" , "hip-chairs@ietf.org" , Gonzalo Camarillo , "hipsec@ietf.org" Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-hip-native-nat-traversal-28: (with COMMENT) Thread-Index: AQHT56bIW3pBexwvIU6mnAuiqBSniKglMLKAgAsbmgCAKLpTAA== Date: Sun, 22 Mar 2020 16:57:27 +0000 Message-ID: <8f6fb915f35c890ae12b25ad3744bdea393ffe14.camel@ericsson.com> References: <152587816145.3957.17385929656409014655.idtracker@ietfa.amsl.com> <83fe234a038ca40ab181523bbbe3e4eb253c9e06.camel@ericsson.com> <20200225190010.GB56312@kduck.mit.edu> In-Reply-To: <20200225190010.GB56312@kduck.mit.edu> Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.1 authentication-results: spf=none (sender IP is ) smtp.mailfrom=miika.komu@ericsson.com; x-originating-ip: [88.148.205.35] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 35cca59a-82ca-4661-fea2-08d7ce821a00 x-ms-traffictypediagnostic: AM0PR07MB4019: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0350D7A55D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(346002)(136003)(396003)(376002)(366004)(199004)(478600001)(6916009)(91956017)(76116006)(6486002)(44832011)(71200400001)(4326008)(2616005)(8936002)(316002)(966005)(5660300002)(186003)(86362001)(36756003)(6506007)(66446008)(66556008)(64756008)(26005)(2906002)(8676002)(6512007)(66476007)(66946007)(66574012)(54906003)(81156014)(81166006)(99106002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB4019; H:AM0PR07MB3876.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SSZsGmTDhyLOXpgidg1E8TcUIjx+gVwna+iJAZr6wxdjsK8ZmDrrdGx4HHk2hyQb502PC3nhmvPVpv6hwjNY92XPujLMhul0j5n+6o5EmCPKyHHgDQSEi7D/fud9O8C05VX92Sh1/gGonll2YjdbC5pDDoGVVQxm6smNMi2AijiGTo3DsYRHQoSdGLuvZKJ86JD7K7EOT2zqB9iMOTdqc53khPhYbSKNj/LnCU2xE8FZrtux7lIXBiJRDExlGxND0dhvuz7le3we+05iwpPz7Oal6Ikr+S2x99xmsW8xzX2JJC/eRnSSDnb7AaBzf9Vw9ed11P2UGRo/Y3ngIsS0KZL/iKQoyf6VO8avnhPfnSMgtkIyfff3HyUkmznjE7WL32y0o+ioWNh5mNACTM9cqDdeieD9xpMDpyDnFFHHTmrTbN0cXPiYcYG/pggFWpjHoC3Ts0+QQEz/YweGp70ZfHT/H/lEoFC8BmV2DKPjlfA/CwAiuiJD+swHV3Ab++96QCkkSnOmYRGyGeg5IeYfT3hNXSQBhy8fPyyCpM8AceB7t5cBbUtCLvqTbJXZHN4q x-ms-exchange-antispam-messagedata: Qy3IzNy3/ZOUzUPg1yM3VSOcmvVvgOPHKqibIg1x/UOWpkV798XpLiIoZNzKAL+TfH0W5jFkGdEkV2fOQTU+djM03lRRPh6WfPw7vhvZKpp3liAR0ausmS49SrHgjqltC6zWASAdlBMUpG5aOBYqZA== Content-Type: text/plain; charset="utf-8" Content-ID: <65E6F1592AF96D4AABD8ABE0ADA70A73@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 35cca59a-82ca-4661-fea2-08d7ce821a00 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2020 16:57:27.2208 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: IX4PcncDhfSWSRRaT2RXGoyDUFWYX5arzqfHVxCKWtdJT5y91nP+3mUE0fX528H9o0ZJngMM7BV+BZ2/lR8G3A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4019 Archived-At: Subject: Re: [Hipsec] Benjamin Kaduk's No Objection on draft-ietf-hip-native-nat-traversal-28: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 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, 22 Mar 2020 16:57:35 -0000 SGkgQmVuamFtaW4sDQoNCnRpLCAyMDIwLTAyLTI1IGtlbGxvIDExOjAwIC0wODAwLCBCZW5qYW1p biBLYWR1ayBraXJqb2l0dGk6DQoNCj4gPiA+IFsuLi5dDQo+ID4gPiBTb21lIHNlY3Rpb24tYnkt c2VjdGlvbiBjb21tZW50cyBmb2xsb3cuDQo+ID4gPiANCj4gPiA+IFNlY3Rpb24gMg0KPiA+ID4g DQo+ID4gPiAgICBSZXNwb25kZXI6DQo+ID4gPiAgICAgICBUaGUgUmVzcG9uZGVyIGlzIHRoZSBo b3N0IHRoYXQgcmVjZWl2ZXMgdGhlIEkxIHBhY2tldCBmcm9tDQo+ID4gPiB0aGUNCj4gPiA+ICAg ICAgIEluaXRpYXRvci4NCj4gPiA+IA0KPiA+ID4gRG9lcyB0aGlzIHN0aWxsIGhvbGQgaWYgdGhl IG1lc3NhZ2UgaXMgbWlzZGVsaXZlcmVkIG9yIGFuDQo+ID4gPiBhdHRhY2tlcg0KPiA+ID4gaXMg aW4gdGhlIG5ldHdvcms/DQo+ID4gDQo+ID4gSWYgbWlzZGVsaXZlcmVkLCB0aGUgSElUcyBkb24n dCBtYXRjaCBhbmQgdGhlIHJlY2VpdmVyIGhvc3QgZHJvcHMNCj4gPiB0aGUNCj4gPiBwYWNrZXQg YXMgZG9jdW1lbnRlZCBpbiB0aGUgYmFzZSBleGNoYW5nZSBzcGVjaWZpY2F0aW9uIGluIFJGQzc0 MDENCj4gDQo+IEEgd2VsbC1iZWhhdmVkIHJlY2VpdmVyIGhvc3QgZHJvcHMgdGhlIHBhY2tldDsg d2hhdCBpZiB0aGUgaG9zdCBpcw0KPiB1bmRlcg0KPiB0aGUgY29udHJvbCBvZiBhbiBhdHRhY2tl cj8NCg0KbGV0J3Mgc2F5IHRoZSByZWNpcGllbnQgb2YgSTEgbWVzc2FnZSBpcyBhbiBhdHRhY2tl ciB0aGF0IGRvZXMgbm90IGhhdmUNCnRoZSBuZWNlc3NhcnkgcHJpdmF0ZSBrZXkgKHRvIGdlbmVy YXRlIHRoZSBzYW1lIGRlc3RpbmF0aW9uIEhJVCBhcyBpbg0KdGhlIEkxIG1lc3NhZ2UpIGJ1dCBy ZXNwb25kcyB3aXRoIGFuIFIxLiBUaGUgaW5pdGlhdG9yIHJlY2VpdmVzIHRoZSBSMQ0KYW5kIHN0 YXJ0cyBwcm9jZXNzaW5nIGl0Og0KDQphKSBBc3N1bWluZyB0aGUgYXR0YWNrZXIganVzdCBnZW5l cmF0ZWQgYSByYW5kb20gcHJpdmF0ZSArIHB1YmxpYyBrZXksDQp0aGUgc291cmNlIEhJVCBvZiBS MSBkb2VzIG5vdCBtYXRjaCB3aXRoIGRlc3RpbmF0aW9uIEhJVCBvZiBJMSwgYW5kIHRoZQ0KSW5p dGlhdG9yIGp1c3QgZHJvcHMgdGhlIG1lc3NhZ2UuIEl0IGlzIHdvcnRoIG5vdGluZyB0aGF0IHRo ZSBJbml0aWF0b3INCmNhbiBhbHNvIGNoZWNrIHRoZSBwdWJsaWMga2V5IHdoZW4gaXQgaGFzIGJl ZW4gY29uZmlndXJlZCB0byBpdCBvcg0Kb2J0YWluZWQgZnJvbSBETlMgKFJGQzgwMDUpLg0KDQpi KSBBc3N1bWluZyB0aGUgYXR0YWNrZXIgaGFzIHJlcGxheWVkIGFuIFIxLCB0aGlzIHByb3RlY3Rl ZCBieSBSMQ0KZ2VuZXJhdGlvbiBjb3VudGVyIGFzIGRvY3VtZW50ZWQgaW4gDQpodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNzQwMSNzZWN0aW9uLTQuMS40DQoNClRoaXMgbm90IHJlYWxs eSByZWxhdGVkIHRvIGRyYWZ0LWlldGYtaGlwLW5hdGl2ZS1uYXQtdHJhdmVyc2FsLTI4IGJ1dA0K dGhlIHVuZGVybHlpbmcgcHJvdG9jb2wgKFJGQzc0MDEpOyBkbyB5b3Ugc3RpbGwgdGhpbmsgc29t ZXRoaW5nIHNob3VsZA0KYmUgbWVudGlvbmVkPw0KDQo+ID4gPiBbLi4uXQ0KPiA+ID4gU2VjdGlv biA0LjUNCj4gPiA+IA0KPiA+ID4gICAgSW4gc3RlcCAyLCB0aGUgQ29udHJvbCBSZWxheSBTZXJ2 ZXIgcmVjZWl2ZXMgdGhlIEkxDQo+ID4gPiBwYWNrZXQuICBJZg0KPiA+ID4gdGhlDQo+ID4gPiAg ICBkZXN0aW5hdGlvbiBISVQgYmVsb25ncyB0byBhIHJlZ2lzdGVyZWQgUmVzcG9uZGVyLCB0aGUg Q29udHJvbA0KPiA+ID4gUmVsYXkNCj4gPiA+ICAgIFNlcnZlciBwcm9jZXNzZXMgdGhlIHBhY2tl dC4NCj4gPiA+IA0KPiA+ID4gRG8gSElQIHBhcnRpY2lwYW50cyByZWdpc3RlciBzcGVjaWZpY2Fs bHkgYXMgUmVzcG9uZGVyL0luaXRpYXRvciwNCj4gPiA+IG9yDQo+ID4gPiBpcyB0aGlzIGp1c3Qg dGhhdCB0aGUgZW50aXR5IHRoYXQgaXMgUmVzcG9uZGVyIGluIHRoaXMgZXhjaGFuZ2UsDQo+ID4g PiBoYXMNCj4gPiA+IHJlZ2lzdGVyZWQgYXQgdGhlIENvbnRyb2wgUmVsYXkgU2VydmVyPw0KPiA+ IA0KPiA+IEkgdGhpbmsgdGhpcyBpcyBjb21tb24gY29uZnVzaW9uIHN0ZW1taW5nIGZyb20gUkZD ODAwMyBhbmQgIFJGQzgwMDQNCj4gPiA6KQ0KPiA+IA0KPiA+IEluaXRpYXRvciBqdXN0IG1lYW5z IHRoZSBwYXJ0aWNpcGFudCBzZW5kaW5nIHRoZSBJMSBvZiB0aGUgYmFzZQ0KPiA+IGV4Y2hhbmdl LCBhbmQgcmVzcG9uZGVyIGlzIHRoZSBwYXJ0aWNpcGFudCByZWNlaXZpbmcgdGhlIEkxIGFuZA0K PiA+IHJlc3BvbmRpbmcgd2l0aCBhbiBSMS4gQW5kIHRoZXJlIGFyZSB0d28gYmFzZSBleGNoYW5n ZXMgaW52b2x2ZWQ6DQo+ID4gb25lDQo+ID4gZHVyaW5nIHJlZ2lzdHJhdGlvbiBhbmQgdGhlIG90 aGVyIG9uZSB3aGVyZSB0aGUgYWN0dWFsIE5BVA0KPiA+IHRyYXZlcnNhbA0KPiA+IHByb2NlZHVy ZXMgdGFrZSBwbGFjZS4gUGVyaGFwcyB0aGlzIGNsYXJpZmllcyB0aGUgc2l0dWF0aW9uOg0KPiA+ IA0KPiA+IEJhc2UgZXhjaGFuZ2UgMTogdGhlIHJlZ2lzdHJhdGlvbiAoPWJhc2UgZXhjaGFuZ2Ug d2l0aCBzb21lIGV4dHJhDQo+ID4gcGFyYW1ldGVycykgeW91IGhhdmUgdGhlIGZvbGxvd2luZyBy b2xlczoNCj4gPiAqIENvbnRyb2wgUmVsYXkgQ2xpZW50ID0gSW5pdGlhdG9yMQ0KPiA+ICogQ29u dHJvbCBSZWxheSBTZXJ2ZXIgPSBSZXNwb25kZXIxDQo+ID4gDQo+ID4gQmFzZSBleGNoYW5nZSAy OiBkdXJpbmcgYSBiYXNlIGV4Y2hhbmdlIHZpYSBhIEhJUCByZWxheSwgdGhlIHJvbGVzDQo+ID4g YXJlDQo+ID4gYXMgZm9sbG93czoNCj4gPiAqIEluaXRpYXRvcjIgPSAoZm9yIGV4YW1wbGUgYSB3 ZWIgYnJvd3NlciBjb25uZWN0aW5nIHRvIGEgSElUIG9mDQo+ID4gUmVzcG9uZGVyMikNCj4gPiAq IENvbnRyb2wgUmVsYXkgU2VydmVyID0gc2FtZSBhcyBhYm92ZSAoaS5lLiBISVAgbWVzc2FnZSBm b3J3YXJkZXIpDQo+ID4gKiBSZXNwb25kZXIyID0gKGZvciBleGFtcGxlIGEgd2ViIHNlcnZlcikN Cj4gPiANCj4gPiAoTm90ZSB0aGF0IHRoZSBudW1iZXJzIDEtMSBhbmQgMi0yIGFyZSBjb3VwbGVk IHdpdGggZWFjaCBvdGhlcikNCj4gPiANCj4gPiBBZnRlciB0aGUgc2Vjb25kIGJhc2UgZWNoYW5n ZSwgSW5pdGlhdG9yMiBhbmQgUmVzcG9uZGVyMiBpbml0aWF0ZQ0KPiA+IHRoZQ0KPiA+IE5BVCB0 cmF2ZXJzYWwgcHJvY2VkdXJlcyB3aXRoIGVhY2ggb3RoZXIuDQo+ID4gDQo+ID4gV2UgaGF2ZSBj aG9zZW4gdG8gbmFtZSB0aGUgZW5kLWhvc3RzIGp1c3QgYXMgIkluaXRpYXRvciIgYW5kDQo+ID4g IlJlc3BvbmRlciIgaW4gdGhpcyBzZWN0aW9uIGJlY2F1c2UgdGhlIHJlZ2lzdHJhdGlvbiBpcyBk b2N1bWVudGVkDQo+ID4gaW4gYQ0KPiA+IHNlcGFyYXRlIHNlY3Rpb24uIFRoZSB0ZXJtaW5vbG9n eSBpcyBhbGlnbmVkIHdpdGggUkZDNzQwMSBidXQgSSBjYW4NCj4gPiB1bmRlcnN0YW5kIHlvdXIg Y29uZnVzaW9uIDopDQo+IA0KPiBJIGRvbid0IHRoaW5rIEknbSBhY3R1YWxseSBjb25mdXNlZCwg YnV0IEknbSBzYXlpbmcgdGhhdCBpZiB3ZSB0YWxrDQo+IGFib3V0IGENCj4gInJlZ2lzdGVyZWQg UmVzcG9uZGVyIiwgYSByZWFzb25hYmxlIHJlYWRlciBtaWdodCBpbmZlciB0aGF0IHRoZXJlIGlz DQo+IHNvbWUNCj4gZW50aXR5IHRoYXQgaGFzIHJlZ2lzdGVyZWQgdG8gYmUgYSBSZXNwb25kZXIs IHdoaWNoIGlzIG5vdCBleGFjdGx5DQo+IHdoYXQncw0KPiBnb2luZyBvbiAtLSB0aGVyZSdzIGFu IGVudGl0eSB0aGF0IGhhcyByZWdpc3RlcmVkLCBhbmQgcmVnaXN0cmF0aW9uDQo+IGlzDQo+IG5l ZWRlZCBpbiBvcmRlciB0byBiZSBhIHJlc3BvbmRlciB3aGVuIGJlaGluZCBhIE5BVCwgYW5kIGl0 IGhhcHBlbnMNCj4gdG8gYmUgdGhlDQo+IHJlc3BvbmRlciB0aGlzIHRpbWUuICBCdXQgaXQgaXMg ZnJlZSB0byBiZSBhbiBpbml0aWF0b3IgZm9yIG90aGVyDQo+IGV4Y2hhbmdlcw0KPiB3aXRob3V0 IGFkZGl0aW9uYWwgcmVnaXN0cmF0aW9uLg0KDQpJIGhvcGUgdGhpcyBjaGFuZ2UgcmVzb2x2ZXMg dGhlIGFtYmlndWl0eToNCg0KSWYgdGhlIGRlc3RpbmF0aW9uIEhJVCBiZWxvbmdzIHRvIGEgc3Vj Y2Vzc2Z1bGx5IHJlZ2lzdGVyZWQgQ29udHJvbA0KUmVsYXkgQ2xpZW50IChpLmUuLCB0aGUgaG9z dCBtYXJrZWQgIlJlc3BvbmRlciIgaW4gRmlndXJlIDQpLCB0aGUNCkNvbnRyb2wgUmVsYXkgU2Vy dmVyIHByb2Nlc3NlcyB0aGUgcGFja2V0Lg0KDQo+ID4gPiBbLi4uXQ0KPiA+ID4gU2VjdGlvbiA2 LjENCj4gPiA+IA0KPiA+ID4gVGhlIFJGQyA1NzcwIHRleHQgdGFsa3MgYWJvdXQgVFVSTiBzZXJ2 ZXJzLCBidXQgdGhhdCdzIG5vIGxvbmdlcg0KPiA+ID4gYXBwbGljYWJsZSBpbiB0aGlzIGRvY3Vt ZW50IChpbnN0ZWFkLCBEYXRhIFJlbGF5IFNmcm9tIGFuIENvbnRyb2wNCj4gPiA+IERhdGEgU2Vy dmVyIHNlcnZlci5lcnZlcnMgYXJlIHVzZWQgdG8NCj4gPiA+IHJlbGF5IGRhdGEgaW4gYSBzaW1p bGFyIHVzYWdlKS4NCj4gPiANCj4gPiBmaXhlZDoNCj4gPiANCj4gPiBXaXRoIHN1Y2ggYSBsZWdh Y3kgTkFULCB0aGUgb25seSBvcHRpb24gbGVmdCB3b3VsZCBiZSB0byB1c2UgYQ0KPiA+IHJlbGF5 ZWQNCj4gPiB0cmFuc3BvcnQgYWRkcmVzcyBmcm9tIGFuICpDb250cm9sIFJlbGF5IFNlcnZlciog c2VydmVyLg0KPiANCj4gVGhlICJmaXhlZCIgdmVyc2lvbiBzYXlzICJDb250cm9sIFJlbGF5IiBi dXQgSSB0aG91Z2h0IGl0IHdhcyBnb2luZw0KPiB0byBiZQ0KPiAiRGF0YSBSZWxheSI7IHlvdSBk aWRuJ3QgZXhwbGljaXRseSB0ZWxsIG1lIEkgd2FzIHdyb25nIGFib3V0IGl0LCBzbw0KPiBwbGVh c2UNCj4gY29uZmlybSBvbmUgd2F5IG9yIHRoZSBvdGhlci4uLg0KPiANCj4gVGhhbmtzIGZvciB0 aGUgdXBkYXRlcyENCg0Kc29ycnksIG15IGJhZCwgb2YgY291cnNlIGl0IHNob3VsZCBiZSBEYXRh IFJlbGF5LiBEb3VibGUgZml4ZWQgdmVyc2lvbg0Kd2lsbCBiZToNCg0KV2l0aCBzdWNoIGEgbGVn YWN5IE5BVCwgdGhlIG9ubHkgb3B0aW9uIGxlZnQgd291bGQgYmUgdG8gdXNlIGEgcmVsYXllZA0K dHJhbnNwb3J0IGFkZHJlc3MgZnJvbSBhbiBEYXRhIFJlbGF5IFNlcnZlci4NCg== From nobody Sun Mar 22 10:25:40 2020 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 F2D473A091A; Sun, 22 Mar 2020 10:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 SZW-v6M5yWz5; Sun, 22 Mar 2020 10:25:34 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40053.outbound.protection.outlook.com [40.107.4.53]) (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 1854F3A0915; Sun, 22 Mar 2020 10:25:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l1HtclbpAxhm8cYG3sSTRssvJ5FZrqROcvHO3IQ24ijjCAN2/dov72TKQl6H0GUAYdLAqYXRyy4RFYlVXP7vySSogif8bFjQZp1cXt8wPn25ZVhTiTS7kgyLBHTLLqCtIp294a1lGemOa+kzCbWfYaAdaaE8XmAHrB7+uM8M9ntMrX8JZi/0Mufi/aLIuvODYHbJcppAzhIRbcq4TBBZ2M89JWxZ0rvX7CCegPx9Sm/n6/+rfsNkROsg2ZEdAyHEBv+vBePni4qrKjUO58l34BVTbPTpOfNKVlbVwipBpD91crJZiA7vt7b4xJgIkZeXYPQBesQ3vX9pF2xkbK77eQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lyQwNjfi9cZ9vnHTYZUwGWvhuC17p0vCmNOULX3WK8A=; b=kFUHl0J2Kd94iX7KLrO8zoATL5aqY3yEBaO73o9B3DcQzjKjQvlod0oaAdNEdf2W98i6PVZkk7iLsbV9qOmaLwmB0bUjsO6pRAUbjsu2lvYLnZGqb8hjmKhib1YvotXDC5KcJXMxS1QYXOvAt7GiUxOhhEckVANj+yCb9FCc3lqel4lm9acAE4lthYpkOFm+P9rivw/hTlZcldXB3UOE/6xMkE0PkFw2ItKkv0Er9fGOm1nMhvWuQ9BT8c7/MVGTTP+mdj26EZOkhLaop3L0WxtjoB/oBDmVpkUAdizFIGjiCpL63KpQ4z+Yg32qeMbR3qLfo4j2W514VN6wOdeQ4g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lyQwNjfi9cZ9vnHTYZUwGWvhuC17p0vCmNOULX3WK8A=; b=MLoaSA/HDJZoToK99+OsTknxTcsIz7y66DgIwK3rdLmoTRZols4bWmzHZh1BqcJp2zctWLqpLgtUxI02kd6TOBQJOZovWxYmqCdxtSFTy7Jix+4IoXqfGwRZMZR7GYVl0YXDPCAr4fr2DtbTvY0MwfEpnXeGXpS/fo4mc0V58oI= Received: from AM0PR07MB3876.eurprd07.prod.outlook.com (52.134.81.144) by AM0PR07MB6178.eurprd07.prod.outlook.com (20.178.16.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.9; Sun, 22 Mar 2020 17:25:31 +0000 Received: from AM0PR07MB3876.eurprd07.prod.outlook.com ([fe80::c93a:7b44:e182:cef6]) by AM0PR07MB3876.eurprd07.prod.outlook.com ([fe80::c93a:7b44:e182:cef6%6]) with mapi id 15.20.2856.003; Sun, 22 Mar 2020 17:25:31 +0000 From: Miika Komu To: "iesg@ietf.org" , "ietf@kuehlewind.net" CC: "draft-ietf-hip-native-nat-traversal@ietf.org" , "hip-chairs@ietf.org" , Gonzalo Camarillo , "hipsec@ietf.org" Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-hip-native-nat-traversal-30:_(with_COMMENT)?= Thread-Index: AQHV7Mfgh8DGWDy3+0muxtTXmGvbzKhVBDaA Date: Sun, 22 Mar 2020 17:25:31 +0000 Message-ID: References: <158273711588.22544.290698498351853887.idtracker@ietfa.amsl.com> In-Reply-To: <158273711588.22544.290698498351853887.idtracker@ietfa.amsl.com> Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.1 authentication-results: spf=none (sender IP is ) smtp.mailfrom=miika.komu@ericsson.com; x-originating-ip: [88.148.205.35] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 34c4f011-a95f-4227-4e51-08d7ce8605db x-ms-traffictypediagnostic: AM0PR07MB6178: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0350D7A55D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(39860400002)(366004)(396003)(136003)(199004)(110136005)(36756003)(66574012)(8936002)(6486002)(966005)(186003)(224303003)(316002)(71200400001)(64756008)(6512007)(44832011)(54906003)(26005)(478600001)(66446008)(5660300002)(81166006)(2906002)(66946007)(66556008)(86362001)(81156014)(76116006)(91956017)(66476007)(2616005)(6506007)(4326008)(99106002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB6178; H:AM0PR07MB3876.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3lefPr2NUYsMRGw1lAwhuvVN38bfiArLwKNTGLs4n+9vzyUeCBIxKNVRE8+hFBzJM2ZW/mUQ6F1KLslS90RWlaa13hzsY/e1xic8aw/cBPFQszWiIsVBwgWOXIm+UTuqW1hyQe7dd4u4SUMtJXYBIyL50UyQM63JaSaKC6ClSGeAm3CK836YThfJcAMs3RugVL6tnYl6K/RjlOS6Ib1R5ESWuH4jW5nkeLTjsY3ZrYlMIL7ItHQJUe6lb5TMAp7n/CKI9MCScmLTkjT2xJjSkeor3qAljsms8ipLxByExPCQeW0VC1m9+p8Jm4K/LqsgeCa5BAqQ6FVNsQeTuM+ncNqGsvOF1OpapnVPvvdepEB0E7tFOyuss5Es5o8dXScAgYfkzP4fAMeWkQFX+oPP/+nGfbQ6qq3nOOecA3nnWnRdOFw8CfRvDZkHdNTH0+/rHIKR9ud0Y4OWn5VvFJpUQUMnrHqXA89IuZpU74lRXfCYVe0VMvayX8tn+d/9jRRIb2CH+I1umzqPV6oQcJesxt71ENuMibhrJx/8UxjRXzrKlcPr3FetSoFfE7v54cqE x-ms-exchange-antispam-messagedata: 9bTHc6c0KFLihLMnhjQvjCjZtp9dVSJuc1Cmy3qZV3yUJwvK48CZ79vRjq0oAC/IEkfXhHkU6mwm2fB9gySzxBr0GvZi7WjVKYhzq5FvLXXBOUs+SMJHQtBOQlwjVzzmiCG0t/+9AhxvgmyjjucKaw== Content-Type: text/plain; charset="utf-8" Content-ID: <2ABDDAF2706FAB41897E15982C21183D@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 34c4f011-a95f-4227-4e51-08d7ce8605db X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2020 17:25:31.4013 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: faYWjXLqfWeRZi1LAMWPJwfFSEfmTHF1Rge4rsRh8JRf5WEfn1gbzD6kyFf1wfGyixmWaMQaGE1YkERtw772qA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6178 Archived-At: Subject: Re: [Hipsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-hip-native-nat-traversal-30=3A_=28with_COMMENT=29?= X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 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, 22 Mar 2020 17:25:37 -0000 SGkgTWlyamEsDQoNCmtlLCAyMDIwLTAyLTI2IGtlbGxvIDA5OjExIC0wODAwLCBNaXJqYSBLw7xo bGV3aW5kIHZpYSBEYXRhdHJhY2tlcg0Ka2lyam9pdHRpOg0KPiBNaXJqYSBLw7xobGV3aW5kIGhh cyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRm LWhpcC1uYXRpdmUtbmF0LXRyYXZlcnNhbC0zMDogTm8gT2JqZWN0aW9uDQo+IA0KPiBXaGVuIHJl c3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0 byBhbGwNCj4gZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMu IChGZWVsIGZyZWUgdG8gY3V0DQo+IHRoaXMNCj4gaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93 ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIA0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5mb3Jt YXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0K PiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJl IGZvdW5kIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtaGlwLW5hdGl2ZS1uYXQtdHJhdmVyc2FsLw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ IC0tLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tLQ0KPiANCj4gVGhhbmtzIGZvciBh ZGRyZXNzaW5nIG15IGRpc2N1c3MgcG9pbnRzIGFuZCBtb3N0IG9mIG15IG90aGVyDQo+IGNvbW1l bnRzLiBJDQo+IGJlbGlldmUgdGhlIGZvbGxvd2luZyBjb21tZW50cyBmcm9tIG15IHByZXZpb3Vz IGJhbGxvdCBhcmUgc3RpbGwNCj4gdmFsaWQ6DQo+IA0KPiBJIGFncmVlIHdpdGggb3RoZXIgQURz IHRoYXQgaXQgaXMgbm90IGNsZWFyIHRvIG1lIHdoeSB0aGlzIG1lY2hhbmlzbQ0KPiBpcyBuZWVk ZWQNCj4gaW4gYWRkaXRpb24gUkZDNTc3MC4gVGhpcyBpcyBhIHVzZSBjYXNlIGZvciBJQ0UgYW5k IEkgd291bGQgdGhpbmsNCj4gdGhhdCByZS11c2luZw0KPiBleGlzdGluZyBjb2RlIGFuZCBsaWJy YXJ5IHdvdWxkIG1ha2UgaW1wbGVtZW50YXRpb24gZWFzaWVyLCBmYXN0ZXINCj4gYW5kIGxlc3MN Cj4gZXJyb3ItcHJvbmUuIEkgZXNwZWNpYWxseSBhZ3JlZSB0byB0aGUgY29tbWVudHMgZnJvbSBB ZGFtIQ0KDQpJIGhhdmUgYXJndW1lbnRlZCB0aGlzIGluIGVhcmxpZXIgZGlzY3Vzc2lvbnMsIHNv IEkgd29uJ3QgcmVwZWF0IGl0DQpoZXJlLiBBZGFtIGNoYW5nZWQgaGlzIGJhbGxvdCB0byAiTm8g b2JqZWN0aW9uIi4NCg0KPiBPdGhlciBjb21tZW50czoNCj4gDQo+IDQpIHNlYyA0Ljg6ICJXaGVu IGEgaG9zdCBkb2VzIG5vdCByZWNlaXZlDQo+ICAgIGFja25vd2xlZGdtZW50cywgZS5nLiwgdG8g YW4gVVBEQVRFIG9yIENMT1NFIHBhY2tldCBhZnRlciBhDQo+IHRpbWVvdXQNCj4gICAgYmFzZWQg b24gbG9jYWwgcG9saWNpZXMsIGEgaG9zdCBTSE9VTEQgcmVzZW5kIHRoZSBwYWNrZXQgdGhyb3Vn aA0KPiB0aGUNCj4gICAgYXNzb2NpYXRlZCBEYXRhIFJlbGF5IFNlcnZlciBvZiB0aGUgcGVlciAo aWYgdGhlIHBlZXIgbGlzdGVkIGl0IGluDQo+ICAgIGl0cyBMT0NBVE9SX1NFVCBwYXJhbWV0ZXIg aW4gdGhlIGJhc2UgZXhjaGFuZ2UuIg0KPiBJIGRpZCBub3QgcmVhbGx5IGZpbmQgYW55dGhpbmcg YWJvdXQgdGhpcyBpbiBzZWN0aW9uIDUuMTAgb2YgUkZDNTc3MC4NCj4gSW4gdGhpbmsNCj4gdGhl IHRpbWVvdXQgbmVlZHMgdG8gYmUgZnVydGhlciBzcGVjaWZpZWQuDQoNCnRoZSB0aW1lb3V0IG1l Y2hhbmlzbXMgYXJlIHNwZWNpZmllZCBpbiB0aGUgUkZDNzQwMSBzdGF0ZSBtYWNoaW5lDQpzcGVj aWZpY2F0aW9uLCBzbyBJIGFkZGVkIGEgcmVmZXJlbmNlIHRoZXJlIGluc3RlYWQgb2YgcmVwZWF0 aW5nIGl0DQpoZXJlOg0KICAgQS4gDQogICBXaGVuIGEgaG9zdCBkb2VzIG5vdCByZWNlaXZlIGFj a25vd2xlZGdtZW50cywgZS5nLiwgdG8gYW4gVVBEQVRFIG9yDQogICBDTE9TRSBwYWNrZXQgYWZ0 ZXIgYSB0aW1lb3V0IGJhc2VkIG9uIGxvY2FsIHBvbGljaWVzLCBhIGhvc3QgU0hPVUxEDQogICBy ZXNlbmQgdGhlIHBhY2tldCB0aHJvdWdoIHRoZSBhc3NvY2lhdGVkIERhdGEgUmVsYXkgU2VydmVy IG9mIHRoZSANCiAgIHBlZXIgKGlmIHRoZSBwZWVyIGxpc3RlZCBpdCBpbiBpdHMgTE9DQVRPUl9T RVQgcGFyYW1ldGVyIGluIHRoZSBiYXNlDQogICBleGNoYW5nZSAqYWNjb3JkaW5nIHRoZSBydWxl cyBzcGVjaWZpZWQgaW4gc2VjdGlvbiA0LjQuMiBpbg0KICAgW1JGQzc0MDFdKi4NCg0K