Cisco Cisco Packet Data Interworking Function (PDIF)
IPSec Certificates
▀ Certificate Management Protocol (CMPv2)
▄ IPSec Reference, StarOS Release 16
114
Certificate Management Protocol (CMPv2)
Overview
In cryptography, a public key certificate (also known as a digital certificate or identity certificate) is an electronic
document which uses a digital signature to bind a public key with an identity information, such as the name of a person
or an organization, their address, and so forth. The certificate can be used to verify that a public key belongs to an
individual. The Certificate Management Protocol (CMP) is an Internet protocol used for obtaining X.509 digital
certificates in a public key infrastructure (PKI). It is described in RFC 4210.
document which uses a digital signature to bind a public key with an identity information, such as the name of a person
or an organization, their address, and so forth. The certificate can be used to verify that a public key belongs to an
individual. The Certificate Management Protocol (CMP) is an Internet protocol used for obtaining X.509 digital
certificates in a public key infrastructure (PKI). It is described in RFC 4210.
StarOS implements the subset of CMPv2 functions:
Key pair and X.509 certificate request generation: The StarOS security gateway acts as an end entity as
described in RFC 4210. The gateway generates the X.509 public and private key pair for authentication during
IKE AUTH. It generates the public and private keys using OpenSSL libraries. The generated private key is
saved locally on the management card, and the public key is embedded in the generated X.509 certificate
request. The key uses RSA encryption; SHA-1 with RSA encryption is used on the Hashing function for the
generated certificate. Certificate requests are sent to the Certificate Authority (CA) or Registration Authority
(RA) during the certification process via CMPv2.
IKE AUTH. It generates the public and private keys using OpenSSL libraries. The generated private key is
saved locally on the management card, and the public key is embedded in the generated X.509 certificate
request. The key uses RSA encryption; SHA-1 with RSA encryption is used on the Hashing function for the
generated certificate. Certificate requests are sent to the Certificate Authority (CA) or Registration Authority
(RA) during the certification process via CMPv2.
Initial certificate request transaction (ir and ip): A certificate request triggers the CMPv2 messaging to get
the first certificate certified by the Certification Authority (CA). This CMPv2 transaction is identified by the
Certification Request and Certification Response messages (ir and ip). At the end of this transaction the
security gateway may receive the certificate signed by the CA in the response message. This certificate is then
saved in the management card and is also propagated to the packet processing cards via internal messaging.
The IKEv2 tunnel creation done at the packet processing cards requires this certificate for the IKE_AUTH
transaction.
Certification Request and Certification Response messages (ir and ip). At the end of this transaction the
security gateway may receive the certificate signed by the CA in the response message. This certificate is then
saved in the management card and is also propagated to the packet processing cards via internal messaging.
The IKEv2 tunnel creation done at the packet processing cards requires this certificate for the IKE_AUTH
transaction.
Certificate enrolment (cr and cp): This CMPv2 transaction obtains additional certificates certified by CA after
the initial certification is done. The security gateway triggers additional certificate enrolment. The additional
certificates are saved and used in a manner similar to the initial certificate.
certificates are saved and used in a manner similar to the initial certificate.
Polling request and response (pollReq and pollRep): The ip, cp or the kup message received from the CA may
contain a status code of “waiting”. This indicates that the CA is still evaluating the certificate request and will
require more time to sign the certificate. In this case the security gateway sends a pollReq message to the CA.
The pollRep message from the CA may either contain the signed certificate or indicate a status of “waiting”
again. If the pollRep message contains the certificate, it is treated as an ip/cp/kup message with a signed
certificate and all relevant actions are taken. The security gateway also supports a CLI command to manually
trigger polling for any request.
require more time to sign the certificate. In this case the security gateway sends a pollReq message to the CA.
The pollRep message from the CA may either contain the signed certificate or indicate a status of “waiting”
again. If the pollRep message contains the certificate, it is treated as an ip/cp/kup message with a signed
certificate and all relevant actions are taken. The security gateway also supports a CLI command to manually
trigger polling for any request.
Certificate update transaction (kur and kup): This key pair update transaction re-certifies or updates a
public/private key pair of the certificate after or before its validity expires. The Key Update Request (kur)
message is sent to the CA with a certificate having a new public key, and the CA sends a Key Pair Update
Response (kup) message with the signed certificate. The security gateway also supports two mechanisms to
update an existing certificate:
message is sent to the CA with a certificate having a new public key, and the CA sends a Key Pair Update
Response (kup) message with the signed certificate. The security gateway also supports two mechanisms to
update an existing certificate:
Manual Update: The gateway sports a CLI command to trigger the certificate update transaction.
Auto update: The gateway can be configured to automatically trigger a certificate update a specified
number of days before the certificate expires.
For both manual and automatic updates, the updated certificate is saved on the management card and
propagated to the packet processing cards.