1. Security Protocols John Mitchell CS 155May 26, 2005

2. Topics uApplication layer protocols (review) Kerberos, SSL/TLS uNetwork layer security IPsec Some details: key management techniques 802.11 Mobility uSecure network infrastructure DNSsec Sender authentication for spam prevention –Sender Policy Framework (SPF) –Domain Keys –Secure ID –S/MIME

3. Ticket 2 Ticket 1 Kerberos Protocol Client KDC Service TGS {Kt} Kc C TGS {Ks} Kt {C} Kt S {C} Ks Ktgs Kc Kv {C, Ks} Kv {C, Kt} Ktgs {C, Ks} Kv {C, Kt} Ktgs

4. TLS protocol layer over TCP/IP Network interface Transport (TCP) Physical layer Internet (IP) Applicationtelnet httpftp nntp SSL/TLS

5. C ClientHello ServerHello, [Certificate], [ServerKeyExchange], [CertificateRequest], ServerHelloDone S [Certificate], ClientKeyExchange, [CertificateVerify] Finished switch to negotiated cipher Finished switch to negotiated cipher

6. Two useful ideas uAuthentication using certificate authority (CA) CA has “widely known” verification key –Examples: Verisign, AT&T, MCI, Keywitness Corp Canada CA supplies signed certificate with site’s public key uIntegrity based on hashing Client, server communicate Compare hash of all messages –Compute hash(hi,hello,howareyou?) locally –Exchange hash values under encryption Abort if intervention detected ClientServer Hi Hello How are you?

7. Handshake Protocol ClientHello C  S C, Ver C, Suite C, N C, Suite S, N S, S, K S ServerHello S  C Ver S, Suite S, N S, sign CA { S, K S } ClientVerify C  S sign CA { C, V C } { Ver C, Secret C } N S sign C { Hash( Master(N C, N S, Secret C ) + Pad 2 + N S Hash(Msgs + C + Master(N C, N S, Secret C ) + Pad 1 )) } (Change to negotiated cipher) N S ServerFinished S  C { Hash( Master(N C, N S, Secret C ) + Pad 2 + N S Hash( Msgs + S + Master(N C, N S, Secret C ) + Pad 1 )) } N S ClientFinished C  S { Hash( Master(N C, N S, Secret C ) + Pad 2 + N S Hash( Msgs + C + Master(N C, N S, Secret C ) + Pad 1 )) } SKSSKS S Master(N C, N S, Secret C )

8. Topics uApplication layer protocols (review) Kerberos, SSL/TLS uNetwork layer security IPsec Some details: key management techniques 802.11 Mobility uSecure network infrastructure DNSsec Sender authentication for spam prevention –Sender Policy Framework (SPF) –Domain Keys –Secure ID –S/MIME

9. IP-level security (IPSec) uEncrypt and authenticate traffic at the IP level uThree security functions Authentication Confidentiality Key management uAdvantages over application layer (TLS) Implemented at gateway, not desktop Transparent to application programs and users Data can be sent unencrypted in LAN to avoid encryption overhead

10. Network level protocol abcdefghi abcdefghi abc TCP def TCP ghi TCP IP abc TCP IP def TCP IP ghi TCP IP Application data uvw TCP IP IPSec xyz TCP IP IPSec lmn TCP IP IPSec

11. IP Security usage scenarios

12. IPSec overview uSecurity 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

13. Transport and tunnel modes uTransport mode Protect only the data payload of an IP packet Used for end-to-end encryption between two hosts (client/server) uTunnel mode Protection for the entire IP packet (incl IP address) Used for firewall/secure router  firewall/secure router

14. IKE: Many modes uMain mode Authentication by pre-shared keys Auth with digital signatures Auth with public-key encryption Auth with revised public-key encryption uQuick mode Compress number of messages Also four authentication options

15. Aug 2001 Position Statement u In the several years since the standardization of the IPSEC protocols (ESP, AH, and ISAKMP/IKE), … several security problems…, most notably IKE. uFormal and semi-formal analyses by Meadows, Schneier et al, and Simpson, have shown … security problems in IKE stem directly from its complexity. uIt seems … only a matter of time before serious *implementation* problems become apparent, again due to the complex nature of the protocol, and the complex implementation that must surely follow. uThe Security Area Directors have asked the IPSEC working group to come up with a replacement for IKE.

16. Topics uApplication layer protocols (review) Kerberos, SSL/TLS uNetwork layer security IPsec Some details: key management techniques 802.11 Mobility uSecure network infrastructure DNSsec Sender authentication for spam prevention –Sender Policy Framework (SPF) –Domain Keys –Secure ID –S/MIME

17. Some protocol details, for fun uProtocols that produce shared keys are Short, typically a few simple messages Rely on cryptographic primitives for authentication and secrecy Subtle and prone to error uNext few slides 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

18. Needham-Schroeder Protocol { A, NonceA } { NonceA, NonceB } { NonceB} KaKa Kb Result: A and B share two private numbers not known to any observer without Ka -1, Kb -1 AB Kb

19. Anomaly in Needham-Schroeder AE B { A, Na } { Na, Nb } { Nb } Ke Kb Ka Ke Evil agent E tricks honest A into revealing private key Nb from B. Evil E can then fool B. [Lowe]

20. Needham-Schroeder Lowe { A, NonceA } { NonceA, B, NonceB } { NonceB} Ka Kb AB Authentication? Secrecy? Replay attack Forward secrecy? Denial of service? Identity protection?

21. STS Family m=g x, n=g y k=g xy STS 0H STS a STS aH STS H STS 0 STS PH JFK 1 distribute certificates cookie open responder JFK 0 symmetric hash JFKi protect identities JFKr STS P Properties: Certificates from CA Shared secret: g ab Identity protection DoS protection Reverse ID protection

22. Example uConstruct protocol with properties: Shared secret Authenticated Identity Protection DoS Protection uDesign requirements for IKE, JFK, IKEv2 (IPSec key exchange protocol)

23. Component 1 uDiffie-Hellman A  B: g a B  A: g b Shared secret (with someone) –A deduces: Knows(Y, g ab)  (Y = A) ۷ Knows(Y,b) Authenticated Identity Protection DoS Protection

24. Component 2 uChallenge Response: A  B: m, A B  A: n, sig B {m, n, A} A  B: sig A {m, n, B} Shared secret (with someone) Authenticated –A deduces: Received (B, msg1) Λ Sent (B, msg2) Identity Protection DoS Protection

25. Composition uISO 9798-3 protocol: A  B: g a, A B  A: g b, sig B {g a, g b, A} A  B: sig A {g a, g b, B} Shared secret: gab Authenticated Identity Protection DoS Protection m := g a n := g b

26. Refinement uEncrypt signatures: A  B: g a, A B  A: g b, E K {sig B {g a, g b, A}} A  B: E K {sig A {g a, g b, B}} Shared secret: gab Authenticated Identity Protection DoS Protection

27. Transformation uUse cookie: JFK core protocol A  B: g a, A B  A: g b, hash KB {g b, g a } A  B: g a, g b, hash KB {g b, g a } E K {sig A {g a, g b, B}} B  A: g b, E K {sig B {g a, g b, A}} Shared secret: gab Authenticated Identity Protection DoS Protection (Here B must store b in step 2, but can fix this later…)

28. Cookie transformation uTypical protocol Client sends request to server Server sets up connection, responds Client may complete session or not (DOS) uCookie version Client sends request to server Server sends hashed data back –Send message #2 later after client confirms Client confirms by returning hashed data Need extra step to send postponed message

29. Cookie in JFK uProtocol susceptible to DoS A  B: g a, A B  A: g b, E K {sig B {g a, g b, A}} A  B: E K {sig A {g a, g b, B}} uUse cookie: JFK core protocol A  B: g a, A B  A: g b, hash KB {g b, g a } A  B: g a, g b, hash KB {g b, g a }, eh2 B  A: g b, eh1 eh1 eh2

30. Efficiency: Reuse D-H key uCostly to compute g a, g b, g ab uSolution Keep medium-term g a, g b (change ~10 min) Replace g a by pair g a, nonce uJFKi, JFKr protocols (except cert or grpinfo, …) A  B: Na, g a, A B  A: Nb, g b, hash KB {Nb, Na, g b, g a } A  B: Na, Nb, g a, g b, hash KB {Nb, Na, g b, g a }, E K {sig A {Na, Nb, g a, g b, B}} B  A: g b, E K {sig B {Na, Nb, g a, g b, A}} Note: B does not need to store any short-term data in step 2

31. Topics uApplication layer protocols (review) Kerberos, SSL/TLS uNetwork layer security IPsec Some details: key management techniques 802.11 Mobility uSecure network infrastructure DNSsec Sender authentication for spam prevention –Sender Policy Framework (SPF) –Domain Keys –Secure ID –S/MIME

32. 802.11i Wireless link-layer protocol Ethernet Access Point Radius Server Laptop computer Wireless 4-way Key management 802.11 Association 802.11x Authentication (1) MAC Disabled, Port Blocked (2) MAC Enabled, Port Blocked (3) MAC Enabled, Port Blocked, PMK generated in STA and AS AS move PMK to AP Secure Communication (4) MAC Enabled, Port Allowed, PTK := KCK|KEK|TK

33. Mobile IPv6 Architecture IPv6 Mobile Node (MN) Corresponding Node (CN) Home Agent (HA) Direct connection via binding update uAuthentication is a requirement uEarly proposals weak

34. Topics uApplication layer protocols (review) Kerberos, SSL/TLS uNetwork layer security IPsec Some details: key management techniques 802.11 Mobility uSecure network infrastructure DNSsec Sender authentication for spam prevention –Sender Policy Framework (SPF) –Domain Keys –Secure ID –S/MIME

35. Recall: DNS address resolution stub resolver Question: www.cnn.com www.cnn.com A ? resolver. www.cnn.com A ? ask.com server the ip address of.com server.com www.cnn.com A ? ask cnn.com server the ip address of cnn.com server cnn.com www.cnn.com A ? xxx.xxx.xxx.xxx add to cache www.cnn.com lab.cs.umass.edu dns.cs.umass.edu

36. DNS Data flow master resolver stub resolver Zone administrator Zone file slaves Dynamic updates

37. Data Protection Server Protection DNS Vulnerabilities Zone file slaves master resolver stub resolver Zone administrator Dynamic updates Cache pollution by Data spoofing Unauthorized updates Corrupting data Impersonating master Cache impersonation

38. DNSSEC uGoals Authenticate servers and requests Integrity against data spoofing and corruption uPK-DNSSEC (Public Key) DNS server signs hash of resource record set PKI based on DNS hierarchy: only root key must be distributed out of band uSK-DNSSEC (Symmetric Certificates) Combine encryption and MAC, roughly Ek(m, MAC(m)) Each message contains a nonce to avoid replay attack Each DNS node shares a key with its parent, called master key The root domain has an asymmetric key pair uHybrid approach The root servers use PK-DNSSEC The top-level domains use SK-DNSSEC

39. Augment DNS for SPAM detection SPF is most successful so far; advocated by AOL, available as open source

40. Domain Keys

41. SPF

42. Microsoft Sender ID

43. S/MIME Signatures

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

45. Topics uApplication layer protocols (review) Kerberos, SSL/TLS uNetwork layer security IPsec Some details: key management techniques 802.11 Mobility uSecure network infrastructure DNSsec Sender authentication for spam prevention –Sender Policy Framework (SPF) –Domain Keys –Secure ID –S/MIME