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

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Wed, 31 August 2016 12:22 UTC

Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E42112D1B1 for <hipsec@ietfa.amsl.com>; Wed, 31 Aug 2016 05:22:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.221
X-Spam-Level:
X-Spam-Status: No, score=-104.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5m89SsYt3wCu for <hipsec@ietfa.amsl.com>; Wed, 31 Aug 2016 05:22:02 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D375312DB07 for <hipsec@ietf.org>; Wed, 31 Aug 2016 05:21:52 -0700 (PDT)
X-AuditID: c1b4fb25-8d3fb70000001071-73-57c6cbde7ecc
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id D5.EC.04209.EDBC6C75; Wed, 31 Aug 2016 14:21:50 +0200 (CEST)
Received: from [131.160.126.239] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.301.0; Wed, 31 Aug 2016 14:21:49 +0200
To: =?UTF-8?Q?Ren=c3=a9_Hummen?= <hummen.committees@gmail.com>
References: <20160321203627.12199.62928.idtracker@ietfa.amsl.com> <56F98E90.10601@ericsson.com> <CAEhFMcjosQF6CPa5cRWo6gtWHWyNFGR5PC4BxTLvZxCaXohckg@mail.gmail.com> <5756C81D.3080601@ericsson.com>
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Message-ID: <f46c9273-568a-8233-5fcf-5cbefe460512@ericsson.com>
Date: Wed, 31 Aug 2016 15:21:49 +0300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <5756C81D.3080601@ericsson.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM2K7lu6908fCDSY8tbCYumgys8W7o99Z HJg8ds66y+6xZMlPpgCmKC6blNSczLLUIn27BK6MZSs72Ap2eVa8nNbF1sDYYdbFyMkhIWAi MftgF3sXIxeHkMB6RokjT5ZBOWsZJZr+3GcDqRIWsJaY+uEmO4gtImAnseTIQ1aIolOMEkdP XwFLMAMVvV57mQXEZhOwkNhy6z6YzStgL/F3YSfYIBYBVYm5C/sYuxg5OEQFYiTW9yVAlAhK nJz5BKycU0BH4snC7UwQIw0kjiyawwphy0s0b53NDGILCWhLLH/WwjKBUWAWkvZZSFpmIWlZ wMi8ilG0OLU4KTfdyFgvtSgzubg4P08vL7VkEyMwMA9u+a26g/HyG8dDjAIcjEo8vAtOHg0X Yk0sK67MPcQowcGsJMJrBAxrId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rz+LxXDhQTSE0tSs1NT C1KLYLJMHJxSDYySU3WfVN2KVz27rPXrAaOtM5fVHCj54NHRsKYyf+mPgqUzf/fNfrvD5vey /rfF+vMfLl4Qx+f7M3Wi275/Z58IHWR6cUXEQ+1TVm5hp5VJ7slTRVcufLgZYuurfMNBaDGn 3qHeS+4ttsKHGcyN5T8+teZeVWMmcWb9HPH3pwxPn6y+an3vqHGJEktxRqKhFnNRcSIAcJM5 gkgCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/mfsAg_mSElMVEvSwFbTuSsCFvQw>
Cc: hipsec@ietf.org
Subject: Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Aug 2016 12:22:14 -0000

Hi Rene,

please, note Miika's email below, which includes a couple of suggestions
about the draft.

Cheers,

Gonzalo

On 07/06/2016 4:11 PM, Miika Komu 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 <miika.komu@ericsson.com
>> <mailto:miika.komu@ericsson.com>> 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
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec
>