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

René Hummen <hummen.committees@gmail.com> Sat, 22 October 2016 08:22 UTC

Return-Path: <hummen.committees@gmail.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 7D1E1129498 for <hipsec@ietfa.amsl.com>; Sat, 22 Oct 2016 01:22:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 TW95Hu0XfljQ for <hipsec@ietfa.amsl.com>; Sat, 22 Oct 2016 01:22:34 -0700 (PDT)
Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60B051293D6 for <hipsec@ietf.org>; Sat, 22 Oct 2016 01:22:34 -0700 (PDT)
Received: by mail-it0-x236.google.com with SMTP id 198so17055012itw.0 for <hipsec@ietf.org>; Sat, 22 Oct 2016 01:22:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9yLBi34A/m0hkk7VFaiuFYdev+hqzADSVZAy3Wan7F0=; b=X+mKAehXmtadd7auze5ZqLldNjXZeFkrEoHpqGPGl8fh69fHIetDuFwVva/RKdlTVF dPmH0SGuBTUHZrdzyLwzpLvSFnmaty7ralu/KWSgV6cxSyahPJ9UV7dyMYBmqaNO4ai8 K6gp4t6kV+rU7JbhQydPI/zG3VDhsqYDe+07KS1z4GJJ02DWzuxQNillla5U9rvuDWof Rxj4WIVEoqyT5V7rLSprM01XgrauyWT9MbAUHEARLhj9YtnpMjAqGhzqyi88fWnGqJjW rvI3Hip4GP5qmRb60x/tT1wbRXPbAPWAl9sI9gV/PPHezngxPeMCZZ1tYmj2We/qd6R/ +N1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9yLBi34A/m0hkk7VFaiuFYdev+hqzADSVZAy3Wan7F0=; b=UzU90HCo6kyzLsKljI1y16PpOXEN5bhTbCFlmlhmwJtH08kBYj3p19c6CwrQ9gSYUH /AvDFk8X+zD4HSwbXytE+hVWAVTIcvUxoiqjSAOAqmGh1UGYRYPV+O8DyqjAE+6/1j0h Ui5TLorKzAnyufn1xCuKfgLDxGRkhLpWJKuaLb3O8I2DTaGelAafXs1R84tdMEt+N9rV KzY1Xnf/C0vdDes5CMk2z7pjBd4aYePmOngRhOUm1qHVuk6dHxZbbQBuRmKDWTvMgDeU 3kyDAFfkHoEvlb21kp0Ru6JXpuz+xUrJEgzgXMwgJZRg5ivRcEdHFvSmNv7tdzlL5Nuk mvnQ==
X-Gm-Message-State: AA6/9RnOALIwbGiWJ41HX92TDYHMDNOOnAmJgw4lEFvi3NM68FXY23/DSmk0xTGZL3bhDm9vSMc2UwXMQhEXcg==
X-Received: by 10.202.207.151 with SMTP id f145mr14035626oig.45.1477124553640; Sat, 22 Oct 2016 01:22:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.92.229 with HTTP; Sat, 22 Oct 2016 01:22:32 -0700 (PDT)
In-Reply-To: <cc2d82b2-447c-3b16-5858-8cae5710b174@ericsson.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> <cc2d82b2-447c-3b16-5858-8cae5710b174@ericsson.com>
From: =?UTF-8?B?UmVuw6kgSHVtbWVu?= <hummen.committees@gmail.com>
Date: Sat, 22 Oct 2016 10:22:32 +0200
Message-ID: <CANS20HNwQYuf5dsFKsj9wSrBRH3a2tXrQ=p0A5fVsL37oPVvRA@mail.gmail.com>
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Content-Type: multipart/alternative; boundary=001a113b047c4f0f95053f6fdca2
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/c5gQiaNwwG4ckYvjy3S8mQka6O0>
Cc: =?UTF-8?B?UmVuw6kgSHVtbWVu?= <hummen.rwth@gmail.com>, 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: Sat, 22 Oct 2016 08:22:37 -0000

Hi,

I just uploaded draft version 04, where I addressed Miika's comments as
discussed in the previous emails.

>From my point of view, this document is ready to proceed.

BR
René

2016-10-21 9:13 GMT+02:00 Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
:

> 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 mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec
>