TS 26.512: Signalling of domainNameAliases during server certificate creation

[davidjwbbc]

Description

TS 26.512 clauses 4.3.6.2 and 7.3 describe Server Certificate creation for a Provisioning Session. In the current versions of TS 26.512 this creation request does not take any additional information from the Application Provider and only produces a server certificate and key pair, or a certificate signing request and key pair, based on the canonical domain name of an Application Server assigned to the Provisioning Session.

TS 26.512 clauses 4.3.3.2 and 7.6 allow the Application Server, that is allocated to Provisioning Session by the Application Function, to be referred to using one or more domainNameAlias FQDNs. Therefore when used in conjunction with a Server Certificate, the signed certificate must include the domainNameAlias value(s) in the list DNS entries in the subjectAltName extension entry of the certificate.

If a CSR is requested by the Application Provider when creating a Server Certificate, and the Application Provider has control over the certificate generation then it is possible for the Application Provider to insert the domainNameAliases during the public certificate creation and signing. However if the Application Provider is using a 3rd party signing server (e.g. ACME server) then the signing is done externally and the CSR will need to provide the domainNameAliases as SubjectAltName entries in the CSR. A CSR is signed by the private key that corresponds to the public key provided in the CSR, this means that a CSR cannot be altered by any entity that does not have access to the private key. Only the Application Function has access to the private key, not the Application Provider, thus preventing the Application Provider from adding the relevant domainNameAliases to the CSR before forwarding it onto a 3rd party signing service, and thus preventing a suitable Server Certificate from being generated.

Suggested solution

The Application Provider supplies a list of domainNameAlias values that it will use with a given certificate during the createServerCertificate operation request. This could be either done as additional URL query parameters (to go alongside the csr flag) or by providing the values in the body of the POST request.

The domainNameAlias values are then added as DNS:... entries in the list of SubjectAltNames for the certificate/CSR.

Behaviour when a CSR is not requested

There are security issues with blindly signing a certificate for any domainNameAlias requested by an Application Provider, so care needs to be taken when the Application Function is providing the certificate signing service.

One or more of the following could be implemented:

1. An authentication mechanism would need to be added to ensure that the Application Provider is allowed to request certificates for the given domainNameAliases, for example:
   • Pre-agreed domain name suffix is used (e.g. .example.com) that has been previously verified by the Application Function operator as allowed by that Application Provider.
   • Addition of a challenge/response authentication mechanism to test that the Application Provider has control of the DNS entry for each domainNameAlias value it requests (e.g. addition of a TXT record).
2. Use of supplementary domainNameAliases is prohibited when a CSR is not requested.

Behaviour when a CSR is requested

It is up to the Application Provider to authenticate it has control over the domainNameAliases it requests with the signing service it uses. However it will also need to authenticate the Canonical Domain Name for the Application Server that the Application Function has allocated or omission of the Canonical Domain Name from the CSR.

The certificate signing service (e.g. ACME server) used by the Application Provider may use an HTTP based challenge response mechanism in order to verify that the certificate request has come from an entity that has control over the domain names requested. This requires the Application Provider to be able to push content to the Application Server to be served via HTTP at certificate creation time.

The sequence would look like:

1. AP asks the AF to create a certificate for the Provisioning Session including domainNameAliases.
2. AF allocates an AS and starts it up with an HTTP service running.
3. AF generates a CSR with the AS canonical domain name as the CommonName and first SubjectAltName entry, and adds the supplementary domainNameAlias values as further SubjectAltName entries and signs the CSR.
4. The AF passes the new CSR back to the AP.
5. AP updates its DNS to point domainNameAlias entries at the AS canonical domain name (which will be the CommonName used in the CSR subject DN).
6. AP forwards the CSR to its 3rd party signing service.
7. Signing service issues a challenge/response request for each FQDN listed in the CSR to the AP.
8. AP pushes challenge/response objects to the AS (this may require the ability to push to a shared "well-known" path on the AS, rather than the allocated Provisioning Session path).
9. Signing service polls the AS for the challenge responses to authenticate the FQDNs.
10. Once all challenges are met successfully the signing service generates a public certificate from the CSR and returns it to the AP.
11. The AP stores the public certificate with the AF using the uploadServerCertificate operation.

