8.1.1.1. IPSec Overview

IPSec is a structure of open standards to ensure private, secure communications over Internet Protocol (IP) networks by using cryptographic security services.

For IPSec, the 7705 SAR supports VPRN for the private side of the tunnel and IES for the public side of the tunnel. A public service instance (IES) connects to the public network and a private service instance (VPRN) connects to the private network, which originates the traffic that is to be encrypted (see Figure 121).

In Figure 121, all ingress customer traffic from the trusted network is aggregated into the private VPRN service, where a VPRN static route directs the traffic into the encryption engine. The encryption engine encrypts the customer traffic using configurable encryption and authentication protocols, and adds the IPSec tunnel outer IP header. The source IP address of the outer IP header is the local security gateway address, and the destination IP address is the peer security gateway address.

The encrypted IPSec packet exits the node via an IES or router interface that is configured on an encryption-capable adapter card; it gets routed to its destination via a standard FIB lookup.

On ingress from an untrusted network, all arriving IPSec traffic is routed to the appropriate security gateway as configured on the VPRN service. The incoming IPSec traffic is processed and checked against the tunnel security configuration.

If the traffic passes all security checks, it is decrypted and the customer traffic is routed through the associated VPRN. Any traffic that does not match the tunnel security configuration is dropped.

Figure 121:  IPSec Implementation Architecture 

8.1.1.2. Hardware Support

The 7705 SAR supports IPSec on the following nodes and adapter cards:

Note: On the 7705 SAR-X, each Ethernet port has its own encryption engine.

8.1.1.3. IPSec Encryption Features

IPSec provides a variety of encryption features required to establish bidirectional IPSec tunnels, including:

Control plane:

Data plane:

Note: The 7705 SAR uses a configured authentication algorithm in an IKE policy for the pseudorandom function (PRF).

8.1.1.4. SHA2 Support

The 7705 SAR supports RFC 4868. For data origin authentication and integrity verification functions in the IKEv1 or IKEv2 and Encapsulating Security Payload (ESP) protocols, the 7705 SAR supports the following HMAC-SHA-256+ algorithms:

For pseudorandom functions (PRF) with IKEv1 or IKEv2, the 7705 SAR supports the following HMAC-SHA-256+ algorithms:

8.1.1.5. IPSec Security Policy, IKE Policy, and IPSec Transform

An IPSec security policy defines the type of traffic allowed to pass in or out of an IPSec tunnel. The policy does this through the configuration of local and remote IP address pairs. The behavior of an IPSec security policy is similar to IP filtering. IPSec security policies are created for a VPRN service context and applied to an IPSec tunnel in that service.

An IKE policy defines how the 7705 SAR encrypts and authenticates an IPSec tunnel that uses that policy. Its configuration includes specifics on Diffie-Hellman key derivation algorithms, encryption and authentication protocols to be used for establishing phase 1 and phase 2 security associations, and so on.

An IPSec transform defines the algorithms used for IPSec SA. The transform configuration dictates the algorithms that customer traffic uses for encryption and authentication.

8.1.1.6. Tunnel Group

A tunnel group is a collection of IPSec tunnels. The 7705 SAR supports one tunnel group that always uses tunnel ID 1.

An IPSec tunnel belongs to only one tunnel group. The show>isa>tunnel-group command allows the operator to view information about the configured tunnel group.

8.1.1.7. Tunnel Interfaces and SAPs

There are two types of tunnel interfaces and associated SAPs:

8.1.1.8. IPSec Tunnel Configuration

To bind an IPSec tunnel to a private tunnel SAP, the ipsec-tunnel command is configured under the SAP context, where the ipsec-tunnel context provides access to the following parameters:

The local gateway address must belong to the same subnet as the delivery-service (IES) public tunnel interface address. The local gateway address and peer gateway address are the source and destination addresses for the outgoing IPSec traffic.

A private tunnel SAP can have only one IPSec tunnel.

8.1.1.9. IPSec over MPLS

IPSec messages can be routed over MPLS tunneled routes. The 7705 SAR supports resolution of IPSec routes to the secure gateway address by using either BGP 3107 label routes or IGP shortcuts. When BGP learns IPv4 addresses as 3107 label routes, BGP resolves the next hops for these routes with an LDP or RSVP-TE tunnel. These BGP routes create BGP tunnels that can be used to resolve an IPSec secure gateway address. When an IGP shortcut is enabled on the 7705 SAR by using the config>router>ospf>rsvp-shortcut command, OSPF installs an OSPF route in the RIB, with an RSVP-TE LSP as the next hop. If this OSPF route is determined as the overall best route, then the next hop is an RSVP-TE tunnel. For information about setting up BGP 3107 label routes or IGP shortcuts to resolve IPSec routes, see Configuring IPSec over MPLS.

8.1.1.10. GRE-Encapsulated VLLs/VPLS over IPSec VPNs

The 7705 SAR can provide secure transport of Cpipe, Epipe, and VPLS traffic by routing it as GRE-encapsulated traffic over IPSec VPNs. This is achieved by enabling route processing in the GRT FIB through a GRT lookup at ingress to the VRF and GRT leaking at egress from the VRF. The 7705 SAR leaks only IPSec tunnels into the GRT as the available next hop; no other tunnel type is leaked from the VRF into the GRT as a next hop. This route processing is enabled with the config>service>vprn>grt-lookup>enable-grt command.

When a packet arrives at the VRF and the grt-lookup>enable-grt command is configured, the following sequence occurs.

In order for a packet to leave the VRF, the route that needs to be resolved — the destination prefix — must be leaked to the GRT. The destination prefix is configured in a route policy using the config>router>policy-options>prefix-list command; that policy is then leaked into the GRT by referencing it in the config>service>vprn>grt-lookup>export-grt command. Packets with the matching route found in the GRT FIB are routed via the IPSec tunnel configured within the VPN.

The 7705 SAR supports the following packet types for GRT lookup in the VRF FIB:

The 7705 SAR supports the following packets types arriving in the VRF via the IPSec tunnel:

The 7705 SAR terminates GRE packets at a system IP address or any local interface IP address. When GRE-encapsulated packets are transported over an IPSec VPN, the IPSec tunnel can terminate on a 7705 SAR or 7750 SR and the GRE packets are processed on the secure gateway.

When configuring grt-lookup, the static-route command must be configured for the local IP address that will be looked up in the GRT. The next hop is set to the desired local IP address and is used on ingress to force a second route lookup in the GRT. If that lookup is successful, and the packet is a GRE packet destined to a local interface, it is forwarded for PW processing. If the packet is destined to a system IP address and is not GRE packet, it is forwarded for management processing. A second static route is required in the IPSec VPN in order to point the far-end IP address to the IPSec tunnel. It is used on egress and is configured for the far-end IP address with a next hop set to the IPSec tunnel.

By enabling GRT lookup, signaling packets such as T-LDP can be routed securely between two system IP addresses by using the IPSec tunnel. However, IGP protocols such as OSPF or IS-IS, which use a multicast destination, cannot use the IPSec tunnel.

Figure 122 shows an example of route leaking configured to resolve the far-end system IP address 100.0.0.2 using an IPSec VPN. Although the example shows GRE to a system IP address on the 7705 SAR for illustrative purposes, GRE to any other local IP address on the 7705 SAR can be substituted.

Figure 122:  Routing GRE-Encapsulated Packets over IPSec 

Based on Figure 122, the CLI example below shows the configuration of a routing policy that will be used to leak the far-end system IP address into the GRT. The command config>router>policy-options>prefix-list>prefix creates a prefix entry with the system IP address of the far-end node (100.0.0.2/32) in the route policy prefix list. The policy option is configured using the prefix specified above (100.0.0.32) with the action accept. The policy preference should be set so that it is lower than the IGP advertised preference.

The far-end system IP address 100.0.0.2 is resolved using a static route configured with an IPSec tunnel next hop of “tunnel2”. The GRT lookup at the ingress VRF is enabled using the config>service>vprn>grt-lookup>enable-grt command and a second static route is configured to enable lookup at ingress for the local system IP address 100.0.0.14/32, as shown in the CLI example below:

The far-end system IP address with a next hop IPSec tunnel (“tunnel2”) is leaked into the GRT using the command config>service>vprn>grt-lookup>export-grt, referencing the routing policy configured above (“grt”).

A GRE-encapsulated SDP to the far-end system IP address is configured using the commands config>service>sdp sdp-id gre create and config>service>sdp>far-end. A Cpipe, Epipe, or VPLS is then configured using that SDP. For information about configuring a Cpipe or Epipe, see Configuring a VLL Service with CLI and Configuring VLL Components in this guide. For information about configuring a VPLS, see Configuring a VPLS Service with CLI in this guide.

For information about GRT lookup for management traffic, see “In-Band Management using a VPRN” in the VPRN Services chapter of this guide.

8.1.1.11. GRE-Encapsulated VLLs/VPLS over IPSec over MPLS

The 7705 SAR can route Cpipe, Epipe, or VPLS traffic over IPSec using either BGP 3107 Label routes or RSVP-TE IGP shortcuts.

When GRE-encapsulated Cpipe, Epipe, or VPLS traffic is routed over IPSec, the GRE packets and T-LDP packets can be routed to the far-end system IP address using the IPSec tunnel. However, there must be special consideration for the MPLS tunnel, in particular for BGP 3107 label routes using IBGP, since MPLS signaling packets cannot use an IPSec tunnel.

8.1.1.11.1. VLLs/VPLS over IPSec over MPLS (Using BGP 3107 Label Routes) Solution 1: Changing BGP Signaling to Loopback Interface

When resolving an IPSec route to the secure gateway address with a BGP 3107 label route, BGP can be set up to use either IBGP or EBGP.

The IBGP 3107 label route is usually set up to the system IP address. However, the Layer 2 services to be protected by IPSec are also set up to the system IP address. In this case routing the IBGP 3107 label routes via the IPSec tunnel creates some complexities.

To avoid routing both Layer 2 services and the IBGP (used for 3107) over the IPSec tunnel, IBGP should be setup to a loopback interface rather than to the system IP address. Also, all MPLS LSPs that will resolve these 3107 labels should be setup to the same loopback interface. For RSVP-TE this means the far end has to be the loopback interface and for LDP this means an originate-fec needs to be configured to the loopback interface.

Figure 123 shows an example of a BGP 3107 label route configured with a loopback interface.

Figure 123:  VLL/VPLS over IPSec over MPLS Using BGP 3107 Label Routes 

Based on Figure 123, the CLI example below shows BGP configured to a neighbor loopback address and the BGP local address configured as a local loopback address. BGP for 3107 label route advertisement is enabled using the advertise-label ipv4 keyword.

#--------------------------------------------------

*A:7705:Dut-A>config>router>bgp# info 

#--------------------------------------------------

            local-as 10

            group “2”

               peer-as 10

               local-address 100.10.0.14

               neighbor 100.10.0.2

                    family vpn-ipv4

                    export “gw”

                    advertise-label ipv4

               exit

            exit

            no shutdown

In addition, IGP must be configured to make the loopback IP addresses reachable for BGP.

The BGP 3107 label route can be resolved with either an LDP or an RSVP-TE tunnel. To use an LDP tunnel, an LDP FEC must be configured to advertise the local loopback IP address to the neighbor, as shown in the CLI example below:

#--------------------------------------------------

*A:7705:Dut-A>config>router>ldp# info 

#--------------------------------------------------

            fec-originate 100.10.0.14/32 advertised-label 32 pop

