[Wimse] Re: What is an identity and section 3.2.1 of draft-ietf-wimse-arch (or must identity be the compositum of all attributes?)

[Pieter Kasselman <[e-mail]>]

Working group chair hat off, identity enthusiast hat on...



Thanks for working on this PR Joe, this is a tricky subject ;)



Someone once told me that the first trap to avoid when working in identity is to try and define it... It is hugely overloaded and we often end up using it as shorthand for a set of other more burdensome activities we try to describe.



Another way to look at it is to focus on the outcome you expect from your use of "identity" and then define the building block to achieve the outcome. You never end up defining identity, but rather what you want to use identity for (the outcome), which in turn helps scoping down the building blocks.



So, when it comes to things like using identity to decide access, a useful way to think about the reason for having identity is that you want to ensure that the right entity (person/workload/device) has access to the right resource at the right time for the right reason. To build such a system you end up needing a couple of building blocks. These include:



1. Identifiers: Identifiers are the basic building blocks of any identity system. It is only possible to manage identities if there is a way to identify them uniquely within and across trust domains.

2. Attestation: Attestation includes the presentation of proof to establish the provenance of an entity. This assertion may include a cryptographic binding (use of a cryptographic key or shared secret), but may also include the collection of other information to assert the provenance of the entity.

3. Secrets Management: Some entities use long-lived secrets such as cryptographic keys (symmetric and asymmetric) as part of the attestation process. In the case of asymmetric cryptographic keys, the public key may be included as an attribute in a credential (see next point on credential formats).

4. Credential Formats: Identifiers are often shared with other system participants by encapsulating them in a credential with a specific format. The credential may include additional information or attributes to identify the entity and is often bound to this additional information using cryptographic techniques (e.g. digital signatures). Examples of credential formats include X.509 certificates, JSON Web Tokens, and Verifiable Credentials.

5. Provisioning: Identifiers, attestation metadata, secrets and credentials follow a lifecycle that includes the usual create, read, update, and delete operations that are recorded in a system of record (e.g. a directory).

6. Authentication: Proving that an identifier and a set of additional attributes is associated with an entity. This is done by presenting a credential which may include attributes that the recipient can verify, including proof of possession of a private key matching the public key included as an attribute in the credential.

7. Authorization: Answering the question of “does this entity have access to that resource, at this time, under these conditions?” based on the previous 6 building blocks. It answers the original question, but there are a few more components needed beyond just making the decision around access.

8. Federation: Maintaining trust boundaries within a system is a common part of controlling access to resources. As an entity cross trust boundaries they need to be able to establish trust relationships to both accept credentials from other domains as well as have their own credentials accepted.

9. Monitoring and Remediation: Once an entity is authenticated and authorization decisions are made, it is necessary to monitor their activity to detect anomalies that may indicate compromise. If a compromise is detected or suspected, it should trigger remediation to mitigate the impact of a compromise.

10. Policy and Configuration: Policy and configuration is required for each of the machine identity building blocks. Policy defines the specific rules that should be applied, ranging from credential format through to authentication method and authorization rules.

11. Compliance: Compliance for each building block needs to be proven against the policies for that building block. Compliance often takes the form of reports and the process is simplified through the use of structured data in both the policy and the event logging.

Looking at the PR, I wonder if, instead of defining a workload identity, what if you define a workload identity management system that ensures the right workload has access to the right resources at the right time? In that case you could define a workload identifier, credential format and some of the attributes included in the credential format (including a public key perhaps). Instead of having a “workload obtain its identity”, perhaps we might say that “a workload should be provisioned with a credential that includes an identifier and other attributes, along with any secrets it might need, as early as possible in its lifecycle”. Instead of “a workload presents its identity”, we can be more specific by saying “a workload presents its credential and authenticates itself using the private key bound to the credential to generate a signature and prove control of the key”. It’s way more burdensome and time consuming to say, but it could help avoiding overloading how the term “identity” gets over used (this may be a bit of an extreme example).

Cheers

Pieter


From: Joseph Salowey <[e-mail]>
Sent: Tuesday, July 2, 2024 1:52 AM
To: Justin Richer <[e-mail]>
Cc: Watson Ladd <[e-mail]>; [e-mail]
Subject: [Wimse] Re: What is an identity and section 3.2.1 of draft-ietf-wimse-arch (or must identity be the compositum of all attributes?)

