Radio base station zero touch service based on acme

Abstract

Systems and methods are disclosed for radio base station zero touch serviced based on Automatic Certificate Management Environment (ACME). In one embodiment, a method performed by an ACME at a radio base station comprises any one or more of the following: sending, to an ACME server, an initial request for a token of a certain token type; receiving, from the ACME server, an initial response that indicates a vendor Token Authority (TA); sending a first request for the token of the certain token type to the vendor TA; receiving, from the vendor TA, a first response comprising information that indicates a second TA; and sending a second request for the token of the certain token type to the second TA.

Description

RADIO BASE STATION ZERO TOUCH SERVICE BASED ON ACMERELATED APPLICATIONS

[0001] This application claims the benefit of European patent application serial number 24305281.8, filed February 20, 2024, and international patent application serial number PCT / CN2024 / 077706, filed February 20, 2024, the disclosures of which are hereby incorporated herein by reference in their entireties.TECHNICAL FIELD

[0002] The present disclosure relates to Radio Base Stations (RBSs) and, more specifically, zero touch configuration of an RBS.BACKGROUND

[0003] Currently Radio Base Stations are configured using a Zero Touch Architecture that is based on the Certificate Management Protocol (CMP).SUMMARY

[0004] Systems and methods are disclosed for radio base station zero touch serviced based on Automatic Certificate Management Environment (ACME). In one embodiment, a method performed by an ACME at a radio base station comprises any one or more of the following: sending, to an ACME server, an initial request for a token of a certain token type; receiving, from the ACME server, an initial response that indicates a vendor Token Authority (TA); sending a first request for the token of the certain token type to the vendor TA; receiving, from the vendor TA, a first response comprising information that indicates a second TA; and sending a second request for the token of the certain token type to the second TA.

[0005] In one embodiment, the vendor TA is associated to a vendor of the radio base station.

[0006] In one embodiment, the certain token type is a token type that indicates a zero touch certificate signing request.

[0007] In one embodiment, the second TA is a mobile network operator (MNO) TA (e.g., aTA associated with an MNO of a mobile network in which the radio base station is deployed). In one embodiment, the method further comprises receiving a second response from the MNO TA, the second response comprising the token. In one embodiment, the method further comprises sending a request to the ACME server, the request comprising the token. In one embodiment, the request sent to the ACME server comprises the first request, the first response, the second request,and the second response. In one embodiment, the first request, the first response, the second request, and the second response are sent / received using a JSON Web Token (JWT) mechanism that provides a trusted chain between the vendor TA and the MNO TA. In one embodiment, ACME server is a certificate authority (CA) selected by the MNO. In one embodiment, the ACME server is a CA configured for 3GPP certificate issuance.

[0008] In one embodiment, the method further comprises, prior to sending the initial request, communicating with the ACME server to create an ACME account and to thereby be associated with the vendor associated to the vendor TA.

[0009] Corresponding embodiments of radio base station including an ACME client and of an ACME client are also disclosed herein.

[0010] Embodiments of a method performed by an ACME server are also disclosed. In one embodiment, a method performed by an ACME server comprises receiving, from an ACME client at a radio base station, an initial request for a token of a certain token type and sending, to the ACME client, an initial response that indicates a vendor TA.

[0011] In one embodiment, the vendor TA is associated to a vendor of the radio base station.

[0012] In one embodiment, the certain token type is a token type that indicates a zero touch certificate signing request.

[0013] In one embodiment, the second TA is an MNO TA (e.g., a TA associated with an MNO of a mobile network in which the radio base station is deployed). In one embodiment, the method further comprises receiving, from the ACME client, a request comprising the token. In one embodiment, the request comprises a series of requests and responses between the ACME client and two or more TAs comprising the vendor TA and an MNO TA. In one embodiment, the series of request and responses are sent / received using a JWT mechanism that provides a trusted chain between the vendor TA and the MNO TA. In one embodiment, the method further comprises validating the token based on the series of requests and responses.

[0014] In one embodiment, the ACME server is a CA selected by the MNO. In one embodiment, the ACME server is a CA configured for 3GPP certificate issuance.

[0015] In one embodiment, the method further comprises, prior to receiving the initial request, communicating with the ACME client to create an ACME account and to thereby associate the ACME client with the vendor associated to the vendor TA.

[0016] Corresponding embodiments of an ACME server and a network node on which an ACME server is implemented are also disclosed.BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure.

[0018] Figure 1 illustrates the case where a Certificate Management Protocol (CMP) Client on a Radio Base Station (RBS) has been configured by the Mobile Network Operator (MNO) and is able to directly contact the appropriated Certificate Authority (CA) selected by the MNO;

[0019] Figure 2 illustrates an embodiment of a CMP Zero Touch RBS;

[0020] Figure 3 illustrates an example of an Automatic Certificate Management Environment(ACME) Zero Touch RBS, in accordance with an embodiment of the present disclosure;

[0021] Figure 4 illustrates a procedure in accordance with one example embodiment of the present disclosure; and

[0022] Figures 5, 6, and 7 are schematic block diagrams of a network node, in accordance with embodiments of the present disclosure.DETAILED DESCRIPTION

[0023] The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure.

[0024] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0025] There currently exist certain challenge(s). Currently, Radio Base Stations (RBSs) are configured using a Zero Touch Architecture that is based on the Certificate Management Protocol (CMP). However, a Zero Touch Architecture based on CMP is less than ideal for automation and deployment over a cloud infrastructure as well as for Web Public Key Infrastructure (PKI).