To use an RSVP-TE tunnel, an LSP is created to the neighbor loopback IP address, as shown in the CLI example below:

#--------------------------------------------------

*A:7705:Dut-A>config>router>mpls# info 

#--------------------------------------------------

            lsp “to-14-loop”

               to 100.10.0.2 

               cspf

               no shutdown

            exit

With EBGP, BGP communicates between the local and neighbor IP interface so IGP is not required to resolve the BGP 3107 label routes. In the example shown in Figure 123, the configuration would use Layer 3 interfaces rather than loopback addresses, as shown in the CLI example:

#--------------------------------------------------

*A:7705:Dut-A>config>router>bgp# info 

#--------------------------------------------------

            local-as 10

            group “2”

               peer-as 10

               neighbor 2.14.1.2

                    family vpn-ipv4

                    export “gw”

                    advertise-label ipv4

               exit

            exit

            no shutdown

To use an LDP tunnel, an LDP FEC is configured to advertise the local interface IP address:

#--------------------------------------------------

*A:7705:Dut-A>config>router>ldp# info 

#--------------------------------------------------

            fec-originate 2.14.2.2/32 advertised-label 32 pop

To use an RSVP-TE tunnel, an LSP is created to the neighbor interface IP address:

#--------------------------------------------------

*A:7705:Dut-A>config>router>mpls# info 

#--------------------------------------------------

            lsp “to-14-loop”

               to 2.14.1.2 

               cspf

               no shutdown

            exit

8.1.1.11.2. VLLs/VPLS over IPSec over MPLS (Using BGP 3107 label Routes) Solution 2: GRE to Local Interface on 7705 SAR

When transporting a GRE-encapsulated VLL or VPLS over IPSec over MPLS, the 7705 SAR can terminate the GRE tunnel to a loopback address. In this scenario, the VLL or VPLS is created between the loopback interfaces and the BGP 3107 label route uses the system IP address to resolve the IPSec gateway. This relies on GRT lookup and leaking, but the far-end loopback IP address is used instead of the system IP address in the routing policy. Figure 124 shows an example of VLL/VPLS over IPSec over MPLS using a loopback address, followed by CLI configuration examples.

Figure 124:  VLL/VPLS over IPSec over MPLS using a Loopback Address 

Based on Figure 124, a local loopback interface is configured on the 7705 SAR:

#--------------------------------------------------

*A:7705:Dut-A>config>router# info 

#--------------------------------------------------

            interface "loop1"

                address 100.10.0.14

                loopback

                no shutdown

            exit

T-LDP signaling is configured to the far-end loopback IP address:

#--------------------------------------------------

*A:7705:Dut-A>config>router>ldp# info 

#--------------------------------------------------

            targeted-session 

                peer 100.10.0.2

                  local-lsr-id “loop1”

                  no shutdown

                exit

            exit

A routing policy is configured on 7705 SAR using the loopback address of the secure gateway:

#--------------------------------------------------

*A:7705:Dut-A>config>router>policy-options# info 

#--------------------------------------------------

            prefix-list "loop"

                prefix 100.10.0.2/32 exact

            exit

            policy-statement "loop"

                entry 1

                    from

                        prefix-list "loop"

                    exit

                    action accept

                        local-preference 3

                        preference 3

                        metric-set 1

                    exit

                exit

            exit

The routing policy is then used to enable GRT lookup and leaking in the VPRN:

#--------------------------------------------------

*A:7705:Dut-A>config>sevice>vprn# info 

#--------------------------------------------------

            static route 100.10.0.2/32 ipsec-tunnel "tunnel2"

            grt-lookup 

               enable-grt

                   static-route 100.10.0.14/32 grt

               export-grt loop

                    exit

                exit

            exit

The GRE SDP is then created to the far-end loopback IP address:

#--------------------------------------------------

*A:7705:Dut-A>config>sevice# info 

#--------------------------------------------------

            sdp 200 gre create

               far-end 100.10.0.2

               keep-alive

                  shutdown

               exit

               no shutdown

            exit

8.1.2.1. X.509v3 Certificate Support on the 7705 SAR

The 7705 SAR PKI implementation supports the following features:

8.1.2.2. Local Storage

The 7705 SAR requires the following objects to be stored locally as a file:

All these objects must be imported with the admin certificate import command before they can be used by the 7705 SAR. The import process converts the format of the input file to distinguished encoding rules (DER), encrypts the key file, and saves it in the cf3:/system-pki directory.

The imported file can also be exported using a specified format by means of the admin certificate export command.

The admin certificate import and admin certificate export commands support the following formats:

8.1.2.3. CA Profile

On the 7705 SAR, the CA-related configuration is stored in a CA profile that contains the following configurable items:

When a user enables a ca-profile (no shutdown), the system loads the specified CA certificate and CRL into memory. The following checks are performed:

The CRL is required in order to enable ca-profile.

8.1.2.4. CA Chain Computation

When verifying a certificate with a CA or a chain of CAs, the system must identify the issuer CA of the certificate. The 7705 SAR looks through all configured CA profiles to find the issuer CA. The following is the method that the system uses to find the issuer CA:

8.1.2.5. Certificate Enrollment

The 7705 SAR supports two certificate enrollment methods:

To use the offline method, perform the following steps:

For the online method using CMPv2-based enrollment, see the Certificate Management Protocol Version 2 (CMPv2).

8.1.2.6. Certificate Revocation Check

A revocation check is a process that checks whether a certificate has been revoked by the issuer CA.

The 7705 SAR supports two methods for the certificate revocation check:

The CRL can be used for both EE and CA certificate checks, while OCSP can only be used for an EE certificate check.

For an IPSec application, users can configure multiple check methods with a priority order for an EE certificate. Using the status-verify command in the ipsec-tunnel configuration context, users can configure a primary method, a secondary method, and a default result. The primary and secondary methods can be either OCSP or CRL. The default result is either good or revoked. If the system does not get an answer from the primary method, it falls back to the secondary method. If the secondary method does not return an answer, the system uses the default result.

By default, the system uses the CRL to check the revocation status of a certificate, whether it is an end entity certificate or a CA certificate. This makes the CRL a mandatory configuration in the ca-profile.

For details about OCSP, see OCSP.

8.1.2.7. Certificate, CRL, and Key Cache

Configured certificates, CRLs, and keys are cached in memory before they are used by the system.

Every certificate, CRL, and key has one system-wide cache copy.

For a CA certificate and a CRL, the cache is created when there is a CA profile and when a no shutdown is performed and removed.

For an IPSec tunnel using legacy cert and key configurations, the cache is created only when the first tunnel using the cache is in a no shutdown state, and it is cleared when the last tunnel that used it is shut down.

For an IPSec tunnel using a cert-profile, the cache is created when the first cert-profile using the cache is in a no shutdown state, and it is removed when the last cert-profile that used it is shut down.

If a certificate or key is configured with both a cert-profile and legacy cert or key command, the cache is created when the first object (an ipsec-tunnel or a cert-profile) using it is in a no shutdown state, and it is removed when the last object using it is shut down.

In order to update a certificate or key without a shutdown ca-profile or ipsec-tunnel, the CLI command admin>certificate>reload manually reloads the certificate and key cache.

8.1.8.1. Metrocell Deployment

As shown in Figure 125, in a typical metrocell deployment, the cell site network is divided into two separate segments: the private domain and the public domain. An IPSec tunnel generated from the 7705 SAR-H is used to backhaul the management and OAM traffic of the private network, including the management traffic of the switches and the 7705 SAR-H itself. All OAM traffic is aggregated within a VPRN service and uses the IPSec tunnel as the uplink tunnel to the 7750 SR gateway.

