Re: [lamps] Including 3GPP NF Type in HTTPS certificates

[Ryan Sleevi <[e-mail]>]

On Wed, Apr 27, 2022 at 10:20 AM John Mattsson <john.mattsson=
[e-mail]> wrote:

> Hi,
>
>
>
> The signaling in 5G (Service Based Architecture) uses HTTP/2 over
> mutually authenticated TLS 1.3. 3GPP has specified a X.509 certificate
> profile in section 6.1.3c of TS 33.310. The profile states that the NF Type
> (e.g., "NRF", "5G_EIR", "UDM", etc.) should be included as a DNS-ID in
> client certificates. I don't think this is appropriate in general. It also
> violates RFC 5280 as several of the NF Types contain an underscore "_"
> character.
>
>
>
>
> https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=2293
>
>
>
> I think 3GPP needs to update their specification.
>
Agreed. 5280 is clear this is a hostname in preferred name syntax, not an
arbitrary DNS label. That said, it seems that 6.1.3c.3 makes normative
reference to NFProfile/NFService encoding rules for NF to FQDN, is it
possible that there’s a translation function for ensuring that the FQDN is
in preferred name syntax of host names?

What would be a recommended way to include the 3GPP NF Type strings in
> X.509 certificates?
>
>
>
> - Should 3GPP/ETSI register a NF type type-id OID for use with otherName
> that takes a utf8String as value?
>
- Should 3GPP/ETSI register a registeredID OID for each NF Type?
>

No, to both of these, not unless you’re saying the NF type id is a fully
qualified and unambiguous name. That is, SAN 1 (the NF type) should not be
presumed to scope or restrict SAN 2 (the hostname)

Setting that important/critical bit aside, it’s also a recipe for interop
pain to go that route.

- Any other recommended way to include the NF type in the 3GPP certificates?
>
If the NF type is a scoping or restriction of the certificate, then simply
assigning an extension to indicate the appropriate NF type(s) is the way
consistent with RFC 5280 and X.509.

It does not need to be an attribute for a name field (like Subject or SAN),
even if it is seen as a narrowing in scope, since most of the core 5280
extensions (such as KU, EKU, and basicConstraints) already exist to more
narrowly scope the use of a certificate.

If the goal is to have the NF type part of the validated data processed by
a client, and have that be meaningfully useful for a 5280 client, then the
main mechanisms are either assigning a per-NF EKU (to restrict a given
certificate to a particular NF “protocol”/“use case”) or to use the
certificatePolicies. The former is more widely practiced and supported, but
canonically “non-standard” (for reasons), while the latter is more
consistent with the model envisaged by X.500.

In both cases, the client supplies an expected keyPurpose/certificatePolicy
as an input to the verification function, and on output receives whether or
not the certificate (and chain) was authorized for that purpose/policy.

If the NF identity is purely advisory, and not meant to be checked by
clients, then it’s somewhat silly to include in the certificate to begin
with, but any extension will work for that.

Things not to do would be what you’ve highlighted (smuggling it into host
name), using policyQualifiers (which formally don’t serve as standard
restrictions), or using arbitrary SAN types (which generally prove more
hassle than value).