Syncable Authenticators

This appendix is normative.

Introduction

The ability to “sync” authenticators — specifically to copy (i.e., clone) their authentication secrets to the cloud and thence to additional authenticators — is a relatively new development in authentication. This appendix provides additional guidelines on the use of syncable authenticators.

Cloning Authentication Keys

In some cases, authentication keys may be stored in a sync fabric (e.g., cloud storage). This allows the keys to be backed up and transferred to other devices. The following requirements apply to keys that are managed in this manner:

All keys SHALL be generated using approved cryptography.
Authentication keys that are cloned or exported from a device to a sync fabric SHALL only be stored in an encrypted form using a key with the minimum security strength specified in the latest revision of [SP800-131A] (i.e., 112 bits as of the date of this publication). These keys SHOULD be encrypted using a method that employs a user-controlled secret.
All authentication transactions SHALL perform private-key operations on the local device using cryptographic keys that are generated on-device or recovered from the sync fabric.
Authentication keys stored in the sync fabric SHALL be protected by access control mechanisms such that only the authenticated user can access their authentication keys in the sync fabric.
User access to authentication 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 using syncable authenticators SHALL be documented and communicated, including on public-facing websites and digital service policies, where applicable.
Authenticators that enable the use of syncable authentication keys SHOULD provide a user interface (UI) that allows subscribers to view the services for which they have created a syncable authentication key, whether that key has been synced, and where that key has been synced. The UI SHALL NOT expose the authentication key itself.

The following additional requirements apply to federal enterprise¹ use of syncable authenticators:

Federal enterprise authentication keys SHALL be stored in sync fabrics that have achieved Federal Information Security Modernization Act (FISMA) [FISMA] moderate protections or equivalent.
Devices (e.g., mobile phones, laptops, tablets) that generate, store, and sync authenticators containing federal enterprise authentication 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.
Access to the sync fabric SHALL be controlled by agency-managed accounts (e.g., a central identity and access management solution, platform-based managed account) to maintain federal enterprise control over the authentication key’s life cycle.
Authenticators that generate authentication keys SHOULD support attestation features that can be used to verify the capabilities and sources of the authenticator (e.g., enterprise attestation).

These controls specifically support syncing and should be considered additive to the existing multi-factor cryptographic authenticator requirements and AAL2 requirements, including [FIPS140] validation.

Syncing authentication keys inherently means that the key can be exported. Authentication at AAL2 may be supported subject to the above requirements. However, syncing violates the non-exportability requirements of AAL3. Similar protocols using keys not stored in an exportable manner that meet the other requirements of AAL3 may be used.

Implementation Requirements

Many syncable authenticators are built on W3C’s [WebAuthn] specification, which provides a common data structure, a challenge-response cryptographic protocol, and an API for leveraging public-key credentials. The specification is flexible and adaptive, meaning that not all deployments of WebAuthn credentials will meet the requirements of federal agencies for implementation.

The specification has a series of flags that the RP application can request from the authenticator to provide additional context for the authentication event and determine whether it meets the RP’s access policies. This section describes certain flags in the WebAuthn specification that federal agencies acting as RPs should understand and interrogate when building their syncable authenticator implementations to align with AAL2 guidelines.

The following requirements apply to WebAuthn Level 3 flags:

User Present (UP): The User Present flag indicates that a “presence” test confirmed that the user has interacted with the authenticator (e.g., tapping a hardware token inserted into a USB port). This supports authentication intent, as described in Sec. 3.2.8. Verifiers SHOULD confirm that the User Present flag has been set.
User Verified (UV): The User Verified flag indicates that the authenticator has locally authenticated the user using one of the available “user verification” methods. Verifiers SHALL indicate that UV is preferred and SHALL inspect responses to confirm the value of the UV flag. This indicates whether the authenticator can be treated as a multi-factor cryptographic authenticator. If the user is not verified, agencies SHALL treat the authenticator as a single-factor cryptographic authenticator. A further extension to the WebAuthn Level 3 specification (see Sec. 10.3 of [WebAuthn]) provides additional data on verification methods if agencies seek to gain context on the local authentication event.
Backup Eligible: The Backup Eligible flag indicates whether the authenticator can be synced to a different device (i.e., whether the key can be stored elsewhere). It is important to note that just because an authenticator can be synced does not mean that it has been synced. Verifiers MAY use this flag to establish policies that restrict the use of syncable authenticators. This flag is necessary to distinguish authenticators that are device-bound from those that may be cloned to more than one device.
Backup State: The Backup State flag indicates whether an authenticator has been synced to a different device. Verifiers MAY use this flag to establish restrictions on authenticators that are synced to other devices. Agencies SHOULD NOT condition acceptance based on this flag for public-facing applications due to user experience concerns.

In addition to the flags specified above, agencies may wish to gain additional information on the origins and capabilities of the syncable authenticators that they choose to implement and accept. Within the context of WebAuthn, some authenticators support attestation features that can be used to determine the capabilities and manufacturers of specific authenticators. For federal enterprise use cases, agencies SHOULD implement attestation capabilities based on the functionality offered by their platform providers. This would take the form of a manufacturer attestation in which the RP requests identifying information about the authenticator.

The unavailability of attestations SHOULD NOT block the use of syncable authenticators for broad public-facing applications. Due to the limited availability of attestations in consumer products, requiring their use is likely to divert users to less secure authentication options that are vulnerable to phishing (e.g., PSTN-based out-of-band authentication). While authentication transaction metadata (e.g., the User Verified flag indicating the use of a local activation factor) is available in WebAuthn responses, attestation can provide stronger assurance of the characteristics of the authenticator used in a transaction. RPs SHOULD use attestation to determine the level of confidence they have in a syncable authenticator when attestations are available.

When the RP receives flag and attestation data, the authenticator may provide information that is incomplete or inconsistent with access to a resource. Agencies SHALL evaluate the use cases for syncable authenticators and determine the appropriate access policy decisions that they intend to make based on the returned information.

Cybersecurity guidelines have historically cautioned against sharing authenticators between users. Rather, different users are expected to maintain their own unique authenticators. Despite this, authenticator and password sharing occurs within some user groups and applications to allow individuals to share access to a digital account.

As indicated in Table 5, some syncable authenticator implementations have embraced this user behavior and established methods for sharing authentication keys between different users. Further, some implementations actively encourage sharing syncable authenticators as a convenient and more secure alternative to sharing passwords for common services.

For enterprise use cases, concerns over sharing keys can be effectively mitigated using device management techniques that limit the ability for keys to be moved off of approved devices or sync fabrics. However, similar mitigations are not currently available for public-facing use cases, leaving RPs dependent on the sharing models adopted by syncable authenticator providers. Owners of public-facing applications should be aware of the risks associated with shared authenticators. When interacting with the public, agencies have limited visibility into which specific authenticators are being employed by their users and should assume that all syncable authenticators may be subject to sharing. While many sharing models have substantial controls that minimize risks (e.g., requiring close proximity between devices to allow sharing), other implementations are less restrictive.

The risk of sharing posed by this new class of authenticators is not unique. It applies to all authenticator types, some of which are weaker than syncable authenticators. Any authenticator can be shared by a user who is determined to share it. Users can actively share passwords, OTPs, out-of-band authenticators, and even push-based authentication events that allow a designee (whether formal or not) to authenticate on behalf of an end user.

Agencies determine which authenticators they will accept for their applications based on the specific risks, threats, and usability considerations they face. Syncable authenticators may be offered as a new option for applications that seek to implement up to AAL2. The trade-offs of this technology should be balanced with expected outcomes for security, privacy, and user experience.

Example

