[Wimse] Re: Request for Agenda Item: Workload identity authenticator levels

[Pieter Kasselman <[e-mail]>]

Thanks Dean

Those are some great point to discuss - levels of granularity, additional metadata and time variance of authentication strength. I want to add another dimension, and that is ease of adoption.

Granularity: In terms of the granularity, I wonder if more precision would actually help, and whether it makes adoption harder. The more granularity, the more choices, the more sophisticated the person deploying the system needs to be. Course grained categorie may be very useful in simplifying decision making, but we may want a lot of fine grained information about the actual mechanisms used.

Additional Metadata: The additional metadata that may be interesting, not so much at deployment time, but at runtime. Knowing the details of the authentication mechanism may be used by identity threat and detection systems, provide richer audit information and provide additional context to evaluate runtime risk.

Time variance: I think we have examples of how other long-established standards try to represent this (for better or worse) . For example there is a ISO 9001, ISO 9001:2015, ISO 9001:2024 and so on. Perhaps the naming convention should include a reference to the data, maybe not only at the spec level, but perhaps even as part of describing the authentication level (e.g. AAL2:2024). I think this is a generally hard problem though as most security properties tend to erode over time (you could argue all of the post-quantum crypto work is a version of this). I do think we want some sort of scheme that is extensible and easily recognisable.

Adoption: When I think about adoption, I thinkabout the “expertise elsewhere” case. We need to make the decision of what to use easy for the non-expert. This is where coarse granularity is really helpful – if I understand that there are 3-5 classes, their distinguishing characteristics, and that each successive class is a superset of the previous classes, it creates a simple mental model – I need these characteristics, it maps to this class, it means I get all the security characteristics of the preceding classes. Suppliers can then create multiple implementations that meets the characteristics, and the details of those implementations (what kind of crypto is used, when was it used, how is it recovered etc), can then be logged at runtime where management systems can interpret and apply more fine grained risk rules (e.g. a authentication level may be met, but then a vulnerability is discovered, and a specific subset of implementations may be flagged for extra scrutiny).

The good news is, there is some lessons we can draw on from user authentication. Let’s see if it can be extended to workloads.

Cheers

Pieter

From: Saxe, Dean <deansaxe=[e-mail]>
Sent: Monday, July 8, 2024 9:23 PM
To: Pieter Kasselman <[e-mail]>; [e-mail]
Subject: Re: [Wimse] Request for Agenda Item: Workload identity authenticator levels

Pieter,

With my work at the FIDO Alliance, I’ve been considering this topic quite a lot recently.  My sense is that authenticator levels as defined by NIST are a useful construct.  But over time, I fear that they lose value because a credential at Level 3 today might only meet Level 2 tomorrow.  The levels are large-grained and don’t sufficiently describe the full context of an authentication event.

Recently I have started talking with others about the idea of describing the properties of the authentication event.  Pam Dingle had two talks at Identiverse this year where she discussed this concept to include not only information about the authenticator, but also information about the account recovery process, what the activation factor was, etc.  These discussions have lead me back to read the Vectors of Trust (VoT) RFC 8485 (https://datatracker.ietf.org/doc/html/rfc8485)  Although I haven’t yet pursued anything down this path, I think the VoT mechanism is well suited to describe the authentication event as a set of vectors which can be parsed to determine the suitability of the event to authorize the workload (or human).

I’m absolutely interested in helping pursue standardization in this realm.  Please let me know how I can help.

-dhs

--
Dean H. Saxe, CIDPRO<https://idpro.org/cidpro/> (he/him)
Senior Security Engineer, AWS Identity Security Team | Amazon Web Services (AWS)
E: [e-mail]<mailto:[e-mail]> | M: 206-659-7293<tel:[phone]>

From: Pieter Kasselman <pieter.kasselman=[e-mail]<mailto:pieter.kasselman=[e-mail]>>
Date: Monday, July 8, 2024 at 8:06 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] [Wimse] Request for Agenda Item: Workload identity authenticator levels


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

WIMSE co-chair hat off, identity enthusiast hat on.

Hi folks,

For user authentication, the industry has well established concepts around different levels of user authentication. For example NIST Special Publication 800-63-3 defines Authenticator Assurance Levels [1]. This raises the question of whether we (workload identity practitioners) would benefit from a similar set of definitions for workload identities.

Consequently, I would like to request a short 10 minutes slot on the agenda at IETF 120 to discuss this topic, see if there are existing work we can leverage and see if there is interest in pursuing establishing some form of Workload Identity Authentication Levels.

Cheers

Pieter

[1] https://pages.nist.gov/800-63-3/sp800-63-3.html