To purchase FIPS YubiKeys, please visit our web store.

Introduction

The Federal Risk and Authorization Management Program, or FedRAMP, is a government-wide program that provides a standardized approach to security based on technical requirements from the National Institute of Standards and Technology (NIST). When services or solutions seek compliance with the FedRAMP requirements to interact with federal resources, the YubiKey 5 FIPS Series devices are often selected as an authenticator of choice for users as part of a larger authentication and identity management framework.

 

FedRAMP, at its core, is a program to modernize and apply modern standards of cybersecurity to ensure the sensitive data contained within federal systems remains secure. It achieves this goal by utilizing the guidelines provided in the NIST Special Publications to provide direction on the implementation of such systems. The NIST documents specific to a particular component of an implementation, from identity proofing to user authentication and beyond, should be regarded as the source of truth, and FedRAMP provides the process to ensure the instructions contained within are implemented fully and correctly.

 

Due to the multiple authentication options possible on a YubiKey, some confusion can arise when ensuring compliance with the NIST SP 800-63-3 guidelines and FedRAMP as a whole. This guide addresses the most common questions and offers prescriptive solutions for most FedRAMP scenarios with the YubiKey.

 

Authenticator Assurance Levels (AALs)

When deciding how to use the YubiKey, the available authentication options will be limited by the required Authenticator Assurance Level (AAL) for the service. AALs are determined by the sensitivity of the interactions between the service and resources, and the required AAL should be defined prior to the design of the user authentication architecture. For guidance on determining the AAL level appropriate for the service, refer to NIST SP 800-63-3, section 6.2.

 

 

There are three AALs, in rising order of security. These levels are fully defined in NIST SP 800-63-3B, Section 4.

 

AAL1: AAL1 provides some assurance that the claimant controls an authenticator bound to the subscriber’s account. AAL1 requires either single-factor or multi-factor authentication using a wide range of available authentication technologies. Successful authentication requires that the claimant prove possession and control of the authenticator through a secure authentication protocol.

 

AAL2: AAL2 provides high confidence that the claimant controls authenticator(s) bound to the subscriber’s account. Proof of possession and control of two distinct authentication factors is required through secure authentication protocol(s). Approved cryptographic techniques are required at AAL2 and above.

 

AAL3: AAL3 provides very high confidence that the claimant controls authenticator(s) bound to the subscriber’s account. Authentication at AAL3 is based on proof of possession of a key through a cryptographic protocol. AAL3 authentication SHALL use a hardware-based authenticator and an authenticator that provides verifiable impersonation resistance; the same device MAY fulfill both these requirements.

 

In order to authenticate at AAL3, claimants SHALL prove possession and control of two distinct authentication factors through secure authentication protocol(s). Approved cryptographic techniques are required.

 

*MF - Multifactor, i.e. two or more forms of authentication must be supplied to use. Examples include smart card locked with a PIN.

*SF - Singlefactor, i.e. only one form of authentication must be supplied to use. Examples include passwords.

 

Supported Authenticator Types

Depending on the function of the YubiKey being utilized, the YubiKey can fall under different Authenticator Types, as such, it will meet the requirements established in NIST SP 800-63-3B in order to be compliant with FedRAMP.  For compliance with the FedRAMP guidelines, an Authenticator must have been FIPS 140-2 certified.

 

Memorized Secret (Section 5.1.1)

While a YubiKey cannot hold a Memorized Secret, it is often used alongside one for authentication. A Memorized Secret is a string of at least 8 characters in length defined by the user; it is commonly referred to as a password, passphrase or PIN. While a Memorized Secret can be entirely numeric, it should not be confused with a PIN, which is used to validate a Mutli-Factor (MF) Cryptographic Device.

 

The key difference is a Memorized Secret is validated against the service being authenticated to while a MF Cryptographic Device PIN is validated by the Cryptographic Device itself.

 

Single-Factor One-Time Password (OTP) Device (Section 5.1.4)

The YubiKey can function as a Single-Factor One-Time Password (SF OTP) hardware device, supporting a number of different OTP protocols. SF OTP devices generates unique one-use codes (OTPs) based off cryptographic algorithms, with the OTP validated by the service being authenticated to. As a Single-Factor device, possession of the SF OTP device is considered sufficient; a user does not need to supply a password or PIN for it to generate an OTP for authentication. The YubiKey supports the YubiOTP, OATH-HOTP or OATH-TOTP protocols when being used as an SF OTP Device.

 

