Module 4

Network & Application Security

Outline

Kerberos
X.509 Authentication Service
IP security Architecture
Secure socket layer
Electronic mail security
Pretty Good privacy
S/MIME
Secure Electronic Transactions
Firewalls

KERBEROS

In Greek mythology, a many headed dog, the

guardian of the entrance of Hades
3

KERBEROS
Is an authentication service

Used in an open distributed environment in

which users at workstation access services on
servers distributed over the network
Only restricted access is allowed
4

KERBEROS
Users wish to access services on servers.
Three threats exist:
User pretend to be another user.
User alter the network address of a workstation.
User eavesdrop on exchanges and use a replay
attack.

KERBEROS
a centralized authentication server (Kerberos) which
authenticates
Users to servers
Servers to users

Relies on conventional encryption, making no use of

public-key encryption
Two versions: version 4 and 5
Version 4 makes use of DES
Version 5 corrects some of the security deficiencies of
Version 4
6

Why KERBEROS?
If a set of users is provided with dedicated personal
computers that have no network connections, then a
users resources can be protected by securing each
computer
But now we use distributed architecture consisting
of dedicated user workstation (clients) and
distributed or centralized servers
7

In this, 3 approaches to security can be envisioned

Rely on each individual client workstation to
assure the identity of its user or users and rely on
each server to enforce a security policy based on
user identification (ID).

Require that client systems authenticate themselves

to servers.
Require the user to prove identity for each service
invoked. Also require that servers prove their
identity to clients.(kerberos provide this)
8

Kerberos Requirements
first published report identified its requirements
as:
secure-an eavesdropper shouldnt be able to get enough
information to impersonate the user
reliable- services using Kerberos would be unusable if
Kerberos isnt available
transparent-users should be unaware of its presence,
beyond the requirement to enter a password
scalable- should support large number of users

Kerberos Version 4
Terms:

C = Client
AS = authentication server
V = server
IDc = identifier of user on C
IDv = identifier of V
Pc = password of user on C
ADc = network address of C
Kv = secret encryption key shared by AS and V
TS = timestamp
|| = concatenation
10

Kerberos
In an unprotected network environment, any
client can apply to any sever for service
Risk is impersonation
To counter this, servers must be able to confirm
the identities of clients who request the service
Each server can be required to undertake this
task for each client/server interaction

11

Kerberos
An alternative is to use an AS that knows
the password of all users and store in a
centralized d/b
AS shares a unique secret key with each
server

12

A Simple Authentication Dialogue

(1) C AS:
(2) AS C:
(3) C V:

IDc || Pc || IDv
Ticket
IDc || Ticket

Ticket = E(Kv,[IDc || ADc || IDv])

Since the ticket is encrypted it cannot be altered by C or
by any opponent

C V: V decrypts the ticket and verifies that the

user ID in the ticket is the same as the unencrypted
user ID in the message
Ticket is valid only if it is transmitted from same
13
workstation.thats why ADc is included

Kerberos Version 4: Dialog 1- Simple

Pc=password of client

kv=Secret Key between AS and V (Server)

Ticket=Ekv[IDc,ADc,IDv]

Kerberos
A more Secure Authentication Dialogue
Simple authentication dialogues problem
Too many times that user has to enter a password
User need a new ticket for every different service

Plaintext transmission of the password(in msg 1)

M1: C AS:
IDc || Pc || Idv

Solution-a new server

TGS(Ticket Granting Server)-issues ticket to users
who have been authenticated to AS

 sending usernames and passwords in the clear

jeopardizes the security of the network.
each time a password is sent in the clear, there is a
chance for interception.

16

Kerberos
A more Secure Authentication Dialogue
Once per user logon session

1.C AS : IDC , IDtgs( request to use TGS service)

2.AS C : Ekc [Tickettgs] (responds with a ticket
encrypted with a key derived from users password)
Tickettgs = E(ktgs [IDC,ADC,IDtgs, TS1,Lifetime1])

Client module asks user for the password to decrypt the

Tickettgs
If password is correct the ticket is successfully recovered

This method avoids transmitting the password as plaintext

A more Secure Authentication

Dialogue
Client request ticket granting ticket[Tickettgs] from the
AS which is saved for later use

Tickettgs = E(ktgs [IDC,ADC,IDtgs, TS1,Lifetime1])

Ticket consists of ID and the network address of the user
and the ID of TGS
Each time when user requires access to new service, the
client applies to the TGS using the ticket [Tickettgs ] to
authenticate itself

A more Secure Authentication Dialogue

Once per type of service

3.C TGS : IDC , IDV , Tickettgs

TGS decrypts the ticket and verifies the ID. It also checks the
lifetime of ticket. If ID and n/w address matches, the user is
authenticted.
If user is permitted to access the server V,TGS issues Ticketv to
access the server V

4.TGS C : Ticketv
Ticketv = EKv[IDC,ADC,IDV,TS2,Lifetime2]

A more Secure Authentication Dialogue

Once per service session

5.C V : IDC , Ticketv

Cleint module request service on behalf of user.

