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

Lishan Li <lilishan48@gmail.com> Mon, 13 February 2017 15:28 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 652031296BE for <dhcwg@ietfa.amsl.com>; Mon, 13 Feb 2017 07:28:47 -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 UW1jQEAqV-Us for <dhcwg@ietfa.amsl.com>; Mon, 13 Feb 2017 07:28:43 -0800 (PST)
Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 0C9E312961D for <dhcwg@ietf.org>; Mon, 13 Feb 2017 07:28:43 -0800 (PST)
Received: by mail-qt0-x22e.google.com with SMTP id x49so85958947qtc.2 for <dhcwg@ietf.org>; Mon, 13 Feb 2017 07:28:42 -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=f+e2TQVy5SYt2oBLsNMtcBwLBsomTLkP+UWIMsebEi4=; b=uSXdW+6D20TeV1DHeX9bs+It9dhp66BeX9/HS3gC9clhK8IPmwt9ObFNvJe6I54Ct2 Vkz+GWoDqc8yerpNmo9F4O9WrQKyQNShxHk0ACMOYeigBx9GfrubkzXM1MOClFI3klzd YlKh3v17k5VB7eEXWw4Ry6rLMHq9vbrvMUWSNgAv0ZB+wp3jVOHL4qcNEuuIPzTxCaYm sm/JtJZdO/uHqWx8pG0+w2jmIix2CbGzHv2wrAcAnR/ijtXixei6tCrYGsSEGMFKaxnY BfmwLu12/s099sklvPOqE1WZrvnPtYavIyHDvtp27C/S7XfzoLAis/t+XoZCopWPaFCl 2JZw==
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=f+e2TQVy5SYt2oBLsNMtcBwLBsomTLkP+UWIMsebEi4=; b=CeSN2r68obVFVFhnIFdmU56ivEH+gEQXB3TAZ16mtdrXr7txNiRM9nHWTL/WWarmAL LVJJAqxRpWBiYJC0J7g+AJ/J4qN4XOphpG5khNiakbf+CktG3HjQT9iPs+YWfU871Nus UKzazSxlvcVg7PWquID/6rJhKpKViJub/Ifj7UUZCva+Prnw+SR70s1IB2TmbjlR2ekL pwxDgKel7FVOYpPeeYGWv26zhbUa4d96R30svqWd5vNzktsGGVgbLfaKvsSdzx741mS2 k8GgmqkTXP5T7BTfKHWXFd7xx995/0CbiqdH2+KAnh5kf8tX+fMe2srnYyRidQsHDSSp aKIg==
X-Gm-Message-State: AMke39nvKO9UQ3YGN/Glke6xUuCOrhxIchvyfRLFgLUCyFD23QC5Nz1/4gRHgI9Xk1ykB7Fz7MhPfwSlXrKQzg==
X-Received: by 10.200.44.83 with SMTP id e19mr20440157qta.260.1486999721821; Mon, 13 Feb 2017 07:28:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.237.36.117 with HTTP; Mon, 13 Feb 2017 07:28:41 -0800 (PST)
In-Reply-To: <CAJE_bqf_AP9w1Bh_5kSB4YkLaV9XJ1tngufAiOMxVqQLwMruNA@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>
From: Lishan Li <lilishan48@gmail.com>
Date: Mon, 13 Feb 2017 23:28:41 +0800
Message-ID: <CAJ3w4NdR-YdNziqK1u_TpExhQLUukpL8uYzEQ4A0MoipOv-Huw@mail.gmail.com>
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Content-Type: multipart/alternative; boundary=001a11406f743376e505486b1a00
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/1107CGrzowyMfQxrS0hzAd3UiC4>
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: Mon, 13 Feb 2017 15:28:47 -0000

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

> At Mon, 16 Jan 2017 17:10:26 +0800,
> Lishan Li <lilishan48@gmail.com> wrote:
>
> > We have submitted a new version of secure DHCPv6. Thanks a lot for
> Bernie's
> > valuable comment.
>
> I apologize for having been inactive on this draft, especially despite
> being listed as a coauthor.  I've finally found time to take a closer
> look at it.  I see the 20 version has been improved a lot; it's much
> more readable than (some of the) older versions and many of the
> technical questions I raised before seem to be addressed.  I
> personally think we still need to discuss and address some more
> technical details, but IMO this version is now much closer to WGLC.
>
[LS]: Thanks a lot for your comments. As a coauthor, you have contributed
a lot and gave many valuable comments.

