Unit-4 Ip Security: Benefits of Ipsec

Download as pdf or txt
Download as pdf or txt
You are on page 1of 12

Information Security (CS7T3) PVP14

Unit-4
IP Security
Implementing security at the IP level, an organization can ensure secure networking not only for
applications that have security mechanisms but also for the many security-ignorant applications.

IP-level security encompasses three functional areas:

 The authentication mechanism assures that a received packet was transmitted by the
party identified as the source in the packet header, and that the packet has not been
altered in transit.
 The confidentiality facility enables communicating nodes to encrypt messages to
prevent eavesdropping by third parties.
 The key management facility is concerned with the secure exchange of keys.

IPSec provides the capability to secure communications across a LAN, across private and public
WANs, and across the Internet.

Benefits of IPSec
 in a firewall/router provides strong security to all traffic crossing the perimeter
 in a firewall/router is resistant to bypass
 is below transport layer, hence transparent to applications
 can be transparent to end users
 can provide security for individual users
 secures routing architecture
IPSec Services
IPSec provides security services at the IP layer by enabling a system to select required security
protocols, and determine the algorithm(s) to use for the service(s)
 Access control
 Connectionless integrity
 Data origin authentication
 Rejection of replayed packets
 a form of partial sequence integrity
 Confidentiality (encryption)
 Limited traffic flow confidentiality
Security Associations
A key concept that appears in both the authentication and confidentiality mechanisms for IP is
the security association (SA).
An association is a one-way relationship between a sender and a receiver that affords security for
traffic flow.
A security association is uniquely identified by three parameters:
• Security Parameters Index (SPI): A bit string assigned to this SA and having local significance
only
• IP Destination Address: this is the address of the destination endpoint of the SA
• Security Protocol Identifier: This indicates whether the association is an AH or ESP security
association.

D.Lokesh Sai Kumar,


Asst.Professor.
Information Security (CS7T3) PVP14

IPSec Architecture
 The IPSec specification has become quite complex. The IPSec specification consists of
numerous documents. The most important of these are
o RFC 2401: An overview of a security architecture
o RFC 2402: Description of a packet authentication extension to IPv4 and IPv6
o RFC 2406: Description of a packet encryption extension to IPv4 and IPv6
o RFC 2408: Specification of key management capabilities

IPSec Architecture have two security header extensions

1. Authentication Header (AH)


2. Encapsulating Security Payload (ESP)
1. Authentication Header
The Authentication Header provides support for data integrity and authentication of IP packets.
 The data integrity feature ensures that undetected modification to a packet’s content in transit is
not possible.
 The authentication feature enables an end system or network device to authenticate the user or
application and filter traffic accordingly; it also prevents address spoofing attacks and replay
attacks.
 Authentication is based on the use of a message authentication code (MAC), hence the
two parties must share a secret key.

Figure below shows the Authentication Header fields:

• Next Header (8 bits): Identifies the type of header immediately following this header
• Payload Length (8 bits): Length of Authentication Header in 32-bit words, minus 2.
• Reserved (16 bits): For future use
• Security Parameters Index (32 bits): Identifies a security association
• Sequence Number (32 bits): A monotonically increasing counter value
• Authentication Data (variable): A variable-length field (must be an integral number of 32-bit
words) that contains the Integrity Check Value (ICV), or MAC,for this packet

Transport & Tunnel Modes

Above Figure shows the difference between end-to-end (transport) mode and end-to-intermediate
(tunnel) mode.

 Transport mode provides protection primarily for upper-layer protocol payloads, by inserting the
AH after the original IP header and before the IP payload. Typically, transport mode is used for end-
to-end communication between two hosts.

D.Lokesh Sai Kumar,


Asst.Professor.
Information Security (CS7T3) PVP14

 Tunnel mode provides protection to the entire IP, after the AH or ESP fields are added to the IP
packet, the entire packet plus security fields is treated as the payload of new “outer”IP packet with a
new outer IP header. Tunnel mode is used when one or both ends of an SA are a security gateway,
such as a firewall or router that implements IPSec.

2. Encapsulating Security Payload (ESP)


 The Encapsulating Security Payload provides confidentiality services, including confidentiality of
