`3` HKA HK, HA, or HKA (was: Terminology)

NIST PIV and digital identity SP 800-116 Rev. 1 against SP 800-116
All changes in this version

modified 3 HKA HK, HA, or HKA

Title changed

Before · SP 800-116

Terminology

After · SP 800-116 Rev. 1

~~Terminology~~HKA HK, HA, or HKA

Control changed

Before · SP 800-116

After · SP 800-116 Rev. 1

The following terms are used in this document and are not defined in FIPS 201. Access Control: A function or a system that restricts access to authorized persons only. Access Control List: A list of (identifier, permissions) pairs associated with a resource or an asset. As an expression of security policy, a person may perform an operation on a resource or asset if and only if the person’s identifier is present in the access control list (explicitly or implicitly), and the permissions in the (identifier, permissions) pair include the permission to perform the requested operation. Assurance Level (or E-Authentication Assurance Level ) : A measure of trust or confidence in an authentication mechanism defined in OMB Memorandum M-04-04 and NIST Special Publication (SP) 800-63, in terms of four levels: [M-04-04]
• Level 1: LITTLE OR NO confidence
• Level 2: SOME confidence
• Level 3: HIGH confidence
• Level 4: VERY HIGH confidence Authentication: A process that establishes the origin of information, or determines an entity’s identity. In this publication, authentication often means the performance of a PIV authentication mechanism. Authentication in Context: Authentication in context is a concept in which PACS may benefit from previous authentication within nested areas in a facility. The PACS may use information from previous access control decisions (“context”) when making a new access control decision. Authorization: In this publication, a process that associates permission to access a resource or asset with a person and the person’s identifier(s). Authenticator: A memory, possession, or quality of a person that can serve as proof of identity, when presented to a verifier of the appropriate kind. For example, passwords, cryptographic keys, and fingerprints are authenticators. BIO or BIO-A: A FIPS 201 authentication mechanism that is implemented by using a Fingerprint data object sent from the PIV Card to the PACS. Note that the short-hand “BIO (-A)” is used throughout the document to represent both BIO and BIO-A authentication mechanisms. Biometric: An authenticator produced from measurable qualities of a living person. Building Security Committee: A committee consisting of representatives of Federal tenants in a facility, and possibly the building owner or management. The committee is responsible for building-specific security issues and approval of security policies and practices. Card Authentication Key (CAK ) : A PIV authentication mechanism (or the PIV Card key of the same name) that is implemented by an asymmetric or symmetric key challenge/response protocol. The CAK is an optional mechanism defined in NIST SP 800-73. [SP800-73] NIST strongly recommends that every PIV Card contain an asymmetric CAK and corresponding certificate, and that agencies use the asymmetric CAK protocol, rather than a symmetric CAK protocol, whenever the CAK authentication mechanism is used with PACS. See Section 7.1.4. Cardholder Unique Identifier (CHUID): A FIPS 201 authentication mechanism that is implemented by transmission of the CHUID data object from the PIV Card to PACS, or the PIV Card data object of the same name. Certificate: A data object containing a subject identifier, a public key, and other information, that is digitally signed by a Certification Authority. Certificates convey trust in the relationship of the subject identifier to the public key. Cloning: In this publication, a process to create a verbatim copy of a PIV Card, or a partial copy sufficient to perform one or more authentication mechanisms as if it were the original card. Contact Reader: A smart card reader that communicates with the Integrated Circuit chip in a smart card using electrical signals on wires touching the smart card’s contact pad. The PIV contact interface is standardized by International Organization of Standards / International Electrotechnical Commission (ISO/IEC) 7816-3. [ISO/IEC7816] Contactless Reader: A smart card reader that communicates with the Integrated Circuit chip in a smart card using radio frequency (RF) signaling. The PIV contactless interface is standardized by ISO/IEC 14443. [ISO/IEC14443] Controller (or Control Panel, or Panel ) : A device located within the secure area that communicates with multiple PIV Card readers and door actuators, and with the Head End System. The PIV Card readers provide cardholder information to the Controller, which it uses to make access control decisions and release door locking mechanisms. The Controller communicates with the Head End System to receive changes in access permissions, report unauthorized access attempts and send audit records and other log information. Most modern controllers can continue to operate properly during periods of time in which communication with the Head End is disrupted and can journal transactions so that they can be reported to the Head End when communication is restored. Counterfeiting: In this publication, the creation of a fake ID card that can perform one or more authentication mechanisms, without copying a legitimate card (see Cloning ). Credential: In this publication, a collection of information about a person, attested to by an issuing authority. A credential may be a physical artifact (e.g., a PIV Card ) or a data object (e.g., a certificate ). One or more data object credentials may be stored on the same physical memory device (e.g., a smart card). Credential Validation: The process of determining if a credential is valid , i.e., it was legitimately issued, its activation date has been reached, it has not expired, it has not been tampered with, and it has not been terminated, suspended, or revoked by the issuing authority. Digital Signature: A data object produced by a digital signature method, such as Rivest, Shamir, Aldeman (RSA) or the Elliptic Curve Digital Signature Algorithm (ECDSA), that when verified provides strong evidence of the origin and integrity of the signed data object. Federal Agency Smart Credential Number (FASC-N): As required by FIPS 201, the primary identifier on the PIV Card for physical access control. The FASC-N is a fixed length (25 byte) data object, specified in [TIG SCEPACS], and included in several data objects on a PIV Card. FASC-N Identifier: The FASC-N shall be in accordance with [TIG SCEPACS]. A subset of FASC-N, a FASC-N Identifier, is a unique identifier as described in [TIG SCEPACS]. Section 2.1, 10 th paragraph of [TIG SCEPACS] states “For full interoperability of a PACS it must at a minimum be able to distinguish fourteen digits (i.e., a combination of an Agency Code, System Code, and Credential Number) when matching FASC-N based credentials to enrolled card holders.” Also, Section 6.6, 3 rd paragraph of [TIG SCEPACS] states, “The combination of an Agency Code, System Code, and Credential Number is a fully qualified number that is uniquely assigned to a single individual”. The Agency Code is assigned to each Department or Agency by Special Publication 800-87, Codes for the Identification of Federal and Federally-Assisted Organizations [SP800-87]. The subordinate System Code and Credential Number value assignment is subject to Department or Agency policy, provided that the FASC-N Identifier (i.e. the concatenated Agency Code, System Code, and Credential Number) is unique for each card. Head End System (or Access Control Server ) : A system including application software, database, a Head End server, and one or more networked personal computers. The Head End server is typically used to enroll an individual's name, create a unique ID number, and assign access privileges and an expiration date. The server is also used to maintain this information and refresh the Controller(s) with the latest changes. Identifier (or Unique Identifier ) : In this publication, a data object, assigned by an authority, that unambiguously identifies a person within a defined community. For example, a Driver License number identifies a licensed driver within a State. The authority registers people and guarantees assignment of each identifier to a unique person. Identity Credential: A credential that contains one or more identifiers for its subject, a person. In this publication, an identity credential is designed to verify the identity of its subject through authentication mechanisms , either manually (see VIS ) or electronically (see CHUID , CAK , PKI , BIO , and BIO-A ). Infrastructure: Distributed substructure of a large-scale organization that facilitates related functions or operations, e.g., telecommunications infrastructure. With regard to PACS, components include conduit, cabling, power supplies, battery backup, electrified door hardware, door position switches, and remote exit devices, as well as connectivity with other life safety systems that will ensure egress in the event of an emergency. Interoperability: In this publication, the quality of allowing any government facility or information system to verify a cardholder’s identity using the credentials on the PIV Card, regardless of the PIV Card Issuer (PCI). Issuance (or Credential Issuance ) : The process by which an issuing authority obtains and verifies information about a person, assigns one or more unique identifiers to the person, prepares information to be placed in or on a credential, produces a physical or data object credential, and delivers the finished credential to its subject. In the case of PIV Cards, issuance is performed only by accredited PCIs. Multi-Factor Authentication: Authentication based on more than one factor. In some contexts, each factor is a different authenticator. In other contexts, each factor is one of “something you know, something you have, something you are” (i.e., memorized fact, token, or biometric) and thus the number of factors is 1, 2, or 3. PACS Registration: The process of authenticating, validating, and verifying information about the PIV cardholder prior to entering the information into a PACS server. The information added during registration is then utilized to perform authentication and authorization of an individual at an access point. Path Validation (or Trust Path Validation ) : The process of verifying the binding between the subject identifier and subject public key in a certificate, based on the public key of a trust anchor, through the validation of a chain of certificates that begins with a certificate issued by the trust anchor and ends with the target certificate. Successful path validation provides strong evidence that the information in the target certificate is trustworthy. Personal Identification Number (PIN): Typically, a short numeric password (4 to 8 digits) used as an authenticator with a bank card, ID card, or other personal security device. Personal Identity Verification (PIV) Card: The identity credential mandated by HSPD-12 and defined by FIPS 201 as an end-point PIV Card. A PIV Card is a smart card with contact and contactless communication capability, and eleven defined data objects for interoperability, five mandatory and six optional. PIV Implementation Maturity Model (PIMM): PIMM is a PIV implementation maturity model that can be used to measure the progress of a facility or an agency towards accepting PIV Card. PIV System: A system comprised of components and processes that support a common (smart card-based) platform for identity authentication across Federal departments and agencies for access to multiple types of physical access environments. Physical Access Control System (PACS): An electronic system that controls the ability of people or vehicles to enter a protected area, by means of authentication and authorization at access control points. PKI: For this document, a PIV authentication mechanism that is implemented by an asymmetric PIV authentication key challenge/response protocol. Private Key: A cryptographic key used with a public key cryptographic algorithm, which is uniquely associated with an entity, and not made public; it is used to generate a digital signature; this key is mathematically linked with a corresponding public key. Public Key: A cryptographic key used with a public key cryptographic algorithm, uniquely associated with an entity, and which may be made public; it is used to verify a digital signature; this key is mathematically linked with a corresponding private key. Reader: A device that interfaces with a PIV Card and a Controller to execute or support execution of one or more PIV authentication mechanisms.

