Subject: [http-auth] rev'd charter-like text

From: Stephen Farrell <[email-masked]>
Date: Mon, 12 Nov 2012 13:52:08 +0000

Hiya,

The attached is my attempt to incorporate last week's
meeting into the earlier charter text. Basically it
follows the approach Sam Hartman suggested at the BoF.

Note that since I'm a proponent of one of the schemes
here, I'll be recusing myself from IESG balloting on
this if/when that happens. So this is offered wearing
no hats etc.

Comments welcome. +1's would be good if they're
warranted.

Cheers,
S.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 12 Nov 2012 09:03:53 -0800

+1 with the caveat that I wasn't at the BOF and can't compare to the alternatives.

On Nov 12, 2012, at 5:52 AM, Stephen Farrell wrote:

> <ha-01.txt>_______________________________________________
> 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: Yoav Nir <[email-masked]>
Date: Mon, 12 Nov 2012 17:13:50 +0000

You can read the previous proposed charter here:
http://www.ietf.org/mail-archive/web/http-auth/current/msg01028.html

On Nov 12, 2012, at 7:03 PM, Henry B. Hotz wrote:

> _______________________________________________
> http-auth mailing list
> [email-masked]

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Mon, 12 Nov 2012 15:33:52 -0500

Hi Stephen,

	> In addition a "more modern" digest scheme with better algorithm agility and internationalisation support may be developed.

The following document is trying to address the algorithm limitation and defines an extension to the Digest mechanism by adding support for the SHA1 and SHA2 algorithms.
https://datatracker.ietf.org/doc/draft-ahrens-httpbis-digest-auth-update/?include_text=1

I think this draft should be added to the list in the charter.

Regards,
 Rifaat

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Stephen Farrell
> Sent: Monday, November 12, 2012 8:52 AM
> To: [email-masked]
> Subject: [http-auth] rev'd charter-like text
> 
> 
> Hiya,
> 
> The attached is my attempt to incorporate last week's meeting into the
> earlier charter text. Basically it follows the approach Sam Hartman
> suggested at the BoF.
> 
> Note that since I'm a proponent of one of the schemes here, I'll be
> recusing myself from IESG balloting on this if/when that happens. So
> this is offered wearing no hats etc.
> 
> Comments welcome. +1's would be good if they're warranted.
> 
> Cheers,
> S.
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 12 Nov 2012 21:08:51 +0000

Hiya,

> I think this draft should be added to the list in the charter.

