Unit IV

Authentication applications
Kerberos & X.509 Authentication services
Internet Firewalls for Trusted System:
Roles of Firewalls
Firewall related terminology
Types of Firewalls
Firewall designs
SET for E-Commerce Transactions.
Intruder
Intrusion detection system
Virus and related threats
Countermeasures
Firewalls design principles
Trusted systems
Practical implementation of cryptography and security.
 User Authentication
 Authentication Application
 Kerberos
Remote User-Authentication Principles

• The process of verifying an identity claimed

by or for a system entity
• An authentication process consists of two
steps:

Verification
• Presenting an step
identifier to the • Presenting or generating
security system authentication information
that corroborates the binding
between the entity and the
Identification identifier
step
 Means of User Authentication

Something the individual knows Something the individual possesses

• Examples include a password, a • Examples include cryptographic keys,
personal identification number (PIN), electronic keycards, smart cards, and
or answers to a prearranged set of physical keys
questions • This is referred to as a token
There are four general
means of authenticating a
user’s identity, which can
be used alone or in
combination
Something the individual is (static Something the individual does
biometrics) (dynamic biometrics)
• Examples include recognition by • Examples include recognition by
fingerprint, retina, and face voice pattern, handwriting
characteristics, and typing rhythm

• For network-based user authentication, the most important

methods involve cryptographic keys and something the
individual knows, such as a password
 Mutual Authentication
• Protocols which enable communicating parties to satisfy
themselves mutually about each other’s identity and to
exchange session keys
Central to the
problem of
authenticated
key exchange are
two issues:
Timeliness
• Important because of the threat
of message replays Confidentiality
• Such replays could allow an • Essential identification and
opponent to: session-key information
• compromise a session key must be communicated in
• successfully impersonate encrypted form
another party • This requires the prior
• disrupt operations by presenting existence of secret or public
parties with messages that keys that can be used for
appear genuine but are not this purpose
 Replay Attacks
1. The simplest replay attack is one in which the
opponent simply copies a message and replays it later
2. An opponent can replay a timestamped message within
the valid time window
3. An opponent can replay a timestamped message within
the valid time window, but in addition, the opponent
suppresses the original message; thus, the repetition
cannot be detected
4. Another attack involves a backward replay without
modification and is possible if symmetric encryption is
used and the sender cannot easily recognize the
difference between messages sent and messages
received on the basis of content
Approaches to Coping(Manage) With
Replay Attacks
• Attach a sequence number to each message used in an authentication
exchange
– A new message is accepted only if its sequence number is in the proper
order
– Difficulty with this approach is that it requires each party to keep track of
the last sequence number for each claimant it has dealt with
– Generally not used for authentication and key exchange because of
overhead

– Timestamps
– Requires that clocks among the various participants be synchronized
– Party A accepts a message as fresh only if the message contains a timestamp that,
in A’s judgment, is close enough to A’s knowledge of current time

– Challenge/response
– Party A, expecting a fresh message from B, first sends B a nonce (challenge) and
requires that the subsequent message (response) received from B contain the
correct nonce value
Remote User-Authentication Using
Symmetric Encryption
A two-level hierarchy of symmetric keys can be used
to provide confidentiality for communication in a
distributed environment
• Strategy involves the use of a trusted key distribution
center (KDC)
• Each party shares a secret key, known as a master key,
with the KDC
• KDC is responsible for generating keys to be used for a
short time over a connection between two parties and
for distributing those keys using the master keys to
protect the distribution
 Kerberos
• Authentication service developed as part of Project
Athena at MIT
• A workstation cannot be trusted to identify its users
correctly to network services
– A user may gain access to a particular workstation and pretend
to be another user operating from that workstation
– A user may alter the network address of a workstation so that
the requests sent from the altered workstation appear to come
from the impersonated workstation
– A user may eavesdrop on exchanges and use a replay attack to
gain entrance to a server or to disrupt operations

– Kerberos provides a centralized authentication server whose

function is to authenticate users to servers and servers to users
– Relies exclusively on symmetric encryption, making no use of
public-key encryption
 Kerberos Requirements
• The first published report on Kerberos listed
the following requirements:
• A network eavesdropper • Should be highly
should not be able to reliable and should
obtain the necessary employ a distributed
information to server architecture
impersonate a user with one system able
to back up another
Secure Reliable

Scalable Transparent

• The system should be • Ideally, the user should not be

capable of supporting aware that authentication is taking
large numbers of clients place beyond the requirement to
and servers enter a password
 Kerberos Version 4
