Conformance to Suite-B Cryptography requirements |
Suite B is a set of cryptographic algorithms used for encryption, key exchange, digital signature, and hashing. As per RFC 6460, the Fact Sheet on Suite B Cryptography requires key establishment and authentication algorithms based on Elliptic Curve Cryptography and encryption using AES.
In particular, Suite B includes the following:
Advanced Encryption Standard (AES) – FIPS 197 (with key sizes of 128 and 256 bits)
Elliptic Curve Digital Signature Algorithm (ECDSA) using 256 and 384 bit prime module curves – digital signatures
Elliptic Curve Diffie-Hellman (ECDH) using 256 and 384 bit prime module curves – key exchange
Secure Hash Algorithm 2 (SHA-256 and SHA-384) – message digest
Additional PKI / Certificate management requirements: Certificate Revocation List (CRL) and Online Certificate Status Protocol (OCSP)
Suite B algorithms are defined to support two
minimum levels of security, minLoS, with security
strengths of 128 and 192 bits:
minLOS-128minLOS-192
The level of security is determined by the strength of the keys.
Configuration support
CRL configuration facts
When a certificate is presented while a CRL download is in progress and that the cached CRL has become stale or is not present, the acceptation or rejection of the certificate is subject to the policy enforcement of CRL configuration.
When a CRL becomes stale, for example if the current time is ahead of the
nextUpdateTimeof the CRL, the CRL is deleted immediately.Once a successful TLS connection is established, even if the server certificate is revoked at a later time, the connection continues to exist until a renegotiation happens.
If a CRL download fails due to any reason (for example, the server is not reachable or the memory is not available), an event is recorded in the system log with the failure reason. Once you have resolved the failure issue, you must initiate a download.
You can download only one CRL at a time. If you initiate a request to fetch a CRL while a CRL download is already in progress, your request will be rejected.
The Cumulative Maximum storage allowed for CRLs in flash is 1MB.
Only two CRL files are allowed in the system. Any fetch request beyond this limit is rejected and logged appropriately.
CRL fetch is supported only via LDAP. The CRL downloaded is of DER (binary) format.
If you delete an installed root-certificate when a CRL download for that profile is already in progress, the download will be uninterrupted. The downloaded CRL thereafter will be deleted once its lifetime expires (becomes stale).
When you configure a CRL URL for a given TA profile, it takes priority over the CDP server settings mentioned in the certificate.
You can configure two URLs per CRL/CDP LDAP servers and OCSP responders.
Standard TCP timeouts are applicable during CRL fetch or OCSP status fetch.
CRLs are also written into the non-volatile memory so that when a device reboots or failover and previously had a valid CRL, it will automatically be loaded from the non-volatile memory avoiding a re-fetch of the CRL. In addition, for every 24 hour period (per CRL file), a given CRL file is updated into the flash memory if there is any recent update to the last written state.
OCSP configuration facts
If you delete an installed root-certificate at the same time that an OCSP handshake is in progress, the revocation status o/p will be based on the deleted root-certificate.
If you configure an OCSP responder URL for a given TA profile, it takes priority over the OCSP server settings specified in the AIA field of the client certificate.
You can configure at most two OCSP responder URLs.
If the revocation-check is configured as both OCSP and CRL, OCSP takes precedence. For example, the switch tries to retrieve the revocation status using OCSP first followed by CRL.
Configure CRL for revocation check
Configures the parameters for the Certificate Revocation list (CRL) revocation check mode.
Syntax
crypto pki ta-profileprofile-namerevocation-check crlstrict|optionalurl1REVOC-URL| url2REVOC-URL|refresh-intervalhours