1 / 16

Secure Remote Password (SRP)

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

jakeem-wolfe
Download Presentation

Secure Remote Password (SRP)

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

More Related