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

From: René Hummen <[email-masked]>
Date: Wed, 1 Jun 2016 14:08:41 +0200

This is part 2. More to come...

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

[...]

> > 5.2.1.  DH_GROUP_LIST
> >
> > The DH_GROUP_LIST parameter contains the list of supported DH Group
> > IDs of a host.  It is defined in Section 5.2.6 of [RFC7401].  With
> > HIP DEX, the DH Group IDs are restricted to:
> >
> > Group                              KDF              Value
> >
> > NIST P-256 [RFC5903]               CKDF             7
> > NIST P-384 [RFC5903]               CKDF             8
> > NIST P-521 [RFC5903]               CKDF             9
> > SECP160R1  [SECG]                  CKDF             10
> > Curve25519 [RFC7748]               CKDF             11
> > Curve448   [RFC7748]               CKDF             12
> >
> > The ECDH groups 7 - 9 are defined in [RFC5903] and [RFC6090].  ECDH
> > group 10 is covered in [SECG] and Appendix D of [RFC7401].  These
> > curves, when used with HIP MUST have a co-factor of 1.
>
> I suggest to change the "value" column title to "group id" or change the
> text
> as follows: "The ECDH groups with *values* 7 - 9..."
>

Fixed according to your second suggestion.

> > The ECDH groups 11 and 12 are defined in [RFC7748].  These curves
> > have cofactors of 8 and 4 (respectively).
>
> Same comment as previously.
>

See above.

> 5.2.3.  HOST_ID
> >
> > The HOST_ID parameter conveys the Host Identity (HI) along with
> > optional information about a host.  It is defined in Section 5.2.9 of
> > [RFC7401].
> >
> > HIP DEX uses the public portion of a host's static ECDH key-pair as
> > the HI.  Correspondingly, HIP DEX limits the HI algorithms to the
> > following profile:
>
> I would add "*new* profile" since this is not part of RFC7401.
>

Done.

> 5.2.4.  HIT_SUITE_LIST
> >
> > The HIT_SUITE_LIST parameter contains a list of the supported HIT
> > suite IDs of the Responder.  Based on the HIT_SUITE_LIST, the
> > Initiator can determine which source HIT Suite IDs are supported by
> > the Responder.  The HIT_SUITE_LIST parameter is defined in
> > Section 5.2.10 of [RFC7401].
>
> > The following HIT Suite IDs are defined for HIP DEX, and the
> > relationship between the four-bit ID value used in the OGA ID field
> > and the eight-bit encoding within the HIT_SUITE_LIST ID field is
> > clarified:
>
> ...the following *new* HIT Suite IDs...
>
> ...is clarified: -> ...is defined as follows:
>

Added "new". However, I kept the "is clarified" bit as this is text
straight from RFC7401. I do not want to make the impression that we are
defining a new mapping here.

> > Note that the HIP DEX HIT Suite ID allows the peers to distinguish a
> > HIP DEX handshake from a HIPv2 handshake.  The Responder MUST respond
> > with a HIP DEX HIT suite ID when the HIT of the Initiator is a HIP
> > DEX HIT.
>
> The details are a bit unclear. Which packet are you talking about here?
>
> I mean the suite id is in R1 (and not in I1), so I guess you're referring
> that
> Responder must respond to I2 with an R2 that contains HIP DEX HITs?
>

I modified the first sentence as follows:
"Note that the HIP DEX HIT Suite ID in the OGA ID field allows the peers to
distinguish a HIP DEX handshake from a HIPv2 handshake."

I will also write up the resquested DEX/BEX interop section.

> > 5.2.5.  ENCRYPTED_KEY
> >
> > [...]
> >
> > The ENCRYPTED_KEY parameter encapsulates a random value that is later
> > used in the session key creation process (see Section 6.3).  This
> > random value MUST have a length of at least 64 bit.  The puzzle value
> > #I and the puzzle solution #J (see [RFC7401]) are used as the
> > initialization vector (IV) for the encryption process.  To this end,
> > the IV is computed as FOLD(I | J, 128).  The AES-CTR counter is a 16
> > bit value that is initialized to zero with the first use.
>
> The initialization vector is a explicit, separate field in RFC7401. Why I
> and J
> are implicitly reused here? To save bits?
>

Yes, this is to save bits.

> The AES-CTR counter pops out a bit suddenly here. Perhaps you could
> "bridge" it to the text in a bit more smoother way.
>

I changed the text as follows:
"Moreover, a 16 bit counter value, which is initialized to zero on first
use, is appended to the IV value in order to guarantee that a non-repeating
nonce is fed to the encryption algorithm defined by the HIP_CIPHER."

> > Once this encryption process is completed, the "encrypted value" data
> > field is ready for inclusion in the Parameter.  If necessary,
> > additional Padding for 8-byte alignment is then added according to
> > the rules of TLV Format in [RFC7401].
>
> The key could be also included in ENCRYPTED parameter, which can
> accommodate multiple parameters... unless it is very important to
> keep the IV implicit.
>

Bob and I discussed about this as well, but felt that the bytes saved on
the wire would outweigh the cost of supporting an additional parameter.

> > 5.3.  HIP Packets
> >
> > [...]
> >
> > In the future, an optional upper-layer payload MAY follow the HIP
> > header.  The Next Header field in the header indicates if there is
> > additional data following the HIP header.
>
> RFC6078 is also future work.
>

See my comment about the need for signatures in my previous email.

