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

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

This is part 3 of 3.

On Mon, Mar 28, 2016 at 10:05 PM, Miika Komu <[e-mail]>
wrote:

>
> > 6.1.  Solving the Puzzle
> >
> > The procedures for solving and verifying a puzzle in HIP DEX are
> > strongly based on the corresponding procedures in HIPv2.  The only
> > exceptions are that HIP DEX does not use pre-computation of R1
> > packets and that RHASH is set to CMAC.  As a result, the pre-
> > computation step in in Section 6.3 of [RFC7401] is skipped in HIP
> > DEX.
>
> in in -> in
>

Fixed.


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


> > 6.3.  HIP DEX KEYMAT Generation
>
> (this section was a bit hard to understand)
>
> > The HIP DEX KEYMAT process is used to derive the keys for the Master
> > Key SA as well as for the Pair-wise Key SA.  The keys for the Master
> > Key SA are based from the Diffie-Hellman derived key, Kij, produced
>
> from -> on
>

Fixed.


> > The keys of the Pair-wise Key SA are not directly used in the HIP DEX
> > handshake. [...]
>
> used -> exposed in plaintext?
>

Rephrased as follows in order to clarify what is meant here:
"The keys derived for the Pair-wise Key SA are not used during the HIP
         DEX handshake. Instead, these keys are made available as payload
         protection keys (e.g., for IPsec)."

> Some payload protection mechanisms have their own
> > Key Derivation Function, and if so this mechanism SHOULD be used.
>
> this -> such
>

We refer to a specific KDF here, so keeping "this".


> > The HIP DEX KEYMAT process consists of two components, CKDF-Extract
> > and CKDF-Expand.  The Extract function compresses a non-uniformly
> > distributed key, as is the output of a Diffie-Hellman key derivation,
>
> as is -> such as
>

Fixed and added reference to RFC 5869 "HMAC-based Extract-and-Expand Key
Derivation Function" for clarification purposes.


> > The key derivation for the Master Key SA employs both the Extract and
> > Expand phases, whereas the Pair-wise Key SA MAY need both the Extract
> > and Expand phases if the key is longer than 128 bits.  Otherwise, it
> > only requires the Expand phase.
>
> Suggest:
>
> 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 key is smaller or equal to 128 bits, but otherwise requires
> also the Expand phase.
>

I adopted your suggestion. Thanks!


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


> > where
> >
> > I          Random #I from the PUZZLE parameter
> > IKM        Input keying material, i.e., either the Diffie-Hellman
> >            derived key or the concatenation of the random values
> >            of the ENCRYPTED_KEY parameters in the same order as
> >            the HITs with sort(HIT-I | HIT-R)
>
> So how to choose between the D-H key and ENCRYPTED_KEY? Use always the
> KEY if present, otherwise D-H?
>

True, this was unclear. I changed it as follows:
"       IKM       Input keying material, i.e., the Diffie-Hellman derived
                 key for the Master Key SA and the concatenation of 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"


>
> > info       sort(HIT-I | HIT-R) | "CKDF-Extract"
>
> Is "CKDF-Extract" an octet string?
>

Yes. Changed as follows:
"    info      sort(HIT-I | HIT-R) | "CKDF-Extract"
              where "CKDF-Extract" is an octet string"


>
> > PRK        a pseudorandom key (of RHASH_len/8 octets)
> > |          denotes the concatenation
> >
> > The pseudorandom key PRK is calculated as follows:
> >
> > PRK     = CMAC(I, IKM | info)
>
> Based on this, I don't really know how to extract key material (the
> arrow notation is confusing).
>

Please check this section again in the updated version and get back to me
if the above changes do not sufficiently help your understanding.


> > The CKDF-Expand function is the following operation:
> >
> > CKDF-Expand(PRK, info, L) -> OKM
>
> What does the arrow mean?
>

See above.


> Maybe name "info" as "info2" because it is different variable.
>

Yes and it is in a different scope. I do not see the need to change this.


> > where
> >
> > PRK      a pseudorandom key of at least RHASH_len/8 octets
> >          (either the output from the extract step or the
> >          concatenation of the random values of the
> >          ENCRYPTED_KEY parameters in the same order as the
> >          HITs with sort(HIT-I | HIT-R))
>
> How to choose between the extract output vs encrypted key?
>

