Subject: [dhcwg] Secure DHCPv6 Deployment Consideration - proposed text

From: Sheng Jiang <[email-masked]>
Date: Tue, 25 Aug 2015 02:56:40 +0000

Hi, dhc,

During the latest AD review and security review, we have received many constructive comments. Although some general security issues are out of scope, we have integrated most of comments. One of the major concern is regarding to the deployment/applicability, particularly the PKI availability. Therefore, we have proposed the below text for a new section, deployment consideration. Your review and comments are appreciated.

Deployment Consideration

This document defines two authentication models: authentication based on public key certificates and PKI; and authentication based on leap of faith to public keys. It is worth noticing that in real deployment, the two models may be mixed together on the serve to be able to serve both stable clients and roaming clients, which may be treated with different service policies.

1. Authentication based on certificate and PKI

This model would mainly be used in the scenarios such as enterprise networks where tight security policies are applied and the clients are stable terminal devices. It would provide tighter security protection because both server and client can be authenticated based on a common trusted CA. As with this precondition, this model would require more complicated pre-configuration, particularly on the client side.

The server can always be considered to have connectivity to authorized CA and verify the clients’ certificate. Because the client may have to validate the authentication in the condition of without connectivity wider than link-local，the verification on the client devices may have to be performed locally. One or multiple certificates, which form a certification path [RFC5280], need to be deployed in the client in order to verify the certificate sent from the server and so perform the authentication. Besides the certificate used to prove the identity, the server may also need to provide additional certificates to help the client generate a certificate chain from the certificates deployed in the client to the certificate.

2.  Authentication based on leap of faith

This model would mainly be the scenarios that the security policies are loss and the clients may roam, such as public coffee shops. Therefore, the PKI could not be deployed in advance. This model requires minimum pre-configuration - server and client has a public/private key pair. A signed certificate could be an equivalent to a public key in this model.

The Leap of faith model by itself could not prevent a client to trust a malicious server or a server to trust a malicious client at the beginning of the first session. But the leap of faith mechanism guarantees the subsequent messages are sent by the same previous sender, and therefore narrows the time window that an attacker can perform attacks. Also, the message integrity is provided.

The server may constrain the resource and access rights to clients who is based on leap of faith model to avoid potential malicious attacks

Additional mechanisms to justify the trust relationship, such as requiring human intervention at the point of the leap of faith on the client or the server may run some algorithm to detect malicious behaviors from clients.

Best regards,

Sheng + Dacheng

---

From: 神明達哉 <[email-masked]>
Date: Tue, 25 Aug 2015 11:42:27 -0700

At Tue, 25 Aug 2015 02:56:40 +0000,
Sheng Jiang <[email-masked]> wrote:

> During the latest AD review and security review, we have received
> many constructive comments. Although some general security issues
> are out of scope, we have integrated most of comments. One of the
> major concern is regarding to the deployment/applicability,
> particularly the PKI availability. Therefore, we have proposed the
> below text for a new section, deployment consideration. Your review
> and comments are appreciated.

> Deployment Consideration
>
> This document defines two authentication models: authentication
> based on public key certificates and PKI; and authentication based
> on leap of faith to public keys. It is worth noticing that in real
> deployment, the two models may be mixed together on the serve to be
> able to serve both stable clients and roaming clients, which may be
> treated with different service policies.

I thought we chose to use TOFU (Trust-on-first-use) instead of "leap
of faith".  Is it intentional this text now uses the latter?

> This model would mainly be used in the scenarios such as enterprise
> networks where tight security policies are applied and the clients
> are stable terminal devices. It would provide tighter security
> protection because both server and client can be authenticated based
> on a common trusted CA. As with this precondition, this model would
> require more complicated pre-configuration, particularly on the
> client side.

Once we say "require more complicated pre-configuration", we'll lose
the most boasted advantage of this proposal: ease of deployment.  So
text like this will also need to answer "then, why do we bother
to introduce a new mechanism?"  I thought this question is one of the
common feedback (or pushback) from post-WGLC reviews, and will have to
be addressed in some way.

In my understanding, the honest answer is that "we think public-key
based mechanism is just more modern, that's it".  We could also note a
relatively minor security advantage in cases like silently stolen
client keys on the server.  There might also be cases where we can
show this approach actually improves deployability, but from the
lessons I learned from previous discussions I suspect such discussions
will be speculative at best, and will be unlikely to satisfy the
reviewers.

> The server can always be considered to have connectivity to
> authorized CA and verify the clients’ certificate. Because the
> client may have to validate the authentication in the condition of
> without connectivity wider than link-local，the verification on the
> client devices may have to be performed locally. One or multiple
> certificates, which form a certification path [RFC5280], need to be
> deployed in the client in order to verify the certificate sent from
> the server and so perform the authentication. Besides the
> certificate used to prove the identity, the server may also need to
> provide additional certificates to help the client generate a
> certificate chain from the certificates deployed in the client to
> the certificate.

I'm not sure if this paragraph directly and clearly addresses the
concern regarding how the client validates the certificate or public
key.  I suspect we'll need to discuss something more specific, like
how a client could pre-cache a complete certification path with
discussions on its own risks.

> This model would mainly be the scenarios that the security policies
> are loss and the clients may roam, such as public coffee
> shops. Therefore, the PKI could not be deployed in advance. This
> model requires minimum pre-configuration - server and client has a
> public/private key pair. A signed certificate could be an equivalent
> to a public key in this model.

Several reviewers have already pointed out that TOFU (or leap of
faith) is not suitable for coffee shop cases (and I agree with them).
My personal answer to them is that a more appropriate case would be
initial setup in a closed home network.  We might also say TOFU can be
used for hijack prevention.

