Re: [http-auth] Why update Digest Auth?

Hi Rifaat,

responding only to the first of your objections:

I am really worried if Digest (presumably not over TLS) is the standard 
authentication method in SIP. A few questions:

- Do people normally use it with a human-memorable password? If they do, 
then the dictionary attack vulnerability is IMO much more serious than 
continuing to use MD5, and would remain serious after we upgrade Digest.

- On the other hand, if people use Digest with computer-generated 
authentication strings, then I18N is probably unnecessary.

- Looking at RFC 3665, it seems to me SIP Register can accommodate a two 
round-trip authentication method, just as well as HTTP can.

Thanks,
	Yaron

On 2013-07-22 13:51, Rifaat Shekh-Yusef wrote:
> I do not like the idea of canceling the Digest work for the following reasons:
>
> 1. Digest is used with SIP protocol, and I am not sure the widely used Digest mechanism in SIP networks will be replaced with any if the new proposals.
>
> 2. This was already discussed during the discussion on the charter, and it seems a bit late to reopen that right now.
>
> 3. I think that the adopters of the new mechanisms should be motivated by the merit of the new mechanisms, not by us not updating Digest.
>
> 4. Some of the adopters of Digest might be satisfied with the Digest as it fulfills their need, and might not be interested in a "better" solution for their network.
>
> To address the timeline point that Stephen has raised, I think that the agility work should be done fairly soon as I do not see any major challenges at this stage.
>
> Regards,
>   Rifaat
>
> Sent from my iPhone
>
> On 2013-07-22, at 12:16 PM, Yoav Nir <ynir@checkpoint.com> wrote:
>
>> I'm not totally opposed, but if we replace Digest with some ZKPP, it's not Digest any more.
>>
>> Two of our experimental drafts are "better digests" - MutualAuth and SCRAM. MutualAuth is mature, has implementations, and I don't see why it shouldn't be ready to progress almost as fast as Digest.
>>
>> Do you think that enterprises would require "Digest" rather than "MutualAuth" or "SCRAM" just because it's called "Digest"?
>>
>> Hopefully these new methods will also support international user names and passwords (because specifying a user authentication method is 2013 that does not support non-English names is even sillier than specifying one that relies on MD5 for security). Then it's up to the enterprises to decide what they want to require vendors to implement.
>>
>> Yoav
>>
>> -----Original Message-----
>> From: http-auth-bounces@ietf.org [mailto:http-auth-bounces@ietf.org] On Behalf Of Yaron Sheffer
>> Sent: Saturday, July 20, 2013 7:34 PM
>> To: HTTP Auth WG
>> Subject: [http-auth] Why update Digest Auth?
>>
>> Sorry for questioning the group's charter, but this keeps bugging me:
>>
>> I'm assuming this WG will publish two Standards Track RFCs, updating Basic and Digest Auth. And a pile of Experimental RFCs with all sorts of lovely state-of-the-art crypto.
>>
>> Enterprises will require vendors to implement the updated Basic and Digest, and in a few years' time we will end up with the worlds'
>> browsers and Web servers supporting Basic and Digest Auth with I18N and (for Digest) crypto agility. Almost nobody will implement the other drafts.
>>
>> In addition, the websec WG will hopefully work on "session continuation", which will extend the authentication to the whole session in a better way than cookies, and will provide channel binding. Assuming much of the Internet's traffic will remain unencrypted for years, this will be "good enough" security for this traffic. But, it won't work with Digest (because it is not "key generating", to borrow an EAP term).
>>
>> Now my question: we are telling implementors to upgrade Digest to gain I18N (and the algorithm agility, which in this case is mostly security theater, because when using short passwords we remain vulnerable to a dictionary attack anyway). Why not tell them *instead* to move to Digest-v2, which is dictionary attack resistant? Digest-v2 could be based on EKE or SRP, or maybe on draft-oiwa-http-mutualauth, and will support session continuation.
>>
>> Seems to me this would be a much better use of our time, as well as implementors' energy.
>>
>> Thanks,
>>      Yaron
>>
>> _______________________________________________
>> http-auth mailing list
>> http-auth@ietf.org
>> https://www.ietf.org/mailman/listinfo/http-auth