Consider allowing RPs to indicate that they want platform authenticators to be synced across devices

[leshi]

Some RPs may want to allow key material associated with platform authenticators to be synched across devices.

For example, this might allow a user who sign into their browser or OS to automatically have all their platform authenticators available in the new browser session.

I believe that for this to be a feature, RPs must explicitly indicate that they want this. We should also consider adding some kind of additional platform binding such that it's clear when the user comes from a new machine (though cookies might be enough for this).

[emlun]

Wouldn't that void most of the point of putting private keys on a secure element (that it's "impossible" to get them back out)? What problem would this solve that is not solved as well (or better) by simply registering the individual devices?

[Kieun]

This is somewhat similar to iOS keychain feature. Is it allowed to extract keys from one device and migrate to other devices in terms of FIDO and WebAuth?

[equalsJeffH]

IIUC, this issue is only in regards to providing a means for an RP webapp to signal that from the RP's perspective it is permissible for the user's public key credential source(s) (for that RP) to be "sync'd" to another device. Yes?

If so, the actual means of such "synchronizing", and whether it exists or not, is separate (see isssue #931. Tho this issue anticipates its existence.

See also: Recovering from lost devices in WebAuthn
and https://lists.w3.org/Archives/Public/public-webauthn/2018Apr/0009.html

[rlin1]

The ability of an authenticator to export keys (e.g. to an different authenticator instance of either (1) the same model or (2) different model with at least the same authenticator security level or (3) a different model with any authenticator security level) has major impact on the ability of the relying party to understand how good the keys are protected and how the user is verified. Meaning in scenario (3) the user could potentially "migrate" keys from a TEE based authenticator using fingerprint user verification to a Rich-OS based authenticator with user presence check only. While the former would be considered strong enough for providing strong customer authentication according to PSD2, the latter wouldn't (and hence would need another factor).
Under scenario (3) it might also be possible to get access to the private key material in the clear which could open up other attack vectors (e.g. asking the user to enter the private key into a malicious app that is asking for the backup claiming the original was lost).

Scenario (1) is typically supported by HSMs these days. It typically requires some cryptographic effort and sometimes even an admin type role to ensure that only this type of key migration works.

[rlin1]

I would recommend pairing such a flag (if we should end up supporting it) with the ability of an authenticator to express support for non-exportable/non-migratable keys in the attestation statement (e.g. similar to never exportable flag in PKCS#11 - but with crptographic assertion on it).
With that RPs interested in the security aspect have an assertion stating whether or not the key is exportable.

[ptoomey3]

I'm not incredibly familiar with the details of the webauthn specification, but am fairly familiar with the general flow given we support U2F today. I just wanted to leave a short comment from an outsider's perspective, given a few of us chatting with @leshi on Twitter resulted in this issue being opened: https://twitter.com/aczeskis/status/1011302905872297984.

From an implementors perspective (i.e. if/when we add support for webauthn), we would have no interest in mandating a hardware backed token. Let's look at where we are starting (just to summarize the obvious):

• Username/password - Passwords are reused, not well chosen, accidentally logged by some backend server, insecurely hashed, ... (we all know the issue with passwords).
• SMS TOTP 2FA - This has by far the best UX experience for users. But, sadly, we have seen this approach devolves into carrier based security 😬.
• App TOTP 2FA - People install the secret on a singular device and eventually either lose the device, wipe an old device without realizing the TOTP secret is not backed up, etc. Moreover, it requires the RP to store the TOTP secret server-side for validation.
• Backup codes - We all know this was a punt, as we had nothing better to offer folks. Lots of folks lose these as they sit in a downloads folder and are eventually deleted.

In short, all of the above have lots of issues that eventually lead to users getting compromised and/or locked out of their accounts. Many sites are in a tough spot trying to strike the right balance between account security and usability (i.e. hoping a legitimate user doesn't get locked out of their own account). I don't deny there is value in a HSM style authenticator for some people and/or specific use cases. But, for the vast majority of users and sites, an API driven exportable webauthn key pair that can be synced using their platform of choice (iCloud Keychain, Google account (ala password syncing today), etc) would be a huge ^ 💯 step forward.

Some folks have suggested existing synced password manager based systems are sufficient for this use case. Sure, it is "sufficient". But, once we have a programatic API between a browser and RP, why would anyone want to use passwords anymore? Key pairs are meaningfully better across all axes for this kind of thing. Even if a password is randomly generated and unique per-site, it still is far more probable to leak sensitive information in various logs, be stored insecurely, etc.

I would recommend pairing such a flag (if we should end up supporting it) with the ability of an authenticator to express support for non-exportable/non-migratable keys in the attestation statement

I'm not super clear on the implementation details, but some notion of attestation sounds ideal. If a RP actually wants to require per-device tokens they can. I can imagine some sites might even have a use case for this based on administrative settings (ex. a google apps account admin that can choose whether their organization wants to require per-device tokens or not).

As an aside, what would happen today if a browser implemented a "soft token"? In other words, if Apple released a version of Safari tomorrow that implemented this full flow purely in software and stored the key pair in iCloud keychain, would that violate something in terms of compliance, certification, ....?

[emlun]

Thanks @ptoomey3! I agree that (almost) anything that simply moves people away from passwords is a good thing. That said, I don't think it's necessary that the RP can indicate it allows credentials to be portable and/or synced. Like you say...

if Apple released a version of Safari tomorrow that implemented this full flow purely in software and stored the key pair in iCloud keychain, would that violate something in terms of compliance, certification, ....?

I wouldn't say that would violate the spec in any way, but it would indeed not be eligible for many certifications. It also probably wouldn't be able to produce a meaningful attestation statement, since a software authenticator (without cooperation from the OS) can do very little to protect an attestation key. That said, none of that matters as long as the RP accepts the (possibly empty) attestation statement - so in a way, RPs can already opt in to allowing syncable credentials by accepting credentials from authenticators that do not promise to not do that. Actually, it's rather something they need to opt out of, since the RP by default will not ask for attestation.

Adding a standardised way to express features like that in attestation certificates sounds reasonable, but perhaps in the scope of a certification authority rather than the core WebAuthn spec? (I'm thinking a list of such feature indicators would likely grow over time)

[ptoomey3]

Actually, it's rather something they need to opt out of, since the RP by default will not ask for attestation.

This was my thought as well. It feels like the cases where a RP would require an attestation might be the exception and not the rule. So, a default of no attestation would imply that the RP assumes nothing about the authenticator (which is probably fine for the vast majority of RPs). And, if they do want to have restrictions, the RP looks for an attestation from an authenticator capable of that.

[equalsJeffH]

@ptoomey3

It feels like the cases where a RP would require an attestation might be the exception and not the rule. So, a default of no attestation would imply that the RP assumes nothing about the authenticator (which is probably fine for the vast majority of RPs). And, if they do want to have restrictions, the RP looks for an attestation from an authenticator capable of that.

Yes, that is how the spec is written. See https://www.w3.org/TR/webauthn/#ref-for-enumdef-attestationconveyancepreference and https://www.w3.org/TR/webauthn/#enumdef-attestationconveyancepreference.

thanks for linking to the twitter thread behind @leshi (aka @aczeskis on twit)'s orig post.

@rlin1 -- your comment wrt key migration/export #969 (comment) perhaps is more appropriate for issue #931 ?

[ptoomey3]

Yes, that is how the spec is written. See https://www.w3.org/TR/webauthn/#ref-for-enumdef-attestationconveyancepreference and https://www.w3.org/TR/webauthn/#enumdef-attestationconveyancepreference.

Gotcha. So, read another way, does the existing AttestationConveyancePreference roughly accomplish what is being discussed in this thread? If a RP wants to allow syncing, they give a attestation preference of none and if they don't, they specify direct. It isn't exactly the same thing. But, maybe for all intents and purposes it is unless #931 outlines some means of backing up a attestation capable authenticator to another attestation capable authenticator.

[emlun]

In practice, yes. There's no API for expressing this particular preference, but the only way for the RP to enforce - or even know - anything about how the authenticator operates is to require and verify a trusted attestation statement (with the assumption that trusted authenticators do behave as promised by their certificate/vendor/whatever). If the RP does not verify or ask for attestation (which it won't by default, since attestationConveyance defaults to "none"), then the authenticator can in practice do whatever it wants.

[nadalin]

@leshi Out of scope for the current version, moving to next level

[rlin1]

Regarding: @rlin1 -- your comment wrt key migration/export #969 (comment) perhaps is more appropriate for issue #931 ?
If this issue is NOT about synchronizing private key material, we should make that very explicit here. I think it currently is not clear what kind of information is expected to the synchronized here.

[emlun]

Since PR #1226 added this (emphasis added):

The credential private key is bound to a particular authenticator - its managing authenticator - and is expected to never be exposed to any other party, not even to the owner of the authenticator.

I suggest we close this issue since the proposal here conflicts with the above.

[equalsJeffH]

Well, the above language can be altered. Since we are still figuring out account recovery/device loss/new device(s), I'm inclined to keep it open.

[Jamesernator]

Would it be possible to have some form of derived key that can be synced to trusted devices while still retaining the authority of the original key but doesn't carry its attestation?

e.g. A flow would look something like this:

• User on DeviceA enables sync to DeviceB, user gives authority to sync to DeviceB
• For each key to sync
  • DeviceA creates a derived key and encrypts it using DeviceB's public key
  • Some service transfers the encrypted derived key to DeviceB
  • DeviceB decrypts the derived key and adds it to its list of keys
• Upon user attempting to login from DeviceB
  • If attestation is required then prompt for attestation from this new device
  • Else proceed with login silently as per normal

[emlun]

@Jamesernator That sounds similar to our recovery extension proposal: https://gist.github.com/emlun/4c3efd99a727c7037fdb86ffd43c020d

[agl]

From call of 2021-03-03: we believe this has been superseded by issues such as #1546