CS 155 May 26, 2005 Topics

‹ Application layer protocols (review) Security Protocols • Kerberos, SSL/TLS ‹ Network layer security • IPsec Some details: key management techniques John Mitchell • 802.11 • Mobility ‹ Secure network infrastructure • DNSsec • Sender authentication for spam prevention – Sender Policy Framework (SPF) – Domain Keys – Secure ID – S/MIME

Kerberos Protocol TLS protocol layer over TCP/IP

S Kc C TG KDC http ftp ket 1 {CT, icKt}Ktgs {Kt}Kc Ktgs telnet Application nntp

{C} S {C,Ticket Kt} 1 Kt Ktgs SSL/TLS TGS Client Ticket 2 {Ks}Kt {C, Ks}Kv Transport (TCP)

Internet (IP) {C} T Ks {Ci,c kKest} 2 Kv Kv Network interface Service Physical layer

SSL/TLS Two useful ideas

‹ Authentication using certificate authority (CA) ClientHello • CA has “widely known” verification key ServerHello, – Examples: Verisign, AT&T, MCI, Keywitness Corp Canada [Certificate], • CA supplies signed certificate with site’s public key [ServerKeyExchange], ‹ Integrity based on hashing [CertificateRequest], • Client, server communicate ServerHelloDone Hi [Certificate], Client Hello Server C ClientKeyExchange, S How are you? [CertificateVerify] • Compare hash of all messages switch to negotiated cipher – Compute hash(hi,hello,howareyou?) locally Finished – Exchange hash values under encryption switch to negotiated cipher • Abort if intervention detected Finished

1 Handshake Protocol Topics

‹ Application layer protocols (review) ClientHello C → S C, Ver , Suite , N C C C • Kerberos, SSL/TLS

ServerHello S → C VerS, SuiteS, NS, signCA{ S, KS } ‹ Network layer security • IPsec ClientVerify C → S signCA{ C, VC } { Ver , Secret } Some details: key management techniques C C KS signC { Hash( Master(NC, NS, SecretC) + Pad2 + • 802.11 Hash(Msgs + C + Master(NC, NS, SecretC) + Pad1)) } • Mobility (Change to negotiated cipher) ‹ Secure network infrastructure ServerFinished S → C { Hash( Master(N , N , Secret ) + Pad + C S C 2 • DNSsec Hash( Msgs + S + Master(N , N , Secret ) + Pad )) C S C 1 • Sender authentication for spam prevention } Master(N , N , Secret ) C S C – Sender Policy Framework (SPF) – Domain Keys ClientFinished C → S { Hash( Master(NC, NS, SecretC) + Pad2 + Hash( Msgs + C + Master(NC, NS, SecretC) + Pad1)) – Secure ID } Master(NC, NS, SecretC) – S/MIME

IP-level security (IPSec) Network level protocol

‹Encrypt and authenticate traffic at the IP level Application data abcdefghi ‹Three security functions • Authentication abc def ghi • Confidentiality TCP • Key management TCP abc TCP def TCP ghi ‹Advantages over application layer (TLS) IP

• Implemented at gateway, not desktop IP TCP abc IP TCP def IP TCP ghi • Transparent to application programs and users IPSec

• Data can be sent unencrypted in LAN to avoid IP IPSec TCP uvw IP IPSec TCP xyz IP IPSec TCP lmn encryption overhead

IP Security usage scenarios IPSec overview

‹Security Association (SA) specifies parameters from the sender to the receiver • SPI: Security parameters index • IP: the receiver’s IP address, which is the address of a user/firewall/router/gateway • Security protocol identifier – AH: authentication header for authentication service only – ESP: encapsulated security payload using encryption – ESP with authentication: as ESP, with authentication

2 Transport and tunnel modes IKE: Many modes

‹Transport mode ‹Main mode • Protect only the data payload of an IP packet • Authentication by pre-shared keys • Used for end-to-end encryption between two hosts • Auth with digital signatures (client/server) • Auth with public-key encryption ‹Tunnel mode • Auth with revised public-key encryption • Protection for the entire IP packet (incl IP address) ‹Quick mode • Used for firewall/secure router ⇔ firewall/secure • Compress number of messages router • Also four authentication options

Aug 2001 Position Statement Topics

