Appendix A Mapping to Cybersecurity Framework Core

Table A-1 maps informative National Institute of Standards and Technology (NIST) and consensus security references to the Cybersecurity Framework core Subcategories that are addressed by this practice guide. The references do not include protocol specifications that are implemented by the individual products that compose the demonstrated security platforms. While some of the references provide general guidance that informs implementation of referenced Cybersecurity Framework core Functions, the references also provide specific recommendations that should be considered when composing and configuring security platforms and technologies described in this practice guide.

Table A-1 Cybersecurity Framework Categories

Category	Subcategory	Informative References
Asset Management (ID.AM): The data, personnel, devices, systems, and facilities that enable the organization to achieve business purposes are identified and managed consistent with their relative importance to business objectives and the organization’s risk strategy.	ID.AM-1: Physical devices and systems within the organization are inventoried.	CCS CSC 1 COBIT 5 BAI09.01, BAI09.02 ISA 62443-2-1:2009 4.2.3.4 ISA 62443-3-3:2013 SR 7.8 ISO/IEC 27001:2013 A.8.1.1, A.8.1.2 NIST SP 800-53 Rev. 4 CM-8
Access Control (PR.AC): Access to assets and associated facilities is limited to authorized users, processes, or devices, and to authorized activities and transactions.	PR.AC-1: Identities and credentials are managed for authorized devices and users.	CCS CSC 16 COBIT 5 DSS05.04, DSS06.03 ISA 62443-2-1:2009 4.3.3.5.1 ISA 62443-3-3:2013 SR 1.1, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9 ISO/IEC 27001:2013 A.9.2.1, A.9.2.2, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 NIST SP 800-53 Rev. 4 AC-2, Information Assurance Family
	PR.AC-3: Remote access is managed.	COBIT 5 APO13.01, DSS01.04, DSS05.03 ISA 62443-2-1:2009 4.3.3.6.6 ISA 62443-3-3:2013 SR 1.13, SR 2.6 ISO/IEC 27001:2013 A.6.2.2, A.13.1.1, A.13.2.1 NIST SP 800-53 Rev. 4 AC‑17, AC-19, AC-20
	PR.AC-4: Access permissions are managed, incorporating the principles of least privilege and separation of duties.	CCS CSC 12, 15 ISA 62443-2-1:2009 4.3.3.7.3 ISA 62443-3-3:2013 SR 2.1 ISO/IEC 27001:2013 A.6.1.2, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4 NIST SP 800-53 Rev. 4 AC-2, AC‑3, AC-5, AC-6, AC-16
Data Security (PR.DS): Information and records (data) are managed consistent with the organization’s risk strategy to protect the confidentiality, integrity, and availability of information.	PR.DS-5: Protections against data leaks are implemented.	CCS CSC 17 COBIT 5 APO01.06 ISA 62443-3-3:2013 SR 5.2 ISO/IEC 27001:2013 A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3 NIST SP 800-53 Rev. 4 AC-4, AC‑5, AC-6, PE-19, PS-3, PS-6, SC-7, SC-8, SC-13, SC-31, SI-4
Protective Technology (PR.PT): Technical security solutions are managed to ensure the security and resilience of systems and assets, consistent with related policies, procedures, and agreements.	PR.PT-1: Audit/log records are determined, documented, implemented, and reviewed in accordance with policy.	CCS CSC 14 COBIT 5 APO11.04 ISA 62443-2-1:2009 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4 ISA 62443-3-3:2013 SR 2.8, SR 2.9, SR 2.10, SR 2.11, SR 2.12 ISO/IEC 27001:2013 A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1 NIST SP 800-53 Rev. 4 Audit and Accountability Family
	PR.PT-2: Removable media is protected and its use restricted according to policy.	COBIT 5 DSS05.02, APO13.01 ISA 62443-3-3:2013 SR 2.3 ISO/IEC 27001:2013 A.8.2.2, A.8.2.3, A.8.3.1, A.8.3.3, A.11.2.9 NIST SP 800-53 Rev. 4 MP-2, MP-4, MP-5, MP-7
	PR.PT-3: Access to systems and assets is controlled, incorporating the principle of least functionality.	COBIT 5 DSS05.02 ISA 62443-2-1:2009 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4 ISA 62443-3-3:2013 SR 1.1, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7 ISO/IEC 27001:2013 A.9.1.2 NIST SP 800-53 Rev. 4 AC-3, CM-7
	PR.PT-4: Communications and control networks are protected.	CCS CSC 7 COBIT 5 DSS05.02, APO13.01 ISA 62443-3-3:2013 SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6 ISO/IEC 27001:2013 A.13.1.1, A.13.2.1 NIST SP 800-53 Rev. 4 AC-4, AC‑17, AC-18, CP-8, SC-7

Appendix B Assumptions Underlying the Build

This project is guided by the following assumptions. Implementers are advised to consider whether the same assumptions can be made based on current policy, process, and IT infrastructure. Where applicable, appropriate guidance is provided to assist this process as described in the following subsections.

B.1 Identity Proofing

NIST SP 800-63A, Enrollment and Identity Proofing [B21] addresses how applicants can prove their identities and become enrolled as valid subjects within an identity system. It provides requirements for processes by which applicants can both proof and enroll at one of three different levels of risk mitigation, in both remote and physically present scenarios. NIST SP 800-63A contains both normative and informative material. An organization should use NIST SP 800-63A to develop and implement an identity proofing plan within its enterprise.

B.2 Mobile Device Security

