Subject: [saag] Fw:Fw:New Version Notification for draft-cui-dhc-dhcpv6-encryption-02.txt

From: "Lishan Li" <[email-masked]>
Date: Wed, 29 Jul 2015 13:43:29 +0800 (CST)

Dear all, 

We have submitted a new draft about DHCPv6 Authentication and Encryption mechanism. This draft discusses two possible solutions to achieve the server authentication and encryption between the DHCPv6 client and server. 
In the IETF93, the DHC WG suggests us to obtain some comments from some secure experts. Could you please review the draft and any comments are welcome. I am really looking forward to your guidance/suggestions! Thanks in advance!

Best Regards,
Lishan-------- Forwarding messages --------
From: [email-masked]
Date: 2015-07-28 23:08:52
To:  "Jianping Wu" <[email-masked]>,"Yiu Lee" <[email-masked]>,"Yong Cui" <[email-masked]>,"Lishan Li" <[email-masked]>,"Jianping Wu" <[email-masked]>,"Lishan Li" <[email-masked]>,"Yiu Lee" <[email-masked]>,"Yong Cui" <[email-masked]>
Subject: New Version Notification for draft-cui-dhc-dhcpv6-encryption-02.txt

A new version of I-D, draft-cui-dhc-dhcpv6-encryption-02.txt
has been successfully submitted by Lishan Li and posted to the
IETF repository.

Name:		draft-cui-dhc-dhcpv6-encryption
Revision:	02
Title:		Authentication and Encryption Mechanism for DHCPv6
Document date:	2015-07-28
Group:		Individual Submission
Pages:		13
URL:            https://www.ietf.org/internet-drafts/draft-cui-dhc-dhcpv6-encryption-02.txt
Status:         https://datatracker.ietf.org/doc/draft-cui-dhc-dhcpv6-encryption/
Htmlized:       https://tools.ietf.org/html/draft-cui-dhc-dhcpv6-encryption-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-cui-dhc-dhcpv6-encryption-02

Abstract:
   The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables
   DHCPv6 servers to configure network parameters.  However, due to the
   unsecured nature, various critical identifiers used in DHCPv6 are
   vulnerable to several types of attacks, particularly pervasive
   monitoring.  This document provides a mechanism to secure DHCPv6
   messages, which achieves the server authentication and encryption
   between the DHCPv6 client and server.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Randy Bush <[email-masked]>
Date: Wed, 29 Jul 2015 16:16:37 +0900

this document, like the v4 dhc document, is all mechanism with no clear
statement of applicability.  neither document discusses key distribution
and management, the usual critical fulcrum of symmetric and asymetric
key-based mechanisms.  e.g. how does this work in a coffee shop?  and
the answer better not be tofu and leap of faith.

randy

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 29 Jul 2015 11:10:26 +0100

Hi Randy,

> the answer better not be tofu and leap of faith.

I'm not keen on that kind of argument tbh where we say "show me your
threat model and btw <this> better not be it." Can you Randy show me
a good analysis of how different kinds of key management have which
consequences for DHCP authentication and confidentiality? I don't
believe I've seen that documented myself but I've not spent time
looking specifically for it. In this case the authors are looking to
us for help with getting that done, and I don't believe poking them
like that is either useful or fair, sorry.

As for TOFU, I do believe there may be a role for that in DHCP. There
are cases where I informally start to use a sadly-open WiFi n/w and
continue to use that for a few days or sporadically  (e.g. a friend's
guest WiFi) and in such cases TOFU could provide some protection to
some or maybe most of the population using such a network. (And even
if my friend has WPA turned on, TOFU for DHCP might protect me from
their clever kid who was in school when I arrived;-) It'd also not be
reasonable to expect my friend to have asked permission from a CA
before setting up the guest WiFi.

And yes, there are enterprise cases where a local PKI could and maybe
should be used instead. And yes one could argue that WiFi roaming
arrangements and large franchises (e.g. starbucks) should find a way
to put certs in place, but I'm not convinced that doing nothing until
we reach that goal is reasonable. I am fairly convinced that always
requiring use of a PKI would result in fairly ubiquitous lack of use.

There may even be good arguments based on the nature of DHCP to the
effect that I'll have to accept what TOFU would tell me to reject, but
I also don't think I've seen that either. (When my putative friend
above buys a new AP/DHCP-server that would be an issue for either TOFU
or a PKI based answer, but perhaps not an insurmountable one in either
case.)

But we (the IETF) have a really bad history with DHCP security in that
RFC 3118 [1] is perhaps the most commonly cited unused security RFC.
One could I think claim it wins the security-BS contest for RFCs
even shoving the evil bit down into 2nd place;-)

Forty-seven (yes 47! [2]) other RFCs reference 3118 and that mostly
means pretending to provide security via a reference that the authors
fully know is BS. I have checked a number of times with such authors
and 3118 seems comprehensively unused. I only ever got one .mil type
person saying that they use it but he wasn't allowed say more. Nobody
else has ever told me that they can or do use 3118. In fact, in most
cases when I see a reference to 3118 as a security mechanism, I'll
put on a DISCUSS ballot to call the authors out for the BS. And in
many cases we find they just copied it from somewhere hoping it'd
shut-up the security ADs;-)

We can certainly improve on that sad state. And I would say that
TOFU is a credible part of that until evidence or detailed argument
to the contrary is produced, which you have yet to do.

S.

[1] https://tools.ietf.org/html/rfc3118
[2] http://www.arkko.com/tools/allstats/citations-rfc3118.html

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

---

From: Randy Bush <[email-masked]>
Date: Wed, 29 Jul 2015 20:40:28 +0900

TOFU is a bit oxymoronic, or certainly abuses 'trust'.  it is more like
You Undergo Big Attack.  it just gives you some assurance the attacker
is reproducible.  

but this is a tangent.  the point is that protocols which rely on
keying really need to nail the key distribution model(s).  

while tofu may be one, is it really one that security folk think the
ietf should advocate for set-up authenticity?  it's not how i want to
make the wsj; and coffee shop mitm will be in the wsj soon enough.

randy

---

From: "Lishan Li" <[email-masked]>
Date: Wed, 29 Jul 2015 21:25:28 +0800 (CST)

Dear Stephen,

Thanks very much for your kind reply. 
I am considering whether the "Opportunistic Security" can be used. The opportunistic security make use of the encryption more broadly, authentication is optional. What do you think of the opportunistic security?

Best Regards,
Lishan

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 29 Jul 2015 14:26:50 +0100

> keying really need to nail the key distribution model(s).  

I agree. But I think one of the issues here is that we don't
(afaik) have a worked out analysis of how various key
distribution models play with DHCP.

> make the wsj; and coffee shop mitm will be in the wsj soon enough.

Fair enough. OTOH, I don't think there will be one key
distribution model that will work well for all DHCP
deployments. So we may end up having to specify a set of
mechanisms, when each is suitable to use and the security
considerations resulting. That's a chunk of work, and a
chunk of work where these authors are looking for help.
I do hope someone's going to volunteer to help them with
that.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 29 Jul 2015 14:28:14 +0100

On 29/07/15 14:25, Lishan Li wrote:
> Dear Stephen,
> 
> 
> Thanks very much for your kind reply. I am considering whether the
> "Opportunistic Security" can be used. The opportunistic security make
> use of the encryption more broadly, authentication is optional. What
> do you think of the opportunistic security?

I think OS is a fine thing. I don't know for sure how or if
it's useful for DHCP though, since I'm yet another person
who's not done the analysis of that;-)

S.