[0026] Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges. Embodiments of the present disclosure provide a Zero Touch Architecture using Automatic Certificate Management Environment (ACME). ACME is a protocol standardized by the Internet Engineering Task Force (IETF). ACME is very convenient forautomation and is deployed over cloud infrastructure as well as for the Web Public Key Infrastructure (PKI).

[0027] Embodiments of the present disclosure will now be described below in more detail.1 ACME used for Radio Base Stations (RBS)1.1 CMP RBS Architectures

[0028] The 3rdGeneration Partnership Project (3GPP) Technical Specification (TS) 33.210 (see, e.g., V17.1.0) specifies the establishment of Internet Protocol (IP) security (IPsec) communication between the base station and the Security Gateway (i.e., the Secure Email Gateway (SEG)). These IPsec communications are established via Internet Key Exchange version 2 (IKEv2), and the peers are authenticated by certificates issued by the operator PKI. For simplicity, it is assumed herein the Vendor and the Operator are different entities and that for example the vendor does not operate the Operator PKI.

[0029] When the base station starts the enrollment procedure, there are basically two procedure that can be envisioned:1. The Mobile Network Operator (MNO) has configured the Radio Base Station (RBS), in which case the RBS can be configured to authenticate the Certificate Authority (CA) that the MNO has selected to issue certificates.2. The MNO has not configured the RBS, in which case the RBS only has the Vendor Certificate and the Vendor Trust Anchor configured by the Vendor.1.1.1 CMP Configured RBS Architecture

[0030] Figure 1 illustrates the case where a CMP Client on an RBS has been configured by the MNO and is able to directly contact the appropriated CA selected by the MNO. This mode is designated as Direct CA communication or Client Mode . The term Client Mode here refers to the fact that CA contacted by the CMP Client is in fact usually a Registration Authority (RA) and behaves like a CMP Client toward an upstream CA. In other words, it simply relays the request behaving itself as a CMP Client. The most important argument to be configured is the CA Trust Anchor (TA), which will enable the CMP Client to authenticate the responses from the CA.

[0031] The CA is configured to authenticate the CMP messages sent by the CMP Client based on the certificate. That certificate can be the MNO certificate or the Vendor Certificate. The CA is also provisioned with the Vendor Name CA. When an MNO Certificate is available, this corresponds to a renew operation. Upon receiving the request, CMP Client requests a new certificate with a potential new key and uses the MNO Certificate to authenticate the CMPmessage. The authentication can be authenticated by the CA. The response from the CA is signed with the CA certificate. The CMP client is able to authenticate the response BECAUSE it has been configured by the MNO with the CA TA.

[0032] When the MNO Certificate is not present, the CMP Client uses the Vendor private key to sign the CMP message and provides the Vendor Certificate. The CA has been configured to trust the Vendor CA name and as such can authenticate the request as associated to the appropriated CA. The CA pre-register the RBS with the information provided by the vendor and associate to them a specific profile, that is mostly how the fields will be filled in the certificate. In many cases, the fields are built from the CN provided by the RBS. This requires some manipulation handled by the CA. The CA can generate any kind of Certificates, and these Certificates will always be accepted by the RBS. The response from the CA is signed with the CA certificate. The CMP client is able to authenticate the response BECAUSE it has been configured by the MNO with the CA TA.1.1.2 CMP Zero Touch RBS Architecture

[0033] The Zero Touch RBS provides a secure way to enable the CMP client to request a message without being configured. The main configuration parameter is to enable the CMP client to authenticate the responses from the CA selected by the MNO - which is represented as CA TA in Figure 2.

[0034] This is resolved by leveraging (1) the Vendor TA to establish an authenticated channel between the CMP Client and the Vendor CA, (2) the CMP capability to communicate a TA via the caPub field, and (3) the capability of the Vendor CA to proxy the requests to the CA selected by the MNO. In fact, the CMP architecture enables such intermediaries Certificate Authorities that are designated as Registration Authorities (RA) and works as intermediaries.

[0035] The RA is configured in a RA mode. It is able to authenticate the CMP client message signed with the Vendor CA, and the CMP Client is able to authenticate the RA responses. The RA is configured to send the certificate request to the appropriated CA and create the appropriated account for the CMP Client. There two ways the certificate can be issued from the CA:1. The RA can respond to the CMP Client with a NEW Vendor Certificate and a Pubcert set to the CA2. The RA can request the CA to issue a certificate and then forward it to the CMP Client.1.2 ACME Zero Touch ACME Architecture

[0036] This section details how the Zero Touch ACME achieves similar goals as the CMP Zero Touch Architecture. The goal is that an unconfigured ACME Client (in an RBS) is able to get a certificate with parameters provided by the MNO as well as by a CA selected by the MNO. The ACME Server may be either directly configured to the RBS or redirected via the Domain Name Server (DNS) or any Hyper Text Transfer Protocol Secure (HTTPS) mechanism.

