I appreciate this conversation. For my part, I think that the RP can set a floor -- this is the minimum acceptable -- but it is ultimately on the CSP to set the threshold, which might be quite higher than what the RP would do.

ID.me users are users we share with the RP. For that reason, we would never allow an MFA setting that an RP might want that would expose our accounts to Account Takeover risk in the context of elevated risk and incentive to an attacker. 

This is a matter of expertise, too. No one knows more about the actual tradeoffs and risk than the CSP because we see legitimate and fraudulent activity across all of the RPs and by use case. 



On Fri, Jul 5, 2024 at 1:47 PM Jimmy Jung <jimmy.jung@slandala.com> wrote:
Thanks Alexei, Taking the larger IAWG out of the loop. Yes, I believe that the 63B supplement is intended to address this; but Kantara is in the position of trying to catch our criteria up to NIST; and it is impacting folks trying to address

Thanks Alexei,

 

Taking the larger IAWG out of the loop.

 

Yes, I believe that the 63B supplement is intended to address this; but Kantara is in the position of trying to catch our criteria up to NIST; and it is impacting folks trying to address the criteria today.  (I think ID.me has some time).

 

My personal view is that relying parties ought to have the flexibility to choose their own level of comfort; regardless of the NIST supplement and the Kantara criteria.  It seems unlikely that a “consumer" oriented RP (e.g., Amazon or Insta) would choose to be more restrictive and not allow synching, but certainly,  if FIDO wants to proliferate, they may well reach RPs that are not comfortable with passkeys synching on to some library workstation browser (e.g., Bank of America or Social Security Administration). 

 

But that is just my personal view, and not germane to the issue at hand - Kantara’s next move.   I think the NIST supplement is a concession to the market.  I assume this hot discussion is happening in the (UAF) Technical Working Group?

 

Jimmy

 

 

 

From: Alexei Czeskis <alexei.czeskis@id.me>
Sent: Friday, July 5, 2024 1:12 PM
To: Jimmy Jung <jimmy.jung@slandala.com>
Cc: Andrew Hughes <andrewhughes3000@gmail.com>; Amanda Gay <amanda@kantarainitiative.org>; wg-idassurance@kantarainitiative.org; Tanel Suurhans <tanel@id.me>; Blake Hall <blake@id.me>
Subject: Re: [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)

 

Hi all!

Definitely very interested in this conversation.  As Blake said, I was a long-time editor for U2F, FIDO2, and WebAuthn -- I love this space!

> 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.
Certain platform vendors have significant reservations about giving RPs this type of control. It's a continuing hot topic of discussion right now in FIDO -- as you can imagine, many RPs want more control.  My personal view is that some of the more "consumer" oriented platforms believe that all non-roaming (non-fob-based) passkeys should be sync'able and that everything else should be managed via MDM.

Yep, the Backup Eligibility and Backup State flags are there in Authenticator Data (so you are supposed to get it back in the response):

 

The 2023 WWDC talk on enterprise management of Passkeys describes what I think is the closest we currently get to having control over passkey creation and sync'ing beyond what's in the spec.


I read the NIST’s 800-63B supplement as accounting for the inability of agencies to control the sync nature on non-managed devices and instead saying that agencies should lean into MDM:

 

Devices (e.g., mobile phones, laptops, tablets) that generate, store, and sync
authenticators containing federal enterprise private keys SHALL be protected by mobile
device management software or other device configuration controls that prevent the
syncing or sharing of keys to unauthorized devices or sync fabrics

 

Is that how you read it as well?

 

Thanks,

-Alexei

 

--

Alexei Czeskis

SVP of Engineering

 

 

On Sun, Jun 30, 2024 at 8:01 PM Blake Hall <blake@id.me> wrote:

Adding Alexei to the discussion. He is one of the FIDO standard authors and might have useful feedback for this group. 

 

On Sat, Jun 29, 2024 at 11:00 PM Jimmy Jung <jimmy.jung@slandala.com> wrote:

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,

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?)

 

_______________________________________________
A Community Group mailing list of KantaraInitiative.org
WG-IDAssurance mailing list -- wg-idassurance@kantarainitiative.org
To unsubscribe send an email to staff@kantarainitiative.org
List archives --  https://urldefense.com/v3/__https://mailman.kantarainitiative.org/hyperkitty/list/wg-idassurance@kantarainitiative.org/__;!!AVdDjg!o4OeETND1XI6_hawcMOpiPnfuUE0UJ2MRI28OrpK6zOpgnKb01iIQmpjh16XrMqHnOod3lgFlfkoN_Ic$
______
Group wiki -- https://urldefense.com/v3/__https://kantara.atlassian.net/wiki/spaces/WG-IDAssurance__;!!AVdDjg!o4OeETND1XI6_hawcMOpiPnfuUE0UJ2MRI28OrpK6zOpgnKb01iIQmpjh16XrMqHnOod3lgFlapns-ql$


 

--

Blake Hall

Founder & CEO

Mobile: 615-293-4702

 

 

 
Veterans Get Secure Single-Sign On for Benefits: http://go.id.me/2iKDM6j
President's National Strategy for Trusted Identities in Cyberspace: http://go.id.me/2hZzUKr
Building the Trust Graph: http://go.id.me/trust-graph

 

 

This message (including any attachments) may contain confidential and privileged information belonging to the sender, for a specific individual and purpose, and is legally privileged. If you are not the intended recipient, you should delete this message and any disclosure, copying, forwarding or distribution of this message, or the taking of any action based on it, by you is strictly prohibited.



--
Blake Hall
Founder & CEO
Mobile: 615-293-4702

 

 
Veterans Get Secure Single-Sign On for Benefits: http://go.id.me/2iKDM6j
President's National Strategy for Trusted Identities in Cyberspace: http://go.id.me/2hZzUKr
Building the Trust Graph: http://go.id.me/trust-graph


This message (including any attachments) may contain confidential and privileged information belonging to the sender, for a specific individual and purpose, and is legally privileged. If you are not the intended recipient, you should delete this message and any disclosure, copying, forwarding or distribution of this message, or the taking of any action based on it, by you is strictly prohibited.