Expressing role reversal in ACE

(I've lost track where we've discussed this before, let's link resources into here as we find them, because I think that this is the maturest we've ever got this)

CoAP and OSCORE are really good at using a single channel for bidirectional requests; also EDHOC is quite flexible there (https://github.com/ace-wg/ace-edhoc-oscore-profile/issues/8 is rather easy, https://github.com/lake-wg/authz/issues/21 is harder but probably still possible). ACE, on the other hand, has a rather fixed mind set on who is the client and who is the server.

A starting point for illustrating ACE's trouble are RD extensions: Depending on who is the ACE client in the initial EDHOC handshake between the RD and the EP, the same set of authorizations that should be expressed for that connection is phrased in either of two ways:

If the EP is the ACE client, the token conveys the authorization to POST to /register?ep=endpoint-name, assures the client that the RD is really an AS recognized server, and implies that the RD is authorized to GET the unfiltered /.well-known/core of the EP in role reversal (assuring the RD that it indeed is the very EP that may provide the information for endpoint-name).
If the RS is the ACE client, the token conveys the authorization to GET the unfiltered /.well-known/core of the EP, assuring the RS that the EP's identity (expressed as an audience) is that which may be consumed into endpoint-name's links. It implies that the EP may POST to the registration URI, and that the server it POSTs to is really the RD recognized by the AS.

While symmetrical in concept, the claims in the tokens for those directions don't look anything like symmetry, and the inference is sketchy at best.

Easy alternatives

The easiest way to address this is to not address it at all. In a role reversal situation, both parties take a token, both POST (or EAD3) it to their peer, they create and maintain two separate OSCORE connections, and at least share a CoAP context.

This works (albeit at the cost of a few more communication hops, possibly enabled by one of the parties acting as a proxy), but it should at least satisfy most security requirements. (It doesn't reveal anything new about who is sending requests: that information is plain in OSCORE and usually apparent in transport layer security).

There has to be a better way

A sketched solution.

diagram-export-19-03-2024-21_09_39

(sorry for the image quality, the eraser.io board on the IETF tables is a major lock-in trap, free to play but pay to properly save).

Let's introduce two new parameters, which can show up in the claims inside a token as well as in the token response:

rev_scope: When the C receives requests from the RS (in role reversed mode), that peer is authorized to act with the indicated scope. This is part of the token response C receives from the AS. The AS may pack them in for the C as a surprise (like broadening a scope, because it knows that the they are authorized), or C may request that rev_scope and rev_aud explicitly.
rev_aud: When RS sends requests to C as part of role reversal, C is authenticated to be (in) the described audience. This is part of the token that the RS decrypts or otherwise verifies.

Combined, these describe which actions are allowed in role reversed mode.

In the motivating example, these restore the symmetry between the two matchings between RD and ACE roles: What is the scope and rev_aud that the a party receives when acting as ACE RS is the rev_scope and aud which the it receives when acting as ACE Client.

Further application

rs_cnf is really a bit like revcnf -- that was one of the first times this whole thing surfaced. We won't retroactively rename it, but could treat it as an honorary rev*.
If someone ever wanted to build a workflow where party C asks a token of the AS, uses the alternative flow described in the document to have the token pushed down to the RS, and the RS should be the one that sends a Session ID to the RS, they could legitimately register a rev_session_id. (We will probably not do this here, because EDHOC is by far flexible enough to just leave it the regular way – but for symmetry, we could).

Remaining asymmetries

The one asymmetry left is that any token renewal (eg. when it is about to expire) is still with the original C. There may be ways to do this (possibly by giving C access to the token series on the AS), but those are not well thought through, and at least for the cases considered so far, this is not needed anyway.

Explaining it to anyone who points out that just because one direction's C can play C towards an AS doesn't mean that its resources as an RS take orders from that AS

The easy answer:

The application has just requested a token for some scope, and is hopefully aware that role reversal is about to happen. It better grant access to the resources described there, even though it's not coming from the responsible AS, but it's coming from the application itself that has just authorized the an operation that will necessitate allowing this access, and by being covered by the ACE token it at least can be sure that the resource access is only available to the right peer.

The elaborate answer:

There may be a game of two tokens somewhere in there, where as a part of the token response C receives from the AS where it requests a token it also receives an actual token from the AS responsible for it as an RS, and the token encrypted for the RS contains an additional encapsulated token response which its own responsible AS packed in there for the other AS.

If that becomes the canonical explanation (and it'd need someone to flesh it out), rev_aud can be retconned as a shorthand for "imagine there is an encapsulated token response you have here, and it contains this aud", and rev_scope would be "imagine this token response had a token encapsulated in there, and this is its scope" – but it is all shorthand because so far it's all just managed by a single AS.

ace-wg / ace-workflow-and-params