Subject: Re: [Ietf-http-auth] Updating RFC 2617 (HTTP Digest) to use UTF-8

From: Ingo Struck <[email-masked]>
Date: Mon, 16 Oct 2006 22:54:02 +0000

Robert, Larry,

> How about creating a separate document which "updates"
> RFC 2617, describes the feature completely, and then
> pushing it out as "proposed standard" quickly?
>
> Should take much less time than the RFC 2617 update.
Sounds like a good idea.

> No, it's a feature by feature test. Basic works for some people some
> of the time, and MD5-sess doesn't. The cause is irrelevant. It could
> be that the spec is too difficult to implement, the spec is not worth
> implementing, the specified protocol doesn't work at all, or that
> browser engineers are dumb. It doesn't really matter--the document is
> really old by now, and the workable parts are clear.
I completely agree with that last statement --
the workable parts are clear and the spec (especially as a
draft document) is quite old. From a practical point of
view you are right with the feature-by-feature check; the
MD5-sess stuff does not work right now. Still it could,
however, circumvent some problems with basic and "simple" digest
auth (e.g. the "eternally-logged-in-problem" moz bug 355319)
if properly implemented.

But maybe it's really time to drop the non-used (or unusable)
parts to have a slight chance to advance the standardisation
state of that rfc and to grind out coherent, interoperable 
implementations within the next, say five to seven, years.

It seems that people agree that the rfc is at least hard
to read -- the reality check with existing implementations
shows that it is hard enough to read to prevent a large number
of implementations that share the same interpretation of the spec.

My proposal would be to create an "updated" document that
at least
- determines the parts to be incorporated into a digest
  (including their encoding and order - only ONE definite
  order, only ONE definite encoding)
- leaves open the hash function used, requiring "at least"
  the implementation of the MD5 hash function (although 
  "outdated" too from a cryptology point of view, but halfway
  proved to be interoperable)
- makes the hash functions that may be used
  subject to an IETF registry (like mime-types) with an
  initial registry of e.g. md5, sha1 and blowfish (note,
  these are to be read as an *example*)
- moves out the "sessionized" version of the scheme to a
  different document
- renders "basic" obsolete as a potential risk (because it means
  clear text passwords, a fact still not well understood by 
  implementors; I still find scores of discussions referring to
  "base64-encryption" which is plain wrong)

This would basically be a cut-down and tightened form of
rfc2617, without the introduction of any new features
that harden the authentication scheme.

To widely establish a better authentication scheme, like
the one Robert proposed at 
http://www.franklinmint.fm/blog/archives/000843.html
(especially incorporating the headers into the digest
is an essential improvement) I would resume with the completely
new "line" of documents started by Robert's (lately expired)
http://www.ietf.org/internet-drafts/draft-sayre-http-hmac-digest-01.txt

I am not sure where best to publish a "cut-down-update" of
rfc 2617 informally for public review... Any recommendations?

Kind regards

Ingo Struck

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 16 Oct 2006 15:42:49 -0700

An Internet-Draft submitted to the IETF Internet-Drafts repository is  
a great way to publish RFC updates for public review. Anybody can  
publish any format-conforming document for a temporary lifetime as an  
Internet-Draft.   I strongly support efforts to update these specs so  
let me know how I can help as AD or if there are any questions I can  
answer.

thanks,
Lisa Dusseault

---

From: "Robert Sayre" <[email-masked]>
Date: Mon, 16 Oct 2006 19:37:13 -0400

On 10/16/06, Lisa Dusseault <[email-masked]> wrote:
>  I strongly support efforts to update these specs so

Hi Lisa,

How do efforts to update these specs relate to the normative folklore
regarding mandatory to implement security technologies?

-- 

Robert Sayre

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 17 Oct 2006 10:36:37 -0700

I think the big question is whether there are other outstanding  
problems with 2617 that can be changed without hurting  
interoperability. If there aren't, it may be best to leave it alone.