Mobile devices can add to an organization’s productivity by providing employees with access to business resources at any time. Not only has this reshaped how typical tasks are accomplished, but organizations are also devising entirely new ways to work. However, mobile devices may be lost or stolen. A compromised mobile device may allow remote access to sensitive on-premises organizational data or any other data that the user has entrusted to the device. Several methods exist to address these concerns (e.g., using a device lock screen, setting shorter screen timeouts, forcing a device wipe in case of too many failed authentication attempts). It is up to the organization to implement these types of security controls, which can be enforced with EMM software (see Section B.4).

NIST SP 1800-4, Mobile Device Security: Cloud and Hybrid Builds [B22] demonstrates how to secure sensitive enterprise data that is accessed by and/or stored on employees’ mobile devices. The NIST Mobile Threat Catalogue [B23] identifies threats to mobile devices and associated mobile infrastructure to support development and implementation of mobile security capabilities, best practices, and security solutions to better protect enterprise IT. We strongly encourage organizations implementing this practice guide in whole or in part to consult these resources when developing and implementing a mobile device security plan for their organizations.

B.3 Mobile Application Security

The security qualities of an entire platform can be compromised if an application exhibits vulnerable or malicious behavior. Application security is paramount in ensuring that the security controls implemented in other architecture components can effectively mitigate threats. The practice of making sure that an application is secure is known as software assurance (SwA). This is defined as “the level of confidence that software is free from vulnerabilities, either intentionally designed into the software or accidentally inserted at any time during its lifecycle, and that the software functions in the intended manner” [B24].

In an architecture that largely relies on third-party—usually closed-source—applications to handle daily user functions, good SwA hygiene can be difficult to implement. To address this problem, NIST has released guidance on how to structure and implement an application-vetting process (also known as app vetting) [B25]. This takes an organization through the following steps:

1. understanding the process for vetting the security of mobile applications

2. planning for implementation of an app-vetting process

3. developing application security requirements

4. understanding types of application vulnerabilities and testing methods used to detect those vulnerabilities

5. determining whether an application is acceptable for deployment on the organization’s mobile devices

PSOs should carefully consider their application-vetting needs. Though major mobile-application stores, such as Apple’s iTunes Store and Google’s Play Store, have vetting mechanisms to find vulnerable and malicious applications, organizations may have needs beyond these proprietary tools. Per NIST SP 800-163, Vetting the Security of Mobile Applications [B25]:

App stores may perform app vetting processes to verify compliance with their own requirements. However, because each app store has its own unique, and not always transparent, requirements and vetting processes, it is necessary to consult current agreements and documentation for a particular app store to assess its practices. Organizations should not assume that an app has been fully vetted and conforms to their security requirements simply because it is available through an official app store. Third party assessments that carry a moniker of “approved by” or “certified by” without providing details of which tests are performed, what the findings were, or how apps are scored or rated, do not provide a reliable indication of software assurance. These assessments are also unlikely to take organization specific requirements and recommendations into account, such as federal-specific cryptography requirements.

FirstNet provides an application store specifically geared toward first responder applications. Through the FirstNet Developer Portal [B26], application developers can submit mobile applications for evaluation against its published development guidelines. The guidelines include security, scalability, and availability. Compliant applications can be selected for inclusion in the FirstNet App Store. This provides first responder agencies with a repository of applications that have been tested to a known set of standards.

PSOs should avoid the unauthorized “side loading” of mobile applications that are not subject to organizational vetting requirements.

B.4 Enterprise Mobility Management

The rapid evolution of mobile devices has introduced new paradigms for work environments, along with new challenges for enterprise IT to address. EMM solutions, as part of an EMM program, provide a variety of ways to view, organize, secure, and maintain a fleet of mobile devices. EMM solutions can vary greatly in form and function, but in general, they use platform-provided application programming interfaces. Sections 3 and 4 of NIST SP 800-124 [B27] describe the two basic approaches of EMM, along with components, capabilities, and their uses. One approach, commonly known as fully managed, controls the entire device. Another approach, usually used for bring-your-own-device situations, wraps or “containerizes” applications inside a secure sandbox so that they can be managed without affecting the rest of the device.

EMM capabilities can be grouped into four general categories:

1. General policy—centralized technology to enforce security policies of particular interest for mobile device security, such as accessing hardware sensors like GPS, accessing native OS services like a web browser or email client, managing wireless networks, monitoring when policy violations occur, and limiting access to enterprise services if the device is vulnerable or compromised

2. Data communication and storage—automatically encrypting data in transit between the device and the organization (e.g., through a virtual private network); strongly encrypting data at rest on internal and removable media storage; and wiping the device if it is being reissued to another user, has been lost, or has surpassed a certain number of incorrect unlock attempts

3. User and device authentication—requiring a device password/passcode and parameters for password strength, remotely restoring access to a locked device, automatically locking the device after an idle period, and remotely locking the device if needed

4. Applications—restricting which application stores may be used, restricting which applications can be installed, requiring specific application permissions (such as using the camera or GPS), restricting use of OS synchronization services, verifying digital signatures to ensure that applications are unmodified and sourced from trusted entities, and automatically installing/updating/removing applications according to administrative policies

PSFR organizations will have different requirements for EMM. This document does not prescribe any specific processes or procedures but assumes that they have been established in accordance with agency requirements. However, sections of this document refer to the NIST Mobile Threat Catalogue [B23], which does list the use of EMM solutions as mitigations for certain types of threats.

B.5 FIDO Enrollment Process