Figure 125:  Typical Metrocell Deployment 

8.1.8.2. Small Business Deployment

In a small business deployment, the network is usually designed with a hub and spoke topology. The spoke sites connect to the hub through a leased line or a public non-secure domain. IPSec provides the security and encryption needed to connect the spoke sites to the centralized office (hub). The hub and spoke topology in a small business deployment is favorable because of the security that the hub side can provide to the entire network. IPS/IDS and anti-virus appliances can be deployed to the hub site, which examines arriving traffic from the spoke sites. SPAM and viruses can be filtered out on the hub site by these appliances. If additional spoke-to-spoke connectivity is required, then additional IPSec tunnels can be established. See Figure 126.

Figure 126:  Typical Small Business Deployment 

8.1.11.1. Network and Access Ingress QoS (Decryption QoS)

IPSec traffic arriving on network ingress is classified based on network policy and network queue policy when the uplink interface is a network interface (refer to the 7705 SAR Quality of Service Guide). This classification is done based on the DSCP marking of the IPSec outer IP header.

The IPSec (encrypted) traffic destined for the secure gateway (SeGW) of the 7705 SAR is mapped to two queues (expedited and best effort) of the decryption engine on the ingress adapter card. This means that encrypted traffic is mapped to the decryption queue.

The encrypted traffic is mapped to one of these two queues based on the queue-type of its mapped network ingress queue, as determined by the result of the network ingress classification. For example, at network ingress, the QoS network policy determines a forwarding class (FC) for the packet. Then, the network-ingress queue policy maps the FC to a queue. The configured queue-type of network-ingress queue (expedited, best-effort, or auto-expedite) is used to choose the queue for the decryption engine on the ingress adapter card (where the uplink interface resides).

The uplink interface for the SeGW can be configured as a network interface or as an access IES interface. For an access IES interface, the decryption-queue mapping is based on the queue-type of the access ingress queue of the IES interface SAP. For example, at IES ingress, the SAP ingress policy determines a forwarding class (FC) for the packet. The FC is mapped to a SAP ingress queue. The queue-type of this SAP ingress queue (expedited, best-effort, or auto-expedite) is used to choose the queue for the decryption engine on the ingress adapter card where the IES interface SAP resides.

The decrypted customer traffic with removed IPSec tunnel header is queued on network and access ingress queues (the uplink interface can be a network interface or an IES interface) based on the network and access ingress policy, and the DSCP bits of the IPSec outer IP header are used for the classification.

8.1.11.2. Network and Access Egress QoS (Encryption QoS)

Customer packets arriving on access ingress in the VPRN are classified based on the SAP ingress policy (refer to the 7705 SAR Quality of Service Guide).

Customer packets arriving in the VPRN that are destined for the IPSec tunnel are enqueued before the encryption engine on the egress adapter card. There are three queues servicing the encryption engine on the egress adapter card (expedited, best effort, and CTL).

All CSM traffic over IPSec (BFD, ping, and so on) is queued in the CTL queue, while data (customer) traffic is mapped to the expedited or best-effort queue.

The customer traffic to the two data queues is mapped based on the queue-type of the ingress SAP queue. For example, at access VPRN SAP ingress, the ingress SAP policy determines a forwarding class (FC) for the packet. The FC is mapped to a SAP ingress queue. The queue-type of the SAP ingress queue (expedited, best-effort, or auto-expedite) is used to choose the queue for the decryption engine on the egress adapter card (where the uplink interface resides).

Note: If DSCP egress re-marking is configured on the network interface or access interface (uplink interface), DSCP bits are re-marked on the IPSec outer IP header.

8.1.12.1. Fragmentation Configuration

By default, the 7705 SAR sets the DF bit on the IPSec tunnel IP header.

There are some configurations where the customer IP header DF bit needs to be copied into the IPSec tunnel IP header. The copy-df-bit command under the config>service>vprn>if>sap>ipsec-tunnel context enables copying the customer clear text IP header DF bit into IPSec tunnel IP header.

