Network Working Group O. Friel
Internet-Draft Cisco
Intended status: Standards Track D. Harkins
Expires: August 26, 2021 Hewlett-Packard Enterprise
February 22, 2021
Bootstrapped TLS Authentication
draft-friel-tls-eap-dpp-02
Abstract
This document defines a TLS extension that enables a server to prove
to a client that it has knowledge of the public key of a key pair
where the client has knowledge of the private key of the key pair.
Unlike standard TLS key exchanges, the public key is never exchanged
in TLS protocol messages. Proof of knowledge of the public key is
used by the client to bootstrap trust in the server. The use case
outlined in this document is to establish trust in an EAP server.
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 August 26, 2021.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
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
Friel & Harkins Expires August 26, 2021 [Page 1]
Internet-Draft TLS-POK February 2021
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Bootstrap Key Pair . . . . . . . . . . . . . . . . . . . 2
1.2. Alignment with Wi-Fi Alliance Device Provisioning Profile 3
2. Bootstrapping in TLS 1.3 . . . . . . . . . . . . . . . . . . 4
2.1. Bootstrap Key Extension . . . . . . . . . . . . . . . . . 4
2.2. Server Ephemeral Keys . . . . . . . . . . . . . . . . . . 4
2.3. Changes to TLS 1.3 Handshake . . . . . . . . . . . . . . 5
2.4. Changes to TLS 1.3 Key Schedule . . . . . . . . . . . . . 6
3. Using TLS Bootstrapping in EAP . . . . . . . . . . . . . . . 7
4. Summary of Work . . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Informative References . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
On-boarding of devices with no, or limited, user interface can be
difficult. Typically, a credential is needed to access the network
and network connectivity is needed to obtain a credential. This
poses a catch-22.
If trust in the integrity of a device's public key can be obtained in
an out-of-band fashion, a device can be authenticated and provisioned
with a usable credential for network access. While this
authentication can be strong, the device's authentication of the
network is somewhat weaker. [Stajano]] presents a functional
security model to address this asymmetry.
There are on-boarding protocols, such as [DPP], to address this use
case but they have drawbacks. [DPP] for instance does not support
wired network access. This document describes an on-boarding
protocol, which we refer to as TLS Proof of Knowledge or TLS-POK.
1.1. Bootstrap Key Pair
The mechanism for on-boarding of devices defined in this document
relies on bootstrap key pairs. A client device has an associated
elliptic curve (EC) key pair. The key pair may be static and baked
into device firmware at manufacturing time, or may be dynamic and
generated at on-boarding time by the device. If this public key,
specifically the ASN.1 SEQUENCE SubjectPublicKeyInfo from [RFC5280],
Friel & Harkins Expires August 26, 2021 [Page 2]
Internet-Draft TLS-POK February 2021
can be shared in a trustworthy manner with a TLS server, a form of
"origin entity authentication" (the step from which all subsequent
authentication proceeds) can be obtained.
The exact mechanism by which the server gains knowledge of the public
key is out of scope of this specification, but possible mechanisms
include scanning a QR code to obtain a base64 encoding of the
ASN.1-formatted public key or upload of a Bill of Materials (BOM).
If the QR code is physically attached to the client device, or the
BOM is associated with the device, the assumption is that the public
key obtained in this bootstrapping method belongs to the client. In
this model, physical possession of the device implies legitimate
ownership.
The server may have knowledge of multiple bootstrap public keys
corresponding to multiple devices, and TLS extensions are defined in
this document that enable the server to identity a specific bootstrap
public key correspinding to a specific device.
Using the extensions defined herein, the client proves to the server
that it has possession of the private analog to its public
bootstrapping key. Provided that the mechanism in which the server
obtained the bootstrapping key is trustworthy, a commensurate amount
of authenticity of the resulting connection can be obtained. The
server also proves that it knows the client's public key which, if
the client does not gratuitously expose its public key, can be used
to obtain a modicum of correctness, that the client is connecting to
the correct network (see [Stajano]).
1.2. Alignment with Wi-Fi Alliance Device Provisioning Profile
The definition of the boostrap public key aligns with that given in
[DPP]. This, for example, enables the QR code format as defined in
[DPP] to be reused for TLS-POK. Therefore, a device that supports
both wired LAN and Wi-Fi LAN connections can have a single QR code
printed on its label, and the bootstrap key can be used for DPP if
the device bootstraps against a Wi-Fi network, or TLS-POK if the
device bootstraps against a wired network. Similarly, a common
bootstrap public key format could be imported in a BOM into a server
that handles devices connecting over both wired and Wi-Fi networks.
Any bootstrapping method defined for, or used by, [DPP] is compatible
with TLS-POK.
Friel & Harkins Expires August 26, 2021 [Page 3]
Internet-Draft TLS-POK February 2021
2. Bootstrapping in TLS 1.3
The bootstrapping modifications introduce an extension to identify a
"bootstrapping" key into the TLS 1.3 handshake. This key MUST be
from a cryptosystem suitable for doing (EC)DH. When using the
bootstrapping extension, two (EC)DH operations are performed, a
static-ephemeral (using the client's bootstrapping key and an
ephemeral key generated by the server) and an ephemeral-ephemeral
(using the client's ephemeral key and an ephemeral key generated by
the server).
2.1. Bootstrap Key Extension
This document defines the "bskey_share" extension.
struct {
select (Handshake.msg_type) {
case client_hello:
opaque bskey[32];
case server_hello:
opaque bskey_exchange<1..2^16-1>;
};
} BootstrapKey;
The BootstrapKey extension is used by the client in its ClientHello
message to specify its bootstrapping key identifier. The 'bskey'
field of this extension SHALL consist of the base64 encoded SHA256
digest of the DER-encoded ASN.1 subjectPublicKeyInfo representation
of the bootstrapping public key.
The BoostrapKey extension is used by the server in its ServerHello
message to specify its ephemeral ECDH keying information. The
'key_exchange' field contains the key exchange information on the
curve that the bootstrapping key is on.
2.2. Server Ephemeral Keys
The server generates two ephemeral key pairs: one that is used for
the static-ephemeral (bootstrap) ECDH exchange and is exchanged in
the "bskey_share" extension, and one that is used for the ephemeral-
ephemeral (TLS key_share) DH exchange and is exchanged in the
"key_share" extension. The "bskey_share" and "key_share" keys are
independent. The key_share keys may be Finite Field DH keys.
Friel & Harkins Expires August 26, 2021 [Page 4]
Internet-Draft TLS-POK February 2021
2.3. Changes to TLS 1.3 Handshake
The client identifies the bootstrapping key in the ClientHello using
the BootstrapKey extension 'bskey' field. The server looks up the
client's bootstrapping key in its database by checking the SHA256
hash of each entry with the value received in the ClientHello. If no
match is found, the server MAY proceed with the TLS handshake without
using the bootstrapping key as input to the key schedule, or MAY
terminate the TLS handshake with an alert.
[[ TODO: should we define an explicit unknown_bsk_identity alert,
similar to unknown_psk_identity ]]
If the server found the matching bootstrap key, the server generates
an ephemeral ECDH keypair on the curve indicated in the bootstrap
public key information, and performs an ECDH operation using the
client bootstrap key and the server's ephemeral keypair. The server
includes a BootstrapKey extension in its ServerHello that includes
its ephemeral ECDH public key in the 'key_exchange' field. This
explicitly confirms to the client that the server has performed an
ECDH operation using the bootstrap key, and has injected the output
into the key schedule.
This is in addition to, and independent from, the (EC)DH that the
server carries out when handling the key_share extension.
The handshake is shown in Figure 1.
Client Server
-------- --------
ClientHello
+ bskey_share
+ key_share -------->
ServerHello
+ bskey_share
+ key_share
{EncryptedExtensions}
{Finished}
<-------- [Application Data*]
{Finished} -------->
[Application Data] <-------> [Application Data]
Figure 1: TLS 1.3 TLS-POK Handshake
Friel & Harkins Expires August 26, 2021 [Page 5]
Internet-Draft TLS-POK February 2021
2.4. Changes to TLS 1.3 Key Schedule
[[ TODO: The key schedule mechanism needs to closed. ]]
Multiple options for modifying the TLS 1.3 key schedule have been
proporsed recently including [I-D.stebila-tls-hybrid-design] and
[I-D.jhoyla-tls-extended-key-schedule]. The key schedule used for
TLS-POK will align with the final direction chosen by the TLS WG.
This document proposes aligning with the model outlined in
[I-D.jhoyla-tls-extended-key-schedule] where the shared secrets
derived from the bskey and key_share key exchanges are injected
together into the key schedule to create the Handshake Secret.
The key schedule for TLS-POK is as follows:
0
|
v
PSK -> HKDF-Extract = Early Secret
|
+-----> Derive-Secret(...)
+-----> Derive-Secret(...)
+-----> Derive-Secret(...)
|
v
Derive-Secret(., "derived", "")
|
v
bskey_input || (EC)DHE -> HKDF-Extract = Handshake Secret
|
+-----> Derive-Secret(...)
+-----> Derive-Secret(...)
|
v
Derive-Secret(., "derived", "")
|
v
0 -> HKDF-Extract = Master Secret
|
+-----> Derive-Secret(...)
+-----> Derive-Secret(...)
+-----> Derive-Secret(...)
+-----> Derive-Secret(...)
Friel & Harkins Expires August 26, 2021 [Page 6]
Internet-Draft TLS-POK February 2021
3. Using TLS Bootstrapping in EAP
Enterprise deployments typically require an 802.1X/EAP-based
authentication to obtain network access. Protocols like [RFC7030]
can be used to enroll devices into a Certification Authority to allow
them to authenticate using 802.1X/EAP. But this creates a Catch-22
where a certificate is needed for network access and network access
is needed to obtain certificate.
Devices whose bootstrapping key can been obtained in an out-of-band
fashion can perform an EAP-TLS-based exchange, for instance
[RFC7170], and authenticate the TLS exchange using the bootstrapping
extensions defined in Section 2. This network connectivity can then
be used to perform an enrollment protocol (such as provided by
[RFC7170]) to obtain a credential for subsequent network connectivity
and certificate lifecycle maintenance.
Upon "link up", an Authenticator on an 802.1X-protected port will
issue an EAP Identify request to the newly connected peer. For
unprovisioned devices that desire to take advantage of TLS-POK, there
is no initial realm in which to construct an NAI (see [RFC4282]) so
the initial EAP Identity response SHOULD contain simply the name
"TLS-POK" in order to indicate to the Authenticator that an EAP
method that supports TLS-POK SHOULD be started.
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (TLS-POK) ->
<- EAP-Request/
EAP-Type=TEAP
(TLS Start)
.
.
.
4. Summary of Work
[TODO: agree with WG chairs where this work lives and where it should
be documented.]
The protocol outlined here can be broadly broken up into 3 distinct
areas:
Friel & Harkins Expires August 26, 2021 [Page 7]
Internet-Draft TLS-POK February 2021
o TLS extensions to transport the bootstrap public key identifier
o TLS key schedule enhancements to inject bootstrap public key
keying material
o TEAP extensions to leverage the new TLS-POK handshake for trust
establishment
This document captures all 3 areas, but it may be more appropriate to
split the work into multiple documents e.g.:
o piggy back on top of [I-D.jhoyla-tls-extended-key-schedule] for
TLS key schedule enhancements
o include the TEAP extensions in [I-D.lear-eap-teap-brski] draft
5. IANA Considerations
IANA will allocated an ExtensionType for the bskey extension from the
appropriate TLS 1.3 repository and replace TBD in this document with
that number.
6. Security Considerations
Bootstrap and trust establishment by the TLS server is based on proof
of knowledge of the client's bootstrap public key. An attack on the
bootstrapping method which substitutes the public key of a corrupted
device for the public key of an honest device can result in the TLS
sever on-boarding and trusting the corrupted device.
Trust on the part of the client is not strong and is based on an
assumption that the public bootstrapping key is not widely
disseminated. If an adversary has knowledge of the bootstrap public
key, the adversary may be able to make the client bootstrap against
the adversary's network. For example, if an adversary intercepts and
scans QR labels on clients, and the adversary can force the client to
connect to its server, then the adversary can complete the TLS-POK
handshake with the client and the client will connect to the
adversary's server. Since physical possession implies ownership,
there is nothing to prevent a stolen device from being on-boarded.
7. Informative References
[DPP] Wi-Fi Alliance, "Device Provisioning Profile", 2020.
Friel & Harkins Expires August 26, 2021 [Page 8]
Internet-Draft TLS-POK February 2021
[I-D.jhoyla-tls-extended-key-schedule]
Hoyland, J. and C. Wood, "TLS 1.3 Extended Key Schedule",
draft-jhoyla-tls-extended-key-schedule-03 (work in
progress), December 2020.
[I-D.lear-eap-teap-brski]
Lear, E., Friel, O., Cam-Winget, N., and D. Harkins, "TEAP
Update and Extensions for Bootstrapping", draft-lear-eap-
teap-brski-05 (work in progress), November 2019.
[I-D.stebila-tls-hybrid-design]
Steblia, D., Fluhrer, S., and S. Gueron, "Hybrid key
exchange in TLS 1.3", draft-stebila-tls-hybrid-design-03
(work in progress), February 2020.
[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>.
[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>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/info/rfc7030>.
[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>.
[Stajano] Anderson, S., "The Ressurecting Ducking: Security Issues
for Ad-Hoc Wireless Networks", 1999.
Authors' Addresses
Owen Friel
Cisco
Email: ofriel@cisco.com
Friel & Harkins Expires August 26, 2021 [Page 9]
Internet-Draft TLS-POK February 2021
Dan Harkins
Hewlett-Packard Enterprise
Email: daniel.harkins@hpe.com
Friel & Harkins Expires August 26, 2021 [Page 10]