CSC/EE 526: Computer

and Network Security

Chapter 9
Dr. Hang Liu
Overview of
Chapter 6
 SSL Architecture
• Two important SSL concepts are:

• A transport that provides a suitable type of

SSL
service
• For SSL such connections are peer-to-peer

connection
relationships
• Connections are transient
• Every connection is associated with one session

• An association between a client and a server

• Created by the Handshake Protocol

SSL session
• Define a set of cryptographic security parameters
which can be shared among multiple connections
• Are used to avoid the expensive negotiation of new
security parameters for each connection
A session state is defined by the
following parameters:

An arbitrary byte sequence chosen by the server to

Session identifier identify an active or resumable session state

An X509.v3 certificate of the peer; this element of

Peer certificate the state may be null

The algorithm used to compress data prior to

Compression method encryption

Specifies the bulk data encryption algorithm and a

hash algorithm used for MAC calculation; also
Cipher spec defines cryptographic attributes such as the
hash_size

48-byte secret shared between the client and the

Master secret server

A flag indicating whether the session can be used

Is resumable to initiate new connections
 A connection state is defined by the
following parameters:

Server and • Byte sequences that are chosen

• When a block cipher in CBC
client by the server and client for each
mode is used, an initialization
connection
random vector (IV) is maintained for
each key
Initialization • This field is first initialized by
Server • The secret key used in MAC vectors the SSL Handshake Protocol
• The final ciphertext block
write MAC operations on data sent by the
from each record is preserved
server
secret for use as the IV with the
following record

Client • The secret key used in MAC

write MAC operations on data sent by the
client
secret
• Each party maintains separate
sequence numbers for
transmitted and received
Server • The secret encryption key for
data encrypted by the server and messages for each connection
write key decrypted by the client Sequence • When a party sends or
numbers receives a change cipher spec
message, the appropriate
sequence number is set to zero
• Sequence numbers may not
Client • The symmetric encryption key
for data encrypted by the client exceed 264 - 1
write key and decrypted by the server
SSL Record Protocol

The SSL Record

Protocol provides
two services for SSL
connections

Confidentiality Message integrity

The Handshake Protocol

The Handshake Protocol
also defines a shared
defines a shared secret
secret key that is used to
key that is used for
form a message
conventional encryption
authentication code
of SSL payloads
(MAC)
fragmented into
Fragmented into
blocks of 214 bytes
(16384 bytes) or
less
change_cipher_
spec ,alert ,
handshake , and
application_data
Table 6.2 SSL Handshake Protocol Message Types
Key Exchange Methods:
• RSA
• Fixed Diffie-Hellman
• Ephemeral DF
• Anonymous DF
• Fortezza

Cipher Algorithms
• RC4, RC2, DES, 3DES
MAC Algorithms
• MD5 or SHA-1
Cipher type:
• Block or stream
HashSize
Key Material
IV Size
IsExportable
 Cryptographic
Computations
• Two further items are of interest:
• The creation of a shared master secret by means of the key
exchange
• The shared master secret is a one-time 48-byte value generated
for this session by means of secure key exchange

• The generation of cryptographic parameters from the master

secret
• CipherSpecs require a client write MAC secret, a server write
MAC secret, a client write key, a server write key, a client write
IV, and a server write IV which are generated from the master
secret in that order
• These parameters are generated from the master secret by hashing
the master secret into a sequence of secure bytes of sufficient length
for all needed parameters
 Key Exchange Methods

• RSA: A 48-byte pre_master_secret is generated by the client, encrypted

with the server’s public RSA key, and sent to the server. The server
decrypts the ciphertext using its private key to recover the
pre_master_secret.
• Diffie-Hellman: Both client and server generate a Diffie-Hellman public
key.
• Fixed DH: Server’s certificate contains the DH public key parameters,
signed by CA. Client provides its DH public key parameters in a
certificate (if client authentication required) or in a message. Generate
a fixed secret key.
• Ephemeral DH: DH public key parameters are signed by sender’s
private key. Receiver uses corresponding public key to verify the
signature. Certificates are used to authenticate the public keys.
Generate a temporary authenticated key. More secure.
• Anonymous DH: each side sends its public SH parameters, no
authentication. Vulnerable to man-in-the-middle attack.
• Fortezza
Key Exchange Methods:
• RSA
• Fixed Diffie-Hellman
• Ephemeral DF
• Anonymous DF
• Fortezza

Cipher Algorithms
• RC4, RC2, DES, 3DES
MAC Algorithms
• MD5 or SHA-1
Cipher type:
• Block or stream
HashSize
Key Material
IV Size
IsExportable
 Transport Layer
