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

[Justin Richer <[e-mail]>]

Chair hat also off.

One of the important things to note about the xAL measurements and AAL in particular is that it's a measurement on the process. You can have an authenticator that's capable of AAL2 but the rest of the process also needs to fit requirements, like how the authenticator is bound to the account and how the session gets managed. I think if we saw something for machine identity we'd see something similar here.


The other thing about xAL is that it defines a floor for compliance. In other words, you can have something match AAL2 that actually exceeds it greatly on some aspect. The xALs aren't meant to give you the full picture, just the statement that it's at least as good as the defined baseline. For most cases this is pretty useful, and it's why LoA still gets used in a bunch of places - think of LoA like a pre defined combination of xALs.

If you want more detail than that, this is exactly where VoT is meant to slot in. You can say "this is AAL2 but also it's a non exportable key". The first part gives you a solid baseline that's good enough for many decisions, the second part adds detail that might make a difference to an app. Because maybe you don't need all the requirements at AAL3 but you we really keen on one aspect. People constantly ask for things like "AAL2.5" and completely miss the point of the xALs in the first place.

Different use cases are going to require different granularity. I think different scales are going to be useful in defining interoperable values. I may be biased but I still think that VoT is a solid idea that can be used to communicate both coarse and fine grained details about a system. Is there something we can do with it in WIMSE? I think that remains to be figured out.

- Justin
________________________________
From: Saxe, Dean <deansaxe=[e-mail]>
Sent: Monday, July 8, 2024 4:23 PM
To: Pieter Kasselman <pieter.kasselman=[e-mail]>; [e-mail] <[e-mail]>
Subject: [Wimse] Re: 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]>
Date: Monday, July 8, 2024 at 8:06 AM
To: "[e-mail]" <[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