search

ietf-wg-wimse / draft-ietf-wimse-s2s-protocol

WIMSE Service to Service I-D
Other
3 stars 3 forks source link

Use of WIT without proof of possession and interop with legacy systems #53

Open jsalowey opened 1 month ago

jsalowey commented 1 month ago

The current draft says that the WIT must not be accepted without proof of possession of the corresponding private key. This is for security reasons because if you are willing to accept the WIT without proof of possession then the security benefit of the WIT is greatly diminished.

This restriction makes it difficult to integrate a WIT seamlessly into existing applications. I question whether this could be done securely, but I think we should have the discussion:

  1. Is there a sensible policy that would make this OK? It seems that legacy application would be none the worse off, but application that could handle the WIT would still benefit. I think there is a difficulty here in that you have client an services sides that might be updated a different times making it more complex.
  2. Perhaps there is an alternate form of POP that would be easier. For example binding to a TLS key or identity. While this seems attractive, one of the reasons for the WIT is to suport cases where MTLS isn't realistic.
yaronf commented 1 month ago

And then the do-nothing alternative:

  1. Don't allow using WIT without PoP (granted there's no way to enforce this restriction in the real world), and rely on token exchange to translate between legacy bearer tokens and WITs.
kenmccracken-google commented 3 weeks ago

I agree with both points (1.) and (2.).

  1. is needed for backward-compatibility with existing "legacy" systems.
  2. allows WITs to be built on top of existing X.509-credentials, which should be part of the recommended mTLS solution.

For both of these cases, claims within the WIT can further constrain access using "aud"/"scp" to express least-privileges access on top of an identity's (possibly-broad) access privileges imparted by Workload identity alone. The "aud"/"scp" constraints can also be preserved during federation with OIDC-like IdPs.

IMO, the WIMSE s2s protocol should provide the option 2 for PoP, where the protocol can accept WITs layered on top of existing X.509-credentials for situations where mTLS is realistic. In these cases, reducing the number of tokens required can reduce developer integration bugs and misconfigurations, when compared to the multi-token-requirements of Section 4. X.509 Certificate hash binding or SAN identity binding should be considered, as an adaptation of https://www.ietf.org/archive/id/draft-ietf-wimse-arch-01.html#name-identity-credentials "Alternatively, sender constrained tokens can be used such as TLS session binding."

yaronf commented 2 weeks ago

We don't see a way to use WITs with legacy systems.

A WIT would be ignored by a legacy system, but the non-legacy system would still need to include a legacy token as well.

jsalowey commented 3 days ago

A WIT is transported in its own header so it can co-exist with a legacy bearer token attribute.

The systems that rely upon the WIT will be secure because it will not be used as a bearer token. The bearer token approach would still have all the problems of a bearer token. In this approach the WIT should convey the information from the bearer token that is necessary for it to be usable by the system.

There could be an alternate approach where the bearer token could have a superset of what is in the WIT if it also includes the identity in the WIT in a standard field. That way a system that understands how to use the WIT could also validate that the bear token is bound to the WIT (and not really a bearer token when used by a system that understands the WIT).

I'm not sure which approach is better right now, but the more information you include in the WIT the more chance it needs to be updated or revoked, so it might be worth defining what the legacy binding attribute to bind an existing token format to the WIT.