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