Single-Factor Cryptographic Device (Section 5.1.7)

When used as a FIDO U2F authenticator, the YubiKey is considered a Single-Factor Cryptographic (SF Cryptographic) hardware device. SF Cryptographic devices perform cryptographic operations using protected symmetric or asymmetric key(s) internally and provides the authenticator output via direct connection to the user’s endpoint, with the output validated by the service being authenticated to. As a Single-Factor device, possession of the SF cryptographic device is considered sufficient; a user does not need to supply a password or PIN for authentication. The YubiKey supports the FIDO U2F protocol when being used as an SF Cryptographic Device.

 

Multi-Factor Cryptographic Device (Section 5.1.9)

Multifactor-Factor Cryptographic (MF Cryptographic) hardware devices provide the highest level of user authentication. As a Multi-Factor device, possession of the MF cryptographic device is not considered sufficient; it is required that the user must authenticate to the hardware device with a PIN or other form of memorized secret prior to the device allowing user authentication to a service.

 

It is important to note that the PIN or other memorized secret used to authenticate to a MF Cryptographic device before the device can be used is not under the same requirements as a Memorized Secret used to authenticate to a service directly; the PIN length for a MF Cryptographic device must be 6 characters or longer as defined in NIST SP-800-63B.

The method in which the PIN is created impacts the permissible minimum length. If the PIN is created as a randomly generated value and not by the user, it can be 6 characters long. This randomly generated value cannot be based on personal identifying information, such as username, social security number or employee ID; for greater detail refer to NIST SP-800-63B, Appendix A. If the PIN is created by a user, it must be at least 8 characters in length, and also cannot be based on personal identifying information.

Smart cards based on the NIST PIV Standard (FIPS 201) as well as WebAuthn authenticators are examples of an MF Cryptographic device. The PIV and WebAuthn support on the YubiKey both can be used as a MF Cryptographic device.

 

Meeting AALs with the YubiKey

The YubiKey can be utilized to meet every AAL level described in NIST 800-63-3, and allow for FedRAMP compliance within your organization. However, not all authentication functions on the YubiKey can be used to meet every AAL level.

 

AAL1

AAL1 can be met with the YubiKey as a Single-Factor One-Time Password (SF OTP) device or a Single-Factor Cryptographic Device (SF Cryptographic). This includes the OTP functions supported on the YubiKey, such as the Yubico OTP, OATH-HOTP or OATH-TOTP, or as a Cryptographic Hardware Device using the FIDO U2F function. As a Single-Factor device, possession of the YubiKey is considered sufficient to meet the requirements to authenticate the user; no additional password or memorized secret is required.

 

A sample deployment using the YubiKey to meet AAL1 would use the YubiKey as an OTP or U2F device, generating OTPs or cryptographic signatures to use along with the username when logging into a site or service. The OTP or cryptographic signature would be validated and confirmed to originate from a YubiKey associated with the username, then the user would be allowed to log in. If the service allows for extended sessions, the user must re-authenticate at least once every thirty days.

 

AAL2

AAL2 can be met with the YubiKey as a Single-Factor One-Time Password (SF OTP) device in conjunction with a seperate Memorized Secret. This includes the OTP functions supported on the YubiKey, such as the Yubico OTP, OATH-HOTP or OATH-TOTP. The Memorized Secret must be provided to and validated by the service the user is authenticating to; the requirements for the Memorized Secret are defined in NIST SP 800-63-3B 5.1.1.2 Memorized Secret Verifiers. As a combined Authentication solution, the YubiKey as an SF OTP device in addition to a valid Memorized Secret authenticated by the service is sufficient to meet the requirements to authenticate the user.

 

A sample deployment using the YubiKey to meet AAL2 would use the YubiKey as an OTP device, generating OTPs to use along with a password and username when logging into a site or service. The OTP would be validated and confirmed to originate from a YubiKey associated with the username, the password would be validated then the user would be allowed to log in. The password should be validated after the OTP, to ensure the OTP cannot be reused if the password is incorrect. If the service allows for extended sessions, the user must re-authenticate at least once every twelve hours.

 

AAL3

The YubiKey offers two options for meeting AAL3. Both options use the YubiKey as a Cryptographic Authenticator, with the authentication process occurring without the user acting as a bridge between the authenticator and endpoint.

 

