Open Bug 233836 Opened 21 years ago Updated 2 years ago

implement DH-EKE based secure password based authenticated key exchange

Categories

(NSS :: Libraries, enhancement, P4)

x86
Windows XP
enhancement

Tracking

(Not tracked)

People

(Reporter: hauser, Unassigned)

Details

User-Agent:       
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 http://www.semper.org/sirene/publ/SBEW_01EKETLS.pdf

---------
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
(http://eprint.iacr.org/2000/044.pdf) , or other discussions at
http://grouper.ieee.org/groups/1363

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

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
-> NSS
Component: Client Library → Libraries
Product: PSM → NSS
Assignee: kaie → wchang0222
QA Contact: bmartin → bishakhabanerjee
Status: UNCONFIRMED → NEW
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.
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. http://zisc.ethz.ch/).
----
Victor Boyko and Philip MacKenzie and Sarvar Patel: Provably Secure
Password-Authenticated Key Exchange Using Diffie-Hellman
CryptEAr, Report 2000/044, Sept., http://eprint.iacr.org/2000/044.ps.gz
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:
	 http://cm.bell-labs.com/who/philmac/pak.html
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
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.