I hadn't seen that and I'm not quite sure what changes to digest
are sought (I've cc'd Mark, who I believe knows better), though
I think there's some i18n stuff that's wanted too. But if you'd
be up for working it as an experimental draft, that'd fit with
the charter all right. So I at least would be up for adding it
on that basis. Then if it does get traction the resulting RFC
could be put on the standards track later. (Note, that can be
done without changing the RFC if there's no need for a change.)

As a personal comment, I don't see why having all those
hash options is useful. More choice is not better here. Seems
to me that just adding SHA256 and HMAC-SHA256 and saying that
clients MUST use that would be simpler and better.

S.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 12 Nov 2012 14:12:32 -0800

On Nov 12, 2012, at 1:08 PM, Stephen Farrell <[email-masked]> wrote:

> I think there's some i18n stuff that's wanted too.

I would note that this draft makes many incompatible changes to the current Digest mechanism. That is a terrible idea. If someone wants to take a stab at  a new "Digest2" mechanism that shares code with Digest, that might or might not be useful. Making incompatible changes with all the deployed code seems like the wrong way to go.

--Paul Hoffman

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 13 Nov 2012 09:33:02 +1100

My understanding is that it's just the hash algo and i18n, along with the editorial work to make it sit cleanly with httpbis p7. Julian, anything else?

--
Mark Nottingham   http://www.mnot.net/

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Mon, 12 Nov 2012 17:37:24 -0500

Can you please elaborate on what "incompatible changes" you see in the draft?

Our intention is to stay compatible with the existing mechanism, and we would be ready to address any incompatibility issues that we might have missed.

Regards,
 Rifaat 

Sent from my iPhone

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 12 Nov 2012 16:14:39 -0800

> Can you please elaborate on what "incompatible changes" you see in the draft?

The fact that you propose that people send multiple "WWW-Authenticate: Digest" headers. That looks to be prohibited by RFC 2617 (unless I'm badly misreading that spec).

> Our intention is to stay compatible with the existing mechanism, and we would be ready to address any incompatibility issues that we might have missed.

If you want to change your proposal to "pick one digest algorithm and use it", that would bring it into line with RFC 2617.

--Paul Hoffman

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Mon, 12 Nov 2012 19:45:06 -0500

Thanks for your feedback Paul.

Take a look at Section 1.2, second paragraph from the bottom; it starts with "NOTE: User agent...".

It clearly states that the client must be ready to handle multiple headers. Does that address your concern? Do you have any other concerns?

Regards,
 Rifaat

Sent from my iPhone

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Mon, 12 Nov 2012 19:52:40 -0500

Clarification:
Take a look at RFC2617, section 1.2, page 3, second paragraph from the bottom, that starts with "NOTE:..."

Sent from my iPhone

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 12 Nov 2012 17:21:42 -0800

On Nov 12, 2012, at 4:45 PM, "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]> wrote:

> It clearly states that the client must be ready to handle multiple headers.

Got it. I read it to mean different authentication mechanisms, but I can see now that it does not.

So, if you tackle the i18n problem as well, this seems OK for the putative WG to consider.

--Paul Hoffman

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 12 Nov 2012 17:22:06 -0800

Like the new one better.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 13 Nov 2012 11:41:09 +0100

> My understanding is that it's just the hash algo and i18n, along with the editorial work to make it sit cleanly with httpbis p7. Julian, anything else?

I haven't checked (and I have to admit that I don't understand Digest 
will enough to understand).

Best regards, Julian

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Tue, 13 Nov 2012 14:09:29 +0000

Hi Stephen,

>But if you'd be up for working it as an experimental draft, that'd fit with the charter all right.

What does this mean? The Digest mechanism is a well defined and standard mechanism and we are not changing that; what experiments is expected in this case?

> clients MUST use that would be simpler and better.

We still need to support MD5 for backward compatibility.
Why is supporting more than one algorithm is a problem? Different systems might be supporting different algorithms.

Regards,
 Rifaat

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Monday, November 12, 2012 4:09 PM
> To: Shekh-Yusef, Rifaat (Rifaat)
> Cc: [email-masked]; Mark Nottingham
> Subject: Re: [http-auth] rev'd charter-like text
> 
> 
> Hiya,
> 
> > 	> In addition a "more modern" digest scheme with better algorithm
> agility and internationalisation support may be developed.
> >
> > The following document is trying to address the algorithm limitation
> and defines an extension to the Digest mechanism by adding support for
> the SHA1 and SHA2 algorithms.

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Tue, 13 Nov 2012 14:11:23 +0000

> So, if you tackle the i18n problem as well, this seems OK for the

Ok, I will look into the i18n issue.

Regards,
 Rifaat

> From: Paul Hoffman [mailto:[email-masked]]
> Sent: Monday, November 12, 2012 8:22 PM
> Cc: Mark Nottingham; [email-masked]

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Tue, 13 Nov 2012 14:22:12 +0000

Mark,

All we have done is add support for secure algorithms, and utilize the ability of the server to send multiple WWW-Authenticate headers and the client to handle these properly, which is already defined in the standard.
We did not look into the i18n issue; will investigate this and provide a new version to address this concern.

Regards,
 Rifaat

> From: Julian Reschke [mailto:[email-masked]]
> Sent: Tuesday, November 13, 2012 5:41 AM
> To: Mark Nottingham
> Cc: Paul Hoffman; Stephen Farrell; Shekh-Yusef, Rifaat (Rifaat); http-
> [email-masked]
> > My understanding is that it's just the hash algo and i18n, along with
> the editorial work to make it sit cleanly with httpbis p7. Julian,
> anything else?
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Nov 2012 14:26:58 +0000

> What does this mean? The Digest mechanism is a well defined and standard mechanism and we are not changing that; what experiments is expected in this case?

Eh, you are proposing to change it.

The experimental thing is (mainly) related to the other
drafts. However, while I do know of a few uses of basic,
I don't know of any at all for digest, so I think one could
argue that its reasonable for any update to digest to be
experimental until we see if it gets used or not, which
would put that into the same category as the other new
proposed schemes.

And having a WG produce a bunch of experimental RFCs and
one standards-track RFC will make the charter text untidy:-)

