Subject: Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 21 Oct 2016 10:13:04 +0300

Hi Rene,

do you intend to release a new version of the draft with this addition?
What is the current status of the draft otherwise?

Thanks,

Gonzalo

On 26/09/2016 4:46 PM, Miika Komu wrote:
> Hi René,
> 
> On 09/11/2016 11:06 PM, René Hummen wrote:
>> Hello Miika,
>>
>> going through your email again, I saw a total of four suggestions.
>>
>> Three of them refer to imprecisions in the text of RFC 7401 (which I
>> copy/pasted for HIP DEX). There, I understood that consistency with RFC
>> 7401 has a higher priority than only fixing your comments for HIP DEX,
>> but keeping the text as is for RFC 7401. This means, I will not modify
>> the text in the HIP DEX draft. Is this also your intention?
> 
> yes, 7401 takes precedence over my comments.
> 
>> The last remaining issue is related to the UPDATE message and the
>> rekeying procedure (Section 6.10.). Here, I added the following
>> paragraph for clarification purposes:
>>
>>    [RFC7402] specifies the rekeying of an existing HIP SA using the
>>    UPDATE message.  This rekeying procedure can also be used with HIP
>>    DEX.  However, where rekeying involves a new Diffie-Hellman key
>>    exchange, HIP DEX peers MUST establish a new connection in order to
>>    create a new Pair-wise Key SA due to the use of static ECDH key-pairs
>>    with HIP DEX.
>>
>> Does this fix your issue?
> 
> Yes. I assume you mean a new HIP association with connection.
> 
>> BR
>> René
>>
>>
>>
>> On Tue, Jun 7, 2016 at 3:11 PM, Miika Komu <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>     Hi,
>>
>>     On 06/03/2016 02:20 PM, René Hummen wrote:
>>
>>         This is part 3 of 3.
>>
>>
>>     I am fine with your fixes. Some comments below.
>>
>>         On Mon, Mar 28, 2016 at 10:05 PM, Miika Komu
>>         <[email-masked] <mailto:[email-masked]>
>>         <mailto:[email-masked]
>>         <mailto:[email-masked]>>> wrote:
>>
>>     > [...]
>>
>>              > 6.2.1.  CMAC Calculation
>>              >
>>              > [...]
>>              >
>>              >
>>              > 5.  Set Checksum and Header Length fields in the HIP
>>         header to
>>              > original values.  Note that the Checksum and Length fields
>>              > contain incorrect values after this step.
>>
>>             I guess also the values following HIP_MAC should be restored
>>         since
>>             they were wiped in the step 2.
>>
>>
>>         I also found this description a bit imprecise, but it is taken
>> from
>>         RFC7401. Step 2 already hints at the fact that parameters
>> following
>>         HIP_MAC may still be of interest:
>>         "Remove the HIP_MAC parameter, as well as all other parameters
>>                 that follow it with greater Type value, saving the
>>         contents if
>>                 they will be needed later."
>>
>>         The question is whether we want to fix the description for HIP
>>         DEX or to
>>         keep things as they are for consistency reasons. In the former
>>         case, I
>>         would prefer to completely rewrite the verification procedure to
>>         work on
>>         the received packet without removing any parameters. However, we
>>         should
>>         then probably also post an errata to RFC7401. If there are no
>> stong
>>         opinions about that, I would go for the latter option.
>>
>>
>>     Latter option works for me too.
>>
>>              > The CKDF-Extract function is the following operation:
>>              >
>>              > CKDF-Extract(I, IKM, info) -> PRK
>>
>>             What does the arrow operator signify? I thought that it
>>         produces PRK,
>>             but PRK is actually defined below.
>>
>>
>>         The arrow is part of a basic mathematical function definition.
>>         So yes,
>>         PRK is the output (domain), but we still need to give it a
>>         proper name.
>>         I changed the artwork to clearly point out the inputs and
>> outputs.
>>
>>
>>     Thanks, it is now better.
>>
>>         Please check this section again in the updated version and get
>>         back to
>>         me if the above changes do not sufficiently help your
>> understanding.
>>
>>
>>     It is good now, thanks!
>>
>>              > L        length of output keying material in octets
>>              >          (<= 255*RHASH_len/8)
>>              > |        denotes the concatenation
>>              >
>>              > The output keying material OKM is calculated as follows:
>>              >
>>              > N       =  ceil(L/RHASH_len/8)
>>              > T       =  T(1) | T(2) | T(3) | ... | T(N)
>>              > OKM     =  first L octets of T
>>              >
>>              > where
>>              >
>>              > T(0) = empty string (zero length)
>>              > T(1) = CMAC(PRK, T(0) | info | 0x01)
>>              > T(2) = CMAC(PRK, T(1) | info | 0x02)
>>              > T(3) = CMAC(PRK, T(2) | info | 0x03)
>>              > ...
>>
>>             The Expand was a bit more clear, but still didn't understand
>>         how to
>>             get to the
>>             Expanded key material due the arrow notation.
>>
>>
>>         Ok, let's clarify this as several comments are related to the
>> arrow
>>         notation. For the function definition we use the mathematical
>> arrow
>>         notation (same as RFC 5869) and for the actual opertation we
>> use the
>>         equals sign (same as RFC 5869). In the end, they denote the same
>>         thing:
>>         "assign X to Y".
>>
>>
>>     Ok, this is what I guessed too.
>>
>>              > (where the constant concatenated to the end of each
>> T(n) is a
>>              > single octet.)
>>
>>             Is there a max value?
>>
>>
>>         I am not sure what you mean here. If you refer to the N in T(N)
>>         then it
>>         is defined above as N = ceil(L/RHASH_len/8).
>>
>>
>>     Yes, I asked about the maximum value for N (which depends on L), but
>>     never mind.
>>
>>              > 8.   The R1 packet may have the A-bit set - in this case,
>>         the system
>>              > MAY choose to refuse it by dropping the R1 packet and
>>         returning
>>              > to state UNASSOCIATED.  The system SHOULD consider
>>         dropping the
>>              > R1 packet only if it used a NULL HIT in the I1 packet.
>>
>>             I didn't understand the logic in the last sentence.
>>
>>
>>         Someone must have had a reason for this recommendation, but that
>>         someone
>>         wasn't me. This is text from RFC7401. Any suggestions how to
>>         proceed?
>>
>>
>>     Fix similarly as the other RFC7401 issue in the beginning of this
>> email.
>>
>>              > 6.7.  Processing Incoming I2 Packets
>>              >
>>              > [...]
>>              >
>>              > 5.   If the system's state machine is in the I2-SENT
>>         state, the
>>              > system MUST make a comparison between its local and
>> sender's
>>              > HITs (similarly as in Section 6.3).  If the local HIT is
>>         smaller
>>              > than the sender's HIT, it should drop the I2 packet,
>> use the
>>              > peer Diffie-Hellman key, ENCRYPTED_KEY keying material
>>         and nonce
>>              > #I from the R1 packet received earlier, and get the local
>>              > Diffie-Hellman key, ENCRYPTED_KEY keying material, and
>>         nonce #J
>>              > from the I2 packet sent to the peer earlier. 
>> Otherwise, the
>>              > system should process the received I2 packet and drop any
>>              > previously derived Diffie-Hellman keying material Kij and
>>              > ENCRYPTED_KEY keying material it might have generated upon
>>              > sending the I2 packet previously.  The peer
>>         Diffie-Hellman key,
>>              > ENCRYPTED_KEY, and the nonce #J are taken from the just
>>         arrived
>>              > I2 packet.  The local Diffie-Hellman key, ENCRYPTED_KEY
>>         keying
>>              > material, and the nonce #I are the ones that were sent
>>         earlier
>>              > in the R1 packet.
>>
>>             Please replace "sender" with "peer" (or remote host) in this
>>         section
>>             for more symmetric terminology.
>>
>>             get -> obtain
>>
>>
>>         I can make these changes if you insist, but I was going for a
>>         minimal
>>         diff to RFC 7401.
>>
>>
>>     Not insisting.
>>
>>
>>              > 11.  The implementation SHOULD also verify that the
>>         Initiator's HIT
>>              > in the I2 packet corresponds to the Host Identity sent in
>>         the I2
>>              > packet.  (Note: some middleboxes may not be able to
>> make this
>>              > verification.)
>>
>>             Why SHOULD? Why not MUST? I think we're talking about
>>         end-hosts here
>>             anyway.
>>
>>
>>         It is defined this way in RFC 7401. Do you really want to
>> change the
>>         packet processing behavior for HIP DEX only?
>>
>>
>>     Fix similarly as the first RFC7401 issue in this email.
>>
>>              > 6.10.  Processing UPDATE, CLOSE, and CLOSE_ACK Packets
>>
>>              > UPDATE, CLOSE, and CLOSE_ACK packets are handled
>>         similarly in HIP DEX
>>              > as in HIP BEX (see Sections 6.11, 6.12, 6.14, and 6.15 of
>>         [RFC7401]).
>>              > The only difference is the that the HIP_SIGNATURE is
>>         never present
>>              > and, therefore, is not required to be processed by the
>>         receiving
>>              > party.
>>
>>             How does rekeying work with the extract and expand functions?
>>
>>
>>         Rekeying is not defined in this document, same as for RFC
>> 7401. That
>>         being said, the rekeying procedure with reuse of the KEYMAT
>> from RFC
>>         7402 directly translates to HIP DEX. For new KEYMAT, the peers
>>         need to
>>         establish a new connection due to the use of static DH keys.
>>
>>
>>     Maybe this should be explicitly stated in the draft.
>>
>>
>>
>>              > 7.  HIP Policies
>>
>>              > There are a number of variables that will influence the
>>         HIP exchanges
>>              > that each host must support.  All HIP DEX implementations
>>         SHOULD
>>              > provide for an ACL of Initiator's HI to Responder's HI.
>>         This ACL
>>              > SHOULD also include preferred transform and local
>> lifetimes.
>>              > Wildcards SHOULD also be supported for this ACL.
>>
>>             Why ACLs are mandatory?
>>
>>
>>         It is not a MUST and considering that HIP DEX is primarly
>>         targeted at
>>         things, there is the need to do basic device authorizations
>>         (based on
>>         their identities) without a human in the loop. Of course you are
>>         also
>>         allowed to use more suffisticated authorization mechanisms.
>>
>>
>>     Ok.
>>
>>             ACL -> ACL consisting of
>>
>>
>>         Changed to the following text that is closer to RFC 7401:
>>         "   All HIP DEX implementations SHOULD provide for an Access
>>         Control List
>>             (ACL), representing for which hosts they accept HIP diet
>>         exchanges,
>>             and the preferred transport format and local lifetimes.
>>         Wildcarding
>>             SHOULD be supported for such ACLs."
>>
>>              > 8.  Security Considerations
>>
>>              > o  The HIP DEX HIT generation may present new attack
>>         opportunities.
>>
>>             They cannot be used in ACLs. Maybe this could be mentioned.
>>         Can this
>>             be mitigated by always using full HIs?
>>
>>
>>         I changed the bullet-point as follows:
>>         "The HIP DEX HIT generation may present new attack opportunities.
>>                Hence, HIP DEX HITs should not be use as the only means to
>>                identify a peer in an ACL.  Instead, the use of the
>>         peer's HI is
>>                recommended."
>>
>>
>>     Ok.
>>
>>         Note that I added a new Section 8 "Interoperability between HIP
>>         DEX and
>>         HIPv2" to satisfy your comment on HIP DEX and HIPv2
>> compatibility.
>>
>>
>>     Thanks!
>>
>>
>>     _______________________________________________
>>     Hipsec mailing list
>>     [email-masked] <mailto:[email-masked]>
>>     https://www.ietf.org/mailman/listinfo/hipsec
>>     <https://www.ietf.org/mailman/listinfo/hipsec>
>>
>>
>