Relying Party: In this publication, an entity, such as a PACS, that depends upon the trust model of the PIV System to correctly produce the results of authentication, i.e., the identity of the cardholder. Revocation: The process by which an issuing authority renders an issued credential useless. For example, a Certification Authority may revoke certificates it issues. Typically, a certificate is revoked if its corresponding private key is known to be, or suspected to be, compromised, or if the certificate’s subject affiliation is changed. Secret Key: A key used by a symmetric key algorithm to encrypt, decrypt, sign, or verify information. In a Symmetric Key Infrastructure (SKI), the sender and receiver of encrypted information must share the same secret key. Skimming: Surreptitiously obtaining data from a contactless smart card, using a hidden reader that powers, commands, and reads from the card within the maximum read distance (reported as about 25 cm with ISO/IEC 14443 smart cards like the PIV Card). [SKIMMER] Sniffing: Surreptitiously obtaining data from a contactless smart card, using a hidden reader that receives RF signals from a legitimate reader and smart card when they perform a transaction. Sniffing is a form of electronic eavesdropping. Sniffing is possible at greater distances than skimming. Social Engineering: A process or technique, similar to a confidence game, used to obtain information from a person without raising suspicion. Termination: In this publication, the action of an identity credential issuer that causes the credential to become invalid. Trust Anchor: A named entity producing digital signatures, and a corresponding certificate that a relying party has decided to trust, i.e., if a digital signature is verified using the public key within the certificate, the signature is trusted to have been made by the entity named in the certificate. VIS: A FIPS 201 authentication mechanism in which the visual identity verification of a PIV Card is done by a human guard. Validation: In this publication, the process of determining that an identity credential was legitimately issued and is still valid, i.e., has not expired or been terminated. Verification: The process of determining if an assertion is true, particularly the process of determining if a data object possesses a digital signature produced by the purported signer. Wiegand: With regard to deployed PACS, a one-way communication protocol consisting of a formatted bit string used from the access reader to the Controller. It can be used with any media, including proximity, bar code, magnetic stripe, and smart cards.Appendix C — Improving Authentication Transaction Times

The deprecation of the CHUID authentication mechanism marks the end for authentication based on reading a static identifier. With the deprecation, however, PACS systems lose a mechanism that is by nature fast. The PKI-CAK authentication mechanism is the most logical replacement for the CHUID authentication mechanism, is computationally expensive. To approach transaction times closer to the CHUID authentication mechanism, optimizations are needed within the PIV Cards as well as with the readers and associated infrastructure. Transaction times for other authentication mechanisms are also important, and many of the recommendations in this section apply to other PIV authentication mechanisms as well.

The steps of the PKI-CAK authentication mechanism can be described as follows:

• The reader obtains information from the PIV Card that allows it to determine an identifier for the card and to determine the card’s Card Authentication certificate.