message contents and limited traffic flow confidentiality.
 As an optional feature, ESP can also provide an authentication service, with the same MACs as AH.
 ESP supports range of ciphers, modes, and padding.

Above Figure shows the format of an ESP packet. It contains the following fields:

 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 (0–255 bytes): for various reasons
 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
 Authentication Data (variable): A variable-length field that contains the Integrity Check Value
computed over the ESP packet minus the Authentication Data field

D.Lokesh Sai Kumar,


Asst.Professor.
Information Security (CS7T3) PVP14

Transport vs Tunnel Mode in ESP


 Transport mode ESP is used to encrypt and optionally authenticate the data carried by IP.

 Transport mode operation provides confidentiality for any application that uses it,

 This mode of operation is also reasonably efficient, adding little to the total length of the IP
packet.

 One drawback to this mode is that it is possible to do traffic analysis on the transmitted
packets.

 Tunnel mode ESP is used to encrypt an entire IP packet. Tunnel mode is useful in a configuration
that includes a firewall or other sort of security gateway that protects a trusted network from external
networks.

Combining Security Associations


 An individual SA can implement either the AH or ESP protocol but not both.
 To implement both we need to combine SA’s
o Form a security association bundle
o May terminated at different or at the same end points
 Security associations may be combined into bundles in two ways:
o Transport adjacency: more than one security protocol on same IP packet, without
invoking tunneling
o Iterated tunneling: application of multiple layers of security protocols effected through
IP tunneling

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 Figure below. 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 organization’s
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.

D.Lokesh Sai Kumar,


Asst.Professor.
Information Security (CS7T3) PVP14

Key Management
The key management portion of IPSec involves the determination and distribution of secret keys.

A typical requirement is four keys for communication between two applications: transmit and
receive pairs for both AH and ESP.

The IPSec Architecture document mandates support for two types of key management:

 Manual where a system administrator manually configures each system with its own
keys and with the keys of other communicating
 Automated where 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.

Oakley
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.

Oakley is designed to retain the advantages of Diffie-Hellman while countering its weaknesses.

The Oakley algorithm is characterized by five important features:

1. It employs a mechanism known as cookies to thwart clogging attacks


2. It enables the two parties to negotiate a group; this, in essence, specifies the global parameters of
the Diffie-Hellman key exchange
3. It uses nonces to ensure against replay attacks
4. It enables the exchange of Diffie-Hellman public key values
5. It authenticates the Diffie-Hellman exchange to thwart man-in-the-middle attacks

Oakley supports the use of different groups for the Diffie-Hellman key exchange, being 768, 1024 or
1536 bit primes, or 155 or 185 bit elliptic curves.

D.Lokesh Sai Kumar,


Asst.Professor.
Information Security (CS7T3) PVP14

ISAKMP
The Internet Security Association and Key Management Protocol (ISAKMP)

 provides a framework for Internet key management and provides the specific protocol support,
defining procedures and packet formats to establish, negotiate, modify, and delete security
associations.
 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.

An ISAKMP message consists of an ISAKMP header followed by one or more payloads, carried in a
transport protocol (UDP by default).

ISAKMP Payloads & Exchanges

 have a number of ISAKMP payload types:

 Security, Proposal, Transform, Key, Identification, Certificate, Certificate, Hash,


Signature, Nonce, Notification, Delete

 ISAKMP has framework for 5 types of message exchanges:

 base, identity protection, authentication only, aggressive, informational

D.Lokesh Sai Kumar,


Asst.Professor.
Information Security (CS7T3) PVP14

Web Security
The World Wide Web is widely used by businesses, government agencies, and many individuals.
But the Web is extremely vulnerable to compromises of various sorts, with a range of threats.

 integrity
 confidentiality
 denial of service
 authentication
Secure Socket Layer (SSL)

 SSL probably most widely used Web security mechanism.

 It is implemented at the Transport layer; IPSec at Network layer; or various Application layer
mechanisms eg. S/MIME & SET (later).

 SSL is designed to make use of TCP to provide a reliable end-to-end secure service.

 SSL has two layers of protocol.

