IPSec and vpn

Presented by : Abdullaziz TagawyCourse : Computer Security 1March / 2016

ResourcesMaterialsIPSec Tutorial by Scott Cleven-MulcahyItem (paper is taken from the GIAC directory of certified professionals)IPSecAn Overview; (Presented by Somesh Jha) University of Wisconsin.The Cryptography of the IPSec and IKE Protocols; (presented by Hugo Krawczyk), Technion & IBM Research. INTERNET KEY EXCHANGE PROTOCOL ; (Presented by PRATEEK SINGH BAPNA).IP Security (IPSec); (Presented by Thomas Lee ), Chief Technologist QA .Technical Development Program - VPN basics (Presented by Martn Bratina) 2014 AT&T Intellectual Property.Book(s)Cryptography and Network Security Principles and Practice 6th Ed (William Stallings)Cryptography and Network Security by Forouzan (2007)Google searchhttp://www.slideshare.net

2

Beginning course details and/or books/materials needed for a class/project.

IPSec ContentsIP Security OverviewApplications of IpsecBenefits of IpsecIPsec DocumentsIPsec ServicesTransport and Tunnel ModesIP Security PolicySecurity AssociationsSecurity Association DatabaseSecurity Policy DatabaseIP Traffic Processing

3

IPSec ContentsEncapsulating Security PayloadESP FormatEncryption and Authentication AlgorithmsPaddingAnti-Replay ServiceTransport and Tunnel Modes

Combining Security AssociationsAuthentication Plus ConfidentialityBasic Combinations of Security Associations

4

IPSec ContentsInternet Key ExchangeKey Determination ProtocolHeader and Payload FormatsAll TogetherVPNWhat is a VPN?Types of VPNs.Commonly used VPNsIPSec VPN Benefits

5

IP Security OverviewIPsec provides the capability to secure communications across a LAN, across private and public WANs, and across the Internet. Examples of its use include:Secure branch office connectivity over the InternetSecure remote access over the InternetEstablishing extranet and intranet connectivity with partnersEnhancing electronic commerce security

Applications of Ipsec:-6

IP Security OverviewSome of the benefits of IPsec:-When IPsec is implemented in a firewall or router, it provides strong security that can be applied to all traffic crossing the perimeter.IPsec in a firewall is resistant to bypass.IPsec is below the transport layer (TCP, UDP) and so is transparent to applications.IPsec can be transparent to end users.IPsec can provide security for individual users if needed.Benefits of Ipsec:-7

IP Security OverviewIPsec encompasses three functional areas: authentication, confidentiality, key management.The latest version of the IPsec document roadmap, which as of this writing is RFC 6071.The documents can be categorized into the following groups: Architecture: Covers the general concepts, security requirements, definitions, and mechanisms defining IPsec technology RFC 4301[Security Architecture for the Internet Protocol.].Authentication Header (AH):RFC 4302[IP Authentication Header] Note that the use of AH is deprecated. It is included in IPsecv3 for backward compatibility but should not be used in new applications.Encapsulating Security Payload (ESP):The current specification is RFC 4303, [IP Encapsulating Security Payload (ESP)].

IPsec Documents:-8

IP Security OverviewIPsec encompasses three functional areas: authentication, confidentiality, key management.The latest version of the IPsec document roadmap, which as of this writing is RFC 6071.The documents can be categorized into the following groups: Internet Key Exchange (IKE): RFC 5996, [Internet Key Exchange (IKEv2) Protocol], but there are a number of related RFCs.Cryptographic algorithms: This category encompasses a large set of documents that define and describe cryptographic algorithms for encryption, message authentication, pseudorandom functions (PRFs), and cryptographic key exchange.Other: There are a variety of other IPsec-related RFCs, including those dealingwith security policy and management information base (MIB) contentIPsec Documents:-9

IP Security OverviewIPsec provides security services at the IP layer (AH , ESP) by enabling a system to select required security protocols, determine the algorithm(s) to use for the service(s), and put in place any cryptographic keys required to provide the requested services.Access controlConnectionless integrityData origin authenticationRejection of replayed packets (a form of partial sequence integrity)Confidentiality (encryption)Limited traffic flow confidentialityIPsec Services:-10

IP Security OverviewAccess ControlIPSec provides access control indirectly, using a Security Association Database (SAD), When a packet arrives at a destination and there is no Security Association already established for this packet, the packet is discarded.Message IntegrityA digest of data is created and sent by the sender to be checked by the receiver.Entity AuthenticationThe Security Association and the keyed-hash digest of the data sent by the sender authenticate the sender of the data

IPsec Services:-

11

IP Security OverviewIPsec Services:-

12

IP Security OverviewBoth AH and ESP support two modes of use: transport and tunnel mode.Transport and Tunnel Modes:-

13

IP Security OverviewIPSec in transport mode does not protect the IP header; it only protects the payload coming from the transport layer.IPSec in tunnel mode protects the original IP header.Transport and Tunnel Modes:-Transport ModeTransport and Tunnel Modes:-Tunnel Mode14

IP Security OverviewTransport and Tunnel Modes:-Transport ModeTransport and Tunnel Modes:-Tunnel Mode

15

