Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt

Lishan Li <lilishan48@gmail.com> Wed, 15 February 2017 11:46 UTC

Return-Path: <lilishan48@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC98129470 for <dhcwg@ietfa.amsl.com>; Wed, 15 Feb 2017 03:46:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level:
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 D3T0bBrwFLgS for <dhcwg@ietfa.amsl.com>; Wed, 15 Feb 2017 03:46:28 -0800 (PST)
Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 A7620127735 for <dhcwg@ietf.org>; Wed, 15 Feb 2017 03:46:28 -0800 (PST)
Received: by mail-qt0-x22b.google.com with SMTP id v23so134715674qtb.0 for <dhcwg@ietf.org>; Wed, 15 Feb 2017 03:46:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=a1/8uqIbK8e2llL5KltnEUg3gHPISf0Yox3gwsRwBsg=; b=uZgriojSy7daHrrh3yjVm74uEkKPQXsipwKaxN36+xAMGgPtr7KdO2G1a4rEeUePJd cCbxQOCSdqNSRFjSPgAxyf6ZXdvFknHdvY/lbxRPcOBhdEfOIeE/qKExaJTz6BpEnrbL xz/n7AGxfu2pXcqSZShBPBOKqdLCzXZZS7xezRPzXMP6lIPZv64VlyFLZgq8E4Eca2hp 1sj/hrDaffhpmCVxQtQc9fXhrlApxQINrLV7Zm/VeB4MFMPlAcCSRd1RxAlNXI+LwWca TF+YuWYC6Xw/X1BvE18oQRsp9A21GLmtPm4LAr6hDGQpll6cCCkKi5lwW9pHDoFzBrbM n4iw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=a1/8uqIbK8e2llL5KltnEUg3gHPISf0Yox3gwsRwBsg=; b=IOb/uWZi0Df+rfcY+hTubzmCOoXR4BFj76Vr1EfYGRV0UTEq0rJi65CZbPSfTHJcyT VCyz4YU40oIBskYNGcu5EMuUdpy58ljK/GfRL/RdDgiwB1gQB9YTiVaI7t7Ndlg7VDwU 6QGzJ+vd0QFTeVPaYdgx24O0O5hMvT3A/uJZqY7nrAwFnkhuINJnQaqV+/gjvfW7Pf8x A03u28aMU8Pn5Nm7pW2Y9sMaSyyNd77C7lOiRf1vj+S1siySH40YZJgSxDgAXYk8CpRb 2fA1yZTGo725IhDqouYgHcupe97Z9oEJhraBrl9pRoalsA+3/MnAEkhpviF8pxuKHjYw hghw==
X-Gm-Message-State: AMke39m+6Wsoy73NzHIdCAkS3BpwWHOThkosmfDn3psJLxeKCP+fSYQCZUv/SWMyEzPMZnBcFAyIeB3bVYjNuw==
X-Received: by 10.237.61.8 with SMTP id g8mr32263683qtf.91.1487159187753; Wed, 15 Feb 2017 03:46:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.46.172 with HTTP; Wed, 15 Feb 2017 03:46:27 -0800 (PST)
In-Reply-To: <CAJE_bqeCBjoGj7V1jTxAh_ce4TH3h_VWxFoRim8wU4OHhaLaow@mail.gmail.com>
References: <148455739520.22478.14651605359463322132.idtracker@ietfa.amsl.com> <CAJ3w4NdCk8CBfNagcXT_VW_50+=xK=N7aB5HHqqn3stMt7Gy-Q@mail.gmail.com> <CAJE_bqf_AP9w1Bh_5kSB4YkLaV9XJ1tngufAiOMxVqQLwMruNA@mail.gmail.com> <CAJ3w4NdR-YdNziqK1u_TpExhQLUukpL8uYzEQ4A0MoipOv-Huw@mail.gmail.com> <CAJE_bqeCBjoGj7V1jTxAh_ce4TH3h_VWxFoRim8wU4OHhaLaow@mail.gmail.com>
From: Lishan Li <lilishan48@gmail.com>
Date: Wed, 15 Feb 2017 19:46:27 +0800
Message-ID: <CAJ3w4NefG3M0+y53xVKM9fOzLaFDgd9FygbNPC5SFDsGXw55JA@mail.gmail.com>
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>, Ted Lemon <Ted.Lemon@nominum.com>
Content-Type: multipart/alternative; boundary=001a11417c781c5a3c0548903b87
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/ggcFzwAxJNSOn-djYE4_l6YgO68>
Cc: dhcwg <dhcwg@ietf.org>
Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Feb 2017 11:46:31 -0000

