Security Protocols

CS 155 May 26, 2005 Security Protocols John Mitchell

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

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

Transport (TCP) Internet (IP) Network interface Physical layer TLS protocol layer over TCP/IP http ftp telnet Application nntp SSL/TLS

SSL/TLS ClientHello S C ServerHello, [Certificate], [ServerKeyExchange], [CertificateRequest], ServerHelloDone [Certificate], ClientKeyExchange, [CertificateVerify] Finished switch to negotiated cipher switch to negotiated cipher Finished

Hi Client Server Hello How are you? Two useful ideas • Authentication 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 • Integrity 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

Handshake Protocol ClientHelloCSC, VerC, SuiteC, NC ServerHelloS  CVerS, SuiteS, NS,signCA{S, KS} ClientVerify C  SsignCA{ C, VC} {VerC, SecretC} signC {Hash(Master(NC, NS, SecretC) + Pad2 + Hash(Msgs + C + Master(NC, NS, SecretC) + Pad1)) } (Change to negotiated cipher) ServerFinished S  C{ Hash(Master(NC, NS, SecretC) + Pad2 + Hash(Msgs + S + Master(NC, NS, SecretC) + Pad1)) } ClientFinishedC  S{ Hash(Master(NC, NS, SecretC) + Pad2 + Hash( Msgs + C + Master(NC, NS, SecretC) + Pad1)) } KS Master(NC, NS, SecretC) Master(NC, NS, SecretC)

IP-level security (IPSec) • Encrypt and authenticate traffic at the IP level • Three security functions • Authentication • Confidentiality • Key management • Advantages 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

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

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

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

IKE: Many modes • Main mode • Authentication by pre-shared keys • Auth with digital signatures • Auth with public-key encryption • Auth with revised public-key encryption • Quick mode • Compress number of messages • Also four authentication options

Aug 2001 Position Statement • In the several years since the standardization of the IPSEC protocols (ESP, AH, and ISAKMP/IKE), … several security problems…, most notably IKE. • Formal and semi-formal analyses by Meadows, Schneier et al, and Simpson, have shown … security problems in IKE stem directly from its complexity. • It 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. • The Security Area Directors have asked the IPSEC working group to come up with a replacement for IKE.

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

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

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

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

STS Family STS0H STS0 cookie • Properties: • Certificates from CA • Shared secret: gab • Identity protection • DoS protection • Reverse ID protection distribute certificates open responder STSa JFK0 STSaH m=gx, n=gy k=gxy STS STSH JFK1 protect identities STSPH JFKi STSP symmetric hash JFKr

Example • Construct protocol with properties: • Shared secret • Authenticated • Identity Protection • DoS Protection • Design requirements for IKE, JFK, IKEv2 (IPSec key exchange protocol)

Component 1 • Diffie-Hellman A  B: ga B  A: gb • Shared secret (with someone) • A deduces: Knows(Y, gab)  (Y = A) ۷ Knows(Y,b) • Authenticated • Identity Protection • DoS Protection

Component 2 • Challenge Response: A  B: m, A B  A: n, sigB {m, n, A} A  B: sigA {m, n, B} • Shared secret (with someone) • Authenticated • A deduces: Received (B, msg1) Λ Sent (B, msg2) • Identity Protection • DoS Protection

m := ga n := gb Composition • ISO 9798-3 protocol: A  B: ga, A B  A: gb, sigB {ga, gb, A} A  B: sigA {ga, gb, B} • Shared secret: gab • Authenticated • Identity Protection • DoS Protection

Refinement • Encrypt signatures: A  B: ga, A B  A: gb, EK {sigB {ga, gb, A}} A  B: EK {sigA {ga, gb, B}} • Shared secret: gab • Authenticated • Identity Protection • DoS Protection

Transformation • Use cookie: JFK core protocol A  B: ga, A B  A: gb, hashKB {gb, ga} A  B: ga, gb, hashKB {gb, ga} EK {sigA {ga, gb, B}} B  A: gb, EK {sigB {ga, gb, A}} • Shared secret: gab • Authenticated • Identity Protection • DoS Protection • (Here B must store b in step 2, but can fix this later…)

Cookie transformation • Typical protocol • Client sends request to server • Server sets up connection, responds • Client may complete session or not (DOS) • Cookie 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

Cookie in JFK • Protocol susceptible to DoS A  B: ga, A B  A: gb, EK {sigB {ga, gb, A}} A  B: EK {sigA {ga, gb, B}} • Use cookie: JFK core protocol A  B: ga, A B  A: gb, hashKB {gb, ga} A  B: ga, gb, hashKB {gb, ga}, eh2 B  A: gb, eh1 eh1 eh2

Efficiency: Reuse D-H key • Costly to compute ga, gb, gab • Solution • Keep medium-term ga, gb (change ~10 min) • Replace ga by pair ga, nonce • JFKi, JFKr protocols (except cert or grpinfo, …) A  B: Na, ga, A B  A: Nb, gb, hashKB {Nb,Na, gb, ga} A  B: Na,Nb, ga, gb, hashKB {Nb,Na, gb, ga}, EK {sigA {Na,Nb, ga, gb, B}} B  A: gb, EK {sigB {Na,Nb, ga, gb, A}} • Note: B does not need to store any short-term data in step 2

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

IPv6 Mobile IPv6 Architecture • Authentication is a requirement • Early proposals weak Mobile Node (MN) Direct connection via binding update Corresponding Node (CN) Home Agent (HA)

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

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

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

DNSSEC • Goals • Authenticate servers and requests • Integrity against data spoofing and corruption • PK-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 • SK-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 • Hybrid approach • The root servers use PK-DNSSEC • The top-level domains use SK-DNSSEC

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

Domain Keys

SPF

Microsoft Sender ID

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

Security Protocols