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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 04 Mar 2020 10:28:05 -0800

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: Robert Moskowitz <[email-masked]>
Date: Fri, 6 Mar 2020 09:21:07 -0500

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

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

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

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

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

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

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

> string?  Is it ASCII, as in 067 075 068 070 045 069 120 116 114 097 099 116?

Will check this too.

> language already stated in Section 5.2.2 on the topic).

Good point.  Will do.

> processing section (i.e., in Section 6.*) on when this should be done.

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

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

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

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

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

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

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

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

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

> source HIT in the _R1_ packet …”?

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

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

> underspecified.  Could the text at least provide a recommendation of aborting

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.

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

> -- Section 1.2.  The sentence “Also, it is often the case that HIP DEX …” is

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

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

fixed.

> The HIP DEX KEYMAT process is based on the/

fixed.

> with the use of static keys by HIP-DEX”.

thanks.  Yes, I have added "with"

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 13 Mar 2020 13:45:06 -0400

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:
>> Please refer tohttps://www.ietf.org/iesg/statement/discuss-criteria.html
> And I should point out it gives more security that has been provided 
> in these classes of devices in the past.
>
>> OLD
> 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.
>

See sec 7.1

> and if I am missed it, I will update the IANA section.

Done.  I think.

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

> 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.
>
> A case of lifting text from 7401 where it needs to be adjusted a bit.  
> I will make the change.
>
> 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.
>
> 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.
>
> 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.
>
> 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
> Thanks.   Fixed.  I kept the 2nd one as the separate para.  Reads 
> better in my opinion.
>

-- 
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: Tue, 17 Mar 2020 09:11:24 -0400

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.

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

>> string?  Is it ASCII, as in 067 075 068 070 045 069 120 116 114 097 099 116?

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

>> language already stated in Section 5.2.2 on the topic).

Done.  See sec 9.3

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

Done. Sec 6.7 step 4 and 6.8 step 5.

> years later deployment teaches us things about what SHOULD and what MUST.

I have pulled this para.

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

> willing to, but I should ask on the HIPSEC list and see what private 

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

> A case of lifting text from 7401 where it needs to be adjusted a bit.  

Change made.

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

> constrained devices?  I would be happy to include copied text or a 

Additional text has been added.

---

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

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:
> 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...
>
>>
>> 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.
>
>>
>> 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.
>
>> A case of lifting text from 7401 where it needs to be adjusted a 
>> bit.  I will make the change.
>
> Change made.
>
>>
>> "If you are going to try and optimize this protocol, remember all 
>> that you have to include" kind of thing.
>>
>> 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.
>>