anima L. Yan, Ed. Internet-Draft Huawei Intended status: Standards Track 10 July 2023 Expires: 11 January 2024 BRSKI-CLE: A Certificateless Enrollment protocol in BRSKI draft-yan-anima-brski-cle-00 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. 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 11 January 2024. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Yan Expires 11 January 2024 [Page 1] Internet-Draft BRSKI-CLE July 2023 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 . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Adaptations to BRSKI . . . . . . . . . . . . . . . . . . . . 4 2.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Enrollment Protocol . . . . . . . . . . . . . . . . . . . 5 2.2.1. Preliminary Phase . . . . . . . . . . . . . . . . . . 6 2.2.2. Public Key Obtaining . . . . . . . . . . . . . . . . 7 2.2.3. Credential Obtaining . . . . . . . . . . . . . . . . 8 2.3. Mutual Authentication Protocol . . . . . . . . . . . . . 8 2.3.1. credential exchange . . . . . . . . . . . . . . . . . 9 2.3.2. proof-of-possession exchange . . . . . . . . . . . . 10 3. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Enrollment Protocol . . . . . . . . . . . . . . . . . . . 10 3.2. Mutual Authentication Protocol . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . 13 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 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. Yan Expires 11 January 2024 [Page 2] Internet-Draft BRSKI-CLE July 2023 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]. Yan Expires 11 January 2024 [Page 3] Internet-Draft BRSKI-CLE July 2023 *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. Yan Expires 11 January 2024 [Page 4] Internet-Draft BRSKI-CLE July 2023 +------------------------+ +--------------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. Yan Expires 11 January 2024 [Page 5] Internet-Draft BRSKI-CLE July 2023 +----------+ +-----------+ +--------+ | | | | | | | 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. Yan Expires 11 January 2024 [Page 6] Internet-Draft BRSKI-CLE July 2023 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. Yan Expires 11 January 2024 [Page 7] Internet-Draft BRSKI-CLE July 2023 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. Yan Expires 11 January 2024 [Page 8] Internet-Draft BRSKI-CLE July 2023 +--------+ +--------+ | | | | | 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. Yan Expires 11 January 2024 [Page 9] Internet-Draft BRSKI-CLE July 2023 *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. Yan Expires 11 January 2024 [Page 10] Internet-Draft BRSKI-CLE July 2023 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: Yan Expires 11 January 2024 [Page 11] Internet-Draft BRSKI-CLE July 2023 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”) 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, . [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, . [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, . Yan Expires 11 January 2024 [Page 12] Internet-Draft BRSKI-CLE July 2023 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, . [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, . [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, . [IDevID] IEEE, "IEEE Standard for Local and metropolitan area networks - Secure Device Identity", IEEE 802.1AR , August 2018, . 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 11 January 2024 [Page 13]