More to the point, we can now "promote" experimental RFCs
onto the standards track without producing a new RFC, if
that's warranted, so the label for the RFC isn't that big
a deal to me at least - the bigger deal is that if we do
this WG, then I reckon we ought finish the RFCs, and then
only promote stuff to the standards track if it gets real
use, and the rest can be forgotten.

(As an aside, does anyone have any usage information for
http auth? E.g. approx. how many sites use basic/digest.
It'd be good to know more about that.)

> We still need to support MD5 for backward compatibility.

Maybe. Depends on whether you use the same or a new scheme
I guess.

> Why is supporting more than one algorithm is a problem? Different systems might be supporting different algorithms.

I didn't say >1 was bad. I said >>1 offers no benefit and
can be bad.

Each potential option decreases the liklihood of interop
unless you mandate that one side do all, which increases
the liklihood of untested code. IMO (and we maybe don't
have consensus on this) best is to have two options for
each "ciphersuite" - one preferred and one as a backup in
case the crypto-crap hits the crypto-fan.

S.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 13 Nov 2012 14:52:59 +0000

> It'd be good to know more about that.)

I've seen some numbers once, but I don't remember where. Pretty much none on the general web, but there's some internal servers that use it, because it's very simple to set up in things like Apache, whereas web forms require actual coding. 

> Maybe. Depends on whether you use the same or a new scheme

As far as I understand "digest", it hashes together the username, password, realm, visible nonce, and some other things, all of which are either sent in the clear or are predictable (except the password).

So the best attack against it is an offline dictionary attack, unless you can think up some truly random passwords.

If you could not guess the password, then I can see how MD5 is worse than SHA-1, SHA2-256 or SHA3-512. But if you can succeed with an offline dictionary attack, what's the advantage of using the better hashes?

Yoav

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 13 Nov 2012 07:59:19 -0800

> Eh, you are proposing to change it.

To use the official parlance, they are proposing to update RFC 2617, which is on Standards Track.

> would put that into the same category as the other new

I have seen Digest used on many web sites. It's not as common as Basic, but it more common than a lot of things on Standards Track.

> one standards-track RFC will make the charter text untidy:-)

Not nearly as untidy as moving a Standards Track RFC to Experimental via an update. I can picture a few process weenies on the IESG spewing on their keyboards.

> use, and the rest can be forgotten.

Doesn't matter. The issue is demoting RFC 2617. Or, you might update RFC 2617 and have the protocol be both Standards Track and Experimental at the same time, Schrödinger-like.

> It'd be good to know more about that.)

Lots of non-commercial sites use it for simple blocking of protected content. Works like a charm.

> Maybe. Depends on whether you use the same or a new scheme

They are saying "same". If it is "new", then there is no question.

> I didn't say >1 was bad. I said >>1 offers no benefit and

+1.

> case the crypto-crap hits the crypto-fan.

See below. 

> If you could not guess the password, then I can see how MD5 is worse than SHA-1, SHA2-256 or SHA3-512. But if you can succeed with an offline dictionary attack, what's the advantage of using the be…

