Transcript CSCE 790: Computer Network Security

CSCE 715:
Network Systems Security
Chin-Tser Huang
[email protected]
University of South Carolina
Certificates



An instrument signed by an authority to
certify something about a subject
Original function is to bind names to
keys or keys to names
Now it can contain authorization,
delegation, and validity conditions
10/26/2004
2
Types of Certificates

ID certificates
name  key

Attribute certificates
authorization  name

Authorization certificates
authorization  key

An attribute certificate needs to combine with
an ID certificate to be used for authorization
10/26/2004
3
X.509 Authentication Service

Part of CCITT X.500 directory service standards


Define framework for authentication services





distributed servers maintaining some info database
directory may store public-key certificates
with public key of user
signed by certification authority
Also define authentication protocols
Use public-key cryptography and digital signatures

algorithms not standardised, but RSA recommended
10/26/2004
4
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
issuer X.500 name (CA)
period of validity (from - to dates)
subject X.500 name (name of owner)
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)
Notation CA<<A>> denotes certificate for A signed by CA
10/26/2004
5
X.509 Certificates
10/26/2004
6
Obtaining a Certificate



Any user with access to CA can get any
certificate from it
Only the CA can modify a certificate
Certificates can be placed in a public
directory since they cannot be forged
10/26/2004
7
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
10/26/2004
8
CA Hierarchy Use
10/26/2004
9
Certificate Revocation


certificates have a period of validity
may need to revoke before expiry, eg:
1.
2.
3.

CA’s maintain list of revoked certificates


user's private key is compromised
user is no longer certified by this CA
CA's certificate is compromised
the Certificate Revocation List (CRL)
users should check certs with CA’s CRL
10/26/2004
10
Authentication Procedures

X.509 includes three alternative
authentication procedures




One-Way Authentication
Two-Way Authentication
Three-Way Authentication
All use public-key signatures
10/26/2004
11
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
integrity & originality of message
message must include timestamp,
nonce, B's identity and is signed by A
10/26/2004
12
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
reply includes original nonce from A,
also timestamp and nonce from B
10/26/2004
13
Three-Way Authentication



3 messages (A->B, B->A, A->B) which
enables above authentication without
synchronized clocks
has reply from A back to B containing
signed copy of nonce from B
means that timestamps need not be
checked or relied upon
10/26/2004
14
X.509 Version 3

It has been recognized that additional
information is needed in a certificate



email/URL, policy details, usage constraints
Define a general extension method rather
than naming new fields
Components of extensions



extension identifier
criticality indicator
extension value
10/26/2004
15
Certificate Extensions

key and policy information


certificate subject and issuer attributes


convey info about subject & issuer keys, plus
indicators of certificate policy
support alternative names, in alternative formats
for certificate subject and/or issuer
certificate path constraints

allow constraints on use of certificates by other
CA’s
10/26/2004
16
Need of Firewalls


Everyone want to be on the Internet
and to interconnect networks
Persistent security concerns


cannot easily secure every system in
organization
Use firewall to provide “harm
minimization”
10/26/2004
17
Functions of Firewalls



A choke point of control and monitoring
Interconnect networks with differing trust
Impose restrictions on network services


Auditing and controlling access



only authorized traffic is allowed
can implement alarms for abnormal behavior
Immune to penetration
Provide perimeter defence
10/26/2004
18
What Firewalls Can Do




Service control
Direction control
User control
Behavior control
10/26/2004
19
What Firewalls Cannot Do

Cannot protect from attacks bypassing it


Cannot protect against internal threats


e.g. sneaker net, utility modems, trusted
organisations, trusted services (e.g. SSL/SSH)
e.g. disgruntled employee
Cannot protect against transfer of all virus
infected programs or files

because of huge range of OS and file types
10/26/2004
20
Types of Firewalls

Three common types



Packet-filtering router
Application-level gateway
Circuit-level gateway
10/26/2004
21
Packet-filtering Router
10/26/2004
22
Packet-filtering Router




Foundation of any firewall system
Examine each IP packet (no context)
and permit or deny according to rules
Restrict access to services (ports)
Possible default policies


prohibited if not expressly permitted
permitted if not expressly prohibited
10/26/2004
23
Examples of Rule Sets
10/26/2004
24
Attacks on Packet Filters

IP address spoofing



Source routing attacks



fake source address to be trusted
add filters on router to block
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
10/26/2004
25
Stateful Packet Filters

Examine each IP packet in context



keep tracks of client-server sessions
check each packet validly belongs to one
Better able to detect bogus packets out
of context
10/26/2004
26
Application Level Gateway
10/26/2004
27
Application Level Gateway


Use an 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
Need separate proxies for each service



some services naturally support proxying
others are more problematic
custom services generally not supported
10/26/2004
28
Circuit Level Gateway
10/26/2004
29
Circuit Level Gateway





Relay two TCP connections
Impose 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 commonly used for this
10/26/2004
30
Bastion Host





Highly secure host system
Potentially exposed to "hostile" elements, so
need to be secured to withstand this
May support 2 or more net connections
May be trusted to enforce trusted separation
between network connections
Run circuit / application level gateways or
provide externally accessible services
10/26/2004
31
Firewall Configurations
10/26/2004
32
Firewall Configurations
10/26/2004
33
Firewall Configurations
10/26/2004
34
Next Class


Presentation of paper “A Framework for
Classifying Denial of Service Attack”
Submit your review through dropbox
before class
10/26/2004
35