FIDO provides a framework for users to register a variety of different multifactor authenticators and use them to authenticate to applications and identity providers. Before an authenticator can be used in an online transaction, it must be associated with the user’s identity. This process is described in NIST SP 800-63B [B10] as authenticator binding. NIST SP 800-63B specifies requirements for binding authenticators to a user’s account both during initial enrollment and after enrollment, and recommends that relying parties support binding multiple authenticators to each user’s account to enable alternative strong authenticators in case the primary authenticator is lost, stolen, or damaged.

Authenticator binding may be an in-person or remote process, but in both cases, the user’s identity and control over the authenticator being bound to the account must be established. This is related to identity proofing, discussed in Section B.1, but requires that credentials be issued in a manner that maintains a tight binding with the user identity that has been established through proofing. PSFR organizations will have different requirements for identity and credential management; this document does not prescribe any specific processes or procedures but assumes that they have been established in accordance with agency requirements.

As an example, in-person authenticator binding could be implemented by having administrators authenticate with their own credentials and authorize the association of an authenticator with an enrolling user’s account. Once a user has one enrolled authenticator, it can be used for online enrollment of other authenticators at the same assurance level or lower. Allowing users to enroll strong multifactor authenticators based on authentication with weaker credentials, such as username and password or knowledge-based questions, can undermine the security of the overall authentication scheme and should be avoided.

Appendix C Architectural Considerations for the Mobile Application Single Sign-On Build

This appendix details architectural considerations relating to SSO with OAuth 2.0; IETF RFC 8252; and AppAuth open-source libraries, federation, and types of MFA.

C.1 SSO with OAuth 2.0, IETF RFC 8252, and AppAuth Open-Source Libraries

As stated above, SSO streamlines the user experience by enabling a user to authenticate once and to subsequently access different applications without having to authenticate again. SSO on mobile devices is complicated by the sandboxed architecture, which makes it difficult to share the session state with back-end systems between individual applications. EMM vendors have provided solutions through proprietary SDKs, but this approach requires integrating the SDK with each individual application and does not scale to a large and diverse population, such as the PSFR user community.

OAuth 2.0, when implemented in accordance with RFC 8252 (the OAuth 2.0 for Native Apps Best Current Practice), provides a standards-based SSO pattern for mobile applications. The OpenID Foundation’s AppAuth libraries [B14] can facilitate building mobile applications in full compliance with IETF RFC 8252, but any mobile application that follows RFC 8252’s core recommendation of using a shared external user-agent for the OAuth authorization flow will have the benefit of SSO.

To implement SSO with OAuth 2.0, this practice guide recommends that application developers choose one of the following options:

• Implement IETF RFC 8252 themselves. This RFC specifies that OAuth 2.0 authorization requests from native applications should be made only through external user-agents, primarily the user’s browser. This specification details the security and usability reasons for why this is the case and how native applications and authorization servers can implement this best practice. RFC 8252 also recommends the use of PKCE, as detailed in RFC 7636 [B28], which protects against authorization code interception attacks.

• Integrate the AppAuth open-source libraries (that implement RFC 8252 and RFC 7636) for mobile SSO. The AppAuth libraries make it easy for application developers to enable standards-based authentication, SSO, and authorization to application programming interfaces. This was the option chosen by the implementers of this build.

When OAuth is implemented in a native application, it operates as a public client; this presents security concerns with aspects like client secrets and redirected uniform resource identifiers (URIs). The AppAuth pattern mitigates these concerns and provides several security advantages for developers. The primary benefit of RFC 8252 is that native applications use an external user-agent (e.g., the Chrome for Android web browser) instead of an embedded user-agent (e.g., an Android WebView) for their OAuth authorization requests.

An embedded user-agent is demonstrably less secure and user-friendly than an external user-agent. Embedded user-agents potentially allow the client to log keystrokes, capture user credentials, copy session cookies, and automatically submit forms to bypass user consent. In addition, session information for embedded user-agents is stored on a per-application basis. This does not allow for SSO functionality, which users generally prefer and which this practice guide sets out to implement. Recent versions of Android and iPhone operating systems (iOS) both provide implementations of “in-application browser tabs” that retain the security benefits of using an external user-agent while avoiding visible context-switching between the application and the browser; RFC 8252 recommends their use where available. In-application browser tabs are supported in Android 4.1 and higher and in iOS 9 and higher.

AppAuth also requires that public client applications eschew client secrets in favor of PKCE, which is a standard extension to the OAuth 2.0 framework. When using the AppAuth pattern, the following steps are performed:

1. The user opens the client application and initiates a sign-in.

2. The client uses a browser to initiate an authorization request to the AS.

3. The user authenticates to the IdP.

4. The OIDC/SAML flow takes place, and the user authenticates to the AS.

5. The browser requests an authorization code from the AS.

6. The browser returns the authorization code to the client.

7. The client uses its authorization code to request and obtain an access token.

There is a possible attack vector at the end user’s device in this workflow if PKCE is not enabled. During step 6, so that the client application can receive the authorization code, the AS redirects the browser to a URI on which the client application is listening. However, a malicious application could register for this URI and attempt to intercept the code so that it may obtain an access token. PKCE-enabled clients use a dynamically generated random code verifier to ensure proof of possession for the authorization code. If the grant is intercepted by a malicious application before being returned to the client, the malicious application will be unable to use the grant without the client’s secret verifier.

AppAuth also outlines several other actions to consider, such as three types of redirect URIs, native-application client registration guidance, and reverse domain-name-based schemes. These are supported and/or enforced with secure defaults in the AppAuth libraries. The libraries are open-source and include sample code for implementation. In addition, if U2F or UAF is desired, that flow is handled entirely by the external user-agent, so client applications do not need to implement any of that functionality.

