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

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Fri, 21 October 2016 07:13 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 24A04129516 for <hipsec@ietfa.amsl.com>; Fri, 21 Oct 2016 00:13:11 -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 XS6b5Ispji4j for <hipsec@ietfa.amsl.com>; Fri, 21 Oct 2016 00:13:08 -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 DA29E129496 for <hipsec@ietf.org>; Fri, 21 Oct 2016 00:13:07 -0700 (PDT)
X-AuditID: c1b4fb25-5405a9800000793b-b0-5809c001b454
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id F8.14.31035.100C9085; Fri, 21 Oct 2016 09:13:06 +0200 (CEST)
Received: from [100.94.10.182] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.3.319.2; Fri, 21 Oct 2016 09:13:05 +0200
To: Miika Komu <miika.komu@ericsson.com>, René Hummen <hummen.rwth@gmail.com>
References: <20160321203627.12199.62928.idtracker@ietfa.amsl.com> <56F98E90.10601@ericsson.com> <CAEhFMcjosQF6CPa5cRWo6gtWHWyNFGR5PC4BxTLvZxCaXohckg@mail.gmail.com> <5756C81D.3080601@ericsson.com> <CAEhFMch1qp868EKLx8V9kxS0-qC-2Cp0C6w=Sct3YSesErzKFQ@mail.gmail.com> <1ade65d6-187e-20e0-fb9b-c3d5b73f42df@ericsson.com>
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Message-ID: <cc2d82b2-447c-3b16-5858-8cae5710b174@ericsson.com>
Date: Fri, 21 Oct 2016 10:13:04 +0300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <1ade65d6-187e-20e0-fb9b-c3d5b73f42df@ericsson.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUyM2J7oC7TAc4Ig+eT+SymLprMbLH43Dc2 ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSvjwN9dbAUHUisO7/jO3MB40rGLkZNDQsBE YlvDcXYQW0hgPaPEhW36XYxcQPZqRolll58zgySEBawlpn64CVYkIpAgsX3uJUaIouNMElfO fgYq4uBgFhCV2D6rCqSGTcBCYsut+ywgNq+AvcSGwzvBelkEVCX2H/4GFhcViJG4/uwRG0SN oMTJmU/A4pwCDhKXF35ghBipKbF+lz5ImFlAXqJ562xmiDu1JZY/a2GZwCgwC0n3LISOWUg6 FjAyr2IULU4tTspNNzLWSy3KTC4uzs/Ty0st2cQIDMmDW36r7mC8/MbxEKMAB6MSD++DN+wR QqyJZcWVuYcYJTiYlUR4b+3ijBDiTUmsrEotyo8vKs1JLT7EKM3BoiTOa7byfriQQHpiSWp2 ampBahFMlomDU6qBMT/1Yqmj0NXG+2xNfPuvruOV2XJAdAb7AqVX95JNtv3Yz3Ux38GO7dhn wb85x6KDm+NWtN+Unrpo+7zln52jW9pepxjdTz+bGXgrTMr+Pe+1w2e/v3xct+lJ+5HioC55 uaT/Fkmu96vOcRqlxv3L6Pg6q+8OY9ODT1euXuPKyomtFlEUbvJ/qcRSnJFoqMVcVJwIAEiK 2ntFAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/a1rS1RI3euQ5EF5Y6XMtjgI2mtk>
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: Fri, 21 Oct 2016 07:13:11 -0000

Hi Rene,

do you intend to release a new version of the draft with this addition?
What is the current status of the draft otherwise?

Thanks,

Gonzalo

On 26/09/2016 4:46 PM, Miika Komu wrote:
> Hi René,
> 
> On 09/11/2016 11:06 PM, René Hummen wrote:
>> Hello Miika,
>>
>> going through your email again, I saw a total of four suggestions.
>>
>> Three of them refer to imprecisions in the text of RFC 7401 (which I
>> copy/pasted for HIP DEX). There, I understood that consistency with RFC
>> 7401 has a higher priority than only fixing your comments for HIP DEX,
>> but keeping the text as is for RFC 7401. This means, I will not modify
>> the text in the HIP DEX draft. Is this also your intention?
> 
> yes, 7401 takes precedence over my comments.
> 
>> The last remaining issue is related to the UPDATE message and the
>> rekeying procedure (Section 6.10.). Here, I added the following
>> paragraph for clarification purposes:
>>
>>    [RFC7402] specifies the rekeying of an existing HIP SA using the
>>    UPDATE message.  This rekeying procedure can also be used with HIP
>>    DEX.  However, where rekeying involves a new Diffie-Hellman key
>>    exchange, HIP DEX peers MUST establish a new connection in order to
>>    create a new Pair-wise Key SA due to the use of static ECDH key-pairs
>>    with HIP DEX.
>>
>> Does this fix your issue?
> 
> Yes. I assume you mean a new HIP association with connection.
> 
>> BR
>> René
>>
>>
>>
>> On Tue, Jun 7, 2016 at 3:11 PM, Miika Komu <miika.komu@ericsson.com
>> <mailto:miika.komu@ericsson.com>> 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>
>>         <mailto: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 <mailto:Hipsec@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/hipsec
>>     <https://www.ietf.org/mailman/listinfo/hipsec>
>>
>>
>