SSL Architecture

 The SSL Record Protocol provides basic security services to various higher-layer protocols.
 Hypertext Transfer Protocol (HTTP), provides the transfer service for Web client/server interaction,
can operate on top of SSL.
 Three higher-layer protocols are also defined as part of SSL:
 the Handshake Protocol.
 Change Cipher Spec Protocol.
 Alert Protocol.
 These SSL-specific protocols are used in the management of SSL exchanges.

Two important SSL concepts are the SSL connection and the SSL session:

 Connection: A connection is a network transport that provides a suitable type of service, such
connections are transient, peer-to-peer relationships, associated with one session

 Session: An SSL session is an association between a client and a server, created by the Handshake
Protocol.

o Sessions define a set of cryptographic security parameters, which can be shared among
multiple connections.

o Sessions are used to avoid the expensive negotiation of new security parameters for each
connection.

D.Lokesh Sai Kumar,


Asst.Professor.
Information Security (CS7T3) PVP14

1. SSL Record Protocol defines two services for SSL connections:

 Message Integrity: The Handshake Protocol also defines a shared secret key that is used to form a
message authentication code (MAC), which is similar to HMAC
 Confidentiality: The Handshake Protocol defines a shared secret key that is used for conventional
encryption of SSL payloads. The message is compressed before being concatenated with the MAC
and encrypted, with a range of ciphers being supported as shown.
Figure below shows the overall operation of the SSL Record Protocol.

The Record Protocol takes an application message to be transmitted, fragments the data into
manageable blocks, optionally compresses the data, applies a MAC, encrypts, adds a header, and transmits
the resulting unit in a TCP segment. Received data are decrypted, verified, decompressed, and
reassembled and then delivered to higher-layer applications.

2. SSL Change Cipher Spec Protocol


The Change Cipher Spec Protocol is one of the three SSL-specific protocols that use the SSL Record
Protocol, and it is the simplest, consisting of a single message. Its purpose is to cause the pending state to
be copied into the current state, which updates the cipher suite to be used on this connection.
3. SSL Alert Protocol

The Alert Protocol is used to convey SSL-related alerts to the peer entity. As with other applications
that use SSL, alert messages are compressed and encrypted, as specified by the current state.

Each message in this protocol consists of two bytes, the first takes the value warning(1) or fatal(2) to
convey the severity of the message. The second byte contains a code that indicates the specific alert. The
first group shown is the fatal alerts, the others are warnings.

4. SSL Hand Shake Protocol


This protocol allows the server and client to authenticate each other and to negotiate an encryption
and MAC algorithm and cryptographic keys to be used to protect data sent in an SSL record. The
Handshake Protocol consists of a series of messages exchanged by client and server, which can be
viewed in 4 phases:

Phase 1. Establish Security Capabilities - this phase is used by the client to initiate a logical connection
and to establish the security capabilities that will be associated with it

D.Lokesh Sai Kumar,


Asst.Professor.
Information Security (CS7T3) PVP14

Phase 2. Server Authentication and Key Exchange - the server begins this phase by sending its certificate
if it needs to be authenticated.

Phase 3. Client Authentication and Key Exchange - the client should verify that the server provided a
valid certificate if required and check that the server_hello parameters are acceptable

Phase 4. Finish - this phase completes the setting up of a secure connection. The client sends a
change_cipher_spec message and copies the pending CipherSpec into the current CipherSpec

Figure below shows the initial exchange needed to establish a logical connection between client and
server. The exchange can be viewed as having the four phases.

Transport Layer Security


TLS is an IETF standardization initiative whose goal is to produce an Internet standard version
of SSL. TLS is defined as a Proposed Internet Standard in RFC 2246.

 IETF standard RFC 2246 similar to SSLv3

 with minor differences

 in record format version number


 uses HMAC for MAC
 a pseudo-random function expands secrets
 has additional alert codes
 some changes in supported ciphers
 changes in certificate types & negotiations
 changes in crypto computations & padding

Secure Electronic Transactions


 SET is an open encryption and security specification

 SET is designed to protect credit card transactions on the Internet.

 SETv1 emerged from a call for security standards by MasterCard and Visa in 1996.

