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

From: Lishan Li <[email-masked]>
Date: Tue, 23 Feb 2016 10:45:40 +0800

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

> At Thu, 21 Jan 2016 23:27:03 +0800,
> Lishan Li <[email-masked]> 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

---

From: 神明達哉 <[email-masked]>
Date: Wed, 24 Feb 2016 09:56:20 -0800

(I've removed [email-masked])

At Tue, 23 Feb 2016 10:45:40 +0800,

> signature and timestamp option are not contained.

Okay.  So focusing on the Reply message (#2): my point was:

- in effect, its only content is the certificate (or public key).
- the recipient is already expected to validate this only content
  directly (by comparing it with locally pre-configured info, by using
  a PKI, etc), so we do not necessarily need to provide additional
  integrity protection for it by signing the message.
- on the other hand, if we eliminate the signing and the signature
  option from this, we'll completely eliminate this option from the
  protocol.  This will help make the protocol simpler and reduce
  development costs.

If you still disagree, perhaps it helps if you can show a specific
attack vector because of the lack of the signature.

> option as the before secure DHCPv6 version.

No, I just didn't see why the public key option was removed (the
explanation regarding TOFU didn't make sense to me).  As I already
said, I'm not necessarily opposed to removing it if there's a
convincing reason that can outweigh its cons.

> message following normal retransmission routines defined in [RFC3315].

Not sure if you are correct:-), but, yes, that answers my question.
Whether this behavior makes most sense is a different question, on
which I don't yet have a particular idea.  Maybe I should first see a
revised draft in full text.

> > https://mailarchive.ietf.org/arch/msg/dhcwg/-tZBpeMs-EiVyMm0MLBpj3dFYNI

Reminder: this is still open.

> forward to your guidance.

I'd simply expect the usual behavior: the server will return a Reply
(obviously) without the requested information (which, in this case,
the certificate or public key option).  I don't think we can eliminate
the possibility of downgrade attack by an on-path attacker, however we
specify the behavior in this case.

--
jinmei

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 24 Feb 2016 18:20:34 +0000

Regarding the last point, Jinmei wrote:

"I'd simply expect the usual behavior: the server will return a Reply
(obviously) without the requested information (which, in this case, the certificate or public key option).  I don't think we can eliminate the possibility of downgrade attack by an on-path attacker, however we specify the behavior in this case."

Yes, an unchanged server would respond to the Information-Request with likely a minimal Reply (just server-duid). It is also possible that there are servers that don't Reply in this case (since providing nothing might be argued as fairly useless).

You might want to update the section 6.  DHCPv6 Client Behavior text below:

   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 connect using
   plain, unencrypted DHCPv6, repeat the server discovery process after
   certain delay or attempt to connect to a different network.  The
   client MUST NOT conduct the server discovery process immediately to
   avoid the packet storm.

To indicate that a client should retry a number of times before taking some alternative action (depending on policy) - that would make it more difficult for a rogue server to beat out a busy "real" server.

BTW: A simple way to avoid the packet storm is to just not cancel the retransmission timer unless a "good" Reply is received; and just let the retransmission timer (with back off as per RFC 3315 section 18.1.5.) handle it.

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of ????
Sent: Wednesday, February 24, 2016 12:56 PM
To: Lishan Li <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [dhcwg] comments on draft-ietf-dhc-sedhcpv6-10.txt

At Tue, 23 Feb 2016 10:45:40 +0800,
Lishan Li <[email-masked]> wrote:

> > 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
> >
> > If so, do you at least agree that it makes almost no sense to 
> > include the explicit separate signature in messages 3 and 4?
> >
> 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?

If you still disagree, perhaps it helps if you can show a specific attack vector because of the lack of the signature.

> > cover all such discussions and reach consensus, but I don't think 
> > I've seen it yet.
> >
> discussions and consensus, the better way for us is to add the public 
> key option as the before secure DHCPv6 version.
> Am I correct?

No, I just didn't see why the public key option was removed (the explanation regarding TOFU didn't make sense to me).  As I already said, I'm not necessarily opposed to removing it if there's a convincing reason that can outweigh its cons.

