Re: [TLS] shared secrets from passwords

[Mohamad Badra <badra@xxxxxxxx>]

Dear Yoav, Nelson and all,

> My recommendation would be to strongly advise TLS implementors
> against any form of deriving shared authentication or encryption
> secrets from passwords.


I understand your recommendation, but I think the password is currently 
the predominant access method used in the Internet applications.


> I suggest you consider a "two factor" system, wherein (say) the user's
> password only serves to locally unlock/decrypt a local copy of a
> shared secret that was previously generated from a random source, and
> where that shared secret cannot be seen by the user.  The user can
> give away his password but doing so will not, by itself, give away
> his shared authentication secret.


Your suggestion is more suitable for the secret storage, my question is 
how can I combine between password databases and rfc4279?

IMO, the only way to make password and rfc4279 working together or to 
make a coherent link between password databases and that RFC is to rely 
on the password to compute the PSK and then to derive the premaster secret.

It is possible to rely on rfc2898 to do that but this document is 
designed for the case where a password is going to be used for 
encryption and/or for integrity. Since it uses salts, extending TLS is a 
must to send the username in the ClientHello.

It is also possible to derive PSKs from passwords in the same way as 
defined in rfc4306 as following (and keep the same statement):

PSK = Alg(Alg(password + username + "Key Pad for Application")
          + psk_identity_hint))

Alg could be SHA-1 or the hash algorithm in the ServerHello.cipher_suite.

Best regards,
Badra



_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls