5GMAG-OpenCAPIF integration

[aaronmontilla]

This thread discusses the possibilities regarding the integration of 5G Media Streaming with the CAPIF authentication method.
In the call, Richard stated that the specs define CAPIF as an option for authentication method in Rel.18. However, the 5G Media Streaming implementation is Rel. 17 compliant.
One option will be to integrate CAPIF with the already existing Rel. 18 compliant services. Anyway, the integration of CAPIF is not mandatory even on Release 18.
Do you think it is interesting to perform this integration? If so, which steps do you think are the best to proceed?

[rjb1000]

Regarding the UE data collection, reporting and event exposure reference implementation, I had a look at TS 26.532 Rel-18 and the YAML APIs lack any security specification suitable for OAuth 2.0 and CAPIF. So this was a dead end, unfortunately.

[rjb1000]

Regarding the 5G Media Streaming reference implementation, it is currently compliant with TS 26.512 Rel-17, and again the YAML APIs lack any security specification suitable for OAuth 2.0 and CAPIF.

For Rel-18, authorisation is formally brought into scope at reference points M1, M3 and M5. The API specification has moved to TS 26.510 and should have everything needed to support OAuth 2.0 and CAPIF at these reference points.

The most interesting reference point from a security perspective is probably M1, but the others are potentially interesting too. And, once one reference point supports OAuth 2.0 and CAPIF, I reckon it would be pretty easy to extend support to all three.

[rjb1000]

The task to integrate with CAPIF would therefore involve implementing the Rel-18 APIs specifically in the 5GMS AF at the reference point(s) of interest. M1 would be the obvious place to start. There are a few approaches that could be taken:

• Compile-time choice. Allow the user to build a 5GMS AF binary that supports either the Rel-17 or Rel-18 API in question.
• Run-time choice. Build a 5GMS AF binary that supports both Rel-17 and Rel-18 APIs, and allow a configuration option to activate one or both of these. Trying to auto-detect which version of the protocol is wanted by an invoker sounds a bit too tricky to implement; a simpler solution would be to bind the two versions of the API to different listening ports.

[rjb1000]

Most of the code to support the Rel-18 API is autogenerated from the YAML, which immediately reduces the labour required, I expect.

• There are some small differences in the individual flags and cardinalities that would impact internal data structures used to store the provisioning state created at reference point M1.
  • This will need some careful attention to create a set of unified structures internally that can be provisioned using either the old API or the new one.
• There have also been some changes to the names of YAML data structures between releases, but these names don't appear on the wire, so the only impact is on the names of the autogenerated classes..
  • New names might actually work in our favour by reducing the chance of having two internal data structures with the same name.
• That just leaves the business logic in the 5GMS AF (e.g. cache expiry, garbage collection, etc.), which doesn't really change in Rel-18, I think.

[rjb1000]

Overall, I suspect that uplifting reference point M1 to Rel-18 isn't a massive task, but is one that requires a careful paper-based analysis beforehand, placing TS 26.512 Rel-17 side-by-side with TS 26.510 Rel-18 to spot the differences and then decide what to do about each one.

[rjb1000]

Speaking to @davidjwbbc about this, we concluded that the best Rel-18 uplift path for the 5GMSd AF would be to work towards a new major release v2.0.0 that is compiled against the Rel-18 YAML APIs at reference points M1d, M5d and M3d. If you want the Rel-18 provisioning, media session handling and configuration APIs, you would compile this; if you want the (legacy) Rel-17 APIs, you would compile the v1 code instead.

To reduce the development work required, the v2.0.0 5GMSd AF would stick with the current Rel-17 integration into the PCF because Open5GS only implements the Rel-17 API at reference point N5. This avoids having to touch the PCF service consumer library.

As a consequence, certain new Rel-18 features of the PCF would not be supported, but we don't think this is a major problem for the Rel-18 5GMSd AF. We haven't done a gap analysis, but the list of new Rel-18 PCF features exploited by the Rel-18 5GMSd AF could actually be an empty list.

[rjb1000]

Do you think it is interesting to perform this integration?

Part of 5G-MAG's remit is to implement unimplemented 3GPP specifications, so I think that is part of the justification argument.

Another factor is that CAPIF is a generic mechanism for API exposure that can, in principle, be applied to any API in the 5G System that defines security based on OAuth 2.0. So, while we might look at the 5GMS AF as an initial example API exposing function, since CAPIF is squarely in scope for TS 26.501 in Rel-18, any reference implementation you do of the CAPIF core function would clearly be much more broadly applicable to other features of the 5G System beyond the 5GMS System.

However, as I mentioned on the call last week, just because CAPIF allows you to expose APIs doesn't mean that it is operationally sensible to do this, so I am interested to learn what the concrete use case you have in mind. For example:

1. Exposing the 5GMS AF provisioning API securely at reference point M1 to a third-party 5GMS Application Provider located either inside or outside the PLMN trust domain is well defined.
   • See TS 26.501 Rel-18 clause 4.11.2.1 and TS 26.512 Rel-18 clause 6.6.2 (which points at TS 26.510 Rel-18 clause 7.4.2).
   • Procedures in TS 26.501 Rel-18 clauses 5.3.3 and 6.2.2.3.
2. Exposing the 5GMS AS configuration API securely at reference point M3 to a third-party 5GMS AF located either inside or outside the PLMN trust domain is also well defined.
   • See TS 26.501 Rel-18 clause 4.11.2.2 and TS 26.512 Rel-18 clause 6.6.3.
   • Procedures in TS 26.501 Rel-18 clauses 5.4.2 and 6.2.2.3.
3. Exposing the 5GMS AF media session handling API securely at reference point M5 to the Media Session Handler in the 5GMS Client is also well defined.
   • See TS 26.501 Rel-18 clause 4.11.2.3 and TS 26.512 Rel-18 clause 6.6.4 (which points at TS 26.510 Rel-18 clause 7.4.3).
   • Procedures in TS 26.501 Rel-18 clauses 5.2.5 and 6.3.3.
4. Exposing APIs of specific 5G Core Network Functions outside the PLMN trust domain seems a bit mad from a security point of view.
   • TS 23.502 and TS 23.503 define a very specific subset of APIs that are exposed by the 5G Core via a special Network Function called the Network Exposure Function (NEF), so this would be a more natural way of achieving this goal.
   • The CAMARA Project is defining higher-level APIs (more abstracted from just mobile networks) for exposure of common network capabilities to external parties.

The other practical question to ask yourself is this: If a given API is defined in the normative OpenAPI YAML to use plain OAuth 2.0, what additional value is CAPIF adding on top of that? In practice, plain old OAuth 2.0 mechanisms do all the heavy lifting. So what extra does CAPIF bring to the party?

@tlohmar and @ibouazizi may have additional views to add on this topic.

[aaronmontilla]

What I had in mind covers the first three points that you mentioned in the last message, but again, I wanted to ask for your opinion on this to reformulate the scope of the project. Regarding what CAPIF is adding I think it will be the simplicity in the discovery and publishment of the different APIs from the provider and the invoker sides.

[dsilhavy]

The question on uplifting the Rel.17 implementation to Rel.18 relates to this discussion thread: https://github.com/orgs/5G-MAG/discussions/111