Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt
Miika Komu <miika.komu@ericsson.com> Tue, 07 June 2016 13:12 UTC
Return-Path: <miika.komu@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 ED7F712D61F for <hipsec@ietfa.amsl.com>; Tue, 7 Jun 2016 06:12:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.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] 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 emhwby2gEZJd for <hipsec@ietfa.amsl.com>; Tue, 7 Jun 2016 06:12:00 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A2AB12D61B for <hipsec@ietf.org>; Tue, 7 Jun 2016 06:12:00 -0700 (PDT)
X-AuditID: c1b4fb25-f79f26d00000327e-e2-5756c81e42d3
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 8D.BC.12926.E18C6575; Tue, 7 Jun 2016 15:11:58 +0200 (CEST)
Received: from [131.160.51.22] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.294.0; Tue, 7 Jun 2016 15:11:57 +0200
References: <20160321203627.12199.62928.idtracker@ietfa.amsl.com> <56F98E90.10601@ericsson.com> <CAEhFMcjosQF6CPa5cRWo6gtWHWyNFGR5PC4BxTLvZxCaXohckg@mail.gmail.com>
To: hipsec@ietf.org
From: Miika Komu <miika.komu@ericsson.com>
Organization: Ericsson AB
Message-ID: <5756C81D.3080601@ericsson.com>
Date: Tue, 07 Jun 2016 16:11:57 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <CAEhFMcjosQF6CPa5cRWo6gtWHWyNFGR5PC4BxTLvZxCaXohckg@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms020208070200020400060804"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM2K7ja7cibBwg5dNyhZTF01mdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvEbpxkL7pdUtL2Ib2BcmdDFyMkhIWAicXfdHkYIW0ziwr31 bF2MXBxCAkcYJQ78ecUK4axilFjyfiUbSJWwgLXE1A832SESKxglph/7zwSSEBEQlZjy4TQz iM0moCWx6s51MJtfQFJiQ8NuMJtXQFvicdtusHUsAioSayacBRsqKhAhMWv7DyaIGkGJkzOf sIDYnAKBEgeXr2IBWcYs0M0ose7KISCHA2izisTFY8ETGAVmIWmZhawMJMEsYCYxb/NDZghb W2LZwtdQtrXEjF8H2SBsRYkp3Q/ZIWxTiddHPzJC2MYSy9b9ZVvAyLGKUbQ4tTgpN93IWC+1 KDO5uDg/Ty8vtWQTIzD8D275rbqD8fIbx0OMAhyMSjy8C7TCwoVYE8uKK3MPMaoAzXm0YfUF RimWvPy8VCURXu8DQGnelMTKqtSi/Pii0pzU4kOM0hwsSuK8/i8Vw4UE0hNLUrNTUwtSi2Cy TBycUg2MkTKSxiKXvaf9K3v9d0bUG6d91hZLLpXeuX5S3uZq7jyFnbzZWVUmwfdO6jTNPWZ7 y/ZJo1yIflPey61Obw5wrbrye694uVlE1ElH1YPzrEsqWy8y7TmX8VNKMeHIy9osYeHQ0vmn M+pD69ZsbbvpF/nySvvFuT2dq/2kVn5sfyS8RVnRk/GvEktxRqKhFnNRcSIAKLTTUIcCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/D4Skh3AJOL-v__TqkLEYf_6wB9Y>
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: Tue, 07 Jun 2016 13:12:03 -0000
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] I-D Action: draft-ietf-hip-dex-02.txt internet-drafts
- Re: [Hipsec] I-D Action: draft-ietf-hip-dex-02.txt Robert Moskowitz
- [Hipsec] A review of draft-ietf-hip-dex-02.txt Miika Komu
- Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt Gonzalo Camarillo
- Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt Gonzalo Camarillo
- Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt René Hummen
- Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt Miika Komu
- Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt René Hummen
- Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt René Hummen
- Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt René Hummen
- Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt Miika Komu
- Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt Miika Komu
- Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt Gonzalo Camarillo
- Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt René Hummen
- Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt Robert Moskowitz
- Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt Miika Komu
- Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt Gonzalo Camarillo
- Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt René Hummen
- Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt Robert Moskowitz