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

René Hummen <hummen.committees@gmail.com> Wed, 01 June 2016 12:08 UTC

Return-Path: <hummen.rwth@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 2ECEF12D1A0 for <hipsec@ietfa.amsl.com>; Wed, 1 Jun 2016 05:08:51 -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 yPdr3ZRn28mW for <hipsec@ietfa.amsl.com>; Wed, 1 Jun 2016 05:08:48 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 03CFA12D19E for <hipsec@ietf.org>; Wed, 1 Jun 2016 05:08:42 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id c127so15921339ywb.1 for <hipsec@ietf.org>; Wed, 01 Jun 2016 05:08:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=eAhrjIyDyNtxdOXNdTJs9j7muHgS8oKU1ig64AZNlDI=; b=UaOvv1yiFw9fTxQH8PQHBcFY3b0ARPwSeX/MrnDQPXFTWOlpsgMytaFc1isLkpwNUy MvkSPZcXmQuorSBem5V1XPC/Pthuny281DejUwZBnNfwKpS/3Yp251lnM8YgEuq9LiyO rnzqMsHU0qKkkisq1Ok+Y6DvxS8fh6vMW6T+30FQjsRYnuhFTof+SPK9iugRldBzIDkI 0YkGDPscZjcvDaMBEM7CO0lGiTeewl+39UrBqdNrRZaSvGPvChg/QfQAk/uS/KTTfUOc cZu2NcEpSudtzhV+Rm0+hIeyRobbdTa7UH4GzZFFuxYbHqs+uKPdiCr4f/FGKgTnHzbP nsoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=eAhrjIyDyNtxdOXNdTJs9j7muHgS8oKU1ig64AZNlDI=; b=IF5fJlenLJl7lmkXeyO1T9B30Yb2BmEmEnv8GWoeDIGEIOew1NKIIWNclV91Mn5nWe 9VMtae4X7fNAq1BoLVpYBFLfRPZwKwVAj4ec1ZhL8OcwthFvAgOD6Otio/Y34F5EiDyG uFu2b3GI/Xi+O2okmzP+r1GYYZDMCoUorHo7IaEE/D9ApUay7p1EYue5uukquhpoBV3v sDvf3tkWa70ieEVmmwEfosPM8gJaE9IDYYxwAyhN5VP7hJBZlGTeK4mud7kn5nzk7swz wQX1jnvKYhOWzlpzWhNgtClAvx0oGF+wmOMbSjk7gAJXritItXvjmxdAsJrQjpxxu+tA vK6g==
X-Gm-Message-State: ALyK8tIqZDFvHB6wlgkrln/OjsG+6hBSiK1P4WakYtJhPHrqCFtq9nWnTOoxJk4UPGlFfonBWuppfhz50nT+8A==
MIME-Version: 1.0
X-Received: by 10.37.37.138 with SMTP id l132mr2017292ybl.170.1464782921145; Wed, 01 Jun 2016 05:08:41 -0700 (PDT)
Sender: hummen.rwth@gmail.com
Received: by 10.13.249.6 with HTTP; Wed, 1 Jun 2016 05:08:41 -0700 (PDT)
In-Reply-To: <56F98E90.10601@ericsson.com>
References: <20160321203627.12199.62928.idtracker@ietfa.amsl.com> <56F98E90.10601@ericsson.com>
Date: Wed, 01 Jun 2016 14:08:41 +0200
X-Google-Sender-Auth: 05mOms4bZ8SjrbfS3zcdFbb3myQ
Message-ID: <CAEhFMciKtw36uCgiopxMsqmWgZ=n1G_aH5psmFgseN3CtPOS=w@mail.gmail.com>
From: René Hummen <hummen.committees@gmail.com>
To: Miika Komu <miika.komu@ericsson.com>
Content-Type: multipart/alternative; boundary="001a113d456ab024a805343659ed"
Archived-At: <http://mailarchive.ietf.org/arch/msg/hipsec/6NK3fxMqCGovypm0EdJ7stTg8wU>
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: Wed, 01 Jun 2016 12:08:51 -0000

This is part 2. More to come...

On Mon, Mar 28, 2016 at 10:05 PM, Miika Komu <miika.komu@ericsson.com>
wrote:

[...]


