Internet DRAFT - draft-yan-anima-brski-cle
draft-yan-anima-brski-cle
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) <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.
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, <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, October 2013,
<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, March 1997,
<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,
May 2017, <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, May 2014,
<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,
Yan Expires 25 April 2024 [Page 8]
Internet-Draft BRSKI-CLE October 2023
draft-ietf-anima-constrained-voucher-21, 7 July 2023,
<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, 20
October 2023, <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, 13 July 2023,
<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, 7 July 2023,
<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, 25
August 2023, <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, 20 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-cose-
cbor-encoded-cert-07>.
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,
<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
Email: ray.yanlei@huawei.com
Yan Expires 25 April 2024 [Page 10]