> The Leap of faith model by itself could not prevent a client to
> trust a malicious server or a server to trust a malicious client at
> the beginning of the first session. But the leap of faith mechanism
> guarantees the subsequent messages are sent by the same previous
> sender, and therefore narrows the time window that an attacker can
> perform attacks. Also, the message integrity is provided.

what does "also, the message integrity is provided" mean in this
context?

> Additional mechanisms to justify the trust relationship, such as
> requiring human intervention at the point of the leap of faith on
> the client or the server may run some algorithm to detect malicious
> behaviors from clients.

"some algorithm to detect malicious behaviors from clients":
specifically what does this mean?

If I remember correctly, there was also a concern about privacy leak
by exchanging clients' public keys or certificates.  Do we have
another section to address this point?

Finally, a couple of editorial nits:

> the two models may be mixed together on the serve to...
s/on the serve/on the server/?

> The Leap of faith model by itself could not prevent a client to
> trust a malicious server or a server to trust a malicious client...

s/to trust/from trusting/ (2 occurrences).

--
JINMEI, Tatuya

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 26 Aug 2015 08:59:27 +0000

Hi, Jin,

My replies in lines.

>of faith".  Is it intentional this text now uses the latter?

Yes, TOFU. I will check the consistency when integrating these text into the document.

>will be speculative at best, and will be unlikely to satisfy the

PKI-based deployment is easier than symmetric key mechanism, particularly when there are multiple servers. PKI is more modern and common. It may be combined with other protocol deployment, not only DHCPv6. I will try to enhance the text, but such discussion actually belong to section 3, "Security Overview of DHCPv6".

>discussions on its own risks.

The establish, deployment and its risks of certification path is another generic issues, which a) is out of scope, it is secure dhcpv6 specific, b) it is addressed in the referred RFC.

>used for hijack prevention.

Let's see what the reviewers may response. I can certainly modify the example. But I am not sure what else is the best model for coffee shop.

>what does "also, the message integrity is provided" mean in this

It means the receiver can validate the message does not modified in the middle.

>> The server may constrain the resource and access rights to clients who is
>based on leap of faith model to avoid potential malicious attacks
>>

I believe this has been mentioned, although not solved, by the last paragraph of section 7, Security Considerations.

>s/to trust/from trusting/ (2 occurrences).

Thanks. Corrected.

Regards,

Sheng

---

From: "Dacheng Zhang" <[email-masked]>
Date: Thu, 27 Aug 2015 18:23:49 +0800

在 15-8-26 下午4:59， "dhcwg on behalf of Sheng Jiang"
<[email-masked]
on behalf of [email-masked]> 写入:

>PKI-based deployment is easier than symmetric key mechanism, particularly
>when there are multiple servers. PKI is more modern and common. It may be
>combined with other protocol deployment, not only DHCPv6. I will try to
>enhance the text, but such discussion actually belong to section 3,
>"Security Overview of DHCPv6".

In addition, the capability of generating cert chains can provide
additional flexibility than the solution based on pre-shared keys.

>The establish, deployment and its risks of certification path is another
>generic issues, which a) is out of scope, it is secure dhcpv6 specific,
>b) it is addressed in the referred RFC.
>
>Let's see what the reviewers may response. I can certainly modify the
>example. But I am not sure what else is the best model for coffee shop.

Maybe we could assume the customer needs to input the wifi password on the
wall first.... 

>I believe this has been mentioned, although not solved, by the last
>paragraph of section 7, Security Considerations.
>
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dhcwg

---

From: 神明達哉 <[email-masked]>
Date: Thu, 27 Aug 2015 10:45:16 -0700

At Wed, 26 Aug 2015 08:59:27 +0000,

> >be addressed in some way.
[...]
> PKI-based deployment is easier than symmetric key mechanism,
> particularly when there are multiple servers. PKI is more modern and
> common. It may be combined with other protocol deployment, not only
> DHCPv6. I will try to enhance the text, but such discussion actually
> belong to section 3, "Security Overview of DHCPv6".

If we can convincingly explain a PKI-based deployment is easier
without showing specific details and without saying something
speculative, that would be great.  I'm personally pessimistic about
that possibility, but if you think you can do it, please go ahead.

> The establish, deployment and its risks of certification path is another generic issues, which a) is out of scope, it is secure dhcpv6 specific, b) it is addressed in the referred RFC.

(Do you mean it is NOT secure dhcpv6 specific?)

I, for one, wouldn't be opposed to not explaining this point in more
detail, but my understanding of the feedback was that reviewers didn't
buy the argument for dismissing this as "out of scope"; I also thought
they considered there is some DHCP specific points in that this is a
kind of chicken-and-egg problem.  Personally I suspect we cannot
pretend it's not our problem.  But again, this is a matter of how
the reviewers will react to this approach.  If you're confident you
can convince them with this argument, I just with you good luck:-)

> Let's see what the reviewers may response. I can certainly modify the example. But I am not sure what else is the best model for coffee shop.

We can't oversell this thing.  If there's a scenario where no model
with the secure DHCPv6 looks viable, we just can't say it can be used
for the scenario, at least with the boasted advantage of easier
deployment.  (Note that I'm not necessarily pushing the other
examples; I'm only saying we have to be honest).

> It means the receiver can validate the message does not modified in the middle.

After the first session, right? (On the first use MITM attack is
possible).  And then it seems to me to say the obvious; the only
difference between TOFU and non-TOFU is in its first session, and once
the trust relationship is established all features of the non-TOFU
case including integrity are provided.  So, personally, I'd just
remove this sentence since it's rather confusing in this context.

> >specifically what does this mean?

This point still seems to be open.

--
JINMEI, Tatuya