Enforce OAuth

[swthorn]

Hi,

I have modified all Network Functions to properly request and validate OAuth tokens from the NRF's authorization server. This will be part of a larger pull request to free5GC as there are a few repositories to which I need to make pull requests.

This pull request modifies the OpenAPI helper libraries that most NFs use. It correctly requests OAuth access tokens from the NRF and sends them along with all requests. This PR looks quite big because most files are changed, however, it is relatively easy to change the code as it's automatically generated and inserted by another program. Please let me know if you have any improvements you want me to make.

NRF Pull Request: free5gc/nrf#8
NSSF Pull Request: free5gc/nssf#5

When these three PR's are merged, I will create other pull requests for the rest of the Network Functions. Please let me know if you have further questions.

Thanks!

[tim-ywliu]

@swthorn

This PR will cause requesting OAuth access token too frequently. Once getting the access token, it can be reused for the service next time.

[swthorn]

@tim-ywliu

Yes, I agree. This implementation has a trade-off between performance and security by adding in OAuth. For these reasons, I add a configuration option to control OAuth enforcement in each NF PR. e.g: https://github.com/free5gc/nssf/blob/b6db32363b421143bab86102a79673ae6a507b27/internal/context/context.go#L55

I agree that there should be a more sophisticated caching approach, but as an initial implementation of OAuth, let me know your thoughts on the current code.

[swthorn]

Hi,

I have a couple of quick notes on the merge conflicts on this PR.

openapi/oauth.go

Line 88 in 3ddfaaf

return strings.Contains(scope, serviceName)

I think this is not sophisticated enough to verify scope. It may allow for subtle attacks you're not expecting. I believe my function here: https://github.com/swthorn/openapi-1/blob/f8fa664f62b7d84bd17dfe7759ae3e5ca01f9694/oauth.go#L54 does a better job at verifying scopes in the JWT.

Secondly,

openapi/oauth.go

Line 71 in 3ddfaaf

token, err := jwt.ParseWithClaims(

does not verify the algorithm in the JWT. The JWT library states this is a security flaw here. Here's a writeup on how to perform an attack: https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/

Finally, I see the TLS certificates are re-generated in the code base (for each run?). Just clarifying that this is intended behavior? Is this a realistic expectation in a deployed telco core?

[tim-ywliu]

@swthorn

Thanks for your report and we'll check the scope & JWT verification.

About certificates generation, the design is that NRF will generate root cert/key if they are not available and all NFs will generate its own cert/key if they are not available.
So, you can also pre-generate the cert/key and NRF/NF will directly use them from the path defined in config.

PS: root cert & NF's certs should be put in the same folder. Keys can be put in different path which only NF can access by itself.

[swthorn]

Hi, just following up on this. Is there something I can do to speed up the review process? Is the hold-up because of the performance trade-off for not caching access tokens?

[swthorn]

Any updates on the status of this PR?

[tim-ywliu]

Sorry, currently we are busy new releasing, so it will be pending util the new release done.

[swthorn]

Hi,

I noticed you guys merged PRs in other NFs but have not updated this yet. I'm sure you know that you will need to update this repo too. Please let me know how I can assist in this process.

Specifically, now that the underlying OAuth method in the NFs has changed significantly since when I made initial PRs (I haven't reviewed the changes you decided to make), how do you want me to adapt the automated instrumentation of the APIs in this repository? It is trivial for me, and a lot of work for you to do manually.

Thanks!

[tim-ywliu]

@swthorn

We use #19 instead and will close this PR, thanks.