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

From: Yaron Sheffer <[email-masked]>
Date: Sat, 20 Jul 2013 19:33:31 +0300

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

---

From: "Henry B. Hotz" <[email-masked]>
Date: Sun, 21 Jul 2013 16:33:11 -0700

I won't claim to know the future, or even everything about the present, but I agree with the goal of getting a "digest-v2" with the properties you suggest.  If this group can reach consensus on such a thing fast enough to leverage some of the resources that might otherwise go to less ambitious updates to digest, I'm all for it.

Is that a realistic possibility?

On Jul 20, 2013, at 9:33 AM, Yaron Sheffer <[email-masked]> wrote:

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

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 22 Jul 2013 01:14:44 +0100

Hiya,

> Sorry for questioning the group's charter, but this keeps bugging me:

I'd rather we do stuff as promised personally and not re-open
the charter. In saying that, I am assuming we finish what we
promised promptly (i.e. within months, not years).

> (for Digest) crypto agility. 

Fair point about vendors and their customers. OTOH, RFC 1149 has
also reportedly been requested of vendors, so customer RFQ silliness
isn't really a good metric for what an IETF WG ought do.

> Almost nobody will implement the other drafts.

That's a nicely confident prediction. Care to bet a beer? (If so,
quantify it fairly somehow and I'll take that bet.)

I hope you're wrong, at least wrt HOBA, but in any case, we ought
not base any decisions on you prediction above, or any equivalent
prediction.

> Seems to me this would be a much better use of our time, as well as

Not to me. You can already and should already run over TLS, at which
point any advantage of ZKPP gets lost in the noise since phishing and
password verifier DB leakage are entirely unaffected by the elegant
ZKPP bit fiddling. (That is a shame, since the crypto really is quite
elegant, but its nonetheless true.)

So I'm still of the opinion that minimal modernising of the existing
schemes plus some experiments is right here and we should not
pointlessly anoint any of the experiments with standards-track
status until after we've seen that they are useful in reality.

Having said that, if we decided to abandon work on Digest I'd not
object.

S.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 22 Jul 2013 09:16:56 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Yaron Sheffer
Sent: Saturday, July 20, 2013 7:34 PM
To: HTTP Auth WG
Subject: [http-auth] Why update Digest Auth?

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.

Thanks,
     Yaron

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 22 Jul 2013 13:51:07 +0300

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

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 22 Jul 2013 07:49:24 -0700

> I'm not totally opposed, but if we replace Digest with some ZKPP, it's not Digest any more. 

+1

> Do you think that enterprises would require "Digest" rather than "MutualAuth" or "SCRAM" just because it's called "Digest"?

As Rifaat points out, some *protocols* require Digest. Some will continue to do so even after there is a standards-track "better than Digest while still using dictionary-guessable passwords" mechanism, some might change to the new mechanism.

> 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…

If the WG is going to come to agreement on how to do i18n for usernames and passwords, it makes sense to wind that into today's Digest instead of forcing protocols that use Digest to either be stuck with bad i18n or have to change crypto models.

--Paul Hoffman

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 22 Jul 2013 23:44:30 +0300

On 2013-07-22 03:14, Stephen Farrell wrote:
[Speculation and counter-speculation removed. As a policy, I never bet a 
beer with an Irishman :-) ]
> elegant, but its nonetheless true.)

Everybody running on TLS today uses Basic, and I'd be surprised if we 
started seeing Digest on TLS.

OTOH on insecure transport, ZKPP has a strong advantage, despite the 
database stealing vulnerability. IMHO assuming that non-TLS use will 
simply go away is way too optimistic.

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 22 Jul 2013 23:51:44 +0300

Hi Yoav,

I agree if it's a ZKPP, it's not Digest any more. I just say, it's a 
better use of everybody's time. And it's not about the name, it's about 
which one we put on the standards track.

Re: Mutual Auth, our charter says it is going to be Experimental. So no 
matter if it's published early, it will have a much lower chance of 
being implemented.

By the way, Mutual Auth appears to be serious on I18N, as it should be.

Thanks,
	Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 23 Jul 2013 00:28:11 +0300

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

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 23 Jul 2013 02:44:02 -0400

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 <[email-masked]>wrote:

>> 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
>>
>>> 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
>>>
>>> From: [email-masked] [mailto:http-auth-bounces@**ietf.org<[email-masked]>]
>>> On Behalf Of Yaron Sheffer
>>> 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).
>>>
>>> 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.
>>>
>>> ______________________________**_________________
>>> http-auth mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/**listinfo/http-auth<https://www.ietf.org/mailman/listinfo/http-auth>
>>>
>>