Network Working Group DeKok, Alan
INTERNET-DRAFT Network RADIUS
Updates: 7585 12 July 2021
Category: Standards Track
Expires: January 12, 2022
EAP Usability
draft-dekok-emu-eap-usability-00.txt
Abstract
This document defines methods which enable simpler deployment of TLS-
based EAP methods. It defines new certificate fields, and uses
existing certificate fields in order describe new methods for
bootstrapping security. The methods defined here change TLS-based
EAP supplicant configuration from a complex and insecure process to
one that is automated, and is essentially trivial. These methods are
still, however, compatible with existing standards and practices.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 12, 2022.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
DeKok, Alan Proposed Standard [Page 1]
INTERNET-DRAFT EAP Guidelines 12 July 2021
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info/) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
DeKok, Alan Proposed Standard [Page 2]
INTERNET-DRAFT EAP Guidelines 12 July 2021
Table of Contents
1. Introduction ............................................. 5
1.1. Requirements Language ............................... 6
2. Historical Problems ...................................... 7
2.1. Supplicant Changes over Time ........................ 7
2.1.1. Phone Vendor One ............................... 7
2.1.2. Phone Vendor Two ............................... 8
2.1.3. Operating System Vendor One .................... 9
2.1.4. Operating System Vendor Two .................... 9
2.1.5. Operating System Vendor Three .................. 9
2.2. Problems with Certificates .......................... 10
2.2.1. Problematic Use of Certificate Stores .......... 10
2.2.2. Problematic use of key purpose fields .......... 11
2.2.3. Problematic Use of Certificates ................ 12
2.2.4. Obtaining Certificates with the new OIDs ....... 13
3. Principles and Guidelines ................................ 15
3.1. Network Configuration Guidelines .................... 15
4. New Recommendations for Certificates with EAP ............ 17
4.1. Comparison to HTTPS ................................. 17
4.2. Additional Information Required ..................... 18
5. How It Works in Practice ................................. 19
5.1. A worked example for EAP-TLS ........................ 19
5.1.1. The Problem Statement .......................... 19
5.1.2. Obtaining the Certificates ..................... 20
5.1.3. Configuring the end user device ................ 21
5.1.4. Obtaining Network Access ....................... 22
5.2. Other TLS-based EAP methods ......................... 23
5.3. EAP methods which do not use TLS .................... 24
5.4. Other Methods of Provisioning ....................... 24
5.5. Trust on First Use Can be Secure .................... 25
5.6. Additional Considerations ........................... 26
6. Extending the Solution ................................... 28
6.1. Bootstrapping via EST ............................... 28
6.1.1. Closing the loop ............................... 29
6.2. Bootstrapping via DNS ............................... 30
6.2.1. CERT records ................................... 30
6.2.2. CERT record labels for Server Certificates ..... 32
6.2.3. CERT record labels for CA Certificates ......... 32
7. Related issues ........................................... 33
7.1. Provisioning Issues ................................. 33
7.1.1. Bootstrapping via a Separate Network ........... 33
7.1.2. Configuration Change is just Refresh ........... 34
7.1.3. Secure versus Insecure Provisioning ............ 35
7.2. Issues related to Security .......................... 35
7.2.1. Why id-on-naiRealm ............................. 36
7.2.2. Resumption ..................................... 36
7.2.3. Choosing EAP Types ............................. 37
DeKok, Alan Proposed Standard [Page 3]
INTERNET-DRAFT EAP Guidelines 12 July 2021
7.2.4. User Experience ................................ 37
7.3. Issues related to Certificates ...................... 38
7.3.1. Public CA versus Private CA .................... 38
7.3.2. Limitations of public CAs ...................... 39
7.3.3. CA Chains ...................................... 40
7.3.4. Delegated Authentication ....................... 41
7.3.5. Identification of Networks ..................... 41
7.4. Anti-solutions ...................................... 42
7.4.1. MDM Products Are not the Solution .............. 42
7.4.2. EST and similar protocols do not solve all of th 44
7.4.3. Captive Portals and Hotspots ................... 45
7.5. id-kp-eapOverLAN May not be sufficient .............. 45
7.6. Guest Networks ...................................... 45
7.7. Using TLS with protocols other than EAP ............. 47
8. Moving to the new methods ................................ 48
8.1. Using the new OIDs .................................. 48
8.2. Recommendations for EAP peers and authenticators .... 49
8.3. Principles and Guidelines ........................... 51
9. Security Considerations .................................. 52
9.1. On Identities and Service Discovery ................. 52
9.2. Password Hashing and Storage ........................ 52
10. IANA Considerations ..................................... 53
10.1. Key Purpose OIDs ................................... 53
10.2. Underscored and Globally Scoped DNS Node Names ..... 54
11. References .............................................. 54
11.1. Normative References ............................... 54
11.2. Informative References ............................. 55
DeKok, Alan Proposed Standard [Page 4]
INTERNET-DRAFT EAP Guidelines 12 July 2021
1. Introduction
TLS [RFC8446] has been widely deployed, and is used with EAP
[RFC3748] and with RADIUS [RFC2865]. Historically, these
specifications have been written to define the protocols "on the
wire", with minimal description of use-cases and usability. The
success of these specifications has been that perhaps a billion
devices use EAP. The failure of these specifications is that EAP can
be still difficult to use, both for administrators and for end users.
Even with a clear standard, implementations do not always follow the
specifications exactly. In some cases implementations do less than
what is recommended, which can cause security and inter-operability
issues. In other cases, implementors do more than what is
recommended, as they have found the specifications insufficient to
address practical requirements. In other cases, there is no
standard, so implementators make individual choices as to how their
implementations work. Even worse, implementors change their
implementations over time, to solve problems which are not addressed
in the standards.
All of these issues lead to confusion for end users and
administrators. These issues lead to decreased security of the
protocols, and decreased trust in the protocols.
The result of the above problems is software where many critical
aspects of its operation are vendor-defined. This wide variation
gives a poor experience for all parties involved, and contributes to
decreased security.
This document therefore defines method to enable the simple and easy
deployment of TLS-based EAP methods. It defines new certificate
fields, and describes how those fields can be used to gain network
access easily and securely. The processes it defines are clear and
straightforward. The end user experience is understandable, and
difficult to get wrong.
That is, this specification removes the need to rely on end users to
make security decisions. History shows us that such reliance is
misplaced. Instead, we rely on the global certificate system which
has proven to work well, along with a few changes to the behavior of
EAP systems.
These ideas are not new. [RFC4334] Section 1 says:
Automated selection of client certificates for use with PPP and
IEEE 802.1X is highly desirable. By using certificate extensions
to identify the intended environment for a particular certificate,
DeKok, Alan Proposed Standard [Page 5]
INTERNET-DRAFT EAP Guidelines 12 July 2021
the need for user input is minimized.
We extend the above statements to include server certificates, and to
further define automated processes by which. In addition, where
[RFC4334] describes the "automated selection of client certificates",
we invert that use-case to show how certificates can be used to
automate network configuration, via a set of simple and clearly
defined processes.
The document begins with an overview of the current situation. We
describe the problems which have motivated this document. First by
showing how the behavior of multiple vendor implementations has
changed over time. We then discuss problems with the ways that
certificate are handled. We discuss how the standards contradict
each other, and how current practices contradict, ignore, or extend
the standards in incompatible ways.
The document begins with a worked example, initially just for EAP-
TLS, and then showing how the processes described for EAP-TLS can be
easily applied to other EAP methods.
We extend the given solution by using DNS and HTTPS to perform
initial bootstrapping of the supplicant configuration. We show how
supplicants can be configured securely by leveraging the existing
trust in the web PKI. This bootstrapping requires no changes to
supplicant code or behavior.
We finally summarize the work by giving a set of specific
recommendations.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
DeKok, Alan Proposed Standard [Page 6]
INTERNET-DRAFT EAP Guidelines 12 July 2021
2. Historical Problems
There have historically been a number of issues with configuring
devices for EAP authentication. The overly positive description of
this history is that it has resulted in a wide variety of tools and
products available to configure EAP on end-user devices. In addition
to the wide variety of configuration products, the behavior of native
supplicants has also varied widely over time.
These issues point to an underlying problem which has, as yet, been
unresolved. Each vendor of configuration products or devices to be
configured has largely been performing searches by "trial and error"
in order to find the best user experience. The result, of course,
has been a frustrating experience for both users and for vendors.
We do not discuss Mobile Device Management (MDM) vendors or vendors
of other supplicant configuration products here. Their products are
largely tools which use the APIs presented by supplicant vendors, and
attempt to hide the complexity from end users.
We also do not discuss the behavior of EAP servers (authenticators)
or RADIUS servers. The issues seen by supplicants are largely
related to user experience, and have little effect on the "on the
wire" protocol. As such, RADIUS servers have been required to make
correspondingly fewer changes to their implementations. In addition,
RADIUS servers are generally designed to be complex, with complex
policies. These policies enable their administrators to change the
behavior of the software without resorting to product upgrades.
As a result, we focus initially on supplicants, how their behavior
has changed over time, and the publicly visible effects of those
changes.
2.1. Supplicant Changes over Time
In this section we discuss how the behavior of multiple supplicants
has changed over time. We do not name the vendors of these
supplicants, as there is no need to blame them for being unable to
solve an industry-wide problem.
2.1.1. Phone Vendor One
This vendor has been gradually disabling the supplicant
configuraration API. Instead, configuration product vendors are able
to influence the user interface with suggested prompts at different
points in the authentication framework.
It appears that the goal is to give the user control over the
DeKok, Alan Proposed Standard [Page 7]
INTERNET-DRAFT EAP Guidelines 12 July 2021
network. A related goal is to require the user's consent before
making changes to the network.
The system also treats SSIDs as defining a location, even though
SSIDs are not inherently location-specific. This mislabelling means
that users' are shown prompts about location, when in fact the
operation being performed is connecting to an SSID.
The effect of these issues is that the user is unable to meaningfully
consent. There may insufficient information available, the available
information may be meaningless to the end user, or the information
given to the end user is simply wrong.
This vendor has changed how manual connections are managed over time.
The user is not always prompted, but the systems behavior has gone
through the following changes to connection requirements:
* do not perform certificate validation * validate that the root CA
is in the system certificate store * validate that the root CA is in
the WiFi certificate store * require a DNS name for the RADIUS
server.
None of these solutions are optimal.
2.1.2. Phone Vendor Two
This vendor has a standard format for WiFi configuration files. The
user can manually install the configuration, but that configuration
is not active until an additional manual step is performed to enable
it.
A standard configuration is useful, but the configuration file is not
typically signed, even though that is supported. It appears that the
the manual enablement step is an attempt to work around the lack of
authentication for the configuration files.
As was seen in the previous section, the end user has no meaningful
information about the configuration. This lack of information means
that the user is conditioned to simply accept the configuration and
enable it, without paying attention to its contents.
This vendor does, however, provide a robust API. This API permits a
rich ecosystem of MDM products which automate the configuration of
end-user devices.
DeKok, Alan Proposed Standard [Page 8]
INTERNET-DRAFT EAP Guidelines 12 July 2021
2.1.3. Operating System Vendor One
This vendor has been gradually disabling their WLAN API. The
remaining APIs permit MDM solutions to associate a user identity with
a particular network. However, there is no ability to set a root CA
or a RADIUS server DNS host name.
When the user connects to the network, a prompt is shown which asks
the user if the server is valid. The server certificate is presented
to the user, but the user has no information about which root CA is
acceptable or not. Instead, the user is shown fields from an unknown
certificate, and is asked to validate that the certificate is
acceptable.
Again, the user has insufficient information to meaningfully consent.
Which again means that the only course of action is to mindlessly
click on "accept".
2.1.4. Operating System Vendor Two
This vendor retains a rich WLAN API, but has removed the ability to
configure specific users. Instead, only system-wide profiles can be
set.
This vendor provides for easy installation of additional root CAs,
but those root CAs are permitted to be used for any purpose. Which
means that a malicious private CA can issue HTTPS certificates for
any domain. These fake certificates will be silently accepted by the
systems browser as being valid. The user will be unable to
distinguish malicious sites presenting those fake certificates from
the genuine domains.
It is difficult to overstate the negative security impact of that
process.
An MDM product adding a private CA generally requires a privileged
account to install the CA. A user can install a CA manually, but the
operating system will show the user large amounts of text in order to
warn the user about the security issues of this process. The user,
of course, has no way of understanding many of these warnings, and is
left again to mindlessly click on "accept".
2.1.5. Operating System Vendor Three
This vendor retains a rich WLAN API, and a number of tools by which
network configuration can be performed. These tools are widely used
by MDM vendors to automate the configuration of networks.
DeKok, Alan Proposed Standard [Page 9]
INTERNET-DRAFT EAP Guidelines 12 July 2021
However, the end user experience is still complex. The user still
must manually select each individual parameter from multiple options.
This capability gives the user a substantial amount of control over
the process, but does not provide any more information than is
available in other operating systems.
This process of allowing the end user to configure everything is
useful for experienced and knowledgable users. However, it leaves
the average user with a bewildering set of choices, most of which are
meaningless or opaque. The user is then left to mindlessly follow
online guides, which may or may not work, and which do not give the
user enough information to give informed consent for the actions that
are being taken.
2.2. Problems with Certificates
The widely (and wildly) changing behavior of supplicant software is
not the end of the story, however. There are a large number of
problems related to the use and abuse of certificates. These issues
are discussed in more detail in this section.
2.2.1. Problematic Use of Certificate Stores
Some EAP peers use a different certificate store for EAP than for
other (e.g. web) applications. In practice, the use-case of
"downloading video from a known source" is substantially different
from the use-case of "sending authentication credentials to a known
destination". As such, the certificate stores should be different
for these two use-cases.
When a CA is allowed to be used for EAP, then the implication is that
all certificates signed by that CA are allowed to be used for EAP.
This result is not secure. It permits attackers to get a valid
server certificate from a public CA, and then to set up an EAP
server. Naive EAP peers will then send user credentials to the
malicious server. Worse, there is no general way for any third-party
to detect that this impersonation has happened. It is only visible
to EAP peers who are in a small geographic area.
Tests have shown that in a university environment, up to fifty
percent of EAP peers will connect to a malicious SSID without
checking the CA or server certificate. In effect, these peers will
send authentication credentials to anyone who asks.
The security problems associated with such behavior cannot be
overstated.
However, not all EAP peers uses separate certificate stores. Using
one certificate store is less of an issue when "self signed" or
DeKok, Alan Proposed Standard [Page 10]
INTERNET-DRAFT EAP Guidelines 12 July 2021
"private" CAs are used. The use of private CAs for EAP means that
the EAP system is now more secure. However, the addition of private
CAs to a global certificate store means that those private CAs can
now issue certificates for well-known public web sites. The
possibility of such forgery has made it difficult for MDM vendors or
site administrators to create and use private CAs.
As such, we reiterate that the certificate stores SHOULD be different
for these each application or use-case. Where the system cannot
tolerate multiple different stores, it SHOULD at least mark each CA
certificate with an annotation as to its intended purpose. While
there is a "key purpose" field defined for certificates, we will see
that this field is not always suitable for differentiating
certificate purposes.
2.2.2. Problematic use of key purpose fields
[RFC5216] Section 5.3 makes the following recommendations about the
certificate used by the EAP-TLS server:
In the case of the EAP-TLS peer, this involves ensuring that the
certificate presented by the EAP-TLS server was intended to be
used as a server certificate. Implementations SHOULD use the
Extended Key Usage (see Section 4.2.1.13 of RFC3280) extension and
ensure that at least one of the following is true:
1) The certificate issuer included no Extended Key Usage
identifiers in the certificate.
2) The issuer included the anyExtendedKeyUsage identifier in the
certificate ...
3) The issuer included the id-kp-serverAuth identifier in the
certificate ...
These recommendations have also been used in EAP-TLS [EAPTLS], EAP-
TTLS [RFC5281], PEAP [PEAP] and [MSPEAP], EAP-FAST [RFC4851], and
TEAP [RFC7170].
We first note that this document extends and strengthens the
suggestion that systems ensure "that the certificate presented by the
EAP-TLS server was intended to be used as a server certificate." We
also extend this recommendation to client certificates, further
strengthening the security around TLS-based EAP methods.
However there is an issue with the [RFC5216] recommendations. These
recommendations appear to be in direct conflict with the definition
of id-kp-serverAuth from [RFC5280] 4.2.1.12, and of the requirements
for its usage:
If the extension is present, then the certificate MUST only be
DeKok, Alan Proposed Standard [Page 11]
INTERNET-DRAFT EAP Guidelines 12 July 2021
used for one of the purposes indicated. If multiple purposes are
indicated the application need not recognize all purposes
indicated, as long as the intended purpose is present.
... If a certificate contains both a key usage extension and an
extended key usage extension, then both extensions MUST be
processed independently and the certificate MUST only be used for
a purpose consistent with both extensions. If there is no purpose
consistent with both extensions, then the certificate MUST NOT be
used for any purpose.
...
id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
-- TLS WWW server authentication
This definition shows that id-kp-serverAuth is intended for "WWW
server" usage, which is in conflict with how it is defined in
[RFC5216]. Similar issues exist for the id-kp-clientAuth OID, in
that it is intended for "WWW client", which is not correct for EAP.
It appears that the recommendations made in [RFC5216] were taken from
[RFC2716], and were made for entirely practical reasons. The desire
was for users of EAP to be able to obtain certificates from public
root CAs. However, those root CAs could not (or would not) issue
certificates which contained OIDs other than id-kp-serverAuth.
Therefore as work around, [RFC5216] Section 5.3 allowed for a wide
variety of EKUs to be used in server certificates. These
certificates could then come from private CAs, or from publicly known
root CAs.
We believe that the long-term correct solution is to define and use
additional key purpose OIDs. These key purpose OIDs can initially be
used by EAP implementations along with private CAs. As support for
these OIDs becomes more widely available, it may be possible for
public CAs to issue purpose-specific certificates.
The problematic use of id-kp-serverAuth has had a number of impacts,
past the issue of contradictory specifications. These impacts result
in certificates being used in problematic ways, which we discuss
below.
2.2.3. Problematic Use of Certificates
The current workarounds to the contradictions in the specifications
are two-fold. One, is simply to get certificates with id-kp-
serverAuth from a public CA, and hope that using it for EAP either is
acceptable, or that it is not noticed. Another is to use a self-
signed CA. Both work-arounds have problems.
Many people prefer to use public CAs, as they are seen as "better"
DeKok, Alan Proposed Standard [Page 12]
INTERNET-DRAFT EAP Guidelines 12 July 2021
than self-signed CAs. However, using a public CA likely means
violating the terms of use of that CA. Which means that the network
continues to work so long as this mis-use is not reported.
It can be useful instead to use private CA. A private CA can add id-
kp-serverAuth without violating any terms of use, or it can omit the
key purpose OIDs, or it can add custom key purpose OIDs.
However, in addition to the problems noted in the earlier section,
private CAs are not installed by default in client devices. This
limitation means that these CAs must be provisioned somehow. As seen
above, these provisioning methods can be complex and prone to
failure.
As such, there is no simple, easy, way for administrators to both
obtain and provision certificates for use with EAP.
We also note that these OIDs are used not only for EAP, but that they
are also used for other public-facing TLS services such as XMPP,
SMTPS, LDAPS, etc. Those protocols may have similar issues with
alleged mis-use of these OIDs. If these use-cases are forbidden user
CAB guidelines, then this would seem to be a serious problem with the
global certificate framework.
We leave the solution of these issues as a point of discussion for
the wider Internet community.
2.2.4. Obtaining Certificates with the new OIDs
Most CAs currently offer limited support for non-"WWW" OIDs in
certificates. In many cases, the Certificate Signing Request (CSR)
supplied by the customer is (in practice) used only as a vague
suggestion. While the CA generally does not add any fields, it may
drop fields that it does not recognize or support. Or, the CA may
discard the CSR entirely.
[CAB] Section 7.1.2.3 makes it difficult for existing CAs to issue
client certificates which contain the new OIDs:
Either the value id-kp-serverAuth [RFC5280] or id-kp-clientAuth
[RFC5280] or both values MUST be present. id-kp-emailProtection
[RFC5280] MAY be present. Other values SHOULD NOT be present. The
value anyExtendedKeyUsage MUST NOT be present.
Further, the requirements of [CAB] Section 7.1.2.4 essentially
forbids CAs from signing certificates which are intended for use with
EAP:
DeKok, Alan Proposed Standard [Page 13]
INTERNET-DRAFT EAP Guidelines 12 July 2021
CAs SHALL NOT issue a Certificate with:
a. Extensions that do not apply in the context of the public
Internet (such as an extKeyUsage value for a service that is only
valid in the context of a privately managed network), unless:
None of the reasons listed after "unless" allow for CAs to issue
certificates for use with EAP in a privately managed network.
This behavior by CAs makes it difficult in practice, if not
impossible, to obtain non-"WWW" certificates from a public CA.
The suggestion given here is to simply use self-signed CAs. This
suggestion is not always practical.
It is possible to define CAs for "walled gardens" with a private CA.
One example is certificates used internally in an organization, or in
a group such as Eduroam [RFC7593] and [EDUROAM]. In those
situations, the members requesting certificates have already
validated, and there is already a legal framework in place to protect
the parties.
Other suggestions have been that it is relatively simple to set up a
new CA, with new procedures and requirements. Given the regulatory
requirements around CAs, it appears that new public-facing CAs have
to be well funded. i.e. requiring many millions of dollars. It is
therefore difficult, if not impossible, for small public-facing CAs
to be created.
The goal of this document is to permit better behavior for EAP peers
and authenticators. If this specification is widely deployed, then
there may be sufficient demand for CAs to offer new certificates
which are marked as fit for their intended purpose.
DeKok, Alan Proposed Standard [Page 14]
INTERNET-DRAFT EAP Guidelines 12 July 2021
3. Principles and Guidelines
After analysis of the historical practices and standards for EAP, we
came to a set of guidelines which are outlined in this section.
Application of these guidelines drove the rest of the specification
which we define herein.
3.1. Network Configuration Guidelines
It is RECOMMENDED that the guidelines given below are followed when
developing new network configuration standards and methods:
* Automated provisioning is strongly preferred to manual
provisioning. We define "automated provisioning" as provisioning
which is performed via software, with little or no user
intervention. Automation minimizes the possibility for end users
to create broken or insecure configurations.
* Manual provisioning should be limited to "Trust on first use"
(ToFU), and cached or "pinned" after that. That is, manual
provisioning should be limited to allowing a user to approve
validation decisions which have been made by the system.
* Relying on end users to manually configure complex systems
is strongly discouraged. Complex systems are difficult to
configure, and improperly configured systems create many issues
related to security, usability, and network access.
* Configuration should be "pinned" in order to permit systems to
detect and prevent unauthorized changes, and to detect malicious
networks which claim to be updated versions of the true network.
* The identity and role of both parties should be exchanged, and
verified. In practice, this suggestion often means that TLS-based
EAP methods are preferred to ones which only do name / password
credential verification.
* The previous requirement usually means that the both parties know
which RFC 7542 NAI realm is being used. This realm serves a
similar purpose to the the DNS host name used in other TLS-based
protocols such as HTTPS. As such, similar methods can be used to
validate certificate authenticity. This NAI realm is contained in
an id-on-naiRealm field, as defined in [RFC7585] Section 2.2
* For TLS-based EAP methods, trust should be based on a
certification authority (CA), which signs certificates for a
particular realm. If the CA is trusted, then everything derived
from that CA can be trusted. If the CA is not trusted, then it is
DeKok, Alan Proposed Standard [Page 15]
INTERNET-DRAFT EAP Guidelines 12 July 2021
impossible to trust anything derived from an untrusted CA.
* CAs should also be associated with permitted uses. For example, a
root CA which is trusted for web surfing is not necessarily trusted
for use with EAP authentication. In practice this means either
having separate certificate stores for different purposes, or
annotating root certificates with their permitted uses.
We believe that these recommendations are correct, simple, practical,
and will improve security and usability for all participants in EAP.
We show that there is a clear upgrade path from current behavior to
better behavior. Each step of that upgrade path is simple, and
involves minimal change for end users or administrators.
DeKok, Alan Proposed Standard [Page 16]
INTERNET-DRAFT EAP Guidelines 12 July 2021
4. New Recommendations for Certificates with EAP
The first step towards a complete solution is to define new OIDs.
These OIDs indicate that certificates are intended for use with an
EAP server, or an EAP peer.
The following key usage purposes are defined within id-kp:
id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
id-kp-eapServer OBJECT IDENTIFIER ::= { id-kp TBD-1 }
-- TLS EAP server authentication
-- Key usage bits that may be consistent: digitalSignature,
-- keyEncipherment or keyAgreement
id-kp-eapClient OBJECT IDENTIFIER ::= { id-kp TBD-2 }
-- TLS EAP peer authentication
-- Key usage bits that may be consistent: digitalSignature,
-- and/or keyAgreement
These EKU fields mirror id-kp-serverAuth, and id-kp-clientAuth,
respectively.
We also rely on id-on-naiRealm, as defined in [RFC7585] Section 2.2.
This field contains the NAI realm [RFC7542] in which the user has an
identity, and for which the EAP server is performing authentication.
4.1. Comparison to HTTPS
We can further explain how these fields help EAP by comparison with
how certificates are used for HTTPS [RFC2818]:
* HTTPS uses id-kp-serverAuth to indicate that a certificate
is permitted to be used with an HTTPS server. We
define id-kp-eapServer which indicates that a
certificate is permitted to be used with an EAP
server.
* HTTPS uses id-kp-clientAuth to indicate that a certificate
is permitted to be used with an HTTPS client. We
define id-kp-eapClient which indicates that a
certificate is permitted to be used with an EAP
client.
* HTTPS uses id-ce-subjectAltName with dNSName [RFC5280] to contain
the DNS name of the server to which the client is
connecting. We use id-on-naiRealm [RFC7585] to
indicate the NAI realm of the server to which the
DeKok, Alan Proposed Standard [Page 17]
INTERNET-DRAFT EAP Guidelines 12 July 2021
client is authenticating.
4.2. Additional Information Required
When combined with a clearly defined process, the above definitions
allow devices to use TLS-based EAP methods with no more complexity
than is seen when browsing the web. That is, in many situations, all
the end device needs is the following:
* network access (trusted or not) * an account in a domain, e.g.
"user@example.com" * one or more trusted root CAs from the web PKI.
This information can be used to securely obtain network access. The
procedures outlined here work with both public CAs and private CAs.
We will first describe how these fields can be used to make EAP
authentication easier to use. Once we have described a worked
example using these fields, we will show how to extend the solution
to solve the remaining open issues.
DeKok, Alan Proposed Standard [Page 18]
INTERNET-DRAFT EAP Guidelines 12 July 2021
5. How It Works in Practice
In this section we provide a worked example for EAP-TLS. This
discussion uses EAP-TLS as an example, but the methods discussed here
are not limited to that use-case. Describing a specific EAP method
allows us to discuss every aspect of the proposal, without worrying
about how similar methods are applicable to different situations.
We expand the discussion later in this section to show how these
methods are applicable to other TLS-based EAP methods.
5.1. A worked example for EAP-TLS
We explain how this specification works via an example using EAP-TLS.
We start off with the problem statement, then how the certificates
might be obtained, then how the EAP peer is configured using
information in the certificates, and finally how the device obtains
network access.
5.1.1. The Problem Statement
For the initial worked example, we assume that we are trying to solve
the limited problem of an end user who has a WiFi enabled device such
as a laptop. The user wishes to use that device to get online, via
the simplest possible method. There is an administrator who also
wishes to get that user online, and wishes to configure the end user
device to do EAP-TLS.
We also presume that there are some additional pieces of the
solution, as follows:
* There may be a Wireless LAN (WLAN) System Service identifier
(SSID) which is used for WiFI authentication. This information can
be realized in the certificate field id-pe-wlanSSID, as defined in
[RFC4334] Section 3.
* All parties know which NAI realm [RFC7542] is being being used.
For example, an individual may work for a company "example.com".
This information is placed into the certificate field id-on-
naiRealm, as defined in [RFC7585] Section 2.2.
* We use the new EKU field id-kp-eapServer. This field indicates
that a certificate is intended to be used as a server certificate
within EAP.
* We use the new EKU field id-kp-eapClient. This field indicates
that a certificate is intended to be used as a client certificate
within EAP.
DeKok, Alan Proposed Standard [Page 19]
INTERNET-DRAFT EAP Guidelines 12 July 2021
Knowing the name of the SSID is necessary, but perhaps not
sufficient. Some environments may have additional security
requirements, such as mandating that only WPA3-192-bit connections
may be used. This information should likely go into another field of
the certificate. For the purposes of this document, we will assume
that knowing the SSID name is acceptable.
EAP methods are also used to authenticate users when SSIDs are not
available (e.g. wired 802.1X), the use of id-pe-wlanSSID is
recommended, but is not required. For the purpose of this section,
we assume that WiFi access is being configured. Later discussion
will show how the methods outlined here can be applied to other forms
of network access.
As we will see below, this information is sufficient to configure
EAP-TLS securely, and with minimal effort by the end user.
5.1.2. Obtaining the Certificates
The administrator begins by obtaining a server certificate from a
root CA. This CA can be public or private. The only requirement is
that the CA is willing to sign certificates which contain an id-on-
naiRealm field, and which also contain the id-kp-eapServer field
which indicates that this certificate is suitable for use with EAP.
The rest of the fields, and the validation process for those fields,
can be identical to the processes used today.
The use of the new EKU fields here is intended to illustrate the end
goal of simplifying deployments. As we will see later, there are
intermediate steps which do not require the new EKU fields.
The administrator also obtains a client certificate, which will be
given to the end user for installation on the device. This client
certificate is issued via a hierarchy which ends in the root CA that
has issued the previously mentioned server certificate. The rest of
the certificate hierachy here is not important to this example. We
only presume that it exists; that it is valid; and therefore that it
is trusted.
The client certificate contains an id-on-naiRealm field, which has
the same NAI realm as seen in the server certificate. The client
certificate also contains the id-kp-eapClient field which indicates
that this certificate is suitable for use with EAP. The client
certificate may also contain a id-pe-wlanSSID field, though this is
not required.
We presume that the client certificate also has an associated private
key, and that this key is encrypted using a password.
DeKok, Alan Proposed Standard [Page 20]
INTERNET-DRAFT EAP Guidelines 12 July 2021
We now have enough information to configure the end user device.
5.1.3. Configuring the end user device
The administrator configures the end device with the client
certificate, along with its associated private key and password. For
the purposes of this example, it is not important how the device
obtains that information. As noted earlier, the distribution problem
will be solved later in this document by extending the solution.
The configuration may also include the entire certificate chain up
to, and including, the root CA. Not all of these certificates are
always required, as they can be exchanged in the initial EAP-TLS
session.
We note here that the configuration of the end user device is not
embodied in a downloadable executable, or in a vendor-specific
configuration file. Instead, the configuration is given in the form
of standardized certificates which have been marked up to express
their intended usage.
When the end user receives the client certificate (and possibly
certificate chain), it can be installed on the device immediately.
When the certificate is installed, it causes a number of additional
steps to be taken by the device which is using that certificate.
These steps are new to EAP peers, and are not performed today.
First, the device determines that this certificate contains id-kp-
eapClient, which indicates that this certificate is intended to be
used for EAP. If there is a certificate chain, then those
certificates can be saved. If the client certificate contains id-pe-
wlanSSID, then the device uses that information to configure itself
so that it will connect to the named SSID, and to perform EAP-TLS
authentication using this client certificate.
This process is similar to that outlined in [RFC4334]. The changes
we make over that specification are new extensions to the
certificates, and additional steps which mandate new behavior.
Finally, if there is a root CA in the certificate chain, that the
root CA is installed. The device also annotates this root CA (pre-
existing or otherwise) as being trusted to issue certificates for use
with EAP. As we will see, the device can also require the EAP server
certificate to contain id-kp-eapServer, along with an id-on-naiRealm
value which matches the id-on-naiRealm which is in the client
certificate.
At this point, the end user device is fully configured for using EAP-
DeKok, Alan Proposed Standard [Page 21]
INTERNET-DRAFT EAP Guidelines 12 July 2021
TLS with a particular SSID.
5.1.4. Obtaining Network Access
When the end user device wishes to obtain network access, it can for
the most part follow the methods used prior to the publication of
this specification. There are, of course, a few changes which
simplify the process and make it more secure.
For privacy, the device uses an anonymous identifier in the EAP
Response Identity field. This identifier is the NAI realm which is
taken from the id-on-naiRealm field of the client certificate.
Taking the NAI realm from the client certificate means that there is
no need for the user to configure the publicly visible EAP Response
Identity. This usage also provides for the anonymity required in
[EAPTLS].
In order to provide for privacy of the client certificate, TLS 1.3 is
used. Older versions of TLS are NOT RECOMMENDED.
When the EAP-TLS connection is established, the device verifies that
the server certificate which is presented also contains a id-on-
naiRealm field, which matches the value in the client certificate.
This validation is similar to the validation of DNS names performed
by web browsers when accessing HTTPS sites. However, as DNS is not
available during EAP authentication, the id-on-naiRealm field is used
instead to validate the server certificate.
For clarity, we repeat the instructions in [RFC7585] Section 2.2, for
matching the NAI realm:
The comparison of an NAIRealm to the NAI realm as derived from
user input with this algorithm is a byte-by-byte comparison,
except for the optional leftmost dot-separated part of the value
whose content is a single "*" character; such labels match all
strings in the same dot-separated part of the NAI realm. If at
least one of the sAN:otherName:NAIRealm values match the NAI
realm, the server is considered authorized; if none match, the
server is considered unauthorized.
Since multiple names and multiple name forms may occur in the
subjectAltName extension, an arbitrary number of NAIRealms can be
specified in a certificate.
The device also verifies that the server certificate also contains
the id-kp-eapServer field. It verifies that the certificate is
signed by a root CA which is annotated as being permitted for use
with an EAP server. If these verification steps fail, then the
DeKok, Alan Proposed Standard [Page 22]
INTERNET-DRAFT EAP Guidelines 12 July 2021
client stops the authentication process, as it has determined that
the network is not trusted.
If all of these verification steps pass, then the end user device can
trust the EAP server, and be authenticated to the network.
We note here that from the perspective of the end user, the only
actions which have performed have been (1) to install a certificate,
and (2) to enter a password for that certificate. This process is
substantially simpler than most WiFi configuration processes used
today. This process is also likely to be easy to follow for most
users.
5.2. Other TLS-based EAP methods
While the above example discusses EAP-TLS, it is easily extensible to
any other TLS-based EAP methods. Instead of distributing a client
certificate to end users, the administrator can distribute a server
certificate and/or a root CA which is intended for use with EAP. For
simplicity, the server certificate should also contain id-pe-
wlanSSID, which informs the client as to which SSID(s) should be used
for authentication.
We reiterate that the public EAP Response Identity used should always
be in the form "@realm", as per [EAPTLS] Section 2.1.7. The user's
full identity should only be sent inside of the TLS tunnel. We also
recommend that the inner authentication methods use the full identity
of "user@realm", and not just the "user" portion.
The end device then follows the same process to configure the SSID
for authentication, to mark up the SSID as being used with a
particular NAI realm, and to annotate the root CA as being permitted
for use with EAP. Again, having an SSID here simply makes this
example clearer, this specification does not mandate its use, and
this specification is applicable to any type of network access which
uses EAP.
When the device connects, it does not need to verify that the server
certificate being presented is the same as was used for
configuration. Instead, the device simply has to "pin" the
combination of SSID, NAI realm, and root CA. This pinning allows for
flexibility in accepting other server certificates, while preventing
down-grade attacks which attempt to supply different root CAs for
that NAI realm. This pinning means that the device associates the
SSID and NAI realm with a particular root CA, and then does not
permit that NAI realm to authenticate to an EAP server which does not
use the same permitted root CA.
DeKok, Alan Proposed Standard [Page 23]
INTERNET-DRAFT EAP Guidelines 12 July 2021
The only requirement on the new server certificate is that it has to
match the same criteria as outlined in the previous section. That
is, the certificate must contain id-kp-eapServer, it must have a
matching id-on-naiRealm, and it must be be signed by a root CA which
the supplicant has permitted to be used with EAP.
The device can then safely send authentication credentials inside of
the TLS tunnel. This process is substantially similar to that used to
log into an HTTPS enabled web site. The only difference here is that
the device must associate the user's credentials with EAP and an NAI
realm, instead of with the web and a DNS host name.
5.3. EAP methods which do not use TLS
Unfortunately, the methods outlined here apply only to TLS-based EAP
methods. This limitation is because we are leveraging the TLS
certificate format in order to both define additional permitted uses
for those certificates, and to inform devices how non-TLS systems
should be configured.
This extra information is simply not possible to add to other EAP
methods such as EAP-PWD [RFC5931]. Those methods typically
authenticate users, but do not provide for carrying additional
information. Those methods also generally do not provide for the
mutual exchange of identities, and for mutual authentication.
Authentication protocols such as EAP-PWD are simple enough that it is
both impossible, and generally unnecessary, for them to use the
methods outlined in this specification. That is, the cryptographic
guarantees in EAP-PWD ensure that it is always safe to perform EAP-
PWD with unknown EAP servers, as there is no possibility for leakage
of user credentials. As such, there is less need to verify the
identity of the EAP-PWD server.
5.4. Other Methods of Provisioning
The EAP-TLS example described how provisioning was done via an
administrator sending certificates to an end user. This process is
not always necessary.
For EAP-TLS, [EAPTLS] Section 2.1.5 provides for the protocol to be
used without peer authentication. This capability can be leveraged
to perform provisioning. All that is needed on the device is for the
EAP peer to have a pre-configured root CA, and to know the NAI realm
which it belongs to, and which is being used for provisioning.
For the purposes of this section, we assume that the root CA known to
the device is willing to issue and sign server certificates which
DeKok, Alan Proposed Standard [Page 24]
INTERNET-DRAFT EAP Guidelines 12 July 2021
contain the id-kp-eapServer and id-on-naiRealm fields. As we will
see below, this assumption may be difficult to achieve in practice.
When the device connects to a network, it can perform the
verification steps outlined above. That is, the server certificate
presented has a matching id-on-naiRealm field; the server certificate
contains id-kp-eapServer; and that the server certificate is signed
by a known root CA. The root CA does not necessarily have to be
annotated as being permitted for EAP.
If all of those requirements are satisfied, then the device can
obtain limited network access. The device can then leverage normal
networking protocols to download provisioning information, which is
then used to configure the device. As noted above, this provisioning
information needs to be little more than a client certificate.
For example, the device could use Enrolment over Secure Transport
(EST) [RFC7030]. It could also use vendor-specific methods.
This process works because every device capable of doing TLS is
shipped with a set of known root CAs, which are intended for use with
the web. In addition, every end user wishing to connect to a known
network is aware of the identity of that network (e.g.
"example.com"), and their their identity in that network (e.g.
"user@example.com").
If the device does not have a root CA configured, as we will see
below, it can use the limited authorization network with other
protocols such as DNS. The device could use DNS to query a pre-
defined SRV record (as with [RFC7585] Section 3). The results of
that record could be a "self signed" root CA. Certificates can
therefore be obtained over DNS, such as via the methods outlined in
[RFC4398].
The only requirement here is that the DNS record be obtained securely
(DNSSec or DNS over TLS), otherwise an attacker could forge the
response, or replace the root CA in transit.
Other methods are also possible, though not discussed here.
5.5. Trust on First Use Can be Secure
Similar provisioning methods can be be used for other TLS-based EAP
methods. In those methods, when a device connects to the network, it
could prompt the user for a username (with an NAI realm) and
password. Then, it could use that information to derive the NAI
Realm, and perform the verification steps described previously. The
device simply needs to know that it is trying to authenticate to a
DeKok, Alan Proposed Standard [Page 25]
INTERNET-DRAFT EAP Guidelines 12 July 2021
specific NAI Realm before verifying the server certificate, and needs
to verify that server certificate prior to sending any user identity
or authentication credentials to the EAP server.
That is, a device which knows that it is trying to authenticate to a
realm "example.com", can then verify that the server certificate
contains id-on-naiRealm which matches "example.com". This process is
similar to a web browser that wishes to connect to a web site for
"example.com". The client already knows that "example.com" is the
desired destination, which then means that the client must verify
that the site which it connects to has a certificate matching
"example.com".
If the device is not configured with any realm, then it has no way of
determining whether or not it should trust any EAP server. As such,
the use of the NAI realm is a critical component of this
specification.
This process is close to "Trust on First Use" (ToFU) provisioning,
with minimal knowledge required, and with a high degree of security.
From the point of view of the end user, the only actions which have
been taken are to select an SSID, and then to enter a name and
password. The process outlined here ensures that the user is
authenticated to a known and trusted network, and that the EAP peer
sends the identity and authentication credentials only to known and
trusted networks.
Some EAP methods such as TEAP [RFC7170] support provisioning of end
user devices. Since this provisioning information is automatic, it
can include additional information not discussed here. The process,
however, remains substantially similar. The client can download one
or more certificates, and then perform the validation and
configuration steps outlined above.
5.6. Additional Considerations
Note that there is no requirement that the device use only the SSID
given in the id-pe-wlanSSID field of a certificate. If the device
sees an authorized server certificate on a different SSID, then it
should proceed with authentication as discussed previously.
However, the EAP server may not permit the client to be authenticated
via other SSIDs. It is therefore RECOMMENDED that channel bindings
[RFC6677] are used in all EAP methods, in order to inform the server
about the clients local environment. Channel bindings also solve
problems with supplicants that do MAC address randomization: The real
MAC address is sent inside of the TLS tunnel, as part of the channel
binding exchange.
DeKok, Alan Proposed Standard [Page 26]
INTERNET-DRAFT EAP Guidelines 12 July 2021
Similarly, there is no requirement for the device to "pin" a
particular server certificate. If the presented server certificate
meets the criteria of known root CA; containing id-kp-eapServer; and
matching id-on-naiRealm, then the connection can be trusted. In
fact, there is no need to cache the server certificate at all.
DeKok, Alan Proposed Standard [Page 27]
INTERNET-DRAFT EAP Guidelines 12 July 2021
6. Extending the Solution
The process described above greatly simplifies the usability of EAP,
and its security. We can, however, do better.
The process described above requires changes to both supplicants, and
to the systems which issue certificates. These changes are useful,
but are not always trivial. Further, the processes still have a
bootstrapping problem, which was waved away in Section 2.2.3 during
the discussion of the worked example. The bootstrapping problem was
somewhat addressed by the use of ToFU provisioning in Section 2.6,
but there are still open issues with respect to security and
provisioning.
In this section, we describe a few was in which the remaining issues
may be addressed, in order to come up with a complete solution to the
problem. We first describe protocols such as EST [RFC7030], and then
later how DNS may also be used.
6.1. Bootstrapping via EST
EST [RFC7030] can be used to distribute previously created
certificates for CAs and servers. It can also be used by clients to
request new client certificates. As there is no distinction in EST
between public CAs and private CAs, either can be used. This feature
enables EST-capable systems to use the new OIDs defined here.
The use of EST therefore solves the certificate distribution problem
which was described earlier in the worked example for EAP-TLS.
However, the requirement here is that the client implements EST, and
not all currently do. Another requirement is that EST uses the
".well-known" relative URL from [RFC5785], and both specifications
assume implicitely that the base domain is rooted both in the web,
and in the top-level subdomain. For example the base URL for
"example.com" is given as "www.example.com". While the ".well-known"
prefix is capable of being used with other portions of the domain
name tree, there is no standard way for a client and server to agree
on its location. The location is simply implicit in the protocol.
This limitation is an issue mainly because we wish to use automatic
enrollment schemes in "captive portal" or "walled gardens", which
have limited network access. It may be possible for a system with
limited network access to reach a URI such as
"https://www.example.com/.well-known/". However, there is no
guarantee that the administrator of the main web server system for a
domain is the same as the administrator of the captive portal system.
DeKok, Alan Proposed Standard [Page 28]
INTERNET-DRAFT EAP Guidelines 12 July 2021
As a result, we need a way for both the client to discover the URI to
use, and for that URI to point to a web sever which is controlled by
the administrator of the captive portal system. The solution here is
to use DNS.
We define a DNS SRV record which points to the EST server for this
NAI realm. In order to provide for the separation of
responsibilities, we make this record specific to EAP.
The format of the SRV record is as follows:
_est._eap.<naiRealm>
An EAP client system can query for this record, and then connect to
the ".well-known" service at the provided host, in order to perform
EST. This record may point to the main EST server for a domain, or
it may point to a separate EST server which is specifically used for
EAP. We believe that it is important to make provisions for
separation of services such as these, even if this separation is not
always used.
We note that the DNS resource record type here is SRV and not URI, as
we only need to define the hostname and port for the EST server. The
rest of the URI is defined by EST.
We discuss the use of DNS in more detail in the next section.
6.1.1. Closing the loop
An EAP peer which has a username, password, and NAI realm can
leverage EST to securely provision client certificates for use with
TLS-based EAP methods.
The device first discovers the location of the EST server via the DNS
lookup above. It can then download any necessary CAs, using the
methods outlined in [RFC7030] Section 4.1 The device then uses the
username and password with HTTP basic authentication in order to
authenticate itself to the EST server. Finally, the device can
request that the EST server create and sign a client certificate,
using the methods outlined in [RFC7030] Section 4.2.
One benefit of this method is that the key associated with the client
certificate can be generated automatically by the client device, and
hidden from the user. This secrecy ensures that the client
certificate is associated with a particular device, and that the user
is prevented from copying the certificate to multiple devices.
DeKok, Alan Proposed Standard [Page 29]
INTERNET-DRAFT EAP Guidelines 12 July 2021
6.2. Bootstrapping via DNS
We have seen above that the EAP configuration problem can be largely
reduced to getting a properly formed certificate onto the device. We
show here how to use DNS to bootstrap the certificate installation.
This bootstrapping process requires no changes to supplicants or to
systems which certificates. Instead, it requires only that:
* certificates be placed at a well-known URI,
* this URI is found DNS CERT records [RFC4398],
* an independent tool downloads the certificates and uses them
to configure EAP as described above,
* the end user or device knows the NAIRealm to which it is
supposed to connect.
This process leverages both DNS, and the existing "web" root CA
infrastructure in order to securely configure EAP, with minimal
manual intervention.
6.2.1. CERT records
The process begins with the administrator obtaining one or more
server certificates as described above, and then placing them at a
well-known URI. The administrator then adds records to DNS which
point to the certificates. The client can then download these server
certificates, and configure its EAP system to use these certificates
when authenticating to the relevant NAI realm.
For the purpose of this section, we assume that the server
certificates are signed by a CA which is already known to the client
system. In the next section, we extend this process to downloading
new CA certificates.
The information stored in DNS is a CERT record as described in
[RFC4398] Section 2. If the DNS record is served over a secure
transport such as DNSSec, DNS over HTTP, or DNS over TLS, then the
record can directly contain the certificate. If the DNS record is
served over an insecure transport, then the "type" field MUST be one
with contains a URI. These requirements typically mean that value of
the "type" field will be (4), for IPKIX, which points to the URL of
an X.509 data object.
In order for this process to be secure, the URL MUST be within same
domain (NAI realm) as the CERT resource record. The URL MUST be
secured with TLS transport. The certificate presented at that URL
DeKok, Alan Proposed Standard [Page 30]
INTERNET-DRAFT EAP Guidelines 12 July 2021
MUST be issued by a root CA which is generally already known to the
device. The certificate presented at the URL MUST pass all normal
HTTPS validation, including that for id-ce-subjectAltName.
That is, when the client accesses a URL pointed to by a CERT record,
certificate validation for that access MUST be performed as per
[RFC5280]. If any of these validation steps fail, then the client
MUST NOT download or use any further data presented by that server.
Further, the contents of the data at that URL MUST be a X.509
certificate.
The downloaded certificate MUST be one with is suitable for TLS-based
EAP methods, as described in [EAPTLS]. The client system MUST verify
that the server certificate matches the NAI realm which is being
used, either via the steps defined here, or via the host name
matching defined in [EAPTLS]. If the certificate does not match the
NAI realm, then it is discarded and not used for EAP.
An issue is that [EAPTLS] provides for host name matching, but not
for NAI realm matching. The two are similar, but not identical. If
we recall [RFC7542] Section 2.5, the NAI realm is defined as:
* Realms MUST be of the form that can be registered as a Fully
Qualified Domain Name (FQDN) within the DNS.
Certificates of the form supported by [EAPTLS] therefore may still
match the given NAI realm.
The downloaded certificate SHOULD also contain id-pe-wlanSSID, in
order to inform the device as to which SSID is suggested for network
access.
Note that there is no requirement for this server certificate to
contain the id-kp-eapServer OID defined here. It is RECOMMENDED to
include that OID, but it is not required.
These requirements ensure that devices can leverage the existing web
framework to securely download certificates which are to be used for
EAP.
The use of insecure transport for DNS is acceptable, as it is only
being used to transport a URL, which is itself protected by TLS. The
URL validation requirements above ensure that an attacker can only
point the device to pre-existing URIs within the given domain, which
contain information not under the control of the attacker.
DeKok, Alan Proposed Standard [Page 31]
INTERNET-DRAFT EAP Guidelines 12 July 2021
6.2.2. CERT record labels for Server Certificates
The next problem is to define a well-known name for this record. We
leverage the [RFC8552] "Underscored" naming of attribute leaves in
order to provde for well-known names. We define a series of names,
which are all rooted from the NAI realm given by the user.
We note here that the insecurity of plain UDP DNS may, in fact, be of
use here. For example, the administrator of a captive portal can
modify the captive portal DNS server in order to serve records for
the "top level" domain, which not normally be permitted. Since this
use of DNS names is only visible from within the captive portal,
there is no security impact outside of this limited network.
The format of the CERT record is as follows:
_server._cert._eap.<naiRealm>
It can be beneficial to use a DNS CERT record instead of Enrolment
over Secure Transport (EST) [RFC7030], as our goal here is to simply
obtain a pre-existing certificate, and not to generate new
certificates. In some cases, the URL provided by DNS can just be the
URL of a certificate hosted by an EST server.
In some cases, the downloaded certificate may be from a CA which is
not known to the device. For example, when the CA is a "private CA"
which is not in the root CA list for web PKI. The next section
addresses this issue.
6.2.3. CERT record labels for CA Certificates
This CA certificate may be obtained via EST, as described in
[RFC7030] Sections 2.1 and 4.1.2. The device can also look up the CA
certificate via a similar process to obtaining the server
certificate, by querying for a CERT record at the following name:
_ca._cert._eap.<naiRealm>
Again, the URL presented here MUST match all of the requirements
given earlier for the certificate obtained from the
"_server._cert._eap.<naiRealm>" record. The only restriction on the
contents and/or format of the downloaded CA certificate is that it
MUST permit the previously downloaded server certificate to be
verified. If the server certificate cannot be verified using this CA
certificate, then both certificates MUST be discarded.
Since this new CA has been downloaded from a trusted source, the CA
can also be given limited trust. That is, the downloaded CA SHOULD
DeKok, Alan Proposed Standard [Page 32]
INTERNET-DRAFT EAP Guidelines 12 July 2021
be trusted to issue certificates for use with EAP, but only for the
NA realm in question. The downloaded CA MUST NOT be trusted for any
other use-cases or purposes. This limitation ensures that private
CAs cannot be used to spoof public web sites from unrelated
organizations.
This requirement in effect mandates implementations to create
multiple certificate stores. This limitation is the minimal change
required to supplicant implementations in order to support the core
of this specification. Every other change suggested here can either
be pushed to an auxiliary tool, or can be delayed until a later step.
That is, the user-visible workflow here can be implemented with
minimal changes to the supplicant software which implements EAP.
7. Related issues
We discuss related issues in this section. The items discussed here
are individually useful to discuss, but do not follow a clear
developmental flow. As such, they are placed into a separate
section.
7.1. Provisioning Issues
There are a number of issues related to provisioning. We show that
there is no need to use a single network for all of the above
discovery and configuration. We show that configuration updates are
simple, and are no more difficult than repeating the initial
provisioning. Finally, we describe why the methods defined herein
are significantly more secure than ToFU.
7.1.1. Bootstrapping via a Separate Network
There is no requirement that a particular network provide all of the
bootstrapping outlined above via a "guest network". It is also
possible to leverage the public Internet in order to bootstrap
authentication to a private network which requires EAP
authentication.
For example, a mobile phone may be trying to connect to a WiFi SSID,
while it also has additional network access via 3G or LTE. There is
no requirement here for the WiFi network to provide a guest network
with full provisioning capabilities. Instead, the phone can simply
try to do unauthenticated EAP-TLS. During the EAP-TLS negotiation,
the device will obtain a copy of the server certificate. This
certificate should contain id-on-naiRealm.
The device can then use the LTE connection, and the process outlined
DeKok, Alan Proposed Standard [Page 33]
INTERNET-DRAFT EAP Guidelines 12 July 2021
above (DNS, EST, etc.) in order to verify that the server certificate
is the one which meets all of the criteria necessary for full
authentication. Once the server certificate is validated and the
device has updated its configuration, it can drop the EAP-TLS
connection, and re-authenticate using any TLS-based EAP method.
With this process, the experience for the end user would be little
more than:
* select an SSID,
* be informed that this is a network associated with a particular NAI
realm (i.e. domain),
* be informed that the network is secure and is trusted,
* be requested to enter an identity and password within that domain,
* enter that identity and password, and obtain network access.
This process is little different from using a web browser to navigate
to a web site, and ensuring that the green "lock" icon is set for
that site.
7.1.2. Configuration Change is just Refresh
Any automatic provisioning scheme has the problem of performing
change control. In our case, updating the configuration which a new
set of data is largely just repeating the bootstrapping process. The
questions then become how often to check for updates, how long to
cache configuration, etc.
It is RECOMMENDED that HTTPS servers which provide the certificates
described in the previous section set the Cache-Control [RFC7234]
directive in the response. It is RECOMMENDED that the "max-age"
directive ([RFC7234] Section 5.2.2.8) be used. The value returned
SHOULD NOT be less than one day (86400 seconds), and MUST NOT go past
the expiry date of the certificate which is being returned.
The supplicant which is retrieiving the certificate SHOULD annotate
the certificate with the value of the "max-age" directive. The
supplicant SHOULD perform the bootstrapping checks again prior to the
"max-age" time limit being reached.
Where "max-age" is not returned, the supplicant SHOULD refresh the
bootstrapping checks again no more than once per day. It SHOULD
track when the certificate was downloaded, and then perform these
checks no later than when the certificate is halfway to expiry, taken
DeKok, Alan Proposed Standard [Page 34]
INTERNET-DRAFT EAP Guidelines 12 July 2021
from when the supplicant first downloaded the certificate.
When either the root CA or server CA has expired, the supplicant MUST
NOT use them to obtain network access. It SHOULD refresh the
certificates at that time. If the certificates are not refreshed,
then the relevant configuration SHOULD be deleted.
If the refreshed certificate is identical to the previously
downloaded certificate, then the supplicant takes no actions other
than to update its refresh timers.
If the refreshed certificate has changed, then the supplicant
performs all of the validation checks described above. If the tests
pass, the new certificate can be used in place of the previous one.
Note that there is no need to "tear down" the current network
connection if the current certificate is still valid. The new
configuration should be used only when the device next requests
network access.
As the old credentials are usually still valid, device SHOULD keep
the old credentials around until such time as it has verified that
the new credentials work. If the new credentials do not obtain
satisfactory network access, then they should be discarded, and the
device should try again not sooner than one day later.
TBD: There should also be fine-grained methods to control when a new
configuration is downloaded, and separately when it is applied. For
client certificates, we can use the "notBefore" field, which
indicates that the certificate is not valid before a particular time.
7.1.3. Secure versus Insecure Provisioning
We now revisit the discussion of ToFU first mentioned above. We note
that the process defined here isn't even "trust on first use".
Instead, it is leveraging the web PKI in order to get secure,
authenticated downloads of non-web certificates. ToFU provision such
as used in TEAP is essentially a standardized way to download
security configuration from an insecure source.
Our proposal here begins with the naiRealm, and then uses trusted
roots and secure protocols to download security configuration from a
known and trusted source. While this process is more complex than
TEAP, in that it requires DNS and HTTPS, it is also more secure.
7.2. Issues related to Security
We explain why id-on-naiRealm was chosen. We describe some issues
related to resumption, and the use of certificates in a multi-server
DeKok, Alan Proposed Standard [Page 35]
INTERNET-DRAFT EAP Guidelines 12 July 2021
environment. We explain how this solution can be extended to
configure individual EAP types. We explain how this solution is
applicable when either private or public CAs are used. We conclude
by explaining how the user experience offered by this solution
creates a simple and clear user experience.
7.2.1. Why id-on-naiRealm
Server certificates used with EAP have historically contained DNS
names. This practice is largely because the certificates are "TLS
web server" certificates. However, [RFC7585] Section 2.2 explains
why DNS names are not appropriate:
Current subjectAltName fields do not semantically allow an NAI
realm to be expressed; the field subjectAltName:dNSName is
syntactically a good match but would inappropriately conflate DNS
names and NAI realm names. Thus, this specification defines a new
subjectAltName field to hold either a single NAI realm name or a
wildcard name matching a set of NAI realms.
We extend the above requirement to say that the wildcard name MUST be
limited to a subset of one realm. That is, a wildcard of
"*.example.com" is permitted, but a wildcard of "*", or "*.com", is
forbidden.
Although this recommendation was done in the context of RADIUS, this
field is exactly what is needed for EAP. The definition is the same
(NAI), and the use-cases are the same.
7.2.2. Resumption
[RFC8446] Section 4.6.1 discusses resumption:
Clients MUST only resume if the new SNI value is valid for the
server certificate presented in the original session and SHOULD
only resume if the SNI value matches the one used in the original
session. The latter is a performance optimization: normally,
there is no reason to expect that different servers covered by a
single certificate would be able to accept each other's tickets;
hence, attempting resumption in that case would waste a single-use
ticket. If such an indication is provided (externally or by any
other means), clients MAY resume with a different SNI value.
-0.3i
Similar requirements apply for EAP, except that clients check id-
on-naiRealm instead of using SNI.
Where multiple servers are in an high availability or load-balance
DeKok, Alan Proposed Standard [Page 36]
INTERNET-DRAFT EAP Guidelines 12 July 2021
group, they SHOULD use the same certificate. Where the same
certificate is used, then either the resumption master secret MUST
be shared among all systems, or the tickets MUST be accessible to
all systems. Preferably by putting them into an external data
store.
7.2.3. Choosing EAP Types
We note that this specification does not define which EAP type is
used by the supplicant, except implicitly. That is, if the
supplicant is given a client certificate, then it is presumed that
EAP-TLS is being used. Otherwise, the supplicant should choose some
other TLS-based EAP type.
It would be possbile define new OIDs which define a list of EAP types
that the EAP server will accept. These OIDs can then be placed in a
server certificate, where they can inform the supplicant as to which
EAP types should be used.
7.2.4. User Experience
It is RECOMMENDED that the system notify any end user of the
configuration changes being performed. It is RECOMMENDED that these
notifications give sufficient information to the end user, so that an
informed decision can be made. It is RECOMMENDED that these
notifications allow the user to stop or cancel the process at any
time.
The goal of the user experience described that it should be little
different from using a web browser to navigate to a web site, and
ensuring that the green "lock" icon is set for that site.
Is is therefore RECOMMENDED that supplicant vendors update their user
interfaces to clearly distinguish between "trusted" and "untrusted"
network access. A "trusted" network is one which satisfies all of
the criteria outlined herein. An "untrusted" network is one which
satisfies only some, or none of the criteria outlined here.
It is likely a good idea to update the graphical user interface (GUI)
for as supplicant with a green / red lock icon, similar to that used
in web browsers. Further, the GUI should also include the naiRealm
which has been verified, as web browsers show the domain name which
has been verified. This information is enough to give the user
enough information to meaningfully consent to obtaining network
access, and to enter credentials.
That is, if the user sees that the operating-system GUI window says
"this site is trusted", and also "you are accessing the example.com
DeKok, Alan Proposed Standard [Page 37]
INTERNET-DRAFT EAP Guidelines 12 July 2021
domain", then the user can safely enter credentials for that domain.
This workflow is familiar to end users, and has been proven to be at
least moderately successful in the web.
7.3. Issues related to Certificates
There are a number of other issues related to certificates, in
addition to those which have been raised above.
TBD: more explanation of the trailing sections.
7.3.1. Public CA versus Private CA
Nothing in this specification requires the use of either a public or
private CA. Both are possible, and both have issues.
The main issue with using a private CA is that it is not already on
the device, and has to be provisioned. While there are many possible
methods of provisioning this information, we define here only a few
straightforward methods. We hope that the method proposed here (DNS
+ HTTPS) is clear, and simple for administrators to implement.
There is still the requirement that the client device have new
software to obtain this information and call the supplicant API.
However, this process is no different than installing custom MDM
software.
Private CAs have the benefit of being able to sign certificates with
any EKU they desire. These certificates can then be marked with an
EKU as being intended for a particular use, and supplicant software
can verify these EKU fields.
The issues with public CAs are described above. Public CAs are
likely to refuse to sign certificates which contain the EKUs proposed
here, and appear to be uninterested in offering a different product
which would sign such certificates. Further, using these
certificates for EAP appears to be against their intended purpose,
and is therefore misuse.
However, the benefit of using public CAs is that they are already
configured on most devices, and it is relatively simple to obtain
certificates from them.
In the end, local administrators can choose whatever CA is best for
them. Our goal here is to simplify the process of using a CA and
server certificate for EAP. It is best to give administrators and
implementors a few simple options which meet their needs, rather than
DeKok, Alan Proposed Standard [Page 38]
INTERNET-DRAFT EAP Guidelines 12 July 2021
mandating one particular solution which is likely to not meet the
needs of a large set of users.
7.3.2. Limitations of public CAs
Recent changes to the CAB guidelines limit certificate validity
periods to 397 days. While this change may be good for the larger
WWW framework, it is not clear how it benefits other protocols such
as EAP. Additional changes include limiting the kind of domain
validation methods permitted, and forbidding file-based validation
for wildcard certificates.
Part of EAP "best practices" is to ensure that EAP (or AAA) servers
have minimal exposure to the public Internet. In order to use
certificates from a public CA therefore, administators must choose
between either exposing their EAP server via WWW (in order to perform
validation), or to expose a different WWW server, and then also
simultaneously install the same certificate on the EAP system.
Neither option is a good one.
In addition, limiting the certificate validity period means that
clients see the server certificate change much more often than has
been previously the case. This higher volume of changes was
historically perhaps not an issue, as we have seen above that some
systems perform limited checks on server certificates.
The benefit of the process outlined here is that the server
certificate either becomes trivially verifiable (even if it changes),
or installing a new server certificate becomes a trivial and secure
process.
On the other hand, if there is no automated process to update the EAP
client configuration, then users will simply be trained to mindlessly
click "accept" when they are presented with a new certificate. As
this process will happen much more often than has historically been
the case, this maladaptive behavior by users will be even more
strongly enforced.
Another issue with public CAs is that intermediate CA certificates
are significantly more expensive than a server certificate. The
reason here appears to be economic: if intermediate CA certs were
cheap, then an organization would simply purchase one, and then use
that CA cert to issue many server certificates.
This limitations means that EAP-TLS is significantly more difficult
to deploy in practice and PEAP or TTLS. The administrator has to
choose between either purchasing an extremely expensive intermediate
CA certificate, or using a private CA.
DeKok, Alan Proposed Standard [Page 39]
INTERNET-DRAFT EAP Guidelines 12 July 2021
The use of intermediate CAs has other issues, as we will see in the
next section.
7.3.3. CA Chains
Some administrators wish to use multiple CAs for security. For
example, a large organization could have one CA which is controlled
by a security group. That CA could issue intermediate CA
certificates to other groups with the organization. These CAs could
be issued on multiple grounds, such as geographic location, or
function units.
In practice, this process could result in there being one CA which is
used for EAP / AAA, another CA which is used for internal web sites,
and another CA for organizational Virtual Private Network (VPN)
usage.
We have worked through all of the examples and discussion above by
largely assuming that there was one "root" CA. Now that we see this
assumption is insufficient, we must then discuss, and solve, the
issue of intermediate CAs.
If an application were to simply trust the "root" CA, then by
inference it would also trust all intermediate CAs. This trust means
that an EAP administrator who can issue client certificates could
potentially configure that client certificate for use in another
protocol, such as with a VPN. Such misuse could lead to unauthorized
users obtaining access to resources.
The solution here is two-fold. One, applications which accept client
certificates SHOULD be configured to trust a particular issuing CA,
which may not be the "root" CA. That is, simply having a certificate
store of root CAs is insufficient. Instead, the application needs to
track a particular intermediate CA.
Another solution is to simply move to purpose-specific EKU fields.
An EAP client which follows this specification can require that the
EAP server contain an id-kp-eapServer field. The EAP client can then
rely on policy within the issuing framework to ensure that all
relevant certificates also have an id-kp-eapServer field. Similarly,
and EAP server which follows this specification can ensure that EAP
clients are presenting certificates which contain id-kp-eapClient.
That is, the use of id-kp-serverAuth for all possible applications
means that it is impossible to limit the use of certificates to one
particular application. An administrator or end user is free to
(mis-)use any certificate for almost any purpose.
DeKok, Alan Proposed Standard [Page 40]
INTERNET-DRAFT EAP Guidelines 12 July 2021
We would suggest that having purpose-specific key usage fields is
preferable. Such fields would make it simpler for both clients and
servers to have more fine-grained control over certificate usage.
7.3.4. Delegated Authentication
In some cases an organization may delegate EAP / AAA functionality to
another organization. This can happen for example, when an
organization does not wish to run authentication servers itself, but
instead delegates that functionality, say to an identity provider
(IdP). The delegated functionality may be operated by an
organization which handles "authentication as a service" for multiple
customers.
A current solution is for the IdP system to present a server
certificate which contains a list all of the domain names which it
services. The problem is that this list can change often, which
means that the old certificate must be revoked, and a new one issued.
If these changes happen regularly, then this "churning" of
certificates can cause problems for clients which cache the server
certificate. There is also the management overhead of updating the
certificate. Over all, this process is not scalable.
The processes outlined here allow for simple discovery and
configuration of TLS-based EAP methods, but they do not entirely
solve this problem.
The problem can be solved, however, by noting that the public EAP
Response Identity used should be in the form "@realm", as per
[EAPTLS] Section 2.1.7. An EAP server will receive this identity in
the first EAP packet, at which point the server can select and
present a certificate which is appropriate for that realm.
The result is that an IdP needs to be configured only with one server
certificate for each NAI realm that it manages. When an NAI realm is
added, deleted, or updated, those changes affect only the
configuration for the modified realm. Any other organization or NAI
realm is not affected.
This solution is simple and scalable.
7.3.5. Identification of Networks
While the examples above used an SSID to identify a network, there
are other ways of network identification.
One is the Roaming Consortium Organisation Identifiers (RCOI), which
are organizational identifiers which are assigned by the IEEE (REF
DeKok, Alan Proposed Standard [Page 41]
INTERNET-DRAFT EAP Guidelines 12 July 2021
TBD). They can be 24 or 36 bits. These organizations are global, and
can identify a vendor, operator, consortium, or other organization.
This section defines the RCOIdentifier name as a form of otherName
from the GeneralName structure in subjectAltName defined in
[RFC5280].
id-on-RCOIdentifier OBJECT IDENTIFIER ::= { id-on TBD }
ub-RCOIdentifier-length INTEGER ::= 255
RCOIdentifier ::= OCTET String (SIZE (1..ub-RCOIdentifier-length))
This field can be used in either a client certificate or a server
certificate. With either usage, it indicates to the client which
RCOI should be used for accessing network services.
7.4. Anti-solutions
In this section, we explain why a number of existing technologies do
not solve the problems which are addressed by this specification.
7.4.1. MDM Products Are not the Solution
MDM products are not the solution. Solutions like Eduroam CAT [CAT]
are simple and easy to use, but they are only one of many possible
products. In the extreme case, each end user has to download one MDM
product for each network being accessed, and then repeat that process
across each of many devices being used to access those networks.
These solutions are not just expensive, and non-standard, they are
not scalable. It is difficult to scale the solutions to millions of
disparate devices, as software has to be written and verified for
each vendor, and often for each firmware version supplied by a
vendor.
In addition, MDM prodicts do not scale for an individual device.
Each MDM product usually assumes that it is in complete control of
the device, which makes it difficult or impossible to install
multiple products. For example, a contractor who works for multiple
companies may need multiple conflicting MDM products. Or, an
employee may be required to install an MDM product on a personal
device, which makes it difficult to say who actually owns that
device.
These MDM products typically also are capable of remotely wiping the
device, such as when a contractor or employee leaves an organization.
If the device was bought for personal use, there are ethical and may
DeKok, Alan Proposed Standard [Page 42]
INTERNET-DRAFT EAP Guidelines 12 July 2021
also be legal implicatations. Other issues are the loss of critical
data such as documents or personal photographs.
Or perhaps even worse, when an MDM product is in complete control of
a device, then there is plausible deniability for a user, for any
action taken on that device. It is likely defensible to claim that
the user is not responsible, because "the remote admin had full
control", or perhaps "the remote admin is running software which
controls my device".
There are serious security issues with a user not being in control of
their own device.
In contrast, a standard discovery and configuration method, run by
devices at the edge, which leverages DNS and HTTP is proven to work
at Internet scales. They are implemented once by each vendor, and
then maintained afterwards. As the configuration for each
organization (NAI realm) is separate, there are minimal issues with
installing multiple configurations on the same machine.
However, in the interest of enabling multiple solutions, we also
define an [RFC8552] URI record. This record points to a location
where a client device can download an MDM solution which is specific
to a particular organization.
The format of the URI record is as follows:
_install._mdm.<naiRealm>
This record SHOULD NOT be visible on the public Internet, i.e. the
public DNS servers for that NAI Realm. Doing so would permit
malicious actors to download and examine the MDM software. Instead,
this record SHOULD be available only inside of the organizations
private network. Either to devices which have used 802.1X in order
to authenticate themselves to the organization, or to devices which
are using private IP address ranges.
The server which hosts the URI SHOULD use device fingerprinting in
order to provide a system-dependent MDM solution.
As with the requirements on certificates above, the URI MUST be
within same domain (NAI realm) as the CERT resource record. The URI
MUST be secured with TLS transport. The certificate presented at
that URI MUST be issued by a root CA which is generally already known
to the device. The certificate presented at the URI MUST pass all
normal HTTPS validation, including that for id-ce-subjectAltName.
If any of these validation steps fail, then the client MUST NOT
DeKok, Alan Proposed Standard [Page 43]
INTERNET-DRAFT EAP Guidelines 12 July 2021
download or use any further data presented by that server.
If the validation steps succeed, then the client device can download
and run the MDM software which has been provided at that URI.
Where possible, the client MUST inform any human user that these
steps are being taken, and MUST give the user the ability to prevent
this download from happening. There are many situations where the
client device is owned by the end user, and not the organization
which is being accessed. As such, it is inappropriate to mandate
that software be automatically installed.
However, there is also no requirement that an organization grant
access to devices which do not follow the organizations policy. The
organization is free to deny the device network access until such
time as the MDM software has been installed.
7.4.2. EST and similar protocols do not solve all of the problem
Certificate provisioning solutions like EST [RFC7030] or Simple
Certificate Enrolment Protocol (SCEP) [RFC8894] are useful, but they
do not solve the underlying problem we solve here.
EST and SCEP are useful for provisioning CA certificates to end
devices, and for end devices to request and provision client
certificates. However, these processes generally configuration on
the client device, and also an unrestricted network connection.
Part of the problem we are trying to solve here is supplicant
configuration, and EST / SCEP do not help.
Further, EST can require complex bootstrapping. Section 2 of
[RFC7030] says:
Both the EST clients and server are configured with information
that provides the basis for mutual authentication and for
authorization. The specific initialization data depends on the
methods available in the client and server, but it can include
shared secrets, network service names and locations (e.g., a
Uniform Resource Identifier (URI) ...), trust anchor information
(e.g., a CA certificate or a hash of a TA's certificate), and
enrollment keys and certificates.
In contrast, the method proposed here requires that the client device
have a known root CA from the web PKI, and the ability to do DNS and
HTTPS. This capability is available on essentially all systems which
can access the public internet.
DeKok, Alan Proposed Standard [Page 44]
INTERNET-DRAFT EAP Guidelines 12 July 2021
The reason for this simplification is that the problem we are trying
to solve for EAP is substantially smaller than the problem that EST
is trying to solve.
We conclude by noting that our solution is entirely compatible with
EST, in that the DNS query for "_ca._cert._eap.example.com" could
return a CERT record which points to the URL of the EST server, for
example "https://example.com/.well-known/est/cacerts", as described
in [RFC7030] Section 4.1.2.
7.4.3. Captive Portals and Hotspots
Captive portals and hotspots have been traditionally used as a method
of controlling network access, as with EAP. The use-case for captive
portals is that the client devices can do DNS and HTTP, but that they
do not have credentials already provisioned. The captive portal is a
way to introduce humans into the process, by displaying information,
and asking for credentials such as credit cards, etc.
There are, of course, a number of issues with captive portals. It
may take the client device some time to determine that it is in a
captive portal. The information displayed on a captive portal page
may be confusing to the end user, or may even be in a language which
the user does not understand.
Automating the onboarding process means that almost all of these
issues are resolved.
7.5. id-kp-eapOverLAN May not be sufficient
While [RFC4334] Section 2 defines id-kp-eapOverLAN, it gives no
explicit use-case for that EKU. That document suggests that the EKU
is intended for use in client certificates. However, it also can be
read to suggest that the EKU could also be used in server
certificates.
As such, we define a new EKU, id-kp-eapClient. If it is determined
that this new EKU is not needed, this document can be updated before
final publication to use id-kp-eapOverLAN instead of id-kp-eapClient.
7.6. Guest Networks
For EAP-TLS, [EAPTLS] Section 2.1.5 provides for the protocol to be
used without peer authentication. The methods outlined here can be
extended to perform provisioning within guest networks. That is, the
device suspects the identity of the network, but also knows that it
does not yet have credentials for use within that network.
DeKok, Alan Proposed Standard [Page 45]
INTERNET-DRAFT EAP Guidelines 12 July 2021
Where an EAP peer wishes to connection to the network, but does not
know the identity of the network, it SHOULD use EAP-TLS without peer
authentication. That is, it should obtain the server certificate
without providing a client certificate.
This server certificate can be examined for identification fields,
such as id-on-naiRealm. The supplicant SHOULD query the network for
the expected server certificate, using the DNS discovery process
outlined above.
Thee certificates and related network configuration which are
discovered this way SHOULD NOT be cached for more than one day.
While on the provisioning network, the device can use almost any
method to authenticate and authorize the end user. For example,
having a "self service" registration page, obtaining temporary
credentials, etc.
It is RECOMMENDED that the guest network permit the device to obtain
email from anywhere on the Internet, via standard email reception
protocols. It is RECOMMENDED that all other ports be blocked. Port
25 (SMTP) MUST be blocked. All DNS ports MUST either be blocked, or
be forwarded to a DNS server controlled by the administrator of the
guest network.
Network access SHOULD be restricted in both time and usage. There is
no reason to allow unauthenticated guest access for more than about
30 minutes. There is no reason to allow unauthenticated guests to
transfer gigabytes of data.
These requirements allow the provisioning process to be simple. A
device uses EAP-TLS without peer authentication to connect to a
network. The user enters an email address in a "self service"
registration page. The visited network determines whether or not the
person using that email address is authorized. If so, it sends a
message to that address with a unique URL.
The user obtains the email, clicks on the URL, and downloads
credentials for the visited network. These credentials could be an
EAP-TLS client certificate, which has the following properties:
* issued by the visited network * containing information identifying
the end user * ideally also contains information identifying the
device * has a limited lifetime, ideally one day * lifetime MUST be
less than 30 days.
The device then provisions the credentials as above.
DeKok, Alan Proposed Standard [Page 46]
INTERNET-DRAFT EAP Guidelines 12 July 2021
This process could also be extended by leveraging DNS even more. The
client device could look up a CERT record based on the user's
identifying information, e.g. for a user with identifier
"user@example.com", visiting a particular naiRalm it could look up a
CERT RR of:
user.example.com._guest._cert._eap.<naiRealm>
The local network could return a custom CERT RR, pointing to a URL
for a page which contains a custom client certificate for use with
EAP-TLS.
As most DNS servers have limited policy capabilities, this
functionality is likely difficult to implement in practice.
7.7. Using TLS with protocols other than EAP
While the discussion so far has been about EAP, there is no reason to
limit this process to EAP. However, we do note that the methods
defined here are intended for bootstrapping access to secure
networks. They are not intended for use with generic web browsing.
For example, it is possible to use similar methods (though with
different DNS names and EKU fields) in order to configure clients for
other protocols such as RADIUS/TLS [RFC6614] or RADIUS/DTLS
[RFC7360].
These methods are not limited to RADIUS and EAP. For example,
discovery of an IMAP server could be done via looking up a SRV record
for "_imap._tcp.<naiRealm>", while discovery of an email submission
server could be done via looking up "_submit._tcp.<naiRealm>". If a
private CA is used for those services, it could be discovered via
looking up a CERT record for "_ca._imap._tcp.<naiRealm>".
Similarly, the issue of intermediate CAs discussed earlier is also
applicable to other protocols, and therefore requires similar
solutions. We also note that there are issues with many other non-
WWW protocols which appear to (mis)-use the id-kp-serverAuth field.
We offer no solution here to that problem.
It may be possible to use these processes in many other situations,
but we do not discuss those use-cases in detail here. We only
discuss them as a side note, to demonstrate that automatic
provisioning of a client system can be done simply, securely, and
with minimal intervention by an end user.
DeKok, Alan Proposed Standard [Page 47]
INTERNET-DRAFT EAP Guidelines 12 July 2021
8. Moving to the new methods
The methods given herein are intended to give parties in an EAP
conversation more, and better information about what should be
happening, and about what is happening. If all of the recommended
information is available, then all parties in an EAP conversation
have strong, positive indications that the system is secure. If any
information is missing or conflicting information is seen, then the
system may or may not be secure.
That is, following the recommendations is a positive signal of
security. Lack of positive signals does not necessarily indicate
insecurity.
It is RECOMMENDED that EAP peers and authenticators which implement
these processes add configurable flags which allow the
recommendations to be made mandatory. These configurable flags
SHOULD permit the recommendations to be enforced in a wide range of
conditions, such as per SSID, per realm, per CA, etc. Doing so will
allow administrators to make and enforce site-local policies.
For example, a company might mandate that all devices which connect
to WiFi use EAP with client certificates, that those client
certificates contain the fields defined above, and that those devices
only send authentication credentials to EAP authenticators which also
satisfy the recommendations above. When an EAP peer follows these
mandates, it will not be vulnerable to any of the attacks outlined
earlier.
These guidelines allows existing systems to operate unchanged. They
also allow updated systems to gain the benefit of increased, and
mandated, security.
8.1. Using the new OIDs
In general, we recommend using private CAs for EAP. Such uses avoid
the issue of certificate misuse under the [CAB] guidelines.
We also have to address how systems which are unaware of this
specification will interact with certificates containing the new
OIDs.
Happily, the requirements of [RFC5216] and [EAPTLS] are requirements
on what should exist, and not on what should not exist. Tests with
implementations, and (where possible) checks of publicly available
source code lead us to conclude that these requirements are
accurately followed.
DeKok, Alan Proposed Standard [Page 48]
INTERNET-DRAFT EAP Guidelines 12 July 2021
The solution then is for server certificates to contain both id-kp-
serverAuth, in order to satisfy [RFC5280], and also to contain id-kp-
eapServer, in order to satisfy this document. The result is that
both old, and new behavior is supported, and that the transition path
from one to the other is seamless.
8.2. Recommendations for EAP peers and authenticators
It is RECOMMENDED that EAP peers use a dedicated certificate store
for EAP. Where a dedicate certificate store cannot be used, each
certificate MUST have additional metadata stored with it, which
indicates its permitted uses. This metadata serves as a way of
creating "per-use-case" certificate stores.
It is RECOMMENDED that no CAs are enabled by default for EAP. User
credentials are provisioned from a known authentication source. If
there are no local user credentials configured, then by definition
there are no known sources. When credentials are configured, known
sources can be enabled at the same time.
It is RECOMMENDED that "web" CAs are not used for EAP. The two use-
cases are different, and misuse of certificates opens both EAP and
WWW systems to attacks.
It is RECOMMENDED that EAP peers do not perform TLS resumption across
different media.
It is RECOMMENDED that when EAP peers use any TLS-based EAP method
with a client certificate, that the client certificate contains id-
kp-eapClient in order to indicate that the certificate is intended to
be used by an EAP peer.
it is RECOMMENDED that EAP peers expose configuration settings which
allow the user to permit this new behavior, or require it, on a per-
NAI realm basis.
It is RECOMMENDED that EAP servers which permit the use of client
certificates mark one or more CAs as being permitted to issue client
certificates. These CAs SHOULD be the one which is the "lowest" in
the certificate chain. That is, the one which is closest to the
client certificate. EAP servers SHOULD NOT mark a global "root" CA
as being permitted to issue client certificates, as that root CA may
sign many intermediate CAs, each of which could then issue client
certificates.
It is RECOMMENDED to use id-pe-wlanSSID [RFC4334] in client and
server certificates. When used in a client certificate, it informs
the client that this certificate should be used when the given SSID
DeKok, Alan Proposed Standard [Page 49]
INTERNET-DRAFT EAP Guidelines 12 July 2021
is seen. When used in a server certificate, it informs the client
that the server is intended to be reachable from this particular
SSID. Note that a mismatch is not necessarily an error.
It is RECOMMENDED that when EAP authenticators use any TLS-based EAP
method with a server certificate, that the server certificate
contains id-kp-eapServer in order to indicate that the certificate is
intended to be used by an EAP authenticator.
It is RECOMMENDED that when EAP authenticators use any TLS-based EAP
method with a server certificate, that the server certificate
contains one or more naiRealm, to indicate that the EAP authenticator
is authorized to accept authentication requests for users in those
realms.
The requirements of [RFC7585] Section 2.2 on the definition, number,
and format of naiRealm are included here by reference.
It is RECOMMENDED that when EAP peers use any TLS-based EAP method,
that the EAP peer verify that the server certificate presented
contains id-kp-eapServer, and an naiRealm which matches the NAI (if
used) in the EAP Identity Response. Any mismatch indicates to the
client that the server is not trusted to authenticate users for that
realm. Therefore user credentials for that NAI realm should not be
sent to the server.
It is RECOMMENDED that when EAP authenticators use any TLS-based EAP
method and a client certificate is presented, that the EAP
authenticator verify that the client certificate contains id-kp-
eapClient, and that the NAI (if used) given in the EAP Identity
Response field matches one of the naiRealm fields in the server
certificate. Any mismatch indicates to the server that the client is
either misconfigured, or is acting maliciously. The server should
therefore treat this mismatch as an authentication failure.
As noted above, the use of the label "*" in id-on-naiRealm is
forbidden for this specification.
Where the server certificates do not contain naiRealm, but do contain
one or more subjectAltName field of type dNSname, clients SHOULD
verify that the NAI realm used by the client is an exact suffix of
the dNSname field.
DeKok, Alan Proposed Standard [Page 50]
INTERNET-DRAFT EAP Guidelines 12 July 2021
8.3. Principles and Guidelines
After analysis of the historical practices and standards for EAP, we
came to a set of guidelines which are outlined in this section.
Application of these guidelines drove the rest of the specification
which we define herein.
It is RECOMMENDED that the guidelines given below are followed when
developing new network configuration standards and methods:
* Automated provisioning is strongly preferred to manual
provisioning. We define "automated provisioning" as provisioning
which is performed via software, with little or no user
intervention. Automation minimizes the possibility for end users
to create broken or insecure configurations.
* Manual provisioning should be limited to "Trust on first use"
(ToFU), and cached or "pinned" after that. That is, manual
provisioning should be limited to allowing a user to approve
validation decisions which have been made by the system.
* Relying on end users to manually configure complex systems
is strongly discouraged. Complex systems are difficult to
configure, and improperly configured systems create many issues
related to security, usability, and network access.
* Configuration should be "pinned" in order to permit systems to
detect and prevent unauthorized changes, and to detect malicious
networks which claim to be updated versions of the true network.
* The identity and role of both parties should be exchanged, and
verified. In practice, this suggestion often means that TLS-based
EAP methods are preferred to ones which only do name / password
credential verification.
* The previous requirement usually means that the both parties know
which RFC 7542 NAI realm is being used. This realm serves a
similar purpose to the the DNS host name used in other TLS-based
protocols such as HTTPS. As such, similar methods can be used to
validate certificate authenticity. This NAI realm is contained in
an id-on-naiRealm field, as defined in [RFC7585] Section 2.2
* For TLS-based EAP methods, trust should be based on a
certification authority (CA), which signs certificates for a
particular realm. If the CA is trusted, then everything derived
from that CA can be trusted. If the CA is not trusted, then it is
impossible to trust anything derived from an untrusted CA.
DeKok, Alan Proposed Standard [Page 51]
INTERNET-DRAFT EAP Guidelines 12 July 2021
* CAs should also be associated with permitted uses. For example, a
root CA which is trusted for web surfing is not necessarily trusted
for use with EAP authentication. In practice this means either
having separate certificate stores for different purposes, or
annotating root certificates with their permitted uses.
We believe that these recommendations are correct, simple, practical,
and will improve security and usability for all participants in EAP.
We show that there is a clear upgrade path from current behavior to
better behavior. Each step of that upgrade path is simple, and
involves minimal change for end users or administrators.
9. Security Considerations
There are a large number of security issues with current practices.
This document attempts to give both fixes, and a transition path to a
better system. As such, the entire document is discussing security
issues.
One of the main points of this document is that systems which are
difficult to configure are likely to be insecure.
This document also highlights problems with misuse of certificates
containing id-kp-serverAuth, and id-kp-clientAuth. If such misused
certificates were to be widely reported, then large parts of the
Internet could be taken offline.
We note that distribution of these certificates MUST NOT be done via
email. There is just too much possibility for forgery and user
mistakes for that process to be secure. We instead rely on secure
transport layers and cryptographically signed data in order to
bootstrap authenticated network access.
9.1. On Identities and Service Discovery
All the user needs is on identity (e.g. "user@example.com"), and a
password. Essentially everything else required for network access
can be derived automatically, and provisioned with no additional user
input. This process is significantly more secure than manual
provisioning.
9.2. Password Hashing and Storage
In some situations, using client certificates with EAP is preferable
to using password-based methods. Password-based EAP methods often
hash the password along with a salt or a challenge, and then send the
hashed version of the password. However, this hashing can conflict
with the desire of administrators to store hashed passwords in their
DeKok, Alan Proposed Standard [Page 52]
INTERNET-DRAFT EAP Guidelines 12 July 2021
user databases. The two different hashing methods are almost always
incompatible, which means that the administrator has to choose either
to send passwords via a method such as PAP inside of TTLS, or to
store clear-text passwords in their local user database.
Neither choice is optimal. Where there is a trade-off, it is
RECOMMENDED that systems use a method such as TTLS with PAP, and then
store hashed or encrypted passwords in the local user database. The
"clear-text" password which is sent in TTLS is, in fact, secured via
TLS when it is sent "over the wire". So there is minimal security
risk with this approach.
While some would argue that exposing the users clear-text password to
an EAP Server is a security risk, it is in practice irrelevant. The
EAP server is almost always co-located with an AAA server (e.g.
RADIUS or Diameter). Those servers control network access for entire
organizations, including setting complex policies. Any attacker who
gains control of an AAA server can take many more, and worse actions
than simply observe peoples passwords.
In contrast, history shows that exposure of user databases (with
names and passwords) is not uncommon. In fact, as the EAP or AAA
server usually has complete access to the user database (including
passwords), compromise of the AAA server almost by definition leads
to compromise of the local user password database.
We therefore make the trade-off which has the lowest possible
security impact, for all failure cases. Passwords SHOULD be stored
hashed or encrypted in a user database. TLS-based EAP methods which
rely on passwords SHOULD use authentication methods which are
compatible with such password storage methods, which generally means
that the passwords are sent by the user in clear-text, but protected
by TLS.
10. IANA Considerations
This section this specification requests from Internet Assigned
Numbers Authority (IANA) registration of the following items.
10.1. Key Purpose OIDs
We request registration of values related to the certificate key
purpose OIDs in accordance with [RFC8126].
* id-kp-eapServer
* id-kp-eapClient
DeKok, Alan Proposed Standard [Page 53]
INTERNET-DRAFT EAP Guidelines 12 July 2021
10.2. Underscored and Globally Scoped DNS Node Names
Per RFC 8552, please add the following entry to the "Underscored and
Globally Scoped DNS Node Names" registry:
+---------+----------------------+---------------------------------+
| RR Type | _NODE NAME | Reference |
+---------+----------------------+---------------------------------+
| CERT | _ca._cert._eap | <this document> |
| CERT | _client._cert._eap | <this document> |
| CERT | _server._cert._eap | <this document> |
| SRV | _est._eap | <this document> |
| URI | _install._mdm | <this document> |
+---------+----------------------+---------------------------------+
We note that [RFC8552] does not provide for "sub" registries, as we
have defined above. However, we believe that these definitions fall
within both the intent of [RFC8552], and common practice.
11. References
11.1. Normative References
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March, 1997, <http://www.rfc-
editor.org/info/rfc2119>.
[RFC3748]
Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748,
June 2004.
[RFC4334]
Housley, R., and Moore, T., "Certificate Extensions and Attributes
Supporting Authentication in Point-to-Point Protocol (PPP) and
Wireless Local Area Networks (WLAN)", RFC 4334, February 2006
[RFC4398]
Josefsson, S., "Storing Certificates in the Domain Name System
(DNS)", RFC 4398, March 2006.
[RFC5216]
Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication
Protocol", RFC 5216, March 2008
[RFC7170]
Zhou, H., et al., "Tunnel Extensible Authentication Protocol (TEAP)
DeKok, Alan Proposed Standard [Page 54]
INTERNET-DRAFT EAP Guidelines 12 July 2021
Version 1", RFC 7170, May 2014.
[RFC7234]
Fielding, Ed., et al, "Hypertext Transfer Protocol (HTTP/1.1):
Caching", RFC 7234, June 2014
[RFC7542]
DeKok, A., "The Network Access Identifier", RFC 7542, May 2015.
[RFC8126]
Cotton, M., et al, "Guidelines for Writing an IANA Considerations
Section in RFCs", RC 8126, June 2017.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key
Words", RFC 8174, May 2017, <http://www.rfc-
editor.org/info/rfc8174>.
[RFC8552]
Crocker, D., "Scoped Interpretation of DNS Resource Records through
"Underscored" Naming of Attribute Leaves", RFC 8552, March 2019.
[EAPTLS]
Mattsson, J., and Sethi, M., "Using EAP-TLS with TLS 1.3", draft-
ietf-emu-eap-tls13-15, May 2021.
11.2. Informative References
[CAT]
https://cat.eduroam.org/
[EDUROAM]
https://eduroam.org/
[MSPEAP]
https://msdn.microsoft.com/en-us/library/cc238354.aspx
[PEAP]
Palekar, A. et al, "Protected EAP Protocol (PEAP)", draft-
josefsson-pppext-eap-tls-eap-06.txt, March 2003.
[CAB]
CA/Browser Forum, "Baseline Requirements for the Issuance and
Management of Publicly-Trusted Certificates" Version 1.7.4, 5 April
2021 https://cabforum.org/wp-content/uploads/CA-Browser-Forum-
BR-1.7.4.pdf
DeKok, Alan Proposed Standard [Page 55]
INTERNET-DRAFT EAP Guidelines 12 July 2021
[RFC2716]
Aboba, B., and Simon, D., "PPP EAP TLS Authentication Protocol",
RFC 2716, October 1999.
[RFC2865]
Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2818]
Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC4851]
Cam-Winget, N., et al, "The Flexible Authentication via Secure
Tunneling Extensible Authentication Protocol Method (EAP-FAST)",
RFC 4851, May 2007.
[RFC5280]
Cooper, D., et al., "Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile", RFC
5280, May 2008.
[RFC5281]
Funk, P., and Blake-Wilson, S., "Extensible Authentication Protocol
Tunneled Transport Layer Security Authenticated Protocol Version 0
(EAP-TTLSv0)", RFC 5281, August 2008.
[RFC5785]
Nottingham, M. and Hammer-Lahav, E., "Defining Well-Known Uniform
Resource Identifiers (URIs)", April 2010.
[RFC5931]
Harkins, D., and Zorn, G., "Extensible Authentication Protocol
(EAP) Authentication Using Only a Password", RFC 5931, August 2010.
[RFC6614]
Winter, S., et al., "Transport Layer Security (TLS) Encryption for
RADIUS", RFC 6614, May 2012.
[RFC6677]
Hartman, S. (ed), et al., "Channel-Binding Support for Extensible
Authentication Protocol (EAP) Methods", RFC 6677, July 2012.
[RFC7030],
Pritikin, M. (Ed), Et al, "Enrollment over Secure Transport",
October 2013
[RFC7360]
DeKok, A., "Datagram Transport Layer Security (DTLS) as a Transport
DeKok, Alan Proposed Standard [Page 56]
INTERNET-DRAFT EAP Guidelines 12 July 2021
Layer for RADIUS", RFC 7360, September 2014.
[RFC7585]
Winter, S, and McCauley, M., "Dynamic Peer Discovery for RADIUS/TLS
and RADIUS/DTLS Based on the Network Access Identifier (NAI)", RFC
7585, October 2015.
[RFC7593]
Weiringa, K. et al, "The eduroam Architecture for Network Roaming",
RFC 7593, September 2015.
[RFC8446]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version
1.3", August 2018.
[RFC8894]
Gutmann, P., "Simple Certificate Enrolment Protocol", RFC 8894,
September 2020.
Acknowledgments
This document would not be possible without the input of many people.
Jorge Vergara provided reviews of previous documents which led to a
clearer articulation of the problem described here, and which
therefore motivated this document. He has also provided reviews for
early versions of this document.
Tom Rixom provided a significant amount of information on issues seen
by supplicants, which motivated much of the text in Section 3.1.
Arran Cudbard-Bell suggested using DNS for the "out of band"
provisioning of certificates in Section 3. He also provided detailed
reviews of multiple versions of this document.
Stefan Winter provided feedback on a number of issues related to
certificates, roaming, and provisioning.
Karri Huhtanen raised issues related to purpose-specific CAs, and
provided suggestions to help address those issues.
Authors' Addresses
Alan DeKok
Network RADIUS SAS
26 rue Colonel Dumont
38000 Grenoble
FRANCE
DeKok, Alan Proposed Standard [Page 57]
INTERNET-DRAFT EAP Guidelines 12 July 2021
Email: aland@networkradius.com
DeKok, Alan Proposed Standard [Page 58]