Security (TLS)
• An IETF standardization Differences include:
initiative whose goal is to
produce an Internet • Version number
standard version of SSL • Message Authentication
Code
• Is defined as a Proposed • Pseudorandom function
Internet Standard in RFC • Alert codes
5246 • Cipher suites
• RFC 5246 is very similar to • Client certificate types
SSLv3
• Certificate_verify and
Finished Messages
• Cryptographic computations
• Padding
Chapter 9
IP Security
“If a secret piece of news is divulged by a spy
before the time is ripe, he must be put to
death, together with the man to whom the
secret was told.”

—The Art of War,

Sun Tzu
 IP Security Overview
• RFC 1636
• “Security in the Internet Architecture”
• Issued in 1994 by the Internet Architecture Board (IAB)
• Identifies key areas for security mechanisms
• Need to secure the network infrastructure from unauthorized
monitoring and control of network traffic
• Need to secure end-user-to-end-user traffic using authentication
and encryption mechanisms
• IAB included authentication and encryption as necessary security
features in the next generation IP (IPv6)
• These security capabilities were designed to be usable both with
the current IPv4 and the future IPv6.
• The IPsec specification now exists as a set of Internet standards
 Applications of IPsec
• IPsec provides the capability to secure communications across a
LAN, private and public WANs, and the Internet

• Secure branch office

connectivity over the
Internet

Examples • Secure remote access over

the Internet

include: • Establishing extranet and

intranet connectivity with
partners
• Enhancing electronic
commerce security

• Principal feature of IPsec is that it can encrypt and/or

authenticate all traffic at the IP level
• Thus all distributed applications (remote logon, client/server, e-
mail, file transfer, Web access) can be secured
 Benefits of IPSec
• Some 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
• Traffic within a company or workgroup does not incur the overhead of security-
related processing
• IPsec in a firewall is resistant to bypass if all traffic from the outside must use IP
and the firewall is the only means of entrance from the Internet into the
organization
• IPsec is below the transport layer (TCP, UDP) and so is transparent to applications
• There is no need to change software on a user or server system when IPsec is
implemented in the firewall or router
• IPsec can be transparent to end users
• There is no need to train users on security mechanisms, issue keying material on a
per-user basis, or revoke keying material when users leave the organization
• IPsec can provide security for individual users if needed
• This is useful for offsite workers and for setting up a secure virtual
subnetwork within an organization for sensitive applications
 Routing
Applications
• IPsec can play a vital role in the routing architecture
required for internetworking

IPsec can assure that:

A router seeking to
establish or maintain
a neighbor A redirect message
A router
relationship with a comes from the
advertisement comes A routing update is
router in another router to which the
from an authorized not forged
routing domain initial IP packet was
router
(neighbor sent
advertisement) is an
authorized router
 Encapsulating Security Internet Key Exchange (IKE)
Payload (ESP) • A collection of documents
• Consists of an encapsulating describing the key
header and trailer used to management schemes for use
provide encryption or with IPsec
combined • The main specification is RFC
encryption/authentication 5996, Internet Key Exchange
• The current specification is (IKEv2) Protocol, but there are a
RFC 4303, IP Encapsulating number of related RFCs
Security Payload (ESP)

Authentication Cryptographic algorithms

Header (AH) • This category encompasses
a large set of documents
• An extension header to provide that define and describe
message authentication
• The current specification is
cryptographic algorithms
RFC 4302, IP Authentication for encryption, message
Header authentication,
pseudorandom functions
(PRFs), and cryptographic
key exchange
Architecture IPsec
• Covers the general concepts,
security requirements,
Documents Other
definitions, and mechanisms • There are a variety of
defining IPsec technology other IPsec-related
• The current specification is RFCs, including those
RFC4301, Security dealing with security
Architecture for the Internet policy and management
Protocol information base (MIB)
content
 IPsec Services
• IPsec provides security services at the IP layer by enabling a
system to:
• Select required security protocols
• Determine the algorithm(s) to use for the service(s)
• Put in place any cryptographic keys required to provide the
requested services

• RFC 4301 lists the following services:

• Access control
• Connectionless integrity
• Data origin authentication
• Rejection of replayed packets (a form of partial sequence
integrity)
• Confidentiality (encryption)
• Limited traffic flow confidentiality
 Transport and
Tunnel Modes
Transport Mode

• Provides protection primarily for

upper-layer protocols Tunnel Mode
• Examples include a TCP or UDP
segment or an ICMP packet • Provides protection to the entire IP
packet
• Typically used for end-to-end
• Used when one or both ends of a security
communication between two hosts association (SA) are a security gateway
• ESP in transport mode encrypts and • A number of hosts on networks behind
optionally authenticates the IP firewalls may engage in secure
payload but not the IP header communications without implementing
• AH in transport mode authenticates IPsec
the IP payload and selected portions • ESP in tunnel mode encrypts and
of the IP header 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
 Table 9.1
Tunnel Mode and Transport Mode
Functionality
 Security Association