• The reader sends a challenge string to the PIV Card and requests an asymmetric operation in response.

• The card responds to the previously issued challenge by signing it using the Card Authentication private key.

• The relying system (reader or controller) uses the public key from the Card Authentication certificate to verify the response from the card.

• The relying system verifies that the Card Authentication certificate is valid.

• The relying system uses the identifier from the card to make an access control decision.

Each of the steps above presents an opportunity for optimization.

As a starting point, PCIs should consider performance when purchasing card stock, as the card is involved in four of the six steps above. When the PKI-CAK authentication mechanism is performed, the PIV Card needs to perform a power-on self-test, perform a private key signature operation using the Card Authentication private key, and transmit data to the reader, so the performance of all of these steps is relevant to the overall performance of the card. [SP800-78] allows the Card Authentication key to be either a 2048-bit RSA key or an elliptic curve cryptography (ECC) P-256 key, and many cards support both cryptographic algorithms. When a card supports both algorithms, the performance of both algorithms should be considered.

Recommendation C.1 : Since ECC private key operations are generally faster than RSA private key operations, PCIs should consider issuing PIV Cards with ECC Card Authentication keys rather than RSA.

The performance of the PIV Card is partially dependent upon the reader. The PKI-CAK authentication mechanism is usually performed over the contactless interface, with the PIV Card being powered by the reader’s magnetic field, and cards will operate more slowly when they are underpowered. Improper installation of the reader may lead to the card being underpowered, and it may also create interference that makes communication between the card and the reader unreliable, which would also lead to increased transaction times.

Recommendation C.2 : Make use of Qualified HSPD-12 Service Providers 22 to ensure that PACS components are properly installed and that readers are properly tested and tuned to provide optimal performance.

In order to maximize performance, the PIV Card needs to be held correctly within the reader’s magnetic field. So, departments and agencies should provide information to their cardholders on the proper way to present their cards to the readers. Placing an image on the reader depicting the proper orientation of the card may also be helpful.

Preregistration of PIV Cards can help to speed up many of the steps in the PKI-CAK authentication mechanism. If the card’s Card Authentication certificate was obtained during the preregistration process then it doesn’t need to be read from the card at the time of authentication. 23 Instead, the reader can obtain an identifier from the card (e.g., by reading the initial portion of the CHUID and extracting the FASC-N, Card UUD, or Cardholder UUID) and can then use the identifier to look up the certificate in the local cache. In addition, status information for the Card Authentication certificate may be obtained from a caching status proxy rather than performing certificate validation at the time of authentication. 24

In many PACS systems, data is transferred from the reader to the controller using the Wiegand protocol, which is very slow and only allows for one-way communication. Replacing the cabling between the reader and the controller to support fast two-way communication will provide several benefits: it will speed up the transfer of the card’s identifier from the reader to the controller; it will enable the caching of the Card Authentication certificate at the controller; and it will allow the reader to offload more of the processing to the controller. Given that card readers tend to have very little processing power, it may be more efficient, if fast two-way communication is available, for the reader to send the results of the challenge to the controller rather than performing the signature verification itself.

Recommendation C.3 : Consider the benefits of upgrading the communications infrastructure between readers and controllers and then using the improved communication to move processing steps to the component that can perform the step most efficiently.

22 Information about Qualified HSPD-12 Service Providers can be found at https://www.idmanagement.gov/IDM/s/article_detail?link=list-of-certified-services . 23 The PACS should be prepared to handle cases in which the Card Authentication certificate on the card was replaced (due to re- key) after the card was preregistered. 24 Agencies should consider using online status checks when the most up to date PIV Card status is necessary. Appendix D — FASC-N Uniqueness

Once the user has been authenticated, access control decisions can be made by comparing PIV identifiers (see Section 6.1 ) against the ACL entries. While any of the PIV identifiers may be used in making access control decisions, within the limitations described in Section 6.1 , this appendix discusses the use of the FASC-N, or portions of the FASC-N, for making access control decisions.

Three components of the FASC-N, the Agency Code, System Code, and Credential Number, constitute the FASC-N Identifier. An individual’s FASC-N Identifier is unique among all cardholders when the complete three-element subset of the FASC-N is used for comparison. There will be no collisions since all of the cardholders have been assigned unique numbers. An ACL pattern may match the entire FASC-N, just the Agency Code, or the Agency Code and System Code (e.g., all PIV Cards issued to one agency, or to one site in one agency) without introducing dangerous collisions or ambiguities across agencies. The values of additional FASC- N fields may be included in the identifiers that are compared against the ACL entries.

This restricts the access control comparison to one of three cases when using the FASC-N:

1. the Agency Code alone (i.e., all PIV Cards with the same Agency Code are accepted);

2. the Agency Code and System Code only (i.e., all PIV Card with the same Agency Code and System Code are accepted); or

3. the Agency Code, System Code, and Credential Number (i.e., a uniquely identified PIV Card).

Any of these cases may also include comparison of additional FASC-N values such as the Credential Series, Individual Credential Issue, Organizational Identifier, or Person Identifier. 25

The FASC-N data fields are defined as fixed length values of Binary Coded Decimal digits. The complete subset of three data fields is 14 decimal digits in length, as stored on the PIV Card. Other representations of the FASC-N Identifier, for example a binary representation, may be used off card, provided that they are isomorphic with respect to pattern matching. The following examples demonstrate the possible uses of FASC-N in a PIV-enabled PACS application.

D.1 Full FASC-N Comparison The following table shows a successful match against an ACL pattern consisting of a full FASC- N comparison. These examples show an organization-specific access control policy that includes the comparison of all FASC-N fields.

25 [SP800-73] allows issuers to populate the FASC-N’s Credential Series, Individual Credential Issue, Organizational Identifier, and Person Identifier fields with all zeros, so these fields may not always provide useful information for comparison. FIELD NAME PIV Card FASC-N ACL FASC-N Pattern

Agency Code 3728 3728

System Code 8377 8377

Credential Number 123456 123456

Credential Series 1 1

Individual Credential Issue 1 1

Person Identifier 1234567890 1234567890

Organizational Category 1 1

Organizational Identifier 0010 0010

Person/Organization Association Category 1 1

The following table shows an unsuccessful match against an ACL pattern consisting of full FASC-N comparison.

FIELD NAME PIV Card FASC-N ACL FASC-N Pattern

Agency Code 3728 3728

System Code 8377 8377

Credential Number 123456 234567

Credential Series 1 1

Individual Credential Issue 1 1

