BCSE309L - Cryptography and

Network Security

Module 6
Transport Layer Security and IP Security

Dr. S. Renuka Devi

Professor
SCOPE
VIT Chennai Campus

1
Module Outline
 Transport-Layer Security
 Secure Socket Layer(SSL)
 TLS
 IP Security
 Overview
 IP Security Architecture
 Encapsulating Payload Security

2
Web Security Threats

3
Relative Location of Security
Facilities in the TCP/IP Protocol Stack

4
Transport Layer Security (TLS)
 TLS is an Internet standard that evolved from a
commercial protocol known as Secure Sockets Layer
(SSL)
 Very similar to SSLv3
 TLS is a general-purpose service implemented as a
set of protocols that rely on TCP
 TLS could be provided as part of the underlying
protocol suite, or it can be embedded in specific
packages
 For example, most browsers come equipped with
TLS, and most Web servers have implemented the
protocol
5
TLS
 TLS is designed to make use of TCP to provide
a reliable end-to-end secure service.
 TLS is not a single protocol but rather two
layers of protocols.
 It provides basic security services to various
higher layer protocols.
 In particular, the Hypertext Transfer Protocol
(HTTP), which provides the transfer service for
Web client/server interaction, can operate on
top of TLS

6
TLS Architecture

7
TLS concepts
1. Connection – a connection is a transport that
provides a suitable type of service
 peer-to-peer relationships

 connections are transient

 Every connection is associated with one session

2. Session – a TLS session is an association between

a client and a server
 created by the handshake protocol

 define a set of cryptographic security parameters,

which can be shared among multiple connections

8
 TLS
There are a number of states associated with each session. A
session state is defined by the following parameters.
Session identifier: to identify an active or resumable session

state
Peer certificate: An X509.v3 certificate of the peer

Compression method: algorithm used to compress data

prior to encryption
Cipher spec: Specifies the encryption algorithm and a hash

algorithm used for MAC calculation

Master secret: 48-byte secret shared between the client and

server
Is resumable: A flag indicating whether the session can be

used to initiate new connections

9
 TLS
A connection state is defined by the following
parameters.
Server and client random: Byte sequences that are

chosen by the server and client for each connection

Server write MAC secret: secret key used in MAC

Client write MAC secret: secret key used in MAC

Server write key: secret encryption key

Client write key: symmetric encryption key

Initialization vectors: an initialization vector (IV) is

maintained for each key - initialized by the TLS

Handshake Protocol
Sequence numbers: sequence numbers for
10
transmitted and received messages for each
 TLS Record Protocol
 provides two services for TLS connections:
Confidentiality and Message integrity

11
TLS Record Protocol
The final step of TLS Record Protocol processing is to
prepend a header consisting of the following fields:
Content Type (8 bits): The higher-layer protocol used

to process the enclosed fragment

Major Version (8 bits): Indicates major version of TLS

in use. For TLSv2, the value is 3

Minor Version (8 bits): Indicates minor version in use.

For TLSv2, the value is 1

Compressed Length (16 bits): The length in bytes of

the plaintext fragment (or compressed fragment if

compression is used). The maximum value is 214 +
2048.
12
Change Cipher Spec protocol
 This protocol consists of a single message
which consists of a single byte with the value 1
 The sole purpose of this message is to cause
the pending state to be copied into the current
state, which updates the cipher suite to be
used on this connection

13
Alert protocol
 It is used to convey TLS related alerts to the peer
entity
 Each message in this protocol consists of two bytes.
 The first byte takes the value warning (1) or fatal
(2) to convey the severity of the message.

If the level is fatal, TLS immediately terminates
the connection. Other connections on the same
session may continue, but no new connections
on this session may be established.
 The second byte contains the code that indicates
the specific alert.

14
Alert protocol
Fatal alerts
Unexpected message – an inappropriate message

was received
Bad_record_mac – an incorrect MAC was received.

Decompression failure – the decompression

function received improper input

Handshake_failure – sender was unable to

negotiate an acceptable set of security parameters