2017-02-15 5:20 GMT+08:00 神明達哉 <jinmei@wide.ad.jp>jp>:

> At Mon, 13 Feb 2017 23:28:41 +0800,
> Lishan Li <lilishan48@gmail.com> wrote:
>
> > > - general: it's still not clear to me how we use this mechanism for
> > >   Reconfigure.
> > >
> > [LS]: According to my understanding:
> > 1. The server sends the encrypted Reconfigure message to the client;
>
> Encapsulated in an Encrypted-Response message?  If so, with setting
> transaction-id to 0 (like Reconfigure itself)?  And is the client
> supposed to try to decrypt it when transaction-id is 0 even if it
> doesn't match any outstanding Encrypted-Query it has sent?  And in
> that case which private key should the client use?  (For the last
> question, see also the comment on the assumption of the number of
> client certificate described in Section 6).
>
> I think these questions and issues can be addressed relatively easily,
> but I believe these should be clearly and explicitly described.
>
[LS]: How about the following method:
The transaction-id of the Encrypted-Reponse message MUST be equal with the
transaction-id of the received Encrypted-Query message and cannot be zero.
In this way, the client will try to decrypt it.

>
> > >   The description of zero hash algorithm field seems to suggest the
> > >   signature and hash algorithms are tightly related in practice.  So
> > >   it may be better to define the algorithm option so that
> > >   signature/hash algorithms are listed as pairs.
> > >
> > [LS]: Yes. In some cases, the signature and hash algorithm are tightly
> > related and cannot be separate. Sorry that I don't understand that
> > "it may be better to define the algorithm option so that signature/hash
> > algorithms are listed as pairs", Could you please explain it more
> clearly?
>
> For example, instead of listing SA-id List and HA-id List separately,
> we might have unified SA-id List:
>
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |      OPTION_ALGORITHM         |         option-len            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    .                          EA-id List                           .
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    .                          SA-id List                           .
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> (no "HA-id List" in this level)
>
> and each entry of SA-id List has two sub fields: signature algorithm
> ID and hash algorithm ID:
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |           SA-len              |            SA-id[1]           |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |           HA-id[1]            |            SA-id[2]           |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |           HA-id[2]            | ...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |           SA-id[n]            |            SA-id[n]           |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> and each pair of (SA-id[i], HA-id[i]) will be considered to specify a
> specific signature method.
>
[LS]: So, for every SA-id, there is a corresponding HA-id or multiple
HA-id(s).
SA-id and HA-id are set to a pair. Right?


> > > - Section 6
> > >
> > >    The first DHCPv6 message sent from the client to the server, such as
> > >    Solicit message, MUST contain the Certificate option, Signature
> > >    option and Increasing-number option for client authentication.[...]
> > >    [...]  One and only one Increasing-number option SHOULD be
> > >    contained,
> > >
> > >   Isn't there a MUST vs SHOULD conflict here?
> > >
> > [LS]: The increasing-number option is optional, not must be contained.
> > In the before version of secure DHCPv6 without encryption, the timestamp
> > option is optional. But in fact, I don't know why it is optional.
>
> This doesn't address my question...
>
[LS]: Sorry. Will correct it.

>
> > > - Section 6
> > >
> > >    [...] In this document, it is assumed
> > >    that the client uses only one certificate for the encrypted DHCPv6
> > >    configuration.  So, the corresponding private key is used for
> > >    decryption.
> > >
> > >   I'm not sure if this is okay.  And, in fact, Section 11 talks about
> > >   a case where multiple key pairs (so multiple certificates) are used:
>
[LS]: We have discussed this issues before.
In most cases, a client will not uses multiple certificate(s) for the
encrypted DHCPv6 configuration process in the same time. Please see the
following reasons:
After the client authentication, the client will use the public key in the
certificate option for encryption. The server only knows one client's
public key for encryption. And the client will also only uses one private
key for decryption. So there is no cases that the client will use one key
pair for the encryption of some DHCPv6 messages and use another key pair
for the encryption of another DHCPv6 messages.

