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

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 protected]
> <mailto:[email protected]>> 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 protected]
https://www.ietf.org/mailman/listinfo/hipsec