Person Identifier 1234567890 1234567890

Organizational Category 1 1

Organizational Identifier 0010 0010

Person/Organization Association Category 1 1 D.2 FASC-N Identifier Comparison The following table shows a successful match against an ACL pattern consisting of one specific FASC-N Identifier.

FIELD NAME PIV Card FASC-N ACL FASC-N Pattern

Agency Code 3728 3728

System Code 8377 8377

Credential Number 123456 123456

The following table shows an unsuccessful match against an ACL pattern consisting of one specific FASC-N Identifier.

FIELD NAME PIV Card FASC-N ACL FASC-N Pattern

Agency Code 3728 3728

System Code 8367 8377

Credential Number 123456 123456

D.3 Partial FASC-N Comparison The following table shows a successful match against an ACL pattern consisting of an Agency Code and the System Code. The “x” symbols represent “don’t care” decimal digits.

FIELD NAME PIV Card FASC-N ACL FASC-N Pattern

Agency Code 3728 3728

System Code 8391 8391

Credential Number 654321 xxxxxx

The following table shows an unsuccessful match against an ACL pattern consisting of an Agency Code and the System Code.

FIELD NAME PIV Card FASC-N ACL FASC-N Pattern

Agency Code 3628 3728

System Code 8377 8377 Credential Number 123456 xxxxxx

The following table shows a disallowed pattern that is not an initial string of the FASC-N Identifier.

FIELD NAME PIV Card FASC-N ACL FASC-N Pattern

Agency Code 3728 37xx

System Code 8377 83xx

Credential Number 123456 xxxxxx

D.4 Isomorphic FASC-N Comparison The following table shows a successful match against an ACL pattern, with the FASC-N Identifier and the upper and lower bounds of the ACL pattern represented in hexadecimal. The match succeeds because the presented FASC-N Identifier is in the closed interval [LB, UB]. This example is the same as the MATCH example of D.2 , with a shift in representation from decimal to hexadecimal.

FIELD VALUE PIV Card FASC-N ACL Pattern LB ACL Pattern UB

Hexadecimal Value 21E9E156BBB1 21E9DBE03300 21E9E1D613FF

The following table shows an unsuccessful match against an ACL pattern, with the FASC-N Identifier and the upper and lower bounds of the ACL pattern represented in hexadecimal. The match fails because the presented FASC-N Identifier is not in the closed interval [LB, UB]. This example is the same as the NO MATCH example of D.2 , with a shift in representation from decimal to hexadecimal.

FIELD VALUE PIV Card FASC-N ACL Pattern LB ACL Pattern UB

Hexadecimal Value 21010BD3F280 21E9DBE03300 21E9E1D613FF Appendix E — Limitations of Legacy Physical Access Control Systems

[FIPS201] and its supporting special publications impose specific requirements on PACS interfaces with PIV Card and PIV System. These requirements presented technical challenges in migrating to PIV Card use in the areas of cardholder identification, card-to-reader interface, and authentication protocol. The following sections explore how [FIPS201] requirements differ from the capabilities of PACS that are not PIV-enabled.

E.1 Cardholder Identification Legacy PACS use cards with data formats that are often proprietary to the specific enterprise. Many of the legacy PACS use an ID number based on a 26-bit standard, which is comprised of an 8-bit site code and a 16-bit unique card ID number with 2 bits assigned to parity (the parity bits add confidence that the data transmission has no errors). The 8-bit site code accommodates 256 unique sites and the 16-bit card ID number accommodates 65 536 unique users for that site. Larger ID numbers are used by some legacy systems but they are not necessarily interoperable.

A PACS based on the 26-bit format is deployed as a standalone solution at a dedicated site. Typically, these solutions are managed locally, and an individual with an access card for one site cannot use the same card at a second site and must obtain a second card. [FIPS201] changes this dynamic because the credential is issued through a separate process instead of as part of the PACS deployment. Legacy PACS need to be upgraded or re-provisioned to support at least a 14-decimal-digit FASC-N Identifier or a 16-byte Card UUID (see Appendix D).

E.2 Door Reader Interface PACS readers come in varying configurations and offer multiple interface options for the card and the controller. [FIPS201] standardizes the use of the [ISO/IEC 14443] interface for the contactless reader to card communication. Note that the card reader may require additional conformance testing for federal acquisition. An authority for such conformance testing is the General Services Administration (GSA) FIPS 201 Evaluation Program [FIPS 201 EP] , which defines tests and maintains a list of approved products. Not all existing PACS use this interface, so some agencies may have to plan to migrate from their legacy environment to the [ISO/IEC 14443] conformant interface. Alternatively, an agency may use the PIV Card’s contact interface based on [ISO/IEC 7816] .

The interface from the door reader to the controller also comes in different configurations. [FIPS201] does not specify which protocols can be used for this interface, as long as the necessary data can be communicated to the controller. Typical deployed implementations support transmitting a small amount of data (on the order of 10 to 15 bytes), but [FIPS201] defines data elements that are much larger. Therefore, depending on the agency’s implementation strategy, an upgrade to the door reader to controller interface may also be required. At a minimum, a 14-decimal-digit FASC-N Identifier or the full 16-byte Card UUID will be supported. Note that any change to this interface may also necessitate changes to the physical wiring and cabling infrastructures. E.3 Authentication Capability Legacy PACS readers use proximity or magnetic stripe technology to interface with identity cards and use proprietary protocols to communicate data. Some of these proprietary protocols employ cryptography, but their use is limited to the local site. [FIPS201] specifies identity credentials that can be used for a new generation of identity management technology for building access. [FIPS201] and its supporting special publications define the credential data model and the card-to-reader interface, and also provide requirements for implementing the digital certificates.

[FIPS201] added a standardized contactless and contact interface, PIN, biometric fingerprints, optional iris images, and cryptography to the card that could be used to attain a higher level of identity authentication assurance. The capability to perform bi-directional data communication is fundamental to the deployment of secure building access. Adding cryptography to the cards permits agencies to validate the data objects on the card and authenticate the cardholder. Adding credential expiration and credential validation requirements also strengthens access control decisions. At the same time, [FIPS201] provided the opportunity to migrate building access systems from LITTLE or NO confidence levels to VERY HIGH confidence levels. Legacy PACS may need upgrades to take advantage of these features and functions, in coordination with the following guidelines and authorities:

+ [FIPS201] assurance levels.

+ The Risk Management Process for Federal Facilities: An Interagency Security Committee Standard [ISC-RMP] .