[0037] The ACME Server is expected to be a CA specialized in 3GPP certificate issuance, but it is not expected to be configured by the MNO with each RBS information. Instead, the CA Selected by the MNO is expected to be as generic as possible. The MNO wants to control the parameters that will be in the issued certificate, and there are two issues we need to address. The first issue is that most of the parameters cannot use the traditional ACME procedures (see, e.g., RFC8555) which are based on providing a proof of control over a given resource. This proves to work very well for a Fully Qualified Domain Name (FQDN) but does not work for Distinguished names as well as other attributes. The second issue is that the very specific parameters associated to the RBS certificate cannot be known by the RBS unless these are specifically configured. This contradicts the hypothesis that RBS is unconfigured.

[0038] To handle parameters that the ACME Client will not be able to prove control over, ACME defined the Token Authority (see RFC 9447 and RFC 9448). This enables the first challenge to be solved; however, it does not enable MNO specific parameters to be provide to the certificate. More specifically, each MNO will likely have a dedicated Token Authority, and we cannot elaborate a system where each 3GPP generic ACME Server be provisioned with an up-to date description of the Token Authorities associated to each MNO.

[0039] Vendors play a specific role in the RBS ecosystem as (1) the RBS are provisioned with a Vendor Certificate issued by the Vendor and (2) the number of vendors is relatively small and stable which makes it feasible for a 3GPP ACME Server to have an up-to-date list of Vendor Token Authorities. At last, (3) the Vendor is able to bind the RBS to a specific MNO - in other terms, it knows which MNO owns the RBS and can be configured with the Token Authority associated to each of its MNOs.

[0040] As a result, the ACME Zero Touch ACME Architecture relies on, the ACME Server being configured with external account associated to each Issuer Vendor. Each of these Issuer Vendor that issued Vendor Certificate are associated a Vendor Token Authority. The ACME Server and the Vendors Token Authorities have some trusted relation. When an ACME Client is sending a request to issue a token, the Vendor Token Authority is able to indicate the ACME Client the corresponding MNO Token Authority. While in this section we only considered two TokenAuthorities (the Vendor Token Authority and the MNO Token Authority), the delegation mechanism would work for any number of Token Authorities. As a result, the ACME Client is able to find the final token authority that will issue the legitimate token. That token will contain the CSR and any other parameters necessary to the ACME Server to issue the certificate.

[0041] Figure 3 depicts the ACME Zero Touch RBS Architecture Overview. Section A provides a detailed description of the exchanges.1. The ACME Client creates an ACME account for a 3gpp profile. The ACME account is anonymous in the sense that it is not linked to an identity. In our case, we need to bind the ACME account to a Vendor. ACME provides a mechanism based on Pre-Shared Key (PSK), but this would not be feasible here as it relies on a ’’shared” key and likely requires some configuration both on the ACME Server and the ACME Client. We detail a procedure to enable the binding between the Vendor Certificate and the Vendor Account. The mechanism uses a proof of ownership of the Vendor private key, and selects the Vendor according to the elements provided by the Vendor Certificate. These include the Issuer Distinguish name as well as other potential other attributes. The described External Account Binding (EAB) enables to associate the ACME account to a Vendor Token Authority.2. The ACME Client is not configured and so does not know what certificate to request. More specifically it does not know which identifiers (such as the FQDN for example) is expected. This is quite unusual for ACME as the traditional procedure is that the ACME Client place an ’order’ for specific identifiers and the ACME Server provides challenges for each of these identifiers. To address this issue, we defined a new token type designated as ZTouchCSR. This token type is not associated any values. The ACME Client MAY provide some values but these will be interpreted as hints by the MNO Token Authority that will issue the token with the Zero Touch CSR and necessary parameters for the issuance of the certificate by the ACME Server.3. With an identifier of type ZTouchCSR, the ACME Server request a challenge of type tkauth-01 of tkauth-type ’ate’. This basically means that the identifier MUST be validated by a Token Authority. The ACME Server provides the Vendor Token Authority it is configured with.4.a. / 4.b The ACME Client contacts the Vendor Token Authority to request the token. The final token is expected to be something like token = ’’type” : ZTouchCSR, ”CSR”: ZTouch CSR Value, As the Vendor Token Authority is not expected to produce such a token, it responds the next Token Authority to contact is the MNO Token Authority. We define a mechanism based on JavaScript Object Notation (JSON) Web Token (JWT) to build a trusted chain between the Vendor Token Authority and the MNO Token Authority using jwt objects. Typically, an initial request is sent to the Vendor Token Authority (see 4. a), the Vendor Token Authority cryptographically binds its response to the initial request. Then (see 4.b) the ACME Client sends the initial response with the received responses to the next Token Authority. This is performed until the token is finally issued.5 The ACME Client POSTs the full chain of the initial request, the following responses and the final response that contains the token. This enables the ACME Server to validate the token can be trusted as the chain of responses starts with the Vendor Token Authority that acts like a Trust Authority.6 Once the ACME Server has received the Zero Touch CSR, there is no need for the ACME Client to upload the CSR again. However, this step is left optional so the state machine of ACME remains less impacted. The main advantage of doing so would be that the ’finalize’ resource provides a ’status’ claims that indicates when the certificate is effectively published. As result, an ACME Client may query the finalize URL to check the status. That advantage seems minor as the ACME Client will request the ’certificate’ URL instead. One downside is that the ACME Server will have to validate the CSR provided by the ACME Client at the ’finalize’ URL exactly match the CSR provided by the token.7 The ACME Client retrieves the certificate.A Exchanges for the RBS with Zero TouchA.1 Creation of the CA account

