Module4 SIC.pdf

1

Module 4

Network & Application Security

2

Outline• Kerberos

• X.509 Authentication Service

• IP security Architecture

• Secure socket layer

• Electronic mail security

• Pretty Good privacy

• S/MIME

• Secure Electronic Transactions

• Firewalls

3

KERBEROS

In Greek mythology, a many headed dog, the

guardian of the entrance of Hades

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

5

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.

6

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

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 shouldn’t be able to get enough

information to impersonate the user

– reliable- services using Kerberos would be unusable if

Kerberos isn’t available

– transparent-users should be unaware of its presence,

beyond the requirement to enter a password

– scalable- should support large number of users

10

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

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

13

A Simple Authentication Dialogue(1) C AS: IDc || Pc || IDv

(2) AS C: Ticket

(3) C V: 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 workstation.thats why ADc is included

Kerberos Version 4: Dialog 1- Simple

Ticket=Ekv[IDc,ADc,IDv]

kv=Secret Key between AS and V (Server)

Pc=password of client

Kerberos

• A more Secure Authentication Dialogue

– Simple authentication dialogue’s 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 theAS which is saved for later use

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

• Ticket consists of ID and the network address of the userand the ID of TGS

• Each time when user requires access to new service, theclient applies to the TGS using the ticket [Tickettgs ] toauthenticate itself

– 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 containinguser 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

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)– 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

4-TicketV

Once per user

logon session

Once per type of

service

ticketTGS=EKtgs[IDc,ADc,

IDtgs,TS1,LifeTime1 ]

Kerberos Version 4 : Dialog 2

- More Secure

Cont.

5- TicketV+ IDc

Once per service session

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

24

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

Version 4 Authentication Dialogue

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])

• 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

• 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 || Tickettgs

|| aunthenticatorc

(4) TGS C: E(Kc,tgs [Kc,v|| IDv || TS4 || Ticketv])

Ticketv

= E(kv,

[Kc,v

,IDC

,ADC

,IDv,TS

4,L-time

4]

Authenticatorc

= EKc,tgs

[IDC

,ADC

,TS3]

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

• 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

Client/Server Authentication Exhange: To Obtain Service

(5) C V: Ticketv || Aunthenticatorc

(6) V C: E(Kc,v[TS5 +1])

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]

ServerServer

ServerServer

Kerberos

Database

Ticket Granting

Server

Authentication

Server

Workstation

Kerberos Key Distribution Service

Kerberos

• The version4 Authentication Dialogue

1. Client requests ticket-granting ticket

2. AS returns ticket-granting ticket

3. Client requests service-granting ticket

4. TGS returns service-granting ticket

5. Client requests service

6. Optional authentication of server to client

Kerberos: The Version 4

Authentication Dialog

1- IDc + IDtgs +TS1

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

Lifetime2,TicketTGS]

KERBEROSOnce per user logon session

ticketTGS=E(Ktgs, [Kc,tgs,

IDc,ADc,IDtgs,TS2, LifeTime2 ]

Kerberos: The Version 4 Authentication

Dialog Cont.

KERBEROS

3- TicketTGS + AuthenticatorC

+ IDv

4-E(kc,tgs[kc,v,IDv,Ts4,Ticketv])

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[K

c,v,Idc,ADc,IDv, TS4,

LifeTime4 ])

Kerberos: The Version 4

Authentication Dialog Cont.

5- TicketV+ AuthenticatorC

Once per service session

TicketV=E(Kv [Kv,c, IDc, ADc, IDv, TS4, Lifetime4])

AuthenticatorC=Ekc,v [IDc,ADc,TS5]

6- E(kc,v[TS5+1])

35

The version4 Authentication

Dialogue

36

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

37

Authenticators

• Proves the client’s 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

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

40

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

41

Request for Service in Another

Realm

Request for Service in another realm:

5-Request ticket for remote server

6-Ticket for remote server

4-Ticket for remote TGS

7-request for remote service

Kerberos Realms and Multiple

Kerberi

43

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

• 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 ]

51

Kerberos : Strengths

• User's passwords are never sent across the network,encrypted or in plain text

• Secret keys are only passed across the network inencrypted 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 topprogrammers, cryptologists and security experts inthe industry

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

53

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

54

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 CA’s private key.

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

59

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)

Who are the Certificate Authorities?

VeriSign

GTE CyberTrust

Entrust

CertCo

USPS / Cylink

Block Diagrams of

Certification Process

Certificate

Authority

CA

Repository

Dbase

SubscriberReceiving

Party

1 2

3

4

5 6

62

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.

63

X.509 Formats

X.509 Certificate format

Version

Serial number

Algorithm

Parameters

Issuer

Not before

Not after

Subject

Algorithm

Parameter

Key

Signature

Algorithm

identifier

Period of

validity

Subject’s

public key

Notation to define a certificate:

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

where

Y<<X>>= the certificate of user X issued by

certification authority Y

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 CA’s 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 B’s 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>>

72

Forward Certificate: Certificate of X generated by other

CAs

Reverse Certificates: Certificates generated by X for

another CA

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

• CA’s maintain list of revoked certificates

– the Certificate Revocation List (CRL)

• users should check certificates with CA’s 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

76