Attacking the crypto would require a preimage attack, which we don't have for MD5. However, when used with passwords, the effort for the dictionary attack is approximately similar (testing SHA-256 is slower than testing MD5, but not so much as to be much of a protection). So all hash algorithms are equally good if the secret is random and large, and ~equally bad if the secret is a password. Given that, I would say SHA-256 should be a MUST, and MD5 is a SHOULD only for backward compatibility.

--Paul Hoffman

---

From: Yoav Nir <[email-masked]>
Date: Tue, 13 Nov 2012 16:10:28 +0000

> Attacking the crypto would require a preimage attack, which we don't have for MD5. However, when used with passwords, the effort for the dictionary attack is approximately similar (testing SHA-256…

Currently, only MD5 is defined. Adding (or moving to) SHA2-256 does not make any difference as far as security. So why bother at all?

Yoav

---

From: Michael Thomas <[email-masked]>
Date: Tue, 13 Nov 2012 08:14:55 -0800

> Currently, only MD5 is defined. Adding (or moving to) SHA2-256 does not make any difference as far as security. So why bother at all?

Correct me if I'm wrong, but doesn't Digest require an additional round
trip to get the nonce each http request? If that's correct, I think Digest
is pretty much a non-starter just because of performance considerations.
If Digest were resurrected in conjunction with some form of session
management, it would be better than Basic, but just adding SHA2 doesn't
address the basic issues of why nobody uses it.

Mike

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Nov 2012 16:22:34 +0000

> Not nearly as untidy as moving a Standards Track RFC to Experimental via an update. I can picture a few process weenies on the IESG spewing on their keyboards.

Well, its always good to elicit that response from that
subset of IETF folk:-)

But you make a fair point though. I buy the argument.

I guess if there's a reason to obsolete basic or digest
and that ought be done in the putative httpauth wg then
doing that as a standards-track thing to obsolete or update
2617 would appear to be the right thing.

But would obsoleting or updating 2617 be better here? I
see that httpbis p7 [1] just updates 2617 fwiw.

To be clear, I've no strong opinion, I'm with Yoav that
given the input's a password, its not earth-shatteringly
important, unless perhaps to fix an i18n thing or to
allow folk to entirely remove md5/sha-1 code from
their infrastructure to keep auditors happy.

S.

[1] http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-21

---

From: Julian Reschke <[email-masked]>
Date: Tue, 13 Nov 2012 19:12:29 +0100

> see that httpbis p7 [1] just updates 2617 fwiw.

That's because it only contains the framework, not Basic or Digest (as 
constrained by the HTTPbis charter).

Optimally, we would have two more documents describing Basic and Digest, 
so that we can fully obsolete 2617.

> ...

There's also a bunch of errata against Digest that should be checked: 
<http://www.rfc-editor.org/errata_search.php?rfc=2617>.

Best regards, Julian

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 Nov 2012 12:55:54 -0600

Hi, thanks for doing this.  I've just one question and some comments.

The question:

 - There is a lot of emphasis on the HTTP authentication framework,
   and while my proposal works with it (in that it uses HTTP headers
   like WWW-Authenticate) it's also specifically layered above HTTP
   (in that it uses the HTTP verbs and resource).  Would my proposal
   then be in scope or out of scope?

   (My proposal is listed explicitly, which would argue that it is in
   scope, if not by definition.)

The comments:

 - I really like this charter, particularly the emphasis on the WG
being short-lived.

 - I understand why "authentication of [...] components of web services"
   is out of scope: that would require being able to name such components
   in URIs, thus it'd necessitate a new URI scheme.  It might be easier
   and more general to declare new URI schemes out of scope.

   Of course, I do think that we should eventually address authentication
   of services, not just servers, but that is clearly beyond what this WG
   can manage.

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Tue, 13 Nov 2012 21:20:36 +0000