> 
> 
> Best Regards, Lishan At 2015-07-29 18:10:26, "Stephen Farrell"
> <[email-masked]> wrote:
>> 
>> Hi Randy,
>> 
>>> this document, like the v4 dhc document, is all mechanism with no
>>> clear statement of applicability.  neither document discusses key
>>> distribution and management, the usual critical fulcrum of
>>> symmetric and asymetric key-based mechanisms.  e.g. how does this
>>> work in a coffee shop?  and the answer better not be tofu and
>>> leap of faith.
>> 
>> I'm not keen on that kind of argument tbh where we say "show me
>> your threat model and btw <this> better not be it." Can you Randy
>> show me a good analysis of how different kinds of key management
>> have which consequences for DHCP authentication and
>> confidentiality? I don't believe I've seen that documented myself
>> but I've not spent time looking specifically for it. In this case
>> the authors are looking to us for help with getting that done, and
>> I don't believe poking them like that is either useful or fair,
>> sorry.
>> 
>> As for TOFU, I do believe there may be a role for that in DHCP.
>> There are cases where I informally start to use a sadly-open WiFi
>> n/w and continue to use that for a few days or sporadically  (e.g.
>> a friend's guest WiFi) and in such cases TOFU could provide some
>> protection to some or maybe most of the population using such a
>> network. (And even if my friend has WPA turned on, TOFU for DHCP
>> might protect me from their clever kid who was in school when I
>> arrived;-) It'd also not be reasonable to expect my friend to have
>> asked permission from a CA before setting up the guest WiFi.
>> 
>> And yes, there are enterprise cases where a local PKI could and
>> maybe should be used instead. And yes one could argue that WiFi
>> roaming arrangements and large franchises (e.g. starbucks) should
>> find a way to put certs in place, but I'm not convinced that doing
>> nothing until we reach that goal is reasonable. I am fairly
>> convinced that always requiring use of a PKI would result in fairly
>> ubiquitous lack of use.
>> 
>> There may even be good arguments based on the nature of DHCP to
>> the effect that I'll have to accept what TOFU would tell me to
>> reject, but I also don't think I've seen that either. (When my
>> putative friend above buys a new AP/DHCP-server that would be an
>> issue for either TOFU or a PKI based answer, but perhaps not an
>> insurmountable one in either case.)
>> 
>> But we (the IETF) have a really bad history with DHCP security in
>> that RFC 3118 [1] is perhaps the most commonly cited unused
>> security RFC. One could I think claim it wins the security-BS
>> contest for RFCs even shoving the evil bit down into 2nd place;-)
>> 
>> Forty-seven (yes 47! [2]) other RFCs reference 3118 and that
>> mostly means pretending to provide security via a reference that
>> the authors fully know is BS. I have checked a number of times with
>> such authors and 3118 seems comprehensively unused. I only ever got
>> one .mil type person saying that they use it but he wasn't allowed
>> say more. Nobody else has ever told me that they can or do use
>> 3118. In fact, in most cases when I see a reference to 3118 as a
>> security mechanism, I'll put on a DISCUSS ballot to call the
>> authors out for the BS. And in many cases we find they just copied
>> it from somewhere hoping it'd shut-up the security ADs;-)
>> 
>> TOFU is a credible part of that until evidence or detailed
>> argument to the contrary is produced, which you have yet to do.
>> 
>> S.
>> 
>> [1] https://tools.ietf.org/html/rfc3118 [2]
>> http://www.arkko.com/tools/allstats/citations-rfc3118.html
>> 
>> 
>>> 
>>> randy
>>> 
>>> _______________________________________________ saag mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/saag
>>>

---

From: "Lishan Li" <[email-masked]>
Date: Wed, 29 Jul 2015 22:11:20 +0800 (CST)

Dear Stephen,

As you said, we can use TOFU for the current mechanism. And in the future, we can specifies a set of key distribution mechanism for the DHCP. Could you please check whether my understanding is correct?
Thanks very much for your guidance.

Best Regards,
Lishan

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 29 Jul 2015 15:19:30 +0100

On 29/07/15 15:11, Lishan Li wrote:
> Dear Stephen,
> 
> 
> As you said, we can use TOFU for the current mechanism. And in the
> future, we can specifies a set of key distribution mechanism for the
> DHCP. Could you please check whether my understanding is correct? 

So that *might* be the right answer, but it might not be. And
maybe it'll turn out to be right for DHCP server/service
authentication but not for other services. My main point is that
the analysis of the various key management schemes and DHCP
security services and DHCP deployments needs to be done before
we can be confident in saying which is the right thing to specify
now that might be deployed in reality.

We do I think have proof that symmetric keying for everything
fails, thanks to RFC3118, but for all the rest, as far as I know
we'd just be guessing right now.

Anyone volunteering to try help figure this out?

Cheers,
S.

