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

[神明達哉 <[e-mail]>]

At Mon, 16 Jan 2017 17:10:26 +0800,
Lishan Li <[e-mail]> 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