>
> ...with one big reservation: I'd very much like to see at least one
> attempt of implementing the spec.  This is a quite complicated
> protocol specification, and no matter how hard we review the paper
> spec, I'm quite sure that an actual implementation attempt will find
> many more unclear points or protocol defects.  Although I understand
> that's not a requirement for a WGLC or even for an RFC (the spirit of
> "believing in running code" has been the thing of past at the IETF,
> sadly) but I still hope we won't end up shipping a protocol spec with
> full of defects mainly because there is not even an attempt of
> implementing it before publishing it.
>
> Specific comments on the 20 version follow.  There is one thing that I
> guess needs broader attention, so I'm noting it here: I think we need
> more discussion on the meaning and justification of "Non-SigAlg" and
> "Non-EncryAlg" (especially the latter).  See below for more details.
>
> - 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;
2. If the Reconfigure option indicates the Renew message, then the client
sends the encrypted Renew message to the server. For this Encrypted-Query
message, it includes the server identifier option.
3. If the Reconfigure option indicates the Information-request message,
then
the client send the encrypted Information-request message to the server.
For this Encrypted-Query message, it does not include the server identifier
option. In this way, the Information message is received by all the servers
which
share the same certificate. If the client does not obtain the proper
parameters,
the client can choose other servers and sends the encrypted
information-request
message.


> - Section 6
>
>    And then the client first checks acknowledged hash, signature and
>    encryption algorithms that the server supports.  If the hash
>    algorithm field is zero, then it indicates that the hash algorithm is
>    fixed according to the corresponding signature algorithm.  The client
>    also uses the acknowledged algorithms in the return messages.
>
>   It's not clear to me from this text how the client checks the
>   algorithms.  By examining the certification option for the
>   signature/encryption algorithms and examining the signature option
>   for the hash ID?  If so, I think it should be clearly described.
>
[LS]: Yes. The signature and encryption algorithms are checked through
the certificate option. And the signature and hash algorithms are checked
through the signature option. And the signature algorithms id in the two
options must be equal. Will describe it more clearly.

>
>   I'd note that the signature ID in the certificate must be equal to
>   the signature ID of the signature option.  And, generalizing this,
>   what if the client doesn't support these algorithms? (This shouldn't
>   happen as long as the server handles the algorithm option correctly,
>   so this is basically a bug of the server implementation).
>
[LS]: For this error, then the client drops the Reply message.

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


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

>
> - 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:
>
>    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?  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.

>
> - Section 7
>
>    [...] If it is the target server, according to
>    the Encryption-Key-Tag option, the server identifies the used public/
>    private key pair and decrypts the Encrypted-message option using the
>    corresponding private key.
>
>   The key tag is not necessarily unique for different public keys (so
>   different key pairs), even if it should normally be unique in
>   practice.  If multiple public keys share the same tag value, the
>   server MUST try all corresponding key pairs.
>
[LS]: Got it. Will modify the related sentences.

>
>   Also, since the key tag option isn't covered by a signature, it may
>   have been forged by an intermediate attacker.  We may want to
>   describe what the server should do in such a case (just discarding
>   it is probably okay as it's forged anyway, but the server could also
>   try all possible keys just in case the key tag is the only forged
>   field).
>
[LS]: If the server then tries all the possible keys, then it is easy to
cause the attack to the server. So I think it is better to just drop it,
like
the action of decryption fail.
So we need to add the following text for this case.
If the server cannot find the corresponding private key of the key tag
or the corresponding private key of the key tag is invalid for decryption,
then the server drops the Encrypted-Query message

>
> - Section 7
>
>    The server validates the client's certificate through the local pre-
>    configured trusted certificates list.
>
>   I'm not sure if this paragraph covers the "opportunistic encryption"
>   mode, i.e, when the server doesn't know the certificate but chooses
>   to use it for encryption only.  (I'm assuming our intent is to
>   support such mode, right?).
>
[LS]: Yes, will add some description about it.

>
> - Section 7
>
>    To provide
>    the replay protection, the Increasing-number option can be contained
>    in the encrypted DHCPv6 message.
>
>   Shouldn't this be either SHOULD or MUST to be consistent with other
>   part of this spec?  (see also the possible SHOULD vs MUST conflict
>   commented above).
>
[LS]: The increasing-number option is optional.

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

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

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

>
> - Section 10.1.2
>
>    It should be noticed that the scenario where the values of EA-id and
>    SA-id are both 0 makes no sense and the client MUST discard a message
>    with such values.
>
>   The 0 EA-id/SA-id values are not described earlier in this
>   document.  I think it should explicitly define its semantics before
>   this text (perhaps in Section 10.1.1).
>
[LS]: Agree, will add some description before it.

>
>   And, from the description of Section 12:
>
>          Non-SigAlg      |   0x00  | this document
>            Non-EncryAlg  |   0x00  | this document
>
>   I guess it means the signature is (effectively) not provided and the
>   message is (effectively) not encrypted, respectively.  If my
>   understanding is correct, is it okay to allow that, especially about
>   encryption?  I vaguely recall a discussion about someone hoping to
>   introduce a non-encryption mode, but I thought we rejected the idea
>   because it would be against the "always encrypt" consensus.
>
[LS]: Sorry for the not clear expression.
In the before part, if the EA-id is set to zero, then the certificate is
not used
for encryption. If the SA-id is set to zero, then the certificate is not
used for
signature.

