Secure Remote Password (SRP)

1. Secure Remote Password (SRP) Bernard Aboba Dan Simon Tim Moore Microsoft Bernard Aboba, 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/ Bernard Aboba, Microsoft

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 Bernard Aboba, Microsoft

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-08.txt) • Wu proposal for SRP integration within Kerberos: http://theory.stanford.edu/~tjw/krbpass.html • SRP GSS-API mechanism:Draft-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.txt) • 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) Bernard Aboba, Microsoft

5. How Does it Work?(From RFC 2945) • The server stores user credentials as 5-tuples of the form: • {<username>, <password verifier>, <salt>, g, N} • <salt> = random() • x = SHA(<salt> | SHA(<username> | ":" | <raw password>)) • <password verifier> = v = g^x % 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 Bernard Aboba, Microsoft

6. Protocol Exchange Client Server -------- ------ U = <username> -> <- salt a = random() A = g^a % N -> v = <stored verifier> b = random() <- B = (v + g^b) % N p = <raw password> x = SHA(s | SHA(U | ":" | p)) S = (B - g^x) ^ (a + u * x) % N S = (A * v^u) ^ b % N K = SHA_Interleave(S) K = SHA_Interleave(S) M = H(H(N) XOR H(g) | H(U) | s | A | B | K)-> (CLIENT AUTH) <- H(A | M | K) (SERVER AUTH) Bernard Aboba, Microsoft

7. “Short Form” Exchange Client Server -------- ------ U, A -> <-s, B H(H(N) XOR H(g) | H(U) | s | A | B | K)-> <-H(A | M | K) • Usable where client initiates (e.g. GSS_API, TLS) • Not usable where server initiates (EAP) Bernard Aboba, Microsoft

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 • Protection against verifier exposure • Implementations need to protect verifier as they would a password or private key Bernard Aboba, Microsoft

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 isn’t this handled in EAP? • EAP doesn’t 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: won’t 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 Bernard Aboba, Microsoft

10. Protected Ciphersuite Negotiation (cont’d) • 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 Bernard Aboba, Microsoft

11. TLS SRP Exchange(From draft-ietf-tls-srp-01.txt) Client Server ------ ------ Client Hello (U, mds)-> <- Server Hello <- Server Key Exchange (md, g, N, s) Client Key Exchange (A) -> <- Server Key Exchange (B) <- Server Hello Done change cipher spec Finished --> change cipher spec <- Finished Bernard Aboba, Microsoft

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 Bernard Aboba, Microsoft

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 >= 1024 bits Bernard Aboba, Microsoft

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-implement 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 Bernard Aboba, Microsoft

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 Bernard Aboba, Microsoft

16. Feedback? Bernard Aboba, Microsoft