security protocols
DESCRIPTION
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). - PowerPoint PPT PresentationTRANSCRIPT
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