Network Security Architectures Part 1 Fundamentals Summer School

Network Security Architectures Part 1 Fundamentals Summer School on Software Security Theory to Practice Carl A. Gunter University of Pennsylvania Summer 2004 CIS 551 Columbia University

Public Key Infrastructure l l Mutual authentication of participants in a transaction requires a system of identities Principals are identified by public keys These keys can be used for authentication, but only if “spoofing” is prevented A Public Key Infrastructure (PKI) provides a basis for establishing trust

PKI Systems l Three Philosophies Ø Hierarchy

X. 509 Certificates X. 509 certificates bind a subject to a public key. This binding is signed by a Certificate Authority (CA). Subject Name Subject Public Key CA Name CA Signature

Chaining Joe Smith Subject Joe’s Key Subject’s Key Philly CA Issuer Philly CA Key Pennsylvania CA Key USA CA

Certificate Management l Distribution: How to find a certificate Ø Ø Certificate accompanying signature or as part of a protocol Directory service l Revocation: Terminate certificates before their expiration time. Ø < DAP < LDAP Ø < DNS Ø Ø Email Cut and paste from web pages Ø How does the relying party know that the certificate has been revoked? Many CRL distribution strategies proposed Mitre report for NIST suggests certificate revocation will be the largest maintenance cost for PKIs

Semantics of CRL’s l Three certificates. Revoke 1. 2. 3. l Q says P is the public key of Alice. R says P is the public key of Alice. Q says R is the public key of Bob. Three kinds of revocation. 1. 2. 3. P is not the public key of Alice. (3 not 2. ) Q no longer vouches for whether P is the public key of Alice. (2 and 3. ) The key of Q has been compromised. (2 not 3. ) 1998 Fox and La. Macchia

Adoption of PKI l Problems Ø Ø Revocation User ability to deal with keys Registration (challenge for all authentication techniques) Weak business model l Areas of Progress Ø Ø Ø SSL Authenticode SSH Smart cards for government employees Web services

Challenges for Network Security l l l Sharing Complexity Scale Unknown perimeter Anonymity Unknown paths

Internet Layers 1. 2. 3. 4. 5. Physical Link Network Transport Application

Security at Layers l Physical doors Ø Spread spectrum Ø Tempest l Ø Locked l Link Ø WEP Ø GSM l Network Ø Firewalls Ø IPSec Transport Ø l SSL and TLS Application Ø Ø Ø S/MIME XMLDSIG and WS security Access control systems for web pages, databases, and file systems

Network Layer Security HTTP FTP TCP IP/IPSec SMTP

Transport Layer Security HTTP FTP SMTP SSL or TLS TCP IP

Application Layer Security PGP S/MIME Kerberos SMTP TCP UDP IP SET HTTP

Division of Labor in the Internet Hosts Routers Networks

TCP/IP Protocol Stack Host Router Host Application Transport Network Link Physical

Communication Processing Flow App 1 App 2 App 1 Transport Network App 2 Transport Network Link Link Physical Phys Physical

Typical Patchwork App 1 App 2 App 1 Transport Network App 2 Transport Network Link Link Physical Phys Physical

Physical Layer Protection Issues l Hide signal Ø Spread l spectrum Emission security Ø Radio emissions (Tempest) Ø Power emissions

Encapsulation Link Layer Frame Link IP Network Layer Header TCP Transport Layer Header Application Link Application Layer Payload

One Hop Link Layer Encryption Host Router Host Application Transport Network Link Network Link

Link Layer Encryption Encrypted Link IP TCP Application Link

End-to-End Network Security Host Router Host Application Transport Network Link

Network Layer Transport Mode Link IP TCP Application Link Encrypted Link IP Hdr TCP Application Tlr Link

VPN Gateway Host Router Host Application Transport Network Link

Network Layer Tunnel Mode Link IP TCP Application Link Encrypted Link New IP Hdr IP TCP Application Tlr Link

Layer 3 Implementation Options l Location Ø Host Ø Network l Style Ø Integrated Ø Modular (for tunnel mode)

Modular Implementation: Bump In The Stack (BITS) App 1 App 2 Transport Network Transport Security Network Net + Sec Network Link

Modular Implementation: Bump In The Wire (BITW) App 1 App 2 Transport Security Transport Network Link

Implementation Options: Integrated on Host App 1 App 2 App 1 Transport App 2 Transport Net + Sec Network Net + Sec Link

Implementation Options: Integrated on Router App 1 App 2 App 1 Transport App 2 Transport Network Net + Sec Network Link

Network Security Location Options Application Transport Network Link End-to-End Transport Link Application Transport Network Link Voluntary Tunnel Link Application Transport Network Link Involuntary Tunnel

Transport Layer Security Host Router Host Application Transport Network Link

Transport Layer Encryption Link IP TCP Application Link Encrypted Link IP Link TCP RH IP TCP Application App Link

Message Processing Sequence App 1 App 2 Sec Transport Network Link

Application Layer Security Link IP TCP Application Link Encrypted Link IP Key ID TCP Application Link

Link Layer Security l Advantages: Ø Transparent to applications Ø Hardware solution possible Ø Can address especially vulnerable links (viz. wireless) l Disadvantages: Ø Hop-by-hop protection causes multiple applications of crypto operations Ø May not provide end to end security

Network Layer Security l Advantages Ø Transparent to applications Ø Amenable to hardware Ø Flexible l Disadvantages Ø Makes routing more complex Ø Flexibility introduces policy management and compatibility challenges

Transport Layer Security l Advantages Ø Transparent to applications and may be packaged with applications Ø Exposing TCP enables compression and Qo. S classification l Disadvantages Ø Probably implemented in software Ø Exposing TCP risks Do. S