‹ In the several years since the standardization of the IPSEC ‹ Application layer protocols (review) protocols (ESP, AH, and ISAKMP/IKE), … several security • Kerberos, SSL/TLS problems…, most notably IKE. ‹ Network layer security ‹ Formal and semi-formal analyses by Meadows, Schneier et al, and Simpson, have shown … security problems in IKE stem • IPsec directly from its complexity. Some details: key management techniques ‹ It seems … only a matter of time before serious • 802.11 *implementation* problems become apparent, again due to the • Mobility complex nature of the protocol, and the complex implementation that must surely follow. ‹ Secure network infrastructure ‹ The Security Area Directors have asked the IPSEC working group • DNSsec to come up with a replacement for IKE. • Sender authentication for spam prevention – Sender Policy Framework (SPF) – Domain Keys – Secure ID – S/MIME

Some protocol details, for fun Needham-Schroeder Protocol

‹Protocols that produce shared keys are • Short, typically a few simple messages { A, NonceA } • Rely on cryptographic primitives for authentication Kb and secrecy { NonceA, NonceB } • Subtle and prone to error ABKa ‹Next few slides { NonceB} Kb • We’ll look at some example issues in design of key management protocols, including use of crypto • This is tricky, but can be lots of fun Result: A and B share two private numbers not known to any observer without Ka-1, Kb-1

3 Anomaly in Needham-Schroeder Needham-Schroeder Lowe

[Lowe] { A, NonceA } Kb

{ A, Na } Ke { NonceA, B, NonceB } Ka AE{ Na, Nb } Ka AB { NonceB} Kb { Nb } Ke

Authentication? Secrecy? { Na, Nb } { A, Na } Evil agent E tricks Ka Kb Replay attack honest A into revealing Forward secrecy? private key Nb from B. B Denial of service? Evil E can then fool B. Identity protection?

STS Family Example

‹Construct protocol with properties: cookie STS0 STS0H • Shared secret distribute • Authenticated certificates Properties: open responder • Identity Protection STS STS JFK „ Certificates from CA a aH 0 ab „ Shared secret: g • DoS Protection m=gx, n=gy k=gxy „ Identity protection ‹Design requirements for IKE, JFK, IKEv2 STS STSH JFK1 „ DoS protection (IPSec key exchange protocol) protect „ Reverse ID protection identities

STSP STSPH JFKi

symmetric hash JFKr

Component 1 Component 2

