BRSKI-CLE: A Certificateless Enrollment protocol in BRSKI

BRSKI-CLE: A Certificateless Enrollment protocol in BRSKI Huawei

Ruanjiandadao Road Nanjing 210000 China ray.yanlei@huawei.com

Operations and Management anima certificateless BRSKI enrollment Bootstrapping Remote Secure Key Infrastructure (BRSKI, RFC 8995) is an automated bootstrap protocol for unconfigured devices called "pledges". Existing enrollment protocols in BRSKI are all based on certificates, which are not suitable for constrained IoT devices. This document defines a certificateless enrollment protocol in BRSKI (BRSKI-CLE) for constrained IoT devices. To achieve a lightweight protocol, a credential based on public keys is designed to replace the domain certificate used in BRSKI. An authentication centre (AC) replaced the certification authority (CA) is used to issue the credential to the pledge. A new mutual authentication protocol is also designed to authenticate using the credentials.

Introduction The Bootstrapping Remote Secure Key Infrastructure (BRSKI) 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) , which is based on certificates, as the enrollment protocol. Other alternative enrollment protocols in BRSKI, such as Constrained BRSKI, BRSKI-AE and , are also based on certificates. After enrollment, the pledge obtains a domain certificate from the registrar. The pledge will authenticate each other by the domain certificate in further communication. A certificate chain typically includes three certificates at least: an end entity certificate, a certification authority (CA) certificate and a root CA certificate. A long certificate chain leads to massive volumes of transmitted data and a long verification time. Therefore, the authentication using certificates is desirable for constrained IoT devices with limited memory or computation ability. Moreover, the process of authentication using certificates typically has two steps. Firstly, the certificate chain is verified by every certificate's signature and its signer's public key. The second step is to verify the signature, which is the possession proof of the private key corresponding to the public key in the certificate. The identity information on the certificate is not checked by the authentication program and is only presented for human reading in most cases. Hence, in the machine-to-machine scenario, as a machine does not need to understand the identity information on the certificate, the identity information in certificates is redundant. BRSKI-CLE, alternatively to EST, is a certificateless enrollment protocol in BRSKI. The goals of BRSKI-CLE are to provide a lightweight enrollment protocol for constrained IoT devices. To enable using certificateless enrollment protocols, BRSKI-CLE makes three adaptations to BRSKI.

Instead of the certificate, a credential calculated only by public keys is designed for the authentication among Pledges.
Instead of CA, an authentication centre (AC) is used to issue credentials to the pledge during enrollment.
A new mutual authentication protocol is designed for the authentication between two Pledges by the credentials.

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. IDevID: An Initial Device Identifier X.509 certificate installed by the vendor on new equipment. This is a term from 802.1AR . 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 . Pledge: The prospective (unconfigured) device, which has an identity installed at the factory.

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 when, and only when, they appear in all capitals, as shown here.

Adaptations to BRSKI

Architecture The architecture of the components in BESKI-CLE is shown in . 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 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.

Architecture Overview ............<-------> (AC) | . | | | | | | . | | . | | +-----+-----+ . |IDevID | . +------------+ | BESKI-CLE . | | . +-----------------+----------+ . | | . | | . | | . | Authentication Centre(AC) | . +-------+ . | | . . +----------------------------+ . . . ................................................ "Domain" Components ]]>

Enrollment Protocol After imprinting, the pledge must begin the process of enrollment. A message flow of the enrollment protocol is shown in .

Preliminary Phase In this phase, the registrar registers the pledge's IDevID on the AC. The format of the AllowListSet message is shown below. IDevID: An Initial Device Identifier X.509 certificate installed by the vendor on new equipment. After authenticating the pledge successfully during imprint, the registrar must send the pledge's IDevID in the AllowListSet message to the AC. After receiving the AllowListSet message, the AC must add the IDevID to its allowlist.

Public Key Obtaining In this phase, the pledge sends the PubKeyRequest message to AC to request the AC's public key, and then the AC return its public key to the pledge in the PubKeyResponse message. The format of the PubKeyRequest message is shown below. ID_P: A number, which is derived from the IDevID, as the identity of the pledge. CS_P: The cipher suites list supported by the pledge. After receiving the PubKeyRequest message, the AC will check whether the received IDevID is on the allowlist. If the received IDevID is on the allowlist, the AC will return the PubKeyResponse message to the pledge. Otherwise, the AC should close the connection. The format of the PubKeyResponse message is shown below. ID_AC: The identity of the AC. PK_AC: The AC's public key. CS_AC: The cipher suite choosen by the AC.

Credential Obtaining In this phase, the pledge requests its credential from the AC by sending the CredentialRequest message. Then, the AC issues the credential for the pledge in the CredentialResponse message. The CredentialRequest message is encrypted by the public key of the AC. The format of the CredentialRequest message is shown below. Enc: The function encrypting by a public key. symKey: A symmetric key for the following communication. PK_P: The public key of the pledge. The CredentialResponse message is encrypted by the symmetric key received in the CredentialRequest message. The format of the CredentialResponse message is shown below. AEAD: AEAD (Authenticated Encryption with Associated Data) functions provide a unified encryption and authentication operation which turns plaintext into authenticated ciphertext and back again. Cred: The credential of the pledge. pSK: The pledge's partial private key from the AC.

