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

[Lishan Li <[e-mail]>]

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

> At Thu, 21 Jan 2016 23:27:03 +0800,
> Lishan Li <[e-mail]> wrote:
>
> > > 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.
>
> I'm still not sure if my point was made clear...so let me be more
> specific: in the following message exchanges:
>
> 1. Information-request from client to server(s)
> 2. Reply to the Information-request from server(s) to client
> 3. Encryption-Query from client to server
> 4. Encryption-Response from server to client
>
> did you mean the Reply message of exchange #2?
>
> If so, do you at least agree that it makes almost no sense to include
> the explicit separate signature in messages 3 and 4?
>
> [LS]: Yes, I mean the Reply message of exchange #2. The reply message
contains the signature option and timestamp option for message integrity
check. In the #3 and #4 messages, the DHCPv6 messages are encrypted, so the
signature and timestamp option are not contained.
What do you think of it?

> > > [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.
>
> Right, but this argument also holds even if we have TOFU...
>
> > So, I think that
> > the certificate option is enough for authentication.
> > Looking forward to your further guidance.
>
> ...so these don't explain why we should now remove the public key
> option.  One obvious, though possibly relatively minor, drawback of
> only having a certificate is that it will make the message size even
> bigger when we actually only need the public key.
>
> I'm not necessarily opposed to removing the public key option if we
> cover all such discussions and reach consensus, but I don't think I've
> seen it yet.
>
> [LS]: In consideration of the support of TOFU and the add of all such
discussions and consensus, the better way for us is to add the public key
option as the before secure DHCPv6 version.
Am I correct?

> > >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.
> [...]
> > > 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.
> > [...]
>
> I'm not sure if my point was really taken, but I'm okay with removing
> the text in question anyway.  I'd add "...and so this method is
> vulnerable to active attacks" to the second sentence.
>
> [LS]: Agree.


> > > >- Section 5.4: in general, I think this section is still quite weak
> > > > >  and/or insufficient. [...]
> [...]
> > > 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.
>
> Okay, will do separately.
>
> > > >- 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?
>
> I basically just asked the definition of "stable".  From the above
> text it seems to mean DHCP clients like desktop PCs, excluding laptops
> and smart phones with a BYOD policy.  If so, I'd say "In enterprise
> network, the security policy is strict and the clients are stable
> terminals" is not a realistic statement.
>
> [LS]: Agree. Will modify 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.
> > >
> > > 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?
>
> I'm afraid not.  I talked about option request options, but your
> answer seems to talk about something else.  Let's be very specific:
> according to the original draft text, the initial Information-request
> message MUST contain an option request option whose codes fields
> include:
>
> 1. code of certificate option
> 2. code of signature option
> 3. code of timestamp option
>
> What I tried to say is that 2 and 3 are redundant, since requesting a
> certificate option should imply a request of signature and timestamp
> option (in this context I'm forgetting the other discussion of whether
> we really need the signature option).
>
> [LS]: So we don't need to specify whether the ORO contains the signature
and timestamp options.
Because of the certificate option request, the Reply message (#2 message)
will contain the signature and timestamp options.

> > > >- 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?
>
> Introducing a new error code is related but a minor point.  My
> question was about what the client should do if it sees that code (or
> whatever signal that indicates this kind of failure).
>
[LS]: As you said before, the DecryptionFail failure is equivalent to
SignatureFail. So if the client sees that code, the client MAY resend the
message following normal retransmission routines defined in [RFC3315].
Am I 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.
>
> Let me rephrase my question: consider the following two cases:
>
> 1. the client includes the timestamp option but server fails to
>    validate it
> 2. the client doesn't include the timestamp option but server wanted
>    to have it
>
> my original question was whether TimestampFail is included in the
> response from the server for both cases.  I assumed the answer was
> yes.  Am I correct?  If I am, your latest text seemed to lose the
> coverage for case 1 since it only talks about case 2: "If the server
> rejects such a message without Timestamp option".  Is it clearer?
>
> [LS]: I have got what you mean. I will modify this sentence to cover the
two cases.

> > >- 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.
>
> I'd probably want to suggest something slightly different, but I'd
> like to first discuss whether we really need a signature option.
> Depending on the result of it this point may become even more moot.
> Note also that if we at least don't include the signature option in
> encrypted message, the coexistence issue doesn't exist in this case in
> the first place.
>
> [LS]: Agree. The signature option is not contained in encrypted message.
So the coexistence issue will not exist.


> p.s. there's another bigger open issue I separated from the rest of
> the discussions:
> https://mailarchive.ietf.org/arch/msg/dhcwg/-tZBpeMs-EiVyMm0MLBpj3dFYNI
>
> [LS]: Another open isssue is that:
If the server receives the Information-request message but it does not
support this work, what should the server do?
In my opinion, if the server don't support this work, it has two choices:
1. drop the received Information-request message;
In this way, the client will not receive any message which illustrate the
server don't support secure DHCPv6. If there is no authenticated DHCPv6
server, the client may resend the Information-request message;
2. send the Reply message with the corresponding error status code to the
client；
This way will introduce the downgrade attack, a third party may send the
Reply message with the corresponding error status code. And then the DHCPv6
configuration process may be unsecured.
I prefer the first one solution. Which one would you prefer? Looking
forward to your guidance.

Best Regards,
Lishan