That's because whether or not 2617 is revised, 2616 needs to clarify  
when encoding of headers is required. Namely, the spec generically  
says that headers can use RFC2047 encoding, but it doesn't say  
whether this is done before or after the header must conform to the  
BNF (which in many cases doesn't allow the necessary flexibility).

If it's before, then implementations must RFC2047-decode every  
incoming header, which I would posit no one currently does (and  
discussion seems to back that up).

If it's the latter, then header specifications (or users of them,  
e.g., authentication schemes) need to explicitly invoke RFC2047  
encoding to have it used.

Since it isn't interoperable to retroactively change requirements,  
the first approach isn't really feasible. Which means that if this is  
clarified in the latter way in 2616, it will have the effect of  
disallowing a number of characters in credentials.

The question to ask at this point is whether we can do any better,  
inside the confines of RFC2617 interoperability. At some point, it  
gets more attractive to just mint a new authentication scheme, rather  
than live within the limits of what's there.

Thoughts?

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

---

From: "Robert Sayre" <[email-masked]>
Date: Tue, 17 Oct 2006 13:49:38 -0400

On 10/17/06, Mark Nottingham <[email-masked]> wrote:
>
> I think the big question is whether...
>
> when encoding of headers is required.

The /first/ question is whether the IETF is a suitable venue. I am not

-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 17 Oct 2006 19:54:20 +0200

>BNF (which in many cases doesn't allow the necessary flexibility).

I don't really see this particular problem. RFC 2047 encoded applies
only to TEXT which, for the features defined in RFC 2616, is only in
quoted strings and the reason phrase in responses.

>discussion seems to back that up).

I don't think this is a valid interpretation.

>encoding to have it used.

I don't think so, RFC 2617 for example refers to quoted-string and
RFC 2616 specifies that other encodings than ISO-8859-1 may be used
there only when using RFC 2047 encoding.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 17 Oct 2006 11:16:43 -0700

> quoted strings and the reason phrase in responses.

...and comments, and warning text. Quoted strings show up in a *lot*  
of places (e.g., transfer codings, ETags, accept-, expect-, pragma  
and cache-control extensions).

But, point taken; I missed that.

If TEXT is well-defined as allowing 2047 encoding, and 2617 refers to  
it (albeit indirectly), then in most cases this is just an  
implementation problem, I think. The one exception that I can see is:

       passwd   = < user's password >

in Digest.

*sigh*

---

From: Julian Reschke <[email-masked]>
Date: Tue, 17 Oct 2006 20:56:02 +0200

Mark Nottingham schrieb:
> ...
> If TEXT is well-defined as allowing 2047 encoding, and 2617 refers to it 
> (albeit indirectly), then in most cases this is just an implementation 
> problem, I think. The one exception that I can see is:
> 
> ...

Hm. Maybe I'm a bit slow, but where's the problem here? Implementations 
not allowing RFC2047 encoding here, or something with the spec itself?

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 17 Oct 2006 13:29:01 -0700

With the spec - passwd isn't defined as being TEXT, and therefore  
2047 encoding (or indeed any charset) isn't specified for it. At  
least, that's how I read it.

On 2006/10/17, at 11:56 AM, Julian Reschke wrote:

>
> Mark Nottingham schrieb:
>> ...
>> If TEXT is well-defined as allowing 2047 encoding, and 2617 refers  
>> to it (albeit indirectly), then in most cases this is just an  
> Hm. Maybe I'm a bit slow, but where's the problem here?  
> Implementations not allowing RFC2047 encoding here, or something  
> with the spec itself?
>
> Best regards, Julian
>

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 17 Oct 2006 13:46:02 -0700

I would expect that any new Proposed Standard RFC would have to take  
into account the heightened expectations around mandatory-to- 
implement security technologies.  Updates to previous RFCs would not  
necessarily be immune to that.  I believe it's very important to  
clarify what HTTP clients and servers do need to support to provide  
adequate security for modern applications -- HTTP is hardly immune to  
attacks, and authentication technology is one of the failing pieces  
here which allows those attacks.  See for example the discussion at  
the Web Authentication Enhancements BoF at the last IETF <http:// 
www3.ietf.org/proceedings/06jul/index.html>.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Tue, 17 Oct 2006 23:01:03 +0200

Mark Nottingham schrieb:
> 
> With the spec - passwd isn't defined as being TEXT, and therefore 2047 
> encoding (or indeed any charset) isn't specified for it. At least, 
> that's how I read it.

