Module4 SIC.pdf
Click here to load reader
Transcript of 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)