Bulk authorization for Nodes

[andrewbonney]

Simon recently brought up the issue that the user interaction in the auth code flow (for initial authorization) means that deployments of large numbers of Nodes could be very involved.

Auth servers support various mechanisms to automate client registration, but the only method to deal with this for the token flows is to use the client credentials flow. At present we don't permit this, and I believe we've discussed its use at length previously.

Adding client credentials support is relatively straightforward from a spec perspective, but it's quite a significant change. It would also place a much greater importance on authentication/authorization steps during the client registration process, which we don't currently mandate. Further to this, given that client credentials may be more dangerous if leaked, it may be worth considering things like mutual TLS in order to bind credentials to a given key pair (see https://tools.ietf.org/html/rfc8705#section-2).

This needs further discussion.

[andrewbonney]

The alternative to client credentials may be https://tools.ietf.org/html/rfc8628, but this requires a mechanism for the client to signal a code and URI to the user. The user could then use a tool to iterate over these codes and URIs from a number of clients. This also requires the Authorization Server to be modern enough to support this RFC.

[prince-chrismc]

this requires a mechanism for the client to signal a code and URI to the user

How does the user gather all the device code URLs? The device code flow only provides a mechanism for physical display but not "notifying a central authority". Users would still be force to inspect each device manually.

[andrewbonney]

How does the user gather all the device code URLs? The device code flow only provides a mechanism for physical display but not "notifying a central authority". Users would still be force to inspect each device manually.

Agreed. This would most likely require something new to be defined.

[andrewbonney]

Danny has also highlighted a (potential third?) option. The recent token exchange RFC (https://tools.ietf.org/html/rfc8693#section-2.3) could allow a Node (for example) to be passed a temporary token by a user (to an HTTP endpoint we'd have to define), which it could then exchange with the Auth server for a token it could then use. I'd have to read further into how you'd accurately scope these tokens. Again, this is quite new so may not be widely supported.

[lo-simon]

this requires a mechanism for the client to signal a code and URI to the user

How does the user gather all the device code URLs? The device code flow only provides a mechanism for physical display but not "notifying a central authority". Users would still be force to inspect each device manually.

That will similar to what you are doing with Authorization Code Flow, you must already be somehow doing a callback to an interface which support browsing (i.e. central authority) to kick start the flow. Using Device Code Flow, that could break up the authorization flow and alllowing the central authority gather all the callbacks in a list and somehow issue the bulk request, or at least given the central authority to authorize all the devices in its own manner.

[prince-chrismc]

allowing the central authority gather all the callbacks

How does this work? How does each device producing a URL get gathered in the central authority?

I think this is something that lacking in OAuth2 that we are trying to gain. The closest example is the Google Home app which scans the WiFi and Bluetooth for available devices... But I still need to navigate in the app to each one for me to authorize them.

[prince-chrismc]

Is dynamic client registration the solution?

From example, as an auth server, I obtain a request on /register, I know it requires access to only registration scope. I have been configured to provide those clients with a particular private claim. I have been purposely built to keep track of new client which have not been granted access. I have a UI to allow review of these and a multi select, when confirmed each redirect _uri when receive a new code to begin requesting tokens.

The question I've been wondering, is this an auth server specific implementation detail? is it reasonable for us to spec a mechanism for this? if we spec something does it not force a non-standard auth server?

[prince-chrismc]

https://tools.ietf.org/html/rfc7523

This specification profiles the OAuth Assertion Framework [RFC7521] to define an extension grant type that uses a JWT Bearer Token to request an OAuth 2.0 access token as well as for use as client credentials.

This document defines how a JWT Bearer Token can be used to request an access token when a client wishes to utilize an existing trust relationship, expressed through the semantics of the JWT, without a direct user-approval step at the authorization server.

[garethsb]

I have been purposely built to keep track of new client which have not been granted access. I have a UI to allow review of these and a multi select, when confirmed each redirect _uri when receive a new code to begin requesting tokens.

That was what I was thinking could be possible, but it would be good to demonstrate that there are existing auth servers already supporting that pattern or that suport an API on which such functionality could be built. @simonlo-sony also pointed out to me that the client may expect to use the STATE parameter (although IS-10 spec currently only mentions and recommends this for Token Requests not Client Registration) and reject requests to its Redirect URI that have taken too long, so we'd need to offer guidance around that at least?

[prince-chrismc]

I found no mention of a state parameter in RFC 7591 for the client registration 🤔 Could you guys share where you saw that for client registration?

reject requests to its Redirect URI that have taken too long, so we'd need to offer guidance around that at least?

Might be worth seeing if this is in an RFC anywhere, I think it's a new issue however

[garethsb]

OK, I must have got the wrong end of the stick!! Sorry, @simonlo-sony...
RFC 7591 client registration is completed by the HTTP response, either 201 or 4xx, not by a callback. So, I understand @prince-chrismc suggestion to be that the Auth Server would accept the client registration (201 Created), but allow a user to registered but unapproved clients, and prohibit responses to token requests from unapproved clients?

[andrewbonney]

I believe the Keycloak implementation supports this form of approval by leaving clients in a disabled state once registered. Their UI does not make bulk approvals straightforward however, not least given that the display only shows the client ID rather than a more useful name. It may well be possible to deal with this via API but I haven't tried that yet.

[lo-simon]

This was my thought on how to perform bulk authorization, if and only if authorization server allow bulk request on step 5.

[prince-chrismc]

https://tools.ietf.org/html/rfc8628

verification_uri
REQUIRED. The end-user verification URI on the authorization server. The URI should be short and easy to remember as end users will be asked to manually type it into their user agent.

https://tools.ietf.org/html/rfc8628#section-3.3

After receiving a successful authorization response, the client
displays or otherwise communicates the "user_code" and the
"verification_uri" to the end user and instructs them to visit the
URI in a user agent on a secondary device (for example, in a browser
on their mobile phone) and enter the user code.

        +-----------------------------------------------+
        |                                               |
        |  Using a browser on another device, visit:    |
        |  https://example.com/device                   |
        |                                               |
        |  And enter the code:                          |
        |  WDJB-MJHT                                    |
        |                                               |
        +-----------------------------------------------+

How do we spec 3? The callback to the broadcast controller would need to be configured in all the clients?

[lo-simon]

My idea on step 3, client can foward the verification_uri and user_code to user defined endpoint on the broadcast controller, which is up to your own implementation. And yes the callback would have to be configured on each client.

ps. diagram has been updated on step 3, using user_code instead of device_code

[prince-chrismc]

client can foward the verification_uri and user_code to user defined endpoint on the broadcast controller, which is up to your own implementation. And yes the callback would have to be configured on each client.

If this configuration is acceptable, RFC 7523 allows us to start with an Authorization header to obtain the initial tokens, simply skipping the callback procedure. (avoiding extra work on adding a new flow)

I wonder if the "general access pass" could be a security vulnerability if it was shared in the System API global resource for instance. MUST it be configure by a human in order to ensure only permitted device are allowed?

Are broadcasters willing to accept installation time configuration for the environment/to enable this feature? Or does this defeat the purpose of the bulk?

[peterbrightwell]

Examined on call. @jonathanthorpe-sony to review options and propose way forward

[peterbrightwell]

Feeling on today's call is that this may need to wait for v1.1

[garethsb]

👍 Hopefully the group can document its feeling on workaround in v1.0, and goal for how devices/clients that only support v1.0 will work in the future with clients/devices that support bulk auth as per a v1.1.

[jonathan-r-thorpe]

@simonlo-sony and I have been thinking about this over the last week.

The three strategies highlighted by @andrewbonney were:

• RFC 8705 - Mutual-TLS Client Authentication
• RFC 8628 - Device Authorization Grant
• RFC 8693 - Token Exchange

In Simon and my discussion we revisited and rejected the Device Authorization Grant. As is covered in the discussion above, although the gathering of device codes could be automated, we don't know of a way that an authorization server could bulk authenticate those codes.

The Token Exchange method is still under study, but is unlikely to be well supported by legacy Authorization Servers due to it being quite new (as Andrew pointed out above).

The Mutual-TLS Client Authentication will certainly work in this situation as it requires no user interaction. It exchanges a client certificate for a token with no requirement for user credentials. Although promising, as mentioned by Andrew above, this might require some fundamental changes as it would require servers and clients to have digital certificates.

When considering Mutual-TLS we observed that it seemed functionally equivalent to the Client Credential Grant - in one a client certificate is exchanged for a token, in the other the client secret and id are exchanged for a token.

This led on to examining why Client Credential Grant hasn't been preferred for devices with no user interface. In the NMOS Authorization Overview there is reference to the Client Credential Grant being deprecated by the IETF.

However, I'm struggling to see in the IETF Best Common Practices where they explicitly deprecate the use of this grant. I can only find some warnings in section 4.14.

Can anyone help me understand why the Client Credential Grant has been discounted? As using this grant type would potentially solve both the problems of bulk authorization and authorization of devices with no UI.

[dannymeloy]

Hi @jonathanthorpe-sony. I've copied some thoughts below regarding some rationale for different flows in various NMOS workflows. It's a bit of a brain dump so apologies in advance.

Client Authentication vs User Authentication:

• Client authentication occurs with confidential clients as they have client secrets. Public clients don't get secrets so they can't authenticate (unless perhaps we make use of the vendor client side certs as mentioned in James's EST work, which might allow us to use Mutual TLS for client auth.) There's also the possibility of using JWT's for client auth that's also enshrined in RFC's somewhere.
• User authentication involves a user performing auth of some kind (password, 2FA, app confirmation, etc.)

The Client Credentials flow doesn't provide user authentication, only client auth, whilst redirection flows such as the Auth Code flow provides user authentication and client auth depending on if the client is public or not.

Use Cases
So client credentials only ever confirms the client, not the user, so its always proposed as a machine-to-machine solution. If a Node is validated via the use of client credentials, then the question is whether the user needs to be validated in order to perform the given action (IS-04 registration, IS-05 connection management.)

• IS-05 - This is hopefully straight forward. Yes the user needs authorization as a user is performing the action and the user logs into the BC using the Auth Code Flow.
• IS-04 - this is a bit trickier. By suggesting we do everything using client credentials, you're effectively saying that all nodes can register with a Registry (assuming aud and iss claims match up) - so anyone can bring up a node and it will be able to register with a registry if its registered with the auth server. Which leads onto..

Client Registration and Verification
We currently don't safeguard against any Node that can establish a valid HTTPS connection from registering dynamically with an Auth Server. The RFC for dynamic client registration says that a process could be put in place but AFAIK it doesn't specify a concrete method and so that might pose an interoperability issue.

We could define some safeguards for dynamic client registration, which may require a large spec change but it seems to me to be the most logical place to put a client verification step, or we accept that the ability to gain access to the network is enough of a safeguard against rogue actors. But it means any device that gains access to the network could both register, get a set of client credentials, and get tokens straight off the bat when using the client credentials grant.

Flow Comparison
With either of the approaches above however, once a client has credentials, it can still perform actions without User Authorisation. A Node with client credentials will be able to register with any registry and perform actions (such as deleting resources) without a step that says "Operator A is logged in, he does/does not have permission to delete things". With the Auth Code Grant, the added step of redirecting to an Identity Provider and User Authentication (username, password, etc) prevents devices being able to perform API interactions without user intervention and therefore with the privileges assigned to that user.

Conclusion
As with all these things we need to balance interoperability/usability with Security. It may be that if we can verify a client is fine (Valid client cert, client registration verification, etc.) then that's enough to permit us to use the Client Credentials Grant. We'd then treat all clients (Nodes) like they can register/query with all Registry's within the Broadcast environment, providing we are mitigating these interactions. These mitigations include things like Nodes only being able to delete records that contain their client ID, which we already mandate in https://amwa-tv.github.io/nmos-authorization-practice/, and validating aud, iss and sub claims.

[dannymeloy]

I should point out that if we permit the Client Creds Grant, further restrictions would need to be enforced within the Auth Server / added to the spec. For instance, we wouldn't want Broadcast Controllers clients registering with the CC Grant and the IS-05 scope, as it could then request tokens implicitly and perform IS-05 connections without user interaction.

So we'd either restrict client credential flows to clients that only have IS-04 (or other applicable IS specs) as the registered scope and assign them a fixed value for the private x-nmos-api claim. Or in the hypothetical client verification step, an operator would be able to reject any client that didn't register with the appropriate grant_types.

[jonathan-r-thorpe]

Hi @dannymeloy, many thanks for your explanation.

I think you've presented the issues quite succinctly, and absolutely agree with your conclusion regarding the balance between usability/interoperability, and security.

As you may know, it was the usability angle that precipitated the question over bulk authorization, as the burden of authorizing multiple (tens, hundreds?) or nodes on the network would degrade the user experience.

Currently broadcasters are happily using air-gapping to secure their networks (with no network level security),

My concern is that without a security solution that is low touch from the end-user perspective there will be resistance to adoption of the standard.

I agree that if used, the Client Credentials Grant should be reserved for those nodes with only IS-04 scope, and that equipment with a user interface such as the broadcast controller should use the Authorization Code Flow.

In terms of mitigation, could a best practice be recommended around Auth Server registration restrictions e.g. limiting registrations by subnet, having an allow list etc. ?

[peterbrightwell]

Moved to #76