doc.: IEEE /524r0 Submission November 2001 Bernard Aboba, MicrosoftSlide 1 Secure Remote Password (SRP) Bernard Aboba Dan Simon Tim Moore Microsoft

doc.: IEEE /524r0 Submission November 2001 Bernard Aboba, MicrosoftSlide 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

doc.: IEEE /524r0 Submission November 2001 Bernard Aboba, MicrosoftSlide 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 ftp://ftp.merit.edu/mail.archives/ietf-ppp-archive/ietf-ppplog 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

doc.: IEEE /524r0 Submission November 2001 Bernard Aboba, MicrosoftSlide 4 How can SRP be used by 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: –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)

doc.: IEEE /524r0 Submission November 2001 Bernard Aboba, MicrosoftSlide 5 How Does it Work? (From RFC 2945) The server stores user credentials as 5-tuples of the form: –{,,, g, N} – = random() –x = SHA( | SHA( | ":" | )) – = 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

doc.: IEEE /524r0 Submission November 2001 Bernard Aboba, MicrosoftSlide 6 Protocol Exchange Client Server U = -> <- salt a = random() A = g^a % N -> v = b = random() <- B = (v + g^b) % N p = x = SHA(s | SHA(U | ":" | p)) S = (B - g^x) ^ (a + u * x) % N S = (A * v^u) ^ b % N 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)

doc.: IEEE /524r0 Submission November 2001 Bernard Aboba, MicrosoftSlide 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)

doc.: IEEE /524r0 Submission November 2001 Bernard Aboba, MicrosoftSlide 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

doc.: IEEE /524r0 Submission November 2001 Bernard Aboba, MicrosoftSlide 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

doc.: IEEE /524r0 Submission November 2001 Bernard Aboba, MicrosoftSlide 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 AP announces supported ciphersuites EAP server offers union of all supported ciphersuites Client negotiates a ciphersuite supported by the AP Problem: Negotiation not protected

doc.: IEEE /524r0 Submission November 2001 Bernard Aboba, MicrosoftSlide 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

doc.: IEEE /524r0 Submission November 2001 Bernard Aboba, MicrosoftSlide 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 No “RC4-40_with_CRC32” ciphersuite in TLS (WEP1) –Need specification for deriving keys from master key

doc.: IEEE /524r0 Submission November 2001 Bernard Aboba, MicrosoftSlide 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

doc.: IEEE /524r0 Submission November 2001 Bernard Aboba, MicrosoftSlide 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 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

doc.: IEEE /524r0 Submission November 2001 Bernard Aboba, MicrosoftSlide 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

doc.: IEEE /524r0 Submission November 2001 Bernard Aboba, MicrosoftSlide 16 Feedback?