Cisco Cisco Packet Data Interworking Function (PDIF)
IPSec Network Applications
▀ IPSec for Femto-UMTS Networks
▄ IPSec Reference, StarOS Release 17
56
Table 10. X.509 Certificate-based Peer Authentication
Step
Description
1
The peer node initiates an IKEv2 exchange with the local node, known as the IKE_SA_INIT exchange, by issuing an
IKE_SA_INIT Request to negotiate cryptographic algorithms, exchange nonces, and perform a Diffie-Hellman
exchange with the local node.
IKE_SA_INIT Request to negotiate cryptographic algorithms, exchange nonces, and perform a Diffie-Hellman
exchange with the local node.
2
The local node responds with an IKE_SA_INIT Response by choosing a cryptographic suite from the initiator’s
offered choices, completing the Diffie-Hellman and nonce exchanges with the peer node. In addition, the local node
includes the list of CA certificates that it will accept in its CERTREQ payload. For successful peer authentication, the
CERTREQ payload must contain at least one CA certificate that is in the trust chain of the peer certificate. At this
point in the negotiation, the IKE_SA_INIT exchange is complete and all but the headers of all the messages that follow
are encrypted and integrity-protected.
offered choices, completing the Diffie-Hellman and nonce exchanges with the peer node. In addition, the local node
includes the list of CA certificates that it will accept in its CERTREQ payload. For successful peer authentication, the
CERTREQ payload must contain at least one CA certificate that is in the trust chain of the peer certificate. At this
point in the negotiation, the IKE_SA_INIT exchange is complete and all but the headers of all the messages that follow
are encrypted and integrity-protected.
3
The peer node initiates an IKE_AUTH exchange with the local node by including the IDi payload, setting the CERT
payload to the peer certificate, and including the AUTH payload containing the signature of the previous
IKE_SA_INIT Request message (in step 1) generated using the private key of the peer certificate. The authentication
algorithm used to generate the AUTH payload is also included in the AUTH payload. The peer node also includes the
CERTREQ payload containing the list of SHA-1 hash algorithms for local node authentication. For successful server
authentication, the CERTREQ payload must contain at least one CA certificate that is in the trust chain of the peer
certificate.
payload to the peer certificate, and including the AUTH payload containing the signature of the previous
IKE_SA_INIT Request message (in step 1) generated using the private key of the peer certificate. The authentication
algorithm used to generate the AUTH payload is also included in the AUTH payload. The peer node also includes the
CERTREQ payload containing the list of SHA-1 hash algorithms for local node authentication. For successful server
authentication, the CERTREQ payload must contain at least one CA certificate that is in the trust chain of the peer
certificate.
4
Using the CA certificate corresponding to the peer certificate, the local node first verifies that the peer certificate in the
CERT payload has not been modified and the identity included in the IDi corresponds to the identity in the peer
certificate. If the verification is successful, using the public key of the peer certificate, the local node generates the
expected AUTH payload and compares it with the received AUTH payload. If they match, the authentication of the
peer node is successful. Otherwise, the local node sends an IKEv2 Notification message indicating authentication
failure.
CERT payload has not been modified and the identity included in the IDi corresponds to the identity in the peer
certificate. If the verification is successful, using the public key of the peer certificate, the local node generates the
expected AUTH payload and compares it with the received AUTH payload. If they match, the authentication of the
peer node is successful. Otherwise, the local node sends an IKEv2 Notification message indicating authentication
failure.
5
The local node responds with the IKE_AUTH Response, including the IDr payload, setting the CERT payload to the
local node certificate, and including the AUTH payload containing the signature of the IKE_SA_INIT Response
message (in step 2) generated using the private key of the local node certificate. The authentication algorithm used to
generate the AUTH payload is also included in the AUTH payload.
local node certificate, and including the AUTH payload containing the signature of the IKE_SA_INIT Response
message (in step 2) generated using the private key of the local node certificate. The authentication algorithm used to
generate the AUTH payload is also included in the AUTH payload.
6
Using the CA certificate corresponding to the local node certificate, the peer node first verifies that the local node
certificate in the CERT payload has not been modified. If the verification is successful, using the public key of the
local node certificate, the peer generates the expected AUTH payload and compares it with the received AUTH
payload. If they match, the local node authentication is successful. This completes the IKE_AUTH exchange.
certificate in the CERT payload has not been modified. If the verification is successful, using the public key of the
local node certificate, the peer generates the expected AUTH payload and compares it with the received AUTH
payload. If they match, the local node authentication is successful. This completes the IKE_AUTH exchange.
7
An IPSec SA gets established between the peer node and the local node. If more IPSec SAs are needed, either the peer
or local node can initiate the creation of additional Child SAs using a CREATE_CHILD_SA exchange.
or local node can initiate the creation of additional Child SAs using a CREATE_CHILD_SA exchange.
Certificate Revocation Lists
Certificate revocation lists track certificates that have been revoked by the CA (Certificate Authority) and are no longer
valid. Per RFC 3280, during certificate validation, IPSec for LTE/SAE checks the certificate revocation list to verify
that the certificate the local node receives from the remote node has not expired and hence is still valid.
valid. Per RFC 3280, during certificate validation, IPSec for LTE/SAE checks the certificate revocation list to verify
that the certificate the local node receives from the remote node has not expired and hence is still valid.
During configuration via the system CLI, one certificate revocation list is bound to each crypto template and can be
fetched from its repository via HTTP or FTP.
fetched from its repository via HTTP or FTP.
For additional information refer to the CRL Fetching section of the IPSec Certificates chapter of this guide.