Re: [Wimse] Is workload identity really the problem?

[Joseph Salowey <[e-mail]>]

On Fri, Sep 8, 2023 at 11:42 AM Orie Steele <[e-mail]>
wrote:

> Sorry to float a solution to a problem I barely understand... but...
>
> On Fri, Sep 8, 2023 at 1:20 PM Joseph Salowey <[e-mail]> wrote:
>
>>
>>
>> On Thu, Sep 7, 2023 at 8:23 AM Justin Richer <[e-mail]> wrote:
>>
>>> I think that this is an important aspect to capture: nobody coming into
>>> this is claiming that there are no tools or partial solutions. But the
>>> problem is that: they're partial, and one of the main goals of this work is
>>> to shine light on the gaps that people see when we bring these pieces
>>> together in different ways.
>>>
>>> Some problems are solved, but that doesn't make all problems solved. In
>>> fact I'd argue that it makes it a more compelling space for finding
>>> solutions because people want to use the parts that we have,where it makes
>>> sense.
>>>
>>> But to do that, first you need to make skat of where the existing parts
>>> fit, then you need to make sense of how they go together, then you need to
>>> write down the gaps and find those solutions, which is what I see as the
>>> core work of wimse. The use case document attempts to capture some of these
>>> as a starting point. Just about everything in there, I could cobble
>>> together something to make it work, and people are doing that. But now it's
>>> time to figure out what the common parts and patterns are, and that's why
>>> I'm interested.
>>>
>>>
>> [Joe] These are things we run into when trying to reuse OAUTH
>> for workloads. The result is solutions that lead to interop problems and
>> potential security issues when we try to reuse common libraries or federate
>> across organizations.   As an example, the defined integration between
>> OAUTH and X.509 is through TLS.  With a little duct tape you can patch
>> together solutions to address cases when end-to-end TLS is not available,
>> but you are limited in authentication mechanisms and the required
>> interactions fall outside the core OAUTH set of use cases that involve
>> public clients and web browsers/user controlled applications.
>>
>
> Is this a "sign in to a public client with a decentralized identifier use
> case" ? Or are you saying you don't want public clients and you don't have
> the OAuth block you are looking for?
>
> [Joe] The cases I'm dealing with don't use public clients in the way OAUTH
defines them (I think).  There probably are cases where workloads are
public clients, but I haven't been focused on that.


> The use case talked about private key jwt.... is there some duct tape
> version of this story with private key jwt and mtls that highlights its
> greatest weak points?
>
> [Joe] The short-comings I've run into with private key jwt is that the
certificate validation piece of it is undefined or at least un-implemented
in many cases (you are checking against a public key you learned in some
other way and that the exchange doesn't involve a nonce for freshness (in
many cases this may not seem important because if the attacker can generate
a signature they have access to the private key when we start looking at
workloads that can attest to have a secure method of key storage then
freshness makes some difference).


> Many of the pieces are there but how they fit together is ill-defined.
>> The problems also exist when trying to communicate information about what
>> has happened previously from one part of the system to another (which may
>> cross an organizational boundary) such as user
>> authentication/identification, hardware attestation or application specific
>> validation.  We have tools from the IETF and other places that can help us,
>> but we need to get out the duct tape to make it work with little chance of
>> interop with other solutions and a chance that there is an unforeseen
>> weakness (fortunately we can always apply more tape and maybe some chewing
>> gum).
>>
>
> Let's make it wrong first, so we can see how to make it right ; )
>

