Re: [websec] HTTP authentication: the next generation

Yaron Sheffer <yaronf.ietf@gmail.com> writes:

> - I am not a cryptographer, so I am treading on extremely thin ice here.
>
> - SRP is certainly better than using PSK with passwords, which is
> *definitely* vulnerable to dictionary attacks.

One final addition here, the situation for PSK depends on the flavour
and whether you are talking about active or passive attackers.  The
statement is true for plain PSK, but less so for DHE_PSK and RSA_PSK.
Section 7.2 of 4279:

   For the PSK ciphersuites, an attacker can get the information
   required for an off-line attack by eavesdropping on a TLS handshake,
   or by getting a valid client to attempt connection with the attacker
   (by tricking the client to connect to the wrong address, or by
   intercepting a connection attempt to the correct address, for
   instance).

   For the DHE_PSK ciphersuites, an attacker can obtain the information
   by getting a valid client to attempt connection with the attacker.
   Passive eavesdropping alone is not sufficient.

   For the RSA_PSK ciphersuites, only the server (authenticated using
   RSA and certificates) can obtain sufficient information for an
   off-line attack.

/Simon

> - That said, I have done my little bit of due diligence (talked to the
> author of SRP and to several cryptographers who've played with some of
> these schemes). Personally, I would rather use a protocol that's been
> formally proven (PACE, AugPAKE, other descendants of EKE) or has had
> real solid cryptographic review (the original EKE). Again, I would be
> happy to be proven wrong on this.
>
> - Even if we start with a mathematically perfect protocol, we are
> bound to make design and engineering mistakes. And Marsh and his like
> will happily poke holes into these implementations :-) But I'd like to
> avoid compounding the risk with cryptographically unsound protocols.
>
> Thanks,
> 	Yaron
>
> On 01/07/2011 04:29 PM, Simon Josefsson wrote:
>> The initial paper contains a security analysis with some reduction-style
>> arguments:
>>
>> http://srp.stanford.edu/ndss.html#SECTION00040000000000000000
>>
>> As with any crypto document from that time, it will lack in how the
>> assumptions are stated and the reductions are made.  That considered, is
>> there something in particular that you think is missing in there?
>>
>> We can fix the problem with lack of review by implementing and deploying
>> the protocol, then certainly researchers are bound to focus on it. ;-)
>>
>> /Simon
>>
>> Yaron Sheffer<yaronf.ietf@gmail.com>  writes:
>>
>>> Another issue is that SRP (as opposed to other protocols in this
>>> space) is not provably secure, and in fact has had relatively little
>>> cryptographic review, AFAIK. I would be glad to be proven wrong on the
>>> second point.
>>>
>>> Thanks,
>>> 	Yaron
>>>
>>> On 01/07/2011 01:57 PM, Simon Josefsson wrote:
>>>> One way to mitigate the dictionary attack problem is to do PBKDF#2
>>>> processing of the password before it hits TLS-PSK.
>>>>
>>>> However I agree that TLS-SRP have superior properties, and it is widely
>>>> implemented.  There is no practical reason to prefer TLS-PSK over
>>>> TLS-PSK for password-based TLS authentication.  One issue is that RFC
>>>> 5054 is Informational rather than Standards Track (same issue as for
>>>> TLS-OpenPGP), which is due to political reasons.
>>>>
>>>> /Simon
>>>>
>>>> Yaron Sheffer<yaronf.ietf@gmail.com>   writes:
>>>>
>>>>> [Culling down the mailing lists]
>>>>>
>>>>> Hi Ben,
>>>>>
>>>>> No, RFC 4279 should not be used with (a hash of) human-memorable
>>>>> passwords, because it would be vulnerable to dictionary attacks. See
>>>>> http://tools.ietf.org/html/rfc4279#section-7.2. SRP, EKE and similar
>>>>> schemes should be used instead.
>>>>>
>>>>> Thanks,
>>>>> 	Yaron
>>>>>
>>>>> On 01/06/2011 05:31 PM, Ben Laurie wrote:
>>>>> [...]
>>>>>
>>>>>>
>>>>>>
>>>>>> Two comments (one really being a response to Roy):
>>>>>>
>>>>>> 1. The IETF has fixed the problem, but no-one is using the fix - perhaps
>>>>>> because it is not clear that it is the fix. I speak of RFC 4279, TLS
>>>>>> pre-shared keys. These could be derived from a hash of the password and
>>>>>> the site name, for example, and thus provide secure mutual
>>>>>> authentication despite password reuse.
>>>>>>
>>>>> [...]
> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten

Received on Friday, 7 January 2011 16:56:26 UTC