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

[Robert Moskowitz <[e-mail]>]

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.
>
> From my point of view, this document is ready to proceed.
>
> BR
> René
>
> 2016-10-21 9:13 GMT+02:00 Gonzalo Camarillo 
> <[e-mail] <mailto:[e-mail]>>:
>
>     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
>     <[e-mail] <mailto:[e-mail]>
>     >> <mailto:[e-mail]
>     <mailto:[e-mail]>>> 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
>     >>         <[e-mail]
>     <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>     >>         <mailto:[e-mail]
>     <mailto:[e-mail]>
>     >>         <mailto:[e-mail]
>     <mailto:[e-mail]>>>> 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
>     >> [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>     >> https://www.ietf.org/mailman/listinfo/hipsec
>     <https://www.ietf.org/mailman/listinfo/hipsec>
>     >>     <https://www.ietf.org/mailman/listinfo/hipsec
>     <https://www.ietf.org/mailman/listinfo/hipsec>>
>     >>
>     >>
>     >
>
>     _______________________________________________
>     Hipsec mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/hipsec
>     <https://www.ietf.org/mailman/listinfo/hipsec>
>
>
>
>
> _______________________________________________
> Hipsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hipsec