BRSKI-CLE: A Certificateless Enrollment framework in BRSKI

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 25 April 2024.¶

Copyright Notice

Copyright (c) 2023 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

There are various constrained IoT devices in the hospital, such as anesthesia syringe pumps, electrocardiogram monitors, smart bed cards, etc. The access gateway is required to authenticate each connected IoT device. Otherwise, adversaries can easily steal medical data through illegally accessed devices. Certificates are widely utilized for authentication nowadays. However, the RAM that can be used for authentication is commonly less than 10 KB in constrained medical IoT devices. Moreover, some extremely constrained medical IoT devices only have about 8 KB RAM. These constrained IoT devices are also common in scenarios other than in the hospital. The IoT devices with around 10 KB RAM are defined as Class 1 constrained devices in [RFC7228]. The limited RAM resources make the Class 1 constrained IoT devices hard to use certificates. Even using CBOR to encode certificates, the certificate chain is also heavy for the Class 1 constrained IoT devices. The CBOR encoded certificate chain in 4 length is around 4 KB, in 2 length is about 1.5 KB as shown in [I-D.ietf-cose-cbor-encoded-cert].¶

The Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995] protocol provides a solution for secure zero-touch (automated) bootstrap of new (unconfigured) devices that are called "pledges". After being authenticated by the server "registrar", a pledge presents its key material to the network and acquires a network-specific identity. This process is called "enrollment". BRSKI typically uses Enrollment over Secure Transport (EST) [RFC7030], which is based on certificates, as the enrollment protocol. Other alternative enrollment protocols in BRSKI, such as Constrained BRSKI[I-D.ietf-anima-constrained-voucher], BRSKI-AE [I-D.ietf-anima-brski-ae] and [I-D.ietf-acme-integrations], are also based on certificates.¶

This document describes a certificateless enrollment framework in BRSKI (BRSKI-CLE) for constrained IoT devices. Considering the evolution towards quantum-safe algorithms, the framework is based on the Key Encapsulation Mechanism (KEM). The framework uses the public key of the server end to encapsulate the symmetric key. The server end only needs to configure one public key to handle an enormous amount of client ends (the IoT devices). Compared with encapsulating by the public key of the client end, such as EDHOC [I-D.ietf-lake-edhoc], a unique public key is required to be configured on each IoT device. When the amount of IoT devices is huge, encapsulating by the public key of the client end is less efficient in deployment.¶

The client end is assumed to have previously known the server end's public key in [I-D.wiggers-tls-authkem-psk]. Otherwise, the client end cannot encapsulate the symmetric key by the server end's public key. In the BRSKI scenario, a pledge cannot previously know a domain server's public key. Thus, the KEM-based authentication mechanism in [I-D.wiggers-tls-authkem-psk] cannot be utilized in the enrollment of BRSKI directly.¶

The mutual authentication between the pledge and the registrar in BRSKI can also make by EDHOC, as shown in [I-D.selander-lake-authz]. Moreover, the pledge's credential is supported transporting by reference rather than by value. Therefore, cooperating with the authentication mechanism shown in [I-D.selander-lake-authz], a constrained IoT device has no need to configure a public key to identify itself for the whole bootstrapping process.¶

An authentication centre (AC) is used for issuing lightweight credentials, such as CBOR Web Tokens (CWTs), to the pledges in the enrollment phase of BRSKI. This document does not specify any lightweight credentials.¶

2. Architecture

The architecture of the components in BESKI-CLE is shown in Figure 1. Compared with the architecture of BRSKI, the CA is replaced by the AC. The AC can be implemented on the registrar or as a backend domain component. After imprinting, the pledge can use BESKI-CLE to obtain a lightweight credential from the AC. It is assumed that the communication between the registrar and the AC is protected by a security protocol, such as TLS or DTLS, and they can authenticate each other using the security protocol.¶

                                           +------------------------+
   +--------------Drop-Ship----------------| Vendor Service         |
   |                                       +------------------------+
   |                                       | M anufacturer|         |
   |                                       | A uthorized  |Ownership|
   |                                       | S igning     |Tracker  |
   |                                       | A uthority   |         |
   |                                       +--------------+---------+
   |                                                      ^
   |                                                      |  BRSKI-
   V                                                      |   MASA
+-------+     ............................................|...
|       |     .                                           |  .
|       |     .  +------------+       +-----------+       |  .
|       |     .  |            |       |           |       |  .
|Pledge |     .  |   Join     |       | Domain    <-------+  .
|       |     .  |   Proxy    |       | Registrar |          .
|       <-------->............<------->   (AC)    |          .
|       | EDHOC  |            | EDHOC |           |          .
|       |     .  |            |       +-----+-----+          .
|IDevID |     .  +------------+             | BESKI-CLE      .
|       |     .           +-----------------+----------+     .
|       |     .           |                            |     .
|       |     .           | Authentication Centre(AC)  |     .
+-------+     .           |                            |     .
              .           +----------------------------+     .
              .                                              .
              ................................................
                             "Domain" Components

                         Credential
Pledge       Registrar     Database
                             (MASA)
  |  ID_CRED_I   |              |
  +------------->|  ID_CRED_I   |
  |   message_3  +------------->|
  |              |              |
  |              |   CRED_I     |
  |    EDHOC     |<-------------+
  |              |              |

3. Enrollment framework

After imprinting, the pledge begins the process of enrollment. A basic protocol flow is shown in Figure 3.¶

+----------+               +-----------+                +--------+
|          |               |           |                |        |
|  Pledge  |               | Registrar |                |   AC   |
|          |               |           |                |        |
+-----+----+               +-----+-----+                +----+---+
      |                          |                           |
      |    [imprint finished]    | (A) Pledge's ID Register  |
      |                          +-------------------------->|
      |                          |                           |
      |  (B) Public Key Request  |                           |
      +------------------------->|  (B) Public Key Request   |
      |                          +-------------------------->|
      |                          |                           |
      |                          |      (C) Public Key       |
      |     (C) Public Key       |<--------------------------+
      |<-------------------------+                           |
      |                          |                           |
      | (D) [Credential Request] |                           |
      +------------------------->| (D) [Credential Request]  |
      |                          +-------------------------->|
      |                          |                           |
      |                          |    (E) <Credential>       |
      |    (E) <Credential>      |<--------------------------+
      |<-------------------------+                           |
      |                          |                           |

          [] Indicates messages protected using AC's public key.
          <> Indicates messages protected using a symmetric key.

Registering Pledge's ID (A):

After authenticating the pledge successfully during imprint, the registrar registers the pledge's ID on the AC. The pledge's ID is the unique identity set by the pledge's vendor, such as the MAC address. The AC may record the pledge's ID on the allowlist.¶

Requesting a public key (B):

The pledge makes a public key request to the AC. The pledge should send its ID in the request.¶

Public key response (C):

If the pledge's ID is on the allowlist, the AC returns its public key to the pledge.¶

Credential request (D):

The pledge interacts with the AC to request a local credential. Firstly, the pledge generates a symmetric key and encapsulates the symmetric key by the received public key. Secondly, the pledge sends the encapsulated key to the AC for credential transporting.¶

Credential response (E):

Firstly, the AC decapsulate the symmetric key by its private key. Secondly, the AC generates a credential for the pledge and encrypts the credential by the received symmetric key. Lastly, the AC sends the encrypted credential to the pledge.¶

4. Security Considerations

TBD.¶

5. IANA Considerations

TBD.¶

Acknowledgements

The authors would like to thank...¶

Contributors

Author's Address