A common use of syncable authenticators is in an AAL2 authentication transaction. The following items summarize how WebAuthn syncable authenticators satisfy aspects of AAL2 requirements:

Phishing resistance (recommended, required for federal enterprise): Achieved: Properly configured syncable authenticators create a unique public or private key pair whose use is constrained to the domain in which it was created (i.e., the key can only be used with a specific website or RP). This prevents a falsified web page from being able to capture and reuse an authenticator output.
Replay resistance (required): Achieved: Syncable authenticators prevent replay resistance (i.e., prevention of reuse in future transactions) through a random nonce that is incorporated into each authentication transaction.
Authentication intent (required): Achieved: Syncable authenticators require users to present an activation factor (i.e., activation secret, biometric characteristic) to initiate the cryptographic authentication protocol. This serves as authentication intent, as the event cannot proceed without the user’s active participation.
Multi-factor (required): Achieved: The User Verified flag value indicates whether a local authentication mechanism (i.e., an activation factor) was used to complete the transaction. Without user verification, the verifier prompts for an additional authentication factor as part of the transaction.

If the subscriber provides their own authenticator, the verifier may have limited visibility into the features and capabilities of the sync fabric and the devices to which the user may sync their authentication keys. In this scenario, the verifier SHOULD leverage additional risk indicators or trust signals that may be available from the transaction, device, or sync fabric to increase confidence in the authentication event.

Syncable authenticators are not unique in this respect. Any subscriber-provided authenticator is subject to the same risks as syncable authenticators, including OTP authenticators and nearly all out-of-band authenticators. It is important for CSPs and IdPs to assess each type of authenticator that they offer at each assurance level and determine which are acceptable based on their users and transaction types.

Security Considerations

Syncable authenticators present distinct threats and challenges that agencies should evaluate before implementation or deployment, as shown in Table 5.

Table 5. Syncable authenticator threats, challenges, and mitigations

Threat or Challenge	Description	Mitigations
Unauthorized key use or loss of control	Some syncable authenticator deployments support sharing authentication keys to devices that belong to other users who can then misuse the key.	Enforce enterprise device management features or managed profiles that prevent synced keys from being shared.
		Provide mechanisms for users to view keys, key statuses, and whether/where keys have been shared.
		Educate users about the risks of unauthorized key use through existing awareness and training mechanisms.
Sync fabric compromise	To support key syncing, most implementations clone keys to a sync fabric (i.e., a cloud-based service connected to multiple devices associated with an account).	Store only encrypted key material.
		Implement sync fabric access controls that prevent anyone other than the authenticated user from accessing the authentication key.
		Evaluate cloud services for baseline security features (e.g., FISMA moderate protections or comparable).
		Leverage hardware security modules to protect encrypted keys.
Unauthorized access to sync fabric and recovery	Synced keys are accessible via cloud-based account recovery processes, which represent a potential weakness to the authenticators.	Implement authentication recovery processes that are consistent with SP 800-63B.
		Restrict recovery capabilities for federal enterprise keys through device management or managed account capabilities.
		Bind multiple authenticators at AAL2 and above to support recovery.
		Require AAL2 authentication to add any new authenticators for user access to the sync fabric.
		Only use synced keys as a derived authenticator in federal enterprise scenarios [SP800-157].
		Notify the user of any recovery activities.
		Leverage a user-controlled secret (i.e., something not known to the sync fabric provider) to encrypt and recover keys.
Revocation	Since syncable authenticators use RP-specific keys, the ability to centrally revoke access based on those keys is challenging. For example, with traditional PKI, CRLs can be used centrally to revoke access. A similar process is not available for syncable authenticators or any FIDO WebAuthn-based credentials.	Implement a central identity management (IDM) account for users to manage authenticators and remove them from the “home agency” account if they are compromised or expired.
		Leverage SSO and federation to limit the number of RP-specific keys that will need to be revoked in an incident.
		Establish policies and tools to request that users periodically review keys for validity and currency.