For this client transmits a message to the server containing
user ID and service granting ticket
Server authenticates by using the contents of the ticket
Tickettgs = Ektgs [IDC,ADC,IDtgs, TS1,Lifetime1]
Ticketv = EKv[IDC,ADC,IDV,TS2,Lifetime2]
20

 Once per user logon session

1.C AS : IDC , IDtgs( request to use TGS

service)
2.AS C : Ekc [Tickettgs] (responds with a ticket
encrypted with a key derived from users
password)
Once per type of service

3.C TGS : IDC , IDV , Tickettgs

4.TGS C : Ticketv
Once per service session

5.C V : IDC , Ticketv

Tickettgs = Ektgs [IDC,ADC,IDtgs, TS1,Lifetime1]

Ticketv = EKv[IDC,ADC,IDV,TS2,Lifetime2]
21

Kerberos Version 4 : Dialog 2-More

Secure
ticketTGS=EKtgs[IDc,ADc,
Once per user
logon session

IDtgs,TS1,LifeTime1 ]
Once per type of
service

4-TicketV

Kerberos Version 4 : Dialog 2

- More Secure
Cont.
Once per service session

5- TicketV+ IDc

TicketV=EKv[IDc,ADc,IDv,Ts2,Lifetime2]

Version 4 Authentication Dialogue

Problems:
Lifetime associated with the ticket-granting ticket
If too short repeatedly asked for password
If too long greater opportunity to replay

The threat is that an opponent will steal the ticket and use
it before it expires
TGS or an application service must be able to prove that the person
using a ticket is the same person to whom that ticket was issued

24

Version 4 Authentication Dialogue

Opponent will steal the ticket and use before it expires
Let AS provide both the client and TGS with a secret
information in a secure manner
Referred to as session key
Authentication Service Exhange: To obtain Ticket-Granting Ticket
(1) C AS:
IDc || IDtgs ||TS1
(2) AS C:
E(Kc ,[Kc,tgs|| IDtgs || TS2 || Lifetime2 ||
Tickettgs])
Tickettgs = E(Ktgs,[Kc,tgs,IDC,ADC,IDtgs,TS2, Lifetime2])

AS responds with message encrypted with key derived

from users password that contains Tickettgs
Encrypted message also contains a copy of session key
kc,tgs(Session key for C and TGS)

 Since session key is inside the message encrypted

with kc only users client can read it
Now C is ready to approach TGS
Ticket-Granting Service Echange: To obtain Service-Granting Ticket
(3) C TGS:

IDv || Ticket

(4) TGS C:

E(Kc,tgs [Kc,v|| IDv || TS4 || Ticket ])

v

tgs

|| aunthenticator

