Security protocols

• Dos and don'ts of client authentication on the web (Kevin Fu, Kendra Smith, Nick Feamster)

• Efficient, DoS-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, CSE525, 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,

ActiveX).. ??– 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-MD5, HMAC-SHA1)

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 733MHz, Linux 2.2-18 kernel, Apache 1.3.17

• Gigabit link with 20usec rtt between machines

• Microbenchmark– 1000 trials of crypt() with 8byte input and 2byte salt

• 8.08usec on average

– 1000 trials of HMAC-SHA1 with 20byte input• 41.4usec average

End-to-end performance

• 400 bytes from web server

• 5000 requests

• SSL takes 90ms for new single connection

• SSL authenticates the whole HTTP stream

General authentication protocols

• AuthA, 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-DoS• Computation DoS• 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}KaKe – 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

• grpinfoR – 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, gr, grpinfoR, IDR, (2)

Sr[gr, grpinfoR],

HHKR(gr, NR, NI, IPI)

• I – R : NI, NR, gi, gr, (3)

HHKR(gr, NR, NI, IPI),

{IDI, sa, SI[NI, NR, gi, gr, IDR, sa]}KaKe

• R – I : {SR[NI, NR, gi, gr, IDI, sa, sa’], sa’}KaKe (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 DoS– 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, gr, grpinfoR, (2)

HHKR(gr, NR, NI, IPI)

• I – R : NI, NR, gi, gr, (3)

HHKR(gr, NR, NI, IPI),

{IDI, IDR’, sa, SI[NI, NR, gi, gr, grpinfoR]}KaKe

• R – I : {IDR, sa’, SR[gr, NR, gi, NI} KaKe (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

• 3rd and 5th messages are objects for DoS cpu attack

• Identities protected at cost of 3 round trips

Phase #1 – Aggressive mode

• DoS 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

IKEv2

• Cookie support

• Avoidance from memory based DoS attacks