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

Dear Jinmei,

Thanks a lot for your valuable comments. For the detailed replies, please
see inline ( these lines start with [LS] ).

Best Regards,
Lishan

2016-01-08 7:10 GMT+08:00 神明達哉 <jinmei@wide.ad.jp>:

> 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.
>
> [LS]: In my opinion, we should give up the previous server selection
feature for
privacy. Compared with rfc3315 and rfc3315bits, secure DHCPv6 is another
mode. rfc3315bis is clear-text mode. And the secure DHCPv6 is secure mode
which achieves authentication and encryption. The server selection feature
and configuration process are all different. And I think it is not
necessary
to reflect the character of secure DHCPv6 mode in rfc3315bis. Looking
forward
to your further guidance.

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

[LS]: In the current version, the client-to-server and server-to-client
both send the certificate option, signature option and timestamp option.
I think that only the server-to-client case MUST contain the signature
option and timestamp option.
In the server-to-client case, the signature and timestamp option in
the Reply message is used to protect the message integrity. So it is
better to remain the timestamp and signature option.
In the client-to-server case, the certificate option is contained in
the encrypted Solicit/Information-request message. Because the message
is encrypted, there is no need to contain the signature and timestamp
option to protect the message integrity.
What do you think of it?

>
> - 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.
>
> [LS]: The encryption algorithm need to be added. I will try to add
it in the next version.

- 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).
>
> [LS]: I think we can use the message transaction-id as the identifier of
the server's public key for encryption, and the client's private key
for decryption. What do you think of it?

- 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?
>
> [LS]: In the current version, TOFU is out of scope. The client and server
use  certificates for authentication, not public key. So I think the
certificate
option is enough. The public key option is removed.

- 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.
>
> [LS]: we have updated a new version of the secure DHCPv6 deployment.
I wish you can give some comments on the secure DHCPv6 deployment draft.
Thanks in advance.

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"?
>
> [LS]: How about the following text:
[...]  However, this method provides little message integrity or source
integrity check, and it protects only the Reconfigure message. In addition,
the key is transmitted in plaintext to the client in earlier exchanges.
[...]

- 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).
>
> [LS]: Will correct it.

> - 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?
>
> [LS]: According to Bernie's comment, we have changed this sentence as
follows:
Depending on its policy, it can choose to repeat the server discovery
process after certain delay or attempt to use an unsecured DHCPv6 server.

- 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).
>
> [LS]: In the next version, only in the server-to-client case, the server
will send the Reply message with signature and timestamp option to the
client for server authentication.
So, how about replacing with the following text:
If the client does not support the hash and signature algorithms used by
the server, the Reply message SHOULD be dropped. If both hash and signature
algorithms are supported, the client then checks the authority of this
server. The client SHOULD also use the same algorithms in the subsequent
messages.

- 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.
>
> [LS]: How about the following "applicability" section:
Secure DHCPv6 is applicable in environments where physical security
on the link is not assured and attacks on DHCPv6 are a concern, such
as enterprise networks. In enterprise networks, the DHCPv6 clients
are manually pre-configured with the trusted servers' certificates to
achieve server authentication. In addition, the DHCPv6 server is
pre-configured with the trusted clients' certificates to verify the client's
identity. After the mutual authentication, the DHCPv6 message is encrypted
 with the recipient's public key, which is contained in the certificate.
The use of PKI as a possibility of making the configuration less manual.
However, its feasibility is unclear right now and subject to future study
and development.

And we supply the following text in section 4:
The public-key based approach proposed in this document is slightly
securer in some cases. For example, if the client's key is quietly
stolen by an attacker, then the attack can pretend to be a valid client
later.

> - 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.
>
> [LS]: Will correct it. public certificate -> certificate.

> - 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".
>
> [LS]: Will correct it.

> - 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.
>
> [LS]: The signature option and timestamp option are used for the message
integrity check. The Reply message is transmitted in clear text. So in
order to protect the Reply message integrity, I think the timestamp
and signature option MUST be contained.

> - 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)"?
>
> [LS]: Have corrected it. return messages -> subsequent messages

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

[LS]: According to Bernie's comment, we have changed this sentence as
follows:
Depending on its policy, it can choose to repeat the server discovery
process after certain delay or attempt to use an unsecured DHCPv6 server.

- 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?
>
> [LS]: Yes. In my option, the particular key is associated with
transaction-id.
What is your opinion? Looking forward to further guidance.

- 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?
>
> [LS]: In the new version, the client will not send the signature option and
timestamp option. So we will delete these sentence.

- 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.
>
> [LS]: Will delete the first sentence in the next version.

> - 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?
>
> [LS]: Yes. Maybe the above sentences are not clear. How about the following
sentences:
[...]  Depending on server's local policy, the message without a
Timestamp option MAY be accepted or rejected.  If the server
rejects such a message without Timestamp option, then a TimestampFail
error status code, defined in Section 10.3, should be sent
back to the client.  [...]

- 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"?
>
> [LS]: Agree. Will correct it.

> - 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).
>
> [LS]: I agree. So we replce this section with the following sentences:
If the Secure DHCPv6 is applied, then the Authentication Option shouldn't
be used.

- 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.
>
> [LS]: Have added a reference: Section 5.3.1, [RFC3971].

> - 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.
>
> [LS]: Have modified it. In the new version, the diagram should just have
basic
client format (see RFC 3315, Section 6) and then text to specify that it
MUST contain a Server Identifier option and an Encrypted-message option.

Editorial nits:
>
> Thanks a lot for the throughout review. I will correct the editorial nits
in the next
version.

- 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.
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>