[Standards-JIG] JEP-0070 revision needed wrt WWW-Authenticate

[Hal Rottenberg]

Here I go dipping my fingers into where they don't belong, but I
couldn't let this one slide.

I was talking with Machekku tonight about a possible implementation of
JEP-0070 [1] for use with a web service he is working on.  Upon
reading the JEP, I discovered a problem with the way it uses the Realm
parameter to the Basic and Digest tokens in the WWW-Authenticate HTTP
header.

According to RFC 2617page 2 [2] when discussing the HTTP header
WWW-Authenticate:

"[HTTP] uses an extensible, case-insensitive token to identify the
authentication scheme."

On page 5, after defning the auth token Basic which everyone is
familiar with, it goes on to give us explicit permission to define a
new token for our new authentication mechanism:

   "The HTTP protocol does not restrict applications to this simple
   challenge-response mechanism for access authentication. Additional
   mechanisms MAY be used, such as encryption at the transport level or
   via message encapsulation, and with additional header fields
   specifying authentication information. However, these additional
   mechanisms are not defined by this specification."

Now the problem is seen when you look at how Realm is defined on page 4 [3]:

   "The realm value...of the server being accessed, defines the
protection space.
   These realms allow the protected resources on a server to be
   partitioned into a set of protection spaces, each with its own
   authentication scheme and/or authorization database."

The overloading of the Realm parameter [4] means that no longer can
one specify different authentication schemes (aside from XMPP) at the
same URI.  In addition, and I think this is the more important part,
the UI of the user agent already knows what to do with the Basic auth
type.  Browsers which do not know that an XMPP Realm is "special" will
just do this:

|   Realm: XMPP
|   Username: _____________
|  Password: ____________

That will obviously make no sense to the Aunt Tillies out there.

So I think the fix needs to involve coming up with a new auth type,
and if we need to specify the XMPP connection method we do that in a
parameter.  Then we can also pick up more appropriate XMPP terms like
SASL.

This example will let you provide fallback to the non-XMPP aware user
agents out there:

401 Unauthorized HTTP/1.1
WWW-Authenticate: Basic realm="Montague House private web space"
WWW-Authenticate: XMPP realm="Montague House private web space",
                          method="Basic"
WWW-Authenticate: XMPP realm="Montague House private web space",
                          method="SASL",
                          domain="montague.shakespeare.lit"

I don't know how the actual use case would work, but let's not forget
the Capulets:

WWW-Authenticate: XMPP realm="Capulet House private web space",
                          method="SASL/TLS",
                          domain="capulet.shakespeare.lit"
                          ...

Along thoese lines anyway.  I'm not gonna rewrite the whole thing, but
I really just wanted to point out the flaws as I saw them.  Please
critique, I did not know much about RFC 2617 before tonight!

[1]: Verifying HTTP Requests via XMPP
http://www.jabber.org/jeps/jep-0070.html

[2]: RFC 2617, HTTP Authentication: Basic and Digest Access Authentication
http://ietfreport.isoc.org/idref/rfc2617/#page-2

[3]: http://ietfreport.isoc.org/idref/rfc2617/#page-4

[4]: http://www.jabber.org/jeps/jep-0070.html#http-response

P.S. Why is it so hard to find RFCs in TOC-hyperlinked format?

--
Psi webmaster (http://psi-im.org)
im:hal at jabber.rocks.cc
http://halr9000.com