[FIPS201] redefines the requirements for building access in a fundamental way: instead of each facility issuing an access card solely for that facility’s PACS architecture, a facility relies on the PIV Card that was issued by the same, or a different, agency certified by the Federal Government. The facility still has control over the user’s access privileges, but the technology has been standardized to optimize interagency interoperability and the credential has been issued to the user as part of the [FIPS201] identity management process.

E.4 Wiring Selecting a particular reader type and its interface with the controller requires careful attention to wiring. Existing wiring should be assessed for its ability to meet the requirements of new readers and controllers, taking performance into consideration. The existing wiring may be a limiting factor due to its capacity to transmit data and original specifications. Many recently installed systems use higher bandwidth cables, which are typically sufficient for a PIV-based access control system. In some environments, advanced signaling methods operating at higher speeds with lower signal-to-noise margins can necessitate upgrades to the wiring.

E.5 Software Upgrades Vendors may be able to upgrade their PACS software to minimize the hardware changes needed for a legacy PACS to accept PIV Cards. Software or firmware upgrades to controllers or door readers may be available to agencies. PACS suppliers should be asked if software or firmware upgrades supporting PIV Cards are a possibility. If available, the agency should ensure that the software upgrade will have no adverse effect on the PACS system or any interconnected systems.

E.6 Legacy PACS Cards and PIV Card Differences The list below compares the basic differences in the technology offerings between the legacy PACS cards and the PIV Card.

+ Some legacy PACS use site-specific card technology, with the result that a card cannot be used at sites with incompatible PACS. For example, a magnetic stripe card cannot be used at a proximity card site, and a magnetic stripe card from one vendor cannot be used at a site with magnetic stripe equipment from another vendor.

+ Legacy PACS cards can provide an identifying number, but in most cases, they cannot respond to a cryptographic challenge. Many non-PIV PACS cards can be copied easily.

+ When two sites use compatible legacy card technology, the risk of duplicate site identifiers for cards is always present. Without government-wide coordination of identifiers, the same identifier could be used on multiple cards at different sites.

+ To achieve government-wide coordination of cardholder identifiers, enough identifiers must be available for all government-issued credentials. Many legacy PACS have a limit on the number of sites (256) and the number of users per site (65 536) that is too small for government-wide use and can lead to the same identifiers being issued to different individuals.

+ Legacy PACS control expiration of credentials through an expiration date stored in a site database, whereas with PIV Cards, expiration dates can be obtained from the cards themselves. There is no simple way to synchronize the expiration of credentials for a federal employee or contractor with access to multiple sites unless all sites are tied into a centralized enterprise-wide PACS (e-PACS).

+ Use of PINs, public key infrastructure, and biometrics with legacy PACS is managed on a site-specific basis at the PACS server. Individuals must enroll PINs, keys, or biometrics at each site. Since PINs, keys, and biometrics are often stored in a site database, they may not be technically interoperable with the requirements of other sites.

[FIPS201] -conformant PIV-enabled PACS eliminate or substantially reduce each of these limitations, relative to legacy PACS installations. Appendix F — References

[FIPS199] Federal Information Processing Standard 199, Standards for Security Categorization of Federal Information and Information System , February 2004. https://doi.org/10.6028/NIST.FIPS.199 .

[FIPS201] Federal Information Processing Standard 201-2, Personal Identity Verification (PIV) of Federal Employees and Contractors , August 2013. https://doi.org/10.6028/NIST.FIPS.201-2 .

[FIPS 201 EP] FIPS 201 Evaluation Program . https://www.idmanagement.gov/fips201/ [accessed 5/16/18].

[FISMA] Federal Information Security Modernization Act of 2014 , Pub. L. 113-283, 128 Stat 3073. https://www.congress.gov/113/plaws/publ283/PLAW- 113publ283.pdf [accessed 5/16/18].

[HSPD-12] Homeland Security Presidential Directive 12, Policy for a Common Identification Standard for Federal Employees and Contractors , August 27, 2004. https://www.dhs.gov/homeland-security-presidential-directive-12 [accessed 5/16/18]

[ISC-RMP] The Risk Management Process for Federal Facilities: An Interagency Security Committee Standard , 2nd edition, November 2016. https://www.dhs.gov/sites/default/files/publications/isc-risk-management- process-2016-508.pdf [accessed 5/16/18].

[ISO/IEC7816] (Parts 3:2006, 4: 2013, 5:2004, 6:2004, 8:2004, and 9:2004), Information technology — Identification cards — Integrated circuit(s) cards with contacts .

[ISO/IEC14443] (Parts 1:2008, 2:2010, 3:2011, and 4:2008) Identification cards - Contactless integrated circuit(s) cards – Proximity cards.

[M-05-24] OMB Memorandum M-05-24, Implementation of Homeland Security Presidential Directive 12—Policy for a Common Identification Standard for Federal Employees and Contractors , August 2005. https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/memoranda/20 05/m05-24.pdf [accessed 5/16/18].

[OPM Memo] Final Credentialing Standards for Issuing Personal Identity Verification Cards under HSPD-12, July 31, 2008 [accessed 5/16/18].

[PIV-I] Federal CIO Council, Personal Identity Verification Interoperability For Issuers, Version 2.01, July 27, 2017. https://www.idmanagement.gov/wp- content/uploads/sites/1171/uploads/piv-i-for-issuers.pdf [accessed 5/16/18]. [RFC5280] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk, Inter X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile , Internet Engineering Task Force (IETF) Network Working Group Request for Comments (RFC) 5280, May 2008. https://doi.org/10.17487/RFC5280 .

[SECTION508] Section 508 of the Rehabilitation Act of 1973, as amended , 29 U.S.C. §794(d), https://www.section508.gov [accessed 5/16/18].

[SKIMMER] I. Kirschenbaum and A. Wool, “How to Build a Low-Cost, Extended-Range RFID Skimmer,” Proceedings of the 15th USENIX Security Symposium (Security ’06) , Vancouver, British Columbia, Canada, July 31 – August 4, 2006, USENIX Association: Berkeley, California, 2006, pp. 43-57. https://www.usenix.org/legacy/event/sec06/tech/full_papers/kirschenbaum/ kirschenbaum.pdf [accessed 3/1/17].

[SP800-73] NIST Special Publication 800-73-4, Interfaces for Personal Identity Verification, May 2015 (including updates as of 2/8/16). https://doi.org/10.6028/NIST.SP.800-73-4 .