Illegal parameter – a field in a handshake message

was out of range or inconsistent with other fields

15
 Alert protocol
 decryption_failed - A ciphertext decrypted in an invalid way
 record_overflow - A TLS record was received with a payload
(ciphertext) whose length exceeds 214 + 2048 bytes
 unknown_ca - CA certificate could not be located or could
not be matched with a known, trusted CA
 access_denied: A valid certificate was received, but when
access control was applied, the sender decided not to
proceed with the negotiation
 decode_error: A message could not be decoded,
 insufficient_security: Returned instead of handshake_failure
 internal_error: An internal error unrelated to the peer or the
correctness of the protocol makes it impossible to continue

16
Alert protocol
Warning
Close_notify – notifies the recipient that the sender will not

send any more messages on this connection

No_certificate – may be sent in response to a certificate

request if no appropriate certificate is available

Bad_certificate – a received certificate was corrupt

Unsupported_certificate – certificate type is not supported

Certificate_revoked – a certificate has been revoked by its

signer
Certificate_expired – a certificate has expired

Certificate_unknown – some other unspecified issue arose

in processing the certificate

17
Handshake 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 TLS record
 This protocol is used before any application
data is transmitted
 The handshake protocol consists of a series of
messages exchanged by client and server

18
19
 Phase 1: Establish security
capabilities
 This phase is used to initiate a logical connection and to
establish the security capabilities that will be
associated with it
 Initiated by the client, which sends a client_hello
message with the following parameters:
 Version

 Random –serve as nonce - to prevent replay attacks

 Session ID

 Cipher suite -cryptographic algorithms supported by

the client, in decreasing order of preference

 Compression method - compression methods that

the client supports

20
Phase 1: Establish security
capabilities
 After sending the client_hello message, the
client waits for the server_hello message,
which contains the same parameters as the
client_hello message
 The version field contains the lower of the
version suggested by the client and the
highest supported by the server
 The random field is generated by the server
and is independent of client’s random field.

21
Phase 2: Server authentication and
key exchange

 The server begins this phase by sending its certificate –

for authentication
 A server_key_exchnge message may be sent if it is
required
 Server can request a certificate from the client
 The certificate_request message includes two

parameters: certificate_type and

certificate_authorities
 The certificate_type indicates the public key

algorithm and its use. The second parameter is a list

of distinguished names of certificate authorities
 Server_hello_done message - indicate the end of the
sever hello and associated messages.

22
Phase 3: Client authentication and
key exchange
 The client should verify that the server
certificate
 If it is satisfactory, the client begins this phase
by sending a certificate message
 If no suitable certificate is available, the client
sends a no_certificate alert instead
 Next is the client_key_exchnage
 Finally, the client may send a certificate_verify
message to produce explicit verification of the
client certificate

23
 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 in to the current
cipherspec
 The client then immediately sends the finished
message
 In response, the server sends its own
change_cipher_spec message and finished message
 At this point, the handshake is complete and the
client and server may begin to exchange application
layer data

24
Heart beat protocol
 A heartbeat protocol is typically used to monitor the
availability of a protocol entity
 The Heartbeat protocol runs on top of the TLS
Record Protocol and consists of two message types:
heartbeat_request and heartbeat_response
 The use of the Heartbeat protocol is established
during Phase 1 of the Handshake protocol - each
peer indicates whether it supports heartbeats
 A heartbeat_request message can be sent at any
time.
 Whenever a request message is received, it should
be answered promptly with a corresponding
heartbeat_response message 25
Heart beat protocol
 The heartbeat serves two purposes.
 First, it assures the sender that the recipient

is still alive, even though there may not

have been any activity over the underlying
TCP connection for a while

 Second, the heartbeat generates activity

across the connection during idle periods,
which avoids closure by a firewall that does
not tolerate idle connections

26
IP Security
 IPSec is a set of communication rules or
protocols for setting up secure connections
over a network (a LAN, across private and
public WANs, and across the Internet)

 IP-level security encompasses three

functional areas:
 Authentication

 Confidentiality

 key management