Ah. I was looking at "password" (as in Basic Auth), not "passwd".

---

From: Julian Reschke <[email-masked]>
Date: Tue, 17 Oct 2006 23:02:53 +0200

Lisa Dusseault schrieb:
> into account the heightened expectations around mandatory-to-implement 
> security technologies.  Updates to previous RFCs would not necessarily 
> be immune to that.  I believe it's very important to clarify what HTTP 
> clients and servers do need to support to provide adequate security for 
> modern applications -- HTTP is hardly immune to attacks, and 
> authentication technology is one of the failing pieces here which allows 
> those attacks.  See for example the discussion at the Web Authentication 
> Enhancements BoF at the last IETF 
> <http://www3.ietf.org/proceedings/06jul/index.html>.

Well, if the IESG expects a revision to RFC2616 to step into the area 
covered by RFC2617, then I must agree with Robert that it's probably not 
worth trying, and that less harm is done by sticking to whatever RFC2616 
is saying today.

Best regards, Julian

---

From: Stefan Eissing <[email-masked]>
Date: Tue, 17 Oct 2006 23:20:34 +0200

Hmm, I am not the greatest spec reader under the sun.

Looking at it from an implementor perspective, I fail to see how  
retroactively non-ascii chars can be *interoperably* fitted into the  
digest specification. If you see a way to do this, I am all for it.  
(It's just so annoying that 401 does not indicate which char of the  
password was wrong.)

What other options are there:

a) It could be clarified which characters in user names, passwords  
and realms can be used for it under which circumstances. An  
implementation having a non-ascii user name/password then at least  
knows which authentication scheme to avoid.

b) The behaviour of some wide-spread implementation could be made  
standard, forcing (or hoping to) the other implementation to follow  
its interpretation.

c) A new auth scheme is specificied which does all unicode chars most  
beautifully. Naming itself "digest-int" or such, so that  
implementations have something to rely on.

d) a mix of all the above. urgs. strike that.

Whatever the choice, it will be a Good Thing if some clarification of  
2616 regarding non-ascii chars in headers is done. Maybe it's already  
there, then some clear words for implementors would suffice. At least  
whoever is trying to fix 2617 has a better base to stand on.

Cheers,

Stefan

Am 17.10.2006 um 22:29 schrieb Mark Nottingham:

>>> If TEXT is well-defined as allowing 2047 encoding, and 2617  
>>> refers to it (albeit indirectly), then in most cases this is just  
>>> an implementation problem, I think. The one exception that I can  
>>> see is:

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 17 Oct 2006 15:27:07 -0700

Since there are so many ways to approach this, so many variations in  
what specs are revised and how they depend upon each other, I can't  
say whether I, or the IESG, expect a revision to RFC2616 to "step  
into" the area covered by RFC2617.  A BoF would be a great place to  
discuss what work needed to be done, how that work would be divided  
into drafts, how those drafts would depend on each other, and how  
security fits into the whole picture.  Then at least some of that  
would presumably make it into a charter, reviewed by the entire IETF,  
if a WG were approved.  Before and after a BoF, mailing list  
discussion here can cover the same questions usefully.  My opinions  
are by no means the only ones that matter.

Lisa

On Oct 17, 2006, at 2:02 PM, Julian Reschke wrote:

> Lisa Dusseault schrieb:
>> I would expect that any new Proposed Standard RFC would have to  
>> take into account the heightened expectations around mandatory-to- 
>> implement security technologies.  Updates to previous RFCs would  
>> not necessarily be immune to that.  I believe it's very important  
>> to clarify what HTTP clients and servers do need to support to  
>> provide adequate security for modern applications -- HTTP is  
>> hardly immune to attacks, and authentication technology is one of  
>> the failing pieces here which allows those attacks.  See for  
>> example the discussion at the Web Authentication Enhancements BoF  
>> at the last IETF <http://www3.ietf.org/proceedings/06jul/index.html>.
>
> Well, if the IESG expects a revision to RFC2616 to step into the  
> area covered by RFC2617, then I must agree with Robert that it's  
> probably not worth trying, and that less harm is done by sticking  
> to whatever RFC2616 is saying today.
>
> Best regards, Julian