[SP800-76] NIST Special Publication 800-76-2, Biometric Specifications for Personal Identity Verification , July 2013. https://doi.org/10.6028/NIST.SP.800-76-2 .

[SP800-78] NIST Special Publication 800-78-4, Cryptographic Algorithms and Key Sizes for Personal Identity Verification , May 2015. https://doi.org/10.6028/NIST.SP.800-78-4 .

[SP800-87] NIST Special Publication 800-87 Revision 2, Codes for the Identification of Federal and Federally-Assisted Organizations , April 2018. https://doi.org/10.6028/NIST.SP.800-87r2 .

[TIG SCEPACS] Technical Implementation Guidance: Smart Card Enabled Physical Access Control Systems, Version 2.3 , The Government Smart Card Interagency Advisory Board’s Physical Security Interagency Interoperability Working Group, December 20, 2005. http://www.idmanagement.gov/tig_scepacs_v2-3/ [accessed 5/16/18] Appendix G — Terminology

The following terms are used in this document.

Access Control The process of granting or denying specific requests to: 1) obtain and use information and related information processing services; and 2) enter physical facilities (e.g., Federal buildings, military establishments, and border crossing entrances).

Access Control List A list of (identifier, permissions) pairs associated with a resource or an asset. As an expression of security policy, a person may perform an operation on a resource or asset if and only if the person’s identifier is present in the access control list (explicitly or implicitly), and the permissions in the (identifier, permissions) pair include the permission to perform the requested operation.

Asymmetric Keys: Two related keys, a public key and a private key, that are used to perform complementary operations, such as authentication, encryption and decryption, signature generation and signature verification.

Assurance Level A measure of trust or confidence in an authentication mechanism defined in terms of four levels:

• Level 1: LITTLE OR NO confidence
• Level 2: SOME confidence
• Level 3: HIGH confidence
• Level 4: VERY HIGH confidence Authentication The process of establishing confidence of authenticity; in this case, in the validity of a person’s identity. In this publication, authentication often means the performance of a PIV authentication mechanism.

Authentication in Context Authentication in context is a concept in which PACS may benefit from previous authentication within nested areas in a facility. The PACS may use information from previous access control decisions (“context”) when making a new access control decision.

Authorization In this publication, a process that associates permission to access a resource or asset with a person and the person’s identifier(s).

Authenticator A memory, possession, or quality of a person that can serve as proof of identity, when presented to a verifier of the appropriate kind. For example, passwords, cryptographic keys, and biometrics are authenticators. BIO A [FIPS201] authentication mechanism that is implemented by using a fingerprint or iris images data object sent from the PIV Card to the PACS and which is matched to the cardholder’s live scan.

BIO-A A [FIPS201] authentication mechanism in which the BIO authentication mechanism is performed in the presence of an attendant who supervises the use of the PIV Card and the submission of the PIN and the sample biometric by the cardholder.

BIO(-A) A shorthand used throughout the document to represent both BIO and BIO-A authentication mechanisms.

Caching Status Proxy A system used to store and re-validate certificates previously harvested from PIV cards during PACS registration. For each certificate in the cache, the proxy updates the PACS and Control Panels with the latest certificate status. The caching status proxy is usually configurable to increase or decrease the frequency with which certificates are validated.

Card UUID The Card UUID is a UUID that is unique for each card and is a required data element on all [SP800-73] compliant PIV Cards.

Cardholder An individual possessing an issued PIV Card.

Cardholder Unique Identifier (CHUID) A deprecated [FIPS201] authentication mechanism or the PIV Card data object containing credential identifiers of the same name.

Cardholder UUID The Cardholder UUID is a UUID that is a persistent identifier for the cardholder. This UUID is an optional data element on [SP800- 73] compliant PIV Cards.

Certificate A data object containing a subject identifier, a public key, and other information that is digitally signed by a certification authority. Certificates convey trust in the relationship of the subject identifier to the public key.

Certificate Revocation List A list of revoked public key certificates created and digitally signed by a certification authority. See [RFC5280]

Certification Authority A trusted entity that issues and revokes public key certificates.

Cloning In this publication, a process to create a verbatim copy of a PIV Card, or a partial copy sufficient to perform one or more authentication mechanisms as if it were the original card. Contact Reader A smart card reader that communicates with the integrated circuit chip in a smart card using electrical signals on wires touching the smart card’s contact pad. The PIV contact interface is standardized by International Organization of Standards / International Electrotechnical Commission (ISO/IEC) 7816-3 [ISO/IEC7816] .

Contactless Reader A smart card reader that communicates with the integrated circuit chip in a smart card using radio frequency (RF) signaling. The PIV contactless interface is standardized by [ISO/IEC 14443] .

Controller (or Control Panel, or Panel) A device located within the secure area that communicates with multiple PIV Card readers and door actuators, and with the Head End System. The PIV Card readers provide cardholder information to the controller, which it uses to make access control decisions and release door-locking mechanisms. The controller communicates with the Head End System to receive changes in access permissions, report unauthorized access attempts and send audit records and other log information. Most modern controllers can continue to operate properly during periods of time in which communication with the Head End is disrupted and can journal transactions so that they can be reported to the Head End when communication is restored.

A controller is often responsible for generating challenges and verifying responses from PIV cards presented at readers. Some control panels can be configured to store certificates and their status to improve performance during authentication at the reader If not configured to store certificates and their status, a dedicated authentication controller can be used to perform challenges and responses using cached certificates. The outcome of the authentication response is then passed to the control panel in the form of the PIV card identifier, such as a FASC-N or a Card UUID.

Counterfeiting In this publication, the creation of a fake ID card that can perform one or more authentication mechanisms, without copying a legitimate card (see Cloning).

Credential In this publication, a collection of information about a person, attested to by an issuing authority. A credential is a data object (e.g., a certificate) that can be used to authenticate the cardholder. One or more data object credentials may be stored on the same physical memory device (e.g., a PIV Card).

Credential Validation The process of determining if a credential is valid , i.e., it was legitimately issued, its activation date has been reached, it has not expired, it has not been tampered with, and it has not been revoked, suspended, or revoked by the issuing authority.

Digital Signature A data object produced by a digital signature method, such as Rivest, Shamir, Adleman (RSA) or the Elliptic Curve Digital Signature Algorithm (ECDSA), that when verified provides strong evidence of the origin and integrity of the signed data object.

Facility Security Committee A committee consisting of representatives of Federal tenants in a facility, and possibly the building owner or management. The committee is responsible for building-specific security issues and approval of security policies and practices.

