Certificates Network Systems Security

1. Certificates Network Systems Security Mort Anvari

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

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

4. X.509 Authentication Service • Part of CCITT X.500 directory service standards • distributed servers maintaining some info database • Define framework for authentication services • 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

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

6. X.509 Certificates

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

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

9. CA Hierarchy Use

10. Certificate Revocation • certificates have a period of validity • may need to revoke before expiry, eg: • user's private key is compromised • user is no longer certified by this CA • CA's certificate is compromised • CA’s maintain list of revoked certificates • the Certificate Revocation List (CRL) • users should check certs with CA’s CRL

11. Authentication Procedures • X.509 includes three alternative authentication procedures • One-Way Authentication • Two-Way Authentication • Three-Way Authentication • All use public-key signatures

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

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

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

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

16. Certificate Extensions • key and policy information • convey info about subject & issuer keys, plus indicators of certificate policy • certificate subject and issuer attributes • 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

17. 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”

18. Functions of Firewalls • A choke point of control and monitoring • Interconnect networks with differing trust • Impose restrictions on network services • only authorized traffic is allowed • Auditing and controlling access • can implement alarms for abnormal behavior • Immune to penetration • Provide perimeter defence

19. What Firewalls Can Do • Service control • Direction control • User control • Behavior control

20. What Firewalls Cannot Do • Cannot protect from attacks bypassing it • e.g. sneaker net, utility modems, trusted organisations, trusted services (e.g. SSL/SSH) • Cannot protect against internal threats • e.g. disgruntled employee • Cannot protect against transfer of all virus infected programs or files • because of huge range of OS and file types

21. Types of Firewalls • Three common types • Packet-filtering router • Application-level gateway • Circuit-level gateway

22. Packet-filtering Router

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

24. Examples of Rule Sets

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

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

27. Application Level Gateway

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

29. Circuit Level Gateway

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

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

32. Firewall Configurations

33. Firewall Configurations

34. Firewall Configurations

35. Next Class • Presentation of paper “A Framework for Classifying Denial of Service Attack” • Submit your review through dropbox before class