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

Miika Komu <miika.komu@ericsson.com> Mon, 26 September 2016 13:46 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 D87DD12B26C for <hipsec@ietfa.amsl.com>; Mon, 26 Sep 2016 06:46:56 -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 RYUNmovz5ZT7 for <hipsec@ietfa.amsl.com>; Mon, 26 Sep 2016 06:46:43 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 AF82512B239 for <hipsec@ietf.org>; Mon, 26 Sep 2016 06:46:42 -0700 (PDT)
X-AuditID: c1b4fb3a-ab7ff7000000099a-05-57e926bfdcc4
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id 88.98.02458.FB629E75; Mon, 26 Sep 2016 15:46:40 +0200 (CEST)
Received: from [131.160.51.22] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.301.0; Mon, 26 Sep 2016 15:46:37 +0200
To: =?UTF-8?Q?Ren=c3=a9_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>
From: Miika Komu <miika.komu@ericsson.com>
Organization: Ericsson AB
Message-ID: <1ade65d6-187e-20e0-fb9b-c3d5b73f42df@ericsson.com>
Date: Mon, 26 Sep 2016 16:46:38 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <CAEhFMch1qp868EKLx8V9kxS0-qC-2Cp0C6w=Sct3YSesErzKFQ@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060407030206030908000109"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyM2K7q+4BtZfhBpduSVlMXTSZ2WLxuW9s DkweO2fdZfdYsuQnUwBTFJdNSmpOZllqkb5dAlfGrfknGAsmTmSsaL13h62B8UF2FyMnh4SA icTno8vYuxi5OIQE1jNKPFz8lgnCWc0o0fT6DCNIlbCAtcTUDzfZQWwRAQuJCWvXMEIUTWSS aP7awNrFyMHBLCAqsX1WFUgNm4CWxKo715lBbH4BSYkNDbvBbF4Be4n2Ww9YQWwWAVWJ/n+z wWxRgQiJWw87WCBqBCVOznwCZnMKBEpcObSZDWQXs0A3o8ScHVMZQXYJCahIXDwWPIFRYBaS llnIykASzAJmEvM2P2SGsLUlli18DWVbS8z4dZANwlaUmNL9kB3CNpV4ffQjVK+xxLJ1f9kW MHKsYhQtTi0uzk03MtJLLcpMLi7Oz9PLSy3ZxAiMioNbflvtYDz43PEQowAHoxIPb8KN5+FC rIllxZW5hxhVgOY82rD6AqMUS15+XqqSCO8FlZfhQrwpiZVVqUX58UWlOanFhxilOViUxHnN Vt4PFxJITyxJzU5NLUgtgskycXBKNTCu3lG8rclhq/c6j1UmS/yK/kSkHL/3WvzsPcXWLytO XVm2/coaESUdx4lCj7OasycUvo7U4JOePlXmgsDt8DOLcvMPXRf8Jsz5a/7/96/mV9u67pgp tNDr5vytf6auE+1NjngQs83hy88bKzv2a2w0/uumV7PoycU/8rP2qBsbmjMt8tCUf539VYml OCPRUIu5qDgRAL2r4NWSAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/KThRgUAVf5h0PvHyXMQbapOEos4>
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: Mon, 26 Sep 2016 13:46:57 -0000

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