Hi Stephen

I like the proposed charter. I believe we have to deal with the arguments we've heard at the BoF, specifically the one about vanity protocols.

I think each document should state a use case. These use cases are likely to be different from one another, which is exactly what we want. Only two of them directly solve the problem of passwords in HTTP, and can be good replacements for Digest / Basic. The others solve different problems. I think the charter should say in addition to "will document…HTTP authentication schemes", that "all WG documents will detail their use case and what problem they solve."

Yoav

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 13 Nov 2012 15:24:06 -0700

On 11/13/12 2:20 PM, Yoav Nir wrote:
> Hi Stephen
> 
> I like the proposed charter. I believe we have to deal with the
> arguments we've heard at the BoF, specifically the one about vanity
> protocols.
> 
> I think each document should state a use case. These use cases are
> likely to be different from one another, which is exactly what we
> want. Only two of them directly solve the problem of passwords in
> HTTP, and can be good replacements for Digest / Basic. The others
> solve different problems. I think the charter should say in
> addition to "will document…HTTP authentication schemes", that "all
> WG documents will detail their use case and what problem they
> solve."

As I said at the mic in Atlanta, it would be nice to have a forcing
function that encourages people to work together so that we don't have
just a bunch of vanity protocols, but a more coherent technology based
on which different use cases can be solved (e.g., via some kind of
pluggable authentication framework like SASL).

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Michael Thomas <[email-masked]>
Date: Tue, 13 Nov 2012 14:28:36 -0800

> pluggable authentication framework like SASL).

God help us, no. Security protocols are utterly impenetrable to
the great unwashed masses of web developers. SASL, the
OAUTH kitchen sink, GSS and all the rest make things even worse.
Please make protocols that are small, understandable, and purpose
built. Do not try to come up with a grand unified theory.

Mike

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Nov 2012 22:33:56 +0000

> I think each document should state a use case. These use cases are likely to be different from one another, which is exactly what we want. Only two of them directly solve the problem of passwords i…

Yuk. IMO use-case text is usually a pain and a mostly useless
one in the IETF. However, I think I'm in a minority in
that belief so will add a sentence. And now that you mention
it I guess some text that would try guide a reader as to
which RFC to go play with/use ought be useful if we don't
go wild trying to make it all perfect.

I'd also have to say that equating forming an IETF WG
and getting your draft through all the associated hoops
is very very far from vanity publishing. Might be better
described as a form of masochistic publishing I'd say.
Maybe there are some people for whom those are the same,
I dunno.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Nov 2012 22:36:12 +0000

> pluggable authentication framework like SASL).

I strongly disagree. See my other mail wrt "vanity."

I see no value in producing a single framework to bind them
all when we fully expect almost all or all of the product of
this WG to wither away and die. We'll be lucky if one of the
proposals see widespread deployment and shouldn't pretend
otherwise. (Its still worth doing IMO.)

A SASL-based proposal may be a fine thing. Attempting to
force all designs to be the same is contrary to what I think
we want to get done here.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Nov 2012 22:43:04 +0000

>    then be in scope or out of scope?

*I* think so. Ultimately we'll wanna get this by the IESG so
more clarity is better if doable.

>    scope, if not by definition.)

Yup.

>    of services, not just servers, but that is clearly beyond what this WG

Right.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Nov 2012 22:43:44 +0000

On 11/13/2012 06:12 PM, Julian Reschke wrote:
>>> Not nearly as untidy as moving a Standards Track RFC to Experimental
>>> via an update. I can picture a few process weenies on the IESG
>>> spewing on their keyboards.
>>>
>>

Ta, I'll shoot out a new rev that tries to get this bit right
in a few.

S.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 14 Nov 2012 09:51:11 +1100

On 14/11/2012, at 1:26 AM, Stephen Farrell <[email-masked]> wrote:

> The experimental thing is (mainly) related to the other drafts. However, while I do know of a few uses of basic, I don't know of any at all for digest, so I think one could argue that its reasonable for any update to digest to be experimental until we see if it gets used or not, which would put that into the same category as the other new proposed schemes.

My understanding was that Experimental was for cases when there was a disagreement about how to do something, and the only way to resolve it was to perform an experiment, eventually either moving it to standards-track or historical.

OTOH, I'm fine if Experimental means "we don't know if this will get deployment, here's a shot in the dark" -- it's just that so many, many more RFCs would have to be classified as "Experimental" in that case.

Cheers,

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 Nov 2012 16:56:41 -0600

> pluggable authentication framework like SASL).

Yes!  (But you knew i would agree, as that is what I've been proposing.)
The trouble is that there didn't seem to be consensus, not even fit this,
when authentication was discussed on the http-bis list.  Perhaps it was my
fault for mentioning GSS and SASL/GS2 instead of just SASL. Think we can
have a do-over?

Nico
--

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 13 Nov 2012 16:02:03 -0700

On 11/13/12 3:36 PM, Stephen Farrell wrote:
>>> I like the proposed charter. I believe we have to deal with
>>> the arguments we've heard at the BoF, specifically the one
>>> about vanity protocols.
>> 
>>> I think each document should state a use case. These use cases
>>> are likely to be different from one another, which is exactly
>>> what we want. Only two of them directly solve the problem of
>>> passwords in HTTP, and can be good replacements for Digest /
>>> Basic. The others solve different problems. I think the charter
>>> should say in addition to "will document…HTTP authentication
>>> schemes", that "all WG documents will detail their use case and
>>> what problem they solve."
>> 
>> As I said at the mic in Atlanta, it would be nice to have a
>> forcing function that encourages people to work together so that
>> we don't have just a bunch of vanity protocols, but a more
>> coherent technology based on which different use cases can be
>> solved (e.g., via some kind of pluggable authentication framework
>> like SASL).
> 
> I see no value in producing a single framework to bind them all
> when we fully expect almost all or all of the product of this WG to
> wither away and die. We'll be lucky if one of the proposals see
> widespread deployment and shouldn't pretend otherwise. (Its still
> worth doing IMO.)
> 
> A SASL-based proposal may be a fine thing. Attempting to force all
> designs to be the same is contrary to what I think we want to get
> done here.

My concern is that Team X and Team Y might be working on things that
are very similar but currently have zero incentive to collaborate, and
in fact might have incentives not to work together at all (because
each team will get a shiny RFC).

Whether we need some kind of framework is a separate question.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Michael Thomas <[email-masked]>
Date: Tue, 13 Nov 2012 15:13:59 -0800

> Whether we need some kind of framework is a separate question.

I would think that it should be part of the working group's discretion
to force nuclear fusion as necessary.

Mike

---

From: Yoav Nir <[email-masked]>
Date: Tue, 13 Nov 2012 23:16:07 +0000

> go wild trying to make it all perfect.

Perfection is not needed, but usefulness is. As I've said at the mic in SAAG in Vancouver, this effort is not informed by any requirements. We haven't heard from anyone responsible for user experience in Facebook, Google, or even http://www.abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk.com (yes, that's a real webmail site that requires a login) or some site that sells dogfood over the Internet. None of them told us that they would like authentication at the HTTP layer, and neither did the people who write the frameworks that they use to build their sites.

We have no idea what an authentication scheme would have to do or be for them to use it. Failing this, we're designing these protocols on-spec. We can build it, but it's definitely not certain that they will come.

Building a beter digest for machines is a laudable goal, but not very interesting (at least to me)

Yoav

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Nov 2012 23:22:16 +0000

On 11/13/2012 11:02 PM, Peter Saint-Andre wrote:
> are very similar but currently have zero incentive to collaborate, 

Cat herding is such a good job for WG chairs:-)

> and

