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

Hi Yaron,

SIP is deployed over UDP, TCP, and TLS.
Both types of deployments, human-memorable & machine-generated passwords,
are widely used.

Regards,
 Rifaat

On Mon, Jul 22, 2013 at 5:28 PM, Yaron Sheffer <yaronf.ietf@gmail.com>wrote:

> 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<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<https://www.ietf.org/mailman/listinfo/http-auth>
>>>
>>