Subject: [Hipsec] Fwd: New Version Notification for draft-ietf-hip-dex-12.txt

From: Robert Moskowitz <[email-masked]>
Date: Mon, 10 Feb 2020 08:30:48 -0500

I believe this version answers all the IESG issues.

Please review, there are some important additions.

EKR had a number of security concerns.  Some I feel don't apply to HIP, 
like use an AEAD for HIP packet security.

But there are a number of added sections, particularly in Security 
Considerations that are worth the group's review that I have things 
stated properly.

Also there is a new parameter, I_NONCE to add Initiator randomness into 
the Master Key generation.  There is some cleanup in the KEYMAT section 
to reflect this.

So please take a read through.

Thank you

-------- Forwarded Message --------
Subject: 	New Version Notification for draft-ietf-hip-dex-12.txt
Date: 	Sun, 09 Feb 2020 23:11:55 -0800
From: 	[email-masked]
To: 	Robert Moskowitz <[email-masked]>, Rene Hummen 
<[email-masked]>, Miika Komu <[email-masked]>

A new version of I-D, draft-ietf-hip-dex-12.txt
has been successfully submitted by Miika Komu and posted to the
IETF repository.

Name: draft-ietf-hip-dex
Revision: 12
Title: HIP Diet EXchange (DEX)
Document date: 2020-02-09
Group: hip
Pages: 57
URL: https://www.ietf.org/internet-drafts/draft-ietf-hip-dex-12.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-hip-dex/
Htmlized: https://tools.ietf.org/html/draft-ietf-hip-dex-12
Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-hip-dex
Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-12

Abstract:
This document specifies the Host Identity Protocol Diet EXchange (HIP
DEX), a variant of the Host Identity Protocol Version 2 (HIPv2). The
HIP DEX protocol design aims at reducing the overhead of the employed
cryptographic primitives by omitting public-key signatures and hash
functions.

The HIP DEX protocol is primarily designed for computation or memory-
constrained sensor/actuator devices. Like HIPv2, it is expected to
be used together with a suitable security protocol such as the
Encapsulated Security Payload (ESP) for the protection of upper layer
protocol data. Unlike HIPv2, HIP DEX does not support Perfect
Forward Secrecy (PFS), and MUST only be used on devices where PFS is
prohibitively expensive. In addition, HIP DEX can also be used as a
keying mechanism for security primitives at the MAC layer, e.g., for
IEEE 802.15.4 networks.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Jeff Ahrenholz <[email-masked]>
Date: Wed, 12 Feb 2020 17:20:10 +0000

> EKR had a number of security concerns.  Some I feel don't apply to HIP, like use an AEAD for HIP packet security.
>
> But there are a number of added sections, particularly in Security Considerations that are worth the group's review that I have things stated properly.
>
> Also there is a new parameter, I_NONCE to add Initiator randomness into the Master Key generation.  There is some cleanup in the KEYMAT section to reflect this.
>

I took a look at the new I_NONCE parameter...

Regarding this statement (Section 5.2.6):
"The I_NONCE parameter encapsulates a random value that is later used in the Master key creation process (see Section 6.3)."

Looking at Section 6.3 HIP DEX KEYMAT Generation, it discusses using Diffie-Hellman derived key Kij, but I don't see anything about using I_NONCE. There is a random #I  provided by the Responder from the PUZZLE parameter, but nothing about a random I_NONCE supplied by the Initiator.

minor nits:
s/when key is smaller or equal to 128 bits/when the key is smaller or equal to 128 bits/
In Section 4.1.1 HIP Puzzle Mechanism, the links (HTML version) to RFC 7401 sections 4.1.1 and 4.1.2 do not link to RFC 7401 but to the dex draft.

-Jeff

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 12 Feb 2020 12:36:35 -0500

> Looking at Section 6.3 HIP DEX KEYMAT Generation, it discusses using Diffie-Hellman derived key Kij, but I don't see anything about using I_NONCE. There is a random #I  provided by the Responder fr…

In 6.3:

        IKM       Input keying material
                    the Diffie-Hellman derived key, concatenated with the
                      random I_NONCE value for the Master Key SA
                    the Diffie-Hellman derived key, concatenated with 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

> In Section 4.1.1 HIP Puzzle Mechanism, the links (HTML version) to RFC 7401 sections 4.1.1 and 4.1.2 do not link to RFC 7401 but to the dex draft.

I will look at this one again.

Back later on it.

---

From: Jeff Ahrenholz <[email-masked]>
Date: Wed, 12 Feb 2020 17:50:29 +0000

>> Looking at Section 6.3 HIP DEX KEYMAT Generation, it discusses
>> using Diffie-Hellman derived key Kij, but I don't see anything
>> about using I_NONCE. There is a random #I  provided by the
>> Responder from the PUZZLE parameter, but nothing about a
>> random I_NONCE supplied by the Initiator.
>    
>    In 6.3:
>    
    
Is this a new table row, or maybe something happened to the output?

It looks good.

In the dex-12 html/text versions I'm seeing the following text, which does not list IKM or info inputs for CKDF-Extract:

   The CKDF-Extract function is the following operation:

     CKDF-Extract(I, IKM, info) -> PRK

     Inputs:
       I         Random #I, provided by the Responder, from the PUZZLE
                 parameter

   The CKDF-Expand function is the following operation:

