The PIV Working Group appreciates the opportunity to provide guidance on the initial scope for ICAM Part B. In addressing your request we created three bodies of content: Required changes to Table 6 2 in FIPS 201 Elements of a Chapter 1 of ICAM B What is an End Point PACS? Discussion of architecture versus functionality Required changes to Table 6 2 in FIPS 201 We believe the following table summarizes reality today based on the body of PIV documents (specifically FIPS 201 1, SP800 116,) and the GSA Approved Products List. This table will make it easier for the consumer to understand the difference between a trusted and non trusted authentication factor, how they can be combined for higher confidence, and which to select for a given application. Required changes to FIPS 201, Table 6 2 Authentication Factors for Physical Access PIV Assurance Level at the Door Trusted Authenticati on Factors Single NO confidence 0 VIS, CHUID, BIO, PIN to CARD Combination VIS + CHUID, CHUID + BIO SOME confidence 1 BIO (S), CAK, PIN to PACS CHUID (S) HIGH Confidence 2 PKI PIN to PACS + CAK, CHUID (S) + PIN to PACS BIO (S) + CAK, BIO (S) + PIN to PACS, PKI + BIO, CHUID (S) +BIO (S) VERY HIGH Confidence 3 PKI + BIO (S), PIN to PACS + CAK + BIO (S). CHUID (S) + BIO (S) + PIN to PACS Notes: 1. The fundamental premise of ICAM is that only trusted authentication factors will be used, so there is a need to categorize assurance levels based on trusted authentication factors. 2. ICAM focuses on end to end results, including use of the PACS, and is not limited to the card. Hence PIN to PACs, a valuable trusted security measure is included above. 3. CHUID (S) incorporates the signature checking option which results in one trusted authentication factor. CHUID has on trusted authentication factors.
4. BIO (S) incorporates the signature checking option which results in one trusted authentication factor. BIO has no trusted authentication factors. 5. BIO A is not shown as there are not good directions for what the attendant should do or how to do it. 6. The assurance achieved at the door cannot be greater than the assurance validated at registration to the PACS. 7. CAK is an Option and may not be present. There are two versions Symmetric and Asymmetric, and either contact or contactless are permitted, though PKI is only Asymmetric on the contact interface. 8. The last entry in the VERY HIGH Confidence does not include a Challenge, though it is three trusted factors. This may deserve some consideration of whether a Challenge becomes a mandatory threshold. Chapter 1 What is an End Point PACS? Assumptions 1. All Options will be made Mandatory (via new or updated standards supported by vendors and users) a. To ensure Interoperability b. To avoid rejection of otherwise good cards c. To ensure only trusted objects are used d. To provide an alternative to the PIV Auth Cert for Physical Access 2. The standards will support HIGH and VERY HIGH Confidence Assurance Levels for Contactless to meet the need for convenient transactions and productivity a. Else folks will bypass the rules to avoid waiting in lines b. Else there will be no environmentally friendly solution 3. PIN to PACS will be recognized as a trusted authentication factor a. Else many agencies will not accept PIV b. Other out of band factors can also be recognized, but the issue of binding must be addressed, whether OTP, cell phone, etc.
i. Biometrics should be recognized and an excellent mechanism to bind the person to another trusted authentication factor 4. Cryptography will be used end to end all the time a. All components will carry the time to market and high cost burden of FIPS 140 2 i. And the burden of transition to FIPS 140 3 b. PACS Host and PACS Controllers will need to be tested for compliance 5. PKI techniques will be used for all critical components involved in identity processes a. Controller b. Reader if performing challenge/response, signature checking, cert checking i. Else can be done by another component c. Other Security Devices and Systems such as Video and Audio Surveillance 6. Support UUID in addition to or potentially in lieu of the FASC N 7. All PIV Cards will be reissued for compliance and interoperability. a. The normal refresh process can achieve this over time if the compliance changes become mandatory ASAP for all new cards being issued 8. End Point PACS provide direct solutions for card authentication a. They will have to meet the same criteria for their own components anyway b. Device authentication will establish trusted system components. Non Person Entities (NPE) will likely use certificate based authentication to achieve identity convergence between people and things. 9. PACS will continue to perform Intrusion Detection in a converged, UL Listed manner so as to preclude false alarms on authorized access onto secure areas. 10. The Controller will have the Power of a PC a. Able to download firmware for PIV Middleware changes i. And on to the reader if it participates in the process b. To fully utilize the power of the Card c. Will be able to synchronize with the PKI to provide response to local and off line credential validation queries
11. The Reader will be more like a sensor only or a USB Reader for a desktop environment a. To ensure only critical components are on the Attack side of the secure perimeter i. Two Part Readers (or Reader/Controller hybrids can also comply) b. To reduce the cost of firmware changes and FIPS 140 and GSA APL re submittal requirements c. Some implementations may consist of a reader that is also a single door controller designed to perform the security process. 12. All PACS will be FISMA Compliant 13. PACS will be bought with Professional Services from the Manufacturer and annual maintenance contracts. Figure 1 Significant Differences between PACS today and PACS ICAM. Discussion of Architecture versus Functionality 1. Multiple architectures exist and will appear over time to achieve the desired functionality
2. The functionality can reside anywhere in the architecture, whether in the reader, the controller, the host, or another component. 3. Response time will likely exceed expectations developed from past experiences with 125KHz Proximity cards. The customer should determine their response time requirements and interview suppliers to determine whether they comply. Faster response times might require different architectures or higher cost. Different response times might be acceptable depending on use case (high traffic entry vs, high security area) 4. Critical ICAM Functionality that will have to be in an end point PACS, requiring upgrade or replacement will include: a. Challenge/Response of the Card s Certificate(s) b. Signature Checking c. Certificate Status Checking d. Path Validation e. Ability to support up 128 bit UUID 5. Existing PACS (or indeed Security System) functionality needs to be sustained. For instance UL listings, intrusion integration to prevent false alarms on authorized access, continued operation even under degraded network capabilities, etc. 6. Additional new functionality or specification changes may impact the architecture of the End Point PACS contemplated today.
Current State PACS Client Server with PACS Software/Database Multi Door Controller Reader Interface Contactless Reader Figure 2 Current State of PACS
A B Server verifies certificates, updates user records Multi Door Controller with local certificates (updated daily) Example upgrade options for PACS to accommodate certificate validation (any transparent readers must replaced with challenge/response readers) C D Smart Reader Interface (to verify certificates) Next generation solutions Figure 3 Example Upgrade Options for PACS to Accommodate Certificate Validation
PIV Assurance Level at the Door Single Combination PKI + BIO (S) PIN to PACS + CAK + BIO (S) CHUID (S) + BIO (S) + PIN to PACS PKI PIN to PACS + CAK, CHUID (S) + PIN to PACS BIO (S) + CAK BIO (S) + PIN to PACS PKI + BIO CHUID (S) +BIO (S) BIO (S) CAK PIN to PACS CHUID (S) VIS PIN to CARD CHUID BIO Figure 4 PIV Assurance Level at the Door