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 Status Certificate Protocol (OCSP)
Suite B algorithms are defined to support two minimum levels of security, minLoS, with security strengths of 128 and 192 bits:
-
minLOS-128 -
minLOS-192
The level of security is determined by the strength of the keys.
Suite B offers configuration support for revocation check and its parameters for ta-profile certificates using CRL and OCSP methods.
MLD: Review comments from Koundiny for which I need input or clarification:
-
Need to mention in detail what an enforcement policy means
MLD: Can someone provide the information?
-
All assumptions on CRL/OCSP should be stated explicitly here or somewhere in the document
MLD: Can someone provide the information?
-
Mention the defaults: i.e. revocation-check would be none which means presented certificate will be accepted directly without doing any revocation checks.
MLD: this is not clear to me.
MLD: Review comments from Koundinya. Erin, please reorganize or change title as appropriate.
-
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.
MLD: Review comments from Koundinya. Erin, please reorganize or change title as appropriate.
-
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.
-
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.
Configures the parameters for the Certificate Revocation list (CRL) revocation check mode.
MLD: As per review comment, need to add info on how to unconfigure the CRL revocation check.