IP Security OverviewTransport mode is normally used when we need host-to-host (end-to-end) protection of data. The sending host uses IPSec to authenticate and/or encrypt the payload delivered from the transport layer. The receiving host uses IPSec to check the authentication and/or decrypt the IP packet and deliver it to the transport layer.The new IP header, has different information than the original IP header.Tunnel mode is normally used between two routers, between a host and a router, or between a router and a host.The entire original packet is protected from intrusion between the sender and the receiver, as if the whole packet goes through an imaginary tunnel.Transport and Tunnel Modes:-Transport ModeTransport and Tunnel Modes:-Tunnel Mode16

IP Security OverviewTransport and Tunnel Modes:-Transport ModeTransport and Tunnel Modes:-Tunnel Mode

17

IP Security OverviewThe IPSec layer comes between the transport layer and the network layer.The flow is from the network layer to the IPSec layer and then back to the network layer again.Transport and Tunnel Modes:-Transport ModeTransport and Tunnel Modes:-Tunnel Mode

18

IP Security PolicySecurity Policy (SP): This is important aspect of IPSec which defines the type of security applied to a packet when it is to be sent or when it has arrived.IPsec policy is determined primarily by the interaction of two databases, the security association database (SAD) and the security policy database (SPD).19

IP Security Policy

20

IP Security PolicyIt is a key concept that appears in both the authentication and confidentiality mechanisms for IP.It is a contract between two parties; it creates a secure channel between them.Alice needs to unidirectionally communicate with Bob.If they are interested only in the confidentiality aspect of security, they can get a shared secret key between themselves.That is mean there are two SAs between Alice and Bob; one outbound SA and one inbound SA.Security Associations:-Idea of Security Association21

IP Security PolicyThe Security Association can be more involved if the two parties need message integrity and authentication.It needs other data such as the algorithm for message integrity, the key, and other parameters.It can be much more complex if the parties need to use specific algorithms and specific parameters for different protocols, such as IPSec AH or IPSec ESP.Each of them stores the value of the key in one variable and the name of the encryption/ decryption algorithm in another.Alice uses the algorithm and the key to encrypt a message to Bob; Bob uses the algorithm and the key when he needs to decrypt the message received from Alice.Security Associations:-Idea of Security Association (con..)

22

IP Security PolicyA security association is uniquely identified by three parameters.Security Parameters Index (SPI): A 32-bit unsigned integer assigned to this SA and having local significance only. The SPI is carried in AH and ESP headers to enable the receiving system to select the SA under which a received packet will be processed.IP Destination Address: This is the address of the destination endpoint of the SA, which may be an end-user system or a network system such as a firewall or router.

Security Protocol Identifier: This field from the outer IP header indicates whether the association is an AH or ESP security association.Security Associations:-23

IP Security PolicyWe need a set of SAs that can be collected into a database.We need a set of SAs that can be collected into a database.The database can be thought of as a two-dimensional table with each row defining a single SA.There are two SADs, one inbound and one outboundSecurity Association Database:-24

IP Security PolicySecurity Parameter Index: A 32-bit value selected by the receiving end of an SA to uniquely identify the SA. In an SAD entry for an outbound SA, the SPI is used to construct the packets AH or ESP header. In an SAD entry for an inbound SA, the SPI is used to map traffic to the appropriate SA. Sequence Number Counter: A 32-bit value used to generate the Sequence Number field in AH or ESP headers, (required for all implementations). Sequence Counter Overflow: A flag indicating whether overflow of the Sequence Number Counter should generate an auditable event and prevent further transmission of packets on this SA (required for all implementations).Security Association Database:-

25

IP Security PolicyAnti-Replay Window: Used to determine whether an inbound AH or ESP packet is a replay, (required for all implementations). AH Information: Authentication algorithm, keys, key lifetimes, and related parameters being used with AH (required for AH implementations). ESP Information: Encryption and authentication algorithm, keys, initialization values, key lifetimes, and related parameters being used with ESP (required for ESP implementations).Security Association Database:-

26

IP Security PolicyLifetime of this Security Association: A time interval or byte count after which an SA must be replaced with a new SA (and new SPI) or terminated, plus an indication of which of these actions should occur (required for all implementations). IPsec Protocol Mode: Tunnel, transport, or wildcard. Path MTU: Any observed path maximum transmission unit (maximum size of a packet that can be transmitted without fragmentation) and aging variables (required for all implementations).Security Association Database:-

27

IP Security PolicyWhen a host needs to send a packet that must carry an IPSec header, the host needs to find the corresponding entry in the outbound SAD to find the information for applying security to the packet.when a host receives a packet that carries an IPSec header, the host needs to find the corresponding entry in the inbound SAD to find the information for checking the security of the packet.Security Association Database:-

28

IP Security PolicyEach entry in an inbound SAD is selected using a triple index:Security parameter index (a 32-bit number that defines the SA at the destination). Destination address.Protocol (AH or ESP).Security Association Database:-

29

IP Security PolicyThe means by which IP traffic is related to specific SAs (or no SA in the case of traffic allowed to bypass IPsec) is the nominal Security Policy Database (SPD).its simplest form, an SPD contains entries, each of which defines a subset of IP traffic and points to an SA for that traffic.In more complex environments, there may be multiple entries that potentially relate to a single SA or multiple SAs associated with a single SPD entry.Each SPD entry is defined by a set of IP and upper-layer protocol field values, called selectors.These selectors are used to filter outgoing traffic in order to map it into a particular SA.Security Policy Database:-30

IP Security PolicyOutbound processing obeys the following general sequence for each IP packet:

Compare the values of the appropriate fields in the packet (the selector fields) against the SPD to find a matching SPD entry, which will point to zero or more SAs.Determine the SA if any for this packet and its associated SPI.Do the required IPsec processing (i.e., AH or ESP processing).Security Policy Database:-31

IP Security PolicyThe following selectors determine an SPD entry:Remote IP Address: This may be a single IP address, an enumerated list or range of addresses, or a wildcard (mask) address. The latter two are required to support more than one destination system sharing the same SA (e.g., behind a firewall).Local IP Address: This may be a single IP address, an enumerated list or range of addresses, or a wildcard (mask) address. The latter two are required to support more than one source system sharing the same SA (e.g., behind a firewall).Next Layer Protocol: The IP protocol header (IPv4, IPv6, or IPv6 Extension) includes a field (Protocol for IPv4, Next Header for IPv6 or IPv6 Extension) that designates the protocol operating over IP. This is an individual protocol number, ANY, or for IPv6 only, OPAQUE. If AH or ESP is used, then this IP protocol header immediately precedes the AH or ESP header in the packet.Name: A user identifier from the operating system. This is not a field in the IP or upper-layer headers but is available if IPsec is running on the same operating system as the user.Local and Remote Ports: These may be individual TCP or UDP port values, an enumerated list of ports, or a wildcard port.Security Policy Database:-32

IP Security PolicySecurity Policy Database:-

33

IP Security PolicyIPsec is executed on a packet-by-packet basis.Each outbound IP packet is processed by the IPsec logic before transmission.Each inbound packet is processed by the IPsec logic after reception and before passing the packet contents on to the next higher layer

IP Traffic Processing:-34

IP Security PolicyOutbound Packets:-

35

IP Security PolicyInbound Packets:-

36

IP Security Policy37SPD and SADB ExampleFromToProtocolPortPolicyABAnyAnyAH[HMAC-MD5]

Tunnel Mode

Transport ModeCAs SPDFromToProtocolSPISA RecordABAH12HMAC-MD5 key

As SADBFromToProtocolPortPolicyTunnel DestAnyAnyESP[3DES]D

Cs SPDFromToProtocolSPISA RecordESP143DES key

Cs SADB

DAB

Authentication Header (AH)It is designed to authenticate the source host and to ensure the integrity of the payload carried in the IP packet.The protocol uses a hash function and a symmetric (secret) key to create a message digest; the digest is inserted in the authentication header.The AH is then placed in the appropriate location, based on the mode (transport or tunnel).38

Authentication Header (AH)

39

Authentication Header (AH)

Authentication DataSequence NumberSecurity Parameters Index (SPI)

Nextheader

Payloadlength

Reserved

Old IP header (only in Tunnel mode)TCP header

New IP headerAuthenticatedData

EncapsulatedTCP or IP packet

Hash of everythingelse40

Authentication Header (AH)Before applying AH

41

Authentication Header (AH)Transport Mode (AH Authentication)Tunnel Mode (AH Authentication)

42

Authentication Header (AH)

43

Encapsulating Security Payload(ESP)ESP can be used to provide :ConfidentialityData origin authentication connectionless integrityAn anti-replay service (a form of partial sequence integrity) And (limited) traffic flow confidentiality.44

Encapsulating Security Payload(ESP)Can optionally provide the same authentication services as AHSupports range of ciphers, modes, padding:incl. DES, Triple-DES, RC5, IDEA, CAST etcCBC & other modesPadding needed to fill block size, fields, for traffic flow.

45

Encapsulating Security Payload(ESP)ESP adds a header and trailer.Note that ESPs authentication data are added at the end of the packet, which makes its calculation easier.

46

Encapsulating Security Payload(ESP)Security Parameters Index (32 bits): Identifies a security association.Sequence Number (32 bits): A monotonically increasing counter value; this provides an anti-replay function, as discussed for AH.Payload Data (variable): This is a transport-level segment (transport mode) or IP packet (tunnel mode) that is protected by encryption.Padding (0255 bytes): Pad Length (8 bits): Indicates the number of pad bytes immediately preceding this field.Next Header (8 bits): Identifies the type of data contained in the payload data field by identifying the first header in that payload (e.g., an extension header in IPv6, or an upper-layer protocol such as TCP).Integrity Check Value (variable): A variable-length field (must be an integral number of 32-bit words) that contains the Integrity Check Value computed over the ESP packet minus the Authentication Data field.ESP Format:-

47

Encapsulating Security Payload(ESP)Two additional fields may be present in the payload:An initialization value (IV): or nonce, is present if this is required by the encryption or authenticated encryption algorithm used for ESP.Traffic flow confidentiality (TFC) : The IPsec implementation may add padding after the Payload Data and before the Padding fieldESP Format:-

48

Encapsulating Security Payload(ESP)The Payload Data, Padding, Pad Length, and Next Header fields are encrypted by the ESP service.If the algorithm used to encrypt the payload requires cryptographic synchronization data, such as an initialization vector (IV), then these data may be carried explicitly at the beginning of the Payload Data field.If included, an IV is usually not encrypted, although it is often referred to as being part of the ciphertext.

Encryption and Authentication Algorithms:-If included, an IV is usually not encrypted, although it is often referred to as being part of the ciphertext.The ICV field is optional.The ICV is present only if the integrity service is selected .The ICV is provided by either a separate integrity algorithm or a combined mode algorithm that uses an ICVThe ICV is computed after the encryption is performed.49

