July 2001 doc IEEE 802 11 01497 r

July 2001 doc. : IEEE 802. 11 -01/497 r 0 Secure Remote Password (SRP) Bernard Aboba Dan Simon Tim Moore Microsoft Submission 1 Bernard Aboba, Microsoft

July 2001 • doc. : IEEE 802. 11 -01/497 r 0 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 P 1363 – See http: //grouper. ieee. org/groups/1363/ Submission 2 Bernard Aboba, Microsoft

July 2001 Pros and Cons of SRP • Pros – – – doc. : IEEE 802. 11 -01/497 r 0 Support for mutual authentication and key derivation No changes required to IEEE 802. 1 X, 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 Submission 3 Bernard Aboba, Microsoft

July 2001 doc. : IEEE 802. 11 -01/497 r 0 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) Submission 4 Bernard Aboba, Microsoft

July 2001 doc. : IEEE 802. 11 -01/497 r 0 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 Submission 5 Bernard Aboba, Microsoft

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

July 2001 doc. : IEEE 802. 11 -01/497 r 0 “Short Form” Exchange Client -------U, A -> Server ------ <-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) Submission 7 Bernard Aboba, Microsoft

July 2001 doc. : IEEE 802. 11 -01/497 r 0 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 Submission 8 Bernard Aboba, Microsoft

July 2001 doc. : IEEE 802. 11 -01/497 r 0 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 WEPv 1 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. 1 X 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 Submission – Example: PPP ECP 9 Bernard Aboba, Microsoft

July 2001 doc. : IEEE 802. 11 -01/497 r 0 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 (WEP 1) and new APs (WEP 2) • 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 Submission 10 Bernard Aboba, Microsoft

July 2001 doc. : IEEE 802. 11 -01/497 r 0 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 Submission 11 Bernard Aboba, Microsoft

July 2001 doc. : IEEE 802. 11 -01/497 r 0 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 “RC 4 -40_with_CRC 32” ciphersuite in TLS (WEP 1) – Need specification for deriving 802. 11 keys from master key Submission 12 Bernard Aboba, Microsoft

July 2001 doc. : IEEE 802. 11 -01/497 r 0 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 Submission 13 Bernard Aboba, Microsoft

July 2001 doc. : IEEE 802. 11 -01/497 r 0 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 Submission 14 Bernard Aboba, Microsoft

July 2001 doc. : IEEE 802. 11 -01/497 r 0 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 Submission 15 Bernard Aboba, Microsoft

July 2001 doc. : IEEE 802. 11 -01/497 r 0 Feedback? Submission 16 Bernard Aboba, Microsoft