BRSKI-CLE: A Certificateless Enrollment protocol in BRSKI

Internet-Draft	BRSKI-CLE	July 2023
Yan	Expires 11 January 2024	[Page]

Abstract

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

1. Introduction

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

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

IDevID: An Initial Device Identifier X.509 certificate installed by the vendor on new equipment. This is a term from 802.1AR [IDevID].¶

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. Adaptations to BRSKI

2.1. 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 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)    |          .
|       |        |            |       |           |          .
|       |     .  |            |       +-----+-----+          .
|IDevID |     .  +------------+             | BESKI-CLE      .
|       |     .           +-----------------+----------+     .
|       |     .           |                            |     .
|       |     .           | Authentication Centre(AC)  |     .
+-------+     .           |                            |     .
              .           +----------------------------+     .
              .                                              .
              ................................................
                             "Domain" Components

Figure 1: Architecture Overview

2.2. Enrollment Protocol

After imprinting, the pledge must begin the process of enrollment. A message flow of the enrollment protocol is shown in Figure 2.¶

+----------+                 +-----------+                +--------+
|          |                 |           |                |        |
|  Pledge  |                 | Registrar |                |   AC   |
|          |                 |           |                |        |
+-----+----+                 +-----+-----+                +----+---+
      |                            |                           |
      |    [imprint finished]      |           IDevID          |
      |                            +-------------------------->|
      |                            |        AllowListSet       |
      |                            |                           |
      |                            |                           |
      |        ID_P,CS_P           |                           |
      +--------------------------->|         ID_P,CS_P         |
      |      PubKeyRequest         +-------------------------->|
      |                            |        PubKeyRequest      |
      |                            |                           |
      |                            |      ID_AC,PK_AC,CS_AC    |
      |     ID_AC,PK_AC,CS_AC      |<--------------------------+
      |<---------------------------+       PubKeyResponse      |
      |      PubKeyResponse        |                           |
      |                            |                           |
      |  Enc( ID_P,symKey,PK_P)    |                           |
      +--------------------------->|   Enc(ID_P,symKey,PK_P)   |
      |     CredentialRequest      +-------------------------->|
      |                            |    CredentialRequest      |
      |                            |                           |
      |                            |    AEAD(ID_P,Cred,pSK)    |
      |     AEAD(ID_P,Cred,pSK)    |<--------------------------+
      |<---------------------------+     CredentialResponse    |
      |     CredentialResponse     |                           |
      |                            |                           |

Figure 2: Message Flow of Enrollment Protocol

There are three phases in the enrollment protocol: the preliminary phase, the public key obtaining and the credential obtaining.¶

2.2.1. Preliminary Phase

In this phase, the registrar registers the pledge's IDevID on the AC. The format of the AllowListSet message is shown below.¶

AllowListSet = (
    IDevID: string,
)

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

2.2.2. 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.¶

PubKeyRequest = (
    ID_P: int,
    CS_P: CipherSuite_list,
)

CipherSuite_list=(
    CipherSuite1: int,
    ...
    Cipher_SuiteN: int,
)

ID_P = hash(IDevID)

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

PubKeyResponse = (
    ID_AC: int,
    PK_AC: int,
    CS_AC: int,
)

ID_AC: The identity of the AC.¶

PK_AC: The AC's public key.¶

CS_AC: The cipher suite choosen by the AC.¶

2.2.3. 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.¶

CredentialRequest = Enc (
    ID_P: int,
    symKey: int,
    PK_P: int,
)

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

CredentialResponse= AEAD(
    ID_P: int,
    Cred: int,
    pSK: int,
)

AEAD: AEAD (Authenticated Encryption with Associated Data) functions provide a unified encryption and authentication operation which turns plaintext into authenticated ciphertext and back again. [RFC5116]¶

Cred: The credential of the pledge.¶

pSK: The pledge's partial private key from the AC.¶

2.3. 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 Figure 3. The initiator acts as a client. The responder acts as a server.¶

+--------+                 +--------+
|        |                 |        |
| Client |                 | Server |
|        |                 |        |
+----+---+                 +----+---+
     |                          |
     |   ID_C,Cred_C,G_C,CS_C   |
     +------------------------->|
     |        Credential        |
     |                          |
     |   ID_S,Cred_S,G_S,CS_S   |
     |<-------------------------+
     |        Credential        |
     |                          |
     |        AuthCode_C        |
     +------------------------->|
     |     ProofOfPossession    |
     |                          |
     |         AuthCode_S       |
     |<-------------------------+
     |    ProofOfPossession     |

Figure 3: Message Flow of Mutual Authentication Protocol

There are two phases for mutual authentication: credential exchange and proof-of-possession exchange.¶

2.3.1. 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 Section 3.2. The format of the Credential message is shown below.¶

Credential=（
    ID_X: int,
    Cred_X: int,
    G_X: int,
    CS_X: int,
）
X denotes the sending side, "C" for the client, "S" for the server.

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

2.3.2. 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.¶

ProofOfPossession=(
    AuthCode_X: int,
)
X denotes the sending side, "C" for the client, "S" for the server.

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

3. Key Derivation

3.1. 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.¶

SK_P=a, PK_P=a*G

AC’s private key and public key are an ECC key pair.¶

SK_AC=b, PK_AC=b*G

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

cred = c*G+PK_P

Then, the AC calculate the partial private key of the pledge.¶

pSK=c+Hash(ID_P || ID_AC || cred)*SK_AC

After receiving the CredentialResponse message, the pledge must calculate its final private and public keys.¶

fSK=SK_P+pSK
fPK= cred+ Hash(ID_P || ID_AC || cred)*PK_AC

fSK: The final private key of the pledge. fPK: The final public key of the pledge.¶

3.2. 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:¶

G_X=x*G

The ephemeral public key of the server is:¶

G_Y=y*G

After receiving the client's Credential message, the server must calculate the following values:¶

fPK_C=cred_C+ Hash(ID_C || ID_AC || cred_C)*PK_AC
cv=cred_C || cred_S || ID_C || ID_S || G_X || G_Y
MK=(y + Hash(cv) *  fSK_S) *   (G_X + Hash(cv) * fPK_C)
AuthKey || EncKey = hkdf(MK, cv || "WORKKEY")

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=cred_S+ Hash(ID_S || ID_AC || cred_S)*PK_AC
cv=cred_C || cred_S || ID_C || ID_S || G_X || G_Y
MK=(x + Hash(cv) *  fSK_C) *   (G_Y + Hash(cv) * fPK_S)
AuthKey || EncKey = hkdf(MK, cv || "WORKKEY")

fPK_S: The final public key of the server.¶

In the proof-of-possession exchange, the client and server calculate the same authentication codes.¶

AuthCode_S=HMAC(AuthKey, MK || “AUTH_SERVER”)
AuthCode_C=HMAC(AuthKey, MK || “AUTH_CLIENT”)

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>.
[RFC5116]: McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <https://www.rfc-editor.org/rfc/rfc5116>.
[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

[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, 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-05, 28 June 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-ae-05>.
[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-16, 13 June 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-acme-integrations-16>.
[IDevID]: IEEE, "IEEE Standard for Local and metropolitan area networks - Secure Device Identity", IEEE 802.1AR , August 2018, <https://1.ieee802.org/security/802-1ar>.