Encapsulating Security Payload(ESP)The Padding field serves several purposes:If an encryption algorithm requires the plaintext to be a multiple of some number of bytes (e.g., the multiple of a single block for a block cipher), the Padding field is used to expand the plaintext (consisting of the Payload Data, Padding, Pad Length, and Next Header fields) to the required length.Padding:-The ESP format requires that the Pad Length and Next Header fields be right aligned within a 32-bit word. Equivalently, the ciphertext must be an integer multiple of 32 bits. The Padding field is used to assure this alignment.Additional padding may be added to provide partial traffic-flow confidentiality by concealing the actual length of the payload.50

Encapsulating Security Payload(ESP)A replay attack is one in which an attacker obtains a copy of an authenticated packet and later transmits it to the intended destination. The receipt of duplicate, authenticated IP packets may disrupt service in some way or may have some other undesired consequence.The Sequence Number field is designed to thwart such attacks.Anti-Replay Service:-

51

Encapsulating Security Payload(ESP)Anti-Replay Service:-

52

Encapsulating Security Payload(ESP)Anti-Replay Service:-

53

Encapsulating Security Payload(ESP)Transport-level security:

A virtual private network via tunnel mode:

Transport and Tunnel Modes:-

54

Figures shows two ways in which the IPsec ESP service can be used. In theleft part of the figure, encryption (and optionally authentication) is provided directlybetween two hosts. The right Figure shows how tunnel mode operation can beused to set up a virtual private network. In this example, an organization has fourprivate networks interconnected across the Internet. Hosts on the internal networksuse the Internet for transport of data but do not interact with other Internet-basedhosts. By terminating the tunnels at the security gateway to each internal network,the configuration allows the hosts to avoid implementing the security capability.The former technique is supported by a transport mode SA, while the latter techniqueuses a tunnel mode SA.

Encapsulating Security Payload(ESP)Transport Mode ESP :-

55

Transport mode ESP is used to encrypt and optionally authenticatethe data carried by IP (e.g., a TCP segment), as shown in Figure 20.8b.For this mode using IPv4, the ESP header is inserted into the IP packet immediatelyprior to the transport-layer header (e.g., TCP, UDP, ICMP), and an ESPtrailer (Padding, Pad Length, and Next Header fields) is placed after the IP packet.If authentication is selected, the ESP Authentication Data field is added after theESP trailer. The entire transport-level segment plus the ESP trailer are encrypted.Authentication covers all of the ciphertext plus the ESP header.In the context of IPv6, ESP is viewed as an end-to-end payload; that is, it isnot examined or processed by intermediate routers. Therefore, the ESP header appearsafter the IPv6 base header and the hop-by-hop, routing, and fragment extensionheaders. The destination options extension header could appear before or afterthe ESP header, depending on the semantics desired. For IPv6, encryption coversthe entire transport-level segment plus the ESP trailer plus the destination optionsextension header if it occurs after the ESP header. Again, authentication covers theciphertext plus the ESP header.

Encapsulating Security Payload(ESP)Transport Mode ESP :-Operation :At the source, the block of data consisting of the ESP trailer plus the entire transport-layer segment is encrypted and the plaintext of this block is replaced with its ciphertext to form the IP packet for transmission. Authentication is added if this option is selected.The packet is then routed to the destination. Each intermediate router needs to examine and process the IP header plus any plaintext IP extension headers but does not need to examine the ciphertext.The destination node examines and processes the IP header plus any plaintext IP extension headers. Then, on the basis of the SPI in the ESP header, the destination node decrypts the remainder of the packet to recover the plaintext transport-layer segment.56

Encapsulating Security Payload(ESP)Transport Mode ESP :-Operation :

57

Encapsulating Security Payload(ESP)Tunnel Mode ESP:-

58

Tunnel mode ESP is used to encrypt an entire IP packet(Figure 20.8c). For this mode, the ESP header is prefixed to the packet and then thepacket plus the ESP trailer is encrypted. This method can be used to counter trafficanalysis.Because the IP header contains the destination address and possibly sourcerouting directives and hop-by-hop option information, it is not possible simply totransmit the encrypted IP packet prefixed by the ESP header. Intermediate routerswould be unable to process such a packet. Therefore, it is necessary to encapsulatethe entire block (ESP header plus ciphertext plus Authentication Data, if present)with a new IP header that will contain sufficient information for routing but not fortraffic analysis.Whereas the transport mode is suitable for protecting connections betweenhosts that support the ESP feature, the tunnel mode is useful in a configuration thatincludes a firewall or other sort of security gateway that protects a trusted networkfrom external networks. In this latter case, encryption occurs only between an externalhost and the security gateway or between two security gateways. This relieveshosts on the internal network of the processing burden of encryption and simplifiesthe key distribution task by reducing the number of needed keys. Further, it thwartstraffic analysis based on ultimate destination.

Encapsulating Security Payload(ESP)Tunnel Mode ESP:-OperationThe source prepares an inner IP packet with a destination address of the target internal host. This packet is prefixed by an ESP header; then the packet and ESP trailer are encrypted and Authentication Data may be added. The resulting block is encapsulated with a new IP header (base header plus optional extensions such as routing and hop-by-hop options for IPv6) whose destination address is the firewall; this forms the outer IP packet.The outer packet is routed to the destination firewall. Each intermediate router needs to examine and process the outer IP header plus any outer IP extension headers but does not need to examine the ciphertext.59

Consider a case in which an external host wishes to communicate with a hoston an internal network protected by a firewall, and in which ESP is implementedin the external host and the firewalls. The upper steps occur for transfer of atransport-layer segment from the external host to the internal host.

