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

From: Alan DeKok <[email-masked]>
Date: Sat, 1 Aug 2015 09:28:28 +0200

On Jul 29, 2015, at 9:47 PM, Randy Bush <[email-masked]> 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.
> do they really want to authenticate all mobiles?

  Yes.  Enterprises are moving to ubiquitous 802.1X, both for wired and wireless.  All end-user devices will be authenticated.

  In those situations, it should be trivial to sign the DHCP packets with a key derived from the 802.1X session.  That signals the end device that the DHCP server is run under the same organization as the 802.1X authenticator.  The main reason this doesn't happen (so far as I can tell) is that the DHCP and 802.1X groups don't talk much.  Either at the IETF, or inside of corporations developing operating systems.

> 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.

  Or, just move to 802.1X, and then sign the DHCP packets as above.  The Hotspot 2.0 standard from the WiFi alliance uses 802.1X for all hotspots.

> 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.

  The main barrier to adoption is deploying the solutions.  The technologies described above are ubiquitous in isolation... the only new thing required is for them to communicate.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 1 Aug 2015 09:31:33 +0200

On Jul 30, 2015, at 2:17 AM, Christian Huitema <[email-masked]> wrote:
> 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.

  That protects the traffic from third party observers, at least at the radio layer.  It doesn't authenticate the DHCP traffic as coming from a trusted source.  The rest of the wired network may still be penetrated and broken.

> 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.

  Or just sign the DHCP packets with a key derived from the 802.1X keys.  That requires no interaction with the switches.  Only the DHCP client and server need to be updated.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 1 Aug 2015 18:27:24 -0700

Alan said: 
"Or just sign the DHCP packets with a key derived from the 802.1X keys.  That requires no interaction with the switches.  Only the DHCP client and server need to be updated."

[BA] Authenticating a DHCP packet with a unicast key derived between the station and the AP would not prove authorization to act as a DHCP server, so IMHO it would not add any value beyond what is already provided by 802.11 security.  Similarly, authenticating a multicast DHCP packet with a key derived from the 802.11 group key would also not demonstrate authorization to act as a DHCP server so that also adds no value.

---

From: Alan DeKok <[email-masked]>
Date: Sun, 2 Aug 2015 10:17:27 +0200

On Aug 2, 2015, at 3:27 AM, Bernard Aboba <[email-masked]> wrote:
> [BA] Authenticating a DHCP packet with a unicast key derived between the station and the AP would not prove authorization to act as a DHCP server, so IMHO it would not add any value beyond what is already provided by 802.11 security.

  That's true.  All it would do was signal that the DHCP packet came from the AP.  Which we already know.

>  Similarly, authenticating a multicast DHCP packet with a key derived from the 802.11 group key would also not demonstrate authorization to act as a DHCP server so that also adds no value. 

  Sure, but that's not what I meant.

  I was thinking of the MSK / EMSK, which are derived from the EAP session, and typically the TLS session.  The EAPOL Key is in turn derived from that.

  It should be possible to derive a DHCP session key from the MSK.  The authentication server can send the DHCP session key to the DHCP server, which can then use it to sign DHCP packets.  The supplicant can do the same thing, and validate the incoming DHCP packet.  The key would be unique to each session.  It would also be possible to use the MSK to derive a unique MAC address for the device, which would signal to the DHCP server that the device had previously been authenticated via 802.1X.  And that identity derivation would solve most of the issues around privacy of identifiers.

  This is imperfect, of course.  It presumes that 802.1X is used, which isn't always the case.  Other methods will be needed in other circumstances.

  Alan DeKok.

---

From: Randy Bush <[email-masked]>
Date: Sun, 02 Aug 2015 17:32:23 +0900

> This is imperfect, of course.  It presumes that 802.1X is used,
> which isn't always the case.  Other methods will be needed in
> other circumstances.

is there any chance we can enumerate the significant scenarios so
that we can start to understand how they might be handled?

randy

---

From: Sam Hartman <[email-masked]>
Date: Mon, 03 Aug 2015 08:05:34 -0400

Bernard claims that using the EAP key hierarchy doesn't prove
authorization to act as a DHCP server.

There's a sense in which this is true.
However, there's another sense in which being involved in the EAP keying
proves that the proposed DHCP server is part of the infrastructure.
I think that provides better assurance by far than we have today.
My hope is that we do not let the perfect solution here become the enemy
of incremental improvement.

---

From: Nico Williams <[email-masked]>
Date: Mon, 3 Aug 2015 11:07:34 -0500

On Wed, Jul 29, 2015 at 03:19:30PM +0100, Stephen Farrell wrote:
> 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.

Ignoring weak passwords and applying a Kerberos-ish (but EAP-ified,
meaning using IAKERB to authenticate to the infrastructure and then
user-to-user Kebreros to authenticate the NAS to the client) I think
symmetric keying for everything ought to work just fine.  (Also ignoring
the lack of PKCROSS.)

Not that that's something I care to push.  Just sayin'.

Weak passwords obviously are a good argument for a PAKE or for at least
having DH + server authentication, so PK does seem necessary, yes, but
mostly for that reason, and for the bootstrapping of cross-domain trusts
that a purely-symmetric Needham-Schroeder protocol has trouble with.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 3 Aug 2015 11:17:50 -0500

> do they really want to authenticate all mobiles?

Authenticating the enterprise and DHCP servers to the mobiles is one
thing.  Authenticating the latter to the former is another.  I've no
idea if enterprises want to do this, but my experience is that many
enterprises that offer wifi want to force users to then VPN and/or else
to accept MITM trust anchors ("you want to use our network, you pay a
privacy price" is de rigeur).

> enterprise, i think the mobile device should reveal as little as

The QR code thing works for enterprises that allows BYOD.

There's also "install this app from the store using 3G/4G then you can
get on our wifi".  There are plenty of options; none perfect.

> it and others should too.

Yes.

> [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,
>       ...

Yes, that approach is a disaster [because of a lack of standard, useful
set of IPsec APIs].  But I'm like a broken record as to this.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 4 Aug 2015 21:54:24 +0200

> There's a sense in which this is true.

  It's all very true.  But not overly helpful.

  AAA servers have certificates with an OID that says "TLS Web Server Authentication".  Yet despite that lie (or perhaps because of it), clients use those certs for EAP / 802.1X authentication.

> of incremental improvement.

  I agree.

  If you trust the AAA server to authenticate you, then it's beneficial to have a trusted introduction to a DHCP server.  You might ignore that trust statement, but that's your decision.  *Not* having that trust statement means you're accepting DHCP packets from random systems on the local network.  Which seems worse to me.

  Alan DeKok.