Security considerations when two (oauth-mtls?) clients use same key

[Joseph Heenan]

As raised on today's call we may need to explicitly call out the security considerations of multiple clients sharing the same TLS client (or I guess private_key_jwt) private key.

Using keys in this manner may open extra attacks if the different clients have different permissions (e.g. one is read only or one is read write) or if one client is significantly more popular, allowing access tokens from the popular client to be used by comprising the less-popular (and potentially less well secured).

[Dave Tonge]

I think we should rather advise that credentials should never be shared between Clients, even with eIDAS its easy to have multiple certs. However this doesn't solve the problem entirely as the certs may have the same DN and therefore for tls_client_auth they are essentially the same. I think we should require that the tls_client_auth_subject_dn must be unique per client. I would need to look into it further but I think this is still compatible with eIDAS / PSD2.

[Joseph Heenan]

@dgtonge That was the position I started out at, however my take away from the call was that both Ralph Bragg & Brian Campbell were advocating that it was okay for multiple clients to use the same TLS client certificate.

@b_d_c Rereading https://tools.ietf.org/html/draft-ietf-oauth-mtls-12 I found the sentence:

The authorization server MUST enforce the binding of a certificate to a specific client as described in either Section 2.1 or Section 2.2 below.

My interpretation of this Is that one certificate must bind to exactly one client, meaning that one certificate being used by two clients is not permitted. From the discussion on the call last week it sounds like that interpretation may not match with your intention though?

[Dave Tonge]

Thanks @josephheenan I missed the part of the call were you were discussing this. I have to say that I don't think the sharing of certs (or DNs) should be encouraged, I read the sentence you quoted in the same way.

[Brian Campbell]

I wouldn't say that I was advocating for it so much as just saying there are situations (like clients 'owned' by the same org with the same baseline permissions) where it wouldn't really be a problem. And that there was nothing in the OAuth MTLS document that explicitly forbid it. Much as there's nothing that explicitly forbids different clients having the same secret. Or the same key(s) with JWT client auth. Credentials is as credentials does.

I don't think sharing of certs should be encouraged either. But haven't (intentionally) done anything in the docs I'm working on to forbid it. I guess I think that's kinda beyond the scope of it.

So with that said, the sentence in MTLS -12 was not intended to say that exactly one certificate must bind to exactly one client. I can now see how it could be read that way but that wasn't the intent. It's really just meant to say that the association between client and expected certificate needs to be checked.

[Joseph Heenan]

Apologies for rather over simplifying your position Brian - that 'in some situations' is definitely an important qualification, thanks for expanded explanation.

I'll have a go at drafting some text.

[Dave Tonge]

https://bitbucket.org/openid/fapi/pull-requests/175/add-security-consideration-around-sharing

[Dave Tonge]

Resolved with this commit: https://bitbucket.org/openid/fapi/pull-requests/175/add-security-consideration-around-sharing