3.2.4 - Install Usb Devices
Pelagio Bosch
Certain commercial entities, equipment, products, or materials may be identified by name or company logo or other insignia in order to acknowledge theirparticipation in this collaboration or to describe an experimental procedure or concept adequately. Such identification is not intended to imply special statusor relationship with NIST or recommendation or endorsement by NIST or NCCoE; neither is it intended to imply that the entities, equipment, products, ormaterials are necessarily the best available for the purpose.
As a private-public partnership, we are always seeking feedback on our practice guides. We are particularly interested in seeing how businesses apply NCCoEreference designs in the real world. If you have implemented the reference design, or have questions about applying it in your environment, please email us atpsfr...@nist.gov.
NIST Cybersecurity Practice Guides (Special Publication 1800 series) target specific cybersecurity challenges in the public and private sectors. They arepractical, user-friendly guides that facilitate the adoption of standards-based approaches to cybersecurity. They show members of the information securitycommunity how to implement example solutions that help them align with relevant standards and best practices and provide users with the materials lists,configuration files, and other information they need to implement a similar approach.
The documents in this series describe example implementations of cybersecurity practices that businesses and other organizations may voluntarily adopt. Thesedocuments do not describe regulations or mandatory practices, nor do they carry statutory authority.
This practice guide describes a reference design for multifactor authentication (MFA) and mobile single sign-on (MSSO) for native and web applications, whileimproving interoperability among mobile platforms, applications, and identity providers, regardless of the application development platform used in theirconstruction. This guide discusses major architecture design considerations, explains security characteristics achieved by the reference design, and maps thesecurity characteristics to applicable standards and security control families. For parties interested in adopting all or part of the reference architecture,this guide includes a detailed description of the installation, configuration, and integration of all components.
The Technology Partners/Collaborators who participated in this build submitted their capabilities in response to a notice in the Federal Register.Respondents with relevant capabilities or product components were invited to sign a Cooperative Research and Development Agreement (CRADA) with NIST, allowingthem to participate in a consortium to build this example solution. We worked with:
NOTICE: The Information Technology Laboratory (ITL) has requested that holders of patent claims whose use may be required for compliance with the guidance orrequirements of this publication disclose such patent claims to ITL. However, holders of patents are not obligated to respond to ITL calls for patents and ITLhas not undertaken a patent search in order to identify which, if any, patents may apply to this publication.
As of the date of publication and following call(s) for the identification of patent claims whose use may be required for compliance with the guidance orrequirements of this publication, no such patent claims have been identified to ITL.
Since May 2018, when this project build was initially completed at the NCCoE laboratory, some of the products used in the build have migrated to new platforms.In addition, new specifications and standards used by the products have been published and revised. While the general integration concepts demonstrated in thisguide still apply, implementers using newer or different products will have to tailor their implementation to meet the specific requirements of those productsand specifications. Thus, the implementation details will be different.
This National Institute of Standards and Technology (NIST) Cybersecurity Practice Guide demonstrates a standards-based example solution and provides users withthe information they need to replicate this approach to implementing our MSSO build. The example solution is modular and can be deployed in whole or in part.
The National Cybersecurity Center of Excellence (NCCoE) worked with its build team partners to create a lab demonstration environment that includes all of thearchitectural components and functionality described in Section 4 of Volume B of this build guide. This includes mobile devices with sample applications,hardware and software-based authenticators to demonstrate the Fast Identity Online (FIDO) standards for MFA, and the authentication server and authorizationserver (AS) components required to demonstrate the AppAuth authorization flows (detailed in Internet Engineering Task Force [IETF] Request for Comments [RFC]8252 [C1] ) with federated authentication to a Security Assertion Markup Language (SAML) Identity Provider (IdP) and an OpenID Connect (OIDC)provider. The complete build includes several systems deployed in the NCCoE lab by StrongKey, Yubico, and Ping Identity as well as cloud-hosted resources madeavailable by Motorola Solutions and by Nok Nok Labs.
The build architecture supports three usage scenarios. The scenarios all demonstrate single sign-on (SSO) among Motorola Solutions Public Safety Experience(PSX) applications and custom-built Apple iPhone operating system (iOS) demo applications using the AppAuth pattern, but differ in the details of theauthentication process. The three authentication mechanisms are as follows:
The fictitious .msso top-level domain is simply a reference to the MSSO project. The demonstration applications hosted in the CPSSP VLAN were used toinitially test and validate the federation setups in the user organization and were later expanded to support the iOS demonstration build.
In a typical production deployment, the NNAS would not be directly exposed to the internet; instead, mobile client interactions with the Authentication ServerAPIs would traverse a reverse proxy server. Nok Nok Labs provided a cloud instance of its software as a matter of expedience in completing the lab build.
Additionally, the use of a VPN client on mobile devices is optional. Many organizations directly expose their IdPs to the public internet, though someorganizations prefer to keep those services internal and use a VPN to access them. Organizations can decide this based on their risk tolerance, but this buildarchitecture can function with or without a VPN client on the mobile devices.
Some general infrastructure elements must be in place to support the components of this build guide. These are assumed to exist in the environment prior to theinstallation of the architecture components in this guide. The details of how these services are implemented are not directly relevant to the build.
This section covers all of the different aspects of installing and configuring the mobile device. There are several prerequisites and different components thatneed to work in tandem for the entire SSO architecture to work.
In iOS 12, Apple replaced the SFAuthenticationSession API with ASWebAuthenticationSession [C7], which performs the same functions asSFAuthenticationSession and presents an identical consent prompt. In lab testing, the build team frequently encountered issues with SFAuthenticationSessionwhere cookies created in an SFAuthenticationSession spawned by one application were not available in an SFAuthenticationSession spawned by another application.When this issue occurred, users would be prompted to authenticate in each application that was launched and SSO did not function properly. The team has notencountered these issues with ASWebAuthenticationSession, and the SSO capabilities of in-application browser tabs are much improved in iOS 12.
The build team encountered issues with the FIDO UAF login flow demonstrated in this practice guide and the iOS in-application browser tab APIs(SFAuthenticationSession and ASWebAuthenticationSession). In the demo scenario, the login flow begins in the browser, which then launches the Passportapplication for user verification and FIDO authentication, and then control is returned to the browser to complete the authentication flow and return the userto the application. With ASWebAuthenticationSession, the authentication flow begins successfully in an in-application browser tab, and the user is redirected tothe Passport application to authenticate, but control is not properly returned to the in-application browser tab when the Passport application closes. SeeSection 4.3.2 of Volume B of this practice guide for additional details about this issue. The build team speculates that this issue would generally apply to anylogin flow that entails launching an external application and then returning control to an in-application browser tab.
Chrome for Android [C9] is a U2F-compatible browser. Google has added U2F functionality to the Google Play Services component of Android[C10], so devices running Android 5 and later can natively support U2F authentication over NFC, Universal Serial Bus (USB), and Bluetooth LowEnergy (BLE) with an over-the-air update to Play Services. To support U2F in the browser, the Google Authenticator application [C11](available on Android Gingerbread [2.3.3] and up) must also be installed.
Yubico has announced development of an authenticator with a Lightning adapter, specifically targeting iOS and Mac devices; and a corresponding mobile softwaredevelopment kit (SDK) for iOS that could enable U2F authentication in native iOS applications [C13]. To enable the AppAuth login flow used inthis practice guide, a U2F-capable browser is also needed. If Apple adds W3C Web Authentication support to the Safari browser, it may support U2F authenticationover Lightning and BLE in the future. Apple has already added experimental support to the Safari Technology Preview release for Mac OS [C14].
4a15465005