Achieving FedRamp Compliance with the YubiKey FIPS Series Devices


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 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 documentations 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.


Requirement

AAL1

AAL2

AAL3

Permitted authenticator types

  • Memorized Secret;

  • Look-up Secret;

  • Out-of-Band;

  • SF OTP Device;

  • MF OTP Device;

  • SF Crypto Software;

  • SF Crypto Device;

  • MF Crypto Software;

  • MF Crypto Device

  • MF OTP Device;

  • MF Crypto Software;

  • MF Crypto Device;

  • or Memorized Secret plus:

    •  Look-up Secret

    • Out-of-Band

    • SF OTP Device

    • SF Crypto Software

    • SF Crypto Device

  • MF Crypto Device;

  • SF Crypto Device plus   Memorized Secret;

  • SF OTP Device plus MF Crypto Device or Software;

  • SF OTP Device plus SF Crypto Software plus Memorized Secret

FIPS 140 validation

  • Level 1 (Government agency verifiers)

  • Level 1 (Government agency authenticators and verifiers)

  • Level 2 overall (MF authenticators)

  • Level 1 overall (verifiers and SF Crypto Devices)

  • Level 3 physical security (all authenticators)

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

*SF - Singlefactor, ie 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-800-63B. The PIN must be composed by the user, and cannot be based on personal identifying information, such as username, social security number or employee ID.

Smart Cards based on the NIST PIV Standard are the primary example of a MF Cryptographic device, including the PIV function of the YubiKey.


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.

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 AAL2 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 FIDO U2F and Password

AAL3 can be met with the YubiKey as a Single-Factor Cryptographic (SF Cryptographic) device in conjunction with a seperate Memorized Secret. This includes the FIDO U2F function supported on the YubiKey. 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 Cryptographic 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 AAL3 would use the YubiKey as a FIDO U2F device, authenticating the user alongside a password and username when logging into a site or service. The U2F Authentication would be validated by a FIDO server integrated with the service, and confirmed to originate from a YubiKey associated with the username. The password would then be validated, allowing the user to log in. If the user is inactive for 15 minutes, they must re-authenticate again.


Authentication Assurance

Authentication Method(s)

Capability

Memorized Secret Requirements

PIN Requirements

1

SF OTP

OATH-TOTP, OATH-HOTP, YubiOTP

N/A

N/A

1

SF Cryptographic Hardware Device

FIDO U2F

N/A

N/A

2

Password + SF OTP

OATH-TOTP, OATH-HOTP, YubiOTP

5.1.1.2 Memorized Secret Verifiers

N/A

3

Password + SF Cryptographic Hardware Device

FIDO U2F

5.1.1.2 Memorized Secret Verifiers

N/A

3

MF Cryptographic Device

Smart Card (PIV Applet)

N/A

From NIST SP800-63-3B Section 5.1.9.1


Any memorized secret used by the authenticator for activation SHALL be a randomly-chosen

numeric value at least 6 decimal digits in length


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.

When used as a MF Cryptographic authentication device, the YubiKey is acting as a FIPS 140-2 certified PIV-compatible smart card, and as such, is built to meet the NIST SP 201-2 requirements. As such, the YubiKey is acceptable to be used as a AAL3 device, but only if the processes around it remain in compliance with the greater framework. For example, the PIN only needs to be 6 characters in length, but there needs to be a process in place to ensure the PIN is provided by and known only to the user, and not derived from personally identifying information, such as a username or employee ID.

As part of a larger discussion, the process in which YubiKeys are intialized 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.

Comments

0 comments

Please sign in to leave a comment.