The clear-df-bit command, also under the ipsec-tunnel context, clears the customer clear text IP header DF bit (if it is set). This allows the customer packet to be fragmented into the IPSec tunnel even if the customer packet has the DF bit set. However, the fragmented customer clear text packet is not be reassembled at the far end of IPSec tunnel.

8.1.12.2. Reassembly

The 7705 SAR does not support reassembly of fragmented IPSec packets.

8.1.17.1. PBR

PBR configuration can be applied in two places for an IPSec service.

The first place is for VPRN and applies to all incoming access traffic into a private VPRN. In this case, PBR can be used to direct the customer traffic into uplink IPSec tunnels by means of ACL matching criteria. The filtering action of forwarding to an indirect next hop can be used to direct customer traffic into the appropriate IPSec tunnel. The security policy works only on the original (customer packet) IP header; that is, the PBR next hop is not used in making the security policy decision.

The second place is for IPSec traffic entering the 7705 SAR from the public domain. A PBR filter can be placed on the network interface or the IES interface to direct the IPSec packet based on the matching/forwarding criteria. In this case, IPSec packets are processed by the PBR filter in the same way as any other IP packet.

For more information on PBR, refer to the “Policy-Based Routing” section in the 7705 SAR Router Configuration Guide.

Note: All routing decisions are made based on the PBR configuration; therefore, it is possible that even if the packet is destined for the local node security gateway (SeGW), the PBR filter might redirect the packet to another interface. Alternatively, for IPSec packets that are not destined for the local node SeGW, PBR can force the packets into the local node SeGW. In this case, the encapsulating security payload (ESP) index of the IPSec packet will not match the SeGW ESP configuration and the packet will be dropped. Thus, it is the responsibility of the network administrator to ensure that the PBR configuration is correct and meets the network needs.

8.1.17.2. MFC

Multi-field classification (MFC) is supported on the private IPSec service (VPRN). MFC functions in the same manner as the VPRN configuration of traditional services.

For more information on MFC, refer to the “Multi-field Classification” section in the 7705 SAR Router Configuration Guide.

8.2.2.1. Certificates

PKI uses two types of certificates:

8.2.4.1. CMPv2 Initial Registration

Initial registration is a process that the end entity uses to enroll a certificate with a certain CA for the first time. The result of this process is that a CA issues a certificate for an end entity’s public key, returning that certificate to the end entity or posting that certificate in a public repository (or both).

The 7705 SAR must be pre-provisioned with the operator CA certificate.

The 7705 SAR public/private key pair is always pre-provisioned before enrollment by means of local generation or another method.

The 7705 SAR uses the CMPv2 initial registration process to enroll its pre-provisioned key with an operator’s CA. The result of this process is a certificate issued by the operator’s CA.

There are two authentication methods (PKI message protection) in this process, which are chosen using the CLI:

8.2.4.2. Key Update

When a key pair is due to expire, the relevant end entity (EE) may request a key update. That is, the EE may request that the CA issue a new certificate for a new key pair or, under certain circumstances, a new certificate for the same key pair. The request is made using a key update request (kur) message, also known as a certificate update operation.

This command requests a new certificate from the CA in order to update an existing certificate due to reasons such as the need to refresh a key or to replace a compromised key.

If the EE already has a signing key pair with a corresponding verification certificate, then communication between the EE and the CA will be protected by the EE’s digital signature.

If the request is successful, the CA returns the new certificate in a key update response (kup) message, which is syntactically identical to a CertRepMessage.

8.2.4.3. CRL

In the operation of some cryptosystems, such as PKIs, a certificate revocation list (CRL) is used. A CRL is list of certificates (or more specifically, a list of serial numbers for certificates) that have been revoked. Entities presenting those revoked certificates should not be trusted.

The CRL must be obtained and imported via CMPv2.