Therefore, for this to work, the AS must be capable of accepting push content from any AP to a "well-known" path in the AS HTTP hosting (not required for HTTPS as authentication is done before a certificate is available). The "well-known" path may be used by multiple APs at the same time so the AS must police the push requests to ensure that one AP is not overwriting another APs "well-known" entry. The push mechanism can be the same as the already defined push model for the interface at reference point M2, however since this operation is happening before the ContentHostingConfiguration response and thus the M2 base URL is not yet known by the AP, a suitable "well-known" M2 base URL will need to be signalled with the createServerCertificate response or discoverable by some other means available to the AP in order to obtain the correct URL path to push content to.

[rjb1000]

Behaviour when a CSR is not requested

...
2. Use of supplementary domainNameAliases is prohibited when a CSR is not requested.

The above is already effectively a restriction imposed by the current specification, so I propose simply adding a clarification to that effect at clause 4.3.6.2. (Changing this design is likely beyond the scope of an essential correction to a frozen release, but could potentially be considered for the next release under a new issue.)

[rjb1000]

Behaviour when a CSR is requested

1. AP asks the AF to create a certificate for the Provisioning Session including domainNameAliases.
2. AP pushes challenge/response objects to the AS (this may require the ability to push to a shared "well-known" path on the AS, rather than the allocated Provisioning Session path).
3. Signing service polls the AS for the challenge responses to authenticate the FQDNs.

The above look like the changes needed to support this fully.

I believe that adding step 1 can be achieved at SA4#124, but steps 8 and 9 are far more complex and probably can't be achieved until a later meeting.

So, the question is whether to add step 1 now and the rest later, in the knowledge that it's not completely fixed, but is at least less broken. Or should this be an "all or nothing" change where it is left in its broken state until a full solution can be specified?

While step 1 could easily be justified as a simple and essential change within the scope of Rel-16/Rel-17, the complexity of steps 8 and 9 might push this into Rel-18 scope, leaving the domain name alias feature permanently broken in Rel-16 and Rel-17 if we decide on the "all or nothing" approach.

Thoughts, @davidjwbbc?

[davidjwbbc]

Step 1 is required for the CSR to be correct from the AF, so I agree with your assessment above.

Steps 8 & 9 require the AS to provide a push service for a common area which is exposed at the root of the paths served at M4 (with care taken by the AS to ensure no AP abuses this area). Step 9 can just re-use the M4 interface as long as it is Internet facing as well as UE facing. Again I think your assessment is correct in that this will require substantially more work to specify and is probably a new feature for Rel-18.

[rjb1000]

CR contributed to SA4#124 (Berlin):

• TS 26.512 CR0033r3 "[5GMS3] Rel-17 corrections" in S4-230771

[rjb1000]

CRs agreed during SA4#124 (Berlin):

• TS 26.512 CR0033r5 "[5GMS3, TEI17] Rel-17 corrections" in S4-230968
• TS 26.512 CR0035 "[5GMS3] Rel-16 corrections" in S4-230976

[rjb1000]

CR Pack SP-230546 including TS 26.512 CR0033r5 (Rel-17) and CR0035 (Rel-16) approved at SA#100 (Taipei).

[rjb1000]

📣 3GPP TS 26.512 V16.10.0 and V17.5.0 are now published:

• https://www.3gpp.org/ftp/Specs/archive/26_series/26.512/26512-ga0.zip
• https://www.3gpp.org/ftp/Specs/archive/26_series/26.512/26512-h50.zip

[rjb1000]

Updated APIs now published:

• https://forge.3gpp.org/rep/all/5G_APIs/-/tree/TSG100-Rel16
• https://forge.3gpp.org/rep/all/5G_APIs/-/tree/TSG100-Rel17