Either of these two options will allow the YubiKey to meet the requirements of an AAL3 authenticator, but only when used in conjunction with an approved environment which supports a secured implementation of digital authentication, including verifier-impersonation resistance. Currently, Chromium-based web browsers do not support sufficient verifier-impersonation resistance with FIDO2 WebAuthn to qualify for being used in an AAL3 deployment. However, these browsers can provide the required AAL3 level if used with smart cards through mutual TLS (mTLS). Also, Windows Logon incorporates token-binding and therefore delivers the necessary protections. Discuss your use cases and requirements with your identity provider vendor as they may have introduced specific controls to meet AAL3 requirements.

 

AAL3 with PIV Smart Card

AAL3 can be met with the YubiKey as a Multi-Factor Cryptographic (MF Cryptographic) device, such as a PIV smart card. The YubiKey PIV smart card function must have a PIN at least 6 characters in length, and contain a user authentication certificate issued by a FIPS 140-2 validated Certificate Authority linked to the service being authenticated to. As a Multi-Factor Authentication solution, the YubiKey as a smart card secured with a PIN is sufficient to meet the requirements to authenticate the user.

 

A sample deployment using the YubiKey to meet AAL3 would use the YubiKey as a PIV smart card, identifying and authenticating the user when logging into a site or service. The user authentication certificates stored on the PIV smart card function of the YubiKey would be validated by a Certificate Authority server controlling access to the service, and confirmed to originate from a trusted CA. If the user is inactive for 15 minutes, they must re-authenticate again.

 

AAL3 with WebAuthn for Windows Logon

FIDO WebAuthn with User Verification on the YubiKey can also fulfill the requirements for a Multi-Factor Cryptographic authenticator, when used with an authentication framework which meets the requirements external to the authenticator itself. The Memorized secret (PIN) would be required to be provided at registration and authentication, and have a length no less than 6 characters.

 

One such deployment using the YubiKey to meet AAL3 would be using the YubiKey as a WebAuthn authentication device on a Windows endpoint for Logon authentication. The WebAuthn PIN is required on registration or logon, and would be no less than 6 characters. The WebAuthn Authentication would be validated against Azure Active Directory, where the authenticator is bound to the user. The Windows endpoint would need to be running in a FIPS 140-2 approved move of operation. If the user is inactive for 15 minutes, or has been connected for 12 hours or more since their previous authentication, they must re-authenticate again.

 

 

Additional Considerations

This guide only touches on the methods with which to meet FedRAMP compliance using the FIPS Series YubiKey as an Authenticator. It is important to keep in mind there are other aspects which can impact the certification of a solution, and should be kept in mind when integrating the YubiKey.

 

The standard includes AAL requirements include 11 categories:

 

• Permitted authenticator types
• FIPS 140-2 verification level
• Reauthentication
• Security controls
• Man-in-the-middle (MitM) resistance
• Verifier-impersonation resistance (phishing resistance)
• Verifier-compromise resistance
• Replay resistance
• Authentication intent
• Records Retention Policy
• Privacy Controls

When used as a MF Cryptographic authentication device, the YubiKey 5 FIPS Series is acting either as a FIPS 140-2 certified PIV-compatible smart card or a FIDO2 WebAuthn Authenticator. As such, a YubiKey 5 FIPS device fulfils the requirements for:

 

• Permitted authenticator types
• FIPS 140-2 verification level
• Authentication intent

The PIV and FIDO WebAuthn frameworks will also need to address the requirements as part of a properly implemented deployment:

 

• Man-in-the-middle (MitM) resistance
• Verifier-impersonation resistance (with token-binding or secure channel)
• Verifier-compromise resistance
• Replay resistance

The remaining categories must be included as part of an overall solution, but are not necessarily part of the authentication process:

 

• Reauthentication
• Security controls
• Records Retention Policy
• Privacy Controls

Microsoft Windows with Azure Active Directory, when used with a YubiKey 5 FIPS Series device, meets the requirements in each of the listed categories necessary to achieve AAL3.

 

As part of a larger discussion, the process in which YubiKeys are initialized and deployed to users should also be considered to ensure compliance. NIST guidelines require the separation of roles between an end user, who uses an authenticator on a day to day usage, and a crypto officer, who is responsible for securely loading the cryptographic secrets onto an authenticator. This can impact some deployments, but also can be easily addressed using systems such as Card Management Solutions (CMS) or having a proper process. This topic is discussed in more detail in YubiKey FIPS Series Deployment Considerations.