Encapsulating Security Payload(ESP)Tunnel Mode ESP:-Operation

The destination firewall examines and processes the outer IP header plus any outer IP extension headers. Then, on the basis of the SPI in the ESP header, the destination node decrypts the remainder of the packet to recover the plaintext inner IP packet. This packet is then transmitted in the internal network.The inner packet is routed through zero or more routers in the internal network to the destination host.60

Consider a case in which an external host wishes to communicate with a hoston an internal network protected by a firewall, and in which ESP is implementedin the external host and the firewalls. The upper steps occur for transfer of atransport-layer segment from the external host to the internal host.

Encapsulating Security Payload(ESP)Tunnel Mode ESP:-Operation

61

Encapsulating Security Payload(ESP)Tunnel Mode ESP:-Transport Mode ESP :-Tunnel mode encrypts entire IP packetAdd new header for next hopGood for VPNs, gateway to gateway security

Transport mode is used to encrypt & optionally authenticate IP dataData protected but header left in clearCan do traffic analysis but is efficientGood for ESP host to host traffic

62

Combining Security AssociationsSAs can implement either AH or ESPTo implement both need to combine SAsForm a security association bundleMay terminate at different or same endpointsCombined byTransport adjacencyIterated tunnelingIssue of authentication & encryption order 63

An individual SA can implement either the AH or ESP protocol but not both. Sometimes a particular traffic flow will call for the services provided by both AH and ESP. Further, a particular traffic flow may require IPSec services between hosts and ,for that same flow, separate services between security gateways, such as firewalls. In all of these cases, multiple SAs must be employed for the same traffic flow to achieve the desired IPSec services. The term security association bundle refers to a sequence of SAs through which traffic must be processed to provide a desired set of IPSec services. The SAs in a bundle may terminate at different endpoints or at the same endpoints. Security associations may be combined into bundles in two ways: Transport adjacency: more than one security protocol on same IP packet, without invoking tunneling Iterated tunneling: application of multiple layers of security protocols effected through IP tunnelingOne interesting issue is the order in which authentication and encryption may be applied between a given pair of endpoints.

Combining Security Associations

64

The IPSec Architecture document lists four examples of combinations of SAs that must be supported by compliant IPSec hosts or security gateways. These are illustrated in Stallings Figure 16.10. Note the *d devices implement IPSec. The cases are:Case 1 security is provided between end systems that implement IPSec.Case 2 security is provided only between gateways (routers,firewalls,etc.) and no hosts implement IPSec.Case 3 builds on Case 2 by adding end-to-end security .The same combinations discussed for cases 1 and 2 are allowed here.Case 4 provides support for a remote host that uses the Internet to reach an organizations firewall and then to gain access to some server or workstation behind the firewall. Only tunnel mode is required between the remote host and the firewall.

Internet Key Exchange65

Internet Key ExchangeUsed for Key Management in IPSec Networks.The IPsec Architecture supports two types of key management:Manual: A system administrator manually configures each system with its own keys and with the keys of other communicating systems. This is practical for small, relatively static environments.Automated: An automated system enables the on-demand creation of keys for SAs and facilitates the use of keys in a large distributed system with an evolving configuration. The default automated key management protocol for IPsec is referred to as ISAKMP/Oakley

66Overview :

Internet Key ExchangeCreates SAs for use by IPSec.Negotiates security parameters for the SAKey Exchange: share keys between partiesManages SAs: create, refresh, maintain, delete.IKEv1 (1998): ISAKMP for management.Oakley is a key exchange protocol.IKEv2 (2003): IKE specifies it all

67Overview :

Internet Key ExchangeOakley Key Determination Protocol: Oakley is a key exchange protocol based on the Diffie-Hellman algorithm but providing added security. Oakley is generic in that it does not dictate specific formats.Internet Security Association and Key Management Protocol (ISAKMP): ISAKMP provides a framework for Internet key management and provides the specific protocol support, including formats, for negotiation of security attributes.68IKE History

Internet Key ExchangeWhen a peer needs to send an IP packet, it consults the Security Policy Database (SPD) to see if there is an AS for that type of traffic. If there is no SA, IKE will called to establish one. IKE operates in two phases:IKE Phase 1Uses Main or Aggressive mode exchangeNegotiates IKE SAOnly established once between two end points

69How It Works:

Internet Key ExchangeIKE operates in two phases:IKE Phase 2Uses quick mode exchange.Negotiates IPSec SAs.Occurs multiple times.Both phases use Diffie-Hellman key exchange to establish a shared key.

70How It Works:

Internet Key ExchangeWhen A wants to talk to B under protection of IPSec, and they do not have an established SA:A invokes IKE to signal B its request for an SAIKE is run between A and B: result is a shared SA (services to be applied and fresh shared keys)Negotiated parameters stored locally at A and B (SAD)SPI (sec. parameters index): pointer to SA included in the IPSec header of each packetArchitectural separation: IKE writes to SAD, IPSec reads from SAD. 71How It Works:

Internet Key Exchange72How It Works:

Internet Key ExchangeAlgorithm for secure key exchange over unsecured channels.Based on the difficulty of finding discreet algorithms.Used to establish a shared secret between parties (usually the secret keys for symmetric encryption or HMACs).

73Diffie-Hellman Algorithm:

Internet Key ExchangeGeneral overview: Key Exchange establishes a shared secret between two parties that can be used for secret communication for exchanging data over a public network. The following conceptual diagram illustrates the general idea of the key exchange by using colors instead of very large numbers.

74Diffie-Hellman Algorithm:

Internet Key Exchange75Diffie-Hellman Algorithm:

Internet Key Exchange

76Diffie-Hellman Algorithm:APrivate Value, XPublic Value, YPrivate Value, XPublic Value, YB

(Shared Secret)

Internet Key ExchangeThere are a number of weaknesses to Diffie-Hellman, as pointed out in [HUIT98].It does not provide any information about the identities of the parties.It is subject to a man-in-the-middle attack, in which a third party C impersonates B while communicating with A and impersonates A while communicating with B. Both A and B end up negotiating a key with C, which can then listen to and pass on traffic. The man-in-the-middle attack proceeds as77Diffie-Hellman Algorithm:

Internet Key Exchange78Diffie-Hellman Algorithm:This is how does Diffie-Hellman work:This is how does the man-in-the-middle attack work in Diffie-Hellman:

Internet Key ExchangeThere are a number of weaknesses to Diffie-Hellman, as pointed out in [HUIT98].It is computationally intensive. As a result, it is vulnerable to a clogging attack,in which an opponent requests a high number of keys. The victim spends considerable computing resources doing useless modular exponentiation rather than real work.IKE key determination is designed to retain the advantages of Diffie-Hellman, while countering its weaknesses.79Diffie-Hellman Algorithm:

Internet Key ExchangeIt employs a mechanism known as cookies to thwart clogging attacks.It enables the two parties to negotiate a group; this, in essence, specifies the global parameters of the Diffie-Hellman key exchange.It uses nonces to ensure against replay attacks.It enables the exchange of Diffie-Hellman public key values.It authenticates the Diffie-Hellman exchange to thwart man-in-the-middle attacks.80Features of IKE key determination:

First, consider the problem of clogging attacks. In thisattack, an opponent forges the source address of a legitimate user and sends apublic Diffie-Hellman key to the victim. The victim then performs a modularexponentiation to compute the secret key. Repeated messages of this typecan clog the victims system with useless work. The cookie exchange requiresthat each side send a pseudorandom number, the cookie, in the initial message,which the other side acknowledges. This acknowledgment must be repeatedin the first message of the Diffie-Hellman key exchange. If the source addresswas forged, the opponent gets no answer. Thus, an opponent can only forcea user to generate acknowledgments and not to perform the Diffie-Hellmancalculation.IKE mandates that cookie generation satisfy three basic requirements:1. The cookie must depend on the specific parties. This prevents an attackerfrom obtaining a cookie using a real IP address and UDP port and then usingit to swamp the victim with requests from randomly chosen IP addresses orports.2. It must not be possible for anyone other than the issuing entity to generatecookies that will be accepted by that entity. This implies that the issuing entitywill use local secret information in the generation and subsequent verificationof a cookie. It must not be possible to deduce this secret information from anyparticular cookie. The point of this requirement is that the issuing entity neednot save copies of its cookies, which are then more vulnerable to discovery, butcan verify an incoming cookie acknowledgment when it needs to.3. The cookie generation and verification methods must be fast to thwart attacksintended to sabotage processor resources.The recommended method for creating the cookie is to perform a fast hash(e.g., MD5) over the IP Source and Destination addresses, the UDP Source andDestination ports, and a locally generated secret value.IKE key determination supports the use of different groups for the Diffie-Hellman key exchange. Each group includes the definition of the two global parametersand the identity of the algorithm. The current specification includes thefollowing groups.SHANNON.IR652 Chapter 20 / IP Security Modular exponentiation with a 768-bit modulusq = 2768 - 2704 - 1 + 264 * ( :2638 * p; + 149686)a = 2 Modular exponentiation with a 1024-bit modulusq = 21024 - 2960 - 1 + 264 * ( :2894 * p; + 129093)a = 2 Modular exponentiation with a 1536-bit modulus Parameters to be determined Elliptic curve group over 2155 Generator (hexadecimal): X = 7B, Y = 1C8 Elliptic curve parameters (hexadecimal): A = 0, Y = 7338F Elliptic curve group over 2185 Generator (hexadecimal): X = 18, Y = D Elliptic curve parameters (hexadecimal): A = 0, Y = 1EE9The first three groups are the classic Diffie-Hellman algorithm using modularexponentiation. The last two groups use the elliptic curve analog to Diffie-Hellman.IKE key determination employs nonces to ensure against replay attacks. Eachnonce is a locally generated pseudorandom number. Nonces appear in responsesand are encrypted during certain portions of the exchange to secure their use.Three different authentication methods can be used with IKE key determination: Digital signatures: The exchange is authenticated by signing a mutually obtainablehash; each party encrypts the hash with its private key. The hash isgenerated over important parameters, such as user IDs and nonces. Public-key encryption: The exchange is authenticated by encrypting parameterssuch as IDs and nonces with the senders private key. Symmetric-key encryption: A key derived by some out-of-band mechanismcan be used to authenticate the exchange by symmetric encryption of exchangeparameters.

Internet Key ExchangeAn IKE session runs over UDP (source and destination port 500).IKE session establishment results in the creation of IKE Sas.IKE then establishes all requested IPSec SAs on demand.

81IKE Protocol:

Internet Key ExchangeThe IKEv2 protocol involves the exchange of messages in pairs.The goal of using four messages to establish the first SA for general use.82IKE v2 Exchanges:

Internet Key ExchangeThe first two pairs of exchanges are referred to as the initial exchanges.the two peers exchange information concerning cryptographic algorithms and other security parameters they are willing to use along with nonces and Diffie-Hellman (DH) values.83IKE v2 Exchanges:

Internet Key ExchangeThe result of this exchange is to set up a special SA called the IKE SA.This SA defines parameters for a secure channel between the peers over which subsequent message exchanges take place.

84IKE v2 Exchanges:

Internet Key Exchangeall subsequent IKE message exchanges are protected by encryption and message authentication.85IKE v2 Exchanges:

Internet Key ExchangeThe second exchange, the two parties authenticate one another and set up a first IPsec SA to be placed in the SADB and used for protecting ordinary (i.e. non-IKE) communications between the peers.

86IKE v2 Exchanges:

Internet Key ExchangeThe CREATE_CHILD_SA exchange can be used to establish further SAs for protecting traffic.87IKE v2 Exchanges:

Internet Key ExchangeThe informational exchange is used to exchange management information, IKEv2 error messages, and other notifications.88IKE v2 Exchanges:

Internet Key ExchangeIKE defines procedures and packet formats to establish, negotiate, modify, and delete security associations.As part of SA establishment, IKE defines payloads for exchanging key generation and authentication data.These payload formats provide a consistent framework independent of the specific key exchange protocol, encryption algorithm, and authentication mechanism.89Header and Payload Formats:

Internet Key Exchange90Header and Payload Formats:

IKE Header Format An IKE message consists of an IKE header followed by oneor more payloads. All of this is carried in a transport protocol. The specification dictatesthat implementations must support the use of UDP for the transport protocol.Figure 20.12a shows the header format for an IKE message. It consists of thefollowing fields. Initiator SPI (64 bits): A value chosen by the initiator to identify a unique IKEsecurity association (SA). Responder SPI (64 bits): A value chosen by the responder to identify a uniqueIKE SA. Next Payload (8 bits): Indicates the type of the first payload in the message;payloads are discussed in the next subsection. Major Version (4 bits): Indicates major version of IKE in use. Minor Version (4 bits): Indicates minor version in use. Exchange Type (8 bits): Indicates the type of exchange; these are discussedlater in this section. Flags (8 bits): Indicates specific options set for this IKE exchange. Three bitsare defined so far. The initiator bit indicates whether this packet is sent bythe SA initiator. The version bit indicates whether the transmitter is capableof using a higher major version number than the one currently indicated. Theresponse bit indicates whether this is a response to a message containing thesame message ID. Message ID (32 bits): Used to control retransmission of lost packets andmatching of requests and responses. Length (32 bits): Length of total message (header plus all payloads) in octets.IKE Payload Types All IKE payloads begin with the same generic payload headershown in Figure 20.12b. The Next Payload field has a value of 0 if this is the lastpayload in the message; otherwise its value is the type of the next payload. ThePayload Length field indicates the length in octets of this payload, including thegeneric payload header.The critical bit is 0 if the sender wants the recipient to skip this payload if itdoes not understand the payload type code in the Next Payload field of the previouspayload. It is set to 1 if the sender wants the recipient to reject this entire message ifit does not understand the payload type.

Internet Key Exchange91Header and Payload Formats:

All Together92

93

filters

filtersHow Components Interacts?Internet Key Exchange (IKE) - Identity Protect Mode defined in RFC 2409Phase 1 Main Mode establishes IKE SA trusted channel between systems, negotiation establishes encrypted channel, mutual trust, and dynamically generates shared secret key (master key)Phase 2 Quick Mode establishes IPSec SAs for data protection, one SA for each direction identified by packet label (SPI), algorithms and packet formats agreed, generates shared session secret keys derived from master key

NIC

TCPIPApplicationServer or GatewayIPSecDriver

IPSecPolicyAgent

IKE (ISAKMP)

IPSecDriver

IPSecPolicy Agent

IKE (ISAKMP)

NIC

TCPIPApplication/ServiceclientIKE ResponderIKE Initiator

UDP port 500 negotiation 1 IKE SA2 IPSec SAs

IP protocol 50/51