[0042] In the RBS with Delegated Token Authority, the ACME server is preconfigured to associate any Vendor certificate to a specific Vendor TA and this for any possible Vendor Certificate. A simple way to implement this is that Vendor register to these 3GPP specific CA a list of selectors to be considered in the Vendor Certificate and the corresponding TA. It is likely that any Distinguished Name of the Issuer will be bound to a Vendor TA. The CA will thus consider the following accounts:Vendor Issuer DN1Vendor Token Authority: https: / / vendorl-authority.example.org Trust Anchor (or Root CA): <DN or Key>Vendor Issuer DNnVendor Token Authority: https: / / vendorl-authority.example.org Trust Anchor (or Root CA): <DN or Key>

[0043] Note that Vendor Issuer DN is one example, and that additional element may be added for example the Public Key may also be considered in case a given vendor got multiple keys. In general we do not recommend binding to a specific key as the key is expected to change over time.

[0044] Note also that Each Vendor Issuer May be associated with a Trust Anchor or Root CA to validate the signatures generated with the private key that is associated to a Vendor Certificate associated to that Vendor Issuer.A.2 Creation of the ACME account

[0045] The creation of an ACME account differs from ACME in that:1. It relies on an External Account Binding (EAB) mechanism that is based on an asymmetric cryptography, that is a Vendor Certificate as opposed to a PSK. In general, PSK are not expected to be long term secrets and this is particularly true for 3GPP usage of PSK where it is used with Service Based Architecture (SB A) as a One Time Password (OTP). The main reason for not using PSK as a long term authentication credential is that PSK are shared. On the other hand, Vendor Certificate are long term authentication credentials with a private key that is not shared. The use of a long term authentication credential enables the authentication credential to be configured by the Vendor for the life time of the RBS as opposed to the MNO - which could only rely on shorter term authentication credentials.2. It relies on a proof of ownership of the authentication credential, e.g. in our case a private key, but unlike a PSK, a Vendor Certificate contains additional parameters that has been validated by the issuer of the Vendor Certificate. These parameters are typically Distinguished Name parameters (C, O, OU, ...) as well as any kind of certificate attributes.

[0046] ACME account is created in an anonymous way, that is not related to any identity, and ACME provides an External Account Binding based on the proof of possession of a Pre Shared Key (PSK). In general, the PSK is only known by the ACME server and the ACME Client, isdistributed by an out of band mechanism, and is used to ’’cryptographically” bind the ACME account to the CA account via an authentication mechanism.

[0047] In our case, we do not provide a PSK and a proof of ownership of the PSK to indicate the binding. Instead, the ACME Client indicates its willingness to bind its ACME account with the CA account by mentioning External Account Binding (EAB) and by providing a full certificate (x5c). How the ACME server binds the account is left to the implementation. If we really want to use a PSK, the ACME server could validate the ACME Client effectively owns the private key associated to the Vendor Certificate, and then generate a PSK from the Vendor Issuer DN and any additional parameters that are necessary to bind a given CA account.