(SA)
• A one-way logical connection Uniquely identified by three parameters:
between a sender and a
receiver that affords security
services to the traffic carried Security Parameters
on it Index (SPI)
• A 32-bit unsigned integer
assigned to this SA and
• In any IP packet, the SA is having local significance only
uniquely identified by the
Destination Address in the
IPv4 or IPv6 header and the
SPI in the enclosed extension IP Destination
Security protocol Address
header (AH or ESP) identifier • Address of the
• Indicates whether the destination endpoint of
association is an AH or the SA, which may be
ESP security an end-user system or a
association network system such as
a firewall or router
 IPSec Packet
32 bits

type of
ver head. length
len service
fragment
16-bit identifier flgs
offset
time to upper header
live layer checksum
32 bit source IP address

32 bit destination IP address

options (if any)

data
(variable length,
typically a TCP
or UDP segment)

TFC: traffic flow

confidentiality
Security Association
Database (SAD)
• Defines the parameters associated with each SA
• Normally defined by the following parameters in a SAD
entry:
• Security parameter index
• Sequence number counter
• Sequence counter overflow
• Anti-replay window
• AH information
• ESP information
• Lifetime of this security association
• IPsec protocol mode
• Path MTU
 Security Policy
Database (SPD)
• The means by which IP traffic is related to specific SAs
• 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

• These are used to filter outgoing traffic in order to map

it into a particular SA

• 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
 Table 9.2
Host SPD Example
 Outbound Packet
Processing
• Outbound 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).
 SPD Entries
• The following selectors determine an SPD entry:

Remote IP Local IP Next layer Local and

Name
address address protocol remote ports
This may be a This may be a
single IP single IP
address, an address, an A user
enumerated list enumerated list identifier from
or range of or range of the operating
addresses, or a addresses, or a system
wildcard (mask) wildcard (mask) The IP protocol These may be
address address header includes individual TCP
a field that or UDP port
designates the values, an
protocol Not a field in the enumerated list
The latter two
The latter two operating over IP or upper-layer of ports, or a
are required to
are required to IP headers but is wildcard port
support more
support more available if IPsec
than one
than one source is running on the
destination
system sharing same operating
system sharing
the same SA system as the
the same SA
user
 Table 9.2
Host SPD Example
TFC: traffic flow
confidentiality
 Encapsulating
Security Payload (ESP)
• Used to encrypt the Payload Data, Padding, Pad Length, and Next Header
fields
• If the algorithm requires cryptographic synchronization data then these data may
be carried explicitly at the beginning of the Payload Data field

• An optional ICV (Integrity Check Value) field is present only if the integrity
service is selected and is provided by either a separate integrity algorithm or a
combined mode algorithm that uses an ICV
• ICV is computed after the encryption is performed
• This order of processing facilitates reducing the impact of DoS attacks
• Because the ICV is not protected by encryption, a keyed integrity algorithm must
be employed to compute the ICV

• The Padding field serves several purposes:

• Additional padding may be added to provide partial traffic-flow confidentiality by
concealing the actual length of the payload
• If an encryption algorithm requires the plaintext to be a multiple of some number
of bytes, the Padding field is used to expand the plaintext to the required length
• Used to assure alignment of Pad Length and Next Header fields
ESP with Authentication
Option
• In this approach, the first user applies ESP to the data to be
protected and then appends the authentication data field
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
• The entire inner IP packet is protected by the privacy mechanism
for delivery to the inner IP destination

• For both cases authentication applies to the

ciphertext rather than the plaintext
Authentication
Header
32 bits

head. type of
ver length
len service
fragment
16-bit identifier flgs offset
time to upper header
live layer checksum

32 bit source IP address

32 bit destination IP address

options (if any)

data
(variable length,
typically a TCP
or UDP segment)
 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
endpoint

• May be combined into bundles in two ways:

Transport • Refers to applying more than one security protocol to

the same IP packet without invoking tunneling
adjacency • This approach allows for only one level of combination

Iterated • Refers to the application of multiple layers of security

protocols effected through IP tunneling
tunneling • This approach allows for multiple levels of nesting
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
• In this case ESP is used without its authentication option
• Encryption is applied to the IP payload
• AH is then applied in transport mode
• Advantage of this approach is that the authentication
covers more fields
• Disadvantage is the overhead of two SAs versus one SA
Transport-Tunnel Bundle
• The use of authentication • One approach is to use a
prior to encryption might be bundle consisting of an inner
preferable for several reasons: AH transport SA and an
• It may be desirable to store the outer ESP tunnel SA
authentication information • Authentication is applied to
with the message at the the IP payload plus the IP
destination for later reference header
• It is more convenient to do • The resulting IP packet is then
this if the authentication processed in tunnel mode by
information applies to the ESP
unencrypted message. • The result is that the entire
• It is impossible for anyone to authenticated inner packet
intercept the message and alter is encrypted and a new
the authentication data outer IP header is added
without detection
 Internet Key Exchange
