TECHNOLOGY AREA(S): Info Systems
OBJECTIVE: Define and develop a software-based solution the U.S. Navy to validate the existence and security posture of government-purpose mobile apps that use Multi-Factor Authentication (MFA) into mobile device applications would employ differing categories (knowledge, possession, and inherence) in concert to authenticate users relying on varying infrastructure to ensure continuity of service during single (ideally multiple) points of failure.
DESCRIPTION: One of the Navys greatest Information Technology (IT) challenges involves providing an efficient, effective, and trusted means to authenticate users of its myriad electronic systems. The de facto Personal Identity Verification (PIV) standard (Common Access Card, CAC) has helped homogenize authentication schemes the wider DoD uses, but that introduces its own challenges in the mobile computing space and its sunset is eminent. Legacy alternatives to authentication utilizing only a single factor such as assigned user names and user-generated passwords cost the Navy dearly. IT resources spent on forgotten passwords and mandatory password changes eat up thousands of call center hours per year. Data breaches are the natural consequence of centrally hosting thousands of user credentials. All of this takes its toll on the end users as well, reducing efficiency of use, confidence in Navy IT practices, and ultimately satisfaction with Navy systems. The Navy needs a flexible, efficient, trusted, and user-friendly authentication solution that consumes fewer IT resources and brings more satisfaction to the Sailors and the wider Navy community. MFA solutions are employed widely in the civilian IT space. These solutions have allowed the civilian industry to achieve maximum participation, promote ease-of-use for the end-user, and minimize expensive tech support resource utilization. The Navy is looking to replicate the success seen there. The Navy desires MFA solutions that are coherent, tested, robust, and easy-to-integrate into new and legacy mobile solutions. Services providing MFA must be trusted and flexible enough to meet the security and reliability needs of the fleet and wider Navy community. The accreditation model produced for this topic should ensure any MFA solution under consideration is composed of, at a minimum, two of the following authentication factors: Knowledge “ something the user knows (e.g. password, Personal Identification Number, PIN) Possession “ something the user has (e.g. PIV card, smart chip) Inherence “ a characteristic the user cannot change (i.e. biometrics) The accreditation model should evaluate MFA solutions with respect to the containment of authentication tokens they produce, specifically methods of: Identity Proofing and Registration Token Storage (token and credential management mechanisms used to establish and maintain token and credential information) Token Passing (assertion mechanisms used to communicate the results of a remote authentication if these results are sent to other parties) The accreditation model should also ensure MFA solutions under consideration by the Navy contain a variety of delivery methods (network infrastructure, protocols, etc.) for these factors. Reliance on a single delivery mechanism (e.g. only using Short Message Service, SMS) or even two pathways presents an infrastructure risk to any authentication system. If the single delivery method goes down, users will be unable to authenticate, disrupting service entirely, even if the infrastructure serving the content and business services remains up. Continuity of authentication support can only be guaranteed if the various factors comprised in the MFA solution use more than one method of delivery (e.g. using TCP to transmit the username and password while SMS delivers a one-time password (OTP) to the users mobile phone). The processes and standards should evaluate MFA solutions based upon criterion established in DoD guidance documents and any other industry best practices found to be relevant to MFA. To increase the chances of Navy Approval Authority acceptance, the accreditation model should borrow heavily from existing, relevant standards established by the DoD which provide a decent baseline, but leave much work to be done, especially vis-Ã-vis mobile authentication solutions. The Navy has encountered several challenges in establishing the procedures and standards solicited in this topic. Innovative small business engineers and experts may fair better, but would do well to keep in mind some of the challenges inherent in this task: MFA is fast-changing technical landscape with new, competing solutions emerging, each with their own well-advertised strengths and often-overlooked flaws Its difficult for regulations to maintain pace with innovation in the marketplace MFA solutions involve a variety of sensors, protocols, encryption methods, and data formats, making the process to certify and accredit these solutions multifaceted and quite technical
PHASE I: Research, analyze, and define a draft set of standards by which MFA solutions will be evaluated and accredited by Navy Approving Official (NAO). PMW 240 will provide a relevant set of use cases with varying attributes for consideration including personally owned and personally enabled, personally owned corporately enabled (Mobile application management), and corporately owned corporately enabled (GFE devices). These use cases also include considerations for personal controlled unclassified information vs corporate controlled unclassified information (more than personal) and general requirements to drive research and tailor the final standards. The hub of these procedures and standards will be a questionnaire for MFA solution providers to fill out when soliciting the Navy for business. A competent Navy Approval Authority should notionally vet these standards for clarity, concision, and applicability to the Navys needs. PMW 240 will coordinate with the NAO as appropriate. PMW 240 will provide a relevant set of use cases with varying attributes for consideration including personally owned and personally enabled, personally owned corporately enabled (Mobile application management), and corporately owned corporately enabled (GFE devices). These use cases also include considerations for personal controlled unclassified information vs corporate controlled unclassified information (more than personal). Specifics to the software solution, such as platform compatibility and code base, will be provided to the small business during this phase.
PHASE II: Based on the Phase II Statement of Work (SOW), the small business will develop the software solution designed in Phase I. The small business will develop two mobile apps for sailors to view their personnel record information on Android and iOS mobile operating systems. They will use the developed software validation tool to execute the validation process end to end against the two mobile apps. Performance of these objectives will be evaluated by PMW 240 and the Navys designated approval authority overseeing the certification and accreditation process.
PHASE III: The small business will deploy and manage the software solution developed in Phase II to the Navy IT community, overseen by PEO EIS. The Phase III SOW will specify the Navy IT organizations the company will collaborate with and describe in detail expectations for validating mobile applications in the future. PMW 240 is assisting PEO EIS with establishing the Navy Mobile Center of Excellence. This includes the hosting of the Navy mobile app locker and defining the process and standards for development and deployment of Navy approved mobile apps. This capability will greatly assist the cyber security aspects of mobile app development, and certification and accreditation.
1. NIST Special Publication 800-124 Revision 1 (final) June 2013. Guidelines for Managing the Security of Mobile Devices in the Enterprise Accessed on 7 Nov 2016. http://dx.doi.org/10.6028/NIST.SP.800-124r1
2. NIST Special Publication 800-63-2 August 2013 Electronic Authentication Guideline Accessed on 7 Nov 2016. http://dx.doi.org/10.6028/NIST.SP.800-63-2
3. Internet Engineering Task Force (IETF) TOTP: Time-Based One-Time Password Algorithm Accessed on 7 Nov 2016. https://tools.ietf.org/html/rfc6238
4. Ramona Adams (ExecutiveGov.com) Terry Halvorsen: DoD to Replace Common Access Cards With Multifactor Authentication Systems" Accessed on 7 Nov 2016. http://www.executivegov.com/2016/06/terry-halvorsen-dod-to-replace-common-access-cards-with-multifactor
5. Shaun Waterman (FedScoop.com) DOD plans to eliminate CAC login within two years Accessed on 7 Nov 2016. http://fedscoop.com/dod-plans-to-eliminate-login-with-cac-cards"
KEYWORDS: Multi-Factor Authentication; MFA; Access Control; Certification; Accreditation; C&A; One-time Passcode; One-time Password; OTP; Time-Based One-Time Password; TOTP; Encryption; Identity And Access Management; IdAM; IAM; Identity Proofing; Tokens; Assertion Mechanisms; Protocols; Cryptographic Key; Cyber Security; CS; Information Assurance; IA