[0048] Note also that the validation of the proof of possession by the ACME Server implies that the ACME Server is configured with a Trust Anchor that enable the validation of the full chain of the Vendor Certificate Chain. Once the ACME Server has been able to associate the ACME Client to a specific Vendor, the ACME Vendor creates an ACME account and an order resource.MNO / ACME Client CAPOST / acme / new- account HTTP / 1.1Host: ca.example.comContent-Type: application / jose+json{"protected": base64url({"alg":"ES256","jwk": / * account key * / ,"nonce": "K60BWPrMQG9SDxBDS_xtSw","url": "https: / / ca.example.com / acme / new-account""payload": base64url({"termsOfServiceAgreed": true,"externalAccou ntBinding": {"protected": base64urlC{ "alg":"ES256","kid": / * key identifier from CA * / ,"url":"https: / / example.com / acme / new- account" "x5c" : < the VendorCertificate chain >"payload": base64url( / * same as in "jwk" above * / )> "signature": / * Signature generated with the Vendor Private Key * / "signature": "5TWiqIYQfIDfALQv...x9C2mg8JGPxl5bI4"}HTTP / 1.1 201 CreatedContent-Type: application / json Replay-Nonce: D8s4D2mLs8Vn- goWuPQeKALink:<https: / / example.com / acme / directory>;rel="index" Location: http s: / / example.com / acme / acct / evO fKh NU 6Owg{"status": "valid","orders":"https: / / example.com / acme / acct / evOfKhNU60wg / order s"}A.3 Applying for Certificate Issuance

[0049] The ’new-order’ differs from the ACME in that it defines a new type of identifier that has no value.

[0050] In the standard ACME, the ACME clients places a ’new-order’ where it indicates the identifiers that are expected to be placed into the (future) issued certificate. In our case, the RBS has not been configured and as such is not aware of which certificate will be issued. In fact, the certificate will be determined by the MNO Token Authority. The ACME client indicates that it is expected to be configured by the MNO TA by requesting an identifier of type Zero Trust Certificate ’ZTouchCSR’ with an empty value.

[0051] Other parameters such as ’’notBefore” or ’’notAfter” are also omitted. This is compatible with conventional ACME as these are mentioned to be optional.MNO / ACME Client CAPOST / acme / new- order HTTP / 1.1Host: example.comContent-Type: application / jose+json{"protected": base64url({"alg":"ES256","kid":"https: / / example.com / acme / acct / evOfKhNU60w g", "nonce": "5XJlL31EkMG7tR6pA00clA","url": "https: / / example.com / acme / new-order""payload": base64url({"identifiers": [{"type":"ZTouchCSR", "value": "" }],"signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g"}>HTTP / 1.1 201 CreatedContent-Type: application / json Replay-Nonce:MYAuv0paoIiywTezizk5vwLocation: https: / / example.com / acme / order / 1234{"status": "pending","identifiers": [{"type":"ZTouchCSR","value" : "" }], "authorizations": ["https: / / example.com / acme / authz / 1234"L## if the ACME Server requires the CSR to be provided by ## the ACME Client"finalize":"https: / / example.com / acme / order / 1234 / finaliz e" ## if the ACME Server takes the CSR as theZero Touch CSR ## provided by the TokenAuthority"certificate": "https: / / example.com / acme / order / 1234 / fmalize"}A.4 Identifier Authorization

[0052] This phase is similar to the one described in RFC 9448, that is the ACME server provides a challenge that is based on a Token Authority ’tkauth-01’ that is validated by a Token Authority ( ’ate’ )MN0 / ACME Client CAPOST / acme / authz / 1234HTTP / 1.1 Host: example.comContent-Type: application / jose+json{"protected": base64url({"alg":"ES256","kid": " http s: / / example.com / acme / acct / evO fKh NU 6Owg", "nonce":"uQpSjlRb4vQVCjVYAyyUWg","url": "https: / / example.com / acme / authz / 1234""payload":"signature": "nuSDISbWG8mMgE7H...QyVUL68yzf3Zawps" }- HTTP / 1.1200 OKContent-Type: application / jsonLink: <https: / / example.com / acme / some-directory>;rel="index"{"status": "pending","expires": "2022-01-08T00:00:00Z","challenges": [{"type": "tkauth-01","tkauth-type": "ate","token-authority": "https: / / vendor- authority.example.org / path", "url":"https: / / example.com / acme / chall / prV_B7yEyA4",}]}A.5 Challenge Completion

[0053] In RFC 9447 and RFC 9448, the ACME Client requested an authorization for the identifiers specified in the order request. A first distinction is that the value of the identifiers is unknown and the ACME Client expects from the Token Authority a value in addition to an authorization. More concretely, the expected value is designated as the Zero Touch CSR.

[0054] Another significant difference is that the Vendor Token Authority is expected to be an intermediary Token Authority and that will be able to further indicate which final Token Authority needs to be contacted to get the final Zero Touch CSR value. There is a chain between the various Token Authority, and the way this chain is built here is by providing an initial request as a JSON Web Token (JWT) also designated as jwt-reqO. The associated response is also a jwt-respO. If theresponse does not contain the Zero Touch CSR, it indicates the next Token Authority to contact. Simply sending jwt-reqO to that new Token Authority could be sufficient, however, we also want the next Token Authority to validate that request has effectively been redirected by the previous Token Authority. In that sense the previous Token Authority are used to grant access to send a request. As a result, jwt-reqO and jwt-respO are sent together to the new Token Authority. This carry both the request and the path. The response from the new Token Authority is a response associated to jwt-reqO and jwt-respO. It can be final if the Zero Touch CSR is provided or indicate another Token Authority.

[0055] When a Zero Touch CSR is present, the ACME Client provides the initial request as well as all responses to the ACME Server that is [jwt-reqO, jwt-respO, ... jwt-respn],

[0056] The different JWT object contains some common claims such as ’iss’ to designate the issuer of the jwt. The issuer MUST match the signer of the JWT. The JWT also contains a JWT identifier ’j ti ’ as well as some time to define the validity of the JWT (’iat’ for the time the JWT is issued as well as ’exp’ the expiration time). The JWT are only expected to be valid for short period of time that is around the time to issue the certificate. It is recommended to set the time over a minute or an hour in case some clock drift.

[0057] In most cases, we expect the issuer of the JWT to match the DN or the SAN of the X509 certificate that designates the signer of the JWT. The current description considers X509 certificate to be sent explicitly, but it could also be envisioned that URL (’x5u’), footprint or any other means are provided to refer to the appropriated signing material.

[0058] The initial request jwt-reqO is represented below. The jwt-reqO is singed by the Vendor Certificate. It contains, the object of the request is provided in the ’ate’ claim as described in RFC 944. In our case, the only information is ’tktype’, the Type of the Token that needs to be issued / validated by the Token Authorities, ’tkvalue’ is an optional claim that MAY carry a CSR, or be empty. If a CSR is provided, it is only considered as a hint. Other parameters MAY also be added such as ’ca’: false but these are only potential hints as the Token Authority will overwrite these values. The request is bound to an ACME Account which is represented by the ’fingerprint’ . That field cannot be used or verified by any of the Token Authorities.MNO / ACME Client CAPOST / path HTTP / 1.1Host: vendorauthority. example.orgContent-Type: application / json[ jwt-reqO ]With jwt-reqO being the object represented below{"protected": base64url({"typ":"JWT", "alg":"ES256", "x5c": Vendor Certificate Chain } )."payload": base64url({ "iss" : vendor ceritificate DN, SAN "jti": "id6098364921", "iat":1300819360, "exp":1300819380, "ate" : {"tktype":"ZT ouchCSR", "tkvalue": , "ca":false,## fingerprint designates the ACME account "fingerprint":"SHA25656:3E:CF:AE:83:CA:4D:15:B0:29:FF:lB:71:D3:BA:B9:19:81:F8:50:9B:DF:4A:D4:39:72:E2:Bl:F0:B9:38:E3"} )."signature": "9cbg5J01Gf5YLjjz...SpkUfcdPai9uVYYQ"}

[0059] In our case, the Vendor Token Authority does not provide any token (TOKEN) that can be used to complete the challenge. Instead, the Vendor Token Authority indicates the next Token Authority to send the request to. We designate this Token Authority as the MNO Token Authority.

[0060] The response of the Vendor Authority is represented below. All responses follow the same format. The request is bound to the response via a hash function of the array of [jwt-reqO],For further response the array will be [ jwt-reqO, jwt-resO, ..., jwt- resp(n-l) ]. If the Token Authority is not able to provide a Zero Touch CSR, it indicates the next Token Authority to contact using the ’token-authority’ claim.- HTTP / 1.1200 OKContent-Type: application / json jwt-respOWith jwt-respO the JWT represented below{"protected": base64url({"typ":"JWT","alg":"ES256","x5c": Vendor Token Authority Certificate Chain"payload": base64url({"iss" : "vendor-authority.example.org", "token-authority": "https: / / mno- authority.example.org / path" "jti":"id6504578098","iat":1300819365,"exp":1300819380,"req" : SHA256( jwt-reqO )} )."signature": "9cbg5J01Gf5YLjjz...SpkUfcdPai9uVYYQ" }

[0061] The Response received from the Vendor Token Authority contains a ’’token-authority” claim that indicate a new exchange needs to be performed further down. The ACME Client sends a request that contains [ jwt-req, jwt-respO ]. Note that that in our case, the second Token Authority provides the authorization, but if additional Token Authorities were involved the ACME request to the n-th Token Authority would be [jwt-reqO, jwt-respO, jwt-respl, ..., jwt-resp(n-l) ].

[0062] The final Token Authority (in our case the MN0 Token Authority) reads the jwt-reqO and MAY validate the expected path in term of Token Authorities. Upon validation, the MN0 Token Authority responds with the expected Zero Touch CSR in a ’token’ claim as described below:- HTTP / 1.1200 OKContent-Type: application / json jwt-resplWith jwt-respl the JWT represented below:{"protected": base64url({"typ":"JWT","alg":"ES256","x5c": MNO Token Authority Certificate Chain } )."payload": base64url({"iss" : "mno- authority.example.org", "token-authority": """jti":"id6504578098","iat":1300819365"exp":1300819380,"req" : SHA256( [ jwt-reqO, jwt-respO ] )"token" : { "tktype":"ZTouchCSR","tkvalue":"F83n2a...avn27DN3==" },"signature": "9cbg5J01Gf5YLjjz...SpkUfcdPai9uVYYQ"}

[0063] Upon Receiving the Zero Touch CSR, The ACME Client POST the chain of jwt-reqO and jwt-resp.. to the Authorized URL as described below.POST / acme / chall / prV_B7yEyA4HTTP / 1.1 Host: boulder.example.comContent-Type: application / jose+json{"protected": base64url({"alg": "ES256","kid":"https: / / example.com / acme / acct / evOfKhNU60wg", "nonce": "Q_s3MWoqT05TrdkM2MTDcw","url": "https: / / boulder.example.eom / acme / authz / asdf / 0"} )."payload": base64url([ jwt-reqO, jwt-respO, jwt-resp (n-1)]),"signature": "9cbg5J01Gf5YLjjz...SpkUfcdPai9uVYYQ"}

[0064] To validate the challenge, the ACME Server checks that chain of jwt is validated by the Vendor Token Authority - that is singed by it as a chain of trust. This mostly consists in validating the challenge. As the Acme Server already knows the CSR, there are two possibilities:1. The ACME Server simply validates the challenge, which - at least in our case validates the order and let the ACME Client upload the CSR in the ’’finalize” URL. This situation is indicated by the presence of a CSR ’claim’. The main advantage of this solution is that2. Skip the CSR exchange and directly issue the certificate. In that case, the ’finalize’ claim SHOULD NOT be provided, and the CSR be automatically provisioned by the ACME Server. Only the ’certificate’ claim is present and the URL is provided. In this case, it is expected to respond after the certificate is issued.A.6 Certificate Issuance

[0065] In this section, we assume the ACME Server takes the Zero Touch CSR from the token issued by the Token Authority and issues the Certificate directly. This also means that the ACME Client has the ’certificate’ URL (See Section A.3).POST / acme / cert / mAt3xBGaobwHTTP / 1.1 Host: example.comContent-Type: application / jose+json Accept: application / pem-certificate- chain{"protected": base64url[{"alg":"ES256","kid":"https: / / example.com / acme / acct / evOfKhNU60wg", "nonce": "uQpSjlRb4vQVCjVYAyyUWg","url": "https: / / example.com / acme / cert / mAt3xBGaobw""payload":"signature": "nuSDISbWG8mMgE7H...QyVUL68yzf3Zawps"}HTTP / 1.1 200 OKContent-Type: application / pem-certificate-chainLink: <https: / / example.com / acme / directory>;rel="index"- BEGIN CERTIFICATE -[End-entity certificate contents]- END CERTIFICATE -- BEGIN CERTIFICATE -[Issuer certificate contents]- END CERTIFICATE -- BEGIN CERTIFICATE -[Other certificate contents]- END CERTIFICATE -Further Description

[0066] Figure 4 illustrates a procedure in accordance with one example embodiment of the embodiments described above. Note that not all details provided above are included in the following description of Figure 4; however, it is to be understood that the details above regarding each of the steps of Figure 4 are applicable.

[0067] As illustrated, the procedure of Figure 4 involves an ACME client 400 at an RBS 402, an ACME server 404, a Vendor TA 406, and an MNO TA 408. The steps of the procedure of Figure 4 are as follows:

[0068] Step 1 : The ACME client 400 (at the RBS 402) creates an ACME account for a 3 GPP profile. The ACME account is anonymous in the sense that it is not linked to an identity. As described above, the ACME account is bound to a Vendor, and a mechanism to enable this binding between the Vendor Certificate (at the RBS 402) and the Vendor Account are described above. This mechanism uses proof of ownership of the Vendor private key and selects the Vendor according to the elements provided by the Vendor Certificate (e.g., Issuer Distinguish name). As a result of this binding, the ACME account of the ACME client 400 is associated to the Vendor TA.

[0069] Step 2: The ACME client 400 sends, to the ACME server 404, a request to issue a token of a new token type (ZTouchCSR), as described above.

[0070] Step 3: The ACME server 404 returns, to the ACME client 400, a response that requests validation by a TA, where the response includes information about the vendor TA 406. The information about the vendor TA 406 includes, e.g., information that enables the ACME client 400 to send a request for the token to the vendor TA 406. Further details about the request of step 2 and the response of step 3 can be found above and are equally applicable here to Figure 4.

[0071] Step 4: The ACME client 400 sends, to the Vendor TA 406 (known from step 1), a request to issue the token of the token type ZTouchCSR, as described above.

[0072] Step 5: The Vendor TA 406 sends a response to the ACME client 400, where this response indicates the MNO TA 408 to be contacted by the ACME client 400.

[0073] Step 6: The ACME client 400 sends a request to the MNO TA 408, as described above. In one example embodiment, in step 2, the ACME client 400 sends an initial request to the Vendor TA 404, and the Vendor TA 404 cryptographically binds its response (sent in step 5) to the initial request. Then, in step 6, the ACME client 400 sends a request to the MNO TA 408, where this request includes the request of step 4 and the response of step 5.

[0074] Step 7: The MNO TA 408 sends a response to the ACME client 400 including the desired token.

[0075] Step 8: The ACME client 400 sends (e.g., POSTs) the full chain of the initial request (step 2), the response (step 3), the subsequent request (step 4), and the subsequent response (step 5) to the ACME server 404. Note that a JWT mechanism is described above as an example embodiment for how the requests and responses of steps 4, 5, 6, 7, and 8 are performed. That example is equally applicable here to the procedure of Figure 4.

[0076] Step 9: The ACME server 404 validates the token, as described above.

[0077] Figure 5 is a schematic block diagram of a network node 500 according to some embodiments of the present disclosure. Optional features are represented by dashed boxes. The network node 500 may be, for example, the RBS 400, a component of the RBS 400 hosting the ACME client 400, a network node at which the ACME server 404 is implemented, a network node at which the vendor TA 406 is implemented, or a network node at which the MNO TA 408 is implemented. As illustrated, the network node 500 includes a control system 502 that includes one or more processors 504 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and / or the like), memory 506, and a network interface 508. The one or more processors 504 are also referred to herein as processing circuitry. In addition, if the network node 500 is the RBS 402, the network node 500 may include one or more radio units 510 that each includes one or more transmitters 512 and one or more receivers 514 coupled to one or more antennas 516. The radio units 510 may be referred to or be part of radio interface circuitry. In some embodiments, the radio unit(s) 510 is external to the control system 502 and connected to the control system 502 via, e.g., a wired connection (e.g., an optical cable). However, in some other embodiments, the radio unit(s) 510 and potentially the antenna(s) 516 are integrated together with the control system 502. The one or more processors 504 operate to provide one or more functions of the network node 500 as described herein (e.g., one or more functions of the ACME client 400, ACME server 404, Vendor TA 406, or MNO TA 408, as described herein). In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory 506 and executed by the one or more processors 504.

[0078] Figure 6 is a schematic block diagram that illustrates a virtualized embodiment of the network node 500 according to some embodiments of the present disclosure. Again, optional features are represented by dashed boxes. As used herein, a “virtualized” network node is an implementation of the network node 500 in which at least a portion of the functionality of the network node 500 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, in this example, if the network node 500 is the RBS 402, the network node 500 may include the control system 502 and / or the one or more radio units 510, as described above. The control system 502 may be connected to the radio unit(s) 510 via, for example, an optical cable or the like. The network node 500 includes one or more processing nodes 600 coupled to or included as part of a network(s) 602. If present, the control system 502 or the radio unit(s) are connected to the processing node(s) 600 via the network 602. Each processing node 600 includes one or more processors 604 (e.g., CPUs, ASICs, FPGAs, and / or the like), memory 606, and a network interface 608.

[0079] In this example, functions 610 of the network node 500 described herein (e.g., one or more functions of the ACME client 400, ACME server 404, Vendor TA 406, or MNO TA 408, as described herein) are implemented at the one or more processing nodes 600 or distributed across the one or more processing nodes 600 and the control system 502 and / or the radio unit(s) 510 in any desired manner. In some particular embodiments, some or all of the functions 610 of the network node 500 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment s) hosted by the processing node(s) 600. As will be appreciated by one of ordinary skill in the art, additional signaling or communication between the processing node(s) 600 and the control system 502 is used in order to carry out at least some of the desired functions 610. Notably, in some embodiments, the control system 502 may not be included, in which case the radio unit(s) 510 communicate directly with the processing node(s) 600 via an appropriate network interface(s).

[0080] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the network node 500 or a node (e.g., a processing node 600) implementing one or more of the functions 610 of the network node 500 in a virtual environment according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

[0081] Figure 7 is a schematic block diagram of the network node 500 according to some other embodiments of the present disclosure. The network node 500 includes one or more modules 700, each of which is implemented in software. The module(s) 700 provides the functionality of the network node 500 described herein. This discussion is equally applicable to the processing node 600 of Figure 6 where the modules 700 may be implemented at one of the processing nodes 600 or distributed across multiple processing nodes 600 and / or distributed across the processing node(s) 600 and the control system 502.

[0082] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processor (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory suchas Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and / or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according to one or more embodiments of the present disclosure.

[0083] While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

Claims

CLAIMS1. A method performed by an Automatic Certificate Management Environment, ACME, client (400) at a radio base station (402), the method comprising any one or more of the following: sending (Fig. 4, step 2), to an ACME server (404), an initial request for a token of a certain token type; receiving (Fig. 4, step 3), from the ACME server (404), an initial response that indicates a vendor Token Authority, TA, (406); sending (Fig. 4, step 4) a first request for the token of the certain token type to the vendor TA (406); receiving (Fig. 4, step 5), from the vendor TA (406), a first response comprising information that indicates a second TA (408); and sending (Fig. 4, step 6) a second request for the token of the certain token type to the second TA (408).

2. The method of claim 1, wherein the vendor TA (406) is associated to a vendor of the radio base station (402).

3. The method of claim 1 or 2, wherein the certain token type is a token type that indicates a zero touch certificate signing request.

4. The method of any of claims 1 to 3, wherein the second TA (408) is a mobile network operator, MNO, TA (408).

5. The method of claim 4 further comprising receiving (Fig. 4, step 7) a second response from the MNO TA (408), the second response comprising the token.

6. The method of claim 5 further comprising sending (Fig. 4, step 8) a request to the ACME server (404), the request comprising the token.

7. The method of claim 6, wherein the request sent to the ACME server (404) further comprises the first request, the first response, the second request, and the second response.

8. The method of claim 6 or 7, wherein the ACME server (404) is a certificate authority,CA, selected by the MNO.

9. The method of claim 8, wherein the ACME server (404) is a CA configured for 3GPP certificate issuance.

10. The method of any of claims 6 to 9, further comprising, prior to sending (Fig. 4, step 2) the initial request, communicating with the ACME server (404) to create an ACME account and to thereby be associated with the vendor associated to the vendor TA (406).

11. The method of claim 7, wherein the first request, the first response, the second request, and the second response are sent / received using a JavaScript Object Notation, JSON, Web Token, JWT, mechanism that provides a trusted chain between the vendor TA (406) and the MNO TA (408).

12. A radio base station comprising an ACME client adapted to perform the method of any of claims 1 to 11.

13. A computer program comprising instructions which, when executed on at least one processor, cause the processor to carry out the method according to any of claims 1 to 11.

14. A carrier containing the computer program of claim 13, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.

15. A method performed by an Automatic Certificate Management Environment, ACME, server (404), the method comprising: receiving (Fig. 4, step 2), from an ACME client (400) at a radio base station (402), an initial request for a token of a certain token type; and sending (Fig. 4, step 3), to the ACME client (400), an initial response that indicates a vendor Token Authority, TA, (406).

16. The method of claim 15, wherein the vendor TA (406) is associated to a vendor of the radio base station (402).

17. The method of claim 15 or 16, wherein the certain token type is a token type thatindicates a zero touch certificate signing request.

18. The method of any of claims 15 to 17, wherein the second TA (408) is a mobile network operator, MNO, TA (408).

19. The method of claim 18, further comprising receiving (Fig. 4, step 8), from the ACME client (400), a request comprising the token.

20. The method of claim 19, wherein the request comprises a series of requests and responses between the ACME client (400) and two or more TAs comprising the vendor TA (408) and an MNO TA (408).

21. The method of any of claims 15 to 20, wherein the ACME server (404) is a certificate authority, CA, selected by the MNO.

22. The method of claim 21, wherein the ACME server (404) is a CA configured for 3GPP certificate issuance.

23. The method of any of claims 15 to 22, further comprising, prior to receiving (Fig. 4, step 2) the initial request, communicating with the ACME client (400) to create an ACME account and to thereby associate the ACME client (400) with the vendor associated to the vendor TA (406).

24. The method of claim 20, wherein the series of request and responses are sent / received using a JWT mechanism that provides a trusted chain between the vendor TA (406) and the MNO TA (408).

25. The method of claim 20 or 24, further comprising validating (Fig. 4, step 9) the token based on the series of requests and responses.

26. An ACME server or network node implementing an ACME server, adapted to perform the method of any of claims 15 to 25.

27. A computer program comprising instructions which, when executed on at least oneprocessor, cause the processor to carry out the method according to any of claims 15 to 25.

28. A carrier containing the computer program of claim 27, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.

Images