27
Application of IPSec
 Secure branch office connectivity over the
Internet

 Secure remote access over the Internet

 Establishing extranet and intranet connectivity

with partners

 Enhancing electronic commerce security

28
An IPSec VPN Scenario

29
Benefits of IPSec
 When IPsec is implemented in a firewall or router, it
provides strong security to all traffic crossing the
perimeter
 IPsec in a firewall is resistant to bypass if the firewall is
the only means of entrance
 IPsec is below the transport layer (TCP, UDP) and so is
transparent to applications
 No need to change software on a user or server system
when IPsec is implemented in the firewall or router
 Even if IPsec is implemented in end systems, upper-layer
software, including applications, is not affected
 IPsec can be transparent to end users
 No need to train users on security mechanisms
30
Routing Applications

IPsec can assure that

A router advertisement (a new router advertises

its presence) comes from an authorized router

A neighbor advertisement comes from an

authorized router
A redirect message comes from the router to

which the initial IP packet was sent.

A routing update is not forged

31
IPSec Services
 Access control
 Connectionless integrity
 Data origin authentication
 Rejection of replayed packets
 Confidentiality
 Limited traffic flow confidentiality

32
Transport and Tunnel modes
 Two protocols are used to provide security:
 Authentication Header (AH)
 Encapsulating Security Payload (ESP)

 Both AH and ESP support two modes of use:

transport and tunnel mode

33
Transport mode
 Provides protection primarily for upper-layer
Protocols
 Protection extends to the payload of an IP packet

Examples include a TCP or UDP segment or an ICMP
packet
 Used for end-to-end communication between two
hosts
 ESP in transport mode encrypts and optionally
authenticates the IP payload but not the IP header
 AH in transport mode authenticates the IP
payload and selected portions of the IP header

34
Tunnel Mode
 Provides protection to the entire IP packet
 To achieve this, 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
 The entire original, inner, packet travels through a
tunnel from one point of an IP network to another
 No routers along the way are able to examine the
inner IP header
 The outer(new) packet has totally different source
and destination addresses

35
Tunnel Mode
 Tunnel mode is used when one or both ends of a
security association (SA) are a security gateway,
such as a firewall or router that implements Ipsec

 ESP in tunnel mode encrypts and optionally

authenticates the entire inner IP packet, including
the inner IP header

 AH in tunnel mode authenticates the entire inner

IP packet and selected portions of the outer IP
header

36
 IP Security Policy
 It is the security policy applied to each IP packet
that transits from a source to a destination
 IPsec policy is determined primarily by the
interaction of two databases, the security
association database (SAD) and the security
policy database (SPD)
 An association is a one-way logical connection
between a sender and a receiver that affords
security services to the traffic carried on it
 If a peer relationship is needed for two-way secure
exchange, then two security associations are
required
37
IPSec Architecture

38
 Security Association
A 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: it may be an end-user system or a

network system such as a firewall or router

Security Protocol Identifier: indicates whether the association

is an AH or ESP security association

39
 Security Association Database
A security association is defined by the following parameters
in an SAD entry
Security Parameter Index - 32-bit value selected by the

receiving end of an SA to uniquely identify the SA

Sequence Number Counter -32-bit value used to

generate the Sequence Number field in AH or ESP headers

Sequence Counter Overflow - a flag indicating whether

the counter overflow should generate an auditable event and

prevent further transmission of packets on this SA
Anti-Replay Window - Used to determine replay packets

40
 Security Association Database
 AH Information - Authentication algorithm, keys, key
lifetimes, and related parameters
 ESP Information - Encryption and authentication
algorithm, keys, initialization values, key lifetimes, and
related parameters
 Lifetime of this Security Association - A time
interval or byte count after which an SA must be
replaced with a new SA or terminated
 IPsec Protocol Mode - Tunnel, transport, or wildcard
 Path MTU - maximum size of a packet that can be
transmitted without fragmentation
41
Security Policy Database
 The 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)
 An SPD contains entries, each of which defines a
