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