Subject: [TLS] shared secrets from passwords

From: Mohamad Badra <[email-masked]>
Date: Tue, 29 Jan 2008 17:11:23 +0100

Dear all,

Is there any RFC with recommendations for deriving shared secrets from 
passwords?

Thanks!
-- 
Mohamad Badra
CNRS - LIMOS Laboratory

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 30 Jan 2008 09:46:32 +1300

>Is there any RFC with recommendations for deriving shared secrets from

Not yet but I'm working on it for use with TLS-PSK, TLS-SRP, and others.

Peter.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 29 Jan 2008 14:35:49 -0800

At Wed, 30 Jan 2008 09:46:32 +1300,
> Not yet but I'm working on it for use with TLS-PSK, TLS-SRP, and others.

Maybe I'm dense today, but why would you need to do that for SRP,
which is designed to use passwords directly.

-Ekr

---

From: Russ Housley <[email-masked]>
Date: Tue, 29 Jan 2008 16:59:53 -0500

RFC 2898
    PKCS #5: Password-Based Cryptography Specification Version 2.0.
      B. Kaliski. September 2000.

At 11:11 AM 1/29/2008, Mohamad Badra wrote:
>Dear all,
>
>Is there any RFC with recommendations for deriving shared secrets 
>from passwords?
>
>Thanks!
>--
>Mohamad Badra
>CNRS - LIMOS Laboratory
>
>
>

---

From: Nelson B Bolyard <[email-masked]>
Date: Tue, 29 Jan 2008 20:16:42 -0800

>> Is there any RFC with recommendations for deriving shared secrets from

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

One fact about shared secrets: If the users are humanly capable of giving
them away, they will do so.  The simplest way to get a user's password is
typically to simply ask him for it.  If the user's shared authentication
secret can be derived from a password, then the attack will be to get the
user to divulge his password to the wrong party.
(Here's a cute example: http://wdl.lug.ro/funny/pictures/credit.jpg )

A system in which the user cannot easily give away his shared authentication
secret, even if he wants to, because he does not have it in his head and he
cannot get his system to show it to him, will be much more secure than one
in which the shared secret itself can be given away from memory or by reading.

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.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 30 Jan 2008 04:36:23 +0000

On Tue, 29 Jan 2008 20:16:42 -0800
Nelson B Bolyard <[email-masked]> wrote:

> My recommendation would be to strongly advise TLS implementors
> against any form of deriving shared authentication or encryption
> secrets from passwords.
> 
> One fact about shared secrets: If the users are humanly capable of
> giving them away, they will do so.  The simplest way to get a user's
> password is typically to simply ask him for it.  If the user's shared
> authentication secret can be derived from a password, then the attack
> will be to get the user to divulge his password to the wrong party.
> A system in which the user cannot easily give away his shared
> authentication secret, even if he wants to, because he does not have
> it in his head and he cannot get his system to show it to him, will
> be much more secure than one in which the shared secret itself can be
> given away from memory or by reading.
> 
> 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.
> 
There are lots of ways to implement bad security; passwords are only
one.  See, for example, http://www.xkcd.com/364/.  Alternatively,
consider http://blog.wired.com/27bstroke6/2008/01/leaked-document.html
-- and remember Gene Spafford's famous line about using crypto on the
Internet with its very weak endpoints.

Past that, there's the human element.  Suppose people do use
client-side certificates.  The bad guys -- those who don't just hack
the client machine -- will implement MITM attacks, since people will
*not* validate the server's certificate properly
(http://research.microsoft.com/copyright/accept.asp?path=http://www.research.microsoft.com/sn/dss/papers/pip.pdf&pub=15).  

Perhaps more to the point, where will the secret key be stored?  I
regularly use five different (believed-to-be-secure) machines.  Which
should have the key?  If one of them is my work machine, does
management have access to the key?

I'd like passwords go go away, too.  I doubt that they will any time
soon.  Preshared secrets for TLS keys are much better than plaintext
passwords transmitted over TLS-protected connections -- and that's what
the issue here is.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---

From: Yoav Nir <[email-masked]>
Date: Wed, 30 Jan 2008 10:09:57 +0200

Several RFC's have such a recommendation. RFC 4306 (IKEv2) has this  
construction to make a shared secret out of a password (section 2.15):

   prf(Shared Secret,"Key Pad for IKEv2")

The idea is that this shared secret has the properties that (a) it  
can't be used for anything other than IKEv2 so storing it is  
presumably OK (why?), and (b) it looks random. The RFC goes on to  
state this:

                                As noted above, deriving the shared
   secret from a password is not secure.  This construction is used
   because it is anticipated that people will do it anyway.

On Jan 29, 2008, at 6:11 PM, Mohamad Badra wrote:

> Scanned by Check Point Total Security Gateway.
>

---

From: Mohamad Badra <[email-masked]>
Date: Wed, 30 Jan 2008 13:56:10 +0100

Dear Yoav, Nelson and all,

 > against any form of deriving shared authentication or encryption

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

 > 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