Secure Remote Password SRP

1
Secure Remote Password (SRP)

• Bernard Aboba
• Dan Simon
• Tim Moore
• Microsoft

2
What is Secure Remote Password?

• An abstract protocol specification
• Creator Thomas Wu, Stanford University
• RFC 2945 (Proposed Standard)
• An EAP method
• Draft-ietf-pppext-eap-srp-03.txt
• Standardized within PPPEXT
• Author James Carlson (Sun Microsystems)
• A GSS-API method
• Draft-ietf-cat-srpgm-02.txt (expired)
• A key derivation mechanism for TLS
• Draft-ietf-tls-srp-01.txt
• Standardized within TLS WG
• Author D. Taylor (Forge Research)
• A set of SASL mechanisms
• Draft-burdis-cat-srp-sasl-04.txt
• Individual submission
• Authors K.R. Burdis (Rhodes University), R.
  Naffah (Forge Research)
• A submission to IEEE P1363
• See http//grouper.ieee.org/groups/1363/

3
Pros and Cons of SRP

• Pros
• Support for mutual authentication and key
  derivation
• No changes required to IEEE 802.1X, EAP (RFC
  2284)
• Uses password-only credentials (no client or
  server certificates)
• Thought to be invulnerable to dictionary attack
  on the on-the-wire protocol
• Does not require password to be stored either in
  cleartext or reversibly encrypted
• Intellectual property statement filed by Stanford
  University
• http//www.ietf.org/ietf/IPR/WU-SRP
• ftp//ftp.merit.edu/mail.archives/ietf-ppp-archive
  /ietf-ppplog.2001.06
• Cons
• Computationally intensive
• 2 MODEXP calculations on each side (assuming
  verifier is cached)
• Only 1 exponentiation required for EKE
• Limited flexibility
• No support for ECC groups, only DH groups
• Requires storage of new per-user credentials
• Username, Salt, Password verifier, prime
  modulus/generator group
• Vulnerable to offline dictionary attack against
  credential store

4
How can SRP be used by 802.11 TGi?

• As an EAP method
• EAP SRP (draft-ietf-pppext-eap-srp-03.txt)
• Simplest way to obtain SRP functionality
• As a Kerberos Extension or GSS-API mechanism
• EAP GSS (draft-aboba-pppext-eapgss-04.txt)
• Wu proposal for SRP integration within Kerberos
  http//theory.stanford.edu/tjw/krbpass.html
• SRP GSS-API mechanismDraft-ietf-cat-srpgm-02.txt
• SRP negotiated via SPNEGO within EAP-GSS
• As a TLS mechanism
• SRP negotiated within TLS (draft-ietf-tls-srp-01.t
  xt)
• Compatible with future upgrade to EAP-TLS with
  certificates (RFC 2716)
• Requires major change to TLS implementations
• Differences
• Overhead
• More overhead for layered negotiations
• Protected authentication negotiation
• Supported within GSS-API (SPNEGO), TLS
• Not supported within pure EAP approach (handled
  via policy)

5
How Does it Work?(From RFC 2945)

• The server stores user credentials as 5-tuples
  of the form
• ltusernamegt, ltpassword verifiergt, ltsaltgt, g, N
• ltsaltgt random()
• x SHA(ltsaltgt SHA(ltusernamegt "" ltraw
  passwordgt))
• ltpassword verifiergt v gx N
• N prime modulus g generator
• Prime modulus/generator/salt are constant each
  time a given user authenticates
• If they could vary, server would need to
  pre-calculate multiple verifiers, one for each
  salt/prime modulus/generator combination
• Client and server calculate and exchange public
  keys
• Server public key derived from the password
  verifier
• DH exchange used to derive a key
• Client and server exchange hashes based on the DH
  key, verifier, group, salt, username, etc.
• Authenticates the DH exchange

6
Protocol Exchange

• Client Server
• -------- ------
• U ltusernamegt -gt
• lt- salt
• a random()
• A ga N -gt
• v ltstored
  verifiergt
• b
  random()
• lt- B (v
  gb) N
• p ltraw passwordgt
• x SHA(s SHA(U "" p))
• S (B - gx) (a u x) N S (A
  vu) b N
• K SHA_Interleave(S) K
  SHA_Interleave(S)
• M H(H(N) XOR H(g) H(U) s A B K)-gt
  (CLIENT AUTH)
• lt- H(A M
  K)
• (SERVER
  AUTH)

7
Short Form Exchange

• Client Server
• -------- ------
• U, A -gt
• lt-s, B
• H(H(N) XOR H(g) H(U) s A B K)-gt
• lt-H(A M K)

• Usable where client initiates (e.g. GSS_API, TLS)
• Not usable where server initiates (EAP)

8
What Does SRP Not Provide?

• Specification of bits on the wire
• RFC 2945 is an abstract protocol specification
  need to adapt it for a particular use
• Specification for how additional keys are derived
  from SRP key (K)
• Bad idea to use K on the wire (master key would
  become stale)
• Need to describe how to derive IVs,
  authentication, encryption keys of appropriate
  lengths in each direction from SRP master key (K)
• Protected ciphersuite negotiation
• Needed to guard against down negotiation attacks

9
Protected Ciphersuite Negotiation

• Why do we care?
• Without protection, ciphersuite negotiation is
  vulnerable to man in the middle downgrading
  negotiated authentication method
• Example AES/OCB was available, but attacker
  caused WEPv1 to be negotiated instead
• Why isnt this handled in EAP?
• EAP doesnt negotiate ciphersuite, only
  authentication method
• RFC 2284 does not provide for per-packet
  authentication, integrity or confidentiality for
  EAP packets
• Solutions
• Negotiate the ciphersuite within an IEEE 802.1X
  message
• Can secure ciphersuite negotiation using the
  negotiated key
• Enables maintenance of the ciphersuite list by
  IEEE 802
• Avoids having to implement protected ciphersuite
  negotiation within each EAP method
• Disadvantage wont provide ciphersuite
  negotiation within other links layers (e.g. PPP)
• Negotiate the ciphersuite within the chosen EAP
  method
• Example RFC 2716 (EAP-TLS)
• Negotiated choice may be rubber-stamped in link
  layer negotiation
• Example PPP ECP

10
Protected Ciphersuite Negotiation (contd)

• Case 1 EAP server colocated with AP
• EAP server knows ciphersuites supported by AP
• Negotiated ciphersuite always supported by the AP
• Case 2 EAP server separate from AP
• EAP server may not know ciphersuites supported by
  AP
• Could have mixture of legacy APs (WEP1) and new
  APs (WEP2)
• Could do manual configuration
• Create a table of support ciphersuites indexed
  by NAS-Identifier or NAS-IP-Address
• Tedious for large installations
• Solution 1 Handle in AAA
• AP informs EAP server of supported ciphersuites
  via AAA attribute(s) in Access-Request
• AAA server sends selected ciphersuite to AP along
  with keys
• Solution 2 Handle in 802.11
• AP announces supported ciphersuites
• EAP server offers union of all supported
  ciphersuites
• Client negotiates a ciphersuite supported by the
  AP
• Problem Negotiation not protected

11
TLS SRP Exchange(From draft-ietf-tls-srp-01.txt)
Client
Server ------
------ Client Hello (U, mds)-gt
lt- Server Hello
lt- Server Key Exchange
(md, g, N, s) Client Key Exchange (A) -gt
lt- Server Key
Exchange (B)
lt- Server Hello Done change cipher spec Finished
--gt
change cipher spec
lt- Finished
12
How Does TLS SRP Work?

• Client and server mutually authenticate
• Only client identity provided, not server
• SRP used as key exchange mechanism within TLS
• Message digest algorithm negotiated within SRP
  exchange
• TLS MIC used instead of exchange of hashes within
  SRP
• Issues
• Could use short form exchange
• Need ciphersuites appropriate for 802.11
• No RC4-40_with_CRC32 ciphersuite in TLS (WEP1)
• Need specification for deriving 802.11 keys from
  master key

13
How does EAP SRP Work?

• EAP SRP is a reasonably faithful implementation
  of RFC 2945 as an EAP method
• Additional features
• Server can provide its identity
• Derived key can be used in ECP or not
• Support for lightweight, periodic
  reauthentications
• Support for hidden pseudonyms for identity
  protection
• Bugs/gripes
• Prime modulus/generator should be specified as
  groups, not numbers
• Current spec analogous to IKE new group mode
• Difficult for client to verify validity of the
  offered group, will probably just compare the
  offered group against a known good list
• Best to just assign group numbers to known good
  groups
• Example groups listed in SRP-SASL draft with
  prime modulus gt 1024 bits

14
Summary

• SRP attractive for password-based authentication
• Thought to be invulnerable to dictionary attack
• Does not require storing password in clear or
  reversibly encrypted
• Intellectual property filings available for
  inspection
• IETF standardization process underway
• RFC 2945 at Proposed Standard
• SRP-TLS, EAP SRP drafts on Standards Track
• Several ways to use SRP
• Can be negotiated within TLS, EAP, GSS-API
• Recommendation
• SRP worthy of consideration as mandatory-to-implem
  ent method for 802.11 Tgi
• Simplest to use SRP as a straight EAP mechanism
• Other secure password-schemes may also be worth
  examining (EKE, etc.) if intellectual property
  issues can be resolved

15
References

• T. Wu, "The SRP Authentication and Key Exchange
  System, RFC 2945, 09/2000
• T. Wu, "The Secure Remote Password Protocol", in
  Proceedings of the 1998 Internet Society
  Symposium on Network and Distributed Systems
  Security, San Diego, CA, pp. 97-111

16
Feedback?