[Hipsec] Barry Leiba's No Objection on draft-ietf-hip-native-nat-traversal-30: (with COMMENT)
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. ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
[Hipsec] Roman Danyliw's Discuss on draft-ietf-hip-dex-13: (with DISCUSS and COMMENT)
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
Re: [Hipsec] Suresh Krishnan's Discuss on draft-ietf-hip-dex-13: (with DISCUSS)
Hi Bob/Jeff, > On Mar 4, 2020, at 11:09 AM, Robert Moskowitz wrote: > > > > 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), I am happy with the Code being set to 0 for ICMPv6 and the Pointer being set as Jeff proposed above. Regards Suresh ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] Benjamin Kaduk's Discuss on draft-ietf-hip-dex-13: (with DISCUSS and COMMENT)
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),
Re: [Hipsec] Suresh Krishnan's Discuss on draft-ietf-hip-dex-13: (with DISCUSS)
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. ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] Suresh Krishnan's Discuss on draft-ietf-hip-dex-13: (with DISCUSS)
> > 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 ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] Suresh Krishnan's Discuss on draft-ietf-hip-dex-13: (with DISCUSS)
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:r...@labs.htt-consult.com There's no limit to what can be accomplished if it doesn't matter who gets the credit ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
