1 / 35

Security protocols

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).

tyraj
Download Presentation

Security protocols

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. 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

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

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

  5. 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)

  6. 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

  7. 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

  8. 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

  9. 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

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

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

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

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

  14. 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)

  15. 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

  16. 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?

  17. 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

  18. 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

  19. 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

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

  21. 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

  22. 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)

  23. 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

  24. 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.

  25. 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 Message components

  26. 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)

  27. 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

  28. 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

  29. 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)

  30. 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)

  31. 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

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

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

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

  35. IKEv2 • Cookie support • Avoidance from memory based DoS attacks

More Related