Security protocols

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 its
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
• Dont be inventive
• Dont 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
• exptdatasdigestMACk(exptdatas)
• 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 initiators or responders
  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
• MKaKe 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
• SxM digital non-message recovering signature
  of message M with private key belonging to x.

25
Message components

• IPi initiators network address
• gi initiators current exponential
• gr responders current exponential
• Ni initiators nonce
• Nr responders nonce
• IDi initiators certificate or public key
  identifying information
• IDr responders 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 (responders 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

26
JFKi

• I R NI, gi, IDR
  (1)
• R I NI, NR, gr, grpinfoR, IDR,
  (2)
• Srgr, grpinfoR,
• HHKR(gr, NR, NI, IPI)
• I R NI, NR, gi, gr,
  (3)
• HHKR(gr, NR, NI, IPI),
• IDI, sa, SINI, NR, gi, gr,
  IDR, saKaKe
• R I SRNI, NR, gi, gr, IDI, sa, sa,
  saKaKe (4)

27
JFKi

• Initiators identity is protected
• Ke Hgir(NI, NR, 1)
• Ka Hgir(NI, NR, 2)
• Diffie-Hellman computation of gir requires
• responders private key and initiators public
  key
• or
• initiators private key and responders 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, SINI, NR, gi,
  gr, grpinfoRKaKe
• R I IDR, sa, SRgr, 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