Subject: [radext] Use of IEEE 8021X to secure DHCP

From: Bernard Aboba <[email-masked]>
Date: Thu, 17 Nov 2016 00:24:31 -0800

The IETF has considered the use of EAP to secure DHCP on multiple
occasions. A few references:
https://tools.ietf.org/html/draft-yegin-eap-boot-rfc3118
https://www.ietf.org/proceedings/61/slides/dhc-3.pdf
https://www.ietf.org/proceedings/77/slides/intarea-4.pdf

A decade ago when the idea was first proposed, a substantial fraction of
devices accessed the Internet over networks that supported EAP:  802.1,
802.11, PPP, PPPOE.  Moreover, there were proposals for cellular networks
(802.16) supporting EAP.   Therefore it appeared possible that EAP-based
key derivation would be available frequently enough that the idea could be
viable.

However, despite repeated proposals (and many, many, IPR issues), the
proposals were never implemented in mainstream operating systems after more
than a decade of discussion.

Why?

The simple answer is that EAP-based link layer authentication never became
mainstream. IEEE 802.16 lost out to LTE and so EAP was never widely
deployed in cellular networks while mobile device usage skyrocketed. With
the decline in usage of PPP and PPPOE, as well as the lack of widespread
deployment of IEEE 802.1X on wired Ethernet,  for all intents and purposes,
EAP-based key derivation became a niche scenario, only utilized with any
regularity only with IEEE 802.11, and even then, only in enterprise
scenarios.  Even within the enterprise, attempts to solve more general
security problems with EAP (remember NAC?) never garnered any substantial
deployment.

By the late 2000s when the Internet Architecture Board began work on what
would become RFC 5505 ("Principles of Internet Configuration"), a clear
lesson had emerged from the carnage: tying the security of a widely used
Internet configuration mechanism such as DHCP to an infrequently available
link-layer authentication mechanism (EAP) was a fundamentally bad idea.

In particular, Section 2.4 describes the drawbacks of inherent in making
Internet configuration mechanisms dependent on the link layer:

   Extensions to link-layer protocols for the purpose of Internet-,
   transport-, or application-layer configuration (including server
   configuration) should be avoided.  Such extensions can negatively
   affect the properties of a link as seen by higher layers.  For
   example, if a link-layer protocol (or tunneling protocol) configures
   individual IPv6 addresses and precludes using any other addresses,
   then applications that want to use privacy extensions [RFC4941
<https://tools.ietf.org/html/rfc4941>] may
   not function well.  Similar issues may arise for other types of
   addresses, such as Cryptographically Generated Addresses [RFC3972
<https://tools.ietf.org/html/rfc3972>].

   Avoiding lower-layer dependencies is desirable even where the lower
   layer is link independent.  For example, while the Extensible
   Authentication Protocol (EAP) may be run over any link satisfying its
   requirements (see Section 3.1 of [RFC3748]
<https://tools.ietf.org/html/rfc3748#section-3.1>), many link layers
do not
   support EAP and therefore Internet-layer configuration mechanisms
   that depend on EAP would not be usable on links that support IP but
   not EAP.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 17 Nov 2016 08:58:51 -0500

> On Nov 17, 2016, at 3:24 AM, Bernard Aboba <[email-masked]> wrote:
> 
> The IETF has considered the use of EAP to secure DHCP on multiple occasions. A few references:

  Which is a bit more complex than this proposal.

> https://www.ietf.org/proceedings/77/slides/intarea-4.pdf

  I'd add the following, which I was involved in a while ago.  IIRC, it's actually deployed in certain vendor equipment, mainly in Korea.

https://www.ietf.org/proceedings/74/slides/dhc-0.pdf

> The simple answer is that EAP-based link layer authentication never became mainstream. IEEE 802.16 lost out to LTE and so EAP was never widely deployed in cellular networks while mobile device usage skyrocketed. With the decline in usage of PPP and PPPOE, as well as the lack of widespread deployment of IEEE 802.1X on wired Ethernet,  for all intents and purposes, EAP-based key derivation became a niche scenario, only utilized with any regularity only with IEEE 802.11, and even then, only in enterprise scenarios.  Even within the enterprise, attempts to solve more general security problems with EAP (remember NAC?) never garnered any substantial deployment.

  NAC failed in large part because no one really knew what it was.  And doing posture assessment via EAP required EAP.  So if people didn't deploy EAP, NAC was harder to deploy.

  I'd add NEA to the list:

https://datatracker.ietf.org/wg/nea/documents/

  Lots of work, not a lot of implementation.

  EAP *is* growing in usage.  Eduroam is deployed world-wide.  Many enterprises are using EAP internally.  Telcos are using EAP, mainly for WiFi and WiFi offloading.

  I'd say in 2016, pretty much every device is capable of doing EAP.  Most networks are capable of doing EAP.  It's just that no one uses it.  Mainly because it's just too difficult to do client configuration.

> By the late 2000s when the Internet Architecture Board began work on what would become RFC 5505 ("Principles of Internet Configuration"), a clear lesson had emerged from the carnage: tying the security of a widely used Internet configuration mechanism such as DHCP to an infrequently available link-layer authentication mechanism (EAP) was a fundamentally bad idea.

  That's the main issue.

  This proposal came out of a discussion in SAAG, about securing DHCP:

https://tools.ietf.org/html/draft-li-dhc-secure-dhcpv6-deployment-03

https://www.ietf.org/mail-archive/web/saag/current/msg07316.html

  i.e. on first connect, the DHCP client "trusts" the network, and caches it's credentials.  This is referred to as "time of first use".  On subsequent connections, the DHCP client validates the network's credentials.

  This seems simple, but many questions have been raised about actual security and usability.  i.e.if you connect to a "bad" network, it may be almost impossible to forget that association.

  Alan DeKok.