BaselineWatch
Desk
Your fleet and your work Fleetyour releases and the hardware they run onTriagewhat needs a decisionWatchlistthe products and platforms you runSaved searchesthe lists you come back to
This instance Sourceswhat is read, how often, under what termsDigestthe daily or weekly summary, and alerts
How it is drawn Appearancethe look and the colour schemeBrandingthe mark this instance wears
Owner sign-in

7.4 PACS Registration

NIST PIV and digital identity SP 800-116 Rev. 1 against SP 800-116
All changes in this version
removed 7 PIV Authentication Mechanisms part of 7

Title changed

Before · SP 800-116

PACS Registration

After · SP 800-116 Rev. 1

PACS Registration

Control changed

Before · SP 800-116

Before a PACS may grant access to a cardholder, the cardholder must be authorized for access in the PACS. Authorization may be granted to a group of individuals, such as all PIV cardholders, or all PIV cardholders sponsored by a specific agency or bureau (see Appendix B). If authorization is granted to specific individuals, information about the cardholder (specifically, at least the FASC-N) must be added to the PACS Server’s authorization database. If on-line credential validation is performed by the PACS at the time of each authentication (see Section 7.5), the PACS might store no information about the cardholder other than the authorizations and transaction audit log. If a caching status proxy is employed, information about the cardholder, including the cardholder’s certificate, must be added to the server’s database. Where one-factor authentication is sufficient, the CAK or PKI certificate may be used. Where at least two-factor authentication is required, the PIV Authentication Key certificate should be used. Enrollment using a caching status proxy should collect and store information required for all FIPS 201 authentication mechanisms needed in the event of increased Threat Condition level. Recommendation: When a card is terminated, the PIV Card Issuer must revoke all valid authentication certificates for the PIV Card. The authentication certificates include the PIV Authentication Key certificate and the Card Authentication Key certificate (if present). When the individual is enrolled using a caching status proxy, the enrollment station obtains the PIV Authentication or asymmetric Card Authentication Key certificate from the PIV Card, validates the certificate (including checking the certificate’s revocation status), and sends a

10 Although a single perimeter could separate areas with a difference of more than one impact level, this practice may be judged high risk and be prohibited by local security policy. challenge to the card to verify that the card holds the private key corresponding to the certificate. The authentication certificate is then added to the server’s database, along with any other information about the individual that the server maintains (e.g., the individual’s authorizations). Since certificate revocation is used as a mechanism to indicate that a PIV Card should no longer be considered valid, the caching status proxy should periodically re-validate all of the certificates in its database and deactivate the access privileges of any individual whose certificate has expired or has been revoked. Re-validation should be performed by the caching status proxy at least once per day. Once the decision has been made to revoke a PIN credential, agencies may employ local de-authorization methods to supplement revocation and achieve a more rapid local effect. When an individual presents his or her PIV Card to a door reader, the door reader obtains the authentication certificate from the card, sends a challenge to the card, and then uses the public key in the certificate to verify the response to the challenge. Recommendation: The CHUID may be collected at registration, but it should be treated as if it were a password (since digital signature provides entropy equivalent to a password) for purposes of retention, i.e., hashed, the hash stored, and the CHUID deleted. A stored CHUID presents risks similar to a stored password; it can be copied and used to gain access. Data elements may be extracted from the CHUID and retained (e.g., the FASC-N, Data Universal Numbering System (DUNS) Number, and Global Unique Identifier (GUID)), and a retained hash is sufficient to enable verification. NIST strongly recommends against the storage of complete CHUIDs in relying systems. Recommendation: PKI and asymmetric CAK authentication mechanisms should be implemented by a PACS reader capable of full certificate path validation, either on-line or using a caching status proxy. Agencies should consider using on-line status checks as a means to reduce the latency of PIV Card status when a PIV Card is used for access to Exclusion areas. If a caching status proxy is used, the certificates should be captured when the PIV Card is registered to the PACS.

After · SP 800-116 Rev. 1

Before a PACS may grant access to a cardholder, the cardholder must be authorized for access in the PACS. Authorization may be granted to a group of individuals, such as all PIV cardholders, or all PIV cardholders sponsored by a specific agency or bureau (see Appendix B). If authorization is granted to specific individuals, information about the cardholder (specifically, at least the FASC-N) must be added to the PACS Server’s authorization database. If on-line credential validation is performed by the PACS at the time of each authentication (see Section 7.5), the PACS might store no information about the cardholder other than the authorizations and transaction audit log. If a caching status proxy is employed, information about the cardholder, including the cardholder’s certificate, must be added to the server’s database. Where one-factor authentication is sufficient, the CAK or PKI certificate may be used. Where at least two-factor authentication is required, the PIV Authentication Key certificate should be used. Enrollment using a caching status proxy should collect and store information required for all FIPS 201 authentication mechanisms needed in the event of increased Threat Condition level. Recommendation: When a card is terminated, the PIV Card Issuer must revoke all valid authentication certificates for the PIV Card. The authentication certificates include the PIV Authentication Key certificate and the Card Authentication Key certificate (if present). When the individual is enrolled using a caching status proxy, the enrollment station obtains the PIV Authentication or asymmetric Card Authentication Key certificate from the PIV Card, validates the certificate (including checking the certificate’s revocation status), and sends a

10 Although a single perimeter could separate areas with a difference of more than one impact level, this practice may be judged high risk and be prohibited by local security policy. challenge to the card to verify that the card holds the private key corresponding to the certificate. The authentication certificate is then added to the server’s database, along with any other information about the individual that the server maintains (e.g., the individual’s authorizations). Since certificate revocation is used as a mechanism to indicate that a PIV Card should no longer be considered valid, the caching status proxy should periodically re-validate all of the certificates in its database and deactivate the access privileges of any individual whose certificate has expired or has been revoked. Re-validation should be performed by the caching status proxy at least once per day. Once the decision has been made to revoke a PIN credential, agencies may employ local de-authorization methods to supplement revocation and achieve a more rapid local effect. When an individual presents his or her PIV Card to a door reader, the door reader obtains the authentication certificate from the card, sends a challenge to the card, and then uses the public key in the certificate to verify the response to the challenge. Recommendation: The CHUID may be collected at registration, but it should be treated as if it were a password (since digital signature provides entropy equivalent to a password) for purposes of retention, i.e., hashed, the hash stored, and the CHUID deleted. A stored CHUID presents risks similar to a stored password; it can be copied and used to gain access. Data elements may be extracted from the CHUID and retained (e.g., the FASC-N, Data Universal Numbering System (DUNS) Number, and Global Unique Identifier (GUID)), and a retained hash is sufficient to enable verification. NIST strongly recommends against the storage of complete CHUIDs in relying systems. Recommendation: PKI and asymmetric CAK authentication mechanisms should be implemented by a PACS reader capable of full certificate path validation, either on-line or using a caching status proxy. Agencies should consider using on-line status checks as a means to reduce the latency of PIV Card status when a PIV Card is used for access to Exclusion areas. If a caching status proxy is used, the certificates should be captured when the PIV Card is registered to the PACS.