anima L. Yan, Ed. Internet-Draft Huawei Intended status: Standards Track 23 October 2023 Expires: 25 April 2024 BRSKI-CLE: A Certificateless Enrollment framework in BRSKI draft-yan-anima-brski-cle-01 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. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. Yan Expires 25 April 2024 [Page 1] Internet-Draft BRSKI-CLE October 2023 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Mutual authentication between the pledge and registrar . 5 3. Enrollment framework . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 6.2. Informative References . . . . . . . . . . . . . . . . . 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 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]. Yan Expires 25 April 2024 [Page 2] Internet-Draft BRSKI-CLE October 2023 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. Yan Expires 25 April 2024 [Page 3] Internet-Draft BRSKI-CLE October 2023 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. Yan Expires 25 April 2024 [Page 4] Internet-Draft BRSKI-CLE October 2023 +------------------------+ +--------------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. Yan Expires 25 April 2024 [Page 5] Internet-Draft BRSKI-CLE October 2023 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. Yan Expires 25 April 2024 [Page 6] Internet-Draft BRSKI-CLE October 2023 +----------+ +-----------+ +--------+ | | | | | | | 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) | | (E) |<--------------------------+ |<-------------------------+ | | | | [] 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. Yan Expires 25 April 2024 [Page 7] Internet-Draft BRSKI-CLE October 2023 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, May 2021, . [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 6.2. Informative References [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, . [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, Yan Expires 25 April 2024 [Page 8] Internet-Draft BRSKI-CLE October 2023 draft-ietf-anima-constrained-voucher-21, 7 July 2023, . [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, 20 October 2023, . [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, 13 July 2023, . [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, 7 July 2023, . [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, 25 August 2023, . [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, 20 October 2023, . Yan Expires 25 April 2024 [Page 9] Internet-Draft BRSKI-CLE October 2023 [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, 18 August 2023, . Acknowledgements The authors would like to thank... Contributors Author's Address Lei YAN (editor) Huawei Ruanjiandadao Road Nanjing 210000 China Email: ray.yanlei@huawei.com Yan Expires 25 April 2024 [Page 10]