> > 5.2.1.  DH_GROUP_LIST
> >
> > The DH_GROUP_LIST parameter contains the list of supported DH Group
> > IDs of a host.  It is defined in Section 5.2.6 of [RFC7401].  With
> > HIP DEX, the DH Group IDs are restricted to:
> >
> > Group                              KDF              Value
> >
> > NIST P-256 [RFC5903]               CKDF             7
> > NIST P-384 [RFC5903]               CKDF             8
> > NIST P-521 [RFC5903]               CKDF             9
> > SECP160R1  [SECG]                  CKDF             10
> > Curve25519 [RFC7748]               CKDF             11
> > Curve448   [RFC7748]               CKDF             12
> >
> > The ECDH groups 7 - 9 are defined in [RFC5903] and [RFC6090].  ECDH
> > group 10 is covered in [SECG] and Appendix D of [RFC7401].  These
> > curves, when used with HIP MUST have a co-factor of 1.
>
> I suggest to change the "value" column title to "group id" or change the
> text
> as follows: "The ECDH groups with *values* 7 - 9..."
>

Fixed according to your second suggestion.


> > The ECDH groups 11 and 12 are defined in [RFC7748].  These curves
> > have cofactors of 8 and 4 (respectively).
>
> Same comment as previously.
>

See above.

> 5.2.3.  HOST_ID
> >
> > The HOST_ID parameter conveys the Host Identity (HI) along with
> > optional information about a host.  It is defined in Section 5.2.9 of
> > [RFC7401].
> >
> > HIP DEX uses the public portion of a host's static ECDH key-pair as
> > the HI.  Correspondingly, HIP DEX limits the HI algorithms to the
> > following profile:
>
> I would add "*new* profile" since this is not part of RFC7401.
>

Done.

> 5.2.4.  HIT_SUITE_LIST
> >
> > The HIT_SUITE_LIST parameter contains a list of the supported HIT
> > suite IDs of the Responder.  Based on the HIT_SUITE_LIST, the
> > Initiator can determine which source HIT Suite IDs are supported by
> > the Responder.  The HIT_SUITE_LIST parameter is defined in
> > Section 5.2.10 of [RFC7401].
>
> > The following HIT Suite IDs are defined for HIP DEX, and the
> > relationship between the four-bit ID value used in the OGA ID field
> > and the eight-bit encoding within the HIT_SUITE_LIST ID field is
> > clarified:
>
> ...the following *new* HIT Suite IDs...
>
> ...is clarified: -> ...is defined as follows:
>

Added "new". However, I kept the "is clarified" bit as this is text
straight from RFC7401. I do not want to make the impression that we are
defining a new mapping here.


> > Note that the HIP DEX HIT Suite ID allows the peers to distinguish a
> > HIP DEX handshake from a HIPv2 handshake.  The Responder MUST respond
> > with a HIP DEX HIT suite ID when the HIT of the Initiator is a HIP
> > DEX HIT.
>
> The details are a bit unclear. Which packet are you talking about here?
>
> I mean the suite id is in R1 (and not in I1), so I guess you're referring
> that
> Responder must respond to I2 with an R2 that contains HIP DEX HITs?
>

I modified the first sentence as follows:
"Note that the HIP DEX HIT Suite ID in the OGA ID field allows the peers to
distinguish a HIP DEX handshake from a HIPv2 handshake."

I will also write up the resquested DEX/BEX interop section.


> > 5.2.5.  ENCRYPTED_KEY
> >
> > [...]
> >
> > The ENCRYPTED_KEY parameter encapsulates a random value that is later
> > used in the session key creation process (see Section 6.3).  This
> > random value MUST have a length of at least 64 bit.  The puzzle value
> > #I and the puzzle solution #J (see [RFC7401]) are used as the
> > initialization vector (IV) for the encryption process.  To this end,
> > the IV is computed as FOLD(I | J, 128).  The AES-CTR counter is a 16
> > bit value that is initialized to zero with the first use.
>
> The initialization vector is a explicit, separate field in RFC7401. Why I
> and J
> are implicitly reused here? To save bits?
>

Yes, this is to save bits.


> The AES-CTR counter pops out a bit suddenly here. Perhaps you could
> "bridge" it to the text in a bit more smoother way.
>

I changed the text as follows:
"Moreover, a 16 bit counter value, which is initialized to zero on first
use, is appended to the IV value in order to guarantee that a non-repeating
nonce is fed to the encryption algorithm defined by the HIP_CIPHER."