• Makes use of DES to provide the authentication service
• Authentication server (AS)
– Knows the passwords of all users and stores these in a
centralized database
– Shares a unique secret key with each server
• Ticket
– Created once the AS accepts the user as authentic; contains the
user’s ID and network address and the server’s ID
– Encrypted using the secret key shared by the AS and the server

– Ticket-granting server (TGS)

– Issues tickets to users who have been authenticated to AS
– Each time the user requires access to a new service the client applies to
the TGS using the ticket to authenticate itself
– The TGS then grants a ticket for the particular service
– The client saves each service-granting ticket and uses it to authenticate
its user to a server each time a particular service is requested
The Version 4 Authentication Dialogue

The lifetime associated with the

ticket-granting ticket creates a
problem:
• If the lifetime is very short (e.g., minutes), the
user will be repeatedly asked for a password
• If the lifetime is long (e.g., hours), then an
opponent has a greater opportunity for replay
A network service (the 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

Servers need to authenticate

themselves to users
 Table 15.1 (page 464 in textbook)
Summary of Kerberos Version 4 Message Exchanges
(This table can be found on pages 467 – 468 in the textbook)
(page 3 of 3)
 Kerberos Realms
and Multiple Kerberi
• A full-service Kerberos environment consisting of
a Kerberos server, a number of clients, and a
number of application servers requires that:
– The Kerberos server must have the user ID and
hashed passwords of all participating users in its
database; all users are registered with the Kerberos
server
– The Kerberos server must share a secret key with
each server; all servers are registered with the
Kerberos server
– The Kerberos server in each interoperating realm
shares a secret key with the server in the other realm;
the two Kerberos servers are registered with each
other
 Kerberos Realm
• A set of managed nodes that share the same
Kerberos database
• The database resides on the Kerberos master
computer system, which should be kept in a
physically secure room
• A read-only copy of the Kerberos database might
also reside on other Kerberos computer systems
• All changes to the database must be made on the
master computer system
• Changing or accessing the contents of a Kerberos
database requires the Kerberos master password
 Kerberos Principal

• A service or user that A service

or user
is known to the An
name
instance
Kerberos system name

• Identified by its A realm

name
principal name

Three parts of a principal

name
Differences Between Versions 4 and 5

Version 5 is intended to
address the limitations of
version 4 in two areas:
Environmental shortcomings Technical deficiencies
• Encryption system dependence • Double encryption
• Internet protocol dependence • PCBC encryption
• Message byte ordering • Session keys
• Ticket lifetime • Password attacks
• Authentication forwarding
• Interrealm authentication
 Table 15.3
Summary of Kerberos Version 5 Message Exchanges
 Table 15.4

Kerberos
Version 5
Flags

(Table can be found on

page 474 in textbook)
 Mutual Authentication
• Public-key encryption for session key
distribution
– Assumes each of the two parties is in possession of
the current public key of the other
– May not be practical to require this assumption
• Denning protocol using timestamps
– Uses an authentication server (AS) to provide public-
key certificates
– Requires the synchronization of clocks
• Woo and Lam makes use of nonces
– Care needed to ensure no protocol flaws
 One-Way Authentication

• Have public-key approaches for e-mail

– Encryption of message for confidentiality,
authentication, or both
– The public-key algorithm must be applied
once or twice to what may be a long message
• For confidentiality encrypt message with
one-time secret key, public-key encrypted
• If authentication is the primary concern, a
digital signature may suffice
 X.509 Authentication service
(X.509 is a Public Key Certificate)
- Use of public key certificate
- X.509 Certificate Format
- X.509 Hierarchy
-
 X.509 Certificates
• Part of the X.500 series of recommendations that define a
directory service
– The directory is, in effect, a server or distributed set of servers that
maintains a database of information about users
• X.509 defines a framework for the provision of authentication
services by the X.500 directory to its users
– Was initially issued in 1988 with the latest revision in 2000
– Based on the use of public-key cryptography and digital signatures
– Does not dictate the use of a specific algorithm but recommends
RSA
– Does not dictate a specific hash algorithm
• Each certificate contains the public key of a user and is signed
with the private key of a trusted certification authority
• X.509 defines alternative authentication protocols based on
the use of public-key certificates
 – Version
– Serial number
Certificates – Signature algorithm
identifier
– Issuer name
Created by a – Period of validity
trusted – Subject name
Certification – Subject’s public-key
Authority (CA) information
and have the – Issuer unique identifier
following – Subject unique
elements: identifier
– Extensions
– Signature
• Version: Differentiates among successive versions of the certificate format;
the default is version 1.
• Serial number: An integer value unique within the issuing CA that is
unambiguously associated with this certificate.
• Signature algorithm identifier: The algorithm used to sign the certificate
Together with any associated parameters.
• Issuer name: X.500 name of the CA that created and signed this certificate.
• Period of validity: Consists of two dates: the first and last on which the
certificate is valid.
• Subject name: The name of the user to whom this certificate refers. That is,
this certificate certifies the public key of the subject who holds the
corresponding private key.
• Subject’s public-key information: The public key of the subject, plus an
identifier of the algorithm for which this key is to be used,
• Issuer unique identifier: An optional-bit string field used to identify
uniquely the issuing CA in the event the X.500 name has been reused for
different entities.
• Subject unique identifier: An optional-bit string
field used to identify uniquely the subject in the
event the X.500 name has been reused for
different entities.
• Extensions: A set of one or more extension
fields.
• Signature: Covers all of the other fields of the
certificate; it contains the hash code of the
other fields encrypted with the CA’s private key.
Example for Certificate for User A
 Obtaining a Certificate

User certificates • Any user with access to the public key of

generated by a the CA can verify the user public key that
was certified
CA have the • No party other than the certification
following authority can modify the certificate
characteristics: without this being detected

– Because certificates are unforgeable, they can be placed in a directory

without the need for the directory to make special efforts to protect
them
– In addition, a user can transmit his or her certificate directly to other
users

– Once B is in possession of A’s certificate, B has confidence that

messages it encrypts with A’s public key will be secure from
eavesdropping and that messages signed with A’s private key are
unforgeable
• In this example, user A can acquire the following
certificates from the directory to establish a
certification path to B:
 Certificate Revocation
• Each certificate includes a period of validity
– Typically a new certificate is issued just before the expiration
of the old one
• It may be desirable on occasion to revoke a certificate
before it expires, for one of the following reasons:
– The user’s private key is assumed to be compromised
– The user is no longer certified by this CA
– The CA’s certificate is assumed to be compromised

– Each CA must maintain a list consisting of all revoked but not

expired certificates issued by that CA
– These lists should be posted on the directory
 Key and Policy Information
• These extensions convey additional information about
the subject and issuer keys plus indicators of certificate
policy
• A certificate policy is a named set of rules that indicates
the applicability of a certificate to a particular
community and/or class of application with common
security requirements
Included are:
• Authority key identifier
• Subject key identifier
• Key usage
• Private-key usage period
• Certificate policies
• Policy mappings
Firewalls
 What is a Firewall?
• a choke point of control and monitoring
• interconnects networks with differing trust
• imposes restrictions on network services
– only authorized traffic is allowed
• auditing and controlling access
– can implement alarms for abnormal behavior
• provide NAT & usage monitoring
• implement VPNs using IPSec
• must be immune to penetration
What is a Firewall?
 Firewall Limitations
• cannot protect from attacks bypassing it
– eg sneaker net, utility modems, trusted
organisations, trusted services (eg SSL/SSH)
• cannot protect against internal threats
– eg disgruntled or colluding employees
• cannot protect against access via WLAN
– if improperly secured against external use
• cannot protect against malware imported via
laptop, PDA, storage infected outside
 Firewalls – Packet Filters
• simplest, fastest firewall component
• foundation of any firewall system
• examine each IP packet (no context) and
permit or deny according to rules
• hence restrict access to services (ports)
• possible default policies
– that not expressly permitted is prohibited
– that not expressly prohibited is permitted
Firewalls – Packet Filters
Firewalls – Packet Filters
 Attacks on Packet Filters
• IP address spoofing
– fake source address to be trusted
– add filters on router to block
• source routing attacks
– attacker sets a route other than default
– block source routed packets
• tiny fragment attacks
– split header info over several tiny packets
– either discard or reassemble before check
 Firewalls – Stateful Packet Filters
• traditional packet filters do not examine
higher layer context
– ie matching return packets with outgoing flow
• stateful packet filters address this need
• they examine each IP packet in context
– keep track of client-server sessions
– check each packet validly belongs to one
• hence are better able to detect bogus packets
out of context
• may even inspect limited application data
 Firewalls - Application Level Gateway (or
Proxy)
• have application specific gateway / proxy
• has full access to protocol
– user requests service from proxy
– proxy validates request as legal
– then actions request and returns result to user
– can log / audit traffic at application level
• need separate proxies for each service
– some services naturally support proxying
– others are more problematic
Firewalls - Application Level Gateway (or
Proxy)
 Firewalls - Circuit Level Gateway
• relays two TCP connections
• imposes security by limiting which such
connections are allowed
• once created usually relays traffic without
examining contents
• typically used when trust internal users by
allowing general outbound connections
• SOCKS is commonly used
Firewalls - Circuit Level Gateway
 Bastion Host
• highly secure host system
• runs circuit / application level gateways
• or provides externally accessible services
• potentially exposed to "hostile" elements
• hence is secured to withstand this
– hardened O/S, essential services, extra auth
– proxies small, secure, independent, non-privileged
• may support 2 or more net connections
• may be trusted to enforce policy of trusted
separation between these net connections
 Host-Based Firewalls
• s/w module used to secure individual host
– available in many operating systems
– or can be provided as an add-on package
• often used on servers
• advantages:
– can tailor filtering rules to host environment
– protection is provided independent of topology
– provides an additional layer of protection
 Personal Firewalls
• controls traffic between PC/workstation and
Internet or enterprise network
• a software module on personal computer
• or in home/office DSL/cable/ISP router
• typically much less complex than other
firewall types
• primary role to deny unauthorized remote
access to the computer
• and monitor outgoing activity for malware
Personal Firewalls
Firewall Configurations
Firewall Configurations
Firewall Configurations
 DMZ
Networks
Virtual Private Networks
Distributed
Firewalls
 Summary of Firewall Locations and
Topologies
• host-resident firewall
• screening router
• single bastion inline
• single bastion T
• double bastion inline
• double bastion T
• distributed firewall configuration
INTRUSION DETECTION SYSTEMS (IDS)
 Introduction to IDS
• Why we need IDS?
– Fire Walls and IDS.
– Analogy Based Example
• Classification of IDSs
• Models of IDS
– Anomaly based model
– Signature based model.
A Typical Fire Wall Deployment
 Anomaly Based IDS

• General Functional Mechanism

• Behavioral Anomaly
– Statistical Approach
• Example: Traffic analysis
• Protocol Anomaly
– Based on Protocols and communication Structure
• Example : Insecure Protocols
• Pros
– Captures all the headers of IP
– Filters out respective (Mail, Web, DNS,. etc) legal traffic
– More Pro- active.
– Quickly Identifies Probes and Scans towards Network Hardware
– Best Suited for Larger networks and Networks vulnerable to frequent
hacking.
 Anomaly Based IDS
• Cons
– Often makes False Alarms (False Positives)
– Need skilled personnel to analyze the possible
intrusions.
– Need Sophisticated Hardware and Software
– Creates large amount of Log data
– Increase network traffic (some)
 Signature Based IDS
• Based on known Attack patterns
• There are two (Basic) kinds of Signature
Based IDSs:
1. NIDS (Network Intrusion Detection System)
2. HIDS (Host Intrusion Detection System)
 What is an attack Signature?
• Sequence of Events
A->B->C, D->E
• Examples of Signature (Unix Systems)
– Gaining root privileges
– Suspected repetitive actions
» Using the command “sudo –s” or “su – root”
– Using Cgi scripts to access the file by fetching arguments.
http://www.host.com/~xxxx or
http://www.host.com/../../etc/passwd
 Signature Based IDS
• General Functional Mechanism
• Pros:
– Ease of Use
– Looks for O/S level changes (Biggest Advantage)
– No need for skilled personal
– Commercial and Open Source
– Regular updates of new signatures to the signature database
 Signature Based IDS
• Cons:
– More Re-active
– More reliable updates only for Commercial versions
– More suited for Hosts than Networks
• Why?
– Depends on Network Traffic
– Consumes CPU time
– Can be hacked easily.
 Network Intrusion Detection Systems
(NIDS).
• Functional Mechanism
– Uses huge standby databases with
signatures
• Components of NIDS
– Sensors and Consoles
NIDS....
A typical Deployment
 NIDS ……
• Selection Criteria
– Deployment of NIDS
• Interference with Net work Traffic
• Commercial NIDS
– Example : Snort
• Open Source NIDS
– Example : Bro
» Monitors network in Passive mode
» No Direct Interference with the Network.
 HIDS
• Functional Mechanism
– Analogy example…
– O/S level Changes
– Sensors and Killing the session
• Most efficient Among all IDSs
– Strips down all the packets including encrypted ones.
• Commercial Vs Open Source
– Example Tripwire
HIDS..
A typical Deployment
 Advancements in IDS
• Hybrid IDS
– Combination of NIDS functionality and HIDS.
• Decoy Based IDS
– Example: Our Honey Pot machine
– *No problem with False Positive
– Captures only unauthorized activities
– All traffic are considered to be suspected ones
Comparing various IDS characteristic features