I put together a PR (https://github.com/ietf-wg-wimse/draft-ietf-wimse-arch/pull/36/files) for the architecture draft to try to better describe identity in a new section.  Please comment and let me know if it helps. Other sections will probably need to be modified once we tighten down this section.

Cheers,

Joe

On Tue, Jun 18, 2024 at 10:11 AM Justin Richer <[e-mail]<mailto:[e-mail]>> wrote:
Thanks, Watson.

[ Chair hat off ]

Ah, monads, I should have known they’d crop up here eventually. :)

I agree that there’s a fundamental difference between "what something is" and "what something can do", and on top of that there’s also "what we call something". All the "something" in this case is a workload in its context.

In many cases, it’s tempting or even convenient to wrap these up together. After all, if I know who you are, then I should know what you can do based on that. And if your identifier — the thing I call you — gives me some of that information in a structured format, then all the better, right? This is a large part of the thinking behind the SVID concept - the name has some internal semantics that guide me towards understanding what to do with the thing that has been given that name. And this pattern has been hugely useful, since it lets you carry information about authorization through a system using something that I guarantee will be there, the identifier. That’s what I’m reading from that section in the WIMSE Arch draft — here’s a larger identity question that gets encoded into an identifier and used for authorization decisions.

But for me, WIMSE does represent an opportunity to tease this apart better than it has been in the past, while still allowing us to deliberately collapse things in cases where it makes sense.  I should be able to figure out that Jessie is cow #2 without naming her "Jessie.cow[2]". But then the question becomes, how do I carry that information? And more importantly for us here, how do I do that in a way that’s interoperable on some level?

And the question goes further, because I don’t believe that identifying the workload is where the security decisions stop. In fact, I think that’s just one input, and not even necessarily a required input, into an authorization decision. Much more important is the context of the request in which the workload is running. This goes beyond the identity of the workload itself and into the world that the identified workload finds itself in at runtime.

I am not going to pretend to have clear answers, but I do think there’s merit in pursuing these questions to find them. But that said, I do believe that there are several concepts that are separable here, which can sometimes be expressed together using the same element:

- an identifier for a workload that is readable by other workloads and systems
- the collection of attributes that uniquely identify a workload (the identifier being one of them), its "identity"
- the runtime context around a workload (request context being a big part of this)
- the set of computed access rights for a workload in a context

In my view, OAuth access tokens are just one input to the runtime context, but today they’re being used to express all of these things in different ways in different systems. I really do think that if we’re going to stop always conflating things, we need to work on fundamental differentiation.


— Justin


On Jun 17, 2024, at 7:59 PM, Watson Ladd <[e-mail]<mailto:[e-mail]>> wrote:

Dear wimsyists,

I must confess to never having read Leibnitz, but I think section
3.2.1 will force me to. I hope this long rambling email explains why
and elucidates some of what confuses me in WISME, and hopefully others
find out they are likewise confused.

Section 3.2.1 implies the identity must include a bunch of information
that's relevant to the problem of authorizing a request, that is
conveyed by whatever ticket brings it alongside a request.

There are two notions of identity at play here. The first is the
concept that makes one thing not like the other. The other is the name
by which we might call a thing not like the other. E.g a farmer might
have cow 1, cow 2, cow 3, or Bessie, Jessie, and Daisy. Bessie does
not convey any of the relevant information about that cow, but does
identify it uniquely among the herd. To me this is also identity, and
indeed is the identity that would be most convenient to convey. This
is where Leibnitz comes in.

Now given a request we might want to evaluate the fundamental question
of "who get to do what to whom". And here I think the distinction
between authorization and authentication has been elided a bit.
Authentication only determines the who. Authorization is about
answering the question of if the request is in fact authorized. A
token could speak only to authentication, but it could also provide
authorization information. The draft is pretty ambivalent about which:
while there is a lean towards authentication it seems the token
issuance is also supposed to be a gating function, and the token
needing to carry more than a simple identifier means that it starts to
blur the line.

Lastly there's a huge gap for me around what sort of policies make
sense. Many systems I've seen and worked with had a broad class of
services provided by various elements, and the users of such services
might be a very dynamic set. Others had a self-serve partitioning of a
class of resources allocated to each service calling in. Other times
we might have systemic policies, e.g. "Infosec says all services must
do X, which we can determine at build time, and those that don't can't
run". Expressing these policies in human understandable form argues
for a simple identifier as a human readable policy depends on such
identifier. I don't think a complex identifier works for that.

In conclusion I think we need to make an explicit choice. Either the
token carries a workload identifier (akin to a Service in K8S or
something else?) or it carries a grab bag of attested environmental
attributes over which policies run. And I think we need to figure out
what policies should be expressable and which shouldn't be.

Sincerely,
Watson Ladd

--
Astra mortemque praestare gradatim

--
Wimse mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>

--
Wimse mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>