[dhcwg] comments on draft-ietf-dhc-sedhcpv6-10.txt

神明達哉 <jinmei@wide.ad.jp> Thu, 07 January 2016 23:10 UTC

Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A76C1A1B13; Thu, 7 Jan 2016 15:10:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level:
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 M3Cuh7GNYonn; Thu, 7 Jan 2016 15:10:16 -0800 (PST)
Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::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 B03B21A1B8B; Thu, 7 Jan 2016 15:10:16 -0800 (PST)
Received: by mail-io0-x230.google.com with SMTP id 77so238445792ioc.2; Thu, 07 Jan 2016 15:10:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=TdZeFZbAQ+rX1uS/TpDAAXEWfE3Cf7j/MPBvPqw61do=; b=O1SCV1hBptb/86oFRaqGVkcHY78kSPCTf7QQr1fXR4rlJ+kwPdK44GaDS0mrPtcMws e9k/bAmMEyfl+hdOYbPi9Ibg2GMhQ1TJRrue4h6U8WyzXKsmPi23K/yPZcbXYyBUkGeG FC5i/oaoMaCeRtBtXGIiNr+pfoXUG5TDPKsWSDjecIKpGJQI9lfq8w5YALWN8sYX2Hb4 nxVQUgYS9dFmgLfSaXxzj55qV2BOHdw7iisLr+wYoqvUFIEiqDGl89VpRRX06epAQdrj 1oJ468NZc+PNcof1OzrQsQY2VS6WUTsNBDElGmU4jMczqk1/Lwu3ERYHeJK9fcVnD4p5 VqsQ==
MIME-Version: 1.0
X-Received: by 10.107.137.151 with SMTP id t23mr72900834ioi.172.1452208215958; Thu, 07 Jan 2016 15:10:15 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.129.80 with HTTP; Thu, 7 Jan 2016 15:10:15 -0800 (PST)
Date: Thu, 7 Jan 2016 15:10:15 -0800
X-Google-Sender-Auth: PWfUcDPgOiDd3fRHg_TGlwEY5ow
Message-ID: <CAJE_bqdZTc57BGzVq8-EaOa7kT2ME9_3bXNKFr0WGk_MzLNOBQ@mail.gmail.com>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
To: draft-ietf-dhc-sedhcpv6@ietf.org
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/YxUaUv908gfBreNeY5IMTJ6qHTw>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: [dhcwg] comments on draft-ietf-dhc-sedhcpv6-10.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 07 Jan 2016 23:10:19 -0000

I've read this version of draft.  While I happen to be listed as a
co-author, I was not really involved in this revision process, so I'm
basically making these comments as a third-party reader.

First, I have some higher-level points to discuss:

- this protocol changes DHCPv6 message exchanges quite substantially:
  previously, the client first sends a Solicit message, gets possibly
  multiple Advertise messages, chooses the server (= sender of one of
  the Advertises) that would be best for the client, and then sends a
  Request to that chosen server.  Now the server selection is done at
  the key exchange phase (the initial Information-request and Reply
  exchange), and the Solicit can be sent only to a single server.  If
  the client doesn't like the Advertise it could restart the whole
  process, but it will be more expensive, and there's no guarantee
  that other servers can provide a better Advertise.

  One might argue that it's okay as "secure DHCPv6" is an "optional"
  extension.  But, with keeping in mind that the current IETF trend is
  to make everything privacy-aware (often by making everything
  encrypted), I'd personally say we should consider it to be the
  standard mode of DHCPv6 operation even if users can still disable
  it.  From this point of view, I think we should either
  A. make the server selection behavior more compatible with the
     pre-encryption protocol, or
  B. accept we give up the previous server selection feature for
     privacy (after careful assessment of its effect and with clear wg
     consensus), and explicitly note that.  we might even have to
     reflect that in rfc3315bis.

- As encryption is now mandatory, I now wonder whether we need a
  separate "signature" at all.  Except for the signature in the reply
  to the initial Information-request, the explicit signature doesn't
  seem to provide any additional integrity or authentication.  And, as
  we now don't allow TOFU for authentication (i.e., we should validate the
  certificate out-of-band anyway, and that's almost the only important
  content of this reply), the signature in the first Reply wouldn't be
  much useful either.  So we might consider simplifying the protocol