>
>>
>>
>>> -Justin
>>> ------------------------------
>>> *From:* Wimse <[e-mail]> on behalf of Pieter Kasselman
>>> <pieter.kasselman=[e-mail]>
>>> *Sent:* Thursday, September 7, 2023 10:59 AM
>>> *To:* Tschofenig, Hannes <hannes.tschofenig=[e-mail]>;
>>> Tschofenig, Hannes <[e-mail]>; evan <[e-mail]>;
>>> Watson Ladd <[e-mail]>
>>> *Cc:* [e-mail] <[e-mail]>
>>> *Subject:* Re: [Wimse] Is workload identity really the problem?
>>>
>>>
>>> Hi Hannes, thanks for the great clarifying questions.
>>>
>>>
>>>
>>> When I wrote “attested identity” I was thinking of an identity that was
>>> assigned to a workload following some kind of attestation process with the
>>> issuing authority (e.g. the sort of flow that happens in the SPIRE
>>> implementation).
>>>
>>>
>>>
>>> I think SPIFFE\SPIRE does an excellent job at solving the “zero turtle”
>>> problem – that is bootstrapping a workload with an identifier and a
>>> credential. There are some tweaks that will make things even better (e.g.
>>> adding some kind of proof-of-possession mechanism to SVID JWTs will help
>>> protect against credential/token theft problems that have become more
>>> commonplace than anyone should be comfortable with).
>>>
>>>
>>>
>>> However, to ensure that an identity system can deliver on the promise of
>>> ensuing that the right entity has access to the right information at the
>>> right time for the right reasons, you need a little bit more. For example,
>>> SPIFFE/SPIRE provides you with credentials that can be used for
>>> authentication (e.g. MTLS),  but does not define how that should be used
>>> with OAuth 2.0. OAuth 2.0 in turn requires that OAuth clients are
>>> registered with the Authorization Server, however, given the dynamic nature
>>> of workloads (add/remove in response to scale demands), these may not
>>> always be feasible (there is some interesting new work on attestation based
>>> client authentication in the OAuth WG that may help address this😉 ).
>>>
>>>
>>>
>>> This is one example that is also described in the use cases doc (see
>>> Section 3,2 in draft-gilman-wimse-use-cases-00 - Workload Identity Use
>>> Cases (ietf.org)
>>> <https://datatracker.ietf.org/doc/draft-gilman-wimse-use-cases/>). The
>>> other use cases attempt to capture similar scenarios where we don’t have
>>> good end-2-end stories solutions – mostly where different standards
>>> eco-systems are trying to connect.
>>>
>>>
>>>
>>> I hope that helps.
>>>
>>>
>>>
>>> Cheers
>>>
>>>
>>>
>>> Pieter
>>>
>>>
>>>
>>> *From:* Tschofenig, Hannes <hannes.tschofenig=
>>> [e-mail]>
>>> *Sent:* Thursday, September 7, 2023 12:51 PM
>>> *To:* Pieter Kasselman <[e-mail]>; Tschofenig,
>>> Hannes <[e-mail]>; evan <[e-mail]>; Watson
>>> Ladd <[e-mail]>
>>> *Cc:* [e-mail]
>>> *Subject:* AW: [Wimse] Is workload identity really the problem?
>>>
>>>
>>>
>>> Hi Pieter,
>>>
>>>
>>>
>>> what do you mean by "attested identity"?
>>>
>>>
>>>
>>> Explain me where SPIFFE falls short in performing authentication, and
>>> authorization of what you want.
>>>
>>>
>>>
>>> Ciao
>>>
>>> Hannes
>>>
>>>
>>>
>>> *Von:* Wimse <[e-mail]> *Im Auftrag von *Pieter Kasselman
>>> *Gesendet:* Donnerstag, 7. September 2023 13:10
>>> *An:* Tschofenig, Hannes <hannes.tschofenig=[e-mail]>;
>>> evan <[e-mail]>; Watson Ladd <[e-mail]>
>>> *Cc:* [e-mail]
>>> *Betreff:* Re: [Wimse] Is workload identity really the problem?
>>>
>>>
>>>
>>> My perspective is that SPIFFE is part the story and is excellent in
>>> getting us to a point where there is an attested identity provisioned with
>>> a credential and since it is platform agnostic, it lends itself to
>>> multi-service/multi-cloud environments. However, that is not sufficient for
>>> someone operating an identity management system. Connecting those standards
>>> to the rest of the standards eco-system to perform authentication,
>>> authorization (including taking user identity and call chain information
>>> into account), (automated) federation, monitoring and remediation
>>> infrastructure and compliance reporting is required to deliver a functional
>>> multi-service workload identity system.
>>>
>>>
>>>
>>> *From:* Wimse <[e-mail]> *On Behalf Of *Tschofenig, Hannes
>>> *Sent:* Thursday, September 7, 2023 10:42 AM
>>> *To:* evan <[e-mail]>; Watson Ladd <[e-mail]>
>>> *Cc:* [e-mail]
>>> *Subject:* Re: [Wimse] Is workload identity really the problem?
>>>
>>>
>>>
>>> From your response I think you are more referring to the management of
>>> credentials. This is something that is largely outside SPIFFE (but covered
>>> in the reference implementations). The IETF has done a tremendous amount of
>>> work on managing credentials. For example, if you want to request an X.509
>>> certificate, re-new a certificate, etc. there are various protocols
>>> available that can be used, such as EST or CMP.
>>>
>>>
>>>
>>> A question that is related to the topic of credential management: Would
>>> you consider the scope of the work in WIMSE to focus on what corresponds to
>>> the scope of SPIFFE or, the larger scope, the scope of SPIRE?
>>>
>>>
>>>
>>> Ciao
>>>
>>> Hannes
>>>
>>>
>>>
>>>
>>>
>>> *Von:* Wimse <[e-mail]> *Im Auftrag von *Evan Gilman
>>> *Gesendet:* Mittwoch, 6. September 2023 01:54
>>> *An:* Watson Ladd <[e-mail]>
>>> *Cc:* [e-mail]
>>> *Betreff:* Re: [Wimse] Is workload identity really the problem?
>>>
>>>
>>>
>>> On Tue, Sep 5, 2023 at 9:48 AM Watson Ladd <[e-mail]>
>>> wrote:
>>>
>>> Dear Wimse enthusiasts,
>>>
>>> I read the usecases draft and I'm not entirely sure that we're
>>> thinking about the problem in the right terms. A lot of the desired
>>> properties seem to be about authorization, and naming is not really
>>> relevant. ...
>>>
>>> ...
>>> Secondly credential capture and reuse  seem to have a different set of
>>> technical issues than naming. One could use asymmetric keys provided
>>> via sidecar so not exposed to the process/ use some of the ideas
>>> explored in the now closed LURK wg, but this seems largely orthogonal
>>> to identity issues.
>>>
>>>
>>>
>>> IMO, identity is a lot more than just naming. It's also about
>>> credentialing, credential exchange/validation, and authority federation (to
>>> name a few). I would ask, how useful is an identity scheme if credential
>>> format and use are not defined? Kerberos, OAuth, etc all define one. And
>>> works to prevent credential theft are also undertaken in those areas
>>>
>>>
>>>
>>> Further, I feel this layer exists largely in service of authorization.
>>> As such, I personally find it useful to frame shortcomings as authorization
>>> needs.
>>>
>>>
>>>
>>> Lastly there's the "what code do I have actually running" question.
>>> And this seems to be really outside of the domain of IETF in general,
>>> and the answers here are not useful to the other usecases. An external
>>> service doesn't care about what commit the latest update a team had
>>> was to make security decisions. It may care about what security
>>> standards were applied in the process, but this feels to me like logic
>>> about issuance of identity credentials not the service identity
>>> itself.
>>>
>>>
>>>
>>> I agree that this specific example is related to the issuance of
>>> identity credentials. The part that I think is worth highlighting is that
>>> the issuance system has much more information about the workload than
>>> appears in the identity itself. The authorization layer frequently wants
>>> this information (for e.g. ABAC), and it's not really clear where to put
>>> this information, how to distribute it, etc. It very well could be that it
>>> does not belong as a part of the issued credential, though I do think it's
>>> a worthwhile discussion
>>> --
>>> Wimse mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/wimse
>>>
>> --
>> Wimse mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/wimse
>>
>
>
> --
>
>
> ORIE STEELE
> Chief Technology Officer
> www.transmute.industries
>
> <https://transmute.industries>
>