> > question was about what the client should do if it sees that code 
> > (or whatever signal that indicates this kind of failure).
> >
> SignatureFail. So if the client sees that code, the client MAY resend 
> the message following normal retransmission routines defined in [RFC3315].
> Am I correct?

Not sure if you are correct:-), but, yes, that answers my question.
Whether this behavior makes most sense is a different question, on which I don't yet have a particular idea.  Maybe I should first see a revised draft in full text.

> 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'd simply expect the usual behavior: the server will return a Reply
(obviously) without the requested information (which, in this case, the certificate or public key option).  I don't think we can eliminate the possibility of downgrade attack by an on-path attacker, however we specify the behavior in this case.

--
jinmei

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Lishan Li <[email-masked]>
Date: Thu, 25 Feb 2016 20:45:16 +0800

2016-02-25 1:56 GMT+08:00 神明達哉 <[email-masked]>:

> [LS]: Agree. But if we don't need the signature option, then the timestamp
option makes no sense, which is used to defend against anti-replay
attack before.

> [LS]: The self-signed certificate is the argument of the remove of the
public
key option. And we also need to supply some text to illustrate that it can
outweigh its cons. For the drawback of the method, the size of the DHCPv6
message is increased when we actually only need the public key, not the
certificate. However, the size of the X.509 certificate is not very large,
such as 1KB, which will not cause IPv6 fragment and other problem.

> [LS]: Will participate in the discussion.

> [LS]: Thanks a lot for your guidance. I think that Bernie's reply has
solved this problem.

Best Regards,
Lishan

---

From: 神明達哉 <[email-masked]>
Date: Thu, 25 Feb 2016 09:53:29 -0800

At Thu, 25 Feb 2016 20:45:16 +0800,

> option makes no sense, which is used to defend against anti-replay

For #2, correct.  We'll still need the timestamp option, though, for
the anti-reply protection of encrypted messages. (We might be able to
make it simpler such as a trivial sequence number, exploiting the fact
that the message is encrypted.  In that sense, it may not have to be a
"time stamp").

[...]
> such as 1KB, which will not cause IPv6 fragment and other problem.

Repeating my previous point just to make it sure that we are on the
same page: the argument that a self-signed certificate should make a
public key option redundant isn't new in our recent changes.  So I'd
wonder why we are now bothering it.  If this is a completely new
attempt of cleanup, I suggest making it very clear (i.e., it has
nothing to do with mandated encryption etc) and discussing it
accordingly.

--
JINMEI, Tatuya

---

From: Lishan Li <[email-masked]>
Date: Fri, 26 Feb 2016 15:30:05 +0800

2016-02-26 1:53 GMT+08:00 神明達哉 <[email-masked]>:

> [LS]: Agree. For the Reply message (#2), it does not contain the timestamp
option
because of the cleartext transmission. For the subsequent encrypted
message, the
timestamp option is used for message integrity check.
In general, in order to defend against the anti-replay attack, the
timestamp option
is used. As you said, the trivial sequence number can make it more simpler.
But if
the trivial sequence number is use, we need to define the format of the
trivial
sequence number. If the timestamp option is used, we can use the format
defined in
Section 5.3.1 of RFC3971.

> [LS]: The self-signed certificate make the DHCPv6 option redundant, which
is not a new problem caused by our defined mechanism. So we don't need to
bother it. Could you please check whether my understanding is correct?

Best Regards,
Lishan

---

From: 神明達哉 <[email-masked]>
Date: Fri, 26 Feb 2016 09:40:41 -0800

At Fri, 26 Feb 2016 15:30:05 +0800,

> bother it. Could you please check whether my understanding is correct?

I didn't mean we "don't need to bother".  My major point is that this
change was confusing:

- We did a very substantial change since 08: merging encryption and
  mandating it (as well as removing TOFU)
- public key option was also removed as well without any explanation
  of why
- so I asked why, and your first response (it's because of the removal
  of TOFU) didn't make sense to me: the argument with self-signed
  certificate can apply with or without TOFU.

That's why we have this conversation.

Now, on clarifying these, I don't yet have a particular opinion on
whether to remove the public key option.  But my suggestion is: if you
want to make this change, raise this issue separately on this list
with your rationale, get consensus, and apply it to a subsequent
version of the draft.

--
JINMEI, Tatuya