Audience Restriction for Client Assertions

[tlodderstedt]

Do we need to be more specific about audience restriction for use the client assertion at the PAR endpoint than RFC7523?

The JWT MUST contain an "aud" (audience) claim containing a
value that identifies the authorization server as an intended
audience. The token endpoint URL of the authorization server
MAY be used as a value for an "aud" element to identify the
authorization server as an intended audience of the JWT.

[panva]

We can make the issuer identifier a required audience of the PAR JWT. That would be a new requirement to OIDC Request Object and JAR aud claim presence. But why would the token endpoint be an accepted audience value? I think we can make the profile stricter by requiring audience, but i wouldn’t add further audience value options.

[panva]

Or are you talking about the eventual JWT based client authentication use? In that case i don’t see why PAR would profile one of several possible auth method.

[tlodderstedt]

I mean use of assertions for client authentication. I feel the audience should be the PAR endpoint to ensure the assertion cannot be used at another endpoint, e.g. the token endpoint.

[panva]

cc @b---c

I believe we touched on this several times now and landed on universally saying the client should be sending the issuer identifier as audience. The AS should accept the issuer, actual endpoint url used or token endpoint url for interoperability with existing software that may have followed one or the other unfortunate worded specifications.

For interoperability with existing software that already uses the issuer identifier for client assertions, i’d say don’t create another profile for authentication assertions in a spec that isn’t really concerned with how clients authenticate themselves.

[b---c]

Pretty much what @panva said (as usual :)

PAR currently has some text on this:

Note that there's some potential ambiguity around the appropriate audience value to use when JWT client assertion based authentication is employed. To address that ambiguity the issuer identifier URL of the AS according to [@!RFC8414] SHOULD be used as the value of the audience. In order to facilitate interoperability the AS MUST accept its issuer identifier, token endpoint URL, or pushed authorization request endpoint URL as values that identify it as an intended audience.

Which was largely derived from text in the CIBA document that came out of discussion around the same/similar topic. Some more info is in https://bitbucket.org/openid/mobile/issues/155/aud-to-use-in-client_assertion-passed-to

[tlodderstedt]

thanks for the explanation. I raised this issue after conversations regarding the OIDC fed draft, which uses assertions in the front channel for client authentication in the authentication/authorization request (https://openid.net/specs/openid-connect-federation-1_0.html#rfc.section.9.1.1).

With this new mechanism, attackers can obtain valid client assertions in the front channel and replay it, even at other endpoints, e.g. token or PAR. In my opinion, the only countermeasure is to add the real endpoint to the assertion as aud.

If we assume assertions can also leak at other places, e.g. logs, that might make sense as a general rule.

What do you think?

[b---c]

JWT based client authentication from RFC 7523 was intended and specified as an authentication mechanism only for direct requests from client to AS. What OIDC fed is doing sending it though the front-channel is not only not in-line with the underlying specifications but, as you've pointed out here, also introduces a security problem. PAR shouldn't need to address that security problem and the problem isn't isolated to PAR anyway (a leaked client assertion could be used at the token endpoint, CIBA, introspection, etc.).

Using any of the OAuth client authentication methods in the front channel is problematic. MTLS and client_secret_basic just won't work. And client_secret_post would be wildly insecure. That might seem like odd comparisons but it's effectively what OIDC fed is trying to do. And doing it with private_key_jwt is also very insecure - it's just a little more subtle. There are other problems as well like the fact that the content of the authn request (which again pass through an untrusted intermediary) aren't bound to the authentication. But I digress.

The history and current state of private_key_jwt and RFC 7523 aren't perfect. But it does the job it was intended for okay. It's about direct entity to entity authentication so the aud identifies the entity not a specific endpoint at an entity.

At a minimum openid-connect-federation needs to acknowledge that it's misusing private_key_jwt and do something to mitigate the security problem. I think strictly requiring the aud in that context to be the authorization endpoint would do it (though it actually would depend on how aud validation is being done and what any particular AS considers as something that "identifies the authorization server as an intended audience"). It seems to me that JAR or OIDC's Request Object by Value might be a more appropriate thing to look at there though. That does beg the question of whether a JWT request object could be used maliciously as a JWT client assertion for authentication, which had me a little worried there, but I think the sub requirement in bullet 2 of https://tools.ietf.org/html/rfc7523#section-3 will thwart such an attempt.

[b---c]

Put in this issue for OIDC fed: https://bitbucket.org/openid/connect/issues/1164/insecure-front-channel-use-of

[jogu]

(probably somewhat off topic for this issue now... apologies)

That does beg the question of whether a JWT request object could be used maliciously as a JWT client assertion for authentication, which had me a little worried there, but I think the sub requirement in bullet 2 of https://tools.ietf.org/html/rfc7523#section-3 will thwart such an attempt.

That's a relatively subtle security property - I wonder if there's any clients that unintentionally include 'sub' in request objects? (Should conformance tests verify the absence of 'sub' in request objects?)

[In most cases I suspect a lack of iat/exp in the request object would prevent it being used as a client assertion? But FAPI requires iat/exp in request objects...]

[b---c]

Yeah, it is a bit subtle and less than ideal. Most of this predates the now accepted advice to use the typ header to prevent substitution/confusion of tokens. So I'm not sure what can be done without updating the RFCs but I'm not sure the potential problem rises to a level of concern that would warrant an update and the follow on impacts on implementations and interoperability.

The use of sub to prevent a mixup jumped out at me because RFC 7523 requires it and 'For client authentication, the subject MUST be the "client_id" of the OAuth client.'. So while it's possible that a client unintentionally includes a 'sub' in request objects, it seems unlikely and even less so that it would have the client id value (which is already being sent as the client_id and maybe the iss too). A missing exp would catch it too but I suspect that shows up in a lot of request objects. iat is optional so probably isn't helpful here.

[b---c]

(Should conformance tests verify the absence of 'sub' in request objects?)

There's nothing in spec that I'm aware of that outright prohibits that. So it's kind of a stretch for conformance tests. But maybe. Perhaps a test that fails if 'sub' is in the request object and its value is the client id. ?

[vdzhuvinov]

FYI OIDC Federation draft 12 switched to JAR and PAR, so the JWT assertion in the front-channel is no longer there
https://openid.net/specs/openid-connect-federation-1_0-12.html

[jogu]

(Should conformance tests verify the absence of 'sub' in request objects?)

There's nothing in spec that I'm aware of that outright prohibits that. So it's kind of a stretch for conformance tests. But maybe. Perhaps a test that fails if 'sub' is in the request object and its value is the client id. ?

For reference I wrote up two tickets to cover tests the FAPI conformance suite could do:

verify that requests objects are not usable as private_key_jwt client authentication
- verifies AS rejects client assertions that are missing sub

Verify that requests objects from clients are not valid client assertions - verifies clients don't include sub in request objects

[b---c]

@vdzhuvinov

FYI OIDC Federation draft 12 switched to JAR and PAR, so the JWT assertion in the front-channel is no longer there
https://openid.net/specs/openid-connect-federation-1_0-12.html

The client auth JWT in the front-channel is no longer there but the the way the JAR JWT is defined in -12 seems rather problematic. See http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20200706/007849.html

[b---c]

@jogu

verifies clients don't include sub in request objects

I was gonna say that it should probably only preclude a 'sub' claim that contains the client_id value. But looks like the ticket has that already with "i.e. that they do not include 'sub' claim that contains the client_id."