Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3)
draft-ietf-emu-eap-tls13-18
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 9190.
|
|
|---|---|---|---|
| Authors | John Preuß Mattsson , Mohit Sethi | ||
| Last updated | 2021-07-29 (Latest revision 2021-07-09) | ||
| Replaces | draft-mattsson-eap-tls13 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Joseph A. Salowey | ||
| Shepherd write-up | Show Last changed 2021-07-09 | ||
| IESG | IESG state | Became RFC 9190 (Proposed Standard) | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | Roman Danyliw | ||
| Send notices to | Joseph Salowey <joe@salowey.net> | ||
| IANA | IANA review state | Version Changed - Review Needed | |
| IANA expert review state | Expert Reviews OK |
draft-ietf-emu-eap-tls13-18
Internet Engineering Task Force M.V. Veillette, Ed.
Internet-Draft Trilliant Networks Inc.
Intended status: Standards Track A.P. Pelov, Ed.
Expires: 29 April 2022 Acklio
I. Petrov, Ed.
Google Switzerland GmbH
C. Bormann
Universität Bremen TZI
M. Richardson
Sandelman Software Works
26 October 2021
YANG Schema Item iDentifier (YANG SID)
draft-ietf-core-sid-17
Abstract
YANG Schema Item iDentifiers (YANG SID) are globally unique 63-bit
unsigned integers used to identify YANG items, as a more compact
method to identify YANG items that can be used for efficiency and in
constrained environments (RFC 7228). This document defines the
semantics, the registration, and assignment processes of YANG SIDs
for IETF managed YANG modules. To enable the implementation of these
processes, this document also defines a file format used to persist
and publish assigned YANG SIDs.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on 29 April 2022.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
Veillette, et al. Expires 29 April 2022 [Page 1]
Internet-Draft YANG Schema Item iDentifier (YANG SID) October 2021
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Notation . . . . . . . . . . . . . . . . . . 4
3. ".sid" file lifecycle . . . . . . . . . . . . . . . . . . . . 5
4. ".sid" file format . . . . . . . . . . . . . . . . . . . . . 6
5. Content-Types . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7.1. YANG Namespace Registration . . . . . . . . . . . . . . . 13
7.2. Register ".sid" File Format Module . . . . . . . . . . . 14
7.3. CoAP Content-Formats Registry . . . . . . . . . . . . . . 14
7.4. Create new IANA Registry: "YANG SID Mega-Range"
registry . . . . . . . . . . . . . . . . . . . . . . . . 14
7.4.1. Structure . . . . . . . . . . . . . . . . . . . . . . 14
7.4.2. Allocation policy . . . . . . . . . . . . . . . . . . 15
7.4.2.1. First allocation . . . . . . . . . . . . . . . . 15
7.4.2.2. Consecutive allocations . . . . . . . . . . . . . 15
7.4.3. Initial contents of the Registry . . . . . . . . . . 16
7.5. Create a new IANA Registry: IETF YANG SID Range Registry
(managed by IANA) . . . . . . . . . . . . . . . . . . . . 16
7.5.1. Structure . . . . . . . . . . . . . . . . . . . . . . 16
7.5.2. Allocation policy . . . . . . . . . . . . . . . . . . 16
7.5.3. Initial contents of the registry . . . . . . . . . . 18
7.6. Create new IANA Registry: "IETF YANG SID Registry" . . . 20
7.6.1. Structure . . . . . . . . . . . . . . . . . . . . . . 20
7.6.2. Allocation policy . . . . . . . . . . . . . . . . . . 20
7.6.3. Recursive Allocation of YANG SID Range at Document
Adoption . . . . . . . . . . . . . . . . . . . . . . 21
7.6.4. Initial contents of the registry . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. ".sid" file example . . . . . . . . . . . . . . . . 25
Appendix B. SID auto generation . . . . . . . . . . . . . . . . 34
Appendix C. ".sid" file lifecycle . . . . . . . . . . . . . . . 36
C.1. ".sid" File Creation . . . . . . . . . . . . . . . . . . 36
C.2. ".sid" File Update . . . . . . . . . . . . . . . . . . . 37
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 38
Veillette, et al. Expires 29 April 2022 [Page 2]
Internet-Draft YANG Schema Item iDentifier (YANG SID) October 2021
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction
Some of the items defined in YANG [RFC7950] require the use of a
unique identifier. In both Network Configuration Protocol (NETCONF)
[RFC6241] and RESTCONF [RFC8040], these identifiers are implemented
using names. To allow the implementation of data models defined in
YANG in constrained devices [RFC7228] and constrained networks, a
more compact method to identify YANG items is required. This compact
identifier, called YANG Schema Item iDentifier or YANG SID (or simply
SID in this document and when the context is clear), is encoded using
a 63-bit unsigned integer. The limitation to 63-bit unsigned
integers allows SIDs to be manipulated more easily on platforms that
might otherwise lack 64-bit unsigned arithmetic. The loss of a
single bit of range is not significant given the size of the
remaining space.
The following items are identified using SIDs:
* identities
* data nodes (Note: including those nodes defined by the 'yang-data'
extension.)
* remote procedure calls (RPCs) and associated input(s) and
output(s)
* actions and associated input(s) and output(s)
* notifications and associated information
* YANG modules and features
It is possible that some protocols use only a subset of the assigned
SIDs, for example, for protocols equivalent to NETCONF [RFC6241] like
[I-D.ietf-core-comi] the transportation of YANG module SIDs might be
unnecessary. Other protocols might need to be able to transport this
information, for example protocols related to discovery such as
Constrained YANG Module Library [I-D.ietf-core-yang-library].
SIDs are globally unique integers. A registration system is used in
order to guarantee their uniqueness. SIDs are registered in blocks
called "SID ranges".
Veillette, et al. Expires 29 April 2022 [Page 3]
Internet-Draft YANG Schema Item iDentifier (YANG SID) October 2021
SIDs are assigned permanently. Items introduced by a new revision of
a YANG module are added to the list of SIDs already assigned.
Assignment of SIDs to YANG items SHOULD be automated. For more
details how this can be achieved, and when manual interventions may
be appropriate, see Appendix B.
Section 3 provides more details about the registration process of
YANG modules and associated SIDs. To enable the implementation of
this registry, Section 4 defines a standard file format used to store
and publish SIDs.
IETF managed YANG modules which need to allocate SIDs, MUST use the
IANA mechanism specified in this document. For YANG modules created
by other parties, the use of IANA allocation mechanisms via use of
Mega-Ranges (see Section 7.4) is RECOMMENDED. Within the Mega-Range
allocation, those other parties are free to make up their own
mechanism.
At the time of writing, a tool for automated SID file generation is
available as part of the open-source project PYANG [PYANG].
2. Terminology and Notation
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.
The following terms are defined in [RFC7950]:
* action
* feature
* module
* notification
* RPC
* schema node
* schema tree
* submodule
The following term is defined in [RFC8040]:
OCSP status handling in TLS 1.3 is different from earlier versions of
TLS, see Section 4.4.2.1 of [RFC8446]. In TLS 1.3 the OCSP
information is carried in the CertificateEntry containing the
associated certificate instead of a separate CertificateStatus
message as in [RFC6066]. This enables sending OCSP information for
all certificates in the certificate chain (except the trust anchor).
To enable revocation checking in situations where EAP-TLS peers do
not implement or use OCSP stapling, and where network connectivity is
not available prior to authentication completion, EAP-TLS peer
implementations MUST also support checking for certificate revocation
after authentication completes and network connectivity is available.
An EAP peer implementation SHOULD NOT trust the network (and any
services) until it has verified the revocation status of the server
certificate after receiving network connectivity. An EAP peer MUST
use a secure transport to verify the revocation status of the server
certificate. An EAP peer SHOULD NOT send any other traffic before
revocation checking for the server certificate is complete.
5.5. Packet Modification Attacks
This section updates Section 5.5 of [RFC5216].
As described in [RFC3748] and Section 5.5 of [RFC5216], the only
information that is integrity and replay protected in EAP-TLS are the
parts of the TLS Data that TLS protects. All other information in
the EAP-TLS message exchange including EAP-Request and EAP-Response
headers, the identity in the identity response, EAP-TLS packet header
fields, Type, and Flags, EAP-Success, and EAP-Failure can be
modified, spoofed, or replayed.
Protected TLS Error alerts are protected failure result indications
and enables the EAP-TLS peer and EAP-TLS server to determine that the
failure result was not spoofed by an attacker. Protected failure
result indications provide integrity and replay protection but MAY be
unauthenticated. Protected failure results do not significantly
improve availability as TLS 1.3 treats most malformed data as a fatal
error.
5.6. Authorization
This is a new section when compared to [RFC5216]. The guidance in
this section is relevant for EAP-TLS in general (regardless of the
underlying TLS version used).
EAP servers will usually require the EAP peer to provide a valid
certificate and will fail the connection if one is not provided.
Some deployments may permit no peer authentication for some or all
Preuss Mattsson & Sethi Expires January 10, 2022 [Page 24]
Internet-Draft EAP-TLS 1.3 July 2021
connections. When peer authentication is not used, EAP-TLS server
implementations MUST take care to limit network access appropriately
for unauthenticated peers and implementations MUST use resumption
with caution to ensure that a resumed session is not granted more
privilege than was intended for the original session. An example of
limiting network access would be to invoke a vendor's walled garden
or quarantine network functionality.
EAP-TLS is typically encapsulated in other protocols, such as PPP
[RFC1661], RADIUS [RFC2865], Diameter [RFC6733], or PANA [RFC5191].
The encapsulating protocols can also provide additional, non-EAP
information to an EAP-TLS server. This information can include, but
is not limited to, information about the authenticator, information
about the EAP-TLS peer, or information about the protocol layers
above or below EAP (MAC addresses, IP addresses, port numbers, WiFi
SSID, etc.). EAP-TLS servers implementing EAP-TLS inside those
protocols can make policy decisions and enforce authorization based
on a combination of information from the EAP-TLS exchange and non-EAP
information.
As noted in Section 2.2, the identity presented in EAP-Response/
Identity is not authenticated by EAP-TLS and is therefore trivial for
an attacker to forge, modify, or replay. Authorization and
accounting MUST be based on authenticated information such as
information in the certificate or the PSK identity and cached data
provisioned for resumption as described in Section 5.7. Note that
the requirements for Network Access Identifiers (NAIs) specified in
Section 4 of [RFC7542] still apply and MUST be followed.
EAP-TLS servers MAY reject conversations based on non-EAP information
provided by the encapsulating protocol, for example, if the MAC
address of the authenticator does not match the expected policy.
5.7. Resumption
This is a new section when compared to [RFC5216]. The guidance in
this section is relevant for EAP-TLS in general (regardless of the
underlying TLS version used).
There are a number of security issues related to resumption that are
not described in [RFC5216]. The problems, guidelines, and
requirements in this section therefore applies to EAP-TLS when it is
used with any version of TLS.
When resumption occurs, it is based on cached information at the TLS
layer. To perform resumption in a secure way, the EAP-TLS peer and
EAP-TLS server need to be able to securely retrieve authorization
information such as certificate chains from the initial full
Preuss Mattsson & Sethi Expires January 10, 2022 [Page 25]
Internet-Draft EAP-TLS 1.3 July 2021
handshake. This document use the term "cached data" to describe such
information. Authorization during resumption MUST be based on such
cached data. The EAP-TLS peer and EAP-TLS server MAY perform fresh
revocation checks on the cached certificate data. Any security
policies for authorization MUST be followed also for resumption. The
certificates may have been revoked since the initial full handshake
and the authorizations of the other party may have reduced. If the
cached revocation data is not sufficiently current, the EAP-TLS peer
or EAP-TLS server MAY force a full TLS handshake.
There are two ways to retrieve the cached data from the original full
handshake. The first method is that the EAP-TLS server and client
cache the information locally. The cached information is identified
by an identifier. For TLS versions before 1.3, the identifier can be
the session ID, for TLS 1.3, the identifier is the PSK identity. The
second method for retrieving cached information is via [RFC5077] or
[RFC8446], where the EAP-TLS server avoids storing information
locally and instead encapsulates the information into a ticket or PSK
which is sent to the client for storage. This ticket or PSK is
encrypted using a key that only the EAP-TLS server knows. Note that
the client still needs to cache the original handshake information
locally and will use the session ID or PSK identity to lookup this
information during resumption. However, the EAP-TLS server is able
to decrypt the ticket or PSK to obtain the original handshake
information.
The EAP-TLS server or EAP client MUST cache data during the initial
full handshake sufficient to allow authorization decisions to be made
during resumption. If cached data cannot be retrieved in a secure
way, resumption MUST NOT be done.
The above requirements also apply if the EAP-TLS server expects some
system to perform accounting for the session. Since accounting must
be tied to an authenticated identity, and resumption does not supply
such an identity, accounting is impossible without access to cached
data. Therefore systems which expect to perform accounting for the
session SHOULD cache an identifier which can be used in subsequent
accounting.
As suggested in [RFC8446], EAP-TLS peers MUST NOT store resumption
PSKs or tickets (and associated cached data) for longer than 604800
seconds (7 days), regardless of the PSK or ticket lifetime. The EAP-
TLS peer MAY delete them earlier based on local policy. The cached
data MAY also be removed on the EAP-TLS server or EAP-TLS peer if any
certificate in the certificate chain has been revoked or has expired.
In all such cases, an attempt at resumption results in a full TLS
handshake instead.
Preuss Mattsson & Sethi Expires January 10, 2022 [Page 26]
Internet-Draft EAP-TLS 1.3 July 2021
Information from the EAP-TLS exchange (e.g., the identity provided in
EAP-Response/Identity) as well as non-EAP information (e.g., IP
addresses) may change between the initial full handshake and
resumption. This change creates a "time-of-check time-of-use"
(TOCTOU) security vulnerability. A malicious or compromised user
could supply one set of data during the initial authentication, and a
different set of data during resumption, potentially allowing them to
obtain access that they should not have.
If any authorization, accounting, or policy decisions were made with
information that has changed between the initial full handshake and
resumption, and if change may lead to a different decision, such
decisions MUST be reevaluated. It is RECOMMENDED that authorization,
accounting, and policy decisions are reevaluated based on the
information given in the resumption. EAP-TLS servers MAY reject
resumption where the information supplied during resumption does not
match the information supplied during the original authentication.
If a safe decision is not possible, EAP-TLS servers SHOULD reject the
resumption and continue with a full handshake.
Section 2.2 and 4.2.11 of [RFC8446] provides security considerations
for TLS 1.3 resumption.
5.8. Privacy Considerations
This is a new section when compared to [RFC5216].
TLS 1.3 offers much better privacy than earlier versions of TLS as
discussed in Section 2.1.8. In this section, we only discuss the
privacy properties of EAP-TLS with TLS 1.3. For privacy properties
of TLS 1.3 itself, see [RFC8446].
EAP-TLS sends the standard TLS 1.3 handshake messages encapsulated in
EAP packets. Additionally, the EAP-TLS peer sends an identity in the
first EAP-Response. The other fields in the EAP-TLS Request and the
EAP-TLS Response packets do not contain any cleartext privacy
sensitive information.
Tracking of users by eavesdropping on identity responses or
certificates is a well-known problem in many EAP methods. When EAP-
TLS is used with TLS 1.3, all certificates are encrypted, and the
username part of the identity response is not revealed (e.g., using
anonymous NAIs). Note that even though all certificates are
encrypted, the server's identity is only protected against passive
attackers while client's identity is protected against both passive
and active attackers. As with other EAP methods, even when privacy-
friendly identifiers or EAP tunneling is used, the domain name (i.e.,
the realm) in the NAI is still typically visible. How much privacy
Preuss Mattsson & Sethi Expires January 10, 2022 [Page 27]
Internet-Draft EAP-TLS 1.3 July 2021
Veillette, et al. Expires 29 April 2022 [Page 4]
Internet-Draft YANG Schema Item iDentifier (YANG SID) October 2021
* yang-data extension
This specification also makes use of the following terminology:
* item: A schema node, an identity, a module, or a feature defined
using the YANG modeling language.
* schema-node path: A schema-node path is a string that identifies a
schema node within the schema tree. A path consists of the list
of consecutive schema node identifier(s) separated by slashes
("/"). Schema node identifier(s) are always listed from the top-
level schema node up to the targeted schema node and could contain
namespace information. (e.g. "/ietf-system:system-state/clock/
current-datetime")
* Namespace-qualified form - a schema node identifier is prefixed
with the name of the module in which the schema node is defined,
separated from the schema node identifier by the colon character
(":").
* YANG Schema Item iDentifier (YANG SID or simply SID): Unsigned
integer used to identify different YANG items.
3. ".sid" file lifecycle
YANG is a language designed to model data accessed using one of the
compatible protocols (e.g. NETCONF [RFC6241], RESTCONF [RFC8040] and
CORECONF [I-D.ietf-core-comi]). A YANG module defines hierarchies of
data, including configuration, state data, RPCs, actions and
notifications.
Many YANG modules are not created in the context of constrained
applications. YANG modules can be implemented using NETCONF
[RFC6241] or RESTCONF [RFC8040] without the need to assign SIDs.
As needed, authors of YANG modules can assign SIDs to their YANG
modules. In order to do that, they should first obtain a SID range
from a registry and use that range to assign or generate SIDs to
items of their YANG module. The assignments can then be stored in a
".sid" file. For example on how this could be achieved, please refer
to Appendix C.
Veillette, et al. Expires 29 April 2022 [Page 5]
Internet-Draft YANG Schema Item iDentifier (YANG SID) October 2021
Registration of the ".sid" file associated to a YANG module is
optional but recommended to promote interoperability between devices
and to avoid duplicate allocation of SIDs to a single YANG module.
Different registries might have different requirements for the
registration and publication of the ".sid" files. For a diagram of
one of the possibilities, please refer to the activity diagram on
Figure 1 in Appendix C.
Each time a YANG module or one of its imported module(s) or included
sub-module(s) is updated, a new ".sid" file MAY be created if the new
or updated items will need SIDs. All the SIDs present in the
previous version of the ".sid" file MUST be present in the new
version as well. The creation of this new version of the ".sid" file
SHOULD be performed using an automated tool.
If a new revision requires more SIDs than initially allocated, a new
SID range MUST be added to the 'assignment-range' as defined in
Section 4. These extra SIDs are used for subsequent assignments.
For an example of this update process, see activity diagram Figure 2
in Appendix C.
4. ".sid" file format
".sid" files are used to persist and publish SIDs assigned to the
different YANG items of a specific YANG module. It has the following
structure.
module: ietf-sid-file
+-- sid-file
+-- module-name? yang:yang-identifier
+-- module-revision? revision-identifier
+-- sid-file-version? sid-file-version-identifier
+-- description? string
+-- dependency-revision* [module-name]
| +-- module-name yang:yang-identifier
| +-- module-revision revision-identifier
+-- assignment-range* [entry-point]
| +-- entry-point sid
| +-- size uint64
+-- item* [namespace identifier]
+-- namespace enumeration
+-- identifier union
+-- sid sid
Veillette, et al. Expires 29 April 2022 [Page 6]
Internet-Draft YANG Schema Item iDentifier (YANG SID) October 2021
The following YANG module defines the structure of this file,
encoding is performed in JSON [RFC8259] using the rules defined in
[RFC7951]. It references ietf-yang-types defined in [RFC6991] and
ietf-restconf defined in [RFC8040].
RFC Ed.: please update the date of the module and Copyright if needed
and remove this note.
<CODE BEGINS> file "ietf-sid-file@2020-02-05.yang"
module ietf-sid-file {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-sid-file";
prefix sid;
import ietf-yang-types {
prefix yang;
reference "RFC 6991: Common YANG Data Types.";
}
import ietf-restconf {
prefix rc;
reference "RFC 8040: RESTCONF Protocol.";
}
organization
"IETF Core Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/core/>
WG List: <mailto:core@ietf.org>
Editor: Michel Veillette
<mailto:michel.veillette@trilliant.com>
Editor: Andy Bierman
<mailto:andy@yumaworks.com>
Editor: Alexander Pelov
<mailto:a@ackl.io>
Editor: Ivaylo Petrov
<mailto:ivaylopetrov@google.com>";
description
"Copyright (c) 2021 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
Veillette, et al. Expires 29 April 2022 [Page 7]
Internet-Draft YANG Schema Item iDentifier (YANG SID) October 2021
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices.
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 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
This module defines the structure of the .sid files.
Each .sid file contains the mapping between each
string identifier defined by a YANG module and a
corresponding numeric value called YANG SID.";
revision 2020-02-05 {
description
"Initial revision.";
reference
"[RFC XXXX] YANG Schema Item iDentifier (YANG SID)";
}
typedef revision-identifier {
type string {
pattern '\d{4}-\d{2}-\d{2}';
}
description
"Represents a date in YYYY-MM-DD format.";
}
typedef sid-file-version-identifier {
type uint32;
description
"Represents the version of a .sid file.";
}
typedef sid {
type uint64 {
range "0..9223372036854775807";
}
description
Veillette, et al. Expires 29 April 2022 [Page 8]
Internet-Draft YANG Schema Item iDentifier (YANG SID) October 2021sensitive information the domain name leaks is highly dependent on
how many other users are using the same domain name in the particular
access network. If all EAP-TLS peers have the same domain, no
additional information is leaked. If a domain name is used by a
small subset of the EAP-TLS peers, it may aid an attacker in tracking
or identifying the user.
Without padding, information about the size of the client certificate
is leaked from the size of the EAP-TLS packets. The EAP-TLS packets
sizes may therefore leak information that can be used to track or
identify the user. If all client certificates have the same length,
no information is leaked. EAP-TLS peers SHOULD use record padding,
see Section 5.4 of [RFC8446] to reduce information leakage of
certificate sizes.
If anonymous NAIs are not used, the privacy-friendly identifiers need
to be generated with care. The identities MUST be generated in a
cryptographically secure way so that that it is computationally
infeasible for an attacker to differentiate two identities belonging
to the same user from two identities belonging to different users in
the same realm. This can be achieved, for instance, by using random
or pseudo-random usernames such as random byte strings or ciphertexts
and only using the pseudo-random usernames a single time. Note that
the privacy-friendly usernames also MUST NOT include substrings that
can be used to relate the identity to a specific user. Similarly,
privacy-friendly username MUST NOT be formed by a fixed mapping that
stays the same across multiple different authentications.
An EAP-TLS peer with a policy allowing communication with EAP-TLS
servers supporting only TLS 1.2 without privacy and with a static RSA
key exchange is vulnerable to disclosure of the EAP-TLS peer
username. An active attacker can in this case make the EAP-TLS peer
believe that an EAP-TLS server supporting TLS 1.3 only supports TLS
1.2 without privacy. The attacker can simply impersonate the EAP-TLS
server and negotiate TLS 1.2 with static RSA key exchange and send an
TLS alert message when the EAP-TLS peer tries to use privacy by
sending an empty certificate message. Since the attacker
(impersonating the EAP-TLS server) does not provide a proof-of-
possession of the private key until the Finished message when a
static RSA key exchange is used, an EAP-TLS peer may inadvertently
disclose its identity (username) to an attacker. Therefore, it is
RECOMMENDED for EAP-TLS peers to not use EAP-TLS with TLS 1.2 and
static RSA based cipher suites without privacy. This implies that an
EAP-TLS peer SHOULD NOT continue the handshake if a TLS 1.2 EAP-TLS
server sends an EAP-TLS/Request with a TLS alert message in response
to an empty certificate message from the peer.
Preuss Mattsson & Sethi Expires January 10, 2022 [Page 28]
Internet-Draft EAP-TLS 1.3 July 2021
5.9. Pervasive Monitoring
This is a new section when compared to [RFC5216].
Pervasive monitoring refers to widespread surveillance of users. In
the context of EAP-TLS, pervasive monitoring attacks can target EAP-
TLS peer devices for tracking them (and their users) as and when they
join a network. By encrypting more information, mandating the use of
privacy, and always providing forward secrecy, EAP-TLS with TLS 1.3
offers much better protection against pervasive monitoring. In
addition to the privacy attacks discussed above, surveillance on a
large scale may enable tracking of a user over a wide geographical
area and across different access networks. Using information from
EAP-TLS together with information gathered from other protocols
increases the risk of identifying individual users.
5.10. Discovered Vulnerabilities
This is a new section when compared to [RFC5216].
Over the years, there have been several serious attacks on earlier
versions of Transport Layer Security (TLS), including attacks on its
most commonly used ciphers and modes of operation. [RFC7457]
summarizes the attacks that were known at the time of publishing and
BCP 195 [RFC7525] provides recommendations for improving the security
of deployed services that use TLS. However, many of the attacks are
less serious for EAP-TLS as EAP-TLS only uses the TLS handshake and
does not protect any application data. EAP-TLS implementations MUST
mitigate known attacks. EAP-TLS implementations need to monitor and
follow new EAP and TLS related security guidance and requirements
such as [RFC8447], [RFC8996], [I-D.ietf-tls-md5-sha1-deprecate].
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/info/rfc3748>.
Preuss Mattsson & Sethi Expires January 10, 2022 [Page 29]
Internet-Draft EAP-TLS 1.3 July 2021
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
March 2008, <https://www.rfc-editor.org/info/rfc5216>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/info/rfc6960>.
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542,
DOI 10.17487/RFC7542, May 2015,
<https://www.rfc-editor.org/info/rfc7542>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
<https://www.rfc-editor.org/info/rfc8996>.
Preuss Mattsson & Sethi Expires January 10, 2022 [Page 30]
Internet-Draft EAP-TLS 1.3 July 2021
6.2. Informative references
[I-D.ietf-emu-eaptlscert]
Sethi, M., Mattsson, J., and S. Turner, "Handling Large
Certificates and Long Certificate Chains in TLS-based EAP
Methods", draft-ietf-emu-eaptlscert-08 (work in progress),
November 2020.
[I-D.ietf-emu-tls-eap-types]
DeKok, A., "TLS-based EAP types and TLS 1.3", draft-ietf-
emu-tls-eap-types-02 (work in progress), February 2021.
[I-D.ietf-tls-md5-sha1-deprecate]
Velvindron, L., Moriarty, K., and A. Ghedini, "Deprecating
MD5 and SHA-1 signature hashes in TLS 1.2", draft-ietf-
tls-md5-sha1-deprecate-06 (work in progress), March 2021.
[I-D.ietf-tls-rfc8446bis]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-rfc8446bis-01 (work in
progress), February 2021.
[I-D.ietf-tls-ticketrequests]
Pauly, T., Schinazi, D., and C. A. Wood, "TLS Ticket
Requests", draft-ietf-tls-ticketrequests-07 (work in
progress), December 2020.
[IEEE-802.11]
Institute of Electrical and Electronics Engineers, "IEEE
Standard for Information technology--Telecommunications
and information exchange between systems Local and
metropolitan area networks--Specific requirements - Part
11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications", IEEE Standard 802.11-2020 ,
February 2021.
[IEEE-802.1AE]
Institute of Electrical and Electronics Engineers, "IEEE
Standard for Local and metropolitan area networks -- Media
Access Control (MAC) Security", IEEE Standard
802.1AE-2018 , December 2018.
[IEEE-802.1X]
Institute of Electrical and Electronics Engineers, "IEEE
Standard for Local and metropolitan area networks -- Port-
Based Network Access Control", IEEE Standard 802.1X-2020 ,
February 2020.
Preuss Mattsson & Sethi Expires January 10, 2022 [Page 31]
Internet-Draft EAP-TLS 1.3 July 2021
[MulteFire]
MulteFire, "MulteFire Release 1.1 specification", 2019.
[PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible
Authentication Protocol (PEAP)", April 2021.
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994,
<https://www.rfc-editor.org/info/rfc1661>.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, DOI 10.17487/RFC2246, January 1999,
<https://www.rfc-editor.org/info/rfc2246>.
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560,
DOI 10.17487/RFC2560, June 1999,
<https://www.rfc-editor.org/info/rfc2560>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000,
<https://www.rfc-editor.org/info/rfc2865>.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
DOI 10.17487/RFC3280, April 2002,
<https://www.rfc-editor.org/info/rfc3280>.
[RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba,
"State Machines for Extensible Authentication Protocol
(EAP) Peer and Authenticator", RFC 4137,
DOI 10.17487/RFC4137, August 2005,
<https://www.rfc-editor.org/info/rfc4137>.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282,
DOI 10.17487/RFC4282, December 2005,
<https://www.rfc-editor.org/info/rfc4282>.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346,
DOI 10.17487/RFC4346, April 2006,
<https://www.rfc-editor.org/info/rfc4346>.
Preuss Mattsson & Sethi Expires January 10, 2022 [Page 32]
Internet-Draft EAP-TLS 1.3 July 2021
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The
Flexible Authentication via Secure Tunneling Extensible
Authentication Protocol Method (EAP-FAST)", RFC 4851,
DOI 10.17487/RFC4851, May 2007,
<https://www.rfc-editor.org/info/rfc4851>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
and A. Yegin, "Protocol for Carrying Authentication for
Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191,
May 2008, <https://www.rfc-editor.org/info/rfc5191>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
RFC 5247, DOI 10.17487/RFC5247, August 2008,
<https://www.rfc-editor.org/info/rfc5247>.
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication
Protocol Tunneled Transport Layer Security Authenticated
Protocol Version 0 (EAP-TTLSv0)", RFC 5281,
DOI 10.17487/RFC5281, August 2008,
<https://www.rfc-editor.org/info/rfc5281>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012,
<https://www.rfc-editor.org/info/rfc6733>.
[RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
"Tunnel Extensible Authentication Protocol (TEAP) Version
1", RFC 7170, DOI 10.17487/RFC7170, May 2014,
<https://www.rfc-editor.org/info/rfc7170>.
[RFC7406] Schulzrinne, H., McCann, S., Bajko, G., Tschofenig, H.,
and D. Kroeselberg, "Extensions to the Emergency Services
Architecture for Dealing With Unauthenticated and
Unauthorized Devices", RFC 7406, DOI 10.17487/RFC7406,
December 2014, <https://www.rfc-editor.org/info/rfc7406>.
Preuss Mattsson & Sethi Expires January 10, 2022 [Page 33]
Internet-Draft EAP-TLS 1.3 July 2021
[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
Known Attacks on Transport Layer Security (TLS) and
Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
February 2015, <https://www.rfc-editor.org/info/rfc7457>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7593] Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam
Architecture for Network Roaming", RFC 7593,
DOI 10.17487/RFC7593, September 2015,
<https://www.rfc-editor.org/info/rfc7593>.
[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
<https://www.rfc-editor.org/info/rfc8447>.
[TS.33.501]
3GPP, "Security architecture and procedures for 5G
System", 3GPP TS 33.501 17.1.0, April 2021.
Appendix A. Updated references
All the following references in [RFC5216] are updated as specified
below when EAP-TLS is used with TLS 1.3.
All references to [RFC2560] are updated with [RFC6960].
All references to [RFC3280] are updated with [RFC5280].
All references to [RFC4282] are updated with [RFC7542].
Acknowledgments
The authors want to thank Bernard Aboba, Jari Arkko, Terry Burton,
Alan DeKok, Ari Keraenen, Benjamin Kaduk, Jouni Malinen, Oleg Pekar,
Eric Rescorla, Jim Schaad, Joseph Salowey, Martin Thomson, Vesa
Torvinen, Hannes Tschofenig, and Heikki Vatiainen for comments and
suggestions on the draft. Special thanks to the document shepard
Joseph Salowey.
Preuss Mattsson & Sethi Expires January 10, 2022 [Page 34]
Internet-Draft EAP-TLS 1.3 July 2021
Contributors
Alan DeKok, FreeRADIUS
Authors' Addresses
John Preuss Mattsson
Ericsson
Stockholm 164 40
Sweden
Email: john.mattsson@ericsson.com
Mohit Sethi
Ericsson
Jorvas 02420
Finland
Email: mohit@piuha.net
Preuss Mattsson & Sethi Expires January 10, 2022 [Page 35]