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

[René Hummen <[e-mail]>]

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?

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?

BR
René



On Tue, Jun 7, 2016 at 3:11 PM, Miika Komu <[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]>> 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]
> https://www.ietf.org/mailman/listinfo/hipsec
>
>