Ticket = E(k [K ,ID ,AD ,ID ,TS ,L-time ]

v
v, c,v C
C v 4
4
Authenticator = E
[ID ,AD ,TS ]
c
Kc,tgs C
C 3
Ticket says anyone who uses Kc,tgs must be C. TGS uses session key to decrypt
authenticator

(4)TGS C:
E(Kc,tgs [Kc,v|| IDv || TS4 || Ticketv])
Message is encrypted with session key shared by
TGS and C
includes a session key to be shared between C and
the server V
Id of V and TS
Ticket for V

27

Client/Server Authentication Exhange: To Obtain Service

(5) C V:
Ticketv || Aunthenticator
c
(6) V C:
E(Kc,v[TS5 +1])

C presents the ticket and the authnticator

Server decrypt the ticket, recover the session key
and decrypt the authenticator
Authenticatorc = EKc,v[IDC,ADC,TS5]
Ticketv = E(Kv,[Kc,v,IDC,ADC,IDv,TS4,L-time4])
Server returns the value of timestamp from the
authenticator incremented by 1 and encrypted with
session key

Kerberos
The version4 Authentication Dialogue
1. C -> AS :IDC,IDTGS,TS1
2. AS -> C : Ekc[Kc,tgs,IDtgs,TS2,L-time2,Tickettgs]
Tickettgs = EKtgs[Kc,tgs,IDC,ADC,IDtgs,TS2,L-time2]
3. C -> TGS : IDV,TicketTGS,Authenticatorc
4. TGS -> C : EKc,tgs[Kc,v,IDv,TS4,TicketV]
Ticketv = EKv[Kc,v,IDC,ADC,IDv,TS4,L-time4]
Authenticatorc = EKc,tgs[IDC,ADC,TS3]
5. C -> K : TicketV,Authenticatorc
6. K -> C : EKc,v[TS5 +1]
Authenticatorc = EKc,v[IDC,ADC,TS5]

Ticket Granting
Server

Kerberos
Database

Authentication
Server
Kerberos Key Distribution Service

Server
Server
Server
Server

Workstation

Kerberos

The version4 Authentication Dialogue

1.
2.
3.
4.
5.
6.

Client requests ticket-granting ticket

AS returns ticket-granting ticket
Client requests service-granting ticket
TGS returns service-granting ticket
Client requests service
Optional authentication of server to client

Kerberos: The Version 4

Authentication Dialog
Once per user logon session
ticketTGS=E(Ktgs, [Kc,tgs,
IDc,ADc,IDtgs,TS2, LifeTime2 ]

1- IDc + IDtgs +TS1

2- E(Kc ,[Kc,tgs,IDtgs,Ts2,

Lifetime2,TicketTGS]

KERBEROS

Kerberos: The Version 4 Authentication

Dialog Cont.
Once per type of service
ticketTGS=E(Ktgs [Kc,tgs,IDc,ADc,IDtgs,
TS2, LifeTime2 ])
AuthenticatorC=E(Kc,tgs[IDc,ADc,TS3]
ticketV=E(Kv[Kc,v,Idc,ADc,IDv, TS4,
LifeTime4 ])

3- TicketTGS + AuthenticatorC
+ IDv
4-E(kc,tgs[kc,v,IDv,Ts4,Ticketv])

KERBEROS

Kerberos: The Version 4

Authentication Dialog Cont.
Once per service session

5- TicketV+ AuthenticatorC

6- E(kc,v[TS5+1])
TicketV=E(Kv [Kv,c, IDc, ADc, IDv, TS4, Lifetime4])
AuthenticatorC=Ekc,v [IDc,ADc,TS5]

The version4 Authentication

Dialogue

35

Tickets:
Contains information which must be considered
private to the user
Allows user to use a service or to access TGS
Reusable for a period of particular time
Used for distribution of keys securely

36

Authenticators

Proves the clients identity

Proves that user knows the session key
Prevents replay attack
Used only once and has a very short life time
One authenticator is typically built per session
of use of a service
37

Kerberos Realms and Multiple

Kerberi
A single administrative domain includes:
a Kerberos server
a number of clients, all registered with server
application servers, sharing keys with server

What will happen when users in one realm need

access to service from other realms?:
Kerberos provide inter-realm authentication

 The Kerberos server must have the user ID (UID)

and hashed password of all participating users in
its database. All users are registered with the
Kerberos server.
The Kerberos server must share a secret with each
server. All servers are registered with the Kerberos
server.
Such an environment is referred to as realm.
39

Inter-realm Authentication:
Kerberos server in each realm shares a secret key
with other realms.
It requires
Kerberos server in one realm should trust the one in
other realm to authenticate its users
The second also trusts the Kerberos server in the first
realm
40

Request for Service in Another

Realm

41

Request for Service in another realm:

7-request for remote service

4-Ticket for remote TGS

5-Request ticket for remote server
6-Ticket for remote server

Kerberos Realms and Multiple

Kerberi
1. Request ticket for local TGS
2. Ticket for local TGS
3. Request ticket for remote TGS
4. Ticket for remote TGS
5. Request ticket for remote server

6. Ticket for remote server

7. Request remote service
43

 Realm
Indicates realm of the user

Options
Times
From: the desired start time for the ticket
Till: the requested expiration time
Rtime: requested renew-till time

Nonce
A random value to assure the response is fresh

Kerberos Version 5 Message Exchange:1

To obtain ticket-granting ticket:

(1)C AS : Options || IDc || Realmc || IDtgs ||Times ||
Nonce1
(2) AS C : Realmc || IDc || Ticket tgs ||
EKc [ Kc,tgs || IDtgs || Times || Nonce1 ||| Realm tgs ]

Ticket tgs= EKtgs [ Flags || Kc,tgs || Realm c ||

IDc || ADc || Times]

Kerberos Version 5 Message Exchange:2

To obtain service-granting ticket :
(3)C TGS : Options || IDv || Times || Nonce2 || Ticket tgs
Authenticator c
(4)TGS C : Realmc || IDc || Ticket v || EK c,tgs [ Kc,v Times||
Nonce2 || IDv Realm v]
Ticket tgs= EKtgs [ Flags || Kc,tgs || Realm c || IDc || ADc ||

Times]
Ticket v : EK v [Kc,,v Realmc || IDc ADc Times ]
Authenticator c : EK c,tgs [IDc Realmc TS1]

Kerberos Version 5 Message Exchange:3

To obtain service
(5) C S : Options || Ticket v|| Authenticator c
(6) S C : EK c,v [TS2|| Subkey || Seq# ]

Ticket v : EK v [Flags || Kc,v || Realmc ||

IDc || ADc || Times ]
Authenticator c : EK c,v [IDc || Realmc ||
TS2 || Subkey|| Seq# ]

KERBEROS Version 5 versus Version4

Environmental shortcomings of Version 4:
Encryption system dependence: DES
Any encryption algorithms can be used in v5 but only DES
is possible in v4

Internet protocol dependence

Only IP is possible to use any internet protocol

Ticket lifetime
1280 minutes (maximum time) any length of time

 Authentication forwarding
V4 does not allow credentials issued to one client to be
forwarded to some other host and used by some other
client. V5 provides this capability.
i.e server can forward authentication to another server

Inter-realm authentication

Technical deficiencies

Double encryption in V4.

PCBC encryption
In v5, Standard CBC is used
Password attack
Session Keys- each ticket includes a session key
that is used by the client.

Kerberos Version 5 Message Exchange:1

To obtain ticket-granting ticket:

(1)C AS : Options || IDc || Realmc || IDtgs ||Times ||
Nonce1
(2) AS C : Realmc || IDc || Ticket tgs ||
EKc [ Kc,tgs || IDtgs || Times || Nonce1 ||| Realm tgs ]

Kerberos : Strengths
User's passwords are never sent across the network,
encrypted or in plain text
Secret keys are only passed across the network in
encrypted form
Client and server systems mutually authenticate
It limits the duration of their users' authentication.
Authentications are reusable and durable
Kerberos has been scrutinized by many of the top
programmers, cryptologists and security experts in
the industry
51

Kerberos - in practice

Currently have two Kerberos versions:

4 : restricted to a single realm
5 : allows inter-realm authentication
Kerberos v5 is an Internet standard
specified in RFC1510, and used by many utilities
To use Kerberos:
need to have a KDC on your network
need to have Kerberised applications running on all participating systems
major problem - US export restrictions
Kerberos cannot be directly distributed outside the US in source format
else crypto libraries must be re-implemented locally

Certificate:
Electronic counterparts to driver licenses,
passports
Verifies authenticity of the public key
Prevents impersonation
Enables individuals and organizations to
secure business and personal transactions

53

Certificate Authorities:
Trusted entity which issue and manage
certificates for a population of public-private
key-pair holders.
A digital certificate is issued by a CA and is
signed with CAs private key.

54

Certificate Issuance Process:

Generate public/private key pair

Sends public key to CA
Proves identity to CA - verify
CA signs and issues certificate
CA e-mails certificate or Requestor
retrieves certificate from secure websites
Requestor uses certificate to demonstrate
legitimacy of their public key

Types of Digital Certificates

E-Mail Certificates
Browser Certificates
Server (SSL) Certificates
Software Signing Certificates

 A certificate is a document that contains both an

identity and a public key, binding them together
by a digital signature.
This digital signature is created by an
organisation called a Certification Authority
(CA).
This organisation guarantees that upon creating
the digital signature it has checked the identity
of the public key owner (e.g. by verifying a
passport) and that is has checked that this public
key owner is in possession of the corresponding
private key.
57

 Anybody in possession of the CA's public key

can verify the CA's signature on the certificate.
In this way the CA guarantees that the public key
in the certificate belongs to the individual whose
identity is in the same certificate.

58

What a certificate includes:

Name of Entity being Certified

Public Key
Name of Certificate Authority
Serial Number
Expiration Date
Digital signature of the issuer
Other information (optional)
59

Who are the Certificate Authorities?

VeriSign
GTE CyberTrust
Entrust
CertCo
USPS / Cylink

Block Diagrams of
Certification Process
3
Certificate
Authority
CA

Repository
Dbase

Receiving
Party

Subscriber
4

X.509 Authentication Service

Distributed set of servers that maintains a
database about users.
Each certificate contains the public key of a
user and is signed with the private key of a
CA.
Is used in S/MIME, IP Security, SSL and
SET.
RSA is recommended to use.
62

63

X.509 Formats

X.509 Certificate format

Version

Notation to define a certificate:

Serial number
Algorithm
Parameters

Algorithm
identifier

Period of
validity

Subject
Algorithm
Parameter
Key

Signature

where
Y<<X>>= the certificate of user X issued by
certification authority Y

Issuer
Not before
Not after

CA<<A>>=CA{V,SN,AI,CA,Ta,A,Ap}

Subjects
public key

Y{I}=the signing of I by Y. It consists of I with

an enciphered hash code appended.

X.509 Certificates
issued by a Certification Authority (CA), containing:
version (1, 2, or 3)
serial number (unique within CA) identifying certificate
signature algorithm identifier algorithm used to sign
the certificate
issuer X.500 name (CA)
period of validity (from - to dates)
subject X.500 name (name of owner-public key holder)
subject public-key info (algorithm, parameters, key)
issuer unique identifier (v2+)
subject unique identifier (v2+)
extension fields (v3)
signature (of hash of all fields in certificate encypted
with CAs private key)
notation CA<<A>> denotes certificate for A signed by CA

Obtaining a Certificate
any user with access to CA can get any
certificate from it
only the CA can modify a certificate
because cannot be forged, certificates can be
placed in a public directory

CA Hierarchy
if both users share a common CA then they are assumed
to know its public key
otherwise CA's must form a hierarchy
use certificates linking members of hierarchy to validate
other CA's
each CA has certificates for clients (forward) and parent
(backward)

each client trusts parents certificates

enable verification of any certificate from one CA by
users of all other CAs in hierarchy
68

69

Securely Obtain a Public Key

Scenario:
A has obtain a certificate from the CA X1
B has obtain a certificate from the CA X2
A can read the Bs certificate but cannot verify it.

X.509 CA Hierarchy
A acquires B certificate
using chain:
X<<W>>W<<V>>V<<Y
>>Y<<Z>> Z<<B>>
B acquires A certificate
using chain:

Z<<Y>>Y<<V>>V<<W>
>W<<X>> X<<A>>

Forward Certificate: Certificate of X generated by other

CAs

Reverse Certificates: Certificates generated by X for

another CA

72

73

Certificate Revocation

certificates have a period of validity

may need to revoke before expiry, eg:
1. user's private key is compromised
2. user is no longer certified by this CA
3. CA's certificate is compromised

CAs maintain list of revoked certificates

the Certificate Revocation List (CRL)

users should check certificates with CAs CRL

74

Authentication Procedures
X.509 includes three alternative
authentication procedures:
One-Way Authentication
Two-Way Authentication
Three-Way Authentication
all use public-key signatures
75

Authentication Procedures:
Three alternative authentication procedures:
One-Way Authentication
Two-Way Authentication
Three-Way Authentication

All use public-key signatures

76

One-Way Authentication:
1 message ( A->B) used to establish
the identity of A and that message is from A
message was intended for B
message must include timestamp, nonce, B's
identity and is signed by A
integrity & originality of message
1-A {ta,ra, IDb,sgnData, E[PUb,Kab]}
B

Ta-timestamp rA=nonce IDb =identity

sgnData=signed with As private key
nonce is an abbreviation of number used once

Two-Way Authentication
2 messages (A->B, B->A) which also
establishes in addition:
the identity of B and that reply is from B
that reply is intended for A
integrity & originality of reply
1-A {ta,ra,B,sgnData,E[PUb,Kab]}
A

B
2-B {tb,rb,A,sgnData, E[PUa,Kab]}

78

Three-Way Authentication
3 messages (A->B, B->A, A->B) which
enables above authentication without
synchronized clocks
1- A {ta,ra,B,sgnData, E[PUb,Kab]}
A

2 -B {tb,rb,A,sgnData, E[PUa,Kab]}

3- A{rb}

79

Firewalls

80

Outline
Firewall Design Principles
Firewall Characteristics
Types of Firewalls
Firewall Configurations

81

Firewalls
Effective means of protecting a local system
or network of systems from network-based
security threats while affording access to
the outside world via WAN`s or the Internet

82

Firewall Design
Principles
Information systems undergo a steady evolution
(from small LAN`s to Internet connectivity)
Strong security features for all workstations and
servers not established

83

Firewall Design
Principles
The firewall is inserted between the premises
network and the Internet
Aims:
Establish a controlled link
Protect the premises network from Internet-based
attacks
Provide a single choke point
84

Firewall Characteristics
Design goals:
All traffic from inside to outside must pass
through the firewall (physically blocking all
access to the local network except via the
firewall)
Only authorized traffic (defined by the local
security policy) will be allowed to pass

85

Firewall Characteristics
Design goals:
The firewall itself is immune to penetration

86

Firewall Characteristics
Four general techniques:
Service control
Determines the types of Internet services that can be
accessed
Firewall may filter traffic on the basis of IP address
and TCP port number

Direction control
Determines the direction in which particular service
requests are allowed to flow
87

Firewall Characteristics
User control
Controls access to a service according to which
user is attempting to access it

Behavior control
Controls how particular services are used (e.g.
filter e-mail to eliminate spam)

88

Types of Firewalls
common types of Firewalls:

Application-level gateways
Circuit-level gateways
Packet-filtering routers
Bastion Host

89

Types of Firewalls
Application-level Gateway

User contacts the gateway using TCP/IP application such as

telnet or ftp, and gateway asks for name of remote host to be
accessed
When user responds with valid user ID and authentication
information, gateway contacts the application on remote
host and relays TCP segments containing application data
between two end points

Types of Firewalls
Application-level Gateway
Also called proxy server
Acts as a relay of application-level traffic

91

Types of Firewalls
Advantages:
Higher security than packet filters
Only need to scrutinize a few allowable
applications
Easy to log and audit all incoming traffic

Disadvantages:
Additional processing overhead on each
connection
92

Types of Firewalls
Circuit-level Gateway

93

Types of Firewalls
Circuit-level Gateway
Stand-alone system or
Specialized function performed by an
Application-level Gateway
Sets up two TCP connections
The gateway typically relays TCP segments
from one connection to the other without
examining the contents
94

Types of Firewalls
Circuit-level Gateway
The security function consists of determining
which connections will be allowed
Typically use is a situation in which the system
administrator trusts the internal users

95

Types of Firewalls
Packet-filtering Router

96

Types of Firewalls
Packet-filtering Router
Applies a set of rules to each incoming IP
packet and then forwards or discards the packet
Filter packets going in both directions
The packet filter is typically set up as a list of
rules based on matches to fields in the IP or
TCP header
Two default policies (discard or forward)
97

Types of Firewalls
Advantages:
Simplicity
Transparency to users
High speed

Disadvantages:
Difficulty of setting up packet filter rules
Lack of Authentication
98

Types of Firewalls
Possible attacks and appropriate countermeasures
IP address spoofing(intruder transmits packets from the
outisde with a source IP address field containing an
address of an internal host)
Counter measure
discard outside packets that contain an inside
source address.
Source routing attacks(Source specifies a route that a
packet should take.)
Counter measure
Discard all packets with this option.
99

Tiny fragment attacks

Intruder uses IP fragmentation option to create
extremely small fragments.
Forces TCP header information into a separate packet
fragment.
Designed to circumvent filtering rules that depend on
TCP header information(a packet filter makes filtering
decision on the first fragment of a packet)
Only the first fragment will be examined by the filtering
router.
All subsequent fragments are filtered out on the basis
that they are part of first fragment
Counter measure
Discard all such packets
strictly enforce minimum fragment size requirements

Packet filtering router uses the following information for

filter rules

Source IP address: The IP address of the system

that originated the IP packet
Destination IP address: The IP address of the system
the IP packet is trying to reach
Source and destination transport-level address:The
transport level port number, which defines
applications such as SNMP or TELNET
IP protocol field: Defines the transport protocol
Interface:For a router with 3 or more ports, which
interface of the router the packet came from or

Bastion Host
A system identified by the firewall administrator as
a critical strong point in the networks security
The bastion host serves as a platform for an
application-level or circuit-level gateway

102

Firewall Configurations
In addition to the use of simple configuration of
a single system (single packet filtering router or
single gateway), more complex configurations
are possible
Three common configurations

103

Firewall Configurations
Screened host firewall system (singlehomed bastion host)

104

Firewall Configurations
Screened host firewall, single-homed
bastion configuration
Firewall consists of two systems:
A packet-filtering router
A bastion host

105

Firewall Configurations
Configuration for the packet-filtering router:
Only packets from and to the bastion host are
allowed to pass through the router

The bastion host performs authentication

and proxy functions

106

Firewall Configurations
Screened host firewall system (dual-homed
bastion host)

107

Firewall Configurations
Screened host firewall, dual-homed bastion
configuration
The packet-filtering router is not completely
compromised
Traffic between the Internet and other hosts on
the private network has to flow through the
bastion host

108

Firewall Configurations
Screened-subnet firewall system

109

Firewall Configurations
Screened subnet firewall configuration
Most secure configuration of the three
Two packet-filtering routers are used
Creation of an isolated sub-network

110

IP Security

112

Outline

IP Security Overview
IP Security Architecture
Authentication Header
Encapsulating Security Payload

IPsec
Internet Protocol Security (IPsec) is a protocol
suite for securing IP communications by
authenticating and encrypting each IP packet of a
communication session.

IP Security Overview
IP security (IPSec) is a capability that can be added to
either current version of the Internet Protocol (IPv4 or
IPv6), by means of additional headers.
IPSec encompasses three functional areas: authentication,
confidentiality, and key management.

Authentication makes use of the HMAC message

authentication code. Authentication can be applied
to the entire original IP packet (tunnel mode) or to
all of the packet except for the IP header (transport
mode).
115

 Confidentiality is provided by an encryption

format known as encapsulating security
payload(ESP).
IPSec defines a number of techniques for
key management.

116

IPv4 Header

Internet Header Length-IHL

117

IPv6 Header

IP Security Overview
IPSec is not a single protocol. Instead, IPSec
provides a set of security algorithms plus a
general framework that allows a pair of
communicating entities to use whichever
algorithms provide security appropriate for
the communication.

119

IP Security Overview
Applications of IPSec
Secure branch office connectivity over the
Internet
Secure remote access over the Internet
Establsihing extranet and intranet connectivity
with partners
Enhancing electronic commerce security

121

IP Security Scenario

IP Security Overview
Benefits of IPSec
Transparent to applications (below transport layer (TCP,
UDP)
Provide security for individual users

IPSec can assure that:

A router(a new router advertises its presence) or neighbor
advertisement comes from an authorized router
A redirect message comes from the router to which the
initial packet was sent
A routing update is not forged

IP Security Architecture
IPSec documents:
RFC 2401: An overview of security
architecture
RFC 2402: Description of a packet encryption
extension to IPv4 and IPv6
RFC 2406: Description of a packet emcryption
extension to IPv4 and IPv6
RFC 2408: Specification of key managament
capabilities
124

IPSec Document Overview

125

 Architecture: Covers the general concepts, security

requirements, definitions, and mechanisms defining
IPSec technology.
Encapsulating Security Payload (ESP): Covers
the packet format and general issues related to the
use of the ESP for packet encryption and, optionally,
authentication.
Authentication Header (AH): Covers the packet
format and general issues related to the use of AH
for packet authentication.

 Encryption Algorithm: A set of documents that describe

how various encryption algorithms are used for ESP.
Authentication Algorithm: A set of documents that
describe how various authentication algorithms are used for
AH and for the authentication option of ESP.

Key Management: Documents that describe key

management schemes.
Domain of Interpretation(DOI): Contains values needed
for the other documents to relate to each other. These
include identifiers for approved encryption and
authentication algorithms, as well as operational parameters
such as key lifetime.

IPSec Services

Access Control
Connectionless integrity
Data origin authentication
Rejection of replayed packets
Confidentiality (encryption)

128

Tunnel mode
In tunnel mode, the entire IP packet is encrypted
and/or authenticated. It is then encapsulated into
a new IP packet with a new IP header
Before applying AH

129

Tunnel Mode (AH

Authentication)

130

Transport mode
In transport mode, only the payload (the data you
transfer) of the IP packet is usually encrypted
and/or authenticated. The routing is intact, since
the IP header is neither modified nor encrypted

131

Transport mode

A TCP segment or a UDP is first encrypted and

then encapsulated in an IPv6 packet

Tunnel mode
The

entire IP datagram with its base header and extension

headers is encrypted and then encapsulated in a new packet
using the ESP extension header. In other words, you have
two base headers: one encrypted, one not.

Security Associations (SA)

Key concept that appears in both authentication
and confdentaility mechanisms for IP
provide the bundle of algorithms and data that
provide the parameters necessary to operate the
AH and/or ESP operations
Identified by three parameters:
Security Parameter Index (SPI)
IP Destination address
Security Protocol Identifier(AH or ESP)

Transport Mode
SA

Tunnel Mode
SA

AH

Authenticates IP payload and Authenticates entire inner

selected portions of IP header IP packet plus selected
and IPv6 extension headers
portions of outer IP
header

ESP

Encrypts IP payload and any

IPv6 extesion header

Encrypts inner IP packet

ESP with
authentication

Encrypts IP payload and any

IPv6 extesion header.
Authenticates IP payload but
no IP header

Encrypts inner IP packet.

Authenticates inner IP
packet.

135

Authentication Header
Provides support for data integrity and authentication of IP
packets.
Guards against replay attacks.

136

 Next header(8 bits):Identifies the type of

header immediately following this header.
Payload length(8 bits):Length of authentication
header
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 that contains the Integrity Check Value.

Before applying AH

138

Transport Mode (AH

Authentication)

139

Tunnel Mode (AH

Authentication)

140

Anti-replay service
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
sequence number field is designed to thwart such
attacks.
Sender initializes sequence number counter to 0

Integrity check value

The authentication data field holds a value referred
to as the integrity check value. The ICV is a
message authentication code or a truncated version
of a code produced by a MAC algorithm.

Encapsulating Security Payload

ESP provides confidentiality services

143

 Security parameters index(32 bits): Identifies a

security association.
Sequence number(32 bits):A monotonically
increasing counter value;this provides an antireplay function,as 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):The padding field serves several

purposes:
If an encryption algorithm requires the plain text to be a
multiple of some number of bytes the padding field is used
to expand the plain text to the required length.
The ESP format requires that the cipher text 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.
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.

 Authentication data(variable):A variable

length field that contains the Integrity
Check Value computed over the ESP
packet minus the authentication data
field.

Encryption and Authentication

Algorithms
Encryption:

Three-key triple DES

RC5
IDEA
Three-key triple IDEA
Blowfish

Authentication:
HMAC-MD5-96
HMAC-SHA-1-96
147

ESP Encryption and Authentication

148

 Transport mode ESP is used to encrypt and

optionally authenticate the data carried by IP.
For this mode using IPv4, the ESP header is
inserted into the IP packet immediately prior to
the transport layer header and an ESP trailer is
placed after the IP packet.
In the context of IPv6, ESP is viewed as an endto-end payload ; that is it is not examined or
processed by intermediate routers. Therefore
the ESP header appears after the IPv6 base
header and the hop-by-hop, routing and
fragment extension headers

ESP Encryption and

Authentication

150

Tunnel mode ESP

is used to encrypt the entire IP packet .
For this mode the ESP header is prefixed
to the packet and then the packet plus the
ESP trailer is encrypted.

Electronic mail security

152

Outline
Pretty good privacy
S/MIME

153

Pretty Good Privacy

Philip R. Zimmerman is the creator of PGP.
PGP provides a confidentiality and
authentication service that can be used for
electronic mail and file storage applications.

154

Why Is PGP Popular?

It is availiable free on a variety of
platforms.
Based on well known algorithms.
Wide range of applicability
Not developed or controlled by
governmental or standards organizations

155

Operational Description
Consist of five services:

Authentication
Confidentiality
Compression
E-mail compatibility
Segmentation

156

157

Compression
PGP compresses the message after applying
the signature but before encryption
The placement of the compression
algorithm is critical.
The compression algorithm used is ZIP

158

E-mail Compatibility
The scheme used is radix-64 conversion (see
appendix 5B).
The use of radix-64 expands the message by
33%.

159

Segmentation and Reassembly

Often restricted to a maximum message
length of 50,000 octets.
Longer messages must be broken up into
segments.
PGP automatically subdivides a message
that is to large.
The receiver strip of all e-mail headers and
reassemble the block.
160

Sumary of PGP Services

Function

Algorithm Used

Digital Signature DSS/SHA or

RSA/SHA
Message
CAST or IDEA or
Encryption
three-key triple DES
with Diffie-Hellman
or RSA
Compression
ZIP
E-mail
Radix-64 conversion
Compatibility
Segmentation
-

161

162

Format of PGP Message

163

164

165

166

The Use of Trust

Key legitimacy field
Signature trust field
Owner trust field
See Table 5.2

(W. Stallings)

167

168

Revoking Public Keys

The owner issue a key revocation
certificate.
Normal signature certificate with a revote
indicator.
Corresponding private key is used to sign
the certificate.

169

S/MIME
Secure/Multipurpose Internet Mail
Extension
S/MIME will probably emerge as the
industry standard.
PGP for personal e-mail security

170

Simple Mail Transfer Protocol

(SMTP, RFC 822)
SMTP Limitations - Can not transmit, or has a
problem with:
executable files, or other binary files (jpeg image)
national language characters (non-ASCII)
messages over a certain size
ASCII to EBCDIC translation problems
lines longer than a certain length (72 to 254 characters)

171

Header fields in MIME

MIME-Version: Must be 1.0 -> RFC 2045, RFC 2046

Content-Type: More types being added by developers

(application/word)

Content-Transfer-Encoding: How message has been

encoded (radix-64)
Content-ID: Unique identifying character string.
Content Description: Needed when content is not
readable text (e.g.,mpeg)

172

S/MIME Functions
Enveloped Data: Encrypted content and
encrypted session keys for recipients.
Signed Data: Message Digest encrypted with
private key of signer.
Clear-Signed Data: Signed but not encrypted.

Signed and Enveloped Data: Various orderings

for encrypting and signing.
173

Algorithms Used
Message Digesting: SHA-1 and MDS
Digital Signatures: DSS

Secret-Key Encryption: Triple-DES, RC2/40

(exportable)
Public-Private Key Encryption: RSA with key
sizes of 512 and 1024 bits, and Diffie-Hellman
(for session keys).
174

User Agent Role

S/MIME uses Public-Key Certificates - X.509 version 3
signed by Certification Authority
Functions:
Key Generation - Diffie-Hellman, DSS, and RSA key-pairs.
Registration - Public keys must be registered with X.509 CA.
Certificate Storage - Local (as in browser application) for
different services.
Signed and Enveloped Data - Various orderings for encrypting
and signing.

175

User Agent Role

Example: Verisign (www.verisign.com)
Class-1: Buyers email address confirmed by
emailing vital info.
Class-2: Postal address is confirmed as well,
and data checked against directories.

Class-3: Buyer must appear in person, or send

notarized documents.
176

Recommended Web Sites

PGP home page: www.pgp.com

MIT distribution site for PGP
S/MIME Charter
S/MIME Central: RSA Inc.s Web Site

177

WEB Security

178

Outline
Web Security Considerations
Secure Socket Layer (SSL) and Transport
Layer Security (TLS)
Secure Electronic Transaction (SET)
Recommended Reading and WEB Sites

179

Web Security Considerations

The WEB is very visible.
Complex software hide many security
flaws.
Web servers are easy to configure and
manage.
Users are not aware of the risks.

180

Security facilities in the TCP/IP

protocol stack

181

SSL and TLS

SSL was originated by Netscape
TLS working group was formed within
IETF
First version of TLS can be viewed as an
SSLv3.1

182

SSL Architecture

183

SSL Record Protocol Operation

184

SSL Record Format

185

SSL Record Protocol Payload

186

Handshake Protocol
The most complex part of SSL.
Allows the server and client to authenticate
each other.
Negotiate encryption, MAC algorithm and
cryptographic keys.
Used before any application data are
transmitted.
187

Handshake Protocol Action

188

Transport Layer Security

The same record format as the SSL record format.

Defined in RFC 2246.
Similar to SSLv3.
Differences in the:

version number
message authentication code
pseudorandom function
alert codes
cipher suites
client certificate types
certificate_verify and finished message
cryptographic computations
padding
189

Secure Electronic Transactions

An open encryption and security specification.
Protect credit card transaction on the Internet.
Companies involved:
MasterCard, Visa, IBM, Microsoft, Netscape,
RSA, Terisa and Verisign
Not a payment system.
Set of security protocols and formats.

190

SET Services
Provides a secure communication channel
in a transaction.
Provides tust by the use of X.509v3 digital
certificates.
Ensures privacy.

191

SET Overview
Key Features of SET:

Confidentiality of information
Integrity of data
Cardholder account authentication
Merchant authentication

192

SET Participants

193

Sequence of events for

transactions
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

The customer opens an account.

The customer receives a certificate.
Merchants have their own certificates.
The customer places an order.
The merchant is verified.
The order and payment are sent.
The merchant request payment authorization.
The merchant confirm the order.
The merchant provides the goods or service.
The merchant requests payments.
194

Dual Signature
DS EKRc [ H ( H ( PI ) || H(OI))]

195

Payment processing

Cardholder sends Purchase Request

196

Payment processing

Merchant Verifies Customer Purchase Request

197

Payment processing
Payment Authorization:
Authorization Request
Authorization Response

Payment Capture:
Capture Request
Capture Response

198

Recommended Reading and

WEB sites
Drew, G. Using SET for Secure Electronic
Commerce. Prentice Hall, 1999
Garfinkel, S., and Spafford, G. Web Security &
Commerce. OReilly and Associates, 1997
MasterCard SET site
Visa Electronic Commerce Site
SETCo (documents and glossary of terms)

199