Changed as follows:
"       PRK       a pseudorandom key of at least RHASH_len/8 octets
                 (either the output from the extract step or the
                 concatenation of the random values of the
                 ENCRYPTED_KEY parameters in the same order as the
                 HITs with sort(HIT-I | HIT-R) in case of no extract)"


> Maybe you should rename this as "PRK2" in order to distinguish the
> variable from the Extract phase.
>

See above.


> > info     sort(HIT-I | HIT-R) | "CKDF-Expand"
>
> Is "CKDF-Expand" an octet string?
>

Fixed same as above.


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


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


> > The initial keys are drawn sequentially in the order that is
> > determined by the numeric comparison of the two HITs, with the
> > comparison method described in the previous paragraph.  HOST_g
> > denotes the host with the greater HIT value, and HOST_l the host with
> > the lower HIT value.
>
> This is just for Master keys, right?
>

Yes, I added this information in the text. The generation of the keying
material for payload security is defined in separate documents (e.g.
https://tools.ietf.org/html/rfc7402#section-7). HIP DEX only provides the
necessary mechanism.


> > The number of bits drawn for a given algorithm is the "natural" size
> > of the keys.  For the mandatory algorithms, the following sizes
> > apply:
> >
> > AES  128 or 256 bits
>
> I would clarify that this depends on the negotiated HIP_CIPHER.
>

Added in the text.


> > 6.5.  Processing Incoming I1 Packets
> >
> > 5.  If the received Responder's HIT in the I1 packet is not NULL, the
> > Responder's in the R1 packet HIT MUST match the destination HIT
>
> ...the Responder's HIT in the R1 packet MUST match...
>

Fixed.


> > 6.6.  Processing Incoming R1 Packets
> >
> > [...]
> >
> > 1.   A system receiving an R1 MUST first check to see if it has sent
> > an I1 packet to the originator of the R1 packet (i.e., it has a
> > HIP association that is in state I1-SENT and that is associated
> > with the HITs in the R1).  Unless the I1 packet was sent in
> > opportunistic mode (see Section 4.1.8 of [RFC7401]), the IP
> > addresses in the received R1 packet SHOULD be ignored by the R1
> > processing and, when looking up the right HIP association, the
>
> right -> correct
>

Changed.


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


> > Note that step 4 from the original processing rules of HIPv2
> > (signature verification) has been removed in the above processing
> > rules for HIP DEX.  Moreover, step 7 of the HIPv2 processing rules
> > has been adapted to account for the fact that HIP DEX uses ECDH
> > public keys as HIs.
>
> Step 7 in the *original* processing rules, what is the ordinal in DEX?
> It is not 7.
>

Fixed as follows:
"         Note that step 4 from the original processing rules of HIPv2
(signature
         verification) has been removed in the above processing rules for
HIP
         DEX. Moreover, step 7 of the original processing rules has been
adapted
         in step 6 avove to account for the fact that HIP DEX uses ECDH
public
         keys as HIs."


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


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


> > Note that steps 11 (encrypted HOST_ID) and 15 (signature
> > verification) from the original processing rules of HIPv2 have been
> > removed in the above processing rules for HIP DEX.  Moreover, step 10
> > of the HIPv2 processing rules has been adapted to account for
> > optional extension of the retransmission mechanism.  Step 16 has been
> > added to the processing rules.
>
> ...in this document.
>

Added.


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


> > 6.11.  Handling State Loss
>
> > Implementors MAY choose to use non-volatile, secure storage for HIP
> > states in order for them to survive a system reboot.  If no secure
> > storage capabilities are available, the system SHOULD delete the
> > corresponding HIP state, including the keying material.  If the
> > implementation does drop the state (as RECOMMENDED), it MUST also
> > drop the peer's R1 generation counter value, unless a local policy
> > explicitly defines that the value of that particular host is stored.
> > An implementation MUST NOT store a peer's R1 generation counters by
> > default, but storing R1 generation counter values, if done, MUST be
> > configured by explicit HITs.
>
> MUST NOT -> SHOULD? Otherwise the part after this is kinda void.
>

I changed the last sentence as follows:
"Such storing of the R1 generation counter values MUST be configured by
explicit HITs."


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


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


Note that I added a new Section 8 "Interoperability between HIP DEX and
HIPv2" to satisfy your comment on HIP DEX and HIPv2 compatibility.

BR
René