Summary: Has 2 DISCUSSes. Needs 7 more YES or NO OBJECTION positions to pass.
(initial ballot from the deferred telechat; updated per -22 and ongoing discussion) ** Section 6.3. Per the definition of IKM, when should these two different derivations be used? ** (discuss-discuss) 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?
(initial ballot from deferred telechat; updated per -22 and ongoing discussions) Thanks for addressing my COMMENTS on -13.
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.
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!
This document was deferred by Terry Manderson in May 2018. The authors have taken into account all COMMENTs from the 2018 ballot, changing several parts of the document based on those COMMENTs. The document went successfully through a new IETF last call and the authors have addressed all points raised during this Last Call (including the SECDIR review by Don Eastlake). Security AD have currently some DISCUSSs based on the May 2020 telechat (that was cancelled pending the fix to those DISCUSS). Authors have addressed all DISCUSS (and some COMMENTs) points raised during the IESG review in revision -21. So I am balloting the approval again in front of the 2019 IESG members. -éric
Thanks for addressing my DISCUSS.
Carrying my earlier (-06) ballot position forward... and then my -13 position forward again. I only reviewed the differences, and do not see any operational concerns.
I only re-reviewed the changes, however, I don't see any transport issues there.
Trusting the sponsoring AD. Skimmed for ART problems, none found.