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

["Templin, Fred L" <[e-mail]>]

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:[e-mail]] On Behalf Of ????
> Sent: Wednesday, February 08, 2017 1:38 PM
> To: Lishan Li <[e-mail]>
> Cc: dhcwg <[e-mail]>
> 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 <[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
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg