Cisco – IPSec

IPsec is an IETF standard (RFC 2401-2412) that defines how a VPN can be configured using the IP addressing protocol. IPsec is not bound to any specific encryption,

authentication, security algorithms, or keying technology. IPsec is a framework of open standards that spells out the rules for secure communications. IPsec relies on

existing algorithms to implement the encryption, authentication, and key exchange. ! ! IPsec provides the framework, and the administrator chooses the algorithms that are used to implement the security services within that framework. By not binding IPsec

to specific algorithms, it allows newer and better algorithms to be implemented without patching the existing IPsec standards. ! There are two common HMAC algorithms: !!!! HMAC-Message Digest 5 (HMAC-MD5) – Uses a 128-bit shared-secret key. The variable-length message and 128-bit shared secret key are combined and run through the HMAC-

MD5 hash algorithm. The output is a 128-bit hash. HMAC-Secure Hash Algorithm 1 (HMAC-SHA-1) – Uses a 160-bit secret key. The variable-length message and the 160-bit shared secret key are combined and run through the

HMAC-SHA-1 hash algorithm. The output is a 160-bit hash. ! At the local device, the authentication key and the identity information (device-specific information) are sent through a Hash algorithm to form Hash_L. One-way

authentication is established by sending Hash_L to the remote device. If the remote device can independently create the same Hash, the local device is authenticated.

The authentication process continues by repeating these steps in the reverse direction. ! At the local device, the authentication key and identity information (device-specific information) are sent through the Hash algorithm forming Hash_L. Hash_L is

encrypted using the local device’s private encryption key creating a digital signature. The digital signature and a digital certificate are forwarded to the remote

device. The public encryption key for decrypting the signature is included in the digital certificate. The remote device verifies the digital signature by decrypting

it using the public encryption key. The result is Hash_L. Next, the remote device independently creates a hash from stored information. If the calculated hash equals

the decrypted Hash_L, the local device is authenticated. After the remote device authenticates the local device, the authentication process begins in the opposite

direction and all steps are repeated from the remote device to the local device. ! There are several DH groups: !!!! DH groups 1, 2, and 5 support exponentiation over a prime modulus with a key size of 768 bits, 1024 bits, and 1536 bits, respectively. These groups are not recommended

for use after 2012. DH groups 14, 15, and 16 use larger key sizes with 2048 bits, 3072 bits, and 4096 bits, respectively, and are recommend for use until 2030. DH groups 19, 20 and 24 support Elliptical Curve Cryptography (ECC), which reduces the time needed to generate keys. With respective key sizes 256 bits, 384 bits, and

2048 bits. DH group 24 is preferred for longevity of use. Newer Cisco IOS versions support more advanced DH groups. !  The two main IPsec framework protocols are AH and ESP. The IPsec protocol is the first building block of the framework. The choice of AH or ESP establishes which

other building blocks are available: ! Authentication Header (AH) – AH, which is IP protocol 51, is the appropriate protocol to use when confidentiality is not required or permitted. ! Encapsulating Security Payload (ESP) – ESP, which is IP protocol 50, can provide confidentiality and authentication. It provides confidentiality by performing

encryption on the IP packet. IP packet encryption conceals the data payload and the identities of the ultimate source and destination. !  Although both encryption and authentication are optional in ESP, at a minimum, one of them must be selected. ! ESP provides the following: Encryption Authentication Integrity ! ! AH provides the following: Authentication Integrity ! The AH function is applied to the entire packet, except for any mutable IP header fields that change in transit. For example, Time to Live (TTL) fields that are

modified by the routers along the transmission path are mutable fields. ! AH supports the HMAC-MD5 and HMAC-SHA-1 algorithms. AH can have problems if the environment uses NAT. ! ESP can also provide integrity and authentication. First, the payload is encrypted. Next, the encrypted payload is sent through a hash algorithm, HMAC-MD5 or HMAC-