That's the vanity argument and is IMO bogus. The ISE exists and
we all know it but have chosen the harder road. I'm sure I don't
care about independent vs. experimental really, but I really
do think that the outcome in the latter case will be better.

I reckon the same is true for the proponents of the other
proposals. Given that the httpbis wg said "no interest"
there's no way the ISE route ought fail so anyone who
wanted any old RFC would have gone there already.

This is *nothing* to do with shiny or vanity or any other
purely pejorative term. I'd love if we were done with that
argument.

> Whether we need some kind of framework is a separate question.

Right. SASL is a credible thing here. But not all credible
things are SASL. FWIW, I'd fully intend to adopt stuff
from other drafts that looks good. But I still don't think
we ought try force that, but rather that we'll be better
off here getting done sooner and learning if any of the
proposals are not DOA. Good review from an interested and
active WG list guided by excellent chairs is what I'm after
here. (The usual in other words:-)

Cheers,
S.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 13 Nov 2012 15:24:36 -0800

> Perfection is not needed, but usefulness is. As I've said at the mic in SAAG in Vancouver, this effort is not informed by any requirements. We haven't heard from anyone responsible for user experie…
I'm here for whatever that's worth. My collaboration with Stephen and Paul
was borne out of running a real web site with real users and being really sick
of the terrible options I have to make my site and users more secure.

I'm on the fence as to whether an http or pure js mechanism for HOBA would
be adequate/better/terrific. If it could be made so that I don't have to
carry any form of a password database, I'd be a lot happier and the net in
general would thank me for not contributing to the multiplier effect of
password leakage with shared passwords.

Mike

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Nov 2012 23:30:11 +0000

On 11/13/2012 11:16 PM, Yoav Nir wrote:
> Perfection is not needed, but usefulness is. As I've said at the mic in SAAG in Vancouver, this effort is not informed by any requirements. 

Disagree. The effort is weak in that respect but not at
zero. HOBA for example poses a real requirement - do
something about password verifier database leakage. I'm
sure you agree that's real, right? (You may disagree
with the proposal but there's no doubt about the req.)

> We haven't heard from anyone responsible for user experience in
Facebook, Google, or even
http://www.abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk.com
(yes, that's a real webmail site that requires a login) or some site
that sells dogfood over the Internet. None of them told us that they
would like authentication at the HTTP layer, and neither did the people
who write the frameworks that they use to build their sites.

Yes but they do not do HTTP authentication, so that's
just fine. I *really* do hope we stop confusing those.

Henrik OTOH did present a real requirement and does
use HTTP auth. Someone else today mentioned some
IBM thing that I'm happy to believe is real. I also
use other sites that do HTTP auth and *I'd* like to
not use a password, and there are many usability
studies showing that users are pissed off with
aspects of passwords.

I'm sure the proponents of the other approaches
could argue similarly.

Again, yes, we're weak here, but not at zero.

> We have no idea what an authentication scheme would have to do or be for them to use it. Failing this, we're designing these protocols on-spec. We can build it, but it's definitely not certain that…

I think that last is fair. But, with 20 years of a
total lack of action, maybe its about time. So I
think its worth a shot given that we have folks who
are willing to invest their time.

> Building a beter digest for machines is a laudable goal, but not very interesting (at least to me)

Fully agree.

S.

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 Nov 2012 17:30:57 -0600

> we want to get done here.

FWIW, while I agree that a framework (e.g., SASL) brings useful
properties to the table, I also agree that we don't need a "forcing
function" -- we have one, as as the charter says, it's the market.  I
wish all proponents saw the value of using a pluggable framework, but
I don't care to force it by fiat here.  (My earlier "yes!" was w.r.t.
SASL, not a forcing function.)

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 Nov 2012 17:33:52 -0600

> with the proposal but there's no doubt about the req.)

If that's the only requirement then use an HSM.  Google does.  You
could make money selling such a thing instead of pushing for new
protocols.  It's not like you can entirely get rid of passwords -- you
can't.

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Nov 2012 23:36:19 +0000