Authentication Procedures:

• Three alternative authentication procedures:

– One-Way Authentication

– Two-Way Authentication

– Three-Way Authentication

• All use public-key signatures

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

A B

1-A {ta,ra, IDb,sgnData, E[PUb,Kab]}

Ta-timestamp rA=nonce IDb =identity

sgnData=signed with A’s private key

nonce is an abbreviation of number used once

78

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

A B

1-A {ta,ra,B,sgnData,E[PUb,Kab]}

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

79

Three-Way Authentication

• 3 messages (A->B, B->A, A->B) which

enables above authentication without

synchronized clocks

A B

1- A {ta,ra,B,sgnData, E[PUb,Kab]}

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

3- A{rb}

80

Firewalls

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

which interface of the router the packet is destined.

Bastion Host

– A system identified by the firewall administrator as

a critical strong point in the network´s 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 (single-

homed 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

112

IP Security

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

117

IPv4 Header

Internet Header Length-IHL

IPv6 Header

119

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.

121

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

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

124

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

125

IPSec Document Overview

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

128

IPSec Services

• Access Control

• Connectionless integrity

• Data origin authentication

• Rejection of replayed packets

• Confidentiality (encryption)

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

130

Tunnel Mode (AH

Authentication)

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)

135

Transport Mode

SA

Tunnel Mode

SA

AH Authenticates IP payload and

selected portions of IP header

and IPv6 extension headers

Authenticates entire inner

IP packet plus selected

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.

136

Authentication Header

• Provides support for data integrity and authentication of IP

packets.

• Guards against replay attacks.

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

138

Before applying AH

139

Transport Mode (AH

Authentication)

140

Tunnel Mode (AH

Authentication)

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.

143

Encapsulating Security Payload

• ESP provides confidentiality services

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

147

Encryption and Authentication

Algorithms• Encryption:

– Three-key triple DES

– RC5

– IDEA

– Three-key triple IDEA

– Blowfish

• Authentication:

– HMAC-MD5-96

– HMAC-SHA-1-96

148

ESP Encryption and Authentication

• 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 end-to-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

150

ESP Encryption and

Authentication

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.

152

Electronic mail security

153

Outline

• Pretty good privacy

• S/MIME

154

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.

155

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

156

Operational Description

• Consist of five services:

– Authentication

– Confidentiality

– Compression

– E-mail compatibility

– Segmentation

157

158

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

159

E-mail Compatibility

• The scheme used is radix-64 conversion (see

appendix 5B).

• The use of radix-64 expands the message by

33%.

160

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.

161

Sumary of PGP Services

Function Algorithm Used Digital Signature DSS/SHA or

RSA/SHA

Message Encryption

CAST or IDEA or three-key triple DES

with Diffie-Hellman or RSA

Compression ZIP

E-mail Compatibility

Radix-64 conversion

Segmentation -

162

163

Format of PGP Message

164

165

166

167

The Use of Trust

• Key legitimacy field

• Signature trust field

• Owner trust field

See Table 5.2 (W. Stallings)

168

169

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.

170

S/MIME

• Secure/Multipurpose Internet Mail

Extension

• S/MIME will probably emerge as the

industry standard.

• PGP for personal e-mail security

171

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)

172

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)

173

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.

174

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

175

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.

176

User Agent Role

• Example: Verisign (www.verisign.com)

– Class-1: Buyer’s 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.

177

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

178

WEB Security

179

Outline

• Web Security Considerations

• Secure Socket Layer (SSL) and Transport

Layer Security (TLS)

• Secure Electronic Transaction (SET)

• Recommended Reading and WEB Sites

180

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.

181

Security facilities in the TCP/IP

protocol stack

182

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

183

SSL Architecture

184

SSL Record Protocol Operation

185

SSL Record Format

186

SSL Record Protocol Payload

187

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.

188

Handshake Protocol Action

189

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

190

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.

191

SET Services

• Provides a secure communication channel

in a transaction.

• Provides tust by the use of X.509v3 digital

certificates.

• Ensures privacy.

192

SET Overview

• Key Features of SET:

– Confidentiality of information

– Integrity of data

– Cardholder account authentication

– Merchant authentication

193

SET Participants

194

Sequence of events for

transactions1. The customer opens an account.

2. The customer receives a certificate.

3. Merchants have their own certificates.

4. The customer places an order.

5. The merchant is verified.

6. The order and payment are sent.

7. The merchant request payment authorization.

8. The merchant confirm the order.

9. The merchant provides the goods or service.

10. The merchant requests payments.

195

Dual Signature

H(OI))]||)(([ PIHHEDScKR

196

Payment processing

Cardholder sends Purchase Request

197

Payment processing

Merchant Verifies Customer Purchase Request

198

Payment processing

• Payment Authorization:

– Authorization Request

– Authorization Response

• Payment Capture:

– Capture Request

– Capture Response

199

Recommended Reading and

WEB sites

• Drew, G. Using SET for Secure Electronic

Commerce. Prentice Hall, 1999

• Garfinkel, S., and Spafford, G. Web Security &

Commerce. O’Reilly and Associates, 1997

• MasterCard SET site

• Visa Electronic Commerce Site

• SETCo (documents and glossary of terms)