>
> - Section 10.1.5
>
>    encryption key tag  A variable length field containing the encryption
>       key tag sent from the client to server to identify the used
>       public/private key pair.  The encryption key tag is calculated
>       from the public key data, like fingerprint of a specific public
>       key.  How to generate the encryption key tag adopts the method
>       define in Appendix B in [RFC4034] and section 5.5 in [RFC6840].
>       The data of the public key is used as input of the generation
>       function.
>
>   If we derive the tag calculation from RFC4034, the length is not
>   variable: it's fixed to 16 bits.
>
[LS]: Will modify it to 16 bits

>
>   Also, I don't think we have to mention RFC6840 section 5.5.  We'd
>   only use the method described in Appendix B of RFC4034 for
>   algorithms other than type 1.
>
[LS]: Got it.

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

The Encryption Key Tag in the Encrypted-Query message provides a mechanism
for selecting
the corresponding private key for decryption. In most cases, the encryption
key tag
can efficiently identify a private key record. The Encryption Key Tag
option can
be used to help select the corresponding private key when more than one
candidate
private key is available.

However, it is essential to note that the encryption key tag is not a
unique identifier.
It is theoretically possible for two different public keys to share one
common encryption
key tag. The encryption key tag is used to limit the possible candidate
keys, bu it
does not uniquely identify a public/private key pair. Implements MUST NOT
assume that
the key tag uniquelly identifier a public/private key pair.

The encryption key tag is the same for all encryption algorithm types
except algorithm
1 (please see Appendix A.1 for the defination of the key tag for algorithm
1). The key
tag generation algorithm is the sum of the public key data broken into 2
octet groups.
First, the public key date is treated as a series of 2 octet groups. These
groups are
then added together.

A reference implementation of the key tag algorithm is as the below
function, with the
data of the public key is used as input. It is not necessary to use the
following
reference code verbatim, but the numerical value fo teh encryption key tag
MUST be
identical to what the referencr implementation would generate for the same
input.

The following reference implementation calculates the value of the
encryption key tag.
This reference implementation applies to all algorithm types except
algorithm 1 (see
Appendix A.1). The input is the data of the public key. The code is written
for clarity,
not efficiency.

/*
    * Assumes that int is at least 16 bits.
    * First octet of the key tag is the most significant 8 bits of the
    * return value;
    * Second octet of the key tag is the least significant 8 bits of the
    * return value.
    */

   unsigned int
   keytag (
           unsigned char key[],  /* the RDATA part of the DNSKEY RR */
           unsigned int keysize  /* the RDLENGTH */
          )
   {
           unsigned long ac;     /* assumed to be 32 bits or larger */
           int i;                /* loop index */

           for ( ac = 0, i = 0; i < keysize; ++i )
                   ac += (i & 1) ? key[i] : key[i] << 8;
           ac += (ac >> 16) & 0xFFFF;
           return ac & 0xFFFF;
   }

   A.1.  Key Tag for Algorithm 1 (RSA/MD5)

   The encryption key tag for algorithm 1 (RSA/MD5) is defined differently
from
   the encryption key tag for all other algorithms, for historical
reasons.  For a
   public key with algorithm 1, the encryption key tag is defined to be the
most
   significant 16 bits of the least significant 24 bits in the public key
modulus
   (in other words, the 4th to last and 3rd to last octets of the public
key modulus).


> - Section 11
>
>    [RFC6273] has analyzed possible threats to the hash algorithms used
>    in SEND.  Since Secure DHCPv6 defined in this document uses the same
>    hash algorithms in similar way to SEND, analysis results could be
>    applied as well: [...]
>
>   Does this matter even when the hash value is in an encrypted
>   message?
>
[LS]: Got it. Will delete it.

>
> - Section 11
>
>   I think we should also discuss a few more security issues in this
>   section:
>   - Since the algorithm option isn't protected by a signature, the
>     list can be forged without detection, which can lead to a
>     downgrade attack.
>   - Likewise, since the Encryption-Key-Tag Option isn't protected, an
>     attacker that can intercept the message can forge the value
>     without detection (see also the relevant comment on Section 7).
>
[LS]: Agree. Will add it.

>
> - Section 12
>
>    Hash Algorithm for Secure DHCPv6.  The values in this table are 8-bit
>    unsigned integers.
>
>   Shouldn't this be 16-bit?  It's defined as an 16-bit value for the
>   HA-id field of various options.  Same for the signature algorithm
>   and encryption algorithm.
>
[LS]: Will modify it.

Thanks again,
Lishan