- Slightly related to the previous point, this draft doesn't talk
  about encryption algorithms, let alone whether/how to negotiate the
  encryption algorithm.  (Aside from whether we need a separate
  'signature') Perhaps it implicitly assumes to use the "signature
  algorithm" for encryption, too, but, if so, I think it should
  explicitly say so.

- This protocol uses the server DUID as the identifier of the server
  key (pair), and (implicitly) assumes the client only has one key
  (pair).  Is that okay?  Don't we need a separate key ID value so we
  can identify the key to be used for decryption without actually
  trying to decrypt the message with all possible keys?  (In the case
  of client this might be trickier since the 'key ID' can reveal the
  identify of the client).

- The 'public key option' has been removed in this version.  I
  probably missed some part of the past discussions, but did we make
  that decision?  What's the rationale of the removal?

- The "security issues" and "applicability" sections (especially the
  latter) look still weak/insufficient to me.  I'll make some more
  specific comments below.

- Related to the previous point, what (will) happened for the separate
  threat analysis/usage document?  If the plan was to move all
  difficult discussions regarding the "security issues" to the
  separate document, we should also see it with this protocol
  document.  (In my understanding) the latter can't move forward
  itself otherwise.

Some specific comments on the draft text follow:

- Section 4

   authentication method.  However, this method provides little message
   integrity or source integrity check, and it protects only the
   Reconfigure message.  This key is transmitted in plaintext.

  I'm not sure if I get the phrase "this method provides little
  message integrity or source integrity check".  Does it try to say
  "*Because* the key is transmitted in plaintext"?

- Section 4

   IETF has expressed strong agreement that PM is an attack that needs
   to be mitigated where possible in [RFC7258].

  I think the acronym "PM" should be explicitly introduced when
  "pervasive monitoring" first appears (in Introduction).

- Section 5.1

   [...]  Depending on
   its policy, it can choose to connect repeat the server discovery
   process after certain delay or attempt to connect to a different
   network.

  I'm not sure what this 'connect' means.  Does it intend to say cases
  like a smartphone/laptop trying to find a wifi base station?

- Section 5.3: what about the server-to-client case?  Clients are
  expected to rely on the selection in the initial
  Information-request/Reply exchange?

   If the recipient does not support the algorithm used by the sender,
   it cannot authenticate the message.  In the client-to-server case,
   the server SHOULD reply with an AlgorithmNotSupported status code
   (defined in Section 10.3).  Upon receiving this status code, the
   client MAY resend the message protected with the mandatory algorithm
   (defined in Section 10.1.2).

- Section 5.4: in general, I think this section is still quite weak
  and/or insufficient.  First, the current text reads as if PKI is
  (readily) usable in enterprise networks, yet it dismisses its
  deployment as out-of-scope.  I don't think this would address
  concerns/questions raised by external reviewers.

  My understanding of the external feedback and our followup
  discussions is that one sure way to deploy this protocol in
  enterprise network is to almost manually configure the clients with
  the server certificate and configure the server with clients
  certificates.  But we'll then have to explain what's the advantage
  of this new protocol against the RFC3315 security mechanism since
  Section 4 of this document states manual configuration is one major
  flaw of the RFC3315 mechanism.  My personal answer to this question
  is that the public-key based approach is slightly securer in cases
  such as that where clients keys are quietly stolen by an attacker
  (so they can pretend to be a valid client later).

  On top of such realistic discussions, I think we can also mention
  the use of PKI as a possibility of making the configuration (much)
  less manual.  But since it would require answering many difficult
  questions, IMO we should be honest to say its feasibility is unclear
  right now and subject to future study and development.

  Also, if we revise this section as suggested above, Section 4 will
  have to be adjusted, too, since we can't (yet) claim secure DHCPv6
  solves the "flaws" of the existing mechanisms.

- Section 5.4:

   [...]  In enterprise network, the security policy is
   strict and the clients are stable terminals.  The PKI model is used

  What does 'stable' mean?  A desktop PC would be considered a "stable
  terminal", but what about laptops?  How about smart phones connected
  to the enterprise network based on the BYOD policy?

- Section 6

   For the security DHCPv6 client, it must have a public certificate.

  What does "*public* certificate" mean?  Does that mean it's not
  "private"?  Same for Section 7.

- Section 6

   [...]  The Information-request message MUST NOT include any
   option which may reveal the private information of the client, such
   as the client identifier option.

  I suggest adding "...or the certificate option".

