Bootstrapped TLS Authentication with Proof of Knowledge (TLS-POK)

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 20 August 2024.¶

Copyright Notice

Copyright (c) 2024 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 include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

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 a device has a public / private keypair, and 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. [duckling] presents a functional security model to address this asymmetry.¶

Device on-boarding protocols such as the Device Provisioning Profile [DPP], also referred to as Wi-Fi Easy Connect, address this use case but they have drawbacks. [DPP] for instance does not support wired network access, and does not specify how the device's DPP keypair can be used in a TLS handshake. This document describes an on-boarding protocol that can be used for wired network access, which we refer to as TLS Proof of Knowledge or TLS-POK.¶

This document does not address the problem of Wi-Fi network discovery, where a bootstrapping device detects multiple different Wi-Fi networks and needs a more robust and scalable mechanism than simple round-robin to determine the correct network to attach to. DPP addresses this issue. Thus, the intention is that DPP is the recommended mechanism for bootstrapping against Wi-Fi networks, and TLS-POK is the recommended mechanism for bootstrapping against wired networks.¶

2. Bootstrap Key

The mechanism for on-boarding of devices defined in this document relies on an elliptic curve (EC) bootstrap key (BSK). This BSK MUST be from a cryptosystem suitable for doing ECDSA. A bootstrapping client device has an associated EC BSK. The BSK may be static and baked into device firmware at manufacturing time, or may be dynamic and generated at on-boarding time by the device. The BSK public key MUST be encoded as the ASN.1 SEQUENCE SubjectPublicKeyInfo from [RFC5280]. If the BSK public key can be shared in a trustworthy manner with a TLS server, a form of "entity authentication" (the step from which all subsequent authentication proceeds) can be obtained.¶

The exact mechanism by which the server gains knowledge of the BSK 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 uploading of a Bill of Materials (BOM) which includes the public key. 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 BSK public keys corresponding to multiple devices, and existing TLS mechanisms are leveraged that enable the server to identity a specific bootstrap public key corresponding to a specific device.¶

Using the process defined herein, the client proves to the server that it has possession of the private key of its BSK. Provided that the mechanism in which the server obtained the BSK public 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 BSK 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 [duckling]).¶

3. Bootstrapping in TLS 1.3

Bootstrapping in TLS 1.3 leverages [RFC8773] Certificate-Based Authentication with an External Pre-Shared Key. The External PSK (EPSK) is derived from the BSK public key as described in Section 3.1, and the EPSK is imported using [RFC9258] Importing External Pre-Shared Keys (PSKs) for TLS 1.3. As the BSK public key is an ASN.1 SEQUENCE SubjectPublicKeyInfo, the client presents a raw public key certificate as specified in [RFC7250] Using Raw Public Keys in TLS and DTLS.¶

The TLS PSK handshake gives the client proof that the server knows the BSK public key. Certificate based authentication of the client to the server using the BSK gives the server proof that the client knows the BSK private key. This satisfies the proof of ownership requirements outlined in Section 1.¶

epskid = HKDF-Expand(HKDF-Extract(<>, Base Key),
                       "tls13-bspsk-identity", L)
where:
  - epskid is the EPSK External Identity
  - <> is a NULL salt
  - Base Key is the DER-encoded ASN.1 subjectPublicKeyInfo
    representation of the BSK public key
  - L is the length of the digest of the underlying hash
    algorithm

struct {
   opaque external_identity<1...2^16-1>;
   opaque context<0..2^16-1>;
   uint16 target_protocol;
   uint16 target_kdf;
} ImportedIdentity;

external_identity = epskid
context = "tls13-bsk"
target_protocol = TLS1.3(0x0304)
target_kdf = HKDF_SHA256(0x0001)

         Client                                            Server
         --------                                          --------
         ClientHello
         + cert_with_extern_psk
         + client_cert_type=RawPublicKey
         + key_share
         + pre_shared_key           -------->
                                                        ServerHello
                                             + cert_with_extern_psk
                                    + client_cert_type=RawPublicKey
                                                        + key_share
                                                   + pre_shared_key
                                              {EncryptedExtensions}
                                               {CertificateRequest}
                                                      {Certificate}
                                                {CertificateVerify}
                                    <--------            {Finished}
         {Certificate}
         {CertificateVerify}
         {Finished}                 -------->
         [Application Data]         <------->    [Application Data]

                Figure 1: TLS 1.3 TLS-POK Handshake

4. Using TLS Bootstrapping in EAP

Upon "link up", an Authenticator on an 802.1X-protected port will issue an EAP Identity 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 [RFC7542]). This document uses the NAI mechanisms defined in [I-D.dekok-emu-eap-arpa] and defines the username field "tls-pok-dpp" that is prepended to the EAP realm "eap.arpa" yielding an initial identity of "tls-pok-dpp@eap.arpa". This identifier SHOULD be included in the EAP Identity response 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-dpp@eap.arpa) ->

                            <- EAP-Request/
                            EAP-Type=TEAP
                           (TLS Start)

    EAP-Response/
    EAP-Type=TEAP
    (TLS client_hello with
     tls_cert_with_extern_psk
     and pre_shared_key) ->

                       .
                       .
                       .

Both client and server have derived the EPSK and associated [RFC9258] ImportedIdentity from the BSK public key as described in Section 3.1. When the client starts the TLS exchange in the EAP transaction, it includes the ImportedIdentity structure in the pre_shared_key extension in the ClientHello. When the server received the ClientHello, it extracts the ImportedIdentity and looks up the EPSK and BSK public key. As previously mentioned in Section 2, the exact mechanism by which the server has gained knowledge of or been provisioned with the BSK public key is outside the scope of this document.¶

The server continues with the TLS handshake and uses the EPSK to prove that it knows the BSK public key. When the client replies with its Certificate, CertificateVerify and Finished messages, the server MUST ensure that the public key in the Certificate message matches the BSK public key.¶

Once the TLS handshake completes, the client and server have established mutual trust. The server can then proceed to provision a credential onto the client using, for example, the mechanisms outlined in [RFC7170].¶

The client can then use this provisioned credential for subsequent network authentication. The BSK is only used during bootstrap, and it not used for any subsequent network access.¶

5. IANA Considerations

None.¶

6. Security Considerations

Bootstrap and trust establishment by the TLS server is based on proof of knowledge of the client's bootstrap public key, a non-public datum. The TLS server obtains proof that the client knows its bootstrap public key and, in addition, also possesses its corresponding private key.¶

Trust on the part of the client is based on successful completion of the TLS 1.3 handshake using the EPSK derived from the BSK. This proves to the client that the server knows its BSK public key. In addition, the client assumes that knowledge of its BSK public key is not widely disseminated and therefore any server that proves knowledge of its BSK public key is the appropriate server from which to receive provisioning, for instance via [RFC7170]. [duckling] describes a security model for this type of "imprinting".¶

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

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

Authors' Addresses