Skip to content

Credentials Specification for Accessing ACVP

Jump to bottom
Chris Celi edited this page Feb 17, 2022 · 3 revisions

Welcome to the ACVP wiki!

The goal for this project is to provide a messaging protocol that can be used with existing authentication and communication protocols to enable the automation of testing and validation of NIST-approved cryptographic algorithms.

We are working actively on this exciting project and people are starting to notice. Thanks!

Credentials for accessing the demo server

To access the demo server one needs a TLS credential and a one-time password (OTP).

See these detailed instructions first for obtaining TLS credentials.

Second-Factor Authentication and Authorization Schema for Accessing and Working with the NIST Automated Cryptographic Validation Services

The second-factor authentication is based on the Time-based One-Time-Password (TOTP) from RFC 6238.

High-Level Architecture.

The high-level architecture of an enterprise client architecture is shown in the figure below. High-Level Architecture.

The architecture includes two application servers (ACVP Proxy and TOTP). The application servers shall be deployed behind a firewall. The TOTP server shall be accessible internally only with respect to the enterprise firewall. The primary function of the TOTP server is to house the client TOTP key K (see RFC 6238) assigned to the person in the enterprise responsible for accessing ACVTS and compute the current OTP upon requests from the ACVP Proxy for completing the two-factor authentication process.

An alternative high-level architecture of an enterprise client architecture is shown below. High-Level Architecture.

The architecture includes one application server (TOTP server), one client machine with the client ACVP application. The TOTP server and client machine shall be deployed behind a firewall. The TOTP server shall be accessible internally only with respect to the enterprise firewall. The primary function of the TOTP server is to house the client TOTP key K (see RFC 6238) assigned to the enterprise for accessing ACVTS and compute the current OTP upon requests from the ACVP Proxy for completing the two-factor authentication process.

Each participating partner to ACVTS that implements this architecture shall obtain a Base64-encoded client TOTP key upon completing a successful National Voluntary Laboratory Accreditation Program (NVLAP) accreditation.

TOTP Parameters

While the TOTP authentication is described in RFC 6238 and RFC 4226, there are several parameters that are important to specify to allow clients to correctly authenticate.

  • The T0 (time) offset from UNIX time shall be zero.
  • Synchronization: the server shall use the Network Time Protocol (NTP) to synchronize with the NIST time server at time.nist.gov. It is expected that clients use a corresponding methodology to prevent clock skew.
  • The time step (or X as specified in RFC 6238) shall be 30 seconds.
  • Cryptographic primitives: HMAC-SHA-256 based on SHA-256 shall be used in this implementation, a valid option per RFC 6238. Please refer to Appendices A and B in RFC 6238 for details on how to compute the TOTP value with these cryptographic primitives and validate the correctness of your client implementation.
  • TOTP length: the number of digits produced based on RFC 4226 shall be 8 digits. Note that any leading zeros in the TOTP value shall be preserved up to the 8-digit length.

As part of the authorization process there is the option on the part of the server to allow a “window,” checking OTP values a specified number of steps either forward or backward from the current step, to handle both network delays and possible clock skew. RFC 6238 recommends checking one step backward to accommodate any network delay and provides no specific guidance on a window for a clock skew other than to recommend this window remain small. There will be a small window, likely one step backward and forward, but this value may change over time based on security and operational considerations.

Two-factor authentication flows

The ACVTS server has a dedicated RESTful entry point for client authentication: https://demo.acvts.nist.gov/acvp/v1/login. The corresponding two-factor authentication flow is shown in the figure below. Note that the successful first-factor authentication is a prerequisite for performing the second factor authentication with TOTP. Note also that this workflow utilizes two protocols: Transmission Control Protocol and Internet Protocol (TCP/IP) and Hypertext Transfer Protocol Secure (HTTPS). Authentication flows.

The NIST ACVTS server links a client ID to a successful first-factor authentication upon completing the two-way TLS handshake for the just established session with the client ID corresponding to the client certificate used in the handshake. The NIST ACVTS server and the NIST TOTP server maintain a database with client ID’s which must be synchronized for proper operation of the second-factor authentication. The NIST TOTP server uses the client ID to find the shared secret K corresponding to that ID. The NIST TOTP server then computes an OTP using the algorithm from RFC 6238. The NIST TOTP server next compares the computed OTP with the supplied client OTP value. If the two match, within a server defined window, the client is authenticated, otherwise the authentication attempt is rejected. Correspondingly, the ACVTS server creates an Authorization JSON Web Token (JWT) and returns it to the client upon success.

Authorization flows

Successful client authentication is required for performing any work with the ACVTS server. In addition, performing specific validation actions or queries on ACVTS requires corresponding authorization. This section defines the basic workflows with the corresponding authorization required for them. A fundamental assumption for this definition is that once the first factor authentication is established with the two-way TLS, ACVTS will manage the workflow sessions for clients using JWT, separately from the session management in TLS. This section considers only the workflow session management with JWT with the assumption that the underlying TLS session between a given client and the ACVTS server is independently maintained.

The workflow authorization flows are shown in the figure below. Authorization flows

Note that all HTTP requests listed are over TLS. Note also that to re-authenticate in this context when the JWT is expired the client needs to submit only the new OTP value using the TLS session previously established. In other words, the client would need to perform only the actions shown in section "Two-factor authentication flows" above that correspond to the second factor authentication and reuse the 2-way TLS session as a first factor authentication as long as the TLS session is active. The basic process flows as follows.

  1. POST a login request to /acvp/v1/login.

  2. Receive the response which contains an accessToken for the current session.

  3. POST the registration to /acvp/v1/testSessions with the accessToken in the Authorization header.

  4. Receive the response which contains the test session ID, vector set IDs, and a new accessToken that contains claims for this data.

  5. GET /acvp/v1/testSessions/<Test Session ID>/vectorSets/<Vector Set ID> with the accessToken the Authorization header to receive the prompt for the vector set.

  6. POST the answers to /acvp/v1/testSessions/<Test Session ID>/vectorSets/<Vector Set ID> with the accessToken the Authorization header.

  7. GET /acvp/v1/testSessions/<Test Session ID>/vectorSets/<Vector Set ID>/results with the accessToken the Authorization header to receive the results.

The access tokens received from either the /acvp/v1/login endpoint or the /acvp/v1/testSessions registration endpoint are set to expire after a pre-defined period, and will result in a “401 Unauthorized” HTTP status code when used outside of this window. The following process will allow the client to refresh the token.

  1. POST to /acvp/v1/login with the expired accessToken and a freshly generated TOTP.

  2. Receive the response with an updated accessToken with the same claims as the previous accessToken. This will allow access to the same vector sets and test session as the previous token.

Additional considerations

The TLS protocols used for authentication shall be version 1.2 or higher. The cipher-suites chosen for each TLS session shall use Federal Information Processing Standard (FIPS)-approved and validated algorithm primitives. The negotiated cipher-suite for each TLS session shall use an authenticated encryption with additional data (AEAD) symmetric block cipher, such as the Galois Counter mode of the Advanced Encryption Standard AES-GCM.

The Partner ACVP Proxy server and the Partner TOTP server shall be deployed on the enterprise intranet and may use other protocols, such as the Internet Protocol Security (IPSec) for communication between themselves. If the Internet Key Exchange version 2 (IKEv2) protocol is used for key establishment, it shall use FIPS-approved and validated algorithm primitives. The negotiated cipher-suite for the resulting session shall use an AEAD symmetric block cipher, such as AES-GCM.

The TOTP server shall authenticate the Proxy server or the ACVP application before sending any authentication data. In the case of IPSec with a pre-shared key, the authentication of the Proxy server is implicit.

Provisioning of shared secrets for TOTP

To deploy and use TOTP in practice one must provision the shared secret K on the client TOTP server and the NIST TOTP server. We refer to Section 7.5 in RFC 4226 for best practices around generation and management of shared secrets for OTP.

Clone this wiki locally