Certificate Status Protocol (OCSP) to know the
status of a specific certificate. The structure of a X.509 v3
digital certificate is shown in : - Certificate
- Version
- Serial Number
- Algorithm ID
- Issuer
- Validity:
- Subject Public Key Info
- Public Key Algorithm
- Subject Public Key
- Issuer Unique Identifier (Optional)
- Subject Unique Identifier (Optional)
- Extensions
(Optional)
- Certificate Signature
Algorithm
- Certificate Signature
PKI
Message Exchange
Certificate enrollment is the process
of obtaining a certificate from a CA. Each end host that wants
to participate in the PKI must obtain a certificate.
Certificate enrollment occurs with these steps between the end
host requesting the certificate and the CA and as shown in :
Step 1 The end host generates an RSA key pair and
requests the public key of the CA. Step 2 The CA sends
the CA public key to the end host. Step 3 The end host
generates a certificate request and forwards the request to the
CA (or the RA, if applicable). The CA receives the certificate
enrollment request, and, depending on your network
configuration, one of the following options occurs: -
Manual intervention is required to approve the request.
- The end host is configured to automatically request a
certificate from the CA. Thus, operator intervention is no
longer required at the time the enrollment request is sent to
the CA server.
Step 4 After the
request is approved, the CA signs the request with the CA’s
private key. Step 5 The CA returns the
completed certificate to the end host. The end host writes the
certificate to a storage area such as NVRAM. Step
6 The end host uses the certificate for communication
with other communication partners. PKI Credentials
Figure shows how PKI credentials, such as RSA keys and
certificates, can be stored in a location other than NVRAM, the
default location on the router. Selected Cisco platforms now
support Smartcard technology in a Universal Serial Bus (USB)
key form (also known as an Aladdin USB eToken key). An eToken
provides secure configuration distribution and allows users to
store VPN credentials to use for deployment. Before you can use
an eToken, you must ensure that you meet the following system
requirements: - A Cisco 871 router, Cisco 1800 Series,
Cisco 2800 Series, or a Cisco 3800 Series router
-
Cisco IOS Release 12.3(14)T or later image running on any of
the supported platforms
- A Cisco-supported USB
eToken
- A Cisco IOS image with k9 code
An
eToken is a Smartcard with a USB interface. The eToken can
securely store any type of file within the available 32-KB
storage space. Configuration files that are stored on the
eToken can be encrypted and accessed only via a user personal
identification number (PIN). The router will not load the
configuration file unless the proper PIN has been configured
for secure deployment of router configuration files. After you
plug the eToken into the router, you must log in to the eToken.
Once you are logged in, you can change default settings, such
as the user PIN (the default is 1234567890) and the allowed
number of failed login attempts before future logins are
refused (the default is 15 attempts). After you have
successfully logged in to the eToken, you can copy files from
the router onto the eToken via the copy command. By
default, after the eToken is removed from the router, all
associated RSA keys are removed; IPsec tunnels are not torn
down until the next IKE negotiation period is initiated.
Content 3.3 Implementing Site-to-Site
IPsec VPN Operations 3.3.1 Site-to-Site IPsec
VPN Operations The goal of IPsec is to protect data between
peers by using the necessary security and encryption
algorithms. Figure shows only one of two bidirectional IPsec
security associations (SAs) that are available. IPsec operation
can be broken down into five steps: Step 1
Interesting traffic initiates the IPsec process: Traffic
is deemed interesting when the VPN device recognizes that the
traffic you want to send needs protection. Step 2
IKE Phase 1: IKE authenticates IPsec peers and
negotiates IKE SAs during this phase, setting up a secure
communications channel for negotiating IPsec SAs in Phase 2.
Step 3 IKE Phase 2: IKE negotiates IPsec SA
parameters and sets up matching IPsec SAs in the peers. These
security parameters are used to protect data and messages that
are exchanged between endpoints. Step 4 Data
transfer: Data is transferred between IPsec peers based on
the IPsec parameters and keys that are stored in the SA
database. Step 5 IPsec tunnel
termination: IPsec SAs terminate through deletion or by
timing out. Figure shows how IPsec policy determines what
traffic to protect and what traffic to send without protection.
For every inbound and outbound datagram there are two choices:
apply IPsec or bypass IPsec and send the datagram in clear
text. For every datagram that is protected by IPsec, the system
administrator must specify the security services that are
applied to the datagram. The security policy database specifies
the IPsec protocols, modes, and algorithms that are applied to
the traffic. IPsec then applies the services to traffic that is
destined to each particular IPsec peer. With the VPN Client,
you use menu windows to select connections that you want IPsec
to secure. When interesting traffic transits the IPsec client,
the client initiates the next step in the process, negotiating
an IKE Phase 1 exchange. Interactive Media Activity
Drag and Drop: Five Steps of IPsec Upon
completion of this activity, the student will be able to
understand the operation of IPsec.
Content
3.3 Implementing Site-to-Site IPsec
VPN Operations 3.3.2 Step 2: IKE Phase 1
The purpose of IKE Phase 1 is to negotiate IKE policy sets,
authenticate the peers, and set up a secure channel between the
peers. IKE Phase 1 occurs in two modes: main mode and
aggressive mode as shown in Figure . The main mode has three
two-way exchanges between the initiator and receiver:
- First exchange: The two peers negotiate and agree on
which algorithms and hashes to use to secure the IKE
communications.
- Second exchange: A
Diffie-Hellmann exchange generates shared secret keys and pass
nonces (a nonce is a value used only once by a computer
security system). A random number sent by one party to another
party, signed, and returned to the first party proves the
second party’s identity. Once created, the shared secret key is
used to generate all the other encryption and authentication
keys.
- Third exchange: In this exchange, each
peer verifies the identity of the other side by authenticating
the remote peer.
The outcome of main mode is a
secure communication path for subsequent exchanges between the
peers. Without proper authentication, you might establish a
secure communication channel with a hacker who can then steal
your sensitive material. In aggressive mode, fewer exchanges
take place with fewer packets. Most of the actions occur during
the first exchange: IKE policy set negotiation; Diffie-Hellmann
public key generation; a nonce, which the other party signs;
and an identity packet, which can be used to verify the
identity of the other party via a third party. The receiver
sends everything back that is needed to complete the exchange.
The only action left after the first exchange is for the
initiator to confirm the exchange. Matching IKE
Policies
When a secure connection is being made between
Host A and Host B through the Internet, IKE security proposals
are exchanged between Router A and Router B. The proposals
identify the IPsec protocol that is being negotiated (for