> protocols.  It's not like you can entirely get rid of passwords -- you

Do we need to go there now? I can't wait to have that discussion
in earnest (again, didn't we do it on saag before?) but would
rather get a wg charter agreed right now really.

S.

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 Nov 2012 17:42:06 -0600

> rather get a wg charter agreed right now really.

Do we?  Probably not, but we're discussing what's in scope and what's
not, and we risk ratholing here and there.  It'd be easier if the
scope matters were crystal clear and if we had consensus for them.  So
is HOBA in scope or not?  I can't tell.  I think the requirement that
device authentication be out of scope should be clarified: device
authentication is in-scope but device state authentication (think NEA)
is not.

That said, I'm curious as to why HSMs are not sufficient for
addressing the password verifier file leakage problem.  I would think
that it would be.

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Nov 2012 23:43:11 +0000

> addressing the password verifier file leakage problem.  I would think

Right. Let's not rathole:-)

S.

---

From: Leif Johansson <[email-masked]>
Date: Wed, 14 Nov 2012 08:29:36 +0100

> protocols.  It's not like you can entirely get rid of passwords -- you
My requirements include portability too.

---

From: Leif Johansson <[email-masked]>
Date: Wed, 14 Nov 2012 08:31:40 +0100

> addressing the password verifier file leakage problem.  I would think
HSMs are risk-mitigation mechanisms but only if employed
just the right way.

Unfortunately clue about how to do things like password
stretching, etc is unevenly distributed.

        Cheers Leif

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 14 Nov 2012 08:21:12 -0500

On the updates to Digest issue, I can't see any point in bike shedding the
algorithm choice. The weakness in Digest is due to the fact that it was
designed to be unencumbered and when I originally proposed the scheme,
Diffie Hellman was encumbered.

Without public key cryptography there is a choice between having the
credentials be protected on the wire and having them protected in storage.
For obvious reasons (to me at least) protecting them on the wire was a
higher priority since servers have a better change of protecting themselves.

At this point we do not need to make that choice, it is possible to achieve
both.

A second problem with the lack of public key is that there was no way to
introduce additional entropy into the exchange. This is the main weakness
in DIGEST, if the user has a choice of a million passwords then an attacker
can find them by brute force whether the crypto is MD5, SHA1 or SHA1024.

So rather than just changing the algorithm as the Ahrends draft proposes,
we should add in a DH exchange inline to boost the amount of entropy in the
exchange and prevent the brute force attack.

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Sat, 17 Nov 2012 16:49:33 +0000

Hi Stephen,

> Eh, you are proposing to change it.

Not exactly.

Take a look at the following snippet from RFC2617, Section 3.2.1:

      algorithm = "algorithm" "=" ( "MD5" | "MD5-sess" | token )

By including the 'token', the standard clearly allows new algorithms to be defined.
What we did here is define new tokens for the new algorithms.

And, as I mentioned before, section 1.2 clearly allows multiple WWW-Authenticate headers to be included, and expect the UA to be ready to properly handle that.

> It'd be good to know more about that.)

Beside what others have already mentioned, the Digest mechanism is widely used in SIP networks.

We are getting requests from our customers to not use MD5 and instead use SHA2, and they state that US-CERT issued a note that MD5 "should be considered cryptographically broken and unsuitable for further use". Take a look at the following link:
http://www.kb.cert.org/vuls/id/836068

Regards,
 Rifaat

> Sent: Tuesday, November 13, 2012 9:27 AM
> > What does this mean? The Digest mechanism is a well defined and
> standard mechanism and we are not changing that; what experiments is
> expected in this case?
> 
> > Why is supporting more than one algorithm is a problem? Different
> systems might be supporting different algorithms.
> 
> >>>> From: [email-masked] [mailto:http-auth-
> [email-masked]]
> >> On