Years of experience with IPv4 have exposed us to various aspects of TCP/IPcommunication: transport protocols have port numbers, NAT and proxy servers havebecome standard networking features, we have learned to accept replay attacks asvulnerability, and Network IDS is considered a requirement by many securityprofessionals. IPSec changes the rules on how and what we deploy in our networksand in some cases we no longer need accept certain limitations of TCP/IP.Unlike many transport layer protocols, such as TLS, TCP, and UDP, ESP uses only aprotocol number. AH also uses a protocol number as is typical of network layerprotocols. Specifically, AH uses protocol number 51 and ESP uses protocol number50. If the two are used together then the protocol number of the outer most protocol isexposed. AH and ESP in transport mode will expose protocol 51 whereas ESP intunnel mode and AH in transport mode will expose protocol 50.As was mentioned in previous sections, AH and ESP may not work with a proxy serveror NAT. More generically, IPSec, in either transport or tunnel mode, does not workwith a device that modifies an IP packet. This is because AH and ESP sign theirportions of each packet. AH signs the entire IP packet with the exception of a fewfields that must change in normal IP communication (such as TTL). Tunnel modeallows the new IP header to be modified enroute, unless AH in transport mode is alsoused, but the rest of the packet is still off limits. The result is that regardless if you useAH or ESP the payload is always off limits for modifications, tunnel or transport, andthe IP and transport header information may also be off limits.Recently Network and Host IDS have become an important tool in the securityprofessionals toolbox. NIDS are basically protocol analyzers. They capture packetson the network, analyze the packets to determine if it is malicious, alert securityadministrators of malicious packets, and in some cases will terminate communicationcontaining malicious packets.All IDS work on the premise that the packet is transparent and that the contents are inan expected position. IPSec complicates this by encrypting portions of the packet,ESP, or moving the location of parts of a packet, tunnel mode. The solution willdepend on the organization. Tunnel mode moves the original IP header and Transportlayers from the expected location within the packet. However, tunnel mode is almostexclusively used between gateways. NIDS will need to be located inside of eachgateway, prior to IPSec tunneling being applied, to permit the NIDS to work.Since transport mode does not relocate important packet information, in principle NIDSwill work with transport mode. If ESP is used with encryption there is no simplesolution, however. One solution is to not use ESP with encryption on a network thatrequires NIDS. Another solution is to use ESP in tunnel mode to a gateway. Once atthe gateway the IPSec is decrypted and available for inspection by NIDS beforereaching the next gateway, which encrypts the packet before sending it to the finaldestination. Potentially a Host IDS that provides packet analysis can be used. Thissolution only works if the HIDS is able to inspect the packet after the packet has beendecrypted. HIDS solutions can quickly become extremely expensive since every hostin the network requires the software.Replay and man-in-the-middle attacks are difficult to protect against. Fortunately, theyare somewhat difficult to carry out since they require direct access to the network thesystems use. Replay attacks capture the packets of a real session, alter the packets,and then retransmit the packets. The end-point hosts believe they are communicatingdirectly with each other, but in fact they are communicating with a server in between.This is attack is extremely difficult to detect.As has been mentioned many times, IPSec provides anti-replay protection. This isdone by using a sliding window. IPSec gives each packet a sequence number. If a 64-packet sliding window is used then a host will accept packets 1 64 without problem.When packet 65 arrives the host will no longer accept packet number 1. Likewise,when packet 100 arrives, any packets below number 36 are dropped. In addition,IPSec does not accept duplicate sequence numbers. In other words, once packet 125arrives for a given IPSec session, IPSec does not permit another packet 125. This alsomeans that IPSec keys must be renegotiated and a new IPSec session establishedbefore IPSec sequence numbers wrap. This scheme makes replay attacks verydifficult since the attacker only has a narrow window of time to retransmit the packet.IPSec provides only limited man-in-the-middle protection. This protection is dependenton authentication method selected. In W2K, 3rd party certificates, Kerberos, andshared secret are supported. Of these, only 3rd party certificates provide strong man-inthe-middle protection.

VPN94

VPNEstablish a connection between networks over an untrusted network provided via a tunnel

95What is a VPN?

Internet

Site ASite B

VPN

VPN96RFC 4308 defines two cryptographic suites for establishing virtual private networks.Suite VPN-A matches the commonly used corporate VPN security used in older IKEv1 implementations at the time of the issuance of IKEv2 in 2005. Suite VPN-B provides stronger security and is recommended for new VPNs that implement IPsecv3 and IKEv2.

VPN97

VPN98Note that for symmetric cryptography:VPN-A relies on 3DES and HMAC.while VPN-B relies exclusively on AES.Three types of secret-key algorithms are used:Encryption: For encryption, the cipher block chaining (CBC) mode is used.Message authentication: For message authentication, VPN-A relies on HMAC with SHA-1 with the output truncated to 96 bits. VPN-B relies on a variant of CMAC with the output truncated to 96 bits.Pseudorandom function: IKEv2 generates pseudorandom bits by repeated use of the MAC used for message authentication.

VPNSite to SiteRemote Access

99Types of VPNs:

VPN

100Types of VPNs:Site to Site

Internet

Site ASite B

Data A-BData A-BData A-BData A-BData A-BData A-B

VPN

101Types of VPNs:Remote AccessInternet

Site A

User 1User 2User n

VPNL2 VPNsL2TPMPLS VPN. VPLSL3 VPNsIPSecMPLS VPN. RoutedGREL5/L6 VPNsSSL-TLS

102Commonly used VPNs:

VPNIPSec VPN Benefits:Anti ReplayConfidentialityIntegrityAuthentication

103IPSec VPN Benefits:

Estimated duration 01:15

A VPN is secure because private data is encapsulated, encrypted and sent to the remote peer for decryption/de capsulation.We will later see what encapsulation and encryption is.

There are four major concerns when sending private data over a public medium that IPSec addresses.

One is Anti-replay It Ensures the uniqueness of each IP packet. Anti-replay is also called replay prevention. Anti-replay ensures that data captured by an attacker cannot be reused or replayed to establish a session or gain information illegally.

ConfidentialityKeep data secure and hidden (using Encryption). Ensures that data is only disclosed to intended recipients.

IntegrityEnsure data hasnt been changed. Protects data from unauthorized modification in transit, ensuring that the data received is exactly the same as the data sent.

AuthenticationVerifies if did the traffic really come from the advertised source?Verifies that a message could only have been sent from a computer that has knowledge of the authentication key

---------------------------------------------------------------------------------------------------------------------The set of security services offered includes access control, connectionless integrity, data origin authentication, protection against replays (a form of partial sequence integrity), confidentiality (encryption), and limited traffic flow confidentiality.

THANK YOU104