Application Layer Security l Advantages Ø Customized to application Ø Requires no special protocol stack (transparent to networking) l Disadvantages: Ø Hard to share between applications (viz. standardization challenge)

Protocols to Software l There are important differences between theoretical descriptions, standards and software Ø Evolution (versions, extensibility) Ø Interoperability (options, negotiation) Ø Error modes l Two brief case studies Ø Transport Layer Security (TLS) Ø Network layer security (Ipsec)

Secure Socket Layer (SSL) l Session protocol with: Ø Ø l l Server authentication Client authentication optional Integrity checksum Confidentiality Possibly the most important security-related ecommerce protocol Session sets up security parameters Many connections possible within a given session Current version TLS 1. 0 http: //www. ietf. org/rfc 2246. txt

X. 509 Key Est. Messages l l l Let DA = EB(k), r. A, LA, A. Let DB = r. B, LB, r. A, A Two messages: 1. A -> B : cert. A, DA, SA(DA) Check that the nonce r. A has not been seen, and is not expired according to LA. Remember it for its lifetime LA. 2. B -> A : cert. B, DB, SB(DB) Check the r. A and A. Check that r. B has not been seen and is not expired according to LB.

Establish Security Capabilities Client Server Clie Time nt H r rve Se ello H

Server Auth & Key Exchange Client Server e cat ifi ert C Time r rve Se a ific ert E est qu Re te C S y Ke ver er nge cha x ello H one D Optional

Client Auth & Key Exchange Client Server Ce rti Time fica te Cli ent Ce rti Ke fica y. E te V xch erif ang ica e Optional tion Optional

Client Auth & Key Exchange Client Ch ang Time e. C Server iph Fin ish Ch nge a er S her ip C h inis F pec S

IPsec l Modes Ø Ø l l Tunnel Transport Ø Ø Protocols Ø Ø Authenticated Header (AH) Encapsulated Security Payload (ESP) Configurations Ø l End-to-end Concatenated Nested Principal elements Ø Ø Ø Security Associations (SAD) Internet Key Exchange (IKE) Policy (SPD)

Typical Case S Client Internet G ESP S ESP Gateway Corporate Network S Server

Encapsulated Security Header and Trailer 0 -7 8 -15 16 -23 23 -31 Security Parameter Index (SPI) Sequence Number Initialization Vector Protected Data Pad Length Authentication Data Next Header

Security Association An SA describes the parameters for processing a secured packet from one node to another l SAs are simplex: use one for each direction l If more than one SA is used for a packet the applicable SAs are called an “SA bundle” l

SA Parameters (ESP Only) Sequence number, Sequence number overflow, Anti-replay window l Lifetime l Mode l Tunnel destination l PMTU l Encryption algorithm (IV, etc. ) l Authentication algorithm l

Policy is not standardized in IPSec but certain basic functionality is expected l A Security Policy Database (SPD) is consulted to determine what kind of security to apply to each packet l The SPD is consulted during the processing of all traffic: l Ø Inbound and outbound Ø IPSec and non-IPSec

SPD Actions Discard l Bypass IPsec l Apply IPsec: SPD must specify the security services to be provided. l Ø For inbound traffic it is inferred from: destination address, protocol, SPI. Ø For outbound traffic this is done with a selector.

Selectors are predicates on packets that are used to map groups of packets to SAs or impose policy l They are similar to firewall filters l Selector support l Ø Destination and source IP addresses Ø Name (DNS, X. 509) Ø Source and destination ports (may not be available on inbound ESP packets; use inner header for inbound tunnel mode)

IPsec Processing: Outbound l l Use selectors in SPD to determine drop, bypass, or apply If apply, determine whether an SA or SA bundle for the packet exists Ø Ø If yes, then apply all appropriate SAs before dispatching If no, then create all necessary SAs. Apply these when done before dispatching

IPsec Processing: Inbound If there are no IPsec headers check SPD selectors to determine processing discard, bypass, or apply l If apply, then drop l If there are IPsec headers, apply SA determined by SPI, destination, protocol l Use selectors on result to retrieve policy and confirm correct application l

Internet Key Exchange (IKE) l l Motivating problem: Security settings (SAs) must be highly configurable Solutions: Ø Ø l l Let network administrator manually configure SA (most common) Provide mechanism to allow automatic negotiation and configuration Can be found at: http: //ietf. org/internet-drafts/draftietf-ipsec-ikev 2 -13. txt IKEv 2 Current as of March 22, 2004

Station to Station Protocol 1. A -> B : YA (Diffie-Hellman public key) Calculate k. 2. B –> A : YB, E(k, SB(YB, YA)) Calculate k, use it to decrypt the signature, check the signature using the verification function of B and known values YB, YA. 3. A -> B : E(k, SA(YA, YB)) Decrypt the signature and check it using the verification function of A.

High-level view l Requester: Responder: l IKE_SA_INIT --> <-- IKE_SA_INIT l l IKE_AUTH --> <-- IKE_AUTH l Ø These are mandatory message exchange pairs, and must be executed in this order.

High-level view l Initiator: Responder: CREATE_CHILD_SA --> l <-CREATE_CHILD_SA l INFORMATIONAL --> l <-INFORMATIONAL l Ø These messages are optional and can be sent by either party at any time.

Changes from IKEv 1 l l 4 initialization messages instead of 8 Decrease latency in common case of 1 CHILD_SA by piggybacking this onto initial message exchanges Protocol is reliable (all messages are acknowledged and sequenced) Cookie exchange option ensures that the responder does not have to commit state until initiator proves it can accept messages

Summary PKI provides potential scalable identities for the Internet but adoption has been difficult l Network protocols are designed in layers; security can be provided at multiple layers with various tradeoffs l Theoretical protocols differ in significant ways from Internet standards and software l