What changes are required? What additional criteria is needed in the existing framework to demonstrate conformity?
Seeking an action to come out of this.
Hughes: Seems that most of the new requirements focus on the federal delivery of authenticators to internal employees/contractors of the agency, with little to no requirements to the user end.
Jimmy: Believes it impacts 63B the most (where we don’t sync/clone). This seems to be aimed at passkeys (if they are allowed from the relying party/tied to a browser). When an individual registers with a site and creates a passkey, the relying party has no ability to constrain the type of passkey created. This is where determining whether to accept syncable/nonsyncable as a relying party should happen.
If a customer/relying party comes to one our our CSPs, and wants a passkey, the following issues occur:
Yes-some are allowed, but some are rejected because they are software passkeys
These are syncable from device to device, and our rules don’t allow that.
Tim Anderson: Sees it not only as applicable to an agency holding AAL2 authenticators, but anyone issuing an AAL2 that want to do passkeys. It seems to specifically invalidate the current 63B language on cloning and makes it the new normative language in Section 4. Doesn’t this need reconciliation?
Hughes: Does this only apply to agencies? (Wilsher)--Likely not, as there are a lot of services that support federal agencies and are driven by private organizations.
Wilsher: Concerned about 63B #0422 (unlocking a device is not an authentication factor)--the supplement doesn’t explicitly invalidate this if using a passkey. But Richard understands it as using a passkey to unlock, the device is going to enable passkey functions. Section: 5.1.8.1-Explicit statement referencing this, with a paragraph on page 4–(set of bullets for general requirements for all uses of syncable authenticators), so surely new criteria would be needed to match these explicitly normative statements?Unsure how to apply these, and which of existing criteria would be overruled.
Hughes: Bullet 2 - how fast do syncable passkeys work? For a CSP that issues AAL2 authenticators-how can they control this? How does the CSP prevent the user from exporting into encrypted/non-encrypted form? How do we evaluate?
Jimmy: Fido passkeys--Fido standard enforces the encryption
Who controls the passkey? End user device or CSP? End user/device (Jimmy/Mike M) Key is stored on device and cloned to the cloud
So to evaluate, we’d have to determine if the device has implemented Fido protocols correctly.
Wilsher: Page 3, table 1 (Required threat miitgations from SP 800-63-3-Table 4.1) “man in the middle” achieved properly configured syncable authenticators. What is this?
There’s got to be some way of saying that the authenticator is being managed properly because of conformance to an established standard (ie Fido) for passkeys. How else do we know it is properly configured? Is there an evaluation process?
Yehoshua: You could only clone the keys if certain requirements are met. So in what way can we assess whether they meet these requirements?
If we say you can clone private keys because you’ve done ABCD and E (essentially compensating controls from this supplement), how would we assess these controls? How can we give ourselves confidence that this will actually work?
Wilsher: 1. Can we determine which of our criteria is moot because of this supplement, and what criteria should be put in place? 2. What degree of confidence can we have that an implementation is “properly configured”? This is depend on how a particular syncable authenticator is implemented and validated.
Nathan: Can the auditors come up with test cases/use cases and use these in evaluations?
Wilsher: seems reasonable, however, who would do that? 2 potential problems-Kantara tries to be technology agnostic, so we don’t want to get into that zone. 2. We’d have to be open to other forms of syncable authenticators (other than passkeys) which should be treated similarly.
Nathan: Concurs, notes that the use/test cases would be editable. Could something be developed by assessors and presented to IAWG? Then it could be used in audits with the analysis/results.
Hughes: Should we get someone to come present to the group RE: passkeys for clarity around how a CSP would have any control over how passkeys exist/get accepted/rejected and whether this is in/out of Kantara’s scope (should we make criteria changes and is this assessable by Kantara assessors)?
Mike M: Dean Sachs from Amazon and Tim Capelli (Octa, formerly of Microsoft)
Tim: Alexi (Google/Fido)
Jimmy: Are we assuming this will track with rev. 4, so at some point we will have to address it? Most likely, yes. A response will be needed, as customers will be wanting answers.
Richard: We need understanding of the mechanisms first, and with the time needed to review/draft criteria, it may make sense to wait till rev 4’s draft is released.
Hughes: The next second public draft could be released for input, but with constraints on questions (they may not be accepting commentary on the material in this supplement)
Jimmy: Another approach to 63B #1150: would be is they are using Fido, you are allowed to clone for multi and single factor (passkeys)