Federal Agency Smart Credential Number (FASC-N) As required by [FIPS201] , the FASC-N is one of the primary identifiers on the PIV Card for physical access control. The FASC-N is a fixed length (25 byte) data object, specified in [TIG SCEPACS] , and included in several data objects on a PIV Card.

FASC-N Identifier The FASC-N shall be in accordance with [TIG SCEPACS] . A subset of FASC-N, a FASC-N Identifier, is a unique identifier as described in [TIG SCEPACS] . Section 2.1, 10 th paragraph of [TIG SCEPACS] states “For full interoperability of a PACS it must at a minimum be able to distinguish fourteen digits (i.e., a combination of an Agency Code, System Code, and Credential Number) when matching FASC-N based credentials to enrolled card holders.” Also, Section 6.6, 3 rd paragraph of [TIG SCEPACS] states, “The combination of an Agency Code, System Code, and Credential Number is a fully qualified number that is uniquely assigned to a single individual.” The Agency Code is assigned to each Department or Agency by Special Publication 800-87, Codes for the Identification of Federal and Federally-Assisted Organizations [SP800-87] . The subordinate System Code and Credential Number value assignment is subject to Department or Agency policy, provided that the FASC-N Identifier (i.e., the concatenated Agency Code, System Code, and Credential Number) is unique for each card. Head End System (or Access Control Server) A system including application software, database, a Head End server, and one or more networked personal computers. The Head End server is typically used to enroll an individual's name, create a unique ID number, and assign access privileges and an expiration date. The server is also used to maintain this information and refresh the controller(s) with the latest changes. The Head End System may also be configured to host the certificate cache used by a caching status proxy. In other cases, the Head End System may include a caching status proxy. Identifier (or Unique Identifier) In this publication, a data object, assigned by an authority, that unambiguously identifies a person within a defined community. For example, a driver license number identifies a licensed driver within a state. The authority registers people and guarantees assignment of each identifier to a unique person.

Identity Credential A credential that contains one or more identifiers for its subject, a person. In this publication, an identity credential is designed to verify the identity of its subject through authentication mechanisms, via an electronically mechanism (see PKI-CAK, PKI-AUTH, BIO, BIO-A, etc.).

Infrastructure Distributed substructure of a large-scale organization that facilitates related functions or operations, e.g., telecommunications infrastructure. With regard to PACS, components include conduit, cabling, power supplies, battery backup, electrified door hardware, door position switches, and remote exit devices, as well as connectivity with other life safety systems that will ensure egress in the event of an emergency.

Interoperability In this publication, the quality of allowing any government facility or information system to verify a cardholder’s identity using the credentials on the PIV Card, regardless of the PIV Card Issuer (PCI).

Issuance (or Credential Issuance) The process by which an issuing authority obtains and verifies information about a person, assigns one or more unique identifiers to the person, prepares information to be placed in or on a credential, produces a physical or data object credential, and delivers the finished credential to its subject. In the case of PIV Cards, issuance is performed only by accredited PCIs.

Issuer The organization that is issuing the PIV Card to an applicant.

Multi-Factor Authentication Authentication based on more than one factor. In some contexts, each factor is a different authenticator. In other contexts, each factor is one of “something you know, something you have, something you are” (i.e., memorized fact, token, or biometric) and thus the number of factors is 1, 2, or 3.

OCC-AUTH A two-factor authentication mechanism that uses secure messaging and on-card comparison of cardholder fingerprint(s).

Online Certificate Status Protocol (OCSP) An online protocol used to determine the status of a public key certificate. See [RFC2560]

PACS Registration The process of authenticating, validating, and verifying information about the PIV cardholder prior to entering the information into a PACS server. The information added during registration is then utilized to perform authentication and authorization of an individual at an access point.

Path Validation (or Trust Path Validation) The process of verifying the binding between the subject identifier and subject public key in a certificate, based on the public key of a trust anchor, through the validation of a chain of certificates that begins with a certificate issued by the trust anchor and ends with the target certificate. Successful path validation provides strong evidence that the information in the target certificate is trustworthy.

Personal Identification Number (PIN) A short numeric password (6 to 8 digits) used as an authenticator by the PIV Card to authenticate the cardholder.

Personal Identity Verification (PIV) Card A physical artifact (e.g., identity card, “smart” card) issued to an individual that contains a PIV Card Application which stores identity credentials (e.g., photograph, cryptographic keys, digitized fingerprint representation) so that the claimed identity of the cardholder can be verified against the stored credentials by another person (human readable and verifiable) or an automated process (computer readable and verifiable).

PIV System A system comprised of components and processes that support a common (smart card-based) platform for identity authentication across Federal departments and agencies for access to multiple types of physical access environments.

Physical Access Control System (PACS) An electronic system that controls the ability of people to enter a protected area, by means of authentication and authorization at access control points.

PKI A support service to the PIV system that provides the cryptographic keys needed to perform digital signature-based identity verification.

PKI-AUTH A PIV authentication mechanism that is implemented by an asymmetric key challenge/response protocol using the PIV Authentication certificate and key.

PKI-CAK A PIV authentication mechanism that is implemented by an asymmetric key challenge/response protocol using the Card Authentication certificate and key. (PKI-CAK | SYM- CAK) + BIO(-A) A three-factor authentication achieved by combining BIO(-A) with either PKI-CAK or SYM-CAK. In this case, the PKI-CAK or SYM-CAK authentication mechanism is used to authenticate the PIV Card and therefore the entry of the PIN to access the biometric fingerprint template can now be trusted.

Private Key A cryptographic key used with a public key cryptographic algorithm, which is uniquely associated with an entity, and not made public; it is used to generate a digital signature; this key is mathematically linked with a corresponding public key.

Public Key A cryptographic key used with a public key cryptographic algorithm, uniquely associated with an entity, and which may be made public; it is used to verify a digital signature; this key is mathematically linked with a corresponding private key.

Reader A device that interfaces with a PIV Card and a controller to execute or support execution of one or more PIV authentication mechanisms.

Relying Party In this publication, an entity, such as a PACS, that depends upon the trust model of the PIV System to correctly produce the results of authentication, i.e., the identity of the cardholder.

Revocation The process by which an issuing authority renders an issued credential useless. For example, a certification authority may revoke certificates it issues. Typically, a certificate is revoked if its corresponding private key is known to be, or suspected to be, compromised.

Secret Key A key used by a symmetric key algorithm to encrypt, decrypt, sign, or verify information. In a symmetric key infrastructure (SKI), the sender and receiver of encrypted information must share the same secret key.