Moskowitz, et al.        Expires August 12, 2020               [Page 32]

Internet-Draft           HIP Diet EXchange (DEX)           February 2020

     CKDF-Expand(PRK, info, L) -> OKM

     Inputs:
       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)
       info      sort(HIT-I | HIT-R) | "CKDF-Expand"
                 where "CKDF-Expand" is an octet string
       L         length of output keying material in octets
                 (<= 255*RHASH_len/8)

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 12 Feb 2020 14:11:13 -0500

On 2/12/20 12:50 PM, Jeff Ahrenholz wrote:
>>                           for the Pair-wise Key SA   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.
>>
>> Moskowitz, et al.        Expires August 15, 2020               [Page 32]
>> 
>>         info      sort(HIT-I | HIT-R) | "CKDF-Extract"
>>                   where "CKDF-Extract" is an octet string
>>
>>       Output:
>>         PRK       a pseudorandom key (of RHASH_len/8 octets)
>>
>>
>>     The pseudorandom key PRK is calculated as follows:
>>
>>         PRK     = CMAC(I, IKM | info)
>>
>> Moskowitz, et al.        Expires August 15, 2020               [Page 33]
>> 
>>       Output:
>>         OKM        output keying material (of L octets)
>>
>>     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)
>>         ...
>>
>      

Look at it in the draft, it does not format so well in a message.

>         L         length of output keying material in octets

Oh, oh.  I checked https://www.ietf.org/id/draft-ietf-hip-dex-12.txt and 
you are right and it is wrong.

Miika?  Something went wrong from what I sent and what got posted. Here 
is what I have from running xml2rfc locally on the xml:

=============================================

    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.

Moskowitz, et al.        Expires August 15, 2020               [Page 32]


      Inputs:

        info      sort(HIT-I | HIT-R) | "CKDF-Extract"
                  where "CKDF-Extract" is an octet string

      Output:
        PRK       a pseudorandom key (of RHASH_len/8 octets)

    The pseudorandom key PRK is calculated as follows:

        PRK     = CMAC(I, IKM | info)

Moskowitz, et al.        Expires August 15, 2020               [Page 33]


      Inputs:

      Output:
        OKM        output keying material (of L octets)

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

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 13 Feb 2020 09:45:22 -0500

> Looking at Section 6.3 HIP DEX KEYMAT Generation, it discusses using Diffie-Hellman derived key Kij, but I don't see anything about using I_NONCE. There is a random #I  provided by the Responder fr…

The problem is the loss of text in sec 6.3, not sec 5.2.6.  We found the 
problem is a bug in the submission tool.  One way or another we will get 
the complete text in sec 6.3 in the next draft.

> s/when key is smaller or equal to 128 bits/when the key is smaller or equal to 128 bits/

Fixed, thanks.

> In Section 4.1.1 HIP Puzzle Mechanism, the links (HTML version) to RFC 7401 sections 4.1.1 and 4.1.2 do not link to RFC 7401 but to the dex draft.

That is a submission tool bug.  I will work with the developers on it.

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 13 Feb 2020 10:56:10 -0500

> In Section 4.1.1 HIP Puzzle Mechanism, the links (HTML version) to RFC 7401 sections 4.1.1 and 4.1.2 do not link to RFC 7401 but to the dex draft.

This is the fault of the tool that takes the ID txt to generate the 
html.  Currently, this is NOT done from the xml, so changing the xml 
will not help.  Once approved for RFC, the RFC editor will make sure all 
html is right.  So we just have to live with this for now.  The problem 
is not ours and there are no reasonable changes we can make to the text 
to get the html right for the draft.

Humph.

---

From: Miika Komu <[email-masked]>
Date: Fri, 14 Feb 2020 14:38:09 +0000

Hi,

ke, 2020-02-12 kello 17:20 +0000, Jeff Ahrenholz kirjoitti:
> > EKR had a number of security concerns.  Some I feel don't apply to
> > HIP, like use an AEAD for HIP packet security.
> > 
> > Also there is a new parameter, I_NONCE to add Initiator randomness
> > into the Master Key generation.  There is some cleanup in the
> > KEYMAT section to reflect this.
> > 
> "The I_NONCE parameter encapsulates a random value that is later used
> in the Master key creation process (see Section 6.3)."
> 
> Looking at Section 6.3 HIP DEX KEYMAT Generation, it discusses using
> Diffie-Hellman derived key Kij, but I don't see anything about using
> I_NONCE. There is a random #I  provided by the Responder from the
> PUZZLE parameter, but nothing about a random I_NONCE supplied by the
> Initiator.

thanks for catching this! This occurred due to a html comment inside a
figure (xml2rfc team is working on a fix). Here is the fixed document:

https://tools.ietf.org/html/draft-ietf-hip-dex-13#section-6.3

> In Section 4.1.1 HIP Puzzle Mechanism, the links (HTML version) to
> RFC 7401 sections 4.1.1 and 4.1.2 do not link to RFC 7401 but to the
> dex draft.

apparently this has to be fixed manually in collaboration with the RFC
editor.