> > >
> > >    If the client tries more than one cert for client authentication,
> the
> > >    server can easily get a client that implements this to enumerate its
> > >    entire cert list and probably learn a lot about a client that way.
> > >
> > >  Perhaps this is intended to handle encrypted Reconfigure?

[LS]: No, this is not designed for the encrypted Reconfigure. This is
different from the above issue.
We consider the scenario where the client has multiple certs. In the
authentication process, if one cert of the client fails, the client may
send another cert for authentication. But once the authentication
successes, then the client and server will only uses the authenticated
public key for encryption.

> If that's
> > >  the only reason for this limitation, I think we should address the
> > >  reconfigure case in some other way and keep the general specification
> > >  more flexible.

> >
> > [LS]: So we deletes the description in section 11.
>
> I don't understand how this addresses the comment...


> > > - Section 9.1
> > >
> > >    [...]  And the client can forget the increasing number
> > >    information after the transaction is finished.  The client's initial
> > >    locally stored increasing number is set to zero.
> > >
> > >   I'm not sure if I understand it and I'm not sure if it's okay
> > >   whatever it means...does this mean the server can (or always does?)
> > >   reset the increasing number to 0 for messages it sends to the server
> > >   at the beginning of a new DHCPv6 session?  Doesn't it lead to an
> > >   easy replay attack?  Or is the assumption that the server first
> > >   sends an error and the client will resend the message with an
> > >   adjusted increasing number?
> > >
> > [LS]: For the first received increasing-number option, the client cannot
> > check it and just need to change the local increasing number into the
> > received number. So for this purpose, i add the above statement.
> > Looking forward to your further guidance.
>
> I'd suggest consulting Ted here, as I guess the introduction of
> increasing-number option was originally his idea.
>
[LS]: Will send another email to Ted for his comment.

>
> > > - Section 10.1.1
> > >
> > >                The mandatory encryption
> > >                algorithms MUST be included.
> > >
> > >   Which algorithm is it?
> > >
> > [LS]: The mandatory encryption algorithm is RSA. How about the following
> > text:
> > The mandatory encryption algorithm, such as RSA, MUST be included.
>
> I don' know why "such as".  I'd consider a particular algorithm(s)
> mandatory at the time of this document, and it/they should be
> explicitly defined here.

[LS]: Got it.

>
> > > - Section 10.1.2
> > >
> > >     0                   1                   2                   3
> > >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |      OPTION_CERTIFICATE       |         option-len            |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |              EA-id            |            SA-id              |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                                                               |
> > >    .                           Certificate                         .
> > >    |                                                               |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >
> > >   This seems to assume a single certificate (which I assume means a
> > >   single public key) can be used for both encryption and signature.
> > >   Is my understanding correct?  If so, can we always assume that?
> > >
> > [LS]: Yes, it means a single certificate and a single public key.
> > If EA-id = 0 & SA-id !=0, then the public key is used for signature.
> > If EA-id != 0 & SA-id =0, then the public key is used for encryption.
> > If EA-id != 0 & SA-id !=0, then the public key is used for signature and
> > encryption.
>
> Ah, so if we want to use different algorithms and/or keys for
> signature and encryption, we have two certificate options, each
> setting EA-id or SA-id to 0?  If so, I suggest explaining it
> explicitly.
>
[LS]: Yes. Will explain it more clearly.

>
> > >   And, although it may be quite straightforward, I don't think this
> > >   description is enough to actually calculate the tag value for a
> > >   given public key.  We should provide some more specific here.
> > >
> > [LS]: Add some more specific text about how to compute it?
> > In the before, I prepared some text about it.
> >  Key Tag Calculation
>
> I've not read the entire text, but it looked like a bit too verbose.
> I'll see if I can offer some specific text.
>
[LS]: Agree. Looking forward to your contributed text.