But actually, I was thinking of throwing a stick of dynamite …  =:-o

Richard G. WILSHER
CEO & Founder,  Zygma Inc.
www.Zygma.biz
+1 714 797 9942

From: Jimmy Jung [mailto:jimmy.jung@slandala.com]
Sent: Sunday, June 30, 2024 03:01
To: Andrew Hughes
Cc: Amanda Gay; wg-idassurance@kantarainitiative.org
Subject: [WG-IDAssurance] The CSP SHALL ensure that MF-CS key authenticators DO NOT facilitate the cloning of the secret key onto multiple devices. (RE: Synch-able authenticators)

Perhaps Andrew will appreciate me throwing a completely different log on the fire. 

We briefly discussed what we should do about NISTs synchable authenticator supplement and concluded that it was at least worth waiting got the next 3-4 draft, to see which way the wind is blowing.  That still seems quite reasonable, but I will reiterate that have a few clients that are quite keen to see this leveraged. 

That being said, I did try to dig onto WebAuthn.  I had assumed that we had the ability to prevent the generation of synchable passkeys as they are registered with the CSP, but I’m having a hard time seeing that when I look through the protocol.  I see an ability to NOT ACCEPT synched passkeys on the authentication side, but no way to prevent their creation at registration.  https://webauthn.guide/#webauthn-api

When the user creates their passkey, the server/CSP can ONLY specify if the credential is “Cross-platform” (i.e., removable; e.g.,yubikey) or “platform” (i.e., SW, tied to the device). But you CAN”T specify if it is backup eligible (i.e., synchable).  You CAN ONLY reject that authenticator after it has been created.  So, to prevent synchable authenticators, we would have to ONLY ALLOW user to create and use Yubikeys and other removeable HW authenticators. 

I think that cuts out a large swath of the passkey utility, until synchability is allowed.

Jimmy

AT REGISTRATION, we can specify the authenticator type.  “authenticatorSelection” seems to define the constraints.  HOWEVER, I am very uncertain if this is granular enough to exclude cloneable authenticators.

authenticatorSelection: This optional object helps relying parties make further restrictions on the type of authenticators allowed for registration. In this example we are indicating we want to register a cross-platform authenticator (like a Yubikey) instead of a platform authenticator like Windows Hello or Touch ID. Read the spec.

From the specification (https://w3c.github.io/webauthn/#dom-publickeycredentialcreationoptions-authenticatorselection): “authenticatorSelection, of type AuthenticatorSelectionCriteria The Relying Party (the server/CSP) MAY use this OPTIONAL member to specify capabilities and settings that the authenticator MUST or SHOULD satisfy to participate in the create() operation. See § 5.4.4 Authenticator Selection Criteria (dictionary AuthenticatorSelectionCriteria).

https://w3c.github.io/webauthn/#dictdef-authenticatorselectioncriteria

authenticatorAttachment, of type DOMString

If this member is present, eligible authenticators are filtered to be only those authenticators attached with the specified authenticator attachment modality (see also § 6.2.1 Authenticator Attachment Modality). If this member is absent, then any attachment modality is acceptable. The value SHOULD be a member of AuthenticatorAttachment but client platforms MUST ignore unknown values, treating an unknown value as if the member does not exist.

We refer to authenticators that are part of the client device as platform authenticators, while those that are reachable via cross-platform transport protocols are referred to as roaming authenticators. … The primary use case for platform authenticators is to register a particular client device as a "trusted device", so the client device itself acts as a something you have authentication factor for future authentication. This gives the user the convenience benefit of not needing a roaming authenticator for future authentication ceremonies, e.g., the user will not have to dig around in their pocket for their key fob or phone.  (https://w3c.github.io/webauthn/#sctn-authenticator-attachment-modality)

Looking instead at NIST’s 800-63B supplement, where they discuss synchable authenticators. 

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63Bsup1.pdf

In Table 2. WebAuthn Level 3 flags, they identify:

Backup Eligibility – which Indicates whether the authenticator can be synced to a different device (i.e., whether the key can be stored elsewhere).

AND

Backup State – which Indicates whether an authenticator HAS been synced to a different device.

NIST specifically says that “Federal agencies MAY use this flag if they intend to establish restric�ons on authen�cators that have been synced to other devices. For public facing applica�ons, agencies SHOULD NOT change the acceptance based on this flag due to user experience concerns. For enterprise decisions, this flag MAY be used to support the restric�on of syncable authen�cators for specific applica�ons.” (excuse the pdf to MS cut and paste)

I Don’t know where in the protocol these show up (somewhere in the https://w3c.github.io/webauthn/#authenticator-data).  But this may only allow us to prohibit their use, not control if they are created. 

I would note that NIST only discusses this in terms of a multi-factor authenticator, but I assume they are accepting the premise that passkey is multifactor, even if the “thing-you-have” is your laptop (of public library computer?)