implement DH-EKE based secure password based authenticated key exchange



15 years ago
11 years ago


(Reporter: hauser, Unassigned)


Firefox Tracking Flags

(Not tracked)




15 years ago
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040207

Bug 122445 has endless discussions how to reduce the effect of the possiblity to
spoof a login screen. Whatever is discussed there appears to mainly fight the
symptoms and not the root cause.

Therefore, I suggest to amend Mozilla (or should this rather be posted to
firefox?) with a real solution of the problem as per:
"Secure Password-Based Cipher Suite for TLS", M. Steiner et al., TISSEC, 2001,
vol 4, #2, pp134-157, May, 2000
  abstract =	 {SSL is the de-facto standard today for securing
		  end-to-end transport on the Internet.	 While the
		  protocol itself seems rather secure, there are a
		  number of risks that lurk in its use, e.g., in web
		  banking.  However, the adoption of password-based
		  key-exchange protocols can overcome some of these
		  problems.  We propose the integration of such a
		  protocol (DH-EKE) in the TLS protocol, the
		  standardization of SSL by IETF. The resulting
		  protocol provides secure mutual authentication and
		  key establishment over an insecure channel.  It does
		  not have to resort to a PKI or keys and certificates
		  stored on the users computer. Additionally, its
		  integration in TLS is as minimal and non-intrusive
		  as possible. 
A good illustration is

Alternative approaches: Charlie Kaufman and Radia Perlman: "PDM - A New Strong
Password-Based Protocol", or Victor Boyko et al. "Provably Secure
Password-Authenticated Key Exchange Using Diffie-Hellman
( , or other discussions at

Reproducible: Always
Steps to Reproduce:

Actual Results:  

Expected Results:  

-> psm, I believe
Assignee: security-bugs → kaie
Component: Security: General → Client Library
Product: Browser → PSM
QA Contact: bmartin
Version: Trunk → 1.01
Version: 1.01 → unspecified

Comment 2

15 years ago
-> NSS
Component: Client Library → Libraries
Product: PSM → NSS


15 years ago
Assignee: kaie → wchang0222
QA Contact: bmartin → bishakhabanerjee


15 years ago
Ever confirmed: true
If this affects TLS/SSL, then it will surely also affect PSM.  There will be
UI issues for getting the user's password.

Rolf, two questions:

1. Is there any TLS/SSL server product against which a new client implementation
could be tested?

2. What about implementing this for http authentication.  
Is there an RFC or ID for that?  
Seems to me a lot more people would benefit from having EKE in that than in TLS.

Comment 4

15 years ago
Just checked with Steiner (he's now at IBM Watson): Unfortunately, there doesn't
appear to be further work on this in that company right now.
The Bell-Lab PAK (see ref below) appears to be another viable option and has an
open source implementation. There may, however, be intellectual property rights
issues from a standards perspective ...
SRP from Wu's might be another alternative. 
Best is probably to check with the authors whether they would be interested in
reactivating that - or try to motivate another institution with less corporate
constraints (e.g.
Victor Boyko and Philip MacKenzie and Sarvar Patel: Provably Secure
Password-Authenticated Key Exchange Using Diffie-Hellman
CryptEAr, Report 2000/044, Sept.,
Comment: PAK (proven with random oracles and DDH assumption).
         Bell Labs/Lucents also offers free-for-non-commercial software of
         PAK integrated in ftp / telnet based on the SRP implementation:

Comment 5

14 years ago
see Bug 268835 for an idea how to make this even more phisher-proof
QA Contact: bishakhabanerjee → jason.m.reid
Assignee: wtchang → nobody
QA Contact: jason.m.reid → libraries
Priority: -- → P4
You need to log in before you can comment on or make changes to this bug.