Secure Messaging A protocol by which a PIV Card Application is authenticated to the relying system. Secure Messaging is used to provide confidentiality and integrity protection for the card commands that are sent to the card as for the responses from the PIV Card.

Skimming Surreptitiously obtaining data from a contactless smart card, using a hidden reader that powers, commands, and reads from the card within the maximum read distance (reported as about 25 cm with [ISO/IEC 14443] smart cards like the PIV Card). [SKIMMER]

Sniffing Surreptitiously obtaining data from a contactless smart card, using a hidden reader that receives RF signals from a legitimate reader and smart card when they perform a transaction. Sniffing is a form of electronic eavesdropping. Sniffing is possible at greater distances than skimming.

Social Engineering A process or technique, similar to a confidence game, used to obtain information from a person without raising suspicion.

SYM-CAK The SYM-CAK is an authentication mechanism based on the optional symmetric card authentication key. As the name implies, the purpose of the SYM-CAK authentication mechanism is to authenticate the card and thereby the cardholder.

Symmetric Key A cryptographic key that is used to perform both the cryptographic operation and its inverse, for example to encrypt and decrypt, or create a message authentication code and to verify the code.

Trust Anchor A named entity producing digital signatures, and a corresponding certificate that a relying party has decided to trust, i.e., if a digital signature is verified using the public key within the certificate, the signature is trusted to have been made by the entity named in the certificate.

Validation In this publication, the process of determining that an identity credential was legitimately issued and is still valid, i.e., has not expired or been revoked.

Verification The process of determining if an assertion is true, particularly the process of determining if a data object possesses a digital signature produced by the purported signer.

VIS A downgraded [FIPS201] authentication mechanism in which the visual identity verification of a PIV Card is done by a human guard.

Virtual Contact Interface An interface established over the contactless interface after the presentation of the pairing code to the PIV Card using secure messaging. All non-card-management operations that are allowed over contact interface may be carried out over the VCI.

Wiegand With regard to deployed PACS, a one-way communication protocol consisting of a formatted bit string used from the access reader to the controller. It can be used with any media, including proximity, bar code, magnetic stripe, and smart cards. Appendix H — Abbreviations and Acronyms

ACL Access Control List BIO Authentication Using Off-Card Biometric Comparison BIO-A Attended Authentication Using Off-Card Biometric Comparison BIO(-A) A short-hand to represent both BIO and BIO-A authentication mechanism CHUID Cardholder Unique Identifier CRL Certificate Revocation List ECC Elliptic Curve Cryptography ECDSA Elliptic Curve Digital Signature Algorithm FASC-N Federal Agency Smart Credential Number FIPS Federal Information Processing Standards FISMA Federal Information Security Modernization Act FSL Facility Security Level GSA General Services Administration GUID Global Unique Identification Number HSPD Homeland Security Presidential Directive ID Identification IEC International Electrotechnical Commission ISC Interagency Security Committee ISO International Organization for Standardization IT Information Technology ITL Information Technology Laboratory LB Lower Bound NIST National Institute of Standards and Technology OCC On-Card Biometric Comparison OCC-AUTH Authentication Using On-Card Biometric Comparison OCSP Online Certificate Status Protocol OMB Office of Management and Budget PACS Physical Access Control System PCI PIV Card Issuer PIN Personal Identification Number PIV Personal Identity Verification PKI-AUTH Authentication with the PIV Authentication Certificate Credential PKI-CAK Authentication with the Card Authentication Certificate Credential POST Power-on self-test RF Radio Frequency RSA Rivest, Shamir, Adleman SP Special Publication SYM-CAK Authentication with the Symmetric Card Authentication Key UB Upper Bound UUID Universally Unique Identifier VCI Virtual Contact Interface VIS Authentication using PIV Visual Credentials Appendix I — Revision History

Version Release Date Updates SP 800-116 November 2008 Initial Release SP 800-116 Revision 1 May 2018 • Reflected [FIPS201] deprecation of CHUID authentication mechanism throughout the document.
• Emphasized that while use of the CHUID authentication mechanism has been deprecated, the on-card CHUID data element has not been deprecated and continues to be mandatory. This data element is the only element with the optional Cardholder UUID. It is also used by the BIO(-A) and SYM-CAK authentication mechanisms as a source for the card’s expiration date and contains unique identifiers to compare against PACS ACL entries.
• Reflected downgrade of VIS authentication mechanism to LITTLE or NO” confidence in cardholder’s identity in content of document.
• Removed VIS + CHUID as an option to transitioning from Unrestricted to Controlled areas since it provides “LITTLE or NO” confidence in the identity of the cardholder.
• Added OCC-AUTH as a two-factor authentication mechanism.
• Added credential validation requirements from [FIPS201] to applicable sections of the document.
• Split table on PIV Authentication Mechanism into two – one for contact and one for contactless PIV Authentication Mechanisms.
• Expanded authentication in context to allow context provided by physically measures to prevent more than one person from passing through an access point (e.g., turnstiles, gates) after each authentication. This is in addition to authentication in context where PACS can store and recall recent access control decisions.
• Added Appendix C – Improving PKI Authentication Transaction Times.
• Expanded content of PACS registration.
• Added a new section 6.1 titled “PIV Identifiers” to describe the identifiers available on the PIV Card that can map to a PACS’s access control list.
• Moved section 7 (PIV Authentication Mechanisms) to Appendix A.
• Removed Section 9 titled “Migration Strategy” from content of document as implementation have matured and are more advanced.
• Removed section 10 titled ‘Future Topics’. [FIPS201] and associated special publication have addressed the future topics. The content of section 10 is now part of the document (i.e., global identifier and OCC-AUTH).
• Moved Appendix C to B and added a list of authentication mechanism combinations for mechanism that have no context.
• Moved Section 5 discussion on limitations of pre-PIV legacy PACS system to Appendix E.
• In coordination with the Interagency Security Committee (ISC), replaced reference to the Department of Justice’s “Vulnerability Assessment Report of Federal Facilities” document with the ISC’s document titled “Risk Management Process for Federal Facilities” to aid deriving the security requirement for facilities.
• Added Appendix I to provide an informative revision history.

3 HKA HK, HA, or HKA (was: Terminology)

Title changed

Before · SP 800-116

After · SP 800-116 Rev. 1

Control changed

Before · SP 800-116

After · SP 800-116 Rev. 1

`3` HKA HK, HA, or HKA (was: Terminology)