---

From: René Hummen <[email-masked]>
Date: Sat, 22 Oct 2016 10:22:32 +0200

Hi,

I just uploaded draft version 04, where I addressed Miika's comments as
discussed in the previous emails.

>From my point of view, this document is ready to proceed.

BR
René

2016-10-21 9:13 GMT+02:00 Gonzalo Camarillo <[email-masked]>
:

> [email-masked]

---

From: Robert Moskowitz <[email-masked]>
Date: Sat, 22 Oct 2016 21:22:31 -0400

I am in agreement with Rene that this version meets the comments here 
that do not add new features.  As much as I would like to add new 
things, like a PAKE process, I would do that as separate document(s).  
In fact that is what I am doing with drafts like my fast-mobility.

So please start last call on this draft.

Bob

On 10/22/2016 04:22 AM, René Hummen wrote:
> Hi,
>
> I just uploaded draft version 04, where I addressed Miika's comments 
> as discussed in the previous emails.
>
> 2016-10-21 9:13 GMT+02:00 Gonzalo Camarillo 
> <[email-masked] <mailto:[email-masked]>>:
>
>     Hi Rene,
>
>     >> On Tue, Jun 7, 2016 at 3:11 PM, Miika Komu
>     >>         <[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     <mailto:[email-masked]>
>     <mailto:[email-masked]>>>> wrote:
>     >>
>     >>     > [...]
>     >>
>     >>              > 6.2.1.  CMAC Calculation
>     >>              >
>     >>              > [...]
>     >>              >
>     >>              >
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     >>     <https://www.ietf.org/mailman/listinfo/hipsec
>     <https://www.ietf.org/mailman/listinfo/hipsec>>
>     >>
>     >>
>     >
>