Federation Requirements Introduced in FIPS 201-3

FIPS 201-3 is the newest version of a NIST standard that governs Personal Identity Verification (PIV) of US Federal employees and contractors. It relies on Special Publication (SP) 800-63C and introduces mandatory support for federation.

Federation Roles

The federation protocol that it defines includes three actors:

1. A subscriber
2. The Identity Provider (IdP)
3. The Relying Party (RP)

These relate to each other as shown in the following diagram:

An RP can come to depend on an IdP statically (i.e., by manual, out-of-band) methods or dynamically by programmatic methods.

Other Terms for Federation Roles

Federation is achieved using various technologies that have synonyms for these terms. Some common ones are listed in the following table:

Federation Assurance Levels

FIPS 201-3 also defines various Federation Assurance Levels (FAL), and explains how to achieve these using OpenID Connect (OIDC) or SAML. A conformant deployment can utilize OIDC to achieve these various assurance levels by implementing the techniques summarized in the following table:

Additionally, the IdP has to employ various security controls that are defined in SP 800-53, FedRAMP, or various industry standards. SP 800-53 defines hundreds of security controls that are needed regardless of FAL (e.g., account management, Separation of Duties (SoD), application of the principal of least privilege, handling unsuccessful logon attempts, etc.). Industry standards to be aware of when determining additional security measures that are required include ISO/IEC 27001, SP 800-53, OIDC for Identity Assurance (OIDC4IA), the Financial-grade API (FAPI)profile of OIDC, and VoT.

Assertions

SP 800-63C goes into detail about assertions (esp. section 6). It describes an assertion as a container of attributes that the IdP claims or asserts as true. It defines various claims that are required in any assertion. Interestingly, all of required claims are also mandatory in OIDC. The mapping of assertion metadata defined in SP 800-63C to the values in OIDC core (section 2) are shown in the following table:

Both SP 800-63C and OIDC require the ID token (assertion) to be signed. In OIDC, the ID token is a JSON Web Token (JWT) which can be symmetrically or asymmetrically signed using JSON Web Signing (JWS); in practice, a JWT is always asymmetrically signed. Also, ID tokens can be encrypted after signing (using JSON Web Encryption (JWE)). This is required by SP 800-63C when the ID token flows through the browser (e.g., when using the hybrid flow).

In OIDC, an RP can send a nonce parameter in the authorization request. The OP is required to place this in the ID token. This will allow the RP to detect replay attempts. Additionally, the Curity Identity Server always includes a JWT ID (a jti claim) in ID tokens. These coupled with the issuance timestamp (i.e., the iat claim) will make the assertion sufficiently unique, as FIPS 201-3 requires.

Both SP 800-63C and OIDC allow the ID token to include additional claims about the user; they also allow the assertion to contain attribute metadata (e.g., when the value was last updated, its origin, format, etc.). This extensibility can be a helpful way to communicate more information about the subscriber to the RP. In turn, the RP may use this additional information to make access control decisions.

The assertion should also specify the Authenticator Assurance Level (AAL) and Identity Assurance Level (IAL) of the subscriber. This can be done using VoT (defined in RFC 8485). In brief, VoT sets forth a protocol where the IdP can inform the RP about the kind of identity proofing that the user underwent before being able to login. Additional, VoT allows the IdP to inform the RP about the strength of the credential used during login and the life cycle of that credential. These will help the RP determine the AAL and IAL using the architecture and wire format laid out in the VoT standard.

Achieving FAL 3

To ascend to level 3 on the federation scale, two relatively difficult challenges must be overcome:

1. The assertion must be encrypted for the RP
2. The assertion must be bound to the Subscriber's key and this binding must be verified by the RP

When using OIDC, as stated above, encrypting the assertion for the RP is done using JWE. The only difficultly with this is the IdP obtaining the public key of the RP. Various methods can be used to minimize this challenge. For instance, a PKI can be used. In such cases, the IdP will obtain the public key of the RP from the key server (directory) in the PKI. It will then hash the key, and include this digest in the header of the JWE. Later, the RP will see this hash and know which of its keys to use to perform decryption. An example of the header of such a JWE is shown in the following listing (cf. Encrypted ID Tokens):

{
  "alg": "RSA-OAEP",
  "enc": "A256CBC-HS512",
  "cty": "JWT",
  "x5t#S256": "Y0H4y9eaiiNyoprMY6vMm4i3LATu0LEBXgSv7F1iNlU"
}

This x5t#S256 claim is the SHA-256 hash of the RP's public key. From this, the RP can find and use its corresponding private key (and the algorithm indicated in the alg claim) to decrypt a symmetric Content Encryption Key (CEK) that is part of the JWE. This CEK is used to symmetrically decrypt the payload of the JWE; the result is JWT signed by the IdP. In this inner JWT, the RP needs to find and verify another important claim.

SP 800-63C does not stipulate the name of this claim, but, in the case of OIDC, it should be the cnf claim defined in RFC 7800. This claims contains members to identify the proof-of-possession key (i.e., proof key) used to confirm the identity of the Subscriber. RFC 8705 defines one such member which is the SHA-256 hash of the public key of the proof key. In such a case, once decoded, the JWT will contain a JSON body such as the one in the following listing:

{
    "cnf": {
        "x5t#S256": "FjeHcvJwiHXlr8dgnP7UvLQ7dLLMTe_3SgMYMuEpekc"
    }
}

To tie this key to the Subscriber, the RP also needs a proof that the Subscriber is in possession of this key. This verification of the key at the IdP and RP forms a type of parallel authentication. There are various ways to implement this, but neither SP 800-63C nor FIPS 201-3 mandates any particular one.

From the Subscriber's perspective, this could be rather tedious because the IdP will prompt them for a credential and moments later, the RP will do the same. For this reason, using some form of PIV middleware that can maintain a client-side session could improve UX. Another possibility is to use a derived PIV that is more convenient for the user. For instance, if a FIDO token is used, the Subscriber can easily tap the authenticator a couple of times: once to authenticate to the IdP and another to prove possession of the key when accessing the RP at FAL 3.

Transmitting Assertions to the RP

The relevant specifications talk about two ways of transmitting an assertion between the IdP and RP:

1. Back channel
2. Front channel

In general, back-channel is more secure, but it does require more network communication. Front-channel delivery transmits an assertion via the Subscriber, typically using the facilities of their browser. Back-channel delivery, on the other hand, only transmits a reference to assertion by way of the Subscriber's user agent. Upon receipt of this reference, the RP dereferences it by making a direct call to the IdP and obtaining the full assertion is the response. These two methods are depicted in the following figures:

OpenID Connect's code flow uses the back-channel delivery method. The implicit flow uses front-channel. Any front-channel delivery method will be limited to FAL 1, so back-channel is required for scenarios requiring FAL 2 and 3.

Conclusion

The requirements defined by FIPS 201-3 are challenging but there are plenty of tools in OpenID that can help with compliance. Browse through the many articles in the resource library and check out the related articles and topics on the right.