Subject: [Hipsec] Benjamin Kaduk's Discuss on draft-ietf-hip-dex-13: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 04 Mar 2020 09:44:57 -0800

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: Robert Moskowitz <[email-masked]>
Date: Wed, 4 Mar 2020 12:56:42 -0500

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.

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[email-masked]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 9 Mar 2020 16:00:33 -0400

> https://datatracker.ietf.org/doc/draft-ietf-hip-dex/

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.

> 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.

> 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).

> did not see discussion of the security consequences of inadvertent

I will look at this and see what I can add.

> 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.

> 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.

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.

> 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.

> 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.

> I'm not sure what value is added by mentioning the possibility of data

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.

> functionality throughout the extent of the association, after the

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.

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

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.

> % 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.

> 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.

> overload it to also be AES-specific.

Do you recommend I just reference SP800-38B?

> 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..

> than itself or the peer identity could have generated that message.

I will think on this one.  See what verbiage helps.

> 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.

> 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.

> [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?

> [same thing re "typically"]

Same response.

> 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.

> host, e.g., the full HI" should allow for sufficient flexibility.

I will see how this changes with the ACL additions.

>     increase the overhead of packets.  Thus, it is not expected that

fixed.

> 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.

> 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).

> needs to provide, I think it's irresponsible to publish this document.

In the works.

>     can become the Initiator in future communications.

same response.

> 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.

> 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.

> 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.

> There are security considerations for serializing the HIP state to

Do you want text about this in the Securities Considerations?

And with this I am pushing out ver 13.

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 9 Mar 2020 16:04:38 -0400

> And with this I am pushing out ver 13.

Oops.  That is ver 14 coming out now before the submit deadline.

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 18 Mar 2020 11:50:57 -0400

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:
>> Please refer to 
>> https://www.ietf.org/iesg/statement/discuss-criteria.html
> 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.
>
> 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 
> I will be adding this per Roman's comments.  Most will be in the I2 
> and R2 processing.

Done.  See 7.1

> 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

> I will look at this and see what I can add.

See changes to 6.11 and last bullet point in Sec Considerations.

> 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.
>
>
> 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")...
>

It is too late in IETF usage to change.  We live with it.

> You want to see the "smoking gun" document on WEP design from Nov 
> '94?  I have it.
>
> 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.
>
> 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 
> 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
>>
> 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
>
> problem with this, in fact probably one of them supplied the text. But 
> I am open to change based on consensus.
>
>> Section 2.3
>>

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.

> 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.
>

    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.

> 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).

> 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).
>

sec 7.1

> 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.

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

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 20 Mar 2020 14:31:13 -0400

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:
>> Yes to the gateway situation.  Or the sensor has E2E DEX connection 
>> to the central server somewhere on the greater Internet.
>>
>> 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.
>>
>> of the opinion of leaving this as is.  But I can be convinced to add 
>> a drop connection.
>>
>> 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 
>> problem with this, in fact probably one of them supplied the text. 
>> But I am open to change based on consensus.
>>
>>> Section 2.3
>>>
>> 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..
>>
>> I got comments in early drafts of 5201-bis.  Put it in.  Take it 
>> out.  So for now, I leave it in.
>>
>> 14 (note I will be pushing out draft 13 today for the publish 
>> deadline for changes done so far).
>>