Information About PKI
This section provides information about PKI.
CAs and Digital Certificates
Certificate authorities (CAs) manage certificate requests and issue certificates to participating entities such as hosts, network devices, or users. The CAs provide centralized key management for the participating entities.
Digital signatures, based on public key cryptography, digitally authenticate devices and individual users. In public key cryptography, such as the RSA encryption system, each device or user has a key pair that contains both a private key and a public key. The private key is kept secret and is known only to the owning device or user only. However, the public key is known to everybody. Anything encrypted with one of the keys can be decrypted with the other. A signature is formed when data is encrypted with a sender’s private key. The receiver verifies the signature by decrypting the message with the sender’s public key. This process relies on the receiver having a copy of the sender’s public key and knowing with a high degree of certainty that it really does belong to the sender and not to someone pretending to be the sender.
Digital certificates link the digital signature to the sender. A digital certificate contains information to identify a user or device, such as the name, serial number, company, department, or IP address. It also contains a copy of the entity’s public key. The CA that signs the certificate is a third party that the receiver explicitly trusts to validate identities and to create digital certificates.
To validate the signature of the CA, the receiver must first know the CA’s public key. Typically, this process is handled out of band or through an operation done at installation. For instance, most web browsers are configured with the public keys of several CAs by default.
Trust Model, Trust Points, and Identity CAs
The PKI trust model is hierarchical with multiple configurable trusted CAs. You can configure each participating device with a list of trusted CAs so that a peer certificate obtained during the security protocol exchanges can be authenticated if it was issued by one of the locally trusted CAs. The Cisco NX-OS software locally stores the self-signed root certificate of the trusted CA (or certificate chain for a subordinate CA). The process of securely obtaining a trusted CA’s root certificate (or the entire chain in the case of a subordinate CA) and storing it locally is called CA authentication.
The information about a trusted CA that you have configured is called the trust point and the CA itself is called a trust point CA. This information consists of a CA certificate (or certificate chain in case of a subordinate CA) and certificate revocation checking information.
The Cisco NX-OS device can also enroll with a trust point to obtain an identity certificate to associate with a key pair. This trust point is called an identity CA.
CA Certificate Hierarchy
For secure services, you typically have multiple trusted CAs. The CAs are usually installed in all the hosts as a bundle. The NX-OS PKI infrastructure does support importing certificate chain. However, with the current CLIs, one chain at a time can be installed. This procedure can be cumbersome when there are several CA chains to be installed. This requires a facility to download CA bundles that could include several intermediate and root CAs.
Trustpoint Import CLIs
The crypto CA trustpoint command binds the CA certificates, CRLs, identity certificates and key pairs to a named label. All files corresponding to each of these entities are stored in the NX-OS certstore directory (/isan/etc/certstore) and tagged with the trustpoint label.
To access the CA certificates, an SSL app only needs to point to the standard NX-OS cert-store and specify that as the CA path during SSL initialization. It does not need to be aware of the trustpoint label under which CAs are installed.
If clients need to bind to an identity certificate, the trustpoint label needs to be used as the binding point.
The import pkcs command is enhanced to install the CA certificates under a trustpoint label. This can be further enhanced to install a CA bundle. The import command structure is modified to add pkcs7 option which is used for providing CA bundle file in pkcs7 format. The proposed solution is to unpack the CA bundle and install each CA chain under its own label. The labels are formed by appending an index to the main trustpoint label.
Existing trustpoint configs are used under the hood. No new configuration CLIs need to be implemented. There are no changes required from client applications.
Once installed, there is no logical binding of all CA chains to a bundle. So, replace or delete of a CA bundle may need some
additional logic. A configuration CLI,
cabundle <bundle name> could be provided to bind a trustpoint to a ca-bundle. This could be used to delete or modify a bundle, fetch operational
data, and so on.
CISCO-AV-PAIR Parsing Environment
Cisco NX-OS mandatorily requires “shell:roles” as the first attribute of the CISCO-AV-PAIR. If the attribute comes at a later stage, it is not considered. NX-OS must relax this strict ordering requirement irrespective of the arrival of the attribute.
cisco-av-pair=shell:roles="network-admin" snmpv3:auth=”SHA” priv=”AES-128”
The snmpv3 parsing does not check strictly on values, so the values like XXXSHA will pass as SHA. The support for attribute “shell:role” is present for RADIUS, TACACS and LDAP protocols. However, ‘snmpv3’ attributes are not available for LDAP.The proposed changes would be incorporated in TACACS and RADIUS code.
The change is not required in LDAP at this stage as LDAP does not support ‘snmpv3’ attributes.
Currently, second snmpv3 attribute is allowed without the mention of the protocol. That is, both attributes do not need to be prepended by “snmpv3:”
cisco-av-pair=shell:roles="network-admin" shell:priv-lvl=15 snmpv3:auth=”SHA” priv=”AES-128”
cisco-av-pair= snmpv3:auth=”SHA” priv=”AES-128” shell:roles="network-admin" shell:priv-lvl=15
Limitations in DMEization
The following are the limitations in DMEization of “crypto ca import” and “copy tftp” action commands:
Only the pkcs12 file format is supported. The pkcs7 file format has multiple trustpoints associated with it. As a result, the pkcs7 file format will be supported in subsequent releases.
The tftp copy is enabled for bootflash: path only so that the user can import the file without logging in to the switch.
The NX-API post payload cannot be generated for import and TFTP Task Managed Objects.
Multiple copy tasks for TFTP are not supported in parallel. Backend will take time for copying the file.
RSA Key Pairs and Identity Certificates
You can obtain an identity certificate by generating one or more RSA key pairs and associating each RSA key pair with a trust point CA where the Cisco NX-OS device intends to enroll. The Cisco NX-OS device needs only one identity per CA, which consists of one key pair and one identity certificate per CA.
The Cisco NX-OS software allows you to generate RSA key pairs with a configurable key size (or modulus). The default key size is 512. You can also configure an RSA key-pair label. The default key label is the device fully qualified domain name (FQDN).
The following list summarizes the relationship between trust points, RSA key pairs, and identity certificates:
A trust point corresponds to a specific CA that the Cisco NX-OS device trusts for peer certificate verification for any application (such as SSH).
A Cisco NX-OS device can have many trust points and all applications on the device can trust a peer certificate issued by any of the trust point CAs.
A trust point is not restricted to a specific application.
A Cisco NX-OS device enrolls with the CA that corresponds to the trust point to obtain an identity certificate. You can enroll your device with multiple trust points which means that you can obtain a separate identity certificate from each trust point. The identity certificates are used by applications depending upon the purposes specified in the certificate by the issuing CA. The purpose of a certificate is stored in the certificate as a certificate extension.
When enrolling with a trust point, you must specify an RSA key pair to be certified. This key pair must be generated and associated to the trust point before generating the enrollment request. The association between the trust point, key pair, and identity certificate is valid until it is explicitly removed by deleting the certificate, key pair, or trust point.
The subject name in the identity certificate is the fully qualified domain name for the Cisco NX-OS device.
You can generate one or more RSA key pairs on a device and each can be associated to one or more trust points. But no more than one key pair can be associated to a trust point, which means only one identity certificate is allowed from a CA.
If the Cisco NX-OS device obtains multiple identity certificates (each from a distinct CA), the certificate that an application selects to use in a security protocol exchange with a peer is application specific.
You do not need to designate one or more trust points for an application. Any application can use any certificate issued by any trust point as long as the certificate purpose satisfies the application requirements.
You do not need more than one identity certificate from a trust point or more than one key pair to be associated to a trust point. A CA certifies a given identity (or name) only once and does not issue multiple certificates with the same name. If you need more than one identity certificate for a CA and if the CA allows multiple certificates with the same names, you must define another trust point for the same CA, associate another key pair to it, and have it certified.
Multiple Trusted CA Support
The Cisco NX-OS device can trust multiple CAs by configuring multiple trust points and associating each with a distinct CA. With multiple trusted CAs, you do not have to enroll a device with the specific CA that issued the certificate to a peer. Instead, you can configure the device with multiple trusted CAs that the peer trusts. The Cisco NX-OS device can then use a configured trusted CA to verify certificates received from a peer that were not issued by the same CA defined in the identity of the peer device.
PKI Enrollment Support
Enrollment is the process of obtaining an identity certificate for the device that is used for applications like SSH. It occurs between the device that requests the certificate and the certificate authority.
The Cisco NX-OS device performs the following steps when performing the PKI enrollment process:
Generates an RSA private and public key pair on the device.
Generates a certificate request in standard format and forwards it to the CA.
The CA administrator may be required to manually approve the enrollment request at the CA server, when the request is received by the CA.
Receives the issued certificate back from the CA, signed with the CA’s private key.
Writes the certificate into a nonvolatile storage area on the device (bootflash).
Manual Enrollment Using Cut-and-Paste
The Cisco NX-OS software supports certificate retrieval and enrollment using manual cut-and-paste. Cut-and-paste enrollment means that you must cut and paste the certificate requests and resulting certificates between the device and the CA.
You must perform the following steps when using cut and paste in the manual enrollment process:
Create an enrollment certificate request, which the Cisco NX-OS device displays in base64-encoded text form.
Cut and paste the encoded certificate request text in an e-mail or in a web form and send it to the CA.
Receive the issued certificate (in base64-encoded text form) from the CA in an e-mail or in a web browser download.
Cut and paste the issued certificate to the device using the certificate import facility.
Multiple RSA Key Pair and Identity CA Support
Multiple identity CAs enable the device to enroll with more than one trust point, which results in multiple identity certificates, each from a distinct CA. With this feature, the Cisco NX-OS device can participate in SSH and other applications with many peers using certificates issued by CAs that are acceptable to those peers.
The multiple RSA key-pair feature allows the device to maintain a distinct key pair for each CA with which it is enrolled. It can match policy requirements for each CA without conflicting with the requirements specified by the other CAs, such as the key length. The device can generate multiple RSA key pairs and associate each key pair with a distinct trust point. Thereafter, when enrolling with a trust point, the associated key pair is used to construct the certificate request.
Peer Certificate Verification
The PKI support on a Cisco NX-OS device can verify peer certificates. The Cisco NX-OS software verifies certificates received from peers during security exchanges for applications, such as SSH. The applications verify the validity of the peer certificates. The Cisco NX-OS software performs the following steps when verifying peer certificates:
Verifies that the peer certificate is issued by one of the locally trusted CAs.
Verifies that the peer certificate is valid (not expired) with respect to current time.
Verifies that the peer certificate is not yet revoked by the issuing CA.
For revocation checking, the Cisco NX-OS software supports the certificate revocation list (CRL). A trust point CA can use this method to verify that the peer certificate has not been revoked.
Certificate Revocation Checking
The Cisco NX-OS software can check the revocation status of CA certificates. The applications can use the revocation checking mechanisms in the order that you specify. The choices are CRL, NDcPP: OCSP for Syslog, none, or a combination of these methods.
The CAs maintain certificate revocation lists (CRLs) to provide information about certificates revoked prior to their expiration dates. The CAs publish the CRLs in a repository and provide the download public URL in all issued certificates. A client verifying a peer’s certificate can obtain the latest CRL from the issuing CA and use it to determine if the certificate has been revoked. A client can cache the CRLs of some or all of its trusted CAs locally and use them later if necessary until the CRLs expire.
The Cisco NX-OS software allows the manual configuration of predownloaded CRLs for the trust points, and then caches them in the device bootflash (cert-store). During the verification of a peer certificate, the Cisco NX-OS software checks the CRL from the issuing CA only if the CRL has already been cached locally and the revocation checking is configured to use the CRL. Otherwise, the Cisco NX-OS software does not perform CRL checking and considers the certificate to be not revoked unless you have configured other revocation checking methods.
NDcPP: OCSP for Syslog
Online Certificate Status Protocol (OCSP) is a method to check certificate revocation when a peer has to retrieve this revocation information and then validate it to check the certificate revocation status. In this method, the certification revocation status is limited by the peer's ability to reach an OCSP responder through the cloud or by the certificate sender's performance in retrieving the certificate revocation-information.
When the remote syslog server shares the certificate which has an OCSP responder URL, the client sends the server certificate to an external OCSP responder (CA) server. The CA server validates this certificate and confirms if it is a valid or a revoked certificate. In this case, the client does not have to maintain the revoked certificate list locally.
Import and Export Support for Certificates and Associated Key Pairs
As part of the CA authentication and enrollment process, the subordinate CA certificate (or certificate chain) and identity certificates can be imported in standard PEM (base64) format.
The complete identity information in a trust point can be exported to a file in the password-protected PKCS#12 standard format. It can be later imported to the same device (for example, after a system crash) or to a replacement device. The information in a PKCS#12 file consists of the RSA key pair, the identity certificate, and the CA certificate (or chain).