subset of IP traffic and points to an SA for that
traffic
 Each SPD entry is defined by a set of IP and
upper-layer protocol field values, called selectors
 Selectors are used to filter outgoing traffic in
order to map it into a particular SA

42
SPD
Outbound processing obeys the following general
sequence for each IP packet.
1.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
2.Determine the SA if any for this packet and its

associated SPI
3.Do the required IPsec processing (i.e., AH or

ESP processing)

43
SPD
The following selectors determine an SPD entry:
Remote IP Address

Local IP Address

Next Layer Protocol

Name

Local and Remote Ports

44
 SPD

 PORT 500 – used by the Internet key exchange (IKE) that occurs during the
establishment of secure VPN tunnels
 PORT 80 - default network port for web servers using HTTP
 PORT 443 - the standard port for HTTPS, the secure version of HTTP
45
IP Traffic Processing
 IPsec is executed on a packet-by-packet basis
 When IPsec is implemented, 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

46
IP Traffic Processing – Outbound
packets

47
IP Traffic Processing – Inbound
packets

48
Encapsulating Security Payload (ESP)
 ESP can be used to provide confidentiality,
data origin authentication, connectionless
integrity, an anti-replay service and (limited)
traffic flow confidentiality

49
ESP

50
Transport and Tunnel modes

51
Transport mode ESP
 used to encrypt and optionally authenticate
the data carried by IP (e.g., a TCP segment)

52
Transport mode ESP

53
Tunnel mode ESP

54
Transport Mode

55
Tunnel Model

56
Combining Security Associations
 An individual SA can implement either the AH
or ESP protocol but not both

 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

57
Combining Security Associations
Security associations may be combined into
bundles in two ways:
Transport adjacency - applying more than one

security protocol to the same IP packet without

invoking tunneling
Iterated tunneling - application of multiple layers of

security protocols effected through IP tunneling

The two approaches can be combined, for example,
by having a transport SA between hosts travel part
of the way through a tunnel SA between security
gateways

58
Authentication plus Confidentiality
 ESP WITH AUTHENTICATION OPTION - the user first
applies ESP to the data to be protected and then
appends the authentication data field
 There are actually two subcases:

Transport mode ESP: Authentication and encryption
apply to the IP payload delivered to the host, but the
IP header is not protected.

Tunnel mode ESP: Authentication applies to the entire
IP packet delivered to the outer IP destination address
and authentication is performed at that destination.
For both cases, authentication applies to the ciphertext
rather than the plaintext

59
Authentication plus Confidentiality
 TRANSPORT ADJACENCY - Another way to
apply authentication after encryption is to use
two bundled transport SAs, with the inner
being an ESP SA and the outer being an AH SA
 Advantage - authentication covers more

fields, including the source and destination

IP addresses
 Disadvantage - overhead of two SAs versus

one SA

60
Authentication plus Confidentiality
 TRANSPORT-TUNNEL BUNDLE
 The use of authentication prior to encryption

might be preferable for several reasons.

 First, because the authentication data are

protected by encryption, it is impossible for

anyone to intercept the message and alter the
authentication data without detection.
 Second, it may be desirable to store the
authentication information with the message at
the destination for later reference. Otherwise the
message would have to be reencrypted to verify
the authentication information
61
Authentication plus Confidentiality
 TRANSPORT-TUNNEL BUNDLE
 One approach to applying authentication before

encryption between two hosts is to use a bundle

consisting of an inner AH transport SA and an outer
ESP tunnel SA
 In this case, authentication is applied to the IP

payload plus the IP header (and extensions) except

for mutable fields
 The resulting IP packet is then processed in tunnel

mode by ESP; the result is that the entire,

authenticated inner packet is encrypted and a new
outer IP header (and extensions) is added

62
Basic combinations of SAs

63
Basic combinations of SAs

64
Basic combinations of SAs

65
Basic combinations of SAs

66
References
 Cryptography and Network Security Principles
And Practice, William Stallings, 5e , Pearson
Education, 2011

67
Thank you

68