Internet-Draft BRSKI-CLE October 2023
Yan Expires 25 April 2024 [Page]
Workgroup:
anima
Internet-Draft:
draft-yan-anima-brski-cle-01
Published:
Intended Status:
Standards Track
Expires:
Author:
L. Yan, Ed.
Huawei

BRSKI-CLE: A Certificateless Enrollment framework in BRSKI

Abstract

The Class 1 constrained IoT devices, defined in RFC7228, may be unable to use certificates within limited RAM. Exiting enrollment protocols of BRSKI are all using certificates. This document defines a certificateless enrollment framework in BRSKI (BRSKI-CLE) for constrained IoT devices. Considering the evolution towards quantum-safe algorithms, the framework is based on Key Encapsulation Mechanism (KEM). Cooperating with the authentication mechanism shown in I-D.selander-lake-authz, a constrained IoT device does not 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 constrained IoT devices. This document does not specify any lightweight credentials.

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.

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.

1.1. Terminology

AC: The authentication centre provides the credential issuance for the pledges.

Domain: The set of entities that share a common local trust anchor.

enrollment: The process where a device presents key material to a network and acquires a network-specific identity.

imprint: The process where a device obtains the cryptographic key material to identify and trust future interactions with a network. This process is the step before enrollment, as defined in BRSKI [RFC8995].

Pledge: The prospective (unconfigured) device, which has an identity installed at the factory.

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

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
Figure 1: Architecture Overview

2.1. Mutual authentication between the pledge and registrar

EDHOC can be a lightweight substitute of TLS for the mutual authentication between the pledge and registrar, as described in [I-D.selander-lake-authz]. Moreover, the pledge's credential is supported transporting by reference rather than by value. Thus, there is no need to configure a credential or a public key on the pledge to identify itself for the mutual authentication.

The message flow of transporting credentials by reference is shown in Figure 2, as described at the bottom of Figure 3 in [I-D.selander-lake-authz]. ID_CRED_I is used to identify the pledge's authentication credential CRED_I. Pledge sends ID_CRED_I to the registrar in the message_3 of EDHOC. The registrar may use ID_CRED_I to obtain the pledge's credential CRED_I from the MASA. Credential lookup of CRED_I may involve MASA or other credential databases.

                         Credential
Pledge       Registrar     Database
                             (MASA)
  |  ID_CRED_I   |              |
  +------------->|  ID_CRED_I   |
  |   message_3  +------------->|
  |              |              |
  |              |   CRED_I     |
  |    EDHOC     |<-------------+
  |              |              |
Figure 2: Transporting Credential by reference

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.
Figure 3: Basic Protocol Flow
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.

6. References

6.1. Normative References

[RFC8995]
Pritikin, M., Richardson, M., Eckert, T., Behringer, M., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, , <https://www.rfc-editor.org/rfc/rfc8995>.
[RFC7030]
Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, , <https://www.rfc-editor.org/rfc/rfc7030>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.

6.2. Informative References

[RFC7228]
Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, , <https://www.rfc-editor.org/rfc/rfc7228>.
[I-D.ietf-anima-constrained-voucher]
Richardson, M., Van der Stok, P., Kampanakis, P., and E. Dijk, "Constrained Bootstrapping Remote Secure Key Infrastructure (BRSKI)", Work in Progress, Internet-Draft, draft-ietf-anima-constrained-voucher-21, , <https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher-21>.
[I-D.ietf-anima-brski-ae]
von Oheimb, D., Fries, S., and H. Brockhaus, "BRSKI-AE: Alternative Enrollment Protocols in BRSKI", Work in Progress, Internet-Draft, draft-ietf-anima-brski-ae-06, , <https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-ae-06>.
[I-D.ietf-acme-integrations]
Friel, O., Barnes, R., Shekh-Yusef, R., and M. Richardson, "ACME Integrations for Device Certificate Enrollment", Work in Progress, Internet-Draft, draft-ietf-acme-integrations-17, , <https://datatracker.ietf.org/doc/html/draft-ietf-acme-integrations-17>.
[I-D.selander-lake-authz]
Selander, G., Mattsson, J. P., Vučinić, M., Richardson, M., and A. Schellenbaum, "Lightweight Authorization using Ephemeral Diffie-Hellman Over COSE", Work in Progress, Internet-Draft, draft-selander-lake-authz-03, , <https://datatracker.ietf.org/doc/html/draft-selander-lake-authz-03>.
[I-D.ietf-lake-edhoc]
Selander, G., Mattsson, J. P., and F. Palombini, "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in Progress, Internet-Draft, draft-ietf-lake-edhoc-22, , <https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-22>.
[I-D.ietf-cose-cbor-encoded-cert]
Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and M. Furuhed, "CBOR Encoded X.509 Certificates (C509 Certificates)", Work in Progress, Internet-Draft, draft-ietf-cose-cbor-encoded-cert-07, , <https://datatracker.ietf.org/doc/html/draft-ietf-cose-cbor-encoded-cert-07>.
[I-D.wiggers-tls-authkem-psk]
Wiggers, T., Celi, S., Schwabe, P., Stebila, D., and N. Sullivan, "KEM-based pre-shared-key handshakes for TLS 1.3", Work in Progress, Internet-Draft, draft-wiggers-tls-authkem-psk-00, , <https://datatracker.ietf.org/doc/html/draft-wiggers-tls-authkem-psk-00>.

Acknowledgements

The authors would like to thank...

Contributors

Author's Address

Lei YAN (editor)
Huawei
Ruanjiandadao Road
Nanjing
210000
China