• MutualAuthentication

The idea is to create and standardize a Password based Zero-Knowledge, Mutual Authentication extension for SSL/TLS.

• Any implementation of this Extension in TLS MUST make sure that the TLS-SNI extension is implemented at the same time.

User Interface

Quoted from http://www.cs.auckland.ac.nz/~pgut001/pubs/man_usability.pdf :

Design Example: TLS Password-based Authentication
    A useful design exercise for visual cues involves the use of TLS´ password-based
    authentication (TLS-PSK). What´s required to effectively apply TLS-PSK are three things:
     
                1.   A means of indicating that TLS-PSK security is in effect, namely that both
                     client and server have performed a mutual authentication process.
                2.   An unmistakeable means of obtaining the user password that can´t be
                     spoofed by something like a password-entry dialog on a normal web page.
                3.   An unmistakeable link between the TLS-PSK authentication process and the
                     web page that it´s protecting.

           The obvious way to meet the first requirement is to set the URL bar to a distinctive
           colour when TLS-PSK is in effect. Users have become accustomed to this as a
           security indicator because some browsers already do this for standard SSL/TLS,
           setting the URL bar to light yellow, and browser vendors have indicated that they
           plan to extend this usage in future browser versions. For TLS-PSK well’ use light
           blue to differentiate it from the standard SSL/TLS security, producing a non-zero
           Hamming weight for the security indicators. Using an in-band indicator (for example
           something present on the web page) is a bad idea, both because as the previous
           section showed it´s quite easily spoofable by an attacker, and because usability tests
           on such an interface have shown that users just consider it part of the web page and
           don´t pay any attention to it [32].
           To meet the second and third requirements, instead of popping up a normal password-
           entry dialog box in front of the web page (which could be coming from hostile code
           on the web page itself), we make the blue URL bar zoom out into a blue-tinted or
           blue-bordered password-entry dialog, and then zoom back into the blue URL bar once
           the TLS-PSK authentication is complete.

  This process creates a clear indication even for novice users of a connection between
  the URL bar indicating that TLS-PSK security is in effect, the TLS-PSK password-
  entry system, and the final result of the authentication. The user learning task has
  been simplified to a single bit, "If you don´t see the blue indicators and graphical 
  effects, run away". This is no more complex than the "If you don´t see the yellow
  URL bar, run away" exercise that users have already demonstrated a reasonable grasp
  of.
  
  Finally, this authentication mechanism is an integral part of the critical action
  sequence. If it´s implemented as described above then you can´t do TLS-PSK 
  authentication without being exposed to the security interface. Unlike the certificate
  check in standard SSL/TLS security, you can´t choose to avoid it.

TLS-PSK

http://www.ietf.org/rfc/rfc4279.txt For this application, the Diffie-Helman variant of TLS-PSK MUST be used. The problem I see with TLS-PSK, is that it isn´t a zero-knowledge proof, and is therefore attackable with dictionary based Active Man-in-the-Middle attacks.

TLS-SRP

http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-12.txt

Waidner

http://citeseer.ist.psu.edu/buhler00secure.html

Gühring

First a normal Diffie-Hellman Key Agreement is done.

• A creates a nonce "n". n:=nonce();
• A encrypts the nonce with the password. s:=Enc(n,pw);
• A sends the encrypted nonce s to B. Send(s);
• B receives s. s:=Receive();
• B and decrypts the nonce with the password. n:=Dec(s,pw);
• B hashes the nonce, the password and the agreed Diffie-Hellman Key: h:=Hash(n|pw|dhkey);
• B sends the Hash h to A. Send(h);
• A calculates the Hash too. ha:=Hash(n|pw|dhkey);
• A receives the hash and verifies it. if(ha == Receive()) OK();

The same procedure is done in the other direction with a nonce generated by B too. The calculations and messages can be parallelized and done at the same time as the Diffie-Helman agreement to speed up the handshake.

The price of this method is 1 Diffie-Hellman exchange, 2 nonces (can be /dev/urandom quality), 4 block encryptions (AES could be used here), 4 hash functions (SHA2/SHA1), and 2 more messages in each direction. I think that is efficient enough.

The attack is to create a random string, and send that to B. Be decrypts it with the real password, and produces the hash, and sends the hash back. Now you can do a dictionary attack by decrypting the random number with the dictionary password, and hashing it together with the dictionary password and the key.