The AppAuth library takes care of several boilerplate tasks for developers, such as caching access tokens and refresh tokens, checking access-token expiration, and automatically refreshing access tokens. To implement the AppAuth pattern in an Android application by using the provided library, a developer needs to perform the following actions:

• Add the Android AppAuth library as a Gradle dependency.

• Add a redirect URI to the Android manifest.

• Add the Java code to initiate the AppAuth flow and to use the access token afterward.

• Register the application’s redirect URI with the AS.

Using the AppAuth library in an iOS application is a similar process:

• Add the AppAuth library by using either Pods or Carthage.

• Configure a custom URL scheme in the info.plist file.

• Update the view controllers and application delegate to initiate the AppAuth flow and to use the access token afterward.

• Register the application’s redirect URI with the AS.

To implement the AppAuth pattern without using a library, the user will need to follow the general guidance laid out in RFC 8252, review and follow the operating system-specific guidance in the AppAuth documentation [B14], and adhere to the requirements of both the OAuth 2.0 framework documented in RFC 6749 [B29] and the PKCE.

C.1.1 Attributes and Authorization

Authorization, in the sense of applying a policy to determine the rights and privileges that apply to application requests, is beyond the scope of this practice guide. OAuth 2.0 provides delegation of user authorizations to mobile applications acting on their behalf, but this is distinct from the authorization policy enforced by the application. This guide is agnostic to the specific authorization model (e.g., role-based access control [RBAC], attribute-based access control [ABAC], capability lists) that applications will use, and the SSO mechanism documented here is compatible with virtually any back-end authorization policy.

While applications could potentially manage user roles and privileges internally, federated authentication provides the capability for the IdP to provide user attributes to RPs. These attributes might be used to map users to defined application roles or used directly in an ABAC policy (e.g., to restrict access to sworn law enforcement officers). Apart from authorization, attributes may provide identifying information useful for audit functions, contact information, or other user data.

In the build architecture, the AS is an RP to the user’s IdP, which is either a SAML IdP or an OIDC provider. SAML IdPs can return attribute elements in the SAML response. OIDC providers can return attributes as claims in the ID token, or the AS can request them from the user information end point. In both cases, the AS can validate the IdP’s signature of the asserted attributes to ensure their validity and integrity. Assertions can also optionally be encrypted, which both protects their confidentiality in transit and enforces audience restrictions because only the intended RP will be able to decrypt them.

Once the AS has received and validated the asserted user attributes, it could use them as issuance criteria to determine whether an access token should be issued for the client to access the requested scopes. In the OAuth 2.0 framework, scopes are individual access entitlements that can be granted to a client application. In addition, the attributes could be provided to the protected resource server to enable the application to enforce its own authorization policies. Communications between the AS and protected resource are internal design concerns for the SaaS provider. One method of providing attributes to the protected resource is for the AS to issue the access token as a JavaScript Object Notation (JSON) Web Token (JWT) containing the user’s attributes. The protected resource could also obtain attributes by querying the AS’s token introspection end point, where they could be provided as part of the token metadata in the introspection response.

C.2 Federation

The preceding section discussed the communication of attributes from the IdP to the AS for use in authorization decisions. In the build architecture, it is assumed that the SaaS provider may be an RP of many IdPs supporting different user organizations. Several first responder organizations have their own IdPs, each managing its own users’ attributes. This presents a challenge if the RP needs to use those attributes for authorization. Local variations in attribute names, values, and encodings would make it difficult to apply a uniform authorization policy across the user base. If the SaaS platform enables sharing of sensitive data between organizations, participants would need some assurance that their partners were establishing and managing user accounts and attributes appropriately—promptly removing access for terminated employees and performing appropriate validation before assigning attributes that enable privileged access. Federations attempt to address this issue by creating common profiles and policies governing use and management of attributes and authentication mechanisms, which members are expected to follow. This facilitates interoperability, and members are also typically audited for compliance with the federation’s policies and practices, enabling mutual trust in attributes and authentication.

As an example, the National Identity Exchange Federation (NIEF) is a federation serving law enforcement organizations and networks, including the Federal Bureau of Investigation, the Department of Homeland Security, the Regional Information Sharing System, and the Texas Department of Public Safety. NIEF has established SAML profiles for both web-browser and system-to-system use cases, and a registry of common attributes for users, resources, and other entities. NIEF attributes are grouped into attribute bundles, with some designated as mandatory, meaning that all participating IdPs must provide those attributes, and participating RPs can depend on their presence in the SAML response.

The architecture documented in this build guide is fully compatible with NIEF and other federations, though this would require configuring IdPs and RPs in compliance with the federation’s policies. The use of SAML IdPs is fully supported by this architecture, as is the coexistence of SAML IdPs and OIDC providers.

NIST SP 800-63-3 [B17] defines Federation Assurance Levels (FALs) and their implementation requirements. FALs are a measure of the assurance that assertions presented to an RP are genuine and unaltered, pertain to the individual presenting them, are not subject to replay at other RPs, and are protected from many additional potential attacks on federated authentication schemes. A high-level summary of the requirements for FALs 1-3 is provided in Table C-1.

Table C-1 FAL Requirements

FAL	Requirement
1	Bearer assertion, signed by IdP
2	Bearer assertion, signed by IdP, and encrypted to RP
3	Holder of key assertion, signed by IdP, and encrypted to RP

IdPs typically sign assertions, and this functionality is broadly supported in available software. For SAML, the IdP’s public key is provided in the SAML metadata. For OIDC, the public key can be provided through the discovery end point, if supported; otherwise, the key would be provided to the RP out of band. Encrypting assertions is also relatively trivial and requires providing the RP’s public key to the IdP. The build architecture in this guide can support FAL-1 and FAL-2 with relative ease.

The requirement for holder of key assertions makes FAL-3 more difficult to implement. A SAML holder of key profile exists but has never been widely implemented in a web-browser SSO context. The OIDC core specification does not include a mechanism for a holder of key assertions; however, the forthcoming token binding over the Hypertext Transfer Protocol (HTTP) specification [B30] and related RFCs may provide a pathway to supporting FAL-3 in an OIDC implementation.

C.3 Authenticator Types

When considering MFA implementations, PSFR organizations should carefully consider organizationally defined authenticator requirements. These requirements may include:

• the sensitivity of data being accessed and the commensurate level of authentication assurance needed

• environmental constraints, such as gloves or masks, that may limit the usability and effectiveness of certain authentication modalities

• costs throughout the authenticator life cycle, such as authenticator binding, loss, theft, unauthorized duplication, expiration, and revocation

• policy and compliance requirements, such as the Health Insurance Portability and Accountability Act (HIPAA) [B31], the Criminal Justice Information System Security Policy [B32], or other organizationally defined requirements

• support of current IT infrastructure, including mobile devices, for various authenticator types

The new, third revision of NIST SP 800-63, Digital Identity Guidelines [B17] is a suite of documents that provide technical requirements and guidance for federal agencies implementing digital identity services, and it may assist PSFR organizations when selecting authenticators. The most significant difference from previous versions of NIST SP 800-63 is the retirement of the previous assurance rating system, known as the Levels of Assurance (LOA), established by Office of Management and Budget (OMB) Memorandum M-04-04, E-Authentication Guidance for Federal Agencies. In the new NIST SP 800-63-3 guidance, digital identity assurance is split into three ordinals as opposed to the single ordinal in LOA. The three ordinals are listed below:

• identity assurance level (IAL)

• authenticator assurance level (AAL)

• FAL

This practice guide is primarily concerned with AALs and how they apply to the reference architecture outlined in Table 3‑2.

The strength of an authentication transaction is measured by the AAL. A higher AAL means stronger authentication and requires more resources and capabilities by attackers to subvert the authentication process. We discuss a variety of multifactor implementations in this practice guide. NIST SP 800-63-3 gives us a reference to map the risk reduction of the various implementations recommended in this practice guide.

The AAL is determined by authenticator type and combination, verifier requirements, reauthentication policies, and security control baselines, as defined in NIST SP 800-53, Security and Privacy Controls for Federal Information Systems and Organizations [B33]. A summary of requirements at each of the levels is provided in Table C-2.

A memorized secret (most commonly implemented as a password) satisfies AAL1, but this alone is not enough to reach the higher levels shown in Table C-2. For AAL2 and AAL3, some form of MFA is required. MFA comes in many forms. The architecture in this practice guide describes two examples. One example is a multifactor software cryptographic authenticator, where a biometric authenticator application is installed on the mobile device—the two factors being possession of the private key and the biometric. The other example is a combination of a memorized secret and a single-factor cryptographic device, which performs cryptographic operations via a direct connection to the user end point.

Reauthentication requirements also become more stringent for higher levels. AAL1 requires reauthentication only every 30 days, but AAL2 and AAL3 require reauthentication every 12 hours. At AAL2, users may reauthenticate by using a single authentication factor, but at AAL3, users must reauthenticate by using both of their authentication factors. At AAL2, 30 minutes of idle time is allowed, but only 15 minutes is allowed at AAL3.

For a full description of the different types of multifactor authenticators and AAL requirements, please refer to NIST SP 800-63B [B10].

Table C-2 AAL Summary of Requirements

Requirement	AAL1	AAL2	AAL3
Permitted authenticator types	Memorized Secret; Lookup Secret; Out of Band; Single Factor (SF) One-Time Password (OTP) Device; Multifactor (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: Lookup 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
Federal Information Processing Standard (FIPS) 140-2 verification	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)
Reauthentication	30 days	12 hours, or after 30 minutes of inactivity; MAY use one authentication factor	12 hours, or after 15 minutes of inactivity; SHALL use both authentication factors
Security controls	NIST SP 800-53 Low Baseline (or equivalent)	NIST SP 800-53 Moderate Baseline (or equivalent)	NIST SP 800-53 High Baseline (or equivalent)
Machine-in-the-middle resistance	Required	Required	Required
Verifier-impersonation resistance	Not required	Not required	Required
Verifier-compromise resistance	Not required	Not required	Required
Replay resistance	Not required	Required	Required
Authentication intent	Not required	Recommended	Required
Records retention policy	Required	Required	Required
Privacy controls	Required	Required	Required

The FIDO Alliance has published specifications for two types of authenticators based on UAF and U2F. These protocols operate agnostic of the FIDO authenticator, allowing PSOs to choose any FIDO-certified authenticator that meets operational requirements and to implement it with this solution. As new FIDO-certified authenticators become available in the marketplace, PSOs may choose to migrate to these new authenticators if they better meet PSFR needs in their variety of duties.

C.3.1 UAF Protocol

The UAF protocol [B2] allows users to register their device to the online service by selecting a local authentication mechanism, such as swiping a finger, looking at the camera, speaking into the microphone, or entering a PIN. The UAF protocol allows the service to select which mechanisms are presented to the user. Once registered, the user simply repeats the local authentication action whenever they need to authenticate to the service. The user no longer needs to enter their password when authenticating from that device. UAF also allows experiences that combine multiple authentication mechanisms, such as fingerprint plus PIN. Data used for local user verification, such as biometric templates, passwords, or PINs, is validated locally on the device and is not transmitted to the server. Authentication to the server is performed with a cryptographic key pair, which is unlocked after local user verification.

C.3.2 U2F Protocol

The U2F protocol [B3] allows online services to augment the security of their existing password infrastructure by adding a strong second factor to user login, typically an external hardware-backed cryptographic device. The user logs in with a username and password as before and is then prompted to present the external second factor. The service can prompt the user to present a second-factor device at any time that it chooses. The strong second factor allows the service to simplify its passwords (e.g., four-digit PIN) without compromising security. During registration and authentication, the user presents the second factor by simply pressing a button on a universal serial bus (USB) device or tapping over NFC.

The user can use their FIDO U2F device across all online services that support the protocol. On desktop operating systems, the Google Chrome and Opera browsers currently support U2F. U2F is also supported on Android through the Google Authenticator application, which must be installed from the Play Store.

C.3.3 FIDO 2

The FIDO 2 project comprises a set of related standardization efforts undertaken by the FIDO Alliance and the World Wide Web Consortium (W3C). The second iteration of the FIDO standards will support the W3C’s Web Authentication standard [B16]. As a W3C recommendation, Web Authentication is expected to be widely adopted by web browser developers and to provide out-of-the-box FIDO support without the need to install additional client applications or extensions.

In addition, the proposed FIDO Client-to-Authenticator Protocol (CTAP) standard will support new authenticator functions, including the ability to set a PIN on authenticators such as YubiKeys. By requiring a PIN at authentication time, a CTAP-compliant authenticator can provide MFA in a manner similar to a smart card. This would eliminate the need to pair an external authenticator with an existing knowledge factor such as username/password authentication against an LDAP database, as was used in the U2F implementation of this build.

C.3.4 FIDO Key Registration

From the perspective of an IdP, enabling users to authenticate themselves with FIDO-based credentials requires that users register a cryptographic key with the IdP and associate the registered key with the username or distinguished name known to the IdP. FIDO registration must be repeated for each authenticator that the user chooses to associate with their account. FIDO protocols are different from most authentication protocols in that they permit registering multiple cryptographic keys (from different authenticators) to use with a single account. This is convenient for end users as it provides a natural backup solution to lost, misplaced, or forgotten authenticators—users may use any one of their registered authenticators to access their applications.

The process of a first-time FIDO key registration is fairly simple:

1. A user creates an account for themselves at an application site, or one is created for them as part of a business process.

2. The user registers a FIDO key with the application through one of the following processes:

   1. as part of the account self-creation process

   2. upon receiving an email with an invitation to register

   3. as part of a registration process, after an authentication process within an organization application

   4. A FIDO authenticator with a temporary, preregistered key is provided so that the user can strongly authenticate to register a new key with the application, at which point the temporary key is deleted permanently. Authenticators with preregistered keys may be combined with shared secrets given/sent to the user out of band to verify their identity before enabling them to register a new FIDO key with the organization’s application.

   5. as part of a custom process local to the IdP

Policy at the organization dictates what might be considered most appropriate for a registration process.

C.3.5 FIDO Authenticator Attestation

To meet AAL requirements, RPs may need to restrict the types of FIDO authenticators that can be registered and used to authenticate. They may also require assurances that the authenticators in use are not counterfeit or vulnerable to known attacks. The FIDO specifications include mechanisms that enable the RP to validate the identity and security properties of authenticators, which are provided in a standard metadata format.

Each FIDO authenticator has an attestation key pair and certificate. To maintain FIDO’s privacy guarantees, these attestation keys are not unique for each device but are typically assigned on a manufacturing batch basis. During authenticator registration, the RP can check the validity of the attestation certificate and validate the signed registration data to verify that the authenticator possesses the private attestation key.

For software authenticators, which cannot provide protection for a private attestation key, the UAF protocol allows for surrogate basic attestation. In this mode, the key pair generated to authenticate the user to the RP is used to sign the registration data object, including the attestation data. This is analogous to the use of self-signed certificates for HTTPS in that it does not actually provide cryptographic proof of the security properties of the authenticator. A potential concern is that the RP could not distinguish between a genuine software authenticator and a malicious look-alike authenticator that could provide registered credentials to an attacker. In an enterprise setting, this concern could be mitigated by delivering the valid authenticator application using EMM or another controlled distribution mechanism.

Authenticator metadata would be most important in scenarios where an RP accepts multiple authenticators with different assurance levels and applies authorization policies based on the security properties of the authenticators (e.g., whether they provide FIPS 140-2-validated key storage [B34]). In practice, most existing enterprise implementations use a single type of authenticator.

C.3.6 FIDO Deployment Considerations

To support any of the FIDO standards for authentication, some integration needs to happen on the server side. Depending on how the federated architecture is set up—whether with OIDC or SAML—this integration may look different. In general, there are two servers where a FIDO server can be integrated: the AS (also known as the RP) and the IdP.

FIDO Integration at the IdP

Primary authentication already happens at the IdP, so logic follows that FIDO authentication (e.g., U2F, UAF) would as well. This is the most common and well-understood model for using a FIDO authentication server and, consequently, there is solid guidance for setting up such an architecture. The IdP already has detailed knowledge of the user and directly interacts with the user (e.g., during registration), so it is not difficult to insert the FIDO server into the registration and authentication flows. In addition, this gives PSOs the most control over the security controls that are used to authenticate their users. However, there are a few downsides to this approach:

• The PSO must now budget, host, manage, and/or pay for the cost of the FIDO server.

• The only authentication of the user at the AS is the bearer assertion from the IdP, so an assertion intercepted by an attacker could be used to impersonate the legitimate user at the AS.

FIDO Integration at the AS

Another option is to integrate FIDO authentication at the AS. One benefit of this is that PSOs will not be responsible for the expenses of maintaining a FIDO server. In addition, an attacker who intercepted a valid user’s SAML assertion or ID token could not easily impersonate the user because of the requirement to authenticate to the AS as well. This approach assumes that some mechanism is in place for tightly binding the FIDO authenticator with the user’s identity, which is a nontrivial task. In addition, this approach has several downsides:

• Splitting authentication into a two-stage process that spans the IdP and AS is a less well understood model for authentication, which may lead to subtle issues.

• The AS does not have detailed knowledge of—or direct action with—users, so enrollment is more difficult.

• Users would have to register their FIDO authenticators at every AS that is federated to their IdP, which adds complexity and frustration to the process.

• PSOs would lose the ability to enforce which kinds of FIDO token(s) their users utilize.

Appendix D Acronyms

AAL	Authenticator Assurance Level
ABAC	Attribute-Based Access Control
API	Application Programming Interface
AS	Authorization Server
BCP	Best Current Practice
CJIS	Criminal Justice Information Services
CNSS	Committee on National Security Systems
CRADA	Cooperative Research and Development Agreement
CTAP	Client-to-Authenticator Protocol
EMM	Enterprise Mobility Management
FAL	Federation Assurance Level
FIDO	Fast Identity Online
FIPS	Federal Information Processing Standard
FirstNet	First Responder Network Authority
GPS	Global Positioning System
HIPAA	Health Insurance Portability and Accountability Act
HTML	Hypertext Markup Language
HTTP	Hypertext Transfer Protocol
HTTPS	Hypertext Transfer Protocol Secure
IA	Information Assurance
IAL	Identity Assurance Level
ID	Identification
IdP	Identity Provider
IEC	International Electrotechnical Commission
IETF	Internet Engineering Task Force
iOS	iPhone Operating System
ISO	International Organization for Standardization
IT	Information Technology
JSON	JavaScript Object Notation
JWT	JSON Web Token
LOA	Level of Assurance
MF	Multifactor
MFA	Multifactor Authentication
MMS	Multimedia Messaging Service
MSSO	Mobile Single Sign-On
MTC	Mobile Threat Catalogue
NCCoE	National Cybersecurity Center of Excellence
NFC	Near Field Communication
NIEF	National Identity Exchange Federation
NIST	National Institute of Standards and Technology
NTP	Network Time Protocol
OEM	Original Equipment Manufacturer
OIDC	OpenID Connect
OMB	Office of Management and Budget
OOB	Out of Band
OS	Operating System
OTP	One-Time Password
PII	Personally Identifiable Information
PIN	Personal Identification Number
PKCE	Proof Key for Code Exchange
PSCR	Public Safety Communications Research Division
PSFR	Public Safety and First Responder
PSO	Public Safety Organization
PSX	Public Safety Experience
RBAC	Role-Based Access Control
RCS	Rich Communication Services
RFC	Request for Comments
RP	Relying Party
SaaS	Software as a Service
SAML	Security Assertion Markup Language
SD	Secure Digital
SDK	Software Development Kit
SF	Single Factor
SIM	Subscriber Identity Module
SKCE	StrongKey Crypto Engine
SMS	Short Message Service
SP	Special Publication
SSO	Single Sign-On
SwA	Software Assurance
TLS	Transport Layer Security
U2F	Universal Second Factor
UAF	Universal Authentication Framework
UI	User Interface
UICC	Universal Integrated Circuit Card
URI	Uniform Resource Identifier
URL	Uniform Resource Locator
USB	Universal Serial Bus
USIM	Universal Subscriber Identity Module
USSD	Unstructured Supplementary Service Data
VoLTE	Voice over Long-Term Evolution
W3C	World Wide Web Consortium

Appendix E References

B1

W. Denniss and J. Bradley, OAuth 2.0 for Native Apps, Best Current Practice 212, Internet Engineering Task Force (IETF) Network Working Group Request for Comments (RFC) 8252, Oct. 2017. Available: https://www.rfc-editor.org/info/rfc8252.

B2

S. Machani et al., FIDO UAF Architectural Overview: FIDO Alliance Implementation Draft, FIDO Alliance, Wakefield, Mass., 2017. Available: https://fidoalliance.org/specs/fido-uaf-v1.1-id-20170202/fido-uaf-overview-v1.1-id-20170202.html.

B3

S. Srinivas et al., Universal 2nd Factor (U2F) Overview: FIDO Alliance Proposed Standard, FIDO Alliance, Wakefield, Mass., 2017. Available: https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-overview-v1.2-ps-20170411.html.

B4

S. Cantor et al., Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS Standard, Mar. 2005. Available: https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf.

B5

N. Sakimura et al., OpenID Connect Core 1.0 incorporating errata set 1, Nov. 2014. Available: https://openid.net/specs/openid-connect-core-1_0.html.

B6

Joint Task Force, Guide for Conducting Risk Assessments, National Institute of Standards and Technology (NIST) Special Publication (SP) 800-30 Revision 1, Gaithersburg, Md., Sept. 2012. Available: https://doi.org/10.6028/NIST.SP.800-30r1.

B7

Joint Task Force, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy, NIST SP 800‑37 Revision 2, Gaithersburg, Md., Feb. 2010. Available: https://doi.org/10.6028/NIST.SP.800-37r2.

B8

C. Johnson et al., Guide to Cyber Threat Information Sharing, NIST SP 800-150, Gaithersburg, Md., Oct. 2016. Available: https://doi.org/10.6028/NIST.SP.800-150.