D.Lokesh Sai Kumar,


Asst.Professor.
Information Security (CS7T3) PVP14

 SET is not itself a payment system.

 SET is a set of security protocols and formats that enables users to employ the existing credit card
payment infrastructure on an open network, such as the Internet, in a secure fashion, by providing:

 a secure communications channel among all parties involved in a transaction


 trust through the use of X.509v3 digital certificates
 privacy because the information is only available to parties in a transaction when and where
necessary.

Above Figure indicates the participants in the SET system, being:

 Cardholder: purchasers interact with merchants from personal computers over the Internet

 Merchant: a person or organization that has goods or services to sell to the cardholder

 Issuer: a financial institution, such as a bank, that provides the cardholder with the payment card.

 Acquirer: a financial institution that establishes an account with a merchant and processes
payment card authorizations and payments

 Payment gateway: a function operated by the acquirer or a designated third party that processes
merchant payment messages

 Certification authority (CA): an entity that is trusted to issue X.509v3 public-key certificates for
cardholders, merchants, and payment gateways

SET Transaction
1. customer opens account
2. customer receives a certificate
3. merchants have their own certificates
4. customer places an order
5. merchant is verified
6. order and payment are sent
7. merchant requests payment authorization
8. merchant confirms order
9. merchant provides goods or service
10. merchant requests payment

D.Lokesh Sai Kumar,


Asst.Professor.
Information Security (CS7T3) PVP14

SET Dual Signature

• The purpose of the SET dual signature is to link two messages that are intended for two different
recipients, the order information (OI) for the merchant and the payment information (PI) for the
bank.

• The merchant does not need to know the customer’s credit card number, and the bank does not need
to know the details of the customer’s order, however the two items must be linked in a way that can
be used to resolve disputes if necessary.

• The customer takes the hash (using SHA-1) of the PI and the hash of the OI, concatenates them, and
hashes the result. Finally, the customer encrypts the final hash with his or her private signature key,
creating the dual signature. This can be summarized as: DS=E(PRc, [H(H(PI)||H(OI))])

SET Purchase Request

The purchase request exchange consists of four messages:

• Initiate Request: The customer requests the certificates in the Initiate Request message, sent to
the merchant.
• Initiate Response: The merchant generates a response and signs it with its private signature key.
• Purchase Request: The cardholder verifies the merchant and gateway certificates by means of
their respective CA signatures and then creates the OI and PI. Next, the cardholder prepares the
Purchase Request message with Purchase-related information & Order-related information.
• Purchase Response: The Purchase Response message includes a response block that
acknowledges the order and references the corresponding transaction number

Purchase Request Customer.

The contents of the Purchase Request message generated by the customer include the following:

1. Purchase-related information, which will be forwarded to the payment gateway by the merchant and
consists of PI, dual signature, & OI message digest (OIMD).
2. Order-related information needed by the merchant and consists of: OI, dual signature, PI message
digest (PIMD).
3. Cardholder certificate. This contains the cardholder’s public signature key.

D.Lokesh Sai Kumar,


Asst.Professor.
Information Security (CS7T3) PVP14

Purchase Request Merchant.

The Purchase Response message includes a response block that acknowledges the order and
references the corresponding transaction number. This block is signed by the merchant using its private
signature key. The block and its signature are sent to the customer, along with the merchant’s signature
certificate.

When the merchant receives the Purchase Request message, the actions listed are performed.

• verifies cardholder certificates using CA sigs


• verifies dual signature using customer's public signature key to ensure order has not been tampered
with in transit & that it was signed using cardholder's private signature key
• processes order and forwards the payment information to the payment gateway for authorization
• sends a purchase response to cardholder

Payment Gateway Authorization


• During the processing of an order from a cardholder, the merchant authorizes the transaction
with the payment gateway

• The payment authorization ensures that the transaction was approved by the issuer, guarantees
the merchant will receive payment, so merchant can provide services or goods to customer.

• The payment authorization exchange consists of two messages: Authorization Request and
Authorization response.

• The payment gateway performs the tasks shown on receiving the Authorization Request
message.

D.Lokesh Sai Kumar,


Asst.Professor.

You might also like