SNAA Securing Networks with Cisco ASA Advanced Volume 2 Version 1.0 Student Guide Text Part Number: 97-2730-02cisco. [DISCLAIMER WARRANTY. THIS CONTENT IS BEING PROVIDED “AS IS CISCO MAKES AND YOU RECEIVE NO WARRANTIES IN |CONNECTION WITH THE CONTENT PROVIDED HEREUNDER, EXPRESS, IMPLIFD, STATUTORY OR IN ANY OTHER PROVISION OF IrHtiS CONTENT OR COMMUNICATION BETWEEN CISCO AND YOU. CISCO SPECIFICALLY DISCLAIMS ALL IMPLIED WARRANTIES, INCLUDING WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT AND FITNESS FOR A PARTICULAR [PURPOSE, OR ARISING FROM A COURSE OF DEALING, USAGE OR TRADE PRACTICE, This learning product may contain early release [content and while Cisco believes i to be accurate, it fll subject wo the disclaimer above. Printed in CanadaTable of Contents Volume 2 !Psec VPNs 4-1 Overview at Module Objectives at Understanding IPsec and Digital Certificates 4-3 Overview 43 ‘Objectives 43 What Is IPsec? 44 IPsec Operation 48 Digital Certificates and Public-Key Cryptography 418 Certificates and Scalability 421 Cettificate Enrollment Process 4-25 Validating the Certificate 431 Certificate Revocation Lists 4:36 Security Appliance Certificate Enrollment Support 4-40 Root Certificate Enrollment 442 Identity Certificate Enroliment 4.42 Key Pairs and Trustpoints 444 Key Pairs 4-44 Trustpoints 4-45 Summary 4-46 Implementing Site-to-Site VPNs with Digital Certificates 4-47 Overview +47 Objectives 447 Site-to-Site VPNs 4-48 Configuring CA Certificates 453 Installing an Identity Certificate 4-60 Site-to-Site [IPsec Connection Profiles 4-70 Modifying Certificate to Connection Mapping 481 Hub and Spoke 4.86 Site-to-Site Redundancy 4-90 Verifying Site-to-Site VPNs 4.91 Troubleshooting Site-to-Site VPNs 4-102 Summary 4-106 Configuring the Cisco VPN Client 4-107 Overview 4.407 Objectives 4-107 Cisco VEN Client 4-100 Cisco VPN Client Installation 441 Digital Certificates with Cisco VPN Client 4417 Conneetion Entry 4-423 Advanced Options 4-130 Verify and Troubleshoot Client Configuration 4137 Summary 4147Implementing Remote-Access VPNs with Di 4-149 Overview 4-149 Objectives 4449 Remote-Access VPNs 4-150 Configuring a Cisco ASA for Remote Access 4.451 Installing Cisco ASA Certificates 4152 Installing a CA Certificate 4153 Enrolling with a CA 4-159 Installing an Identity Certificate 4-166 Defining a Remote-Access Address Pool 4-168 User Policy Attribute Inheritance 4-170 Configuring an IPsec Connection Profile 4174 Configuring the Certificate to Connection Profile Policy 4477 Verifying Remote-Access VPNs 4-181 Using Cisco ASDM 4-181 Troubleshooting Remote-Access VPNs 4-186 ‘Summary 4-191 Configuring Advanced Remote-Access Features and Policy 4-193 Overview 4-193 Objectives 4-193 Load Balancing 4194 Reverse Route Injection 4-202 Backup Servers 4-205 Intra-Interface VPN Traffic 4-207 NAT Transparency 4-209 Client Update 4214 Split Tunneling 4.218 Personal Firewalls 4-220 ‘Summary 4223 Configuring Cisco ASA 5505 as a Cisco Easy VPN Hardware Client 4-225 Overview 4.225 Objectives 4225 Introduction to Cisco Easy VPN 4226 Cisco Easy VPN Server Policy 4-229 Cisco Easy VPN Hardware Client 4-232 ‘Summary 4.251 Configuring QoS for IPsec VPNs 4-253 Overview 4-253 Objectives 4-253 QoS Overview 4.254 Cisco ASA QoS 4-256 Configuring QoS for VPNs 4.259 Verifying QoS 4273 Summary 4-274 Module Summary 4.275 ‘Securing Networks with ASA Advanced (SNAA) v1.0 (© 2008 Cisco Systems, Inc.Module 4| IPsec VPNs Overview Internal corporate networks have increasingly become geographically div connections, remote-office connections, e, with partner nd remote and mobile workers needing access to company network assets. The Cisco ASA adaptive security appliance can provide IP security (IPsec) connections to enable these connections into the company network. This module discusses the Cisco ASA configuration of IPsec virtual private networks (VPNS). Module Objectives Upon completing this module, you will be able to explain the IPsec VPN features and capabilities of the security appliance. This ability includes being able to meet these objective = Explain the components and the function: are and how they are used ity of IPsec and explain what digital certificates = Identify the steps needed to configure the Cisco security appliance to establish LAN-to- LAN tunnels with the digital certificate m= Identify the necessary steps to configure the IPsec VPN client, using digital certifica m Identify the necessary steps to configure the security appliance for remote access, using digital certificates = Explain the advanced remote-access features of the Cisco ASA m= Determine the necessary configuration for the Cisco ASA 5505 to be a VPN hardware client Identify the steps to configure quality of service (QoS) for VPN traffic42 Securing Networks with Cisco ASA Advanced (SNA) v1.0 © 2008 Cisco Systems, IncLesson 1 Understanding IPsec and Digital Certificates Overview In the current business environment, itis critical that corporate networks that are connected to the Internet offer flexible and secure virtual private network (VPN) access with IP Security (IPsec). Connecting remote sites over the Intemet provides a great cost-saving opportunity when compared to the traditional WAN access such as Frame Relay or ATM. With IPsec technology, customers now can build VPN tunnels through the public Internet with the security of eneryption protection against wire taping or intruding on the private communication. In this lesson, you will be introduced to RFC 2401, Security Architecture for the Internet Protocol ing IPsec), some of the underlying protocols used by IPsec, and public key infrastructure Objectives Upon completing this lesson, you will be able to explain the functionality and the components of IPsec and explain what digital certificates are and how they are used. This ability includes being able to meet these objectives: = Describe IPsec and the components that define IPsec Describe how IPsec works = Describe how digital certificates and public-key cryptography work = Describe the scalability that is achieved by using certificates = Describe the purpose of CRLs and the protocols used for CRLs ribe key pairs and trustpointsWhat Is IPsec? This topic describes IPsec and the components that define IPsec. IP Security * RFC 2401 = Combines three protocols into a cohesive security framework eae IPsec combines three protocols into a cohesive security framework. IPsec is designed to provide interoperable, high-quality, and cryptographically based security. IPsec is defined in REC 2401. The set of security services offered includes access control, connectionless integrity, data origin authentication, protection against replays, confidentiality (encryption), and limited traffic flow confidentiality. These services are provided at the IP layer, offering protection for IP and upper-layer protocols. Because these services are provided at the IP layer, they can be used by any higher-layer protocol (for example TCP, User Datagram Protocol [UDP], and Border Gateway Protocol [BGP]). IPsec combines the following security protocols: = Authentication Header (AH) = Encapsulating Security Payload (ESP) m Internet Key Exchange (IKE) AH and ESP can be used independently or together, although for most applications, just one of them is sufficient, For both of these protocols, IPsec does not define the specific security algorithms to use but, rather, provides an open framework for implementing industry-standard algorithms. Initially, most implementations of IPsec support Message Digest 5 (MDS) from RSA Security (*RSA” stands for Rivest, Shamir, and Adleman, the three inventors) or the Secure Hash Algorithm (SHA) as defined by the U.S. government for integrity and authentication. 4-4 Securing Networks with Cisco ASA Advanced (SNAA) v1.0 © 2008 Cisco Systems, Inc.IPsec provides security services at the IP layer by enabling a system to select required security protocols, determine the algorithm (or algorithms) to use for the service (or services), and put in place any cryptographic keys required to provide the requested services. IPsec can be used to protect one or more paths between a pair of hosts, between a pair of security gateways, or between a security gateway and a host Note The term “security gateway’ is predominantly used to refer to an intermediate system that implements IPsec protocols (for example, a router or a firewall implementing IPsec), The IPsec protocol provides IP network-layer encryption and defines a new set of headers to be added to IP datagrams, These new headers are placed after the IP header and before the Layer 4 protocol (typically TCP or UDP). They provide information for securing the payload of the IP packet imply put, IPsec provides secure tunnels between two peers, such as two routers. You define which packets are considered sensitive and should be sent through these secure tunnels, and by specifying the characteristics of these tunnels, you define the parameters that should be used to protect these sensitive packets. Then, when the IPsec peer sees such a sensitive packet, it sets up the appropriate secure tunnel and sends the packet through the tunnel to the remote peer These tunnels are sets of security associations (SAs) that are established between two IPsec peers, The SAs define which protocols and algorithms should be applied to sensitive packets and also specify the keying material to be used by the two peers. SAS are established per security protocol (AH or ESP). rectional and are Note IVIKE is used to establish the SAs, the SAs will have lifetimes so that they will periodically expire and require renegotiation. Multiple IPsee tunnels can exist between two peers to secure different data streams, with each tunnel using a separate set of SAs. For example, some data streams might only be while other data streams must be both encrypted and authenticated ithenticated Access control lists (ACLs) that are associated with IPsec crypto map entries represent which traffic the router requires to be protected by IPsec. Inbound traffic is processed against the erypto map entries; if an unprotected packet matches a permit entry in a particular ACL that is associated with an IPsee cryplo map entry, that packet is dropped because it was not sent as an IPsec-protected packet. Crypto map entries also include transform sets. A transform set is an acceptable combination of security protocols, algorithms, and other seitings to apply to IPsec-protected traffic. During the IPsec SA negotiation, the peers agree to use a particular transform set when protecting a particular data flow. Because these security services use shared-secret values (cryptographic keys), IPsec relies on a separate set of mechanisms for putting these keys in place (© 2008 Cisco Systems, Inc. IPsec VPNs 45IPsec Protocols and Terminology * Symmetric encryption * Public key infrastructure ae Certificates ~ AES Certificate authorities eae) Certificate revocation lists ~ 3DES = IPeec terme + Asymmetric encryption and key Gyn ane ee see saa aes, an ~ Transform sets * Hashing algorithms and technologies ~ MDS SHA — HMAC. Cisco security appliances support the following IPsec and related standards Listed here are some other protocols and terms used with IPsec. = Advanced Encryption Standard (AES): AES was finalized as a Federal Information, Processing Standard (FIPS)-approved cryptographic algorithm to be used to protect electronic data transmission (FIPS PUB 197). AES is based on the Rijndael algorithm, which specifies how to use keys with a length of 128, 192, or 256 bits to encrypt blocks with a length of 128, 192, or 256 bits (all 9 combinations of key length and block length are possible). = Data Encryption Standard (DES): The DES was published in 1977 by the National Bureau of Standards (NBS) (the former name of the National Institute of Standards and Technology [NIST] and is a secret-key encryption scheme based on the Lucifer algorithm from IBM. The contrast of DES is public key. Cisco uses DES in classic cryptography, IPsee cryptography, and on the Cisco ASA adaptive security appliance. = Triple DES (3DES): This is a mode of the DES encryption algorithm that enerypts data three times. Three 64-bit keys are used, instead of one 64-bit key, for an overall key length of 192 bits. The first encryption is encrypted with a second key, and the result text is again encrypted with a third key 1s cipher © Diffie Hellman (DH): This is a method of establishing a shared key over an insecure medium. DH is a component of Oakley protocol. = RSA: RSA is a public key cryptographic algorithm with a variable key length. The main weakness of RSA is that it is significantly slow to compute compared to popular secret-key algorithms, such as DES. The Cisco IKE implementation uses a DH exchange to get the This exchange can be authenticated with cd keys). With the DH exchange, the DES key never crosses the network (not even in encrypted form), which is not the case with the RSA encrypt and sign technique. RSA is not a public domain and must be licensed from RSA Secu 48 Securing Networks with Cisco ASA Advanced (SNA) v1.0 (© 2008 Cisco Systems, inc© Hash: This is a one-way function that takes an input message of arbitrary length and produces a fixed-length digest. Cisco uses both SHA and MDS hashes withi implementation of the IPsec framework. = MDS: MDS is a one-way hashing algorithm that produces a 128-bit hash, Both MDS and SHA are variations on Message Digest 4 (MD4), which is designed to strengthen the security of this hashing algorithm, SHA is more secure than MD4 and MDS = SHA-1: This is a one-way hash put forth by the NIST. SHA is closely modeled after MD4 and produces a 160-bit digest. Because SHA produces a 160-bit digest, it is more resistant to brute-force attacks than 128-bit hashes (such as MDS), but it is slower. = Hashed Message Authentication Code (HMAC): HMAC is a mechanism for message authentication using cryptographic hashes such as SHA and MDS = Certificate: A certificate is a eryptographically signed object that contains an identity and a public key associated with this identity = Certificate authority (CA): A CA isa third-party entity with the responsibility to issue and revoke cettificates. Each device that has its own certificate and public key of the CA can authenticate every other device within the domain of a given CA. This term also applies to server software that provides these services. © Certificate revocation list (CRL): A CRL is a digitally signed message that lists all of the current but revoked certificates listed by a given CA. = Crypto map: A crypto map is a Cisco IOS software configuration entity that performs two primary functions. First, it selects data flows that need security processing. Second, it detines the policy tor these Hows and the erypto peer that traftic needs to go to. A crypto map is applied to an interface. = Perfect forward secrecy (PFS): PFS ensures that a given IPsec SA key was not derived from any other secret (like some other keys). In other words, if someone breaks a key, PFS ensures that the attacker is not able to derive any other key. If PFS is not enabled, someone can potentially break the IKE SA secret key, copy all the IPsec protected data, and then use knowledge of the IKE SA secret to compromise the IPsec SA that is set up by this IKE SA. With PFS, breaking IKE does not give an attacker immediate access to IPsec. The attacker needs to break each IPsec SA individually. The Cisco IOS IPsec implementation uses PFS group | (DH 768 bit) by default = Transform sets: A transform describes a security protocol (AH or ESP) with its corresponding algorithins (for example, ESP with the DES cipher algorithm and HMAC and SHA for authentication), {© 2008 Cisco Systems, Inc. IPsec VPNs 47IPsec Operation This topic describes IPsec operation. iPsec Operation Host isco Securty e1sco Secunty Host 8 Pgs ‘Appkance B ey Reiy Te & Interesting traffic is detected: The VPN devices recognize the traffic to protect defined in crypto access control lists. IKE establishes security associations for secure communications: IKE Phase 1: The VPN devices negotiate an IKE security policy and establish a secure channel IKE Phase 2: The VPN devices negotiate an IPsec securily policy to protect IPsec data Data transfer: The VPN devices apply security services to trafic, then transmit the traffic. Tunnel terminated: The tunnel is torn down, ‘The goal of IPsec is to protect the desired data with the needed security services. IPsec operation can be broken down into five primary steps: = Interesting traffic is detected: Traffic is deemed interesting when the VPN device recognizes that the traffic you want to send needs to be protected. ACLs are used to define traffic that is to be deemed interesting (data to be encrypted), IKE negotiates SAs in two phases: — IKE Phase 1: A basic set of security services are negotiated a between peers. These secu between the peers. IKE Ph IKE peers. il agreed upon 1 all subsequent communications n channel between — IKE Phase 2: IKE negotiates IPsec SA par. ching IPsec SAs in the peers. These security parameters are used to protect data and messages that exchanged between endpoints. re m= Data transfer: Data is transferred between IPsec peers, based on the IPsee parameters and keys that are stored in the SA database. ation: IPsec SAs terminate through deletion or by timing out. 48 Securing Networks with Cisco ASA Advanced (SNAA) v1.0 (© 2008 Cisco Systems, Inc.Interesting Traffic Branch 8 Host 8 ASAB Host A ‘ ‘Cisco ASAA Encrypter —_ iy caer Cleaned ae SISLASA A extended permt iP 10010 2562552860 19.020 286 296 2580 eee www paper.com ‘Send in Cleartext * Host A is sending traffic bound for Intranet (Host 8), — Defined by the crypto ACL; is deemed interesting and encrypted * Host A is sending traffic bound for Internet (www. paper com) Not defined by crypto ACL; sent as cleartext. Determining which traffic needs to be protected is a part of formulating a security policy for a corporate VPN. The VPN security policy determines which traffic needs to be protected and which traffic ean be sent in the clear and not protected. For every inbound and outbound datagram, there are two choices: apply IPsec or bypass IPsec and send the datagram in cleartext Using IPsec, you will configure ACLs to define which traffic should be protected between two IPsec peers. Therefore, traffic may be selected based on source and destination address and, optionally, Layer 4 protocol and port. Note ‘The ACLs used for IPsec (crypto ACLs) are used only to determine which traffic should be: protected by IPsec, not which traffic should be blocked or permitted through the interface ‘Separate ACLs define blocking and permitting at the interface. Simply put, IPsee provides secure turmels between two pects. ACL» ate configured to de! which packets are considered sensitive and should be sent through these secure tunnels. Then, when the IPsec peer sees such a sensitive packet, it sets up the appropriate secure tunnel and sends the packet through the tunnel to the remote peer. For example, in the figure, Host A is sending outbound traffic to Branch B. Since the packet matches the outbound traffic defined by the crypto ACL to be interesting,” the packet will be encrypted by Cisco ASA security appliance A and forwarded Host A is sending outbound traffic to the Internet (www.paper.com) m Since the packet does not match the outbound traffic defined by the crypto ACL, the packet will be forwarded as cleartext by Cisco ASA security appliance A (© 2008 Cisco Systems, Inc. IPsecVPNs 49)Internet Key Exchange Internet Key Exchange (IKE) » RFC 2409 * A hybrid protocol consisting of. Skeme = Amechanism for using public key encryption for authentication Oakley » Amodes-based mechanism for arriving at an encryption key between two peers, ISAKMP (Internet Security Association Key Management Protocol) = Anarchitecture for message exchange including packet formats and state transitions between two peers. » Phase-based IKE is a hybrid protocol that uses part Oakley and part of another protocol suite called Skeme inside the Intemet Security Association and Key Management Protocol (ISAKMP) framework, IKE is used to establish a shared security policy and authenticated keys for services (such as IPsec) that require keys. Before any [Psee traffic can be passed, each router, firewall, and host must be able to verify the identity of its peer. Identity verification can be done by manually entering pre-shared keys of both hosts or by a certificate authority (CA) service. Iki is the protocol formerly known as ISAKMP/Oakley, and is defined in RFC 2409. IKE is a hybrid solution that uses the following: = Skeme: Describes a versatile key exchange technique that provides anonymity reputability, and quick key refreshment = Oakley: Describes a series of key exchanges called “modes” and details the services provided by each (for example, perfect forward secrecy for keys, identity protection, and authentication) = ISAKMI 1! rovides a framework for authentication and key exchange but does not d em; designed to support many different key exchanges ine = Diffie-Hellman (DH): IKE uses a DH key exchange to set up a shared session secret, fro which cryptographic keys are derived 4-10 Securing Networks with Cisco ASA Advanced (SNAA) v1.0 (© 2008 Cisco Systems, IncHow IKE Works oa an Main Mode 6 Messages foie On erectile! ical Aggressive Mode IKE is a two-phase protocol. Oakley and Skeme each define a method to establish an authenticated key exchange. This includes the construction of payloads, the information that payloads carry, the order in which payloads are processed, and how they are used While Oakley defines modes, ISAKMP defines phases. The relationship between the two is very straightforward, and IKE presents different exchanges as modes that operate in one of two phases. IKE Phase 1 The basic purpose of IKE Phase | is to negotiate IKE policy sets, authenticate the peers, and set up a secure channel between the peers. IKE Phase | occurs in two modes: main mode or aggressive mode. Aggressive mode is faster, but it does not provide identity protection for the communicating parties like the slower main mode does. Therefore, the peers must exchange identification information prior to establishing a secure SA. Aggressive mode is enabled by default on the Cisco ASA security appliance. = Mai mode has three two-way exchanges between the initiator and receiver: — First exchange: The algorithms and hashes that are used to secure the IKE communications are negotiated and agreed upon between peers. Second exchange: This exchange uses a DH exchange to generate shared-secret keys and pass nonces, which are random numbers sent to the other party, signed, and returned to prove their identity. The shared-secret key is used to generate all the other encryption and authentication keys. — Third exchange: This exchange verifies the identity of the other side, It is used to authenticate the remote peer. The main 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 could be stealing all your sensitive material (© 2008 Cisco Systems, Inc. IPsec VPNs 4-11Aggressive mode has two two-way exchanges between the initiator and receiver: — First exchange: Almost all of the IKE policy-set negotiation happens. The DH 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 through a third party are all exchanged. The receiver sends everything back that is needed to complete the exchange. Second exchange: iator confirms the exchange. IKE Phase 2 The purpose of IKE Phase 2 is to negotiate IPsec SA parameters and set up matching unidirectional IPsec SAs between the peers. These security parameters are used to protect data and messages that are exchanged between endpoints by performing the following functions: = Negotiate IPsce security parameters and IPsec transform sets, = Establish IPsec SAs & Periodically renegotiate IPsec SAs to ensure security = (Optional) Perform an additional DH exchange IKE Phase 2 has one mode, called quick mode. Quick mode occurs after IKE has established the secure tunnel in Phase 1. It negotiates a shared IPsec transform, derives shared-secret keying material used for the IPsec security algorithms, and establishes IPsec SAs. Quick mode exchanges nonces that are used to generate new shared-secret-key material and prevent replay attacks from generating invalid SAs. Quick mode accomplishes an IKE Phase 2 excha Quick mode is also used to renegotiate a new IPsec SA when the IPsec SA lifetime expires. Quick mode also refreshes the keying material that is used to ereate the shared-seeret hey 1 based on the keying material derived from the DH exchange in Phase | ‘The ultimate goal of IKE Phase 2 is to establish a secure IPsec session between endpoints Before that can happen, each pair of endpoints negotiates the level of security required (for example, eneryption and authentication algorithms for the session). Rather than negotiate each protocol individually, the protocols are grouped into sets, called IPsec transform sets. IPsec transform sets are exchanged between peers during quick mode. If a match is found between sets, IPsec session-establishment continues. If no match is found, the session is halted. 412 ‘Securing Networks with Cisco ASA Advanced (SNA) v1.0 (© 2008 Cisco Systems, IncIPsec Session Cisco Security Cisco Security ‘Appliance A ‘Appliance B_ Host 8 ees Host A —_—" \Psec Session = SAs are exchanged between peers. » The negotiated security services are applied to the traffic After IKE Phase 2 is complete and quick mode has established IPsec SAs, traffic is exchanged between hosts A and B through a secure tunnel. Interesting traffic is encrypted and decrypted according to the security services specified in the IPsec SA. (© 2008 Cisco Systems, Inc. IPsec VPNs 4.13,DH Exchange Private Value, X, Private Value, Xp. Alice pubic Value, Y, Public Value, Y, 8°? Y, =9”* mod p Y, =9*° mod p 1 1 Dm conor Yo" mod p= zz mod p = zz XeXp Alice-Calculated zZz=Qg mod p Bob-Calculated (Shared Seéret) DH key exchange is a public-key exchange method that provides a way for two peers to establish a shared secret key over an insecure communication path. In order to start a DH exchange, the two parties must agree on two nonsecret numbers. The first number is g, the generator, and the second number is p, the modulus. These numbers ean be made public and are usually chosen from a table of known values, The g is usually a very small number, such as 2, and p is a very large prime number. Next, every party generates its own secret value. Then, based on g, p, and the secret value of each party, each party calculates its public value, The public value is computed according to the following formula: =g'mod p In this formula x is the secret value of the entity, and Yis the public value of the entity. After computing the public values, the two parties exchange their public values. Each party then exponentiates the received public value with its secret value to compute a common shared- secret value, When the algorithm completes, both parties have the same shared secret, which they have computed from the ecret value and the public value of the other party No one listening on the channel can compute the secret value, because only g, p, ¥, and Yyare Kno:wn, at least one secret value is needed to calculate the shared secret. Unless the attacker ea compute the discrete algorithm of the above equation to recover X4 or Xp, they cannot obtain the shared secret. With DH, there are several different DH algorithms and groups defined: DH groups | through 7. A group number defines an algorithm and unique values. For instance, group | defines a prime modular exponential (MODP) algorithm with a 768-bit prime number. Group 2 detines an MODP algorithm with a 1024-bit prime number. Group 7 uses an elliptic curve cryptography (ECC) algorithm. During IKE Phase 1, the group is negotiated between peers. Between Cisco VPN devices, groups 1, 2, and 7 are supported. 4-14 Securing Networks with Cisco ASA Advanced (SNAA) v1.0 (© 2008 Cisco Systems, Inc.After the group negotiations are completed, the shared-secret key is calculated. The shared- secret key, SKEYID, is used in the derivation of three other keys: SKEYID_a, SKEYID_d, and SKEYID_e, Each key has a separate purpose. SKEYID_a is the keying material used during the authentication process. SKEYID_d is the keying material used to derive keys for non-ISAKMP SAs. SKEYID_¢ is the keying material used in the encryption process. All four keys are calculated during IKE Phase 1 Authenticate Peer identity Remote Office Authentication Peer authentication methods » Pre-shared keys, = RSA cignature When you are conducting business over the Internet, you must know who is at the other end of the tunnel, The device on the other end of the VPN tunnel must be authenticated before the ‘communications path is considered secure. The last exchange of IKE Phase 1 is used to authenticate the remote peer. ISAKMP provides VPN peer authentication and is also used to set up the secure tunnels. ISAKMP defines the procedures for authentication of a communicating peer, creation and management of Security Associations, key generation techniques, and threat mitigation (for ‘example, denial of service and replay attacks). The Cisco ASA security appliance supports two data origin authentication methods: & Pre-shared keys: IKE can use pre-shared keys that are manually input by the administrators on both ends of the co hared-secret” password is configured on both security applian wuthentication. Pre-shared keys are easy 10 le well. Each IPsec peer must be configured with the pre-shared key of every other peer with which it communicates. = RSA Signature: IKE can also use digital signatures for peer authentication. Certificate Authority (CA)-signed certificates are exchanged in the IKE tunnel. Routers and security appliances communicate with the CA using the Simple Certification Enrollment Protocol (SCEP) protocol, which is an extension to the ITU-T X.509 standard for public key infrastructure (PKI). (© 2008 Cisco Systems, Inc. Wsec VPNs 4:15Security Associations + SAD ~ Destination IP address - SPI vwemers 77 snes eee ESPRDESIHNA a 28800 Encryption { algorithm ee ‘Aiport Internet ‘authentication a ~ Nace tases my key lifetime ‘SPI-39 esppesmos ~~] Tunnel 28800 The concept of a security association (SA) is fundamental to IPsec. Both AH and ESP make use ‘of SAs, and a major function of IKE is the establishment and maintenance of SAs. All implementations of AH or ESP must support the concept of an SA. An SA isa simplex connection that affords security services to the traffic carried by it. Security services are afforded to an SA by the use of AH, or ESP, but not both. If both AH and ESP protection is applied to a traffic stream, two (or more) SAs are created to afford protection to the traffic stream, To secure typical, bidirectional communication between two hosts, or between two security gateways, two SAs (one in each direction) are required. When the security services are agreed upon between peers, each VPN peer device enters the information in a security policy database (SPD). The information includes the encryption and authentication algorithm, destination IP address, transport mode, key lifetime, and so on. This information is referred to as the SA. An SA is a one-way logical connection that provides security to all traffic traversing the connection. Because most traffic is bidirectional, two SAs are required: one for inbound traffic and one for outbound traffic. The VPN device indexes the SA with a number, a security parameter index (SPI). Rather than send the individual parameters of the SA across the tunnel, the source gateway (or host) inserts the SPI into the ESP header. When the IPsec peer receives the packet, it looks up the destination IP address, IPsec protocol, ind SPI in its SA database (SAD), then processes the packet according to the algorithms listed under the SPD. The IPsec SA is a compilation of the SAD and the SPD. The SAD is used to identify the SA destination IP address, IPsec protocol, and SPI number. The SPD defines the security services applied to the SA, eneryption and authentication algorithms, and mode and key lifetime, For example, in the corporate-to-bank connection, the security policy provides a very secure tunnel using 3DES, SHA, tunnel mode, and a key lifetime of 28800. The SAD value is 192.168.2.1 ESP, and SPI-12, For the remote user accessing e-mail, a less secure policy is negotiated using DES, MDS, tunnel mode, and a key lifetime of 28800. The SAD values are a destination IP address of 192.168.12.1, ESP, and SPI-39. 416 ‘Securing Networks with Cisco ASA Advanced (SNAA) v1.0 (© 2008 Cisco Systems, Inc.The longer you keep a password on your company PC, the more vulnerable it becomes. The same is true of keys and SAs. For good security, the SA and keys should be changed periodically. There are two parameters to consider: lifetime type and duration. The first parameter, lifetime type, defines how the lifetime is measured, by the number of bytes transmitted or the amount of time transpired. The second parameter, the duration, is expressed in either kilobytes of data or seconds of time. For example, you might specify a lifetime based on 10,000 KB of data transmitted or 28,800 seconds of time expired. ‘The keys and SAs remain active until their lifetime expires or until some external event—the client drops the tunnel— causes them to be deleted. Tunnel Termination i “Appliance A “Appliances “OS'S m ~ — Le J ys — maser} \ eco —_—— * A tunnel is terminated: By an SA lifetime timeout ~ If the packet counter is exceeded By peer + Removes IPsec SA IPsec SAs terminate through deletion or by timing out. An SA can time out when a specified number of seconds has elapsed or when a specified number of bytes has passed through the tunnel. When the SAs terminate, the keys are also discarded. When subsequent [Psec SAs are needed for a flow, IKE performs a new Phase 2 negotiation and, if necessary, a new Phase | negotiation. A successful negotiation results in new SAs and new keys. New SAs are usually established before the existing SAs expire so that a given flow can continue uninterrupted. ‘© 2008 Cisco Systems, Inc IPsecVPNS 4.17Digital Certificates and Public-Key Cryptography This topic describes how digital certificates and publi key cryptography work. TAT RoR A Ae Ao es MRE Public-Key Cryptography © Users have a key pair Private Public » Anything encrypted by one key can be decrypted by the other key * Asymmetric cryptography Traditional cryptography has usually involved the creation and sharing of a “secret” key for the encryption and decryption of messages. This secret or “private” key system has the significant flaw that if the key is discovered or intercepted by someone else, messages can easily be decrypted. For this reason, “public” key cryptography and the public key infrastructure (PKI) is the preferred approach on the Internet. The private key system is sometimes known as symmetric cryptography because the encryption keys are the same, and the public key system is sometimes known as asymmetric cryptography because the keys for encryption and decryption are different. Digital signatures, enabled by public-key cryptography, provide a means to authenticate devices and users In public-key cryptography, such as the RSA encry stem, each u has a key pair containing both a public and a private key. The keys act as complements, and anything enerypted with one of the keys ean be decrypted with the other. A signature is formed when data is encrypted with a private key. The signature is attached to the data and sent to the receiver. The receiver applies the public key of the sender to the data. If the signature sent with the data matches the result of applying the public key to the data, the validity of the message is established. This process relies on the receiver having a copy of the public key of the sender and having a high degree of certainty that this key belongs to the sender, not to someone pretending to be the sender. a8 ‘Securing Networks with Gisco ASA Advanced (SNA) v1.0 (©2008 Cisco Systems, IncObtaining the public key of a sender is normally handled out-of-band or through an operation done at installation. For instance, most web browsers are configured with the root certificates of several CAs by default. For VPN, the IKE protocol can use peer devices before setting up security associations. igital signatures to authenticate Public-key cryptography is used by the PKL (© 2008 Cisco Systems, Inc. IPsec VPNs 4.19Digital Signature Remote Pay Ty Souh PY so00 Gratin and ‘00 "Ootrs ees a ‘The digital signature provides a form of digital credentials that authenticate the identity of the sending party, whoever that may be. other words, digital signatures are used to Tink data with the holder of a specific private key and consists of the following: At the local end, a message is run through a hash algorithm. A private key is used to encrypt the hash only. The encrypted hash is appended to the message and sent to the remote end, At the remote end: — Running the original message through a hash algorithm produces the hash. ‘The public key of the sender decrypts the original message of the hash to which it ‘was appended. Ifthe hashes match, the private key of the local user signs the messa Only a specific private key could have produ < the digital signature 420 ‘Securing Networks with Cisco ASA Advanced (SNAA) v1.0 (© 2008 Cisco Systems, Inc.Certificates and Scalability ‘This topic explains the scalability that is achieved by using cert When you are conducting business over the Internet, ficates. PKI Scalability for VPN Root CA, ‘Sen TS J ‘ No. of Devices _[No. of Certificates [ No. of Pre-Shared Keys 10 10. i 45 700 700 4960 |, You must know who is at the other end of the tunnel. The device on the other end of the VPN tunnel must be authenticated before the communications path is considered secure. ISAKMP is used to provide VPN peer authentication as well as to set up the secure tunnels. The Cisco ASA security appliance supports two data origin authentication methods: Pre-shared keys: IKE can use pre-shared keys that are manually input by the administrators on both ends of the connection. The same IKE “shared-secret” password is configured on both security appliances for IKE authentication. Pre-shared keys are easy to configure manually but do not scale well. Each pair of communicating IPsee peers should be using a unique pre-shared key. No two pairs should have the same pre-shared key. To communicate with multiple peers, each IPsec device must be configured with dhe unig pre-shared key of every other peer with which it communicates. RSA Signature: IKE can also use digital signatures for peer authentication. Each device has its own “unique” certificate that it exchanges with its peer device. exclianges the same unique the each device's certificat cach device stificate with each remote peer that it communicates with. If authenticated by the other end, the tunnel setup can continue (© 2008 Cisco Systems, Inc. IPsec VPNs 4.21With a network using pre-shared keys, each pair of devices should have its own unique pre~ shared key to exchange. In a network of 10 devices, the administrator would have to configure 45 unique pre-shared keys, (N (N-1)) /2. For a network of 100 device pairs, the administrator would have to configure 4950 unique pre-shared keys. Pre-shared key designs do not scale well. With certificates, each device only requires its own certificate. Certificates are unique to a device. In a network in which 10 devices must establish tunnels between devices, 10 certificates are required, one certificate per device. Certificates allow scalability in very large networks. Without certificates, every new device added to the network would require a configuration change on every other device with which it communicates securely. CA Server Fulfi Peers ing Requests from IPsec Each IPsec peer individually enrolls with the CA server. Certificate Authority. 4 Server With a certificate authority, you do not need to configure keys between all of the encrypting IPsec peers. Instead, you individually enroll each participating peer with the CA and request a certificate. When this has been accomplished, cach participating peer can dynamically authenticate all of the other participating peers. To add a new IPsec peer to the network, you need to configure only that new peer to request a certificate from the CA, instead of making multiple key configurations with all the other existing IPsec peers. 422 Securing Networks with Cisco ASA Advanced (SNAA) v1.0 (© 2008 Cisco Systems, InePublic Key Infrastructure Hierarchical Central Root CA Subordinate cA Public key infrastructure (PKI) is the set of hardware, software, people, policies, and procedures needed to create, manage, store, distribute, and revoke digital certificates. PKI makes it possible to generate and distribute keys within a secure domain and enables CAS to issue keys, associated certificates, and CRLs in a secure manner. The two PKI models are central and hierarchical authorities: m= Central: A flat network design. A single authority, root CA, signs all certificates. Each device that needs a certificate sends a request to the root CA. Small companies with several hundred employees or devices can use central CA. In the central CA example, there is a small company with only a few sites. Each site, Boston and Headquarters, enrolls with the same CA. = Hierarchical authority: A tiered approach. The ability to sign a certificate is delegated through a hierarchy. The top of the hierarchy is the root CA. It si ate authorities, also known as a registration authority (RA). ate CAs sign certificates for lower-level CAs or employees. Large, geographically dispersed corporations (for example, Cisco Systems) use hierarchical CAs. The root CA is located in San Jose, the company headquarters. Rather than having thousands of devices making, ate requests back to San Jose, subordinate CAS are placed strategically around the world. Devices request a CA from the local subordinate CA, such as the devices in Boston, New York, and London. Each of these devices has the same root certificate that was distributed by two different subordinate CAs. Note Registration authority (RA) is responsible for communicating with clients requesting certificates. RA is used to offload the enrollment process overhead from the CA and offers better security since clients have no direct access to the CA. When using SCEP, the CA will retum both a CA and RA certificate to the Cisco ASA security appliance. © 2008 Cisco Systems, Inc. IPsec VPNs 4.23,Certificate Authority RSA CA responsibilities: re Hl = Create certificates Entrust. = Administer certificates cya lili) * Revoke invalid certificates B varroiore etfuefts cisco Certificate authorities (CAs) hold the key to the PKI, A CA is a trusted third party whose job is to certify the authenticity of users to ensure that you are who you say that you are. The CA digital signature, created with the CA private key, guarantees authenticity. You can verify a digital signature using the CA public key. Only the CA public key can decrypt the digital certificate. The CA creates, administers, and revokes invalid certi tes. The CA can be a corporate network administrator or a recognized third party. Trusted sources supported by the Cisco ASA security appliance include the following: ® CiscoCA = Entrust = RSA Keon = Netscape CMS = Baltimore Technologies ® Microsoft Certificate Services . VeriSign ‘Securing Networks with Cisco ASA Advanced (SNAA) v1.0 © 2008 Cisco Systems, IncCertificate Enrollment Process In the next section, the generic certificate enrollment process is discussed. Certificate Generation Process Dea server Process request Generate certificate Install certificate certificate \d user (or end entity) must obtain a digital certificate from the CA to participate in a certificate exchange. This is known as the enrollment process. It requires four steps: 1. Each user generates a private and public key pair. 2. The requestor generates a certificate request and sends it to the CA. The CA transforms the certificate request into a digital certif and identity digital certificate to the requestor. ‘ate and returns both a root 4, The requestor installs the root certificate into the security appliance first. While installing the identity certificate, the Cisco ASA security appliance uses the public key from the root cottificate to validate the signature of the identity e cate, © 2008 Cisco Systems, Inc. PsecVPNs 4.25,Generating a Certificate Request Cisco ASA PKCS #10 In the certificate generation process, first you generate a certificate request known as a Public- Key Cryptography Standard #10 (PKCS #10). User information such a3 a common name, organizational unit, organization, locality, state, country, and public key can be requested. After the information is supplied, the Cisco ASA security appliance generates a certificate request: a PKCS #10. The request is formatted as an Abstract Syntax Notation One (ASN.1) message and sent to the CA. 4-26 Securing Networks with Cisco ASA Advanced (SNAA) v1.0 (© 2008 Cisco Systems, IncCertificate Request ‘The figure shows a sample certificate request form completed on the Cisco ASA security appliance. In the example, the admi rator supplies the common name and organi H unit. The additional subject attributes that could also be defined on the request form are as follows: Common Name (CN) field: A u ique name for the subject. Organizational Unit (OU) field: The Security appliance uses the organizational unit as the group name. By default, the OU field of the certificate must match the group attribute data based in the security appliance Organization (O) field: The company name. Locality (L): ty or town where the company resides State/Province (SP): State or province where the company resides. Country (C): Country where the company resides, (© 2008 Cisco Systems, inc. (Psec VPNs 4.27Digital Certificate Encoding PC or Cisco ASA Digital certificate Ep ff When a certificate is sent between a CA and a security appliance, the ASN.1 formatted message is encoded. The digital certificate encoding can be one of two types: Distinguished Encoding Rules (DER) data (raw binary format) or Privacy Enhanced Mail (PEM) format (binary converted to base 64 format). Typically when you request a certificate, the CA prompts you for the encoding type: DER or base 64 encoding. This may be an issue if the sender or receiver can support only one encoding type. The Cisco ASA security appliance can support both types. The CA can send certificates individually, an identity and a root certificate. You can also request an all-inclusive CA certificate path, PKCS #7. PKCS #7 is a message syntax that allows multiple certificates to be enveloped within one message (the same concept as PKZip storing, multiple files in a zip file) 428 ‘Securing Networks with Cisco ASA Advanced (SNAA) v1.0 (© 2008 Cisco Systems, IncGenerating an Identity Certificate Cisco ASA or PC cA (see) = Certeaie 123488 Dios. | Ka34s67e Upon receipt of the PKCS #10, the CA verifies the authenticity of the PCS #10. The CA decrypts the digital signature with the requestor’s public key to validate it. If valid, PKCS #10 is transformed into an identity certificate. The identity certificate is a composite of information supplied from the PKCS #10 and by the CA. For security, a hash algorithm is performed on the ned attributes. The hash value is encrypted using the CAs private key, and is attached to ificate. The identity certificate is then sent to the security appliance as an ASN.1 formatted message, (© 2008 Cisco Systems, Inc. IPsec VPNs 4.29Digital Certificates ton a Digital certificates contain: va we + Serial number ns 2 Validity dates Bore te tk Issuer's name he Sean Subjects name Basie d hicrs, 308%) ‘Subject’s public key information Butte sauce caseeen ‘The figure shows a sample digital certificate that was issued by the CA. The X.509 certificate consists of specifie fields and values. The certificate information displays the follow = Certificate format version: Currently, it is X.509 version 1, 2, or 3 = Certificate serial number: Unique certificate numerical identi When a certificate is revoked, it is the ce in the CA domain, icate number that is listed on the CRL Signature algorithm: Identifies the public key of the CA and the hashing algorithm. @ Issuer: The di tinguished name of the CA. Validity period: Specifies the start and expiration dates for the certificate. Subject X.500 name: The distinguished name of the entity holding the private key Subject public key information: Specifies the public key of the subject and the hashing algorithm. = Extensions: Extends the certificate to allow additional information = CRL-DPs (distribution points): Location of the CRL li for this certificate. CA signature: The CA performs a hash function on the certificate contents; the hash is then signed with the private key of the CA to ensure authenticity 430 Securing Networks with Cisco ASA Advanced (SNAA) v1.0 (© 2008 Cisco Systems, IncValidating the Certificate This topic discusses the validation of certifi Verifying the Certificate Digital Certificate * Identity certificate validation: Can the identity certificate be verified with the CA public key? — Has the identity certificate expired? — Has the identity certificate been revoked? Before an identity certificate is installed, the security appliance must v ASA security appliance checks the following to validate the identity certificate: Is the identity c ficate verified with the public key of the CA? m= Has the identity c e expired? = Has the identity certificate been revoked? Once validated, the certificate is installed on the security appli now be exchanged with a peer during the IKE authentication ph nce, The identity certificate ean . (© 2008 Cisco Systems, Inc IPsec VPNs 4.31Peer Certificate Validation Headquarters aay =e Internet isl Validate the identity certificate of the peer. * Exchange the identity certificates during IKE negotiations. + Verify the identity certificate signature through the stored root certificate * Verify that the certificate validity period has not expired. * Verify that the identity certificate has not been revoked During Internet Key Exchange (IKE) negotiations, identity certificates are exchanged to authenticate peers. When an identity certificate is received from an IKE peer. the Cisco ASA security appliance attempts to validate the peer’s certificate. In the example in the figure, the Headquarters Security Appliance sends its identity certificate to the Boston Branch security appliance. The Boston Branch security appliance attempts to validate the certificate as follows: m Validate the signature. The security appliance uses the public key stored on its root certificate to decrypt the hash of the identity certificates. The security appliance also re- computes a hash of the received identity certificate. If the decrypted and re-computed hashes match, the certificate is valid Note Before IKE exchange can begin, a valid identity and root certificate must be installed on each security appliance. Notice that the identity certificates were both issued by an Entrust CA. Also notice that an Entrust root certificate was installed on each security appliance, To validate an incoming identity certificate, the receiving security appliance must have a copy of both its and its peers CAs root certificate resident on the device. If the remote peer was enrolled by a Microsoft CA and the local peer was enrolled through an Entrust CA, each security appliance must have both an Entrust and a Microsoft Root Certificate resident on the devices. = Check the validity period of the certificate against the system clock of the security appliance. If the system clock of the security appliance falls within the validity period of the identity certificate, the test is suecessful. The validity range can be found on the identity cenificate = (Optional.) If enabled, the security appliance locates the CRL. and determines if the identity certificate serial number is on the list. If present, the certificate is revoked. If absent, the certificate is valid. ‘Securing Networks with Cisco ASA Advanced (SNA) v1.0 (© 2008 Cisco Systems, incIf the received identity certificate passes the validation process, the Boston Branch security appliance authenticates the Headquarters security appliance. In turn, the Boston Branch security appliance sends its identity certificate to the Headquarters security appliance. The Headquarters security appliance performs the same validation process for the identity certificate of the Boston Branch security appliance Cx py ® cy Roat Publi ers Key The first step in validating a digital certificate is to validate the signature. Signature validation begins at the CA, where the original identity certificate is put through a hash algorithm, the output hash is encrypted by the private key of the CA, and the hash is appended to the end of the certificate. At the remote end, there is a two-step process: Step1 The receiver uses the public key of the CA to decrypt the hash. The result is the original hash value. Step2 The received message is sent through the hash algorithm to produce a second hash. The CA-generated hash and security appliance-generated hash are compared: = If they match, the identity cert te is genuine, = If they do not match, the certificate is invalids there is an invalid signature or identity certificate. © 2008 Cisco Systems, Inc. [Psec VPNs 4.33Certification Chain Central Hierarchical Root Cenifcate taennty Cerificate. Subordinate CA Certificate Boston Headquarters Identity Cerificate Previously, it was stated that the security appliance needs a copy of the public key of the CA to decrypt the hash. The question is where docs the security appliance find a copy of that key? The answer is, it depends on the CA environment, central or hierarchical, In a central, or flat, CA, the root CA signs the identity certificate. The root certificate must be installed before trying to install the identity certificate so that the security appliance has access to the root's public key. One of the root CA fields is a copy of the public key of the CA. In the example in the figure, the public key of the root cei s used to validate the signature of the certificate of Boston, Ina hierarchical environment, the ability to sign is delegated through the hierarchy. The top is the root CA; it signs certificates for subordinate CAs. The subordinate CA signs certificates for lower level CAS. Ultimately, a subordinate CA will sign the user’s identity certificate. ‘The certificate must be validated up the chain of authority. In the example in the figure, the public Key of the subordinate CA validates London’s certificate. The public key of the root CA validates the subordinate CA. 434 ‘Securing Networks with Cisco ASA Advanced (SNAA) v1.0 (© 2008 Cisco Systems, IncValidity Period Brean Berctnnte Fein Ea ‘tates ‘The next step is to check the validation period. A certifi ne. The vali te is valid for a specific period of ity period (range) is set by the CA and consists of “Valid from” and “Valid to” fields. On the Cisco ASA security appliance, when you try to add a certificate, the validity range is compared against the system clock. If the system clock is not within the validity range—either too early or too late—you receive an error message. In the example, the system clock on the security appliance must be between January 23, 2008, and January 22, 2009, for the certificate to be valid. (© 2008 Cisco Systems, inc IPsec VPNs 4-35Certificate Revocation Lists ‘This topic describes the purpose of CRL: \d the protocols used for CRLs. Certificate Revocation List = Away to determine whether a certificate has been revoked by its issuing CA. * May be retrieved using: HTTP SCEP — LDAP = CRL is stored for a period of time after which it is considered “stale”. certificate is issued, it is valid for a fixed period of time. Sometimes a CA revokes a certificate before this time period expires; for example, due to security concerns or a change of me or association. CAs periodically issue a signed list of revoked certificates. Certif Revocation Lists provide the security appliance with one means of determining whether a certificate is within its valid time range or has been revoked by its issuing CA. As cert are revoked, they are published in the certificate revocation list (CRL). The CA signs the CRL, and a validity date period is embedded in the CRL. You can configure the security appliance to make CRI. checks mandatory when authenticating a certificate. The security appliance can retrieve CRLs from CAs using HTTP, Simple Certificate Enrollment Protocol (SCEP), or Lightweight Directory Access Protocol (LDAP). You can also make the CRL check optional, which allows the certificate authentication to succeed when the CA is unavailable to provide updated CRL data, CRLs retrieved for each trustpoint are cached for a length of time configurable for each trust point 436 Securing Networks with Cisco ASA Advanced (SNAA) v1.0 (© 2008 Cisco Systems, IneAll PK -participating peers should be able to access the CRL. The default behavior of the security appliance is to retrieve the certificate's CRL from the Certificate Distribution Point location, which is embedded in the presented certificate. Once a security appliance retrieves the CRL, it keeps the CRL in its cache until the CRL reaches the expiration date/time. The security appliance will retrieve the CRL again when the certificate linked with the CRL is presented. The security appliance may have several CRL in its cache simultaneously, depending on CRL granularity. While CRL checking is enabled by default, it can be disabled if certificate status is not an issue. Of course, CRL checking should be enabled when the network requires a hi degree of security. A shorter period should be set for CRL. expiration in an environment that meets these conditions: mount of certificate revocation. = There will be a significant = Itis critical that security peers in the PKI are aware of certificate revocation activity Certificate Revocation List (Cont.) * List of revoked certificates signed by the CA (es) = Stored on the CA or CRL ! distribution point | Revoked * No requirement on devices to | Cert 12345 ensure that the CRL is current Cert 12241 Cert 22333 Sa Checking the certificate revocation list (CRL) is the last validation step. A CRL is a list is rd hy the CA that contains certificates that are no longer valid. CRLs are signed by the CA and are released periodically or on demand. CRLs are valid for a specific amount of time, depending on the CA vendor used. Some reasons a certificate might be invalidated are as follows: User data changes (for example, the username), = A key is compromised, = Anemployee leaves the org ization. The CRL must be consulted by anyone using a certificate, to ensure that it is still valid. There is ho requirement on devices to ensure that the CRL is current. (© 2008 Gisco Systems, Inc. IPsec VPNs 437CRL: General Ee ijt nn ‘The figure contains an example of a CRL. The CRL has two tabs: General and Revocation List The gencral tab includes information about the CRL itself, such as the name of the CA that sued the list, the date the list was issued, and the date of the next publication. The date of the ext publication could be hourly, daily, weekly, and so on, as defined by the revocation list, which includes all the revoked certificates. The certificates are listed by certificate serial number and revocation date. CRL: Revocation Lis The figure contains an example of the CRL. The certificate serial number and revocation date and time are listed. 438 ‘Securing Networks with Cisco ASA Advanced (SNA) vi 0 (© 2008 Cisco Systems, Inc.$$ rsae A number of certificate revocation list-distribution points (CRL-DPs) are accessible from the web. Because the web is a large place, it is difficult for the security appliance to check a particular certificate to see if itis valid or revoked. As part of the identity certificate, the CRL extension includes the CRL-DP. The CRL-DP information is included in the identity certificate extension fields. If you double-click the CRL-DP icon in the certificate, the URL of the CRL- DP is included. In the example in the figure, the CRL is located at: http://asal.xyz.com/+CSCOCA+/asa_ca.crl (© 2008 Cisco Systems, Inc. IPsec VPNs 4.39Security Appliance Certificate Enrollment Support This topic provides a brief overview of the Cisco ASA security appliance certificate enrollment support. Security Appliance Enrollment Support File Network (Manual) (Automated) Certificate, ‘Server Certificate, Generate ae Generate PKCS #10 re Uploaa Download PKCS #10, For the Cisco ASA security appliance to participate in the certificate exchange, a certificate needs to be loaded on the security appliance. The security appliance supports two types of certificate enrollment: File-based enrollment: This is a manual process. You can enroll by creating a request file, PKCS #10. When you have created a request file, you can either e-mail it to the CA and receive a certificate back, or you can access the CA web site and « enrollment request in the area that the CA provides. Wh and root certificates are downloaded to the PC. The ce the security appliance. and paste the generated by the CA, identity jeates must then he ported onto = Network-based enrollment: This is an automated process that enables you to connect directly to a CA through Simple Certificate Enrollment Protocol (SCEP). Complete the enrollment form to connect to a CA through SCEP. The security appliance contacts the CA through SCEP, and the CA returns a CA certificate. When the CA certificate is verified, the security appliance uses SCEP to send the enrollment request to the CA, where the CA issues an identity certificate. The CA then retums the identity to the security appliance, For network-based enrollment to work, both the security appliance and the CA must support SCEP. ‘There will be further discussion of SCEP-based rollment later in this module. “440 Securing Networks with Cisco ASA Advanced (SNAA) v1.0 (© 2008 Cisco Systems, Inc.Security Appliance Certificate Manual Loading Process Generate $ PKCS #10 Centicate ‘Server Luss Generate the certificate request and upload Load the root Cericate paced Server Download the root and identity certificate Load identity certificate The Cisco ASA security appliance certificate manual loading process consists of the followi Generate the certificate request and upload it toa CA, m= The CA generates the identity and root certificates. Each is downloaded to a PC. ™ Both the root and identity certificates are loaded onto the secu ¥Y appliance. (© 2008 Cisco Systems, Inc. IPsec VPNs 4-81Network-Based Enrollment: SCEP Handshake a cere Device g Sever Request CA or CA Certificate Enrollment RA Certficate __ I RA Certiticate Verify CA or RA ee Certificate File-based enrollment fer-intensive process. Network-based enrollment is an automated process, which cables the Cisco ASA sccurity appliance to connect direetly toa CA. through SCEP. The SCEP operates between the security appliance and the certificate server. The certificate request process is always the same, but the approval process varies, depending upon whether the identity certificate is automatically or manually approved. The approval process varies between CAs. In a private network where the corporation owns the CA, the approval process can be set to automatie: the device makes a request, the CA approves the request, and an identity certificate is generated. If the device is making the request of a public CA, the request may be delayed pending a manual approval process. The following is the SCEP process Root Certificate Enrollment To enroll with a CA or RA, you must complete the following steps: m= Send the CA or RA certificate request to the CA m The CA returns a CA or RA certificate. m The requesting device: — Verifies the CA or RA. Identity Certificate Enrollment To retrieve an identity certificate when enrolled with a CA or RA, you must complete the following steps: m The requesting device takes the following actions: — Generates keys. — Generates the certificate request. — Sends the certificate request 10 the CA. 442 ‘Securing Networks with Cisco ASA Advanced (SNAA) vi 0 (© 2008 Cisco Systems, Incm The CA processes the request, generates an identity certificate, and returns the identity certificate to the requesting device. — Ifthe CA does not process the request, the CA places the request in a pending, (approval) file and returns the pending message to the requesting device. — If the request is still pending, the requesting device will periodically send a poll to the CA If the identity certificate is approved, the CA sends it to the requesting device, (© 2008 Cisco Systems, Inc IPsec VPNs 4.43,Key Pairs and Trustpoints This topic describes key pairs and trustpoints Key Pairs and Trustpoints and Key Pairs Each peer has a key pair containing both a public and a private key. These keys act as complements; any communication encrypted with one can be decrypted with the other. Key pairs are RSA keys. m RSA keys can be used for IPsec, Secure Sockets Layer (SSL), and Secure Shell (SSH). = SCEP enrollment supports the certification of RSA keys. = For the purposes of generating keys, the ma default size is 1024. uum key modulus for RSA keys is 2048. The = For signature operations, the supported maximum key size is 4096 bits = You can generate a general purpose RSA key pair, used for both signing and encryption, or ‘you can generate separate RSA key pairs for each purpose. Separate signing and encryption keys help reduce exposure of the keys. This is because SSL uses a key for encryption but not signing, but IKE uses a key for signing but not encryption. By using separate keys for each, exposure of the keys is minimized To configure a key pair for ac generated, jeate, you specify the labels to ide: the key pair to be 4-44 Securing Networks with Cisco ASA Advanced (SNAA) v1.0 © 2008 Cisco Systems, IncTrustpoints ‘Trustpoints let you manage and track CAs and certificates. A trustpoint is a representation of a CA or identity pair, A trustpoint contains the identity of the CA, CA-specifie configuration parameters, and an association with one enrolled identity certificate. fier you have defined a trustpoint, you can reference it by name in c CA. You can configure many trustpoints. mands that require a Note fa security appliance has multiple trustpoints that share the same CA, only one of these. trustpoints that share the CA can be used to validate user certificates. Use the support- user-cert-validation command to control the trustpoint of the shared CA that is validating user certificates that are issued by that CA, For automatic enrollment, a trustpoint must be configured with an enrollment URL and the CA that the trustpoint represents must be available on the network and must support SCEP. You can export and import the key pair and issue certificates associated with a trustpoint in PKCS 412 format. This is useful if you want to manually duplicate a trustpoint configuration on a different security appliance. (© 2008 Cisco Systems, inc sec VPNs 4.45,Summary This topic summarizes the key points that were discussed in this lesson. Summary = IPsec combines three protocols into a cohesive security framework. * IPsec operation can be summarized into a few primary steps. = PKI provides a means to authenticate peer devices and users. * A digital certificate contains information to identify a user or device. + Certificates allow scalability in very large networks. » Key pairs and trustpoints are required when configuring a security appliance for accepting and establishing VPN connections, * Certificate revocation lists provide the security appliance with one means of determining whether a certificate that is within its valid time range has been revoked by its issuing CA. = The security appliance supports several CA servers. 4-46 Securing Networks with Cisco ASA Advanced (SNAA) v1.0 (© 2008 Cisco Systems, IncLesson 2| ‘Implementing Site-to-Site VPNs with Digital Certificates Overview IP Security (IPsec) virtual private networks (VPNs) can be configured for various types of authentication, One such method is using pre-shared keys. In that case, each client shares a common key. That method is not very scalable, especially in an enterprise network. Another more scalable method would incorporate the public key infrastructure (PKI) for authentication, PKI uses digital certificates to authenticate endpoints for the VPN tunnel. This lesson guides you through the process of configuring an IPsec site-to-site VPN using di ital certificates, Objectives Upon completing this lesson, you will be able to configure the Cisco ASA adaptive security appliance to establish site-to-site tunnels, using digital certificates. This ability includes being able to meet these objectives: = Describe the components of site-to-site VPNs, = Explain the steps necessary te certificates fe the Cisco ASA security appliance to use digital = Define interesting traffic with ACLs List the steps needed to configure an ISAKMP policy for site-to-site VPNs List the steps necessary to define IPsec transform set = Explain the steps needed to configure a site-to-site VPN using digital certificates = Configure a crypto map for site-to-site VPNs = Configure the Cisco ASA security appliance for hub-and-spoke site-to-site connections = Configure site-to-site redundancy m= Use show comm: \ds to verify the configuration of site-to-site VPNs m= Use debug commands to verify that the configuration of site to site VPNs is working propeSite-to-Site VPNs This topic describes the components of site-to-site VPNs. Site-to-Site VPNs Remote Site Remote yg a Site ys" ot 7 <> ~ <> In the figure, a corporation wants to tie remote sites together by way of a VPN. Each remote site has 500 people. One option is to run a remote VPN where the VPN Client is installed on every PC. This is a logistical and administrative nightmare, The better option is to use the VPN capabilities of the security appliance. One security appliance is installed at each site, a VPN gateway, and all remote PC traffic is routed to the security appliance. The security appliances cenerypt and encapsulate the traffic, The security appliances perform all IPsec functionality. and route all interoffice VPN traffic through the Internet. This option requires that no additional software be installed on the PCs. This application is referred to as a site-to-site VPN. 1g business over a site-to-site VPN tunnel, you must “know” who is at the other wl. The VPN gateway on the other end of the VPN tunnel must be authenticated before the communications path is considered secure. The last exchange of Intemet Key Exchange (IKE) Phase 1 is used to authenticate the remote VPN gateway peer. In large networks, the use of a pre-shared key to authenticate a remote peer does not scale well. The preferred method is the exchange of digital certificates to authenticate remote peers. 448 Securing Networks with Cisco ASA Advanced (SNA) v1.0 (© 2008 Cisco Systems, Inc.CA Server Fulfilling Requests from iPsec Peers Each IPsec peer individually enrolls with the CA server With a certificate authority (CA), you do not need to configure keys between all of the encrypting IPsec peers. Instcad, you individually enroll each participating peer with the CA and request a certificate. When this has been accomplished, each participating peer can dynamically authenticate all of the other participating peers. To add a new IPsec peer to the network, you need to configure only that new peer to request a certificate from the CA, instead of making multiple key configurations with all the other existing IPsec peers. With a CA, you do not need to configure keys between all of the encrypting IPsec peers. Instead, each individual peer enrolls with the CA and requests a certificate. When this has been accomplished, the peers can exchange certificates during tunnel establishment. (© 2008 Cisco Systems, In. IPsec VPNs 4-49Peer Certificate Authentication Headquarters = S ——_—__ —| ee CI — Internet, rae bead ee Boston Branch Validate the peer identity certificate + Exchange the identity certificates during IKE negotiations * Verity the identity certificate signature via the stored root certificate. * Verity thatthe certificate validity period has not expired * Verify thatthe identity certificate has not been revoked During IKE negotiations, identity certificates are exchanged to authenticate VPN gateway peers. When an identity certificate is received from an IK! attempts to validate the peer’s certificate. In the example in the figure, the Headquarters security appliance sends its identity certificate to the Boston Branch security appliance. The Boston Branch security appliance attempts to validate the received certiticate as follows arity appliance Validate the signature. The security appliance uses the public key stored on its root certificate (the CA certificate) to decrypt the identity certificates hash. The security appliance also re-computes a hash of the received iden rypted and re-computed hashes match, the certificate is valid = Check the validity period of the certificate against the system clock of the se appliance. If the security appliance’s system clock falls within the validity period of the identity certificate, the test is successful. The validity range can be found on the identity certificate srity = (Optional.) Ifenabled, the security appliance locates the certificate revocation list (CRL) and determines if the identity certificate serial number is on the revocation list. If present, the certificate is revoked. If absent, the certificate is valid If the received identity certificate passes the validation process, the Boston Branch security appliance authenticates the Headquarters security appliance. In turn, the Boston Branch security appliance sends its identity certificate to the Headquarters security appliance. The Headquarters security appliance performs the same validation process for the Boston Branch se: appliance’s identity certificate. 4-50 Securing Networks with Cisco ASA Advanced (SNAA) v1.0 (© 2008 Cisco Systems, IncSCEP-Based Enrollment Certificate Server Public key technology is becoming more widely deployed. With the use of public key certificates in network security protocols, comes the need for a certificate management protocol that PKI clients and CA servers can use to support automated certificate enrollment. The goal of the Simple Certificate Enrollment Protocol (SCEP) is to support the secure issuance of certificates to network devices in a sealable, more streamlined manner. SCEP supports automated CA public key distribution and certificate enrollment, (SCEP is a secure messaging protocol that requires minimal user intervention.) This method is quicker and allows you to enroll and install certificates using only the security appliance, but is only available if you are enrolling both with a CA that supports SCEP and enrolling through the web. If your CA does not support SCEP or if you do not have network connectivity to your CA, then you cannot use the automatic method; you must use the manual ethod (©2008 Cisco Systems, Inc. IPsec VPNs 4.51SCEP Enrollment Process Certificate ver oe Load root certificate ee Certificate through SCEP 2) Server “4 ig g Load identity certificate through SCEP. Whether you use the automatic or the manual method, you follow the same overall certificate management procedure: Step 1 Step 2 Stop 3 Step 4 Install CA (root) certificate(s). (Optional.) Enable CRL checking, Enroll and install identity certificates. Enable digital certificates on the security appl 452 ‘Securing Networks with Cisco ASA Advanced (SNAA) v1.0 © 2008 Cisco Systems, incConfiguring CA Certificates This topic describes the steps necessary to configure the Cisco ASA security applianc request, download, and verify a CA certificate through Cisco Adaptive Secur Manager (ASDM). SCEP Handshake: CA Certificate Enrollment 2 ne aoe Baap RA certificate Verify CA or RA, certificate To participate in the digital certificate exchange, the security appliance requires two certificates. The SCEP process first enrolls with the CA and downloads aCA certificate. The security appliance performs a second procedure. A successful second exchange results in the downloading of an identity certificate. In the figure, the CA and identity certificate handshake exchange are displayed. In the next section of this lesson, only the CA certificate enrollment is discussed. (The identity certificate enrollment will be discussed later in the lesson.) The process for installing a CA certifi Step1 The security appliance sends a Get CA message to the CA Step2 The CA returns a CA certificate to the security appliance. Step3 fier the security appliance receives the CA (root) certificate, the security appliance authenticates the CA (root) certificate. The administrator ean also verify the CA (root) certificate out-of-band by comparing the root certificate hash of the security appliance with the root certificate hash registered with the CA administrator. When comparing the two hashes, they should match Note Registration authority (RA) is responsible for communicating with clients requesting certificates, RA is used to offload the enrollment process overhead from the CA and offers better security since clients have no direct access to the CA. When using SCEP, the CA will retumn both a CA and RA certificate to the security appliance, (© 2008 Cisco Systems, Inc. IPsec VPNs 4.53,CA Certificates Panel Ceeticate = = asiOe canoe pe) CA Centicates: ‘Ste 10-Ste VPN: Site-to-site VPN certificates conf Configuration>Site to Site VPN Certificate Management. Notice in the navigation pane that there are three entries under Certificate Management: = CA Certificates: Used to manage CA ce m= Identity Certificates: Used to manage identity certificates, ™ Code Signer Certificates: Special certificates used to create digital signatures to sign code, with the signed code itself revealing the certificate origin. ‘To add, edit, and display CA certificates, choose CA Certificates under the navigation pane. To the right of the navigation pane is the CA Certificates field. The CA Certificates field displays a list of the certificates available, identified by “Issued To.” “Issued By,” the date the certificate expires, and the certificate’s usage or purpose. You can click a certificate in the list and edit its configuration, or you can add a new certificate to the displayed list Step1 To add a new certificate to the list, click the Add button. The Add a Certificate window opens 454 Securing Networks with Cisco ASA Advanced (SNA) v1.0 © 2008 Cisco Systems, Inc.SCEP URL—po sas Retry Period Loe tant Rety Gount—fow sencams i — fintinanetents There are three options for installing a CA certificate, The CA Certificate pane lets you add a new certificate configuration from an existing file by manually pasting in a certificate or by SCEP automatic enrollment, Click the appropriate option to activate one of the following: ® Install from a file: To add a certificate configuration from an existing file. = Paste certificate in PEM format: For manual enrollment, copy and paste the PEM format certificate (base 64 or hexadecimal format) into the pane. m= Use SCEP: For automatic enrollment, the security appliance contacts the CA by using SCEP protocol, obtains the certificates, and installs them on the device. To add a CA cert te by using SCEP, complete the follo Ws tasks: Step2 Click the Use SCEP radio button. To use SCEP, you must enroll with a CA that supports SCEP, and you must enroll through the Internet. Step 3 In the SCEP URL: HTTP:// field, enter the path and filename of the certificate to be automatically installed. In the example, boston/certsrv/mscep/mscep dll is entered in the field where “boston” is the name of the server and “certsrv/mscep/mscep.dll” is required to access a Microsoft CA server through SCEP, step4 —_ Inthe Retry Period field, specify the maximum number of minutes to retry installing certificate, The default is one minute. Step5 In the Retry Count field, specify the number of retries for installing a cert default is 0, which indicates unlimited retries within the retry period. step 6 Click the More Options button. The Configuration Options for CA Ce! window opens. This displays configuration options for new and existing CA. certificates. (© 2008 Cisco Systems, Inc. IPsec VPNs 4.55Options for CA Certificate Revocation check Do not check Sa Check Perera RL distribution point — ~ Certificate defined ~ Static URL RL retrieval method — LDAP. SCEP HTTP Online Certificate Status Protocol (OCSP) rules Rules for obtaining a revocation list Advanced —————1 Taos OCSP and CRI options strator, additional CA certi adding a new CA certificate or modifying an existi ons are available, whether x panes are the tab- selectable displays that address certificate revocation configuration specifies. Each tabbed display is summarized in the following list: = Revocation Check: The Revocation Check pane lets you chose or reject revocation checking, specify a method of revocation checking (CRL or Online Certificate Status Protocol [OCSP)) and allows you to ignore revocation-checking errors when validating a certificate. = CRL Retrieval Policy: The CRL Retrieval Policy pane lets you configure the use of the CRL distribution point and static CRL URLs, with capabilities to add, edit, and delete status CRL URLs. = CRL Retrieval Method: The CRL Retrieval Method pane lets you chose from the following list: — Lightweight Directory Access Protocol (LDAP) icate E — Simple Cert — HTTP rollment Protocol (SCEP) ‘These three methods can be used for CRL retrieval, = OCSP Rules: OCSP is used for obtaining revocation status of an X.509 digital certificate and is an alternative to CRLs. Cisco ASA adaptive security appliance release 7.2 introduced OCSP as a certificate revocation option. m= Advanced: The Advanced pane allows you to set up CRL update parameters, OCSP parameters, and certificate acceptance and validation parameters. After configuring the options and clicking the Okay button in the Configuration Options for CA Certificate window, the Add a Certificate window opens. Click the button to start the SCEP automatic enrollment process. 1 Cortifientes 4-58 Securing Networks with Cisco ASA Advanced (SNAA) v1.0 (© 2008 Cisco Systems, IncSuccessfully Enrolled CA Certificate Jin lipoma [Jenn ome Qoeen ics During the automatic enrollment process, the security appliance contacts the CA by using the SCEP protocol, obtains the CA certificates, and then installs them on the Cisco ASA security appliance. Upon successful completion, the “CA certificate installed successfully” popup Each installed CA certificate is displayed in the CA Certificates pane. The “Issued By,” the date the certificate expires, and the window open certificates are identified by “Issued T certificate usage or purpose (© 2008 Cisco Systems, Inc. IPsec VPNs 4.57Verifying CA Certificate install Using ASDM CA certificates can be verified through command-line interface (CLI) and Cisco ASDM. ‘Through Cisco ASDM, you can view installed CA certificates. Use this Cisco ASDM procedure to verify CA certificate installation: Step1 Open the Configuration > § Certificates pane VPN > Certificate Manageme Step2 Choose CA Certificates. Step3 Click the Show Details button on the right side of the pane. Step4 From the popup CA Certificates, choose from the following CA Certificates information tabs: = General: Displays the values for type, serial number, status, usage, public key type, CRI. distribution point, the times within which the certificate is valid, and associated certificates. = Issued to: Displays the distinguished n certificate is being issued to (in X.500 f distributed directory system ne (DN) of the client or host that the iat). X.500 is an ISO standard = Issued by: Displays the DN of the CA server that issued the certificate in X.500 format. Step Click the Close button. This figure shows the newly installed CA certificate. Notice the three tabs on the certificate: General, Issued to, and Issued by. In the General tab, notice the following fields: = Type: CA = Status: Available = Valid from and to Dates: 18:12:33 May 19, 2008 to 18:20:59 May 19, 2010 4-58 Securing Networks with Cisco ASA Advanced (SNAA) v1.0 (© 2008 Cisco Systems, Inc.Verifying CA Certificate Installation Using CLI ‘You can use the show crypto ca certificates command to view the newly installed CA certificate through the CLI. This figure shows the output of the show crypto ca certificates command. Some important information displayed includes the following The status of the certificate The certificate serial number The certificate usage The public key type ‘The issuer name of the certificate The subject name of the certificate The CRL distribution points Validity dates Any associated trustpoint created on the Cisco ASA security appliance (© 2008 Cisco Systems, inc. IPsec VPNs 4.59Installing an Identity Certificate After the CA certificate is successfully installed, you can request an identity certificate from the CA SCEP: Identity Certificate Handshake Oe es ‘Server ell Relurn CA oF RA cent Venty CA ot RA Generate keys Generate cenicate f —————___j Process request request = If approved, generate ‘Send request entity certificate Store certificate ee =H pending approval Request pending Send poling request (aproved) Store certificate The first part, CA certificate enrollment, is complete, the grayed out section in the figure. A CA certificate was requested. The CA returned a CA certificate. The CA certificate was validated and stored on the security appliance. The next step is to request, download, validate, and store an identity certificate for the security appliance. The procedure for requesting an identity certificate is as follows: m= The requesting device (the Cisco ASA security appliance, in this example) takes these actions: — Generates the RSA keys — Generates the certificate request — Sends the certificate request to the CA The CA processes the request, generates an identity certificate, and returns the identity certificate to the security appliance. = If there is no approval, the CA places the request the pending message to the security appliance. a pending (approval) file and returns — The security appliance will periodically send a poll to the CA If the identity certificate is approved, the CA sends it to the security appliance This section covers how identity cert the seeurity appliance through SCEP. ‘ates are generated and transferred between a CA and 460 Securing Networks with Cisco ASA Advanced (SNAA) v1.0 © 2008 Cisco Systems, Inc.identity Certificate Top Level Navigate to the Configuration > Certificates pane to manage the vate Management > Identity jcates used in a site-to-site VPN application. An Identity Certificate is used to authenticate with remote VPN gateways peers. To the right of the navigation pane is the Identity Certificates pane. The Identity Certificate pane displays a list of the certificates available identified by “Issued to,” “Issued by,” the date that the certificate expires, and the certificate’s usage or purpose. You can click a cert configuration, or you can add a new certi identity certificates stored on the se icate in the list and edit its te to the displayed list. Currently there are no ty appliance. In the next few sections, this lesson discusses the procedure required to add an identity certificate through SCEP. To begin the process of adding a new certificate, perform the following step: Step1 Click the Add button. The Add a Certificate window opens. (© 2008 Cisco Systems, Inc. IPsec VPNs 4.61Generate Key Pair wks feo rmetron Certicate Wa ea: Key Pair F Cenincate 5 ‘Atiibutes © notes ame: fi i io E am corr oapane From the Add Identity Certificate window, an administrator can import an existing identity certificate from a file or add a new certificate configuration through SCEP. To add a new identity certificate through SCEP, the administrator needs to generate the Rivest, Shamir, and ‘Adleman (RSA) keys, add optional distinguishing attributes such as a department name, a company name, a city, and so on, and change enrollment parameters. In the Add Iden Certificate window, the following parameters are available: m= To import an identity certificate from an existing file, choose Import the identity certificate from a file and enter the following information: — Decryption Pass Phrase: Specify the pa file. phrase used to decrypt the PKCS #12 — File to Import From: You can type the pathname of the file in the box or you ca click Browse and search for the file. = To add a new identity certificate requires the following information: Key Pair: RSA key pairs are required to enroll fi ASA sceurity appliance supports multiple key pairs. Cisco identity centific Certificate Subject DN: Specify the certificate subject-name DN to form the DN in the Identity Certificate, and click the Select button to add DN attributes in the Certificate Subject DN pane. RSA key pairs are required to enroll for identity certificates. To add a new RSA key, complete the following steps: Step2 In the Add Identity Certificate pane, choose the Add a new radio button, ty certificate Step 3 Choosing the Key Pair drop-down menu, verily that an RSA key pair is resident on the security appliance. In the example, None is the value of the Key Pair field. A key pair is required before performing SCEP enrollment. 462 Securing Networks with Cisco ASA Advanced (SNAA) v1.0 (© 2008 Cisco Systems, IncStep 4 Step 5 Step 6 Step 7 Step 8 ‘To generate a key pair, click the New button. The Add Key Pair window opens, In the Name field, choose the Enter new key pair name radio button to name the new key you will be generating, From the Size drop-down menu, choose the default key pair size: 512, 788, 1024 or 2048. The default is a key size of 1024. From the Usage field, specify the key pair usage by choosing either the General purpose or Special radio button. There are two types of usage for RSA keys: general purpose (the default) and special. If you use general-purpose RSA keys, the security appliance generates one key for both signing and eneryption. When you choose Special, the Cisco ASA security appliance generates two key pairs, one for signature use and one for encryption use. Click the Generate Now button. The security app! based on your inputs. nce will generate an RSA key (©2008 Cisco Systems, Inc IPsec VPNs 4-63,Add Attributes to the Certificate Attribute 4 and extranet based. Por all intranct-based VPN tunnels, you might want to apply one policy and a different group policy for the extranet-based tunnels. You can have one policy for partners, another policy for subsidiaries, and so on, One way to differentiate between remote peer types is to parse the fields of an inbound identity certificate, You can categorize remote peers based on their certificate’s department name (OU) field, their company name (O) field, and so on. This discussion describes how to add certificate attributes to an identity certificate. The mapping of the identity certificate field and a policy is explained later in the lesson. In the Add Identity Certificate pane, the following Certificate Subject DN fields are available: = Certificate Subject DI Identity c¢ Certifi “boston! Specify the certificate subject-name DN to form the DN in the ficate, and click the Select button to add additional DN attributes in the ite Subject DN pane. In the figure, the identity certificate subject DN is set to Attribute: Choose one or more DN attributes from the drop-down 1 u, You 6 these X.500 fields of attributes for the Certificate Subject DN: CN = Common name OU = Department = Company name = Country S = State or Province — L= Location — EA = E-mail address 464 Securing Networks with Cisco ASA Advanced (SNAA) v1.0 {© 2008 Cisco Systems, Inc‘To add attributes to an idemtity certificate, perform the following steps: Step9 In the Add Identity Certificate window, click the Select button, The Certificate Subject DN window opens. Step 10 From the Attribute drop-down menu, choose the desired attribute. In the example, company name (O) was chosen, Step 11 In the Value field, enter the desired company name. In the example, Cisco was entered Step 12 After the attribute and value are entered, click the Add button to save the attribute, In the example, the company name of “Cisco” and a department of “training” are specified When the identity certificate is generated, the department and organization (company name) fields of the new identity certificate will be populated with “training” and “Cisco” respectively (© 2008 Cisco Systems, Inc. IPsecVPNs 4.85dentity Certificate: Advanced Settings ootintamin Une rar Oo tor] Ervoll URL enemas — Retry Period, o~ Retry Count (etonacr eters The last step is to conf ure the SCEP parameters for the identity certificate enrollment. The Advanced > Enrollment Mode allows you to choose either manual cnrollment (Request by ‘manual enrollment) or enrollment by CA (Request from a CA) through SCEP, which requires the following information: = Enrollment URL (SCEP): HTTP://: Enter the path- and filename of the cert ae to be automatically installed. © Retry Period: Specify the maximum number of minutes to retry stalling an Identity Certificate. The default is one minute. = Retry Coun default is 0, whie ate. The pecify the number of retries for installing an Identity Cert ndicates unlimited retries within the retry period. To add the SCEP parameters, perform the following steps: Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 In the Add Identity Certificate window, click the Advanced bution. The Advanced Uptions window opens. Choose the Enrollment Mode tab, The Enrollment Mode tab opens. Choose the Request from a CA radio button, In the Enrollment URL (SCEP): http:// field, enter the CA server SCEP address information. In the example, 10.0.2.10/certsrv/mscep/mscep.all was entered. The address of the SCEP CA server is 10.0.2.10. The Microsoft CA server information is certsrv/mscep/mscep.ll In the Retry Period field, specify the maximum number of minutes to retry installing, an Identity Certificate. The default is one minute. In the Retry Count field, specify the number of retries for installing an Identity Certificate. The default is 0, which indicates wnlimit in the retry period 466 ‘Securing Networks with Cisco ASA Advanced (SNAA) v1.0 (© 2008 Cisco Systems, Inc.Step7 Click Okay to accept the new values. The Add Identity Certificate window opens. Step8 In the Add Identity Certificate window, click the Add Certificate button to start the SCEP enrollment process. (© 2008 Cisco Systems, in. IPsec VPNs 4.67Verifying CA Certificate installation Using ASDM Ifthe SCEP enrollment process was successful, a new identity certificate should appear in the Identity Certificate pane. The example displays a newly installed identity cert Cisco ASDM. Use this Cisco ASDM procedure to verify identity certificate installation icate, using Step 1 Open the Configuration > Site-to-Site VPN > C Certificates pane. ficate Management > Identity Step 2 Choose Identity Certificates, Step3 Click the Show Details button on the right side of the pane. An Identity Certificate popup opens. From the top of the Identity Certificate, choose from the following tabs: = General: Displays the values for type, serial number, status, usage, public hey type, CRI. distribution point, the times within which the certificate is valid, and associated certificates. m Issued t0: Displays the distinguished name (DN) of the client or centificate is being issued to (in X.500 format). yost that the = Issued by: Displays the DN of the CA server that issued the certificate in X.500 format Step4 Click the Close button. 4-68 Securing Networks with Cisco ASA Advanced (SNAA) v1.0 (© 2008 Cisco Systems, Inc.Verifying ID Certificate Installation Using cui Toston show Gaye Ga GnneTtTOnn cartiticate certificate General Furpone Public Key Type: REA (1024 Bits) oustraintinis Thoaton onus (1) heep://boston/certsnco}t /bostons20ea.er1 {2} €4ie://\\borton\Cort Enroll \bostont20ce.or1 fend dates 20:49:21 897 Mar 20 2005 You can also use the show erypto ca certificates CLI command to view the newly installed Identity Certificate. This figure shows the identity certificate returned by the CA server This figure shows the output of the show crypto ca certificates command. Some important information displayed includes the following: m= The status of the certificate = The certificate serial number = The certificate usage The public key type ® = The issuer name of the certificate = The subject name of the certificate = CRL distribution points = Any associated trusty created on the Cisco ASA security appliance (© 2008 Cisco Systems, Inc. IPsec VPNs 4.69,Site-to-Site IPsec Connection Profiles This topic describes how to confi, site-to-site VPN tunnel, using a connection profile. Connection Profiles: Getting Started Ge. — |Psec access interface Connection After the CA certificate and identity cert site VPN tunnel can be configured. Thet {es are stored on the security appliance, the site-to- 'e are three basic ways to add a site-to-site IPsec VPN tunnel. You can use the IPsec VPN Wizard to add a site-to-site VPN. You can use the Site-to- Site VPN > Advanced menus to add or modify a site-to-site VPN configur the Site-to-Site VPN > Connection Profiles menus to add or modify a site-to-site VPN. This section discusses how to configure a site-to-site tunnel using the connection profiles. button in the Cisco ‘The Site-to-Site menus To access the Site-to-Site VPN navigation pane, click the Configurati ASDM toolbar and choose Site-to-Site VPN from the navigation pat contain the following options: = Connection Profiles: Enables you to add, edit, xl delete connection profiles. Policies: Enables you to manage VPN group policies. = Certificate Management: Enables you to manage digital certificates, ™ Advanced: Enables you to access the following configuration panes: — Tunnel Groups: Enables you to add, edit, and delete tunnel groups. — Crypto Maps: Enables you to add, edit, and delete erypto maps. In addition to configuring basic and required crypto map parameters, you can configure optional settings such as Reverse Route Injection (RD), which can improve the reliability nd performance of your site-to-site VPN by enabling the security appliance to learn routing information for connected clients. You can also enable Network Address Translation Transparency (NAT-T), which enables IPsec peers to establish connection through a NAT device. — _ IKE Policies: Enables you to add, edit, and delete IKE policies. 470 Securing Networks with Cisco ASA Advanced (SNA) v1.0 (© 2008 Cisco Systems, Inc