> > Once this encryption process is completed, the "encrypted value" data
> > field is ready for inclusion in the Parameter.  If necessary,
> > additional Padding for 8-byte alignment is then added according to
> > the rules of TLV Format in [RFC7401].
>
> The key could be also included in ENCRYPTED parameter, which can
> accommodate multiple parameters... unless it is very important to
> keep the IV implicit.
>

Bob and I discussed about this as well, but felt that the bytes saved on
the wire would outweigh the cost of supporting an additional parameter.


> > 5.3.  HIP Packets
> >
> > [...]
> >
> > In the future, an optional upper-layer payload MAY follow the HIP
> > header.  The Next Header field in the header indicates if there is
> > additional data following the HIP header.
>
> RFC6078 is also future work.
>

See my comment about the need for signatures in my previous email.


> > 5.3.1.  I1 - the HIP Initiator Packet
> >
> > [...]
> >
> > As a compression of the employed HIs, the Initiator's and the
> > Responder's HITs both determine the DH group ID that must be used in
> > order to successfully conclude the triggered handshake.  HITs,
> > however, only include the OGA ID identifying a HIP DEX HIT.  They do
> > not include information about the specific DH group ID of the
> > corresponding HI. [...]
>
> Something wrong here, the first sentence is contradicting with the
> second and third one.
>

This clearly was unclear. I made another attempt at this as follows:
"As the Initiator's and the Responder's HITs are compressions of the
           employed HIs, they determine the DH Group ID that must be used in
           order to successfully conclude the triggered handshake. HITs,
           however, only include the OGA ID identifying the HI algorithm.
They
           do not include information about the specific group ID of the
HI."


> > 5.3.2.  R1 - the HIP Responder Packet
> >
> > [...]
> >
> > The R1 packet generation counter is used to determine the currently
> > valid generation of puzzles.  The value is increased periodically,
> > and it is RECOMMENDED that it is increased at least as often as
> > solutions to old puzzles are no longer accepted.
>
> Section 6.1 describes: "The only exceptions are that HIP DEX does not
> use pre-computation of R1 packets and that RHASH is set to CMAC.  As a
> result, the pre- computation step in in Section 6.3 of [RFC7401] is
> skipped in HIP DEX.
>
> I guess R1 packet generation counters are still meaningful for the
> Initiator (despite Responder does not pre-generate R1s)?
>

Section 6.1 does not mandate not to use pre-computation. For this reason,
we did not remove it here. Moreover, it is an optional parameter, so we did
not want to prevent its use per se.


> > [...]
> >
> > The HOST_ID parameter depends on the received DH_GROUP_LIST parameter
> > and the Responder HIT in the I1 packet.  Specifically, if the I1
> > contains a Responder HIT, the Responder verifies that this HIT
> > matches the required DH group based on the received DH_GROUP_LIST
> > parameter.
>
> "...included in the I1". Right?
>

Added.

> 5.3.3.  I2 - the Second HIP Initiator Packet
> >
> > [...]
> >
> > The HIP_CIPHER contains the single encryption transform selected by
> > the Initiator that it uses to encrypt the ENCRYPTED and ENCRYPTED_KEY
> > parameters.  The chosen cipher MUST correspond to one of the ciphers
> > offered by the Responder in the R1.  All implementations MUST support
> > the AES-CTR transform [RFC3686].
> >
> > [...]
> >
> > The TRANSPORT_FORMAT_LIST parameter contains the single transport
> > format type selected by the Initiator.  The chosen type MUST
> > correspond to one of the types offered by the Responder in the R1
> > packet.  Currently, the only transport format defined is the ESP
> > transport format [RFC7402].
>
> Should all of the cipher suites and transport formats still be echoed
> to the Responder for security reasons? See also my next comment.
>
> > 5.3.4.  R2 - the Second HIP Responder Packet
> >
> > [...]
> >
> > The Responder repeats the DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST,
> > and TRANSPORT_FORMAT_LIST parameters in the R2 packet.  These
> > parameters MUST be the same as included in the R1 packet. The
> > parameter are re-included here because the R2 packet is MACed and
> > thus cannot be altered by an attacker.  For verification purposes,
> > the Initiator re-evaluates the selected suites and compares the
> > results against the chosen ones.  If the re-evaluated suites do not
> > match the chosen ones, the Initiator acts based on its local policy.
>
> Ok, so now the full list of parameters is included, so forget about my
> previous comment.
>

Done :)