Bringing Zero Trust to FIDO2 Authenticators

Establishing Attestations for the Derived FIDO2 Credential (DFC)

Read time: 6 minutes

Executive Summary

The following information pertains to a workflow for the issuance and management of a Derived FIDO2 Credential (DFC) based upon previous guidance for the issuance of X.509-based Derived PIV Credentials. This workflow allows for organizational attestation of the FIDO2 hardware token, strong identity binding to tie a user’s existing PIV or CAC smart card to the issuance of the DFC and using attribute based access control (ABAC) to provide attestation of the assurance level of the DFC during authentication. These controls are established practices that minimize the risk of impersonation and allow for managing which resources an end user can interact with while leveraging a DFC.

Get Started Today!
Contact sales at FedGov@pingidentity.com

Need for Attestation

There exists a strong need for attestation of identity and organizational attachment with multi-factor authentication (MFA) credentials used by the US Federal Executive Branch. These attestations include organizational affiliation of the MFA token, as well as attestation to the trust or assurance level of the credential during authentication. These attestations allow an organization to trust that only approved hardware tokens have been registered as MFA credentials for their users from that organization’s supply chain and these credentials can only be used to access approved data and resources.

When these attestations are not present, there exists a potential vulnerability for a valid MFA credential to be issued through—or to—an unauthorized token for an end user account, which could be leveraged to circumvent the protections intended through the enforcement of MFA. Such a vulnerability was documented by the CISA in Alert AA22-074A in which a Russian state-sponsored actor was able to register their mobile device as a valid mobile authenticator for a non-governmental organization and execute an attack resulting in a successful infiltration of that organization’s network.

Because organizational attestation was not enforced by the MFA issuance system, the Russian state-sponsored actor was able to register their mobile device as a valid authenticator and thus breach the network.

For traditional X.509 smart cards this attestation is satisfied through organizational site keys loaded onto the smart card cardstock. This ensures a user cannot bring their own smart card purchased or acquired from outside of the supply chain of their organization and subsequently load credentials onto that foreign smart card.

During key generation, the public certificates on the X.509 smart card are populated with one or several object identifiers (OIDs) that assert what the keys should be used for, as well as information pertaining to the trust of the credential. Additionally, digital signatures from the CA trust chain are provided anchoring the X.509 credential to a root of trust further solidifying the organization attachment of the credential—further reducing the likelihood of spoofing the X.509 credential.

FIDO2 credentials—while providing phishingresistance—do not inherently provide these methods of attestation. It is critical to limit issuance and usage of a DFC in a manner that allows for these attestations to be enforced. If not, there exists the potential for a nonauthorized token to be issued within an organization. Additionally, the lack of an OID within a DFC makes it difficult to establish the level of trust of the DFC during authentication.

Luckily, these necessary attestations can be successfully accomplished by following a similar issuance and lifecycle management process as outlined in the NIST special publications 800-157 and 800-79-2. Furthermore, the use of modern ABAC can assert these attestations during authentication to relying parties. This allows for the establishment of trust of the FIDO2 token during issuance (as well as during use) and paves the way for full enterprise lifecycle management that can be tied to the end user’s PIV smart card eligibility status.

By following the Derived PIV Credential issuance workflow and lifecycle management, the same necessary attestations can be asserted through the Derived FIDO2 Credential.

Derived FIDO2 Credential (DFC) Issuance Workflow

3.1

Supervisor Approval Received for End User to Receive a DFC MFA

Consistent with NIST SP 800-157.

3.2

End User Receives the DFC Physical Token

The DFC should have an organizational certificate installed during manufacturing or loaded by the organization upon receipt of the unassigned FIDO2 tokens.

3.3

End User Logs into the DFC Credential Management System (CMS) with their PIV Authentication Certificate

This binds the issuance of the DFC to the established identity proofing of the PIV smart card.

PIV Authentication certificate revocation list (CRL) validation and PIV Authentication Object Identifier (OID) check to be performed during authentication.

7 days later, CRL validation to be repeated on the PIV Authentication certificate presented by the end user during issuance of the DFC. If found to be revoked, action may need to be taken to revoke the issued DFC.
- Consistent with NIST SP 800-157 and NIST SP 800-79-2.

3.4

Registration and Issuance of DFC by the CMS

Conforms to the FIDO2 standard and exists between the CMS and the DFC.

This binding can be leveraged to replace individual application registration to the DFC and can be centrally leveraged by the agency’s federation policy engine.
- Consistent with OMB M-22-09 for central identity policy management and enforcement.

3.5

Registration of the DFC by the CMS Binds the FIDO2 Token to the End User Identity Within a Directory

Several attributes should be generated during the directory binding to include DFC lifetime.

The DFC CMS shall generate an attribute indicating the level of assurance of the credential. This shall take the place of the id-fpki-common-derived-pivAuth and id-fpkicommon-derived-pivAuth-hardware OIDs found within Derived PIV Credentials.
- Consistent with NIST SP 800-157 and NIST SP 800-79-2.

3.6

Check the End User’s PIV Card Revocation Status

Every 18 hours, the DFC CMS checks the issuing PIV smart card CMS.
- Consistent with NIST SP 800-79-2.

3.7

Remove Access at the End of the Credential Lifetime

While the lifetime of the DFC should be independent of the certificate and smart card lifetimes of the end user’s associated PIV, when the end user is no longer PIV eligible, all DFCs belonging to that end user shall no longer be authorized for authentication.

While the FIDO2 standard does not currently provide an analog to X.509 certificate revocation, the DFC CMS shall ensure that end user’s FIDO2 tokens cannot be used for successful authentication.

This further necessitates the need for the FIDO2 binding to exist only between the DFC and the DFC CMS rather than with each individual end application.
- Consistent with FIPS 201-3, NIST SP 800-157, and NIST SP 800-79-2.

Better Together: Yubico, EntryPoint and Ping Identity

The no-code integration of Yubico’s YubiKey FIDO2 hardware security keys, EntryPoint’s CMS, and Ping Identity’s enterprise-grade federation and ABAC policy engine allows agencies to follow the DFC issuance and lifecycle workflow steps listed previously. It does this by asserting both organizational attestation and the level of assurance of the FIDO2 key, while deriving the trust of the YubiKey FIDO2 hardware security key through a sophisticated validation of the end user’s smart card.

Together, this integration brings the zero trust concept of “trust nothing, verify everything” to FIDO2 authenticators through strong identity proofing, a phishing-resistant authenticator and modern authentication through federation and ABAC. It also realizes the Identity Assurance Level (IAL), Authenticator Assurance Level (AAL), and Federation Assurance Level (FAL) outlined in NIST SP 800-63-3.

In combination, these three services support NIST Special Publication 800-63, Revision 3:

To eliminate vendor lock-in, the partnership is built around standards-based protocols, allowing for a cohesive solution which is consumed, managed, and enforced through a centralized identity and access management platform. This platform enables federated authentication to cloud, on-premise, legacy, and airgapped applications.

All this together creates a reliable solution that works off the shelf without any code customizations for deployment. This, along with Ping Identity’s ability to leverage X.509 PIV and CAC authentication, provides an all-in-one solution for adaptive authentication and dynamic ABAC authorization for federal agencies and departments, consistent with the requirements in the OMB M-22-09.

Get Started Today!
Contact sales at FedGov@pingidentity.com

#3635 | 06.22 | v04