- Section 6

   non-security options assigned to it.  The Option Request option in
   the Information-request message MUST contain the option code of
   certificate option, signature option, timestamp option, and server
   identifier option.

  Should we really need to include all of these?  The certificate
  option should surely be specified, but the need for the others seem
  to be almost automatically derived from the specification.

- Section 6

   [...] The client SHOULD also use the same algorithms in the
   return messages.

  It's not very clear to me what "return messages" mean (as the client
  is usually the initiator of DHCP exchanges).  Perhaps "in subsequent
  messages (of the same DHCPv6 session)"?

- Section 6

   [...]  Depending on its policy, it can choose to connect using
   plain, unencrypted DHCPv6, repeat the server discovery process after
   certain delay or attempt to connect to a different network.

  What "connect to a different network" means isn't very clear to me
  (see also the same sense of comment on Section 5.1)

- Section 6

   For the received Encrypted-Response message, the client extracts the
   encrypted-message option and decrypts it using its private key to
   obtain the original DHCPv6 message.

  What if the client has more than one key pair (see also the higher
  level comment above)?  Is it assumed to associate transaction-id to
  a particular key?

- Section 6

   o  Upon receiving a SignatureFail error status code, the client MAY
      resend the message following normal retransmission routines
      defined in [RFC3315].

  What's the rationale of this behavior?

- Section 7

   If the server does not send the timestamp option, the client ignores
   the timestamp check and verifies the signature.  If there is a [...]

  I don't understand the role of the first sentence in this context.

- Section 7

   [...]  Depending on server's local policy, the message without a
   Timestamp option MAY be acceptable or rejected.  If the server
   rejects such a message, a TimestampFail error status code, defined in
   Section 10.3, should be sent back to the client.  [...]

  To be sure: is the TimestampFail supposed to be returned when a
  message from the client doesn't have Timestamp but the server wanted
  it?

- Section 8

   [...]  Actually, by definition in this
   document, relay agents SHOULD NOT add any secure DHCPv6 options.

  Why is this a "SHOULD NOT", i.e. can't this be "MUST NOT"?

- Section 10.1.2

   Note: if both signature and authentication option are present,
   signature option does not protect the Authentication Option.  It

  Should we still worry about it?  The only possible reason for having
  both that I can see is to allow a newer client implementation to
  work with both new and old server implementations.  But now that the
  message is encrypted in a way that older implementations don't
  understand, it's completely impossible anymore.  I think we can now
  simply say Authentication Option shouldn't be used with Secure
  DHCPv6 (and if it's used the behavior is undefined).

- Section 10.1.3

   Timestamp      The current time of day (SeND-format timestamp
                  in UTC (Coordinated Universal Time). It can reduce
                  the danger of replay attacks.

  I'd add a reference to the SeND RFC here.

- Section 10.2.1

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    msg-type   |               transaction-id                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                             DUID                              .
     |                           (variable)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Why is the DUID dedicated field, instead of using the server
  identifier option?  There are other types of messages that require a
  server identifier option (e.g., RENEW), but they don't make it a
  separate field.  I don't see any reason how this case is different,
  and using a separate format will make implementations unnecessarily
  complicated.

Editorial nits:

- Section 4: this sentence at least misses a period (I'm not sure if
  it's terminated with 'improved' or some other text was expected
  after that).

   [...]  The
   basic DHCPv6 specification [RFC3315] defines security mechanisms, but
   they have significant flaws and can be improved

- Section 5.1: s/authentication, MUST/authentication MUST/

   key.  The message that fails client authentication, MUST be dropped.
   And the server sends the corresponding error status code to client.

- Section 6: s/security/Secure/

   For the security DHCPv6 client, it must have a public certificate.

- Section 7: s/pre-configured/pre-configured with/

   The server may be pre-configured a public key certificate, which is

- Section 7: s/replies/replies with/ (same for some other use cases of
  'reply')

   server authentication information, it replies the Reply message to

- Section 8 s/describes/described/

   [...]  The unknown
   messages MUST be forwarded as describes in [RFC7283].

- Section 10.1.2 s/be/be in/

   [...]  The signature option could
   be any place within the DHCPv6 message while it is logically created

- Section 10.1.2 s/chose not/chose not to/ Also, this sentence(-like)
  seems grammatically broken but I have no idea about how to fix it.

   changing auth option, the authors chose not include authentication
   option in the signature.