> > 5.3.1.  I1 - the HIP Initiator Packet
> >
> > [...]
> >
> > As a compression of the employed HIs, the Initiator's and the
> > Responder's HITs both determine the DH group ID that must be used in
> > order to successfully conclude the triggered handshake.  HITs,
> > however, only include the OGA ID identifying a HIP DEX HIT.  They do
> > not include information about the specific DH group ID of the
> > corresponding HI. [...]
>
> Something wrong here, the first sentence is contradicting with the
> second and third one.
>

This clearly was unclear. I made another attempt at this as follows:
"As the Initiator's and the Responder's HITs are compressions of the
           employed HIs, they determine the DH Group ID that must be used in
           order to successfully conclude the triggered handshake. HITs,
           however, only include the OGA ID identifying the HI algorithm.
They
           do not include information about the specific group ID of the
HI."

> > 5.3.2.  R1 - the HIP Responder Packet
> >
> > [...]
> >
> > The R1 packet generation counter is used to determine the currently
> > valid generation of puzzles.  The value is increased periodically,
> > and it is RECOMMENDED that it is increased at least as often as
> > solutions to old puzzles are no longer accepted.
>
> Section 6.1 describes: "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.
>
> I guess R1 packet generation counters are still meaningful for the
> Initiator (despite Responder does not pre-generate R1s)?
>

Section 6.1 does not mandate not to use pre-computation. For this reason,
we did not remove it here. Moreover, it is an optional parameter, so we did
not want to prevent its use per se.

> > [...]
> >
> > The HOST_ID parameter depends on the received DH_GROUP_LIST parameter
> > and the Responder HIT in the I1 packet.  Specifically, if the I1
> > contains a Responder HIT, the Responder verifies that this HIT
> > matches the required DH group based on the received DH_GROUP_LIST
> > parameter.
>
> "...included in the I1". Right?
>

Added.

> 5.3.3.  I2 - the Second HIP Initiator Packet
> >
> > [...]
> >
> > The HIP_CIPHER contains the single encryption transform selected by
> > the Initiator that it uses to encrypt the ENCRYPTED and ENCRYPTED_KEY
> > parameters.  The chosen cipher MUST correspond to one of the ciphers
> > offered by the Responder in the R1.  All implementations MUST support
> > the AES-CTR transform [RFC3686].
> >
> > [...]
> >
> > The TRANSPORT_FORMAT_LIST parameter contains the single transport
> > format type selected by the Initiator.  The chosen type MUST
> > correspond to one of the types offered by the Responder in the R1
> > packet.  Currently, the only transport format defined is the ESP
> > transport format [RFC7402].
>
> Should all of the cipher suites and transport formats still be echoed
> to the Responder for security reasons? See also my next comment.
>
> > 5.3.4.  R2 - the Second HIP Responder Packet
> >
> > [...]
> >
> > The Responder repeats the DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST,
> > and TRANSPORT_FORMAT_LIST parameters in the R2 packet.  These
> > parameters MUST be the same as included in the R1 packet. The
> > parameter are re-included here because the R2 packet is MACed and
> > thus cannot be altered by an attacker.  For verification purposes,
> > the Initiator re-evaluates the selected suites and compares the
> > results against the chosen ones.  If the re-evaluated suites do not
> > match the chosen ones, the Initiator acts based on its local policy.
>
> Ok, so now the full list of parameters is included, so forget about my
> previous comment.
>

Done :)

---

From: René Hummen <[email-masked]>
Date: Fri, 3 Jun 2016 13:20:01 +0200

This is part 3 of 3.

On Mon, Mar 28, 2016 at 10:05 PM, Miika Komu <[email-masked]>
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é

---

From: René Hummen <[email-masked]>
Date: Fri, 3 Jun 2016 13:26:50 +0200

Hi Miika,

2016-05-20 11:48 GMT+02:00 Miika Komu <[email-masked]>:

> Hi,
>
> On 05/16/2016 06:50 PM, René Hummen wrote:
>
>> Hi Miika, all,
>>
>> thanks for reviewing the draft!
>>
>
> my pleasure. I am ok with your changes, just a small note below.
>
>      > 2.1.  Requirements Terminology
>>
>>     In section 6.3, you are introduce also -> notation, which was
>>     not explained.
>>
>>
>> I didn't think an explanation of this formal notation was necessary as
>> it is also not further described, e.g., in RFC5869. What would you like
>> me to write here?
>>
>
> I should probably read RFC5869 before I can understand how to implement
> the key derivation for DEX. It was a bit difficult to follow what is the
> input and especially what is the resulting output.
>
> The reference for RFC5869 is missing?
>

 I added the reference during my revision.

BR
René

---

From: Miika Komu <[email-masked]>
Date: Tue, 7 Jun 2016 15:54:02 +0300

Hi Rene,

> This is part 2. More to come...

I am fine with your fixes for part 2.

---

From: Miika Komu <[email-masked]>
Date: Tue, 7 Jun 2016 16:11:57 +0300

Hi,

> 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]>> wrote:
 > [...]
>      > 6.2.1.  CMAC Calculation
>      >
>      > [...]
>      >
>      >
> RFC7401. Step 2 already hints at the fact that parameters following
> HIP_MAC may still be of interest:

Latter option works for me too.

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

>     The Expand was a bit more clear, but still didn't understand how to
>     get to the
> 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.

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

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

> I can make these changes if you insist, but I was going for a minimal
> diff to RFC 7401.

Not insisting.

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

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

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

>        identify a peer in an ACL.  Instead, the use of the peer's HI is

Ok.

> HIPv2" to satisfy your comment on HIP DEX and HIPv2 compatibility.

Thanks!