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

[Robert Moskowitz <[e-mail]>]

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