• The key management
portion of IPsec The IPsec Architecture document mandates
support for two types of key management:
involves the
determination and • A system administrator
distribution of secret manually configures each
system with its own keys and
keys with the keys of other
communicating systems
• A typical requirement • This is practical for small,
relatively static environments
is four keys for
communication
between two Manual Automated
applications
• Transmit and • Enables the on-demand
creation of keys for SAs and
receive pairs for facilitates the use of keys in a
large distributed system with
both integrity and an evolving configuration
confidentiality
 ISAKMP/Oakley
• The default automated key management protocol of IPsec
• Consists of:
• Oakley Key Determination Protocol
• A key exchange protocol based on the Diffie-Hellman algorithm
but providing added security
• Generic in that it does not dictate specific formats
• Internet Security Association and Key Management Protocol
(ISAKMP)
• Provides a framework for Internet key management and
provides the specific protocol support, including formats, for
negotiation of security attributes
• Consists of a set of message types that enable the use of a
variety of key exchange algorithms
 ISAKMP
• NSA-designed protocol to exchange security
parameters (but not establish keys)
• Protocol to establish, modify, and delete IPSEC
security associations
• Provides a general framework for exchanging
cookies, security parameters, and key management
and identification information
• Exact details left to other protocols
• Two phases
• 1. Establish secure, authenticated channel (“SA”)
• 2. Negotiate security parameters (“KMP”)
 Oakley

• Exchange messages containing any of

• Client/server cookies
• DH information
• Offered/chosen security parameters
• Client/server ID’s
• until both sides are satisfied
• Oakley is extremely open-ended, with many variations
possible
• Exact details of messages exchange depends on exchange
requirements
• Speed vs thoroughness
• Identification vs anonymity
• New session establishment vs rekey
• D-H exchange vs shared secrets vs PKC-based exchange
 IKE (ISAKMP/Oakley)

• ISAKMP merged with Oakley

• ISAKMP provides the protocol framework
• Oakley provides the security mechanisms

• Combined version clarifies both protocols, resolves

ambiguities
 IKE (ISAKMP/Oakley)
• Phase 1 example
Client Server
Client cookie
Client ID
Key exchange information →
 Server cookie
Server ID
Key exchange information
Server signature
Client signature →
• Other variants possible (data spread over more messages, authentication
via shared secrets)
• Above example is aggressive exchange which minimizes the number
of messages
 IKE (ISAKMP/Oakley)
• Phase 2 example
Client Server
Encrypted, MAC’d
Client nonce
Security parameters
Offered →
 Encrypted, MAC’d
Server nonce
Security parameters
accepted
Encrypted, MAC’d
Client nonce
Server nonce →
 IPSEC Algorithms
• DES in CBC mode for encryption
• HMAC/MD5 and HMAC/SHA (truncated to 96
bits) for authentication
• Later versions added optional, DOI-dependent
algorithms
• 3DES
• Blowfish
• CAST-128
• IDEA
• RC5
• Triple IDEA (!!!)
 Cookies
• Cookie based on IP address and port, stops flooding
attacks
• Attacker requests many key exchanges and bogs down host
(clogging attack)

• Cookie depends on
• IP address and port
• Secret known only to host
• Cookie = hash( source and dest IP and port + local secret )

• Host can recognize a returned cookie

• Attacker can’t generate fake cookies
 Features of IKE Key
Determination
• Algorithm is characterized by five important features:

• It employs a mechanism known as cookies to thwart clogging attacks

1.

• It enables the two parties to negotiate a group; this is, in essence,

2. specifies the global parameters of the Diffie-Hellman key exchange

• It uses nonces to ensure against replay attacks

3.

• It enables the exchange of Diffie-Hellman public key values

4.

• It authenticates the Diffie-Hellman exchange to thwart man-in-the-

5. middle-attacks
 Table 9.3
IKE Payload Types
Table 9.4 Cryptographic Suites for IPsec
 Summary
• IP security overview • Encapsulating security payload
• Applications of IPsec • ESP format
• Benefits of IPsec • Encryption and authentication
• Routing applications algorithms
• IPsec documents • Padding anti-replay service
• IPsec services • Transport and tunnel modes
• Transport and tunnel modes
• Header Authentication (AH)
• IP security policy
• Combining security associations
• Security associations
• Authentication plus confidentiality
• Security association database
• Basic combinations of security
• Security policy database associations
• IP traffic processing
• Internet key exchange
• Cryptographic suites • Key determination protocol
• Header and payload formats
 Homework

• Chapter 9: Problems 9.5, 9.6, 9.7 and 9.8

• Due: Wednesday, 12/6