[TLS] PSK has no security? ... was Re: I-D Action: draft-ietf-tls-pwd-04.txt

[Hannes Tschofenig <[e-mail]>]

I just noticed this one sentence "PSK has no security?" and it caught my
attention.

I believe you guys are trying to misinterpet the TLS-PSK document. Maybe
you are thinking about use cases we did not envision.

TLS-PSK is not a password-based authentication mechanism for TLS!
It was never meant to be one either.

On the Web, already at that time, everyone was using passwords in forms
rather than at a lower layer in the stack. This has not changed.
(So, there was no need to standardize a password-based mechanism in TLS
at that time.)

There are very few people who are interested in using passwords in TLS
and I don't think this is the direction where deployments are going.
(Have a look at FIDO for a more promising approach of improving
authentication on the Web.)
[FWIW, I believe the strong password-based authentication and key
exchange in TLS will not lead to an improvement in password practices on
the Web.]

As a co-author of the TLS-PSK RFC I can tell you that the work was
motivated by activities in the 3GPP. The 3GPP had developed a Kerberos
alike key management protocol. The fresh and unique session key (not
password) would then be used as input to the TLS-PSK protocol.

Now, it turns out that that 3GPP work didn't really go anywhere. What we
hadn't anticipated at that time was the development on Internet of
Things where it makes sense to provision symmetric keys (not passwords)
on sensors for use with the TLS-PSK protocol. This is useful because of
(a) the excellent performance of symmetric key cryptography and (b) the
small code size.

Ciao
Hannes

On 04/02/2014 12:30 AM, Dan Harkins wrote:
> 
> On Tue, April 1, 2014 2:16 pm, Nico Williams wrote:
>> On Tue, Apr 01, 2014 at 01:59:09PM -0700, Dan Harkins wrote:
>>> On Tue, April 1, 2014 12:30 pm, Nico Williams wrote:
>>>> On Fri, Mar 28, 2014 at 8:40 PM, Watson Ladd <[e-mail]>
>>>> wrote:
>>>>> PSK has no security? That's ridiculous: if high-entropy keys are used
>>>>> it is fairly easy to see it is secure.
>>>>
>>>> TLS-PSK did not specify a PBKDF either, so it can't be used with
>>>> passwords, therefore we might as well assume high-quality keys for
>>>> TLS-PSK.  Therefore you're quite right.
>>>
>>>   There is nothing in the protocol that prevents it from being used with
>>> passwords. You're not only assuming something about the nature of the
>>> PSK, you're assuming something about the people that use the protocol
>>> and that is quite naive.
>>
>> PSK requires pre-sharing the secret key.  If such presharing involves a
>> password then the secret key must be derived from said password.  How?
>> Well, the two peers have to agree.  How?  Well, it's not specified!
> 
>   No, the secret key IS the password, it's not derived from the password.
> 
>> If there interoperable TLS-PSK w/ password implementations, then there's
>> a missing standard.  I have no knowledge of such implementations.
>>
>> Without any further input the only reasonable conclusion is that TLS-PSK
>> does not support passwords.  Evidence to the contrary would be welcomed.
> 
>   Try openssl. It has an artificial hex checker for PSK inputs but make
> your PSK be "bad" without the quotes. Works just fine.
> 
>   The presence of implementations is somewhat irrelevant since the point is
> that the _specification_ allows for a PSK to be anything, it just needs to be
> identical on both sides.
> 
>>>   Furthermore making assumptions about the nature of the PSK does not
>>> change the fact that TLS-PSK has a defect: the advantage an attacker
>>> gains is through computation and not interaction. And for the non-DHE
>>> ciphersuites, that defect can be exploited through passive attack!
>>
>> Only if they are password-derived keys, otherwise no.
> 
>   No, that is wrong. Just because something is a number, or is taken
> from a large space of numbers does not change the fact that the adversary
> gains advantage through computation. It either passively observes a
> single TLS-PSK exchange (if non-DHE) or it performs a single active attack
> on a TLS-PSK user (if DHE) and then goes offline and crunches numbers
> until it determines the PSK.
> 
>   Using a "high quality key" just makes that number crunching take more
> time, it does not change the fundamental nature of the number crunching.
> And therein lies the flaw of the TLS-PSK ciphersuites.
> 
>   A protocol that requires the adversary to gain advantage through
> interaction and not through computation is vastly superior because
> excessive unsuccessful interaction can be detected.
> 
>>>> Even if the server must store a password-equivalent I'd still want a
>>>> decent PBKDF to be used for any protocol that derives keying material
>>>> from passwords!
>>>
>>>   Why? Deterministically hashing a secret 1000 times or 4000 times
>>> does not increase the entropy in the secret. A PBKDF is just supposed
>>> to increase the work factor of the attacker, it does nothing to the
>>> resulting keying material.
>>
>> Because verifier databases get compromised regularly.  Just point your
>> browser to your favorite news site and wait a few weeks, you'll see.
> 
>   But that has nothing to do with how a protocol derives keying material.
> 
>>>   Wi-Fi specifies a PBKDF when using a PSK and the exchange is
>>> essentially the same as the non-DHE TLS-PSK ciphersuites. That
>>> protocol is horribly broken and tools exist on the Internet to attack
>>> it. And guess what? People still use it with weak, low-entropy PSKs
>>> in spite of assumptions to the contrary.
>>
>> My concern is not eavesdroppers in this case.  See above.
> 
>   So what? It's an example of a protocol that uses a PBKDF being
> trivially and successfully attacked. The result of the attack is that
> the PSK. If the attacker chooses to use that knowledge to further
> eavesdrop it's up to him. Regardless of your concern, your belief in
> the power of a PBKDF seems a bit misplaced.
> 
>   Dan.
> 
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>