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

"Templin, Fred L" <Fred.L.Templin@boeing.com> Fri, 10 February 2017 22:47 UTC

Return-Path: <Fred.L.Templin@boeing.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 A9E9F129F2F for <dhcwg@ietfa.amsl.com>; Fri, 10 Feb 2017 14:47:04 -0800 (PST)
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 89PzRFBQnkAS for <dhcwg@ietfa.amsl.com>; Fri, 10 Feb 2017 14:47:02 -0800 (PST)
Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (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 504D9129F2D for <dhcwg@ietf.org>; Fri, 10 Feb 2017 14:47:02 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v1AMl16b053257; Fri, 10 Feb 2017 15:47:01 -0700
Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v1AMkx3w053226 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Fri, 10 Feb 2017 15:46:59 -0700
Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 10 Feb 2017 14:46:58 -0800
Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Fri, 10 Feb 2017 14:46:58 -0800
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@wide.ad.jp>, Lishan Li <lilishan48@gmail.com>
Thread-Topic: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt
Thread-Index: AQHSglOjbTsgor1qYk63PeyrUa0poqFi1e9w
Date: Fri, 10 Feb 2017 22:46:58 +0000
Message-ID: <aba52c11e462426bb3cbf66fcdca7783@XCH15-06-08.nw.nos.boeing.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>
In-Reply-To: <CAJE_bqf_AP9w1Bh_5kSB4YkLaV9XJ1tngufAiOMxVqQLwMruNA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [137.136.248.6]
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/RaNaD_JJJMKDltLmp0pJ06Z9ynA>
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: Fri, 10 Feb 2017 22:47:05 -0000

Hi, I have not reviewed this latest version of the draft but in my understanding
from past discussions is that this mechanism always encrypts and there is no
longer an "authentication-only" mode. That being the case, if this work is to go
forward the WG must first resurrect the Relay Agent Assignment Notification
(RAAN) draft:

https://www.ietf.org/mail-archive/web/dhcwg/current/msg17651.html

Otherwise, sedhcpv6 would be incompatible with Relays that must glean route
information during DHCPv6 PD exchanges.

Chairs - what do we need to do to make RAAN a working group item?

Thanks - Fred

> -----Original Message-----
> From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of ????
> Sent: Wednesday, February 08, 2017 1:38 PM
> To: Lishan Li <lilishan48@gmail.com>
> Cc: dhcwg <dhcwg@ietf.org>
> Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt
> 
> 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.
> 
> ...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.
> 
> - Section 1
> 
>    [...]  Such communications are already protected using the
>    mechanism described in section 21.1 in [RFC3315].
> 
>   Perhaps a better reference today would be
>   draft-ietf-dhc-relay-server-security.
> 
> - Section 1
> 
>    [...] The
>    Algorithm, Certificate, Signature, and Increasing-number options are
>    used for authentication.  The Encryption-Query message, Encryption-
>    Response message, Encrypted-message option and Encryption-Key-Tag
>    option are used for encryption.
> 
>   I suspect this is not 100% accurate.  Except for the signature
>   option, everything can also be used for (or related to) encryption.
> 
> - Section 5.3
> 
>    [...]  The same client and server SHOULD use the
>    same algorithm in a single communication session.
> 
>   Shouldn't this be a MUST?  Especially now that the client and the
>   server negotiate and fix a specific set of algorithms initially, I
>   don't see any possibility for an exception to this requirement.
> 
> - Section 5.3
> 
>    The sender can
>    offer a set of algorithms, and then the receiver selects one
>    algorithm for the future communication.
> 
>   s/sender/client/ and s/receiver/server/.  Only the client offers an
>   algorithm set using the algorithm option.
> 
> - Section 5.5: s/The One/One/
> 
>    The One feasible environment in
>    an early deployment stage would be enterprise networks.
> 
> - Section 5.5
> 
>    In
>    enterprise networks, the client is manually pre-configured with the
>    trusted servers' public key and the server is also manually pre-
>    configured with the trusted clients' public keys.
> 
>   I suggest s/is (also) manually/can (also) be manually/ since manual
>   configuration wouldn't be the absolute only option.
> 
> - 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.
> 
>   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).
> 
>   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.
> 
> - Section 6: s/return/subsequent/
> 
>    [...] The client
>    also uses the acknowledged algorithms in the return messages.
> 
> - 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?
> 
> - 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.
> 
> - 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.
> 
>   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).
> 
> - 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?).
> 
> - 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).
> 
> - 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?
> 
> - Section 10.1.1
> 
>                The mandatory encryption
>                algorithms MUST be included.
> 
>   Which algorithm is 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?
> 
> - 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).
> 
>   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.
> 
> - 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.
> 
>   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.
> 
>   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.
> 
> - 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?
> 
> - 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).
> 
> - 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.
> 
> --
> JINMEI, Tatuya
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg