MODIFICATION
D -- The purpose of this modification is to extend the RFI response date to December 7, 2011.
- Notice Date
- 12/1/2011
- Notice Type
- Modification/Amendment
- NAICS
- 541519
— Other Computer Related Services
- Contracting Office
- Contracting Center of Excellence (NCR-CC), 200 Stovall Street, 11TH Floor, Alexandria, VA 22331-1700
- ZIP Code
- 22331-1700
- Solicitation Number
- W91WAWPMNES1
- Archive Date
- 11/30/2012
- Point of Contact
- Hamilton D. Cunningham, 703.325.2239
- E-Mail Address
-
Contracting Center of Excellence (NCR-CC)
(hamilton.d.cunningham@us.army.mil)
- Small Business Set-Aside
- N/A
- Description
- Request for Information (RFI) for Program Management Network and Enterprise Services (PM NES) Of User-based Authentication Technologies Army Contracting Command National Capitol Region 200 Stovall Street Alexandria, Virginia 22331-1700 THIS REQUEST FOR INFORMATION (RFI) SUPPORTS THE ESTABLISHMENT OF A MOBILE DEVICE MANAGEMENT SYSTEM SERVICING THE DEPARTMENT OF DEFENSE TO FACILITATE ENTERPRISE MANAGEMENT OF MOBILE DEVICES. Table of Contents 1.0Background4 2.0Introduction4 3.0Vendor Instructions4 4.0Request for General Information6 5.0Objective6 6.0Request for Technical Information7 7.0Constraints8 8.0Transition and Transformation9 1.0Background Today, the Common Access Card (CAC) is the standard form of identification issued to all military, civilian, and contractor personnel by the United States Department of Defense (DoD). The CAC serves as both a visual confirmation of a user's identity as well as a digital authentication token. Complemented with a corresponding smart card reader, the CAC enables users to access DoD computers, networks, and facilities as well as encrypt and cryptographically sign email using Public Key Infrastructure (PKI). As the DoD workforce shifts from a physical desktop-oriented work environment to a virtually-connected mobile office presence, the reliance on CAC readers to provide a means of identity authentication has become outdated and cumbersome. With computing technologies moving towards more agile and travel-friendly form factors, like smartphones and tablets, the need for an equally mobile and integrated solution to provide user authentication is paramount in order to elicit wide acceptance and adoption from the DoD community. 2.0Introduction This RFI is a means of technical discovery and information gathering from members of industry. Program Management Network and Enterprise Services (PM NES) seeks to (1) become familiar with the current state of the market with respect to hardware and software-based certificate solutions and (2) identify commercially available technologies that could lend themselves well to user-based authentication in a mobile environment and be cost-effective to deploy across millions of users throughout DoD. 3.0Vendor Instructions DISCLAIMER THE GOVERNMENT DOES NOT INTEND TO AWARD A CONTRACT ON THE BASIS OF THIS RFI OR OTHERWISE PAY FOR INFORMATION RECEIVED IN RESPONSE TO THE RFI. This RFI is issued for information and planning purposes only and does not constitute a solicitation. All information received in response to the RFI that is marked Proprietary will be handled accordingly. The Government shall not be liable for or suffer any consequential damages for any proprietary information not properly identified. Proprietary information will be safeguarded in accordance with the applicable Government regulations. Responses to the RFI will not be returned nor will the Government confirm receipt of the RFI response. Whatever information is provided in response to this RFI will be used to access tradeoffs and alternatives available for determining how to proceed in the acquisition process. In accordance with FAR 15.201(e), responses to this RFI are not offers and cannot be accepted by the Government to form a binding contract. The anticipated North American Industry Classification System Code (NAICS) for this requirement is 541519 (size standard $25M). Small businesses are strongly encouraged to provide responses to this RFI, in order to assist Secure Go Mobile in determining the potential levels of interest, competition and technical capability to provide the required services within the Small Business community. In addition, this information will also be used to assist Secure Go Mobile in establishing a basis for developing any subsequent potential subcontract plan small business goal percentages. Submission Instructions Responses should include the (1) business name and address; (2) name of company representative and their business title; (3) contract vehicles that would be available to the Government for the procurement of the product and service, to include General Service Administration (GSA) Federal Supply Schedules (FSS), or any other Government Agency contract vehicle. The responses should be in a white paper format, no longer than twenty-five (25) pages in length. Responses to this RFI are due NLT Wednesday 7 December 2011 at 5:00 PM Eastern (EST). Contact POC is Gregory Clark (gregory.clark5@us.army.mil). Proprietary Statement Proprietary information and trade secrets, if any, must be clearly marked on all materials. All information received that is marked Proprietary will be handled accordingly. Please be advised that all submissions become Government property and will not be returned. Responses will be reviewed by government personnel and PM NES PMSS support contractor personnel from SNVC, Inc. All government and contractor personnel reviewing RFI responses will have signed non-disclosure agreements and understand their responsibility for proper use and protection from unauthorized disclosure of proprietary information as described in 41 USC 423. The Government shall not be held liable for any damages incurred if proprietary information is not properly identified. Contracting Office Address: 200 Stovall Street Hoffman Building 1 10th Floor, Room 10S67 Alexandria, Virginia 22331-1700 United States Place of Performance: Non-U.S. United States Primary Point of Contact.: Gregory Clark, Contracting Officer gregory.clark5@us.army.mil Phone: 703.325.6542 4.0 Request for General Information 1.Describe your organization. What products/services does your organization provide and how are they applicable to this RFI? 2.If possible, please describe client organizations/agencies within the DoD and federal government community that have used your products/services for this particular use case. What was the size and scope of their deployments? 3.Describe your organization's experience with and expertise in providing hardware/software-based certificates and/or applicable technologies. 4.Please provide any additional information about your organization which you feel distinguishes you as a provider of, or authority on, hardware/software-based certificates and/or applicable technologies. 5.Please describe your solution/product. Please describe a future roadmap for your organization as well as your product. What features and/or capabilities do you plan to integrate in future versions of your product? Please provide a tentative timeline of capability milestones, if applicable. 6.What is your current year-to-date (YTD) revenue in this industry? 7.Please provide market penetration and level of financial funding to meet product improvement and marketing goals in the next 5 years. 8.Does your MDM solution have DoD Information Assurance Certification and Accreditation Process (DIACAP) accreditation, Certificate of Networthiness (CoN), Security Technical Implementation Guide (STIG), and/or equivalent qualifications which permit use of your product on the DoD network? Please list all relevant certifications. 9.What are your standard contract terms and conditions? 10.Please provide any additional information about your organization which you feel distinguishes you as a provider of, or authority on, hardware/software-based certificates and/or applicable technologies. 5.0Objective Ideally, the product should provide the following capabilities: 1.Support for iOS 5.x, Android 2.x and 3.x, Blackberry 6.x and 7.x, and Windows Phone 7 (WP7) mobile device platforms 2.Support for DoD's Public Key Infrastructure (PKI) a.Provide signing and encrypting capability 3.Support for authentication: a.To the mobile device itself b.To the downstream networks, applications and other services 4.Support for multi-factor authentication (minimum of two factors): a.Biometrics (hand, iris, face, etc.) b.PIN/passcode c.Hard/soft certificate d.Voice e.Etc. 5.Minimize the weight and/or number of items that a user must possess in order to authenticate effectively 6.Minimize the number of steps, while preserving the same level of security of the external CAC reader, required by the user to process CAC credentials in order to perform CAC/PKI communications (i.e., sending encrypted emails, etc.) 7.Leverage an existing capability/functionality available on smartphones/tablets (i.e. SIM card, microSD, camera, etc.) 8.Provide either a wired/wireless interface between the authentication component and the device 9.Capable of being used for PC-based authentication 10.Support for secure, encrypted communication between the authentication component and the device 11.Support mitigations for spoofing, man-in-the-middle attacks, and other forms of identity impersonation 12.FIPS 140-2 level 1 compliant 13.If biometrics is employed, NIST compliant biometric implementation 14.Leverage existing use of CAC technology 6.0Request for Technical Information Please answer the following questions and provide as much detail as possible. Please note that some questions are to be interpreted simply as guideline and can be used to include any additional information related to the topic which may differentiate or better explain your product's functionality. Additionally, please be aware that fulfilling the capabilities outlined in this document are not required but merely desired. This RFI is intended as a broad and open-ended opportunity for PM NES to discover innovative ideas using existing technologies for this specific application and all submissions will be treated with equal consideration. 1.What mobile OS platforms (specify by version number) do you support and how does support differ if multiple platforms are supported? Does your solution(s) provide universal support across all mobile platforms? If not, what particular constraints limit universal use of your product? Please explain. 2.Are there limitations to what device manufacturers and/or carrier service providers your product supports as well? If so, please describe. 3.Do you leverage an existing capability/functionality available on the smartphone/tablet (i.e. SIM card, microSD, camera, etc.)? 4.Do you use a wired or wireless interface? If wireless, please describe the technology and implementation used. Is the wired/wireless communication secured using a cryptographic module? 5.Do you support DoD's Public Key Infrastructure (PKI)? Please explain. 6.What factors of authentication do you support? Is the number/type of authentication enforced configurable? If so, please describe. 7.Does your solution leverage the current CAC (smart card with PKI) solution? If so, please describe. 8.How much does your solution/product weigh? 9.How does your solution/product mitigate potential threats of spoofing, man-in-the-middle attacks, and other forms of identity impersonation? 10.Can your solution/product prompt the user for authentication upon unlocking of the device? What about authentication to downstream networks, applications and other services? If this is device-specific, please describe which devices this feature is available on. 11.If encryption is used in your solution/product, is your solution/product FIPS 140-2 level 1 compliant and/or validated by NIST? Please describe the cryptographic modules used in your product to support data-at-rest, data-in-motion, and data-in-transit encryption. 12.Does your solution/product have other practical applications that the DoD community can leverage? For example, can your solution/product be used to grant users physical access to a facility? 13.Does your solution require network access? 14.Can your solution/product be leveraged by other third-party applications? (i.e. Good For Enterprise, Citrix, etc.) 15.Does your product/solution support both the garrison and tactical environments? To what extent does performance and reliability decrease in relation to the use conditions? What are the limiting factors in your product/solution that constrain its use for various environments? 16.Does your product/solution require power? If so, does it use its own independent source of power or does it use the mobile device's battery? 7.0Constraints The following constraints should be identified and mitigation processes defined in industry responses. Compliance with Army security policies, guidelines and architectures including Top Level Architecture (TLA), Information Assurance Vulnerability Alert (IAVA) reporting, monitoring, etc. Unified Capability Approved Product List (UC-APL) Compliance with Section 508 of the Rehabilitation Act of 1973 DIACAP Authority to Operate (ATO) Certificate to Operation (CTO) Certificate of Networthiness (CON) Army Interoperability Certification (AIC) IPv6 Transition Preparation Clinger-Cohen Act (CCA) Compliance Information Assurance Strategy (AIS) - Required for CCA compliance and the others Global Information Grid Bandwidth Expansion (GIG BE) connectivity Continuity of Operations (COOP) and Disaster Recovery (DR) Army Environmental/Facilities requirements (if applicable), specifically: Infrastructure Physical Security Survivability Time lines Required footprint/floor space Approvals and Ownership 8.0Transition and Transformation In any organization, change is always challenging. It is the Army's intent to transition to provide alternatives to the CAC sled functionality and transform the user community as seamlessly, and expeditiously as possible. As such, it is requested that industry address the following additional items in their response to this RFI. A successful mitigation plan for past transitions in the commercial or Federal marketplace. Any capabilities that exist for users to perform a "Self-Service" migration. Any issues and mitigation techniques related to migrating devices into the new Enterprise solution. Levels of service currently being provided in the commercial or Federal marketplace and their key performance parameters. Strategies for identifying and resolving recurring and systemic problems with CAC/PIV alternatives. Current methodology for providing Tier 2/Tier 3 level support services. An expected "start up" period of time in calendar days, from date of award through service provision, including installation, Information Assurance (IA) accreditations and certifications. How would the transition of data to a new service provider (commercial or government) at the end of the contract be performed?
- Web Link
-
FBO.gov Permalink
(https://www.fbo.gov/notices/539d91798e4a5389d41346c590bc45a7)
- Record
- SN02632116-W 20111203/111201235251-539d91798e4a5389d41346c590bc45a7 (fbodaily.com)
- Source
-
FedBizOpps Link to This Notice
(may not be valid after Archive Date)
| FSG Index | This Issue's Index | Today's FBO Daily Index Page |