B9

C. Brown et al., Assessing Threats to Mobile Devices & Infrastructure: The Mobile Threat Catalogue, Draft NIST Interagency Report 8144, Gaithersburg, Md., Sept. 2016. Available: https://nccoe.nist.gov/sites/default/files/library/mtc-nistir-8144-draft.pdf.

B10(1,2)

P. Grassi et al., Digital Identity Guidelines: Authentication and Lifecycle Management, NIST SP 800-63B, Gaithersburg, Md., June 2017. Available: https://doi.org/10.6028/NIST.SP.800-63b.

B11

P. Grassi et al., Digital Identity Guidelines: Federation and Assertions, NIST SP 800-63C, Gaithersburg, Md., June 2017. Available: https://doi.org/10.6028/NIST.SP.800-63c.

B12

International Organization for Standardization/International Electrotechnical Commission/Institute of Electrical and Electronics Engineers, Systems and software engineering—System life cycle processes, ISO/IEC/IEEE 15288:2015, 2015. Available: https://www.iso.org/standard/63711.html.

B13

R. Ross et al., Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems, NIST SP 800-160, Gaithersburg, Md., Nov. 2016. Available: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-160v1.pdf

B14(1,2)

AppAuth. AppAuth. Available: https://appauth.io/.

B15

M. Jones and D. Hardt, The OAuth 2.0 Authorization Framework: Bearer Token Usage, IETF Network Working Group RFC 6750, Oct. 2012. Available: https://www.rfc-editor.org/info/rfc6750.

B16

D. Balfanz et al., Web Authentication: An API for accessing Public Key Credentials Level 1, W3C Recommendation, Mar. 2019. Available: https://www.w3.org/TR/webauthn/.

B17(1,2)

P. Grassi et al., Digital Identity Guidelines, NIST SP 800‑63-3, Gaithersburg, Md., June 2017. Available: https://pages.nist.gov/800-63-3/.

B18

A. Popov et al., The Token Binding Protocol Version 1.0, IETF Network Working Group RFC 8471, Oct. 2018. Available: https://www.rfc-editor.org/info/rfc8471.

B19

T. Lodderstedt, Ed., et al., OAuth 2.0 Threat Model and Security Considerations, IETF Network Working Group RFC 6819, Jan. 2013. Available: https://www.rfc-editor.org/info/rfc6819.

B20

NIST. NIST Internet Time Servers. Available: https://tf.nist.gov/tf-cgi/servers.cgi.

B21

P. Grassi et al., Digital Identity Guidelines: Enrollment and Identity Proofing, NIST SP 800-63A, Gaithersburg, Md., June 2017. Available: https://doi.org/10.6028/NIST.SP.800-63a.

B22

J. Franklin et al., Mobile Device Security: Cloud and Hybrid Builds, NIST SP 1800-4, Gaithersburg, Md., Nov. 2015. Available: https://www.nccoe.nist.gov/sites/default/files/library/sp1800/mds-nist-sp1800-4-draft.pdf.

B23(1,2)

C. Brown et al., Mobile Threat Catalogue, NIST, 2016. Available: https://pages.nist.gov/mobile-threat-catalogue/.

B24

Committee on National Security Systems (CNSS), National Information Assurance (IA) Glossary, CNSS Instruction Number 4009, Apr. 2015. Available: https://rmf.org/wp-content/uploads/2017/10/CNSSI-4009.pdf.

B25(1,2)

M. Ogata et al., Vetting the Security of Mobile Applications, NIST SP 800-163 Revision 1, Gaithersburg, Md., Apr. 2019. Available: https://doi.org/10.6028/NIST.SP.800-163r1

B26

First Responder Network Authority. FirstNet Developer Portal. Available: https://developer.firstnet.com/firstnet.

B27

M. Souppaya and K. Scarfone, Guidelines for Managing the Security of Mobile Devices in the Enterprise, NIST SP 800-124 Revision 1, Gaithersburg, Md., June 2013. Available: https://doi.org/10.6028/NIST.SP.800-124r1.

B28

N. Sakimura et al., Proof Key for Code Exchange by OAuth Public Clients, IETF Network Working Group RFC 7636, Sept. 2015. Available: https://www.rfc-editor.org/info/rfc7636.

B29

D. Hardt, Ed., The OAuth 2.0 Authorization Framework, IETF Network Working Group RFC 6749, Oct. 2012. Available: https://www.rfc-editor.org/info/rfc6749.

B30

A. Popov et al., Token Binding over HTTP, IETF Network Working Group RFC 8473, Oct. 2018. Available: https://www.rfc-editor.org/info/rfc8473.

B31

U.S. Department of Labor, Employee Benefits Security Administration. Fact Sheet: The Health Insurance Portability and Accountability Act (HIPAA). Available: https://permanent.access.gpo.gov/gpo10291/fshipaa.html.

B32

Criminal Justice Information Services (CJIS) Security Policy, Version 5.6, U.S. Department of Justice, Federal Bureau of Investigation, Criminal Justice Information Services Division, June 2017. Available: https://www.fbi.gov/services/cjis/cjis-security-policy-resource-center.

B33

Joint Task Force, Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53 Revision 4, Gaithersburg, Md., Jan. 2015. Available: https://dx.doi.org/10.6028/NIST.SP.800-53r4.

B34

U.S. Department of Commerce. Security Requirements for Cryptographic Modules, Federal Information Processing Standards (FIPS) Publication 140-2, May 2001. Available: https://doi.org/10.6028/NIST.FIPS.140-2.