Mutual Authentication Protocol After enrollment, two pledges can authenticate each other by using the credential. A message flow of the mutual authentication protocol is shown in . The initiator acts as a client. The responder acts as a server.

credential exchange In this phase, the client and the server must exchange their credentials. Then, the same master key is calculated based on the peer’s credential and ephemeral public key by the client and server. The details of key derivation are shown in . The format of the Credential message is shown below. ID_X: The identity of the sender. Cred_X: The credential of the sender. G_X: The ephemeral public key of the sender. CS_X: The cipher suites list supported by the client or the cipher suite choosen by the server.

proof-of-possession exchange In this phase, the client and the server must exchange the possession proof of the master key. The format of the ProofOfPossession message is shown below. AuthCode_X: The authentication code of the sender. If the receiving authentication code is equal to the authentication code calculated locally, the authentication is successful. Otherwise, the authentication fails.

Key Derivation

Enrollment Protocol The key derivation is based on the Schnorr signature algorithm. Assuming "a" is a random number generated by the pledge, "b" is a random number generated by the AC, and "G" is an elliptic curve base point. Pledge’s private key and public key are an Elliptic curve cryptography (ECC) key pair. AC’s private key and public key are an ECC key pair. The symKey in the CredentialRequest message is a random number. After receiving the CredentialRequest message, the credential is calculated by the AC as below. Assuming c is a random number generated by the AC. Then, the AC calculate the partial private key of the pledge. After receiving the CredentialResponse message, the pledge must calculate its final private and public keys. fSK: The final private key of the pledge. fPK: The final public key of the pledge.

Mutual Authentication Protocol Assuming "x" is a random number generated by the client, "y" is a random number generated by the server, and "G" is an elliptic curve base point. The ephemeral public key of the client is: The ephemeral public key of the server is: After receiving the client's Credential message, the server must calculate the following values: fPK_C: The final public key of the client. cv: The concatenation value as the input for the hash function. MK: The master key. AuthKey: The key for the authentication in the proof-of-possession exchange. EncKey: The symmetric key for the communication after the mutual authentication. After receiving the server's Credential message, the client must calculate the following values: fPK_S: The final public key of the server. In the proof-of-possession exchange, the client and server calculate the same authentication codes.

Security Considerations TBD.

IANA Considerations TBD.

References Normative References Bootstrapping Remote Secure Key Infrastructure (BRSKI) This document specifies automated bootstrapping of an Autonomic Control Plane. To do this, a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well. Enrollment over Secure Transport This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA. An Interface and Algorithms for Authenticated Encryption This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [STANDARDS-TRACK] Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Constrained Bootstrapping Remote Secure Key Infrastructure (BRSKI) Sandelman Software Works vanderstok consultancy Cisco Systems IoTconsultancy.nl This document defines the Constrained Bootstrapping Remote Secure Key Infrastructure (Constrained BRSKI) protocol, which provides a solution for secure zero-touch bootstrapping of resource-constrained (IoT) devices into the network of a domain owner. This protocol is designed for constrained networks, which may have limited data throughput or may experience frequent packet loss. Constrained BRSKI is a variant of the BRSKI protocol, which uses an artifact signed by the device manufacturer called the "voucher" which enables a new device and the owner's network to mutually authenticate. While the BRSKI voucher is typically encoded in JSON, Constrained BRSKI uses a compact CBOR-encoded voucher. The BRSKI voucher is extended with new data types that allow for smaller voucher sizes. The Enrollment over Secure Transport (EST) protocol, used in BRSKI, is replaced with EST- over-CoAPS; and HTTPS used in BRSKI is replaced with CoAPS. This document Updates RFC 8366 and RFC 8995. BRSKI-AE: Alternative Enrollment Protocols in BRSKI Siemens AG Siemens AG Siemens AG This document defines an enhancement of Bootstrapping Remote Secure Key Infrastructure (BRSKI, RFC 8995) that supports alternative certificate enrollment protocols, such as CMP. This offers the following advantages. Using authenticated self-contained signed objects for certification requests and responses, their origin can be authenticated independently of message transfer. This supports end-to-end authentication (proof of origin) also over multiple hops, as well as asynchronous operation of certificate enrollment. This in turn provides architectural flexibility where to ultimately authenticate and authorize certification requests while retaining full-strength integrity and authenticity of certification requests. ACME Integrations for Device Certificate Enrollment Cisco Cisco Ernst & Young Sandelman Software Works This document outlines multiple advanced use cases and integrations that ACME facilitates without any modifications or enhancements required to the base ACME specification. The use cases include ACME integration with EST, BRSKI and TEAP. IEEE Standard for Local and metropolitan area networks - Secure Device Identity IEEE

Acknowledgements The authors would like to thank...

Contributors