Dear IAWG members,
I know we will meet this week to learn more about FIDO and passkeys and consider how to address the 63B supplement
in our criteria. We have discussed reviewing the next 63-4 draft as part of our thinking, but the NIST 63-4 draft missed the rumored July release. We can be certain that NIST released the supplement recognizing the market and in an attempt to be agile. I
think it behooves us to attempt to be similarly responsive. And, among almost all the organizations I am working with passkeys are desired, if not imperative. I believe we need to take two steps:
-
Quickly roll the supplement into the 63-3 criteria. No doubt we will have better perspective if we have the 63-4 draft, but the supplement will still be the 63-3 criteria and if “classic” is any
example, it will stay in play for a while.
-
I also believe FIDO got it wrong, that not allowing a relying party to prevent cloneable keys; to control their own security, is an imprudent selection of “easy” over secure. Kantara, as a digital
identity collaborative should formally take a position against this implementation. I don’t mind cloning, but I do mind not allowing a site to disallow cloning as part of THEIR policy (I mean, come on; initially it violated NIST policy) – of course this is
all predicated on my understanding the FIDO implementation; something I hope to nail down Thursday. (In looking at this more, I’m getting a sense of the difficulty of this, but I am still convinced it is the right thing to do)
Based on that sense of urgency, I took a first pass at rolling in the supplement (attached). It is fairly straight
forward but asks a few questions. One over-arching question; the supplement makes reference to “properly configured syncable authenticators,” and it seems to imply that FIDO/WebAuth is OK; but I have assumed that the actual SHALL statements they gave us ARE
the “proper configuration” they are looking for.
For those of you who saw an earlier draft of the criteria, they have been tweaked, based on some suggestions from
Richard Wilshire. In that time, I also came up with a few other questions that will no doubt take us down some rabbit holes.
The NIST supplement ONLY addresses Multifactor Cryptographic Software MF-CS Authenticators, not Single-Factor Cryptographic
Software Authenticators; and we can assume that NIST has accepted the argument that passkeys are multifactor. But they are only multifactor to the extent that you can consider the device (e.g., workstation or laptop) “something you have.” I’m having to rewire
some paradigms to think of my laptop as an authentication token; but if NIST is good with it, I guess I can manage. But if passkeys are Multifactor Cryptographic Software Authenticators then “syncability” is not the only obstacle they have to deal with.
The rest of the 63B MF-CS criteria includes rules for the activation data and biometrics (63B 5.1.8 and Kantara criteria 63B#1250 - 63B#1330).
Multifactor Cryptographic Software Authenticators require either a randomly generated 6 digit OR an 8 character activation
secret to activate (see below). Can passkeys do either of these? The CSP/relying party has no way to generate a secret for the user and no control over the length of the user generated secret. As best I can tell, I can lower my passkey to four digits and
the CSP has no way to know or enforce the length of my passkey activation PIN . Also, the multifactor criteria requires the CSP to zeroize the unencrypted activation secret or biometric sample after authentication AND enforce biometric criteria – and the
CSP has no control over that; although maybe by requiring FIDO, that is being met. In general, 63B and our criteria assign a number of items to the CSP, that in passkeys are managed locally. Some of them are perhaps inherited from the FIDO implementation,
but I’m cautious about the CSPs ability to control the activation secrets, the rate-limiting, biometric Failed Match Rates or any of the biometric implementation.
-
63B#1290 - The CSP SHALL ensure that memorized secrets used by the authenticator for activation are a randomly-chosen numeric value at least 6 decimal digits in length
or other memorized secret meeting the requirements of the applicable criteria 63B#0410 - '0460.
-
63B#0410 - The CSP SHALL require memorized secrets chosen by the Subject to be at least 8 characters in length.
-
63B#0420 - The CSP SHALL require memorized secrets generated by itself or a Verifier to be at least 6 characters in length and randomly-generated.
-
63B#0430 - If the CSP [or Verifier] determines that a chosen memorized secret appears on a list of compromised values it SHALL require the Subject to choose a different memorized secret.
-
63B#0410 - The CSP SHALL require memorized secrets chosen by the Subject to be at least 8 characters in length.
-
63B#1300 - The CSP SHALL enforce a rate-limiting mechanism iaw 63B#1450 & '1460 (without qualification regarding the degree of entropy which the memorized secret exhibits).
-
63B#1310 - If a biometric factor is used in an authentication the CSP SHALL ensure that all criteria 63B#1470 - '1550 are fulfilled.
-
63B#1320 - The CSP SHALL zeroize the unencrypted secret key and the activation secret or biometric sample (including any associated biometric data) immediately after an authentication transaction
has taken place.
To some extent I’m wondering if passkeys work under 800-63, even with the NIST supplement.
Jimmy
PS – There are 4 requirements for a Single-Factor Cryptographic Software Authenticator. Those same 4 requirements
also apply to Multifactor-Factor Cryptographic Software Authenticators, plus another 6 all relating to the second factor (e.g., biometrics, activation secret). Am I allowed to declare my MF-CS a SF-CS and just ignore those 6 requirements?
😊
|
|
Jimmy Jung 703 851 6813 |
Jimmy
From: Amanda Gay <amanda@kantarainitiative.org>
Sent: Tuesday, August 6, 2024 7:30 AM
To: wg-idassurance@kantarainitiative.org
Cc: tim.cappalli@okta.com; dean.saxe@beyondidentity.com; alexei.czeskis@id.me; tanel@id.me
Subject: [WG-IDAssurance] Agenda and Invitation - IAWG - August 08, 2025
Dear IAWG Members:
Please join us this Thursday, at 12 Noon ET for the next IAWG meeting.
The proposed agenda and Zoom details are below. Please also keep an eye out for an email from Jimmy containing a first attempt at rolling the supplement into Kantara criteria!
Date and Time
·
Date: Thursday, 2024-08-08
·
Time: 9:00 PT | 12:00 ET (time
zone calculator)
o
Please join the meeting from your computer, tablet or smartphone: https://zoom.us/j/93167965850?pwd=dldoT0hYK1k4MkVGYkQ3TkNqdG1Idz09
o
Meeting ID: 931 6796 5850
o
Passcode: 884696
o
You can also dial in using your phone. Find your local number: https://zoom.us/u/aeg9vt8LSr
o
Need to add IAWG meetings to your calendar? Do so here!
DRAFT 08.08.2024
-
Administration:
o
Roll call, determination of quorum.
o
Minutes approval
§
Jimmy moves for unanimous, seconded by Hughes. Motion passes.
o
Kantara Updates
o
Assurance Updates
2.
IAWG Actions/Reminders/Updates:
-
Proposed Meeting Cadence for June/Extended Summer*
-
August 8 (Passkey Presentations), August 22
-
*If rev.4 is released, this cadence will be updated
3.
ISO 17065 Discussion Items
4.
Group Discussion:
-
Passkey Presentations
-
Tim Capalli, Okta
-
Dean Saxe, Beyond Identity
-
Alexei Czeskis, ID.me
5.
Any Other Business
--
Amanda Gay | Administrative Coordinator
Twitter: @KantaraNews
LinkedIn: @KantaraInitiative