-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TS 26.512: Signalling of domainNameAliases during server certificate creation #64
Comments
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.) |
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? |
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. |
CR contributed to SA4#124 (Berlin):
|
CR Pack SP-230546 including TS 26.512 CR0033r5 (Rel-17) and CR0035 (Rel-16) approved at SA#100 (Taipei). |
📣 3GPP TS 26.512 V16.10.0 and V17.5.0 are now published: |
Updated APIs now published: |
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 thedomainNameAlias
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
domainNameAlias
es 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 thedomainNameAlias
es 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 relevantdomainNameAlias
es 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 thecreateServerCertificate
operation request. This could be either done as additional URL query parameters (to go alongside thecsr
flag) or by providing the values in the body of the POST request.The
domainNameAlias
values are then added asDNS:...
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:
domainNameAliases
, for example:.example.com
) that has been previously verified by the Application Function operator as allowed by that Application Provider.domainNameAlias
value it requests (e.g. addition of a TXT record).domainNameAlias
es 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
domainNameAlias
es 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:
domainNameAlias
es.domainNameAlias
values as further SubjectAltName entries and signs the CSR.domainNameAlias
entries at the AS canonical domain name (which will be the CommonName used in the CSR subject DN).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.The text was updated successfully, but these errors were encountered: