Security protocols Dos and don ts of client

Security protocols • Dos and don'ts of client authentication on the web (Kevin Fu, Kendra Smith, Nick Feamster) • Efficient, Do. S-Resistant, Secure Key Exchange for Internet Protocols (W. Aiello, S. Bellovin, M. Blaze, R. Canetti, J. Ioannidis, A. Keromytis, O. Reingold) Presented by Artur Saygin, CSE 525, OGI, Winter 2004

Why? • Well-studied authentication schemes exist – HTTP and SSL/TLS authentication • People continue using their own schemes • 27 web sites expected – Authentication scheme weakened on 2 – Unauthorized access gained on 8 – Secret authenticator key extracted on 1

Authentication • Client Authentication – providing of identity of client to server • Server Authentication – providing of identity of server to client

Client and server talk using HTTP. Since it’s stateless every request includes authenticator

Practical limitations of authentication • Deployability – Client computation (Java, Jscript, Tcl, Flash, Active. X). . ? ? – Client state – cookies • User acceptability – Easier for user is better • Performance – Stronger the protocol more it costs (SSL handshake)

Server security requirements • Coarse-grained service – cares about legality of access without taking care of visitors identity • Fine-grained service – cares about identity and therefore knows if access is legal

Confidentiality and privacy • Confidentiality – protection of traffic from disclosure by anyone except sender and recipient – Often confused with authentication • Privacy – protection of data from unauthorized access

Breaks • Existential forgery – breaks coarse-grained service • Selective forgery – breaks c-g service as well as fine-grained one • Replay attack – reusing sniffed authenticators • Total break – recovery of secret key to generate authenticator

Adversaries • Interrogative – adaptive querying of server – May use publicly known facts (list of usernames) • Eavesdropping – sniffing traffic and replaying back authenticators • Active – sniffing and modifying traffic

Hints for web client authentication • Cryptography issues • Password protection issues • Authenticators issues

Cryptography • • • Keep it simple Don’t be inventive Don’t rely on secrecy of protocol Understand tools you use Do not compose security scheme

Passwords • Limit exposure of passwords • Prohibit guessable passwords • Reauthenticate before password change

Authenticators • • • Make authenticator unforgeable Protect secret authenticator Avoid use of persistent cookies Limit lifetime of authenticators Bind authenticators to addresses

Example design • Simple, portable, secure against interrogative adversary exp=t&data=s&digest=MACk(exp=t&data=s) t – expiration time s – arbitrary data server associates with client MAC(…) - non-malleable message authenticator code (HMAC-MD 5, HMAC-SHA 1)

Example design • Expiration time (t) – – No need to keep state about user Avoidance of session number scheme Server makes decisions of time issues Differs from site to site • Arbitrary data (s) – More data without keeping state – Make sure its not sensitive

Example design • Authentication – If t is not expired server computes digest and compares with one that client sent • Revocation – Not provided in this scheme – Short session? – Server key rotation?

Alternative – session number scheme – Subject to guessing attack on session number space – O(n) server states required for n users – Complicated use on multi-server systems due to synchronization need

Security analysis • Non-malleable MAC secures against authenticator forgeries • Authenticator hijacking work between sniff time and expiration time – Run on top of SSL to provide confidentiality of authenticator • Brute force faces key size and key rotation parameters • Passwords still can be stolen

Implementation and performance • Perl 5. 4, LWP, HTTP, CGI, FCGI and Digest modules • Pentium III 733 MHz, Linux 2. 2 -18 kernel, Apache 1. 3. 17 • Gigabit link with 20 usec rtt between machines • Microbenchmark – 1000 trials of crypt() with 8 byte input and 2 byte salt • 8. 08 usec on average – 1000 trials of HMAC-SHA 1 with 20 byte input • 41. 4 usec average

End-to-end performance • 400 bytes from web server • 5000 requests • SSL takes 90 ms for new single connection • SSL authenticates the whole HTTP stream

General authentication protocols • Auth. A, EKE, Kerberos, SRP and others – Unsuitable for short term connections since take time to set up – Undesirable for web servers since require computations

Web-specific authentication protocols • Basic authentication in HTTP – Login and password send in request as plain text – Does not provide expiration, therefore exposes long term authenticator • Digest authentication in HTTP – Sends cryptographic hash of login, password, server nonce, URL and HTTP method – Very little client support • SSL – – Provides confidentiality Authentication is achieved via X. 509 certificates Public-key infrastructure required Client support issues (IE and NN certificates do not interoperate)

Just Fast Keying (JFK) • Security • Perfect Forward Secrecy (The confidence that the compromise of a long-term key does not compromise any earlier session keys". ) • • • Privacy (protection of initiator’s or responder’s identity) Memory-Do. S Computation Do. S Efficiency (2 round trips) Non-Negotiated (negotiations create complications) Simplicity

A little bit of notation • Hk(M) – keyed hash of message M using key k. H is pseudorandom function and its output is a secure MAC • {M}Ka. Ke – encryption using symmetric key Ke followed by MAC authentication with symmetric key Ka of message M. MAC is computed over cipher text prefixed with “R” or “I” • Sx[M] – digital non-message recovering signature of message M with private key belonging to x.

Message components • • • IPi – initiator’s network address gi – initiators current exponential gr – responder’s current exponential Ni – initiator’s nonce Nr – responder’s nonce IDi – initiator’s certificate or public key identifying information IDr – responder’s certificate or public key identifying information Idr’ – an indication by the initiator as to what auth info the latter should use HKr – transient hash key private to responder • • • sa – cryptographic and service properties association that initiator wants to establish. Contains Domain-of-Interpretation which JFK understands and application specific bit string sa’ – SA information the responder may need to give the initiator (responder’s SPI in IPSec) Kir – shared key derived from gir, NI and NR used for application protection Ke, Ka – shared keys derived from gir, NI and NR used to encrypt and authenticate messages 3 and 4 of JFK protocol grpinfo. R – all groups supported by responder, symmetric algorithms used to protect messages 3 and 4, and hash functions used for key generation

JFKi • I – R : NI, gi, IDR’ (1) • R – I : NI, NR, grpinfo. R, IDR, Sr[gr, grpinfo. R], HHKR(gr, NR, NI, IPI) (2) • I – R : NI, NR, gi, gr, (3) HHKR(gr, NR, NI, IPI), {IDI, sa, SI[NI, NR, gi, gr, IDR, sa]}Ka. Ke • R – I : {SR[NI, NR, gi, gr, IDI, sa’], sa’}Ka. Ke (4)

JFKi • Initiator’s identity is protected – Ke = Hgir(NI, NR, “ 1”) – Ka = Hgir(NI, NR, “ 2”) – Diffie-Hellman computation of gir requires • responder’s private key and initiator’s public key or • initiator’s private key and responder’s public key or • inverse function from known values which is extremely expensive

JFKi • Responder is protected from Do. S – Message 2 is “cheap” to compute – Elements of message 2 can be computed once in 30 sec; NR must change each time – Message 4 is computed after round trip indication – No states created – Pairs of message 3 and 4 cached to avoid duplicate computations • Cache is searched by auth token • Cache is purged after HKR is changed

JFKr • I – R : NI, gi (1) • R – I : NI, NR, grpinfo. R, HHKR(gr, NR, NI, IPI) (2) • I – R : NI, NR, gi, gr, (3) HHKR(gr, NR, NI, IPI), {IDI, IDR’, sa, SI[NI, NR, gi, grpinfo. R]}Ka. Ke • R – I : {IDR, sa’, SR[gr, NR, gi, NI} Ka. Ke (4)

Rejections • Message 2 is a rejection – responder does not accept the group of initiators exponential from message 1 • Message 4 is a rejection – lack of authorization – disagreement on service and cryptographic algorithms requested – something else (IP information)

IKE • Current standard for key establishment and SA parameter negotiation • Two phase protocol • Phase #1 (Phase 1 SA) decides – Auth method – Encryption/hash method – Diffie-Hellman group

Phase #1 –Main mode • 3 rd and 5 th messages are objects for Do. S cpu attack • Identities protected at cost of 3 round trips

Phase #1 – Aggressive mode • Do. S memory attack on responder from random IPs • No identity protection

Phase #2 – Quick mode • Decides – Security algorithms – Type of traffic to protect – IP security protocol (ESP/AH) • Messages protected using Phase #1 keys

IKEv 2 • Cookie support • Avoidance from memory based Do. S attacks