> Best Regards, Lishan
>>> but this is a tangent.  the point is that protocols which rely
>>> on keying really need to nail the key distribution model(s).
>> 
>> (afaik) have a worked out analysis of how various key distribution
>> models play with DHCP.
>> 
>>> 
>>> while tofu may be one, is it really one that security folk think
>>> the ietf should advocate for set-up authenticity?  it's not how i
>>> want to make the wsj; and coffee shop mitm will be in the wsj
>>> soon enough.
>> 
>> Fair enough. OTOH, I don't think there will be one key distribution
>> model that will work well for all DHCP deployments. So we may end
>> up having to specify a set of mechanisms, when each is suitable to
>> use and the security considerations resulting. That's a chunk of
>> work, and a chunk of work where these authors are looking for
>> help. I do hope someone's going to volunteer to help them with 
>> that.
>> 
>> S.
>> 
>> 
>>> 
>>> randy
>>> 
>>> 
>> 
>> _______________________________________________ saag mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/saag

---

From: Randy Bush <[email-masked]>
Date: Thu, 30 Jul 2015 04:47:53 +0900

> I agree. But I think one of the issues here is that we don't (afaik)
> have a worked out analysis of how various key distribution models play
> with DHCP.
> model that will work well for all DHCP deployments.

which is why i said "(s)" above.

> So we may end up having to specify a set of mechanisms, when each is
> suitable to use and the security considerations resulting. That's a
> chunk of work, and a chunk of work where these authors are looking for
> help.  I do hope someone's going to volunteer to help them with that.

the problem is, as i said in the meeting, we have a poor track record
here[0].  not a lot of good examples from which to steal.  and i am not
sure picking on dhcp is a good iconic example.  have you looked at the
anima wg?

but back to picking on dhcp, :)

within an enterprise, one is tempted to suggest enterprise-controlled
credential distribution; i get a cert (or whatever) oob to let my laptop
authenticate the dhcp service and vice versa.  but enterprises are
seeing a lot of byod, and i am not sure how they are dealing with that.
do they really want to authenticate all mobiles?

in the coffee shop, one would like the mobile device to be given the
dhcp server's credentials out of band; i suggested a QR code on the wall
as one (i.e. there could be others) example.  and, unlike the
enterprise, i think the mobile device should reveal as little as
possible about itself.

bottom line: i do not think there are easy solutions in the introduction
space.  but it is our responsibility.  and i am trying to think about
it and others should too.

randy

--

[0] - i am remonded of the plethora of documents with insecure
      transports where the sec cons says "use ipsec" with no hint about
      keying, how the upper layer can even tell if ipsec is being used,
      ...

---

From: Christian Huitema <[email-masked]>
Date: Thu, 30 Jul 2015 00:17:30 +0000

On Wednesday, July 29, 2015 12:48 PM, Randy Bush wrote:
> within an enterprise, one is tempted to suggest enterprise-controlled credential
> distribution; i get a cert (or whatever) oob to let my laptop authenticate the
> dhcp service and vice versa.  but enterprises are seeing a lot of byod, and i am
> not sure how they are dealing with that.
> in the coffee shop, one would like the mobile device to be given the dhcp
> server's credentials out of band; i suggested a QR code on the wall as one (i.e.
> there could be others) example.  and, unlike the enterprise, i think the mobile
> device should reveal as little as possible about itself.
> 
> bottom line: i do not think there are easy solutions in the introduction space.
> but it is our responsibility.  and i am trying to think about it and others should
> too.

I sent private comments to the draft authors already, mostly about applicability issues, and mostly in line with Randy's comments.

IMHO this draft has a narrow applicability, which depends mostly on whether the client trusts the network. In the cases where the client does not trust the network, I believe attempting DHCP encryption does more harm than good.  The point is, DHCP encryption hides some of the DHCP parameters from parties on the link, but it also reveals the client identity as part of the key negotiation -- or in any case it reveals "parts" of that identity. At the same time, in the absence of pre-established trust, encryption does not really protect against on-link attackers, since they can spoof the server. In the "random coffee shop" scenario, the actual privacy harm is a bad bargain for the dubious security gain. In such scenario, I would recommend data minimization, e.g., a combination of randomized MAC Addresses and the DHCP anonymity profile.