‹Diffie-Hellman ‹Challenge Response: A → B: ga A → B: m, A b B → A: g B → A: n, sigB {m, n, A} A → B: sigA {m, n, B} • Shared secret (with someone) – A deduces: • Shared secret (with someone) (Knows(Y,b ٧ (Knows(Y, gab) ⊃ (Y = A • Authenticated • Authenticated – A deduces: Received (B, msg1) Λ Sent (B, msg2) • Identity Protection • Identity Protection • DoS Protection • DoS Protection

4 m := ga Composition n := gb Refinement

‹ISO 9798-3 protocol: ‹Encrypt signatures: A → B: ga, A A → B: ga, A b a b b a b B → A: g , sigB {g , g , A} B → A: g , EK {sigB {g , g , A}} a b a b A → B: sigA {g , g , B} A → B: EK {sigA {g , g , B}}

• Shared secret: gab • Shared secret: gab • Authenticated • Authenticated • Identity Protection • Identity Protection • DoS Protection • DoS Protection

Transformation Cookie transformation

‹Use cookie: JFK core protocol ‹Typical protocol A → B: ga, A • Client sends request to server B → A: gb, hash {gb, ga} • Server sets up connection, responds KB • Client may complete session or not (DOS) A → B: ga, gb, hash {gb, ga} KB ‹Cookie version a b EK {sigA {g , g , B}} • Client sends request to server b a b B → A: g , EK {sigB {g , g , A}} • Server sends hashed data back • Shared secret: gab – Send message #2 later after client confirms • Authenticated • Client confirms by returning hashed data • Identity Protection • Need extra step to send postponed message • DoS Protection

(Here B must store b in step 2, but can fix this later…)

Cookie in JFK Efficiency: Reuse D-H key

‹Protocol susceptible to DoS ‹Costly to compute ga, gb, gab A → B: ga, A eh1 ‹Solution b a b a b B → A: g , EK {sigB {g , g , A}} • Keep medium-term g , g (change ~10 min) a b a a A → B: EK {sigA {g , g , B}} • Replace g by pair g , nonce eh2 ‹JFKi, JFKr protocols (except cert or grpinfo, …) ‹Use cookie: JFK core protocol A → B: Na, ga, A A → B: ga, A b b a B → A: Nb, g , hashKB {Nb, Na, g , g } B → A: gb, hash {gb, ga} a b b a KB A → B: Na, Nb, g , g , hashKB {Nb, Na, g , g }, A → B: ga, gb, hash {gb, ga}, eh2 a b KB EK {sigA {Na, Nb, g , g , B}} B → A: gb, eh1 b a b B → A: g , EK {sigB {Na, Nb, g , g , A}}

Note: B does not need to store any short-term data in step 2

5 Topics 802.11i Wireless link-layer protocol

Wireless ‹ Application layer protocols (review) Access Point Radius Server • Kerberos, SSL/TLS Laptop computer Ethernet ‹ Network layer security (1) MAC Disabled, Port Blocked • IPsec Some details: key management techniques 802.11 Association • 802.11 (2) MAC Enabled, Port Blocked • Mobility 802.11x Authentication ‹ Secure network infrastructure (3) MAC Enabled, Port Blocked, PMK generated in STA and AS • DNSsec • Sender authentication for spam prevention AS move PMK to AP – Sender Policy Framework (SPF) 4-way Key management – Domain Keys – Secure ID (4) MAC Enabled, Port Allowed, PTK := KCK|KEK|TK – S/MIME Secure Communication

Mobile IPv6 Architecture Topics

‹ Application layer protocols (review) Mobile Node (MN) • Kerberos, SSL/TLS Direct connection via ‹ Network layer security IPv6 binding update • IPsec Some details: key management techniques • 802.11 • Mobility ‹ Secure network infrastructure Corresponding Node (CN) • DNSsec • Sender authentication for spam prevention ‹ Authentication is a – Sender Policy Framework (SPF) requirement – Domain Keys Home Agent (HA) ‹ Early proposals weak – Secure ID – S/MIME

Recall: DNS address resolution DNS Data flow

Question: www.cnn.com Zone administrator

www.cnn.com A ? . dns.cs.umass.edu Zone file lab.cs.umass.edu master resolver www.cnn.com A ? ask .com server stub the ip address of .com server resolver resolver xxx.xxx.xxx.xxx www.cnn.com A ? .com ask cnn.com server Dynamic the ip address of cnn.com server slaves updates add to cache stub resolver www.cnn.com A ?

xxx.xxx.xxx.xxx

www.cnn.com cnn.com

6 DNS Vulnerabilities DNSSEC

Cache impersonation ‹ Goals • Authenticate servers and requests Corrupting data Impersonating master • Integrity against data spoofing and corruption Zone administrator ‹ PK-DNSSEC (Public Key) • DNS server signs hash of resource record set master resolver • PKI based on DNS hierarchy: only root key must be distributed out Zone file of band ‹ SK-DNSSEC (Symmetric Certificates) • Combine encryption and MAC, roughly Ek(m, MAC(m)) Dynamic • Each message contains a nonce to avoid replay attack updates slaves • Each DNS node shares a key with its parent, called master key • The root domain has an asymmetric key pair stub resolver Hybrid approach Cache pollution by ‹ • The root servers use PK-DNSSEC Data spoofing Unauthorized updates • The top-level domains use SK-DNSSEC Data Server Protection Protection

Augment DNS for SPAM detection Domain Keys

SPF is most successful so far; advocated by AOL, available as open source

SPF Microsoft Sender ID

7 S/MIME Signatures Anti-Spam Summary

‹ Domain keys: PKI based on DNS hierarchy • Server makes public key available via DNS • Outgoing server signs message • Inbound mail servers check signatures ‹ SPF • Concise text records stored in DNS designate which servers send email from a domain, using IP address ranges, or established mail exchange (MX) records. ‹ Caller ID • Uses XML records stored in DNS, which list the IP address ranges that send e-mails legitimately from a particular domain. ‹ Sender ID: • The convergence of Microsoft's Caller ID for E-Mail proposal and Meng Wong's SPF. Microsoft has submitted this to the IETF. ‹ S/MIME • Public-key signatures using separate PKI

Topics

‹ Application layer protocols (review) • Kerberos, SSL/TLS ‹ Network layer security • IPsec Some details: key management techniques • 802.11 • Mobility ‹ Secure network infrastructure • DNSsec • Sender authentication for spam prevention – Sender Policy Framework (SPF) – Domain Keys – Secure ID – S/MIME

8