SHA-1. The hash provides authentication and data integrity for the data payload. ! Optionally, ESP can also enforce anti-replay protection. Anti-replay protection verifies that each packet is unique and is not duplicated. This protection ensures that

a hacker cannot intercept packets and insert changed packets into the data stream. Anti-replay works by keeping track of packet sequence numbers and using a sliding

window on the destination end. ! Anti-replay is typically used in ESP, but it is also supported in AH. ! ESP and AH can be applied to IP packets in two different modes, transport mode and tunnel mode. ! In transport mode, security is provided only for the Transport Layer of the OSI model and above. Transport mode protects the payload of the packet but leaves the

original IP address in plaintext. The original IP address is used to route the packet through the Internet. ! ESP transport mode is used between hosts. Transport mode works well with GRE, because GRE hides the addresses of the end devices by adding its own IP. ! Tunnel mode provides security for the complete original IP packet. The original IP packet is encrypted and then it is encapsulated in another IP packet. This is known

as IP-in-IP encryption. The IP address on the outside IP packet is used to route the packet through the Internet. ! ESP tunnel mode is used between a host and a security gateway or between two security gateways. For gateway-to-gateway applications, rather than load IPsec on all of

the computers at the remote and corporate offices, it is easier to have the security gateways perform the IP-in-IP encryption and encapsulation. ! The IPsec VPN solution negotiates key exchange parameters, establishes a shared key, authenticates the peer, and negotiates the encryption parameters. The negotiated

parameters between two devices are known as a security association (SA). ! DH is used to create the shared secret key. However, IPsec uses the Internet Key Exchange (IKE) protocol to establish the key exchange process. ! IKE is layered on UDP and uses UDP port 500 to exchange IKE information between the security gateways. UDP port 500 packets must be permitted on any IP interface

involved in connecting a security gateway peer. ! IKE is defined in RFC 2409. It is a hybrid protocol, combining the Internet Security Association and Key Management Protocol (ISAKMP) and the Oakley and Skeme key

exchange methods. ISAKMP defines the message format, the mechanics of a key-exchange protocol, and the negotiation process to build an SA for IPsec. ISAKMP does not

define how keys are managed or shared between the two IPsec peers. Oakley and Skeme have five defined key groups. Of these groups, Cisco routers support Group 1 (768-

bit key), Group 2 (1024-bit key), and Group 5 (1536-bit key). ! Each peer must have identical ISAKMP and IPsec parameters to establish an operational and secure VPN. Note that the terms ISAKMP and IKE are commonly used by industry

people to refer to IKE. ! An alternative to using IKE is to manually configure all parameters required to establish a secure IPsec connection. This process is impractical because it does not

scale. !  The basic purpose of Phase 1 is to negotiate IKE policy sets, authenticate the peers, and set up a secure channel between the peers. It can be implemented in main

mode (longer, initial contact) or aggressive mode (after initial contact). ! ! SAs are negotiated by the IKE process ISAKMP on behalf of IPsec. It can be negotiated in quick mode. ! In Phase 1, the transform sets, hash methods, and other parameters are determined. !  PFS is a property that states that keys used to protect data are not used to derive any other keys. PFS ensures that if one key is compromised, previous and

subsequent keys remain secure. ! Policy set numbers are only locally significant to a VPN device. The policy set numbers do not have to match between two VPN peers. In a point-to-point application,

each end might need only a single IKE policy set to be defined. In a hub-and-spoke environment, the central site might require multiple IKE policy sets to satisfy all

the remote peers. !!!!! The first exchange between the initiator and the responder establishes the basic security policy. The second exchange creates and exchanges the DH public keys between the two endpoints. The last exchange of IKE Phase 1 authenticates the remote peer. !!!!! ! The purpose of IKE Phase 2 is to negotiate the IPsec security parameters that will be used to secure the IPsec tunnel. ! Quick mode negotiates the IKE Phase 2 SAs. In this phase, the SAs that IPsec uses are unidirectional; therefore, a separate key exchange is required for each data

flow. !

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s