Even in the "trusted network" scenario, the gain is only apparent in the absence of link-layer protection. For example, enterprise Wi-Fi networks typically use 802.1x and EAP to negotiate a link-layer encryption key specific to the client. This goes a long way towards protecting all the link traffic, including DHCP. Clearly there is a residual risk of on-line attackers, such as a local computer owned by a virus. That risk is generally mitigated by filters in the switches, restricting the sending of DHCP and RA packets. DHCP encryption would be useful if it was easier to deploy than those filters, and more secure.

So we are left with the application domain of "trusted networks" that do not implement link-layer protection. In those networks, DHCP encryption provide some privacy benefits, by hiding the value of identifiers and configuration parameters.

-- Christian Huitema

---

From: "Lishan Li" <[email-masked]>
Date: Thu, 30 Jul 2015 16:21:01 +0800 (CST)

Dear Christian,

Thanks for your comments. Please see inline.

[Lishan]:  For the client identity reveal problem, Ralph and Jinmei examined the same problem in the original design. In the 01 version, we have solved the problem. And according to Ralph's suggestion, we currently adopt a scheme in which the server offers its certificate first, and then the client encrypt all of its traffic with the selected server's key, so that the message can only be decoded by the specific server. 
For the spoofing attack problem, our mechanism mainly focus on the client privacy protection. 
And I am sorry not to understand the "dubious security gain", could you please explain it more detail? Thanks!

[Lishan]: The link-layer encryption 802.1x and EAP you mentioned is only designed for the Wi-Fi network. For the general scenario, such as wired environment, the DHCP encryption is needed. 

>So we are left with the application domain of "trusted networks" that do not implement link-layer protection. In those networks, DHCP encryption provide some privacy benefits, by hiding the value of…
[Lishan]: I cannot agree with you. Whatever in the "trusted networks" or "untrusted networks", DHCPv6 encryption can both achieve the server authentication and encryption to protect the client's privacy.
Best Regards,
Lishan

---

From: Erik Kline <[email-masked]>
Date: Thu, 30 Jul 2015 11:41:56 +0200

>>Even in the "trusted network" scenario, the gain is only apparent in the
>> absence of link-layer protection. For example, enterprise Wi-Fi networks
>> typically use 802.1x and EAP to negotiate a link-layer encryption key
>> specific to the client. This goes a long way towards protecting all the link
>> traffic, including DHCP. Clearly there is a residual risk of on-line
>> attackers, such as a local computer owned by a virus. That risk is generally
>> mitigated by filters in the switches, restricting the sending of DHCP and RA
>> packets. DHCP encryption would be useful if it was easier to deploy than
>> those filters, and more secure.
>>
> [Lishan]: The link-layer encryption 802.1x and EAP you mentioned is only
> designed for the Wi-Fi network. For the general scenario, such as wired
> environment, the DHCP encryption is needed.

802.1x works on wired ethernet.

---

From: ianG <[email-masked]>
Date: Sat, 01 Aug 2015 02:21:04 +0100

On 29/07/2015 12:40 pm, Randy Bush wrote:
> ietf should advocate for set-up authenticity?

Hell yeah!  It's worked to deliver pretty much 100% security &/= 
availability for the worlds that use it.

The balance we want is TOFU every time all time with option of upgrading 
to something stronger if user cares.

> it's not how i want to

Oddly - coffee shops & pubs in UK have been MITM routinely for at least 
a couple of years that I've noticed.  Shocking really, but nobody seems 
to care.  The trick is to find a coffee house that has its own WIFI - 
and gives you a password.  The ones with franchise WIFIs are all doing 
MITMs as far as I can see.

iang

---

From: Randy Bush <[email-masked]>
Date: Sat, 01 Aug 2015 11:17:27 +0900

> The trick is to find a coffee house that has its own WIFI - and gives
> you a password.

(arbitrary) username and password (see firesheep), and does not use tkip
[0] and ...

pita

March 15, 2016: (Reuters) Over 1,000 WiFi users at Edgeware Starbucks
have their identities stolen and bank accounts emptied.  Banks laugh as
UK laws leave the liability with the customer, not the bank.

randy

--

[0] - very likely the praha ietf network suffered the tkip attack (among
      others).  in response, tkip was quickly disabled.