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

[Lishan Li <[e-mail]>]

Dear Jinmei,

Please see inline.

2016-01-19 3:08 GMT+08:00 神明達哉 <[e-mail]>:

> At Sun, 17 Jan 2016 16:52:38 +0800 (CST),
> "Lishan Li" <[e-mail]> wrote:
>
> > >- 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?
>
> Maybe my points weren't clear enough.  First off, I didn't talk about
> timestamp at all; let's focus on the signature option.  Secondly, I
> don't see why encryption is not enough in the server-to-client case
> for message integrity.


>
[LS]:In the server-to-client case, the Reply message is transmitted in
cleartext not encryption, which contains the server's certificate
information.
So I think that it is better to contain the signature option for the Reply
message integrity check.
Looking forward to your further guidance.

> >- 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?
>
> It's probably okay.  I think it should be described more explicitly.
>
> [LS]: Will add the explicit description.

> >- 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.
>
> I don't understand that.  We should still be able to manually
> configure public keys on clients and servers (see also the
> applicability discussion), so simply because we removed the TOFU mode
> shouldn't me we should remove the public key option.
>
> [LS]: If the device is pre-configured with public key not certificate, it
can
generate the self-signed certificate for authentication. So, I think that
the certificate option is enough for authentication.
Looking forward to your further guidance.

> >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.
> > [...]
>
> This one still has the same problem.  Why does this method
> (=Reconfigure Key Authentication Protocol) provide little message
> integrity or source integrity?
>
> [LS]: The authentication mechanism defined in RFC3315 can provide for the
authentication of the client and server, and for the integrity of messages
delivered between DHCPv6 clients and servers.
So, how about the following text:
[...]  However, this method protects only the Reconfigure message. In
addition,
the key is transmitted in plaintext to the client in earlier exchanges.
[...]

> >- 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.
>
> Dropping the message is fine, but then what?  Should the client keep
> waiting for an expected reply and then possibly retransmit its message?
>
> [LS]: If the Reply message is dropped and there is no other authenticated
DHCPv6 server, then the scenario is no authenticated DHCPv6 server. And
then the client's following behavior is:
If there are no authenticated DHCPv6 servers or existing servers failed
authentication, the client behavior is policy specific.  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.4: in general, I think this section is still quite weak
> > >  and/or insufficient. [...]
> >
> > >
> > [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.
>
> I'd first like to know whether we (the wg in general including
> yourself) agree on my points and understanding of previous feedback.
> On top of that, I'll probably offer my own proposed text on these.
>
> [LS]: I agree with your proposed point. Looking forward to your proposed
text on this.

> >- 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?
>
> This point isn't answered.
>
> [LS]: In the secure DHCPv6 deployment draft, we mainly consider two
different
scenario: stable client with strict security policy and roaming client with
loose
security policy.
For the stable clients, such as the desktop PC in enterprise network, they
are
pre-configured the trusted servers' certificates or the trusted CAs'
certificates
for server authentication.
For the roaming clients, such as the smart phones in coffee room, it is
difficult
to be pre-configured the trusted certificates for authentication.
What do you think of the scenario classification?

> >- 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.
>
> We are probably talking about different things.  My question and point
> are whether timestamp and signature are specified in the "option
> request option".  Your response doesn't seem to answer that point.
>
> [LS]: The certificate option "MUST" be contained, and the signature option
and timestamp option "SHOULD" be contained.
Have I got what you mean?

> >- 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.
>
> See above.
> >
> >
> > >- 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.
>
> Deleting it is probably fine, but it doesn't answer my point.  We'll
> still need to answer what the client should do if the server indicates
> a failure in decryption (which is equivalent to SignatureFail).
>
> [LS]: In the current version, we consider the scenario where the server
indicates a failure in authentication. If the message fails certificate
validation, the DHCPv6 server SHOULD reply with an AuthenticationFail
error status code to the client.
So, you suggest to define a new error status code: DecryptionFail error
status code. If the DHCPv6 server fails decryption, the DHCPv6 server
SHOULD reply with an DecryptionFail error status code to the client.
Could you please check whether my understanding is correct?

> >- 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.  [...]
>
> Doesn't the original text (also) cover the case where Timestamp is
> included but the check on it fails?  If so, the new text now loses its
> original sense.
>
> [LS]: The original text covers the scenario where the timestamp check
fails. But the lack of timestamp and timestamp check failure are two
different scenario. So I don't understand why the new text now loses
its original sense. Looking forward to the further guidance.

> >- 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.
>
> It should also describe the rationale.  Also, we might consider using
> an RFC2119 keyword, either SHOULD NOT or MUST NOT.


[LS]: How about the following text；
If Secure DHCPv6 is used, the DHCPv6 message is encrypted in a way that
the authentication mechanism defined in RFC3315 don't understand. So, the
Authentication option SHOULD NOT be used if Secure DHCPv6 is applied.

Best Regards,
Lishan