Webinar: NIST SP 800-63 Digital Identity Standard: Updates & What it Means for Passkeys.pptx

The fourth revision of the draft NIST SP 800-63-4 Digital Identity Guidelines is now open for public comment.

The FIDO Alliance hosted a webinar on September 24, 2024, with top digital identity experts to discuss the latest updates to the standard and what they mean for passkeys.

Megan Shamas, CMO of the FIDO Alliance, was joined by guests Ryan Galluzzo, Digital Identity Program lead of NIST NCCOE, Teresa Wu, co-chair of the FIDO Alliance Government Deployment Working Group and VP of Smart Credentials at IDEMIA. The panel unpacked the latest changes to the draft and shared what it means for passkeys.

Webinar attendees also had an opportunity to get questions answered before the public comment submission deadline next month. NIST requests that all comments be submitted by 11:59 pm Eastern Time on October 7, 2024.

1. Digital Identity Supplement – Syncable Authenticators May 2024 Ryan Galluzzo Applied Cybersecurity Division Information Technology Lab

2. Ryan Galluzzo Digital Identity Program Lead, Applied Cybersecurity Division  NIST Teresa Wu VP, Smart Credentials IDEMIA & Co-Chair, Government Deployment Working Group FIDO Alliance Megan Shamas Chief Marketing Officer FIDO Alliance

3. Agenda The Supplement v. The Guidelines What is a syncable authenticator? Why now? What Assurance Level are Syncable Authenticators? General requirements & Enterprise Requirements for AAL2 But what about sharing & Attestation? Questions? 3

4. The Supplement & the Guidelines This specific doc provides interim guidance for the use of syncable authenticators We released this to fill an immediate gap between NIST SP 800-63-3 and 800-63-4 It is effective now 4 The second public draft of NIST SP 800-63-4 Integrates the content from the supplement almost exactly Open for comments and changes based on input from community The Supplement The Digital Identity Guidelines

5. What is a syncable authenticator? Syncable Authenticator : Software or hardware cryptographic authenticators that allow authentication keys to be cloned and exported to other storage in order to sync those keys to other authenticators (i.e., devices). Sync Fabric: Any on-premises, cloud-based, or hybrid service used to store, transmit, or manage authentication keys generated by syncable authenticators that are not local to the user’s device. 5 Syncable Passkeys (or multi-device?) are an example of Syncable Authenticators

6. Why Now? Top 5 Reasons Why: Phishing resistance for the masses! Who uses one device now? Starting to scale and seeing broad adoption (available to est. 1 Billion plus at Google alone) Agencies asked “can I use these things?” and “what AAL are they?” The standards have matured substantially (thought there is still work to be done) We wanted agencies to be able to evaluate syncable authenticators as a viable option alongside other AAL2 authenticators such as SMS OTP, OTP Apps, and push authentication. But… Our guidance excluded the “cloning” of authentication keys – a necessary characteristic of syncable authenticators 6

7. Syncable Authenticators can achieve AAL2 Syncable authenticators, when implemented consistent with the supplement, provide comparable and often superior protection to other AAL2 authenticators Phishing Resistant Replay Resistant Multi-factor Authentication Intent Since AAL3 still prohibits export of keys, the maximum achievable AAL for syncable authenticators is AAL2 7

8. General Requirements to Support AAL2 Syncable authenticator SHALL make use of a local authentication event to unlock the locally stored key or SHALL be used with another authenticator (e.g., a user-selected password) if no local authentication mechanism is available. All keys SHALL be generated using approved cryptography.  Private keys that are cloned or exported from a device SHALL be stored only in an encrypted form. All authentication transactions SHALL perform private-key operations on the local device using cryptographic keys that were generated on-device or recovered from the sync fabric (e.g., in cloud storage). 8

9. General Requirements to Support AAL2 (Cont) Private keys stored in cloud-based accounts SHALL be protected by access control mechanisms such that only the authenticated user can access their private keys in the sync fabric. User access to private keys in the sync fabric SHALL be protected by AAL2- equivalent MFA to preserve the integrity of the authentication protocols using the synced keys. These general requirements and any other agency-specific requirements for the use of syncable authenticators SHALL be documented and communicated, including on public-facing websites and digital service policies, where applicable. Attestations SHOULD NOT be used for broad public-facing applications. [Minor Changes in 2PD] 9

10. Federal Enterprise AAL2 Requirements Federal enterprise private keys SHALL be stored in sync fabrics that have achieved FISMA Moderate protections or comparable. Devices that generate, store, and sync authenticators containing federal enterprise private keys SHALL be protected by MDM software or other device configuration controls that prevent the syncing of keys to unauthorized devices or sync fabrics. Access to the sync fabric SHALL be controlled by agency-managed accounts to maintain enterprise control over the life cycle of the private key. Authenticators that generate private keys SHOULD support attestation features that can be used to verify the capabilities and source of the authenticator. These requirements are additive to AAL2 and all other requirements apply, including FIPS 140 validation 10

11. Implementation Requirements Many syncable authenticators are built upon W3C’s WebAuthn specification, wher e they are the following applies: Not all deployments of WebAuthn credentials and syncable authenticators will meet the requirements of federal agencies User Present (UP)  Verifiers SHOULD confirm that the User Present flag has been set. User Verified (UV)  Verifiers SHALL indicate that UV is preferred, and SHALL inspect responses to confirm the value of the UV flag. If the user is not verified, agencies SHALL treat the authenticator as a single-factor. Backup Eligible  Verifiers MAY use this flag if they intend to establish policies that restrict the use of syncable authenticators. Backup State  Verifiers MAY use this flag if they intend to establish restrictions on authenticators that have been synced to other devices. For public-facing applications, agencies SHOULD NOT condition acceptance based on this flag. For enterprise applications, this flag MAY be used to support the restriction of syncable authenticators. 11

12. What about Sharing? Many implementers of syncable authenticators are promoting their ability to be shared between different users. While this is a security concern, consider… For enterprise applications, the threat of sharing can be mitigated through managed accounts and devices, though the same is not available for the public Any authenticator can be shared by users at nearly all assurance levels, consider the security key left in the family laptop… Despite the change in security paradigm that syncable authenticators introduce it does not substantially shift the threat model comparted to other AAL2 authenticators Syncable authenticators provide phishing resistance and eased recovery in a familiar, scalable, and convenient model with many benefits over AAL2 options (e.g., SMS OTP) 12

13. What about Attestation? Attestations can provide insight into the origin and security features of a syncable authenticator, but are not widely available for public facing applications This does not mean agencies should avoid synced authenticators, it does mean they need to understand the risks associated with unattested implementation These are similar to most other risks associated with external, user provided authenticators (e.g., key length on TOTP authenticator apps, account security on SMS OTP, pin lengths) It is NISTs view that most platform providers and pluggable passkey providers are aligned to the requirements and doing the right thing The syncable authenticator threat surface is preferable to many other AAL2 authenticators Attestation should not be a blocker to offering scaled phishing resistance for public users of government services If agencies remain uncomfortable with limited attestation, implement compensating controls (e.g., another factor) – though for most AAL2 use cases this seems unnecessary 13

14. Key Take-aways 14