BaselineWatch
Desk
Your fleet and your work Fleetyour releases and the hardware they run onTriagewhat needs a decisionWatchlistthe products and platforms you runSaved searchesthe lists you come back to
This instance Sourceswhat is read, how often, under what termsDigestthe daily or weekly summary, and alerts
How it is drawn Appearancethe look and the colour schemeBrandingthe mark this instance wears
Owner sign-in

4.1.3 FAL3

NIST PIV and digital identity SP 800-217 (Draft)
All changes in this version
first version loaded 4 Federation Assurance Level (FAL) 788 part of 4.1

Title

FAL3

Control

All of the requirements for FAL1 and FAL2 apply at FAL3 except when more specific or stringent requirements in this section override them.

The PIV IdP at FAL3 SHALL establish identifiers and key material for RP such that the IdP can identify and trust the RP prior to the federation transaction.

As defined in [SP800-63C] , FAL3 requires the establishment of a bound authenticator , which the subscriber presents directly to the RP alongside the federation assertion from the IdP. The bound authenticator does not need to be a PIV credential, though most PIV credentials can be used as bound authenticators at FAL3. When used as a bound authenticator, a PIV credential must be verified separately from the PIV identity account and the assertion with which it is associated. The nature of the binding depends on the type of authenticator, its use, and its phishing resistance qualities. The same authenticator MAY be used as both a derived PIV authenticator at the IdP and a bound authenticator at the RP in a single transaction provided that both the IdP and RP separately verify the authenticator.

PKI-based credentials, such as the PIV authentication certificate on the PIV Card, MAY be used as an IdP-managed bound authenticator, as shown in Fig. 2 . When a certificate is used in this fashion, the assertion SHALL contain an identifier of the certificate (as discussed in Sec 6.2.3 ) as an attribute in the assertion to identify the specific certificate used as an authenticator. If the RP uses a just-in-time provisioning method for the RP subscriber account (as defined in [SP800-63C] ), the RP SHALL compare the attributes of the certificate with other attributes from the federation transaction when first associating the bound authenticator with a federated identifier. For example, if the certificate includes one email address, and the federation transaction gives the RP a different email address, the RP needs to decide whether the transaction should be rejected or if this specific discrepancy is expected for its use case and security profile.

Non-PKI-based derived PIV credentials and authenticators other than PIV credentials MAY be used as RP-managed bound authenticators, as shown in Fig. 3 , provided the authenticators meet the phishing resistance requirements in [SP800-63C] . With RP- managed bound authenticators, the IdP does not see the authenticator directly. The RP SHALL conduct an appropriate binding ceremony, as defined in [SP800-63C] .

When a PIV credential is used as a bound authenticator at the RP, the RP SHALL verify the authenticator in the context of a valid assertion. In this way, the authenticator functions separately from its use as a PIV credential. Fig. 2. IdP-managed bound authenticators Assertion
- FAL3
- IdP-Managed
- Certificate CN PIV Card or Derived PIV Credential

PIV Card or PKI-Based Derived PIV Credential Subscriber IdP

RP

Fig. 3. RP-managed nound authenticators

22 Subscriber IdP

RP Assertion
- FAL3
- RP-Managed
- No Authenticator ID PIV Card or Derived PIV Credential

Non-PIV Bound Authenticator In the case of a lost bound authenticator, the RP SHALL provide mechanisms for 861 862

863 864 865 866 867 868

869 870 871 872 873 874 875 unbinding old authenticators and binding a new authenticator at FAL3.