Subject: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

From: IESG Secretary <[email-masked]>
Date: Tue, 21 Feb 2012 10:10:05 -0800 (PST)

A modified charter has been submitted for the Hypertext Transfer 
Protocol Bis (httpbis) working group in the Applications Area of the 
IETF.  The IESG has not made any determination as yet.  The modified 
charter is provided below for informational purposes only.  Please send 
your comments to the IESG mailing list ([email-masked]) by Tuesday, 
February 28, 2012.

Hypertext Transfer Protocol Bis (httpbis)
=========================================

Charter
Last Modified: 2012-02-09

Current Status: Active Working Group

Chair(s):
    Mark Nottingham  <[email-masked]>

Applications Area Director(s):
    Pete Resnick  <[email-masked]>
    Peter Saint-Andre  <[email-masked]>

Applications Area Advisor:
    Peter Saint-Andre  <[email-masked]>

Mailing Lists:
    General Discussion:[email-masked]
    To Subscribe:      [email-masked]
        In Body:       subscribe
    Archive:           http://lists.w3.org/Archives/Public/ietf-http-wg/

Description of Working Group
----------------------------

This Working Group is charged with maintaining and developing
the "core" specifications for HTTP.

The Working Group's specification deliverables are:
* A document (or set of documents) that is suitable to supersede RFC
 2616 (HTTP/1.1) and move RFC 2817 to Historic status
* A document cataloguing the security properties of HTTP/1.1
* A document that specifies HTTP/2.0 an improved binding of HTTP's
 semantics to the underlying transport.

### HTTP/1.1

HTTP is one of the most successful and widely-used protocols on the
Internet today. However, its specification has several editorial issues.
Additionally, after years of implementation and extension, several
ambiguities have become evident, impairing interoperability and the
ability to easily implement and use HTTP.

The working group will refine RFC2616 to:
* Incorporate errata and updates (e.g., references, IANA registries,
 ABNF)
* Fix editorial problems which have led to misunderstandings of the
 specification
* Clarify conformance requirements
* Remove known ambiguities where they affect interoperability
* Clarify existing methods of extensibility
* Remove or deprecate those features that are not widely implemented
 and also unduly affect interoperability
* Where necessary, add implementation advice
* Document the security properties of HTTP and its associated
 mechanisms (e.g., Basic and Digest authentication, cookies, TLS) for
 common applications

It will also incorporate the generic authentication framework from RFC
2617, without obsoleting or updating that specification's definition of
the Basic and Digest schemes.

Finally, it will incorporate relevant portions of RFC 2817 (in
particular, the CONNECT method and advice on the use of Upgrade), so
that that specification can be moved to Historic status.

In doing so, it should consider:
* Implementer experience
* Demonstrated use of HTTP
* Impact on existing implementations and deployments

### HTTP/2.0

There is emerging implementation experience and interest in a protocol
that retains the semantics of HTTP, without the legacy of HTTP/1.x
message framing and syntax, which have been identified as hampering
performance and encouraging misuse of the underlying transport.

As such, there is an opportunity to create a new major
(non-wire-compatible) version of HTTP.

To do this, the Working Group will solicit candidates for this work from
the community, to be submitted as Internet-Drafts. Expected focus areas
for candidates include:

* Significantly improved perceived performance in common use cases
 (e.g., browsers, mobile)
* More efficient use of network resources; in particular, reducing the
 need to use multiple TCP connections
* Ability to be deployed on today's Internet, using IPv4 and IPv6, in
 the presence of NATs
* Maintaining HTTP's ease of deployment
* Reflecting modern security requirements and practices

Although proposals are not required to meet all of these goals, it is
expected that the resulting work (if undertaken) will be chartered to
meet them (and therefore, selecting one that meets the majority of them
as a starting point is in everyone's interest).

The Working Group will then select a starting point for the new work
based upon the following criteria:

* Compatibility with HTTP/1.1 semantics; i.e., it must be possible to
 pass through a HTTP/1.1 message with reasonable fidelity
* Broad implementer interest (e.g., from Web browsers, "back-end"
 or "web api" uses of HTTP, servers, intermediaries, CDNs, etc.)

Changes to the existing semantics of HTTP are out of scope in order to
preserve the meaning of messages that might cross a 1.1 --> 2.0 --> 1.1
request chain. However, the resulting effort may define new semantics to
further the goals above, along with suitable extensibility mechanisms
for defining additional semantics.

If the Working Group forms consensus around a proposal to use as a
starting point, it is expected it will re-charter to begin work on that
document (or set of documents). The resulting work will be known as
"HTTP/2.0", unless the Working Group determines that this isn't suitable
(e.g., for interoperability).

Although work on this new version will begin in parallel with completion
of work on HTTP/1.1, the Working Group will prioritize HTTP/1.1 work
until it is complete.

Goals and Milestones
---------------------

  Done        First HTTP/1.1 Revision Internet Draft

  Done        First HTTP Security Properties Internet Draft

  Feb 2012    Working Group Last Call for HTTP/1.1 Revision

  Feb 2012    Working Group Last Call for HTTP Security Properties

  Feb 2012    Call for Proposals for HTTP/2.0

  Apr 2012    Submit HTTP/1.1 Revision to IESG for consideration as a
              Proposed Standard

  Apr 2012    Submit HTTP Security Properties to IESG for
              consideration as Informational RFC

  June 2012   Re-charter to work on HTTP/2.0

###

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Feb 2012 18:26:27 +0000

> * Reflecting modern security requirements and practices

In some earlier discussion I asked what "modern" means
there. It seems to mean at least working well with TLS,
but I'm not sure what else is meant, if anything.

In particular, I think it'd be good to try get better
(more usable, more secure etc.) HTTP authentication
defined as a built-in part of HTTP/2.0.

My initial take is that if we're not going to do this
for a major revision of the protocol, then when are we
going to do it? So I'd like to see that included.

The counter argument offered was that better HTTP
authentication is complex and probably hard to get right
and so would be better handled separately.

While that's not an unreasonable point, my counter-counter
argument is that it doesn't seem to have worked very well
so far.

It was also argued that this charter is scoped to just
allow for selection of an initial candidate for HTTP/2.0
and there'd be another re-charter to follow based on that
selected candidate, so that discussion of specific
security features would be better done after that when
there's a specific protocol on which to do work.

My worry about that is that in practice the main
security aspects of a putative HTTP/2.0 will be very
hard to change at that point, so I'd like to see it
discussed as part of this phase of the work.

What do others think?

Thanks,
Stephen.

PS: When I say "like" above, that's what I'd personally
like, not a position that I'm adopting as a security AD.
(Alhough that'd be a fairly predictable position I guess:-)

On 02/21/2012 06:10 PM, IESG Secretary wrote:
>      Mark Nottingham<[email-masked]>
>
>      Pete Resnick<[email-masked]>
>      Peter Saint-Andre<[email-masked]>
>
>      Peter Saint-Andre<[email-masked]>
>
> Mailing Lists:
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 21 Feb 2012 19:33:08 +0100

> and so would be better handled separately.

I believe this should be orthogonal to HTTP/2.0. Is there a specific 
thing that makes it impossible to use the existing authentication framework?

> ...

Best regards, Julian

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Feb 2012 18:37:12 +0000

> thing that makes it impossible to use the existing authentication

Who knows? We don't have a protocol on the table yet. I
would imagine that some level of backwards compatibility
would be a requirement of course, or at least an issue to
be considered.

But the existing HTTP client authentication is also not
necessarily very useful, and there have been a number of
efforts to improve on that, none of which seem to have
gotten sufficient traction to get widely deployed/used.
Maybe HTTP/2.0 is a good time to try fix that.

S.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 21 Feb 2012 19:50:04 +0100

> Maybe HTTP/2.0 is a good time to try fix that.

Well, we have an existing authentication framework. It would be 
interesting to find out what's missing from it.

Best regards, Julian

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Feb 2012 22:19:28 +0000

Hi Julian,

> interesting to find out what's missing from it.

Fair point.

I would wonder whether that framework could be used
as-is if HTTP/2.0 does do away "with the of HTTP/1.x
message framing and syntax" but I guess some equivalent
functionality could be defined in that case.

So as in my initial mail the 1st question here is, what
does "modern" mean in this draft charter? E.g. does it
mean "same as the current framework with different
bits" or something else? If so, what?

And then should it include adding some new options
or MTI auth schemes as part of HTTP/2.0 or even looking
at that? (I think it ought to include trying for that
personally, even if there is a higher-than-usual risk
of failure.)

S

---

From: Robert Collins <[email-masked]>
Date: Wed, 22 Feb 2012 11:28:38 +1300

On Wed, Feb 22, 2012 at 7:50 AM, Julian Reschke <[email-masked]> wrote:

>
> Well, we have an existing authentication framework. It would be interesting
> to find out what's missing from it.

browser id, openid, and oauth are all authentication frameworks built
on top of HTTP rather than with HTTP; being able to implement some or
all of those at the protocol layer would be very nice.

As to whats involved, I don't have a short-list at hand, sorry :)

-Rob

---

From: Barry Leiba <[email-masked]>
Date: Tue, 21 Feb 2012 17:36:11 -0500

> on top of HTTP

OAuth is an authorization framework, not an authentication one.  Please be
careful to make the distinction.

What we're looking at here is the need for an HTTP authentication system
that (for example) doesn't send reusable credentials, is less susceptible
to spoofing attacks, and so on.

Barry

---

From: Adrien de Croy <[email-masked]>
Date: Wed, 22 Feb 2012 11:38:05 +1300

Hi Julian,

> interesting to find out what's missing from it.

session support with login and logout would be good.  I know it's a can 
of worms, with some serious security implications.

But this is why no websites use HTTP auth to speak of, which makes it 
difficult to do integrated authentication.

Adrien

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 22 Feb 2012 09:40:02 +1100

> functionality could be defined in that case.

That shouldn't affect the framework at all. At most, you'd have to define how to re-serialise the current syntax if you don't have a way to "tunnel" it (since HTTP/1.1 passthrough is required).

> bits" or something else? If so, what?

As discussed off-list, I'd be happy to drop this phrase from *this* charter, in anticipation of it being worked out in discussions about the *next* one.

> personally, even if there is a higher-than-usual risk

Based on past experience, I think the risk is very high, and we don't need to pile any more risk onto this particular project. 

Also, most of the discussions about authentication and associated problems on the Web are *not* exclusive to HTTP or even protocol artefacts; they include concerns like UI and human factors, integration into hypertext, etc. As such, what we really need is a "whole of stack" focus on Web authentication; shoving it into this particular WG will, IMO, lead to a predictable failure.

Regards,

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

---

From: Tim Bray <[email-masked]>
Date: Tue, 21 Feb 2012 14:46:14 -0800

[in-line]

> Based on past experience, I think the risk is very high, and we don't need to pile any more risk onto this particular project.

+1

HTTP's ability to be equipped with security technology has been
adequate, and I haven't heard much argument that its semantics were
the big obstacle to newer/better security.  Preserving its semantics
means its successor should be equally adequate.

Mnot is *understating* the risk of loading up the charter with this stuff. -T

---

From: Robert Collins <[email-masked]>
Date: Wed, 22 Feb 2012 11:53:27 +1300

> careful to make the distinction.

I call rubbish:

http://tools.ietf.org/html/rfc5849#section-1.1

And I quote: "   client
         An HTTP client (per [RFC2616]) capable of making OAuth-
         authenticated requests (Section 3).

   server
         An HTTP server (per [RFC2616]) capable of accepting OAuth-
         authenticated requests (Section 3)."

OAuth certainly *thinks* it provides *both* Authentication *and*
Authorization, and it uses the same header that Basic and Digest do -
Authorization.

> that (for example) doesn't send reusable credentials, is less susceptible to
> spoofing attacks, and so on.

Those are good things too, though orthogonal to my point, which is
that some of the most widely deployed authentication - yes,
authentication - systems used by web sites are not part of the HTTP
protocol spec. OpenID  and cookie based systems in general.

(Though OAuth is a pleasing exception in that it can and does
preferentially use the Authorization header).

-Rob

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Feb 2012 22:53:12 +0000

> As discussed off-list, I'd be happy to drop this phrase from *this* charter, in anticipation of it being worked out in discussions about the *next* one.

Well, I think the phrase does need to be replaced
by something else all right.

I'm reluctant to omit mention of security entirely
of course and do want to know what's gonna be done
for authentication in a putative HTTP/2.0.

Like I said, I'm pretty skeptical that any significant
change to security properties will be achievable at
that next charter stage.

> Based on past experience, I think the risk is very high, and we don't need to pile any more risk onto this particular project.

Based on past experience the milestones for this will be
wildly optimistic and it'll really take five years so at
the end of 2017 we'll be right where we are in terms of
HTTP authentication for all of which time HTTP authentication
will be the "next thing" to do. (Ok, I'm exaggerating a
bit there.)

I think both experiences are valid.

> Also, most of the discussions about authentication and associated problems on the Web are *not* exclusive to HTTP or even protocol artefacts; they include concerns like UI and human factors, integr…

It is true that many sites don't use HTTP authentication
for UI reasons. I don't think it follows that doing nothing
is the right approach. (Well, one could argue to remove all
user authentication from HTTP I guess - is that one of the
proposals?)

Cheers,
S.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 22 Feb 2012 09:55:41 +1100

Stephen, 

The approach we're advocating for this WG is to solicit well-formed proposals, select one and develop it. 

If there isn't one for HTTP authentication, how are you advocating we proceed?

Regards,

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Feb 2012 23:01:09 +0000

> If there isn't one for HTTP authentication, how are you advocating we proceed?

I'm not thinking now in terms of advocating a specific
proposal for how to proceed.

Right now, I'm interested in what others reviewing the
draft charter think about this topic. That's the point
of having this discussion in the open like this.

(So maybe I should shut up for a while:-)

S

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 22 Feb 2012 12:29:02 +1300

On 22.02.2012 11:46, Tim Bray wrote:
> [in-line]
>
> On Tue, Feb 21, 2012 at 2:40 PM, Mark Nottingham wrote:
>> Based on past experience, I think the risk is very high, and we 
>> don't need to pile any more risk onto this particular project.
>
> +1
>

+1.

I think the new security additions should be limited to making it clear 
and ensuring that HTTP as a transport neither adds nor substracts 
security to the overall system.
  HTTP over TLS or such has connection-level security/authentication as 
inherited from that TLS.
  HTTP message authentication or such has per-message security for the 
particular message.

We may have to consider new features or restrictions to ensure that TLS 
level security is retained end-to-end or such. But fixing problems in 
those other layers in a charter to re-design the middle HTTP layer seems 
inappropriate.

AYJ

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 22 Feb 2012 07:49:14 +0100

On Wed, Feb 22, 2012 at 11:53:27AM +1300, Robert Collins wrote:
(...)
> Authorization, and it uses the same header that Basic and Digest do -

I think that this simply shows a semantic mistake from the past, where
authentication and authorization were a bit conflated. Look at the HTTP
headers, you have the server send "www-authenticate", and the client
responds with "authorization" ! At least this is a point we should clarify
in the next version, because I know too many people who consider that
authenticated == authorized. And this is also one reason for http-based
auth not being *that* much deployed in the applications world since they
have to pretend an authentication failure (401) to report a lack of
authorization if/when they want to offer the client a chance to try other
credentials.

Regards,
Willy

---

From: David Morris <[email-masked]>
Date: Tue, 21 Feb 2012 23:04:45 -0800 (PST)

On Tue, 21 Feb 2012, Michael Richardson wrote:

> 
> >>>>> "Barry" == Barry Leiba <[email-masked]> writes:
>     Barry> OAuth is an authorization framework, not an authentication
>     Barry> one.  Please be careful to make the distinction.
> 
>     Barry> What we're looking at here is the need for an HTTP
>     Barry> authentication system that (for example) doesn't send
>     Barry> reusable credentials, is less susceptible to spoofing
>     Barry> attacks, and so on.
> 
> and is implemented in HTTP, not in terms of HTML forms, yet has all the 
> flexibility of the HTML form method?

And includes the ability for the user to logoff / the server reset the 
login?

---

From: Julian Reschke <[email-masked]>
Date: Wed, 22 Feb 2012 09:38:08 +0100

> in the next version, because I know too many people who consider that

We can clarify it in *this* version. Do you have a specific proposal for 
Part 7?

> authorization if/when they want to offer the client a chance to try other

<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-18.html#status.403>:

"7.4.4 403 Forbidden

The server understood the request, but refuses to authorize it. 
Providing different user authentication credentials might be successful, 
but any credentials that were provided in the request are insufficient. 
The request SHOULD NOT be repeated with the same credentials.

If the request method was not HEAD and the server wishes to make public 
why the request has not been fulfilled, it SHOULD describe the reason 
for the refusal in the representation. If the server does not wish to 
make this information available to the client, the status code 404 (Not 
Found) MAY be used instead."

What's wrong with this status code? As far as I can tell, what's missing 
is UI, not protocol elements.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 22 Feb 2012 09:39:33 +0100

On 2012-02-22 08:04, David Morris wrote:
>>>>>>> "Barry" == Barry Leiba<[email-masked]>  writes:

Is that a protocol problem or a user agent problem?

-- > <http://lists.w3.org/Archives/Public/www-archive/2012Jan/0023.html>

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 22 Feb 2012 12:16:20 +0100

Hi Julian,

> We can clarify it in *this* version. Do you have a specific proposal for 

Unfortunately no, because I think the confusion is too much anchored in
people's mind.

(...)
> is UI, not protocol elements.

There's nothing wrong, but I've never seen a browser suggest to logout/relog
upon a 403. Also, since browsers don't offer the possibility to logout in
general, it's hard to suggest that this possibility should be specifically
offered upon 403. In fact it's the global authentication/authorization
mechanism that should be cleaned up in 2.0 and I don't think it's too hard,
we just have to clearly state that we might break *some* of the 1.1 assumptions.

Best regards,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Wed, 22 Feb 2012 12:47:55 +0100

> we just have to clearly state that we might break *some* of the 1.1 assumptions.

If browsers had an API for logging off, servers could send a 403 
response page *doing* the log off. Wouldn't that be sufficient?

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 22 Feb 2012 14:22:15 +0100

> response page *doing* the log off. Wouldn't that be sufficient?

In my opinion, 403 is an authorization issue, and it can come from
the user attempting to perform an unauthorized operation or just
that the lack of authorization requires a re-login. Only the user
can decide. So I think that the 403 response shouldn't cause the
logout to happen, but just make the browser ask the user if he
prefers to log out or to continue normal browsing. A "log off"
button on the top right corner would definitely help. Users could
take the advice from the text response accompanying the 403 to
decide whether they need to log off and log in as another user
or if they prefer to click the "back" button and ignore the error.

403 is quite a common error where WAF products are deployed, and it
would have a disastrous effect if it would cause an automatic logout.

That said, I totally agree with you that if we could get the browsers
include the logout method, we could start from a cleaner ground to
propose more reliable and user-friendly solutions even in 1.1. Maybe
we should consider that this feature exists and see what we can build
based on that assumption ?

Willy

---

From: Julian Reschke <[email-masked]>
Date: Wed, 22 Feb 2012 14:37:44 +0100

> would have a disastrous effect if it would cause an automatic logout.

That's why I suggested that the server decides by including the 
necessary client side JS code...

> based on that assumption ?

Maybe.

My impression is that every time this topic comes up people compile a 
large list of things-that-absolutely-need-to-be-done, and in the end 
nothing ever happens because that list is too long, and there's 
disagreement what should be on the list.

I think there's rough consensus that to make HTTP authentication work 
better in practice, servers need to be able to logout the user. As far 
as I can tell, a straightforward way to do so is to have a browser API 
for that. It's a shame there's no progress on that.

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 22 Feb 2012 15:02:49 +0100

> necessary client side JS code...

I think that sometimes the server wants to cause the logout (eg: application
status code) and sometimes the user wants to log off. Many web developers
working in environments where basic auth is in use are used to open/close
their browser all the day due to the lack of logoff button.

> disagreement what should be on the list.

I'm not surprized. In fact, I tend to prefer basic building blocks on top
of which other things may be build, but right now it's obvious that some
such blocks are missing.

> for that. It's a shame there's no progress on that.

If we had the browsers provide the logoff button, then the current 403
is already enough for user-initiated action. If we want the server to
force a logoff, we possibly need to define how this is supposed to be
done. Note that in this case it's a change of authentication, which is
different from a lack of authorization (eg: return 401 with an empty
www-authenticate response).

I do think that all of that might be defined in 1.1 without touching
the in-browser API if browser vendors collaborate ; we just have to
define how it should work and still be compatible with non-compliant
browsers (possibly that returning 401 without a www-authenticate header
has no negative effect on older browsers, I'm just suggesting).

It would be nice to have their opinion here. Patrick, Anne, any idea ?
We also need to keep in mind there are non-browser UAs. Maybe Daniel
has some useful ideas based on how curl handles 401.

Regards,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Wed, 22 Feb 2012 15:27:02 +0100

> status code) and sometimes the user wants to log off. Many web developers

The server can send code that allows the user to make the decision.

> their browser all the day due to the lack of logoff button.

And in future there may be browsers that can not be closed at all.

> is already enough for user-initiated action. If we want the server to

Browsers will not add any new UI components without a very strong use 
case. That's why adding the button to he page *content* will work much 
better.

> www-authenticate response).

When I say logout I mean "stop sending credentials until prompted again".

Best regards, Julian

---

From: David Morris <[email-masked]>
Date: Wed, 22 Feb 2012 07:25:16 -0800 (PST)

> -- > <http://lists.w3.org/Archives/Public/www-archive/2012Jan/0023.html>

I consider it a protocol issue in the same way that authentication is a
protocol issue.

The question I was responding to was one of adoption by application
developers and is in addition to the lack of application control over
the current authenticate dialog. A "use case" if you will.

The JS approach isn't really adequate because not all user agents
execute the payload. Second 1/2 of the "use case."

I'm not advocating that this be solved as part of the Recharter/2.0
activity, I'm neutral on the where question.

---

From: Albert Lunde <[email-masked]>
Date: Wed, 22 Feb 2012 10:32:19 -0600

It seems like what would be useful would be a way of bringing in trusted 
third-parties into authentication that didn't look like a 
man-in-the-middle attack, and didn't rely on JavaScript.

SAML "federation" (e.g. Shibboleth) is layered on top of HTML+HTTP,
but it, and most of the other existing WebSSO systems, rely on 
JavaScript tricks somewhere in their process.

Trusted third parties are presently more the domain of certificates or 
Kerberos, than HTTP as such.

SASL is another framework for layering authentication onto protocols, 
that's been worked on considerably. But I don't know if it can meet the 
needs of the browser-based market now being served by 
forms+cookies+JavaScript.

Finding a single authentication/authorization framework that serves the 
needs of both browser and non-broswer clients is hard.

Scott Cantor has written a lot about why global logout for Shibboleth is 
hard to implement. Part of that may rest on the underlying legacy 
mechanisms they are using, but it's also a communication problem.

Having a local logout that really meant "stop sending cookies and 
credentials for realm X to these servers" and/or authentication realms 
that spanned servers might help, I don't know.

-- 
     Albert Lunde  [email-masked]
                   [email-masked]  (address for personal mail)

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 23 Feb 2012 10:04:10 +0200

On 2/22/12 12:40 AM, Mark Nottingham wrote:
> Also, most of the discussions about authentication and associated problems on the Web are*not*  exclusive to HTTP or even protocol artefacts; they include concerns like UI and human factors, integration into hypertext, etc. As such, what we really need is a "whole of stack" focus on Web authentication; shoving it into this particular WG will, IMO, lead to a predictable failure.
I agree with Mark on this point

/Salvatore

---

From: John C Klensin <[email-masked]>
Date: Fri, 24 Feb 2012 11:43:31 -0500

--On Friday, February 24, 2012 16:58 +0100 Patrik Fältström
<[email-masked]> wrote:

> On 24 feb 2012, at 16:38, Andrew Sullivan wrote:
> 
>> Over in spfbis, people are arguing that the SPF RRTYPE should
>> be deprecated and abandoned in SPF because nobody uses it
>> because of practical difficulties in getting new RRTYPEs
>> deployed.  What makes us think that the arguments in favour
>> of SRV are going to find more fertile ground?
> 
> Because people disagree on whether it is actually hard to get
> new RRTYPEs deployed.
> 
> I for example do completely disagree on it being hard. Sure,
> your user interface in the gui of your favorite $EDITOR might
> not support the new RRTYPE, but should that constrain
> deployment of good standards?

Patrik,

While I don't see it as hard as Andrew does, I don't see it as
easy either.  The problem isn't one's favorite $EDITOR.  It is
the number of folks who, for lots of reasons, haven't upgraded
from operating systems, resolvers, etc., that don't support
newer RRTYPES.   Remember that, while Windows 7 is getting some
of the market share that Vista never did, there are still a huge
number of XP systems out there -- many of them in the hands of
people and organizations who aren't going to make the hardware
investment to upgrade in a difficult economy.  The situation
with the Mac platform actually isn't much better -- I know a lot
of people who haven't (and can't) upgrade from OS 9, much less
to the latest carnivorous feline.  

SRV has the advantage of many year's head start and more utility
to more protocols over, e.g., SPF but the reality remains that,
if some users have support for an important new RRTYPE and
others don't, we have either an inconsistent user experience
(more confusion, more support calls, etc.) or, as we have seen
with DNAME, a need to carry around complex workarounds that can
lead to bugs, vunerabilities, or, ahem, inconsistent user
experience.

And, fwiw, I'm actually much more concerned about use of the DNS
for any part of the process if we don't have broad consensus in
and between the IETF and the implementer community about whether
IRIs or URIs are authoritative and about how domain names
containing IDN labels are encoded in either.   I'm equally
concerned if some organization of our mutual acquaintance is
determined to declare the existence of equivalent names in the
DNS that will create user expectations that certs and comparison
mechanisms cannot support.

--On Thursday, February 23, 2012 14:38 -0800 Doug Barton
<[email-masked]> wrote:

> 2782 was published 12 years ago this month. I suppose it can be
> considered mature enough to deploy at this point? :)

One might wish.  But real maturity has to be based on
implementation and deployment, not just publication dates.   I
note, for example, that RFC 736 (an old favorite example of mine
for several reasons) was published over 34 years ago is, like
2782, still at Proposed Standard, and, sadly, hasn't gone
anywhere (at least in the last decade or so).   Certainly it is
elderly as Internet protocols go, but I don't think the leap
from "elderly" to "mature" is obviously justified.

    john

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 24 Feb 2012 17:57:31 +0100

On 24 feb 2012, at 17:43, John C Klensin <[email-masked]> wrote:

> It is
> newer RRTYPES.

As I said, people disagree... ;-)

As far as I know, there is nothing in any of the operating systems you mention that prohibits an application to send a random udp packet, and because of that your application can include a resolver library.

What is a problem are the cases where DNS is not used at all at the end node, but instead other name binding/lookup protocols combined with a firewall policy that because of this can and is blocking udp+tcp/53 in various ways.

That said, I still ask when it is, in general, time to just move forward. I see for example many other reasons why people should not use that old software. IE6 for example. Yes, economically constrained situations exists, but that problem do not go away by having us not start using SRV or HTTP/1.1 or SNI or HTML5.0 or...pick your favourite. And with SPF, that is not used by the edge node either.

I am asking more generally why specifically this DNS issue is so stuck, because I think that is unfair. We upgrade other protocols...

But my point is, people disagree. As we see here ;-)

   Patrik

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 26 Feb 2012 07:40:25 +0100

On Fri, Feb 24, 2012 at 05:57:31PM +0100, Patrik Fältström wrote:
> I am asking more generally why specifically this DNS issue is so stuck,
> because I think that is unfair. We upgrade other protocols...

Because in HTTP, anybody can be anywhere. You can have client-side proxies,
server-side gateways, load balancers, etc... everyone in this chain may or
may not resolve, it's only a matter of configuration and architecture choice.
There are plenty of places where clients won't access public resolvers at all
and rely on their proxies for this. So you can't make use of DNS to improve
these users' experience.

Also, DNS is SLLLLOOOOWWWWW. It's fast enough to send a mail. But for HTTP
it adds too much latency. Some people in the mobile world would like to be
able to configure an explicit proxy on their smartphones in order to avoid
a very expensive round trip before fetching an object : at 20 host names
on a web page, 300 ms round trip means 6 seconds are lost to resolve these
objects if they can't be totally parallelized.

DNS suggestion is something going back and forth regularly. I think that
people who try to push it hard only see the very simple case where users
have a direct low-latency internet connection. The reality is much much
different. This well reflected by the fact that in the end, after many
proposals, it has still not been adopted !

Regards,
Willy

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 24 Feb 2012 15:59:13 +0000

On 24 feb 2012, at 16:38, Andrew Sullivan wrote:

> Over in spfbis, people are arguing that the SPF RRTYPE should be
> deprecated and abandoned in SPF because nobody uses it because of
> practical difficulties in getting new RRTYPEs deployed.  What makes us
> think that the arguments in favour of SRV are going to find more
> fertile ground?

Because people disagree on whether it is actually hard to get new RRTYPEs deployed.

I for example do completely disagree on it being hard. Sure, your user interface in the gui of your favorite $EDITOR might not support the new RRTYPE, but should that constrain deployment of good standards?

   Patrik

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 24 Feb 2012 15:38:51 +0000

On Fri, Feb 24, 2012 at 01:54:32PM +1100, Mark Andrews wrote:
> 
> In message <[email-masked]>, Doug Barton writes:
> > 
> +1000

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Doug Barton <[email-masked]>
Date: Sat, 25 Feb 2012 03:57:58 +0000

> think that the arguments in favour of SRV are going to find more

Because I emphasized the point that SRV has been around for 12 years? I
have enough experience to know how difficult it is to deploy new RRs.
SRV is not new.

Doug

-- 

	It's always a long day; 86400 doesn't fit into a short.

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: John C Klensin <[email-masked]>
Date: Mon, 27 Feb 2012 14:41:15 -0500

> As far as I know, there is nothing in any of the operating
> systems you mention that prohibits an application to send a
> random udp packet, and because of that your application can
> include a resolver library.
> 
> What is a problem are the cases where DNS is not used at all
> at the end node, but instead other name binding/lookup
> protocols combined with a firewall policy that because of this
> can and is blocking udp+tcp/53 in various ways.

I'd suggest that there are two other problems.  One is that
per-application resolver setups pretty much prevent caching of
any flavor (possibly not an issue if one opens applications,
keeps them open for a long time, and uses different target sites
with different applications, but, if that scenario has been
studied wrt frequency, I'm not aware of it).  The other, more
important, issue is that it just about guarantees an
inconsistent user experience wrt the treatment of names.  

Of course those are tradeoffs against locally-improved
functionality and reasonable people can disagree about how
important those issues are wrt the other considerations.

> That said, I still ask when it is, in general, time to just
> move forward. I see for example many other reasons why people
> should not use that old software. IE6 for example. Yes,
> economically constrained situations exists, but that problem
> do not go away by having us not start using SRV or HTTP/1.1 or
> SNI or HTML5.0 or...pick your favourite. And with SPF, that is
> not used by the edge node either.
> 
> I am asking more generally why specifically this DNS issue is
> so stuck, because I think that is unfair. We upgrade other
> protocols...

Where I probably agree with you is that I think that we need to
evaluate costs, benefits, and risks and to do so against an
understanding and hope that we will have _many_ more Internet
users a decade from now than we do today.  Accepting the latter
may justify changes even more painful than transition to a new
RRTYPE if we understand that we are inconveniencing a relatively
small number of people today in order to make things much better
for a far larger future number.  And that is why I have never
believed in arguments for guaranteed absolute forward
compatibility in Internet, and Internet-like, situations.

> But my point is, people disagree. As we see here ;-)

Indeed.  Even though I would hope that we can at least mostly
agree about the facts even if we disagree about the tradeoffs to
which they lead.

    john

---

From: Mark Andrews <[email-masked]>
Date: Mon, 27 Feb 2012 22:48:58 +0000

In message <[email-masked]>, Willy Tarreau writes:
> On Fri, Feb 24, 2012 at 05:57:31PM +0100, Patrik F=E4ltstr=F6m wrote:

> may not resolve, it's only a matter of configuration and architecture choic=
> e.
> There are plenty of places where clients won't access public resolvers at a=
> ll

Proxies can lookup SRV records.  They already lookup A and AAAA records.
 
> objects if they can't be totally parallelized.

If they can't be parallelized then you can blame the page developer.

As for SRV you can always do SRV + AAAA + A in parallel.

> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Henrik Nordström <[email-masked]>
Date: Wed, 29 Feb 2012 20:19:32 +0100

> interesting to find out what's missing from it.

My take is better secure authentication schemes (not plaintext password
based) which is cleanly specified to a level that implementations
actually interop properly, and the ability for site owners (and proxies)
to influence how the login process is presented to users in a safe
manner that do not collide with preceived https security or makes a mess
for matchine<->machine communication not involving humans.

The existing HTTP auth framework works in general very well for
machine<->machine. 

This said I have used HTTP Digest authentication quite successfully (but
with a number of interop workarounds) with non-tech users using the
default login box, only providing a good error response message seen if
the user cacels of fails the login.

Regards
Henrik

---

From: Henrik Nordström <[email-masked]>
Date: Wed, 29 Feb 2012 20:32:50 +0100

> their browser all the day due to the lack of logoff button.

There is a very simple but confsing method for that: requesting a
resource requiring different credentials in the same realm, and ask the
user to log in there with some well known credentials (i.e. username
logoff, password logoff)

In some browsers even cancelling that login box is sufficient, but most
require the user to login with different credentials to invalidate the
first.

> is already enough for user-initiated action.

Fully agreed.

> If we want the server to force a logoff, we possibly need to define how
> this is supposed to be

logoff is mostly in the realm of human interaction, so javascript could
do it nicely imho. Document.logoff() or similar.

Not sure there even is a demand for protocol level indicated logoff
where the server at HTTP level tell the client to invalidate the cached
credentials.

Regards
Henrik

---

From: Adrien de Croy <[email-masked]>
Date: Thu, 01 Mar 2012 09:09:56 +1300

There is one other thing I would add to auth:

Ability for a challenger to identify itself, and for a response to 
target a challenger.

Currently with chained proxies, it's not possible to reliably pass 
challenges and creds back to the client.  A proxy looking at a request 
would need to maintain state to know if it challenged the client or not.

Adding a parameter to the challenge and response which identifies the 
challenger would allow for this.

In fact it would then allow proxy and server auth to use the same 
mechanism and headers.

Adrien

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

---

From: Adrien de Croy <[email-masked]>
Date: Thu, 01 Mar 2012 09:14:06 +1300

> where the server at HTTP level tell the client to invalidate the cached

Actually I would like to see this.

For example product admin back-ends which use http auth. We'd like to be 
able to time out a user so someone else coming along (if the first user 
didn't close the browser) doesn't gain access to things they shouldn't.

Regards

Adrien

---

From: Henrik Nordström <[email-masked]>
Date: Wed, 29 Feb 2012 23:44:30 +0100

> Ability for a challenger to identify itself, and for a response to 

proxy-auth is currently defined hop-by-hop avoiding this mess. But
unfortunately real-life networks is not always that simple.

but security implications of multi-level proxy challenges is tricky to
say the least. There is no guarantee the next request travels the same
path. I would not dare to venture into specifying what such muti-level
challenge/response process with varying path would look like or work or
the security aspects of any such design.

> challenger would allow for this.

Yes, but opens up a big can of worms as expressed above.

> In fact it would then allow proxy and server auth to use the same 

Which is one very visible aspect of that big can of worms. You need a
damn good framework defining what may be sent where, and the
possibilities of both security leakage and breakage explodes.

Regards
Henrik

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 01 Mar 2012 11:51:43 +1300

On 01.03.2012 09:14, Adrien de Croy wrote:
> For example product admin back-ends which use http auth. We'd like to
> be able to time out a user so someone else coming along (if the first
> user didn't close the browser) doesn't gain access to things they
> shouldn't.

Timeout is only needed in the protocol if the server and client are not 
timing out credentials. bringing up the question of why do the client 
and server not implement a timeout already? it is point-blank more 
secure.

You place a caveat on having not closed the browser. For good reason. 
The protocol mandating that the client close the browser is useless. Yet 
a protocol timeout would be a mandated equivalent of closing the 
browser. TCP has this same problem and added TIME_WAIT to resolve it. We 
are today faced with many complex features of HTTP/1.1 being designed 
explicitly to avoid the problems it creates (pipelines, keep-alive, 
chunking, tunnels). Lets not inflict mandatory authentication TIME_WAITs 
on users when a server makes a mistake and terminates early.

AYJ

---

From: Adrien de Croy <[email-masked]>
Date: Thu, 01 Mar 2012 11:57:00 +1300

On 1/03/2012 11:44 a.m., Henrik Nordström wrote:
> path.

that depends on proxy design.  If the challenges and responses are going 
over the same TCP connection it's pretty simple.

e.g. NTLM...  sorry, had to say it :)

the main area we see the problem is actually not in proxy auth, but when 
a proxy intercepts the connection, requires auth and then the website 
requires auth as well.

It's hard for the proxy to know whether an auth response should be 
processed by itself, or upstream.

> I would not dare to venture into specifying what such muti-level

I guess a proxy could keep a map of seen auth identifier tokens and 
re-use the same path back again (if possible).

But ok, see your point.

In most cases though where this happens, wouldn't the upstream proxies 
be within the same administrative domain?  e.g. so creds should work, 
and leakage shouldn't be a problem.

Adrien

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/

---

From: Adrien de Croy <[email-masked]>
Date: Thu, 01 Mar 2012 12:02:54 +1300

On 1/03/2012 11:51 a.m., Amos Jeffries wrote:
> Timeout is only needed in the protocol if the server and client are 
> not timing out credentials. bringing up the question of why do the 
> client and server not implement a timeout already? it is point-blank 
> more secure.

sure, I presume you mean by timeout in the credentials, timeout of some 
token associated with the creds, rather than invalidating the password.

there's no room for this in Basic or NTLM.  Not sure about Digest.  
That's why I proposed Kerberos.

> The protocol mandating that the client close the browser is useless. 
> Yet a protocol timeout would be a mandated equivalent of closing the 
> browser. TCP has this same problem and added TIME_WAIT to resolve it. 
> We are today faced with many complex features of HTTP/1.1 being 
> designed explicitly to avoid the problems it creates (pipelines, 
> keep-alive, chunking, tunnels). Lets not inflict mandatory 
> authentication TIME_WAITs on users when a server makes a mistake and 
> terminates early.

Don't follow you here.  Server can't rely on client to do anything it's 
told.  It has to manage resources, therefore it has to be allowed to 
timeout connections, auth tokens whatever.

Regards

Adrien

---

From: Henrik Nordström <[email-masked]>
Date: Thu, 01 Mar 2012 00:04:49 +0100

> didn't close the browser) doesn't gain access to things they shouldn't.

Yes. Applications need the ability to time out sessions.

Which begs the question, is that auth framework or scheme?

digest auth can already be used in this manner by tracking server
nonce(s) or opaque, and forcing a 401 stale=false response if the
session have been timed out on the server side.

Regards
Henrik

---

From: Henrik Nordström <[email-masked]>
Date: Thu, 01 Mar 2012 00:21:51 +0100

> over the same TCP connection it's pretty simple.

I won't go into this. HTTP is message oriented, not connection oriented.

> processed by itself, or upstream.

Are you talking of transparent intercepting proxies doing NTLM here? If
you do then please stop, that's just happens to work because the
security model of NTLM is plain broken broken allowing it to be abused
in mitm attacks in completely insecure manners. end of discussion.
Please let NTLM die a painful death.

> and leakage shouldn't be a problem.

Even that assumption only holds for basic auth. With anything else it
breaks.

Regards
Henrik

---

From: Adrien de Croy <[email-masked]>
Date: Thu, 01 Mar 2012 13:07:08 +1300

> I won't go into this. HTTP is message oriented, not connection oriented.

I'm not 100% convinced.  Esp with auth.  Even disregarding NTLM, any 
time you have a challenge and response, if the response comes to a 
server over a different TCP connection, then I think a lot of 
implementations will break.  Maybe therefore they are poorly designed.

If for instance multiple proxy clients are multiplexed over a pool of 
connections between the proxy and a server, so that subsequent requests 
on a connection to a server can be for any proxy client, then the 
server's job of maintaining association of credentials, or deciding when 
to issue a challenge is made much more difficult than if it assumes the 
connection is for only 1 user.

Maybe if assuming 1 connection = 1 user is broken, it should be 
explicitly warned about in the spec.  The alternative though is either 
the server has to challenge every request, or the auth tokens submitted 
by clients can be used without round-trips, or some other token needs to 
be stored and looked up by the server in global (i.e. 
non-connection-oriented) memory.  Basic fits there, but does Digest?  
NTLM certainly doesn't of course.

> in mitm attacks in completely insecure manners. end of discussion.

actually any sort of auth when you intercept you no longer know who the 
target is.

> Please let NTLM die a painful death.

It's going to be a very long death.  It's just not going away.  I think 
we will still see significant use of it in 10 years from now.

I'm not even sure how to implement Digest on windows (I've only briefly 
looked), but it looks quite difficult.

Even Negotiate is still connection-oriented?

> Even that assumption only holds for basic auth. With anything else it

ok

So basically the answer remain: "use Digest".

Adrien

---

From: Adrien de Croy <[email-masked]>
Date: Thu, 01 Mar 2012 13:13:01 +1300

NTLM could be made non-connection-oriented if http auth had some sort of 
context attribute that identified the auth conversation (in both 
challenges and responses), instead of having to associate it with the 
connection.

Adrien

On 1/03/2012 1:07 p.m., Adrien de Croy wrote:
> connections between the proxy and a server, so that subsequent 
> requests on a connection to a server can be for any proxy client, then 
> the server's job of maintaining association of credentials, or 
> deciding when to issue a challenge is made much more difficult than if 
> it assumes the connection is for only 1 user.
>
> the server has to challenge every request, or the auth tokens 
> submitted by clients can be used without round-trips, or some other 
> token needs to be stored and looked up by the server in global (i.e. 
> actually any sort of auth when you intercept you no longer know who 
> the target is.
>
> It's going to be a very long death.  It's just not going away.  I 
> think we will still see significant use of it in 10 years from now.
>
> I'm not even sure how to implement Digest on windows (I've only 
> briefly looked), but it looks quite difficult.
>

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 01 Mar 2012 13:19:30 +1300

> session have been timed out on the server side.

Basic auth can do this in a limited way by using a nonce token instead 
of a password. The server rejecting with 401 the old "password" after a 
timeout. Requiring a new random or cyclic one to be sent by the client.

AYJ

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 01 Mar 2012 13:46:49 +1300

On 01.03.2012 13:13, Adrien de Croy wrote:
> NTLM could be made non-connection-oriented if http auth had some sort
> of context attribute that identified the auth conversation (in both

No. That just makes HTTP connection-oriented at the abstract level of 
channels. No change to NTLM.

NTLM would also require dropping the second-stage token exchange 
through the channel its authenticating. Which is effectively Kerberos, 
and also a reason behind Kerberos being preferred for implementation 
instead of NTLM across the WAN.

AYJ

---

From: Henrik Nordström <[email-masked]>
Date: Thu, 01 Mar 2012 01:54:08 +0100

> implementations will break.  Maybe therefore they are poorly designed.

We do have a bit of this problem with digest auth. If the servers do not
have syncronized nonce stores then digest performance degrades
considerably if the client switches server.

> explicitly warned about in the spec.

That assumption is utterly broken. Has always been since HTTP/1.0 added
keep-alive. Not even 100% safe to assume that for https:// these days.

> The alternative though is either 

basic auth is completely stateless on the server side, by nature of
transmitting plaintext login:password in each request.

digest auth requires servers to keep shared state of issued server
nonces to perform well. If not then each time the client lands at a
different server the server will issue a new nonce and the client
automatically retry the request until the client manages to hit the same
server twice in a row. keep-alive helps mitigating this a lot but not
fully.

NTLM is.. well NTLM. Does not fit into anything HTTP terms.

> actually any sort of auth when you intercept you no longer know who the 

You can't do any standard HTTP auth (basic or digest) in intercepting
mode and still have happy users.

> we will still see significant use of it in 10 years from now.

I hope not. Most should be switching to Kerberos via Negotiate now. And
you can't do the transparent intercepting proxy auth trick with
kerberos.

> looked), but it looks quite difficult.

It's not very difficult. But you need to enable it in the domain
controller and reset the password on every account that needs to use
digest auth, and also enable it in IIS obviously.

In theory Windows should even be able to do automatic single sign on
with Digest auth just as it does for NTLM/Kerberos, but I do not think
that's implemented. Never investigated it in detail.

> Even Negotiate is still connection-oriented?

Yes, it's the same breakage HTTP wise as NTLM, but at least a reasonably
secure auth protocol as such if ignoring the mess it does to HTTP.

> So basically the answer remain: "use Digest".

Yes. Digest is the best we currently have in HTTP with some sanity
preserved.

Regards
Henrik

---

From: Adrien de Croy <[email-masked]>
Date: Thu, 01 Mar 2012 13:55:45 +1300

> channels. No change to NTLM.

I disagree.  NTLM works even over UDP.

It's just 3 messages.  There's nothing tying it to a TCP connection 
inside the NTLM protocol.

Sure it's a couple more messages than simple challenge response.  
Normally ends in 3 requests and 2 challenges.  But it could be decoupled 
from the TCP connection.  Subsequent request would just need to be able 
to remind the server which auth conversation they relate to - e.g. 
sending back a token (nonce).  This token could then even be timed out 
by the server.

All the server needs to do to poke the next token into the SSPI is 
resolve the auth context.  A simple map of auth-conversation-token to 
SSPI token would take care of that.  Even allow for things like 
impersonation of client if done properly.

These could conceivably be replayed though, but doesn't Digest suffer 
from that?

> instead of NTLM across the WAN.

NTLM is nothing like Kerberos in terms of crypto etc.

Sure, Kerberos has many advantages.  For instance in SOCKS auth, you can 
do a kerberos auth with 1 message from the client.  That I presume is 
because the ticket is obtained out of band.

Adrien

---

From: Henrik Nordström <[email-masked]>
Date: Thu, 01 Mar 2012 01:58:43 +0100

> challenges and responses), instead of having to associate it with the 

Yes.

Also would have been quite trivial for NTLM/Negotiate to use a hashed
session cookie similar to how Digest operates. NTLM have shared secrets
only known to client & server.

Which is again the question if auth framework should have some kind of
session concept, or if that belongs in the auth scheme.

Regards
Henrik

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 01 Mar 2012 14:05:06 +1300

> explicitly warned about in the spec.

Maybe. Part 1 section 2 goes into a lot of details but seems not to say 
that explicitly anywhere or have any diagram showing connection 
multiplexing.
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-18#section-2

> NTLM certainly doesn't of course.

You have switched from connection==user assumption to 
connection==client assumption mid-sentence.

The difference between client hop-by-hop concept and user end-to-end 
concept is critical to the arguments you seem to be making.

If you look past the optimizations HTTP does require a challenge on 
every request. For www-auth the UA clients optimize the round-trip out 
of existence by holding state about the origins previous challenges and 
sending credentials up front. At no point in the spec does HTTP permit 
intermediaries to use, validate or touch the user-to-origin credentials.
  proxy-auth credentials are specifically and directly hop-by-hop so 
that intermediaries can use them.

> actually any sort of auth when you intercept you no longer know who

When you intercept the target is not you. End of story.
There is no middle ground, the act of interception destroyed it.

> Even Negotiate is still connection-oriented?

Negotiate needs to die as painful a death as NTLM. Long live Kerberos, 
which has hop-by-hop properties and despite its orientation hangup can 
be used almost as easily as Basic or Digest auth given a minimum of 
HTTP/1.1 across all hops.

> So basically the answer remain: "use Digest".

Use something that works hop-by-hop and provides a realm or scoping. 
Digest being the oldest, but Kerberos, and OAuth also meet the criteria.

AYJ

---

From: Adrien de Croy <[email-masked]>
Date: Thu, 01 Mar 2012 14:08:49 +1300

On 1/03/2012 1:58 p.m., Henrik Nordström wrote:
> only known to client&  server.
>

I'd lean towards putting it in the framework.  Then implementation 
issues in underlying auth systems can be resolved independently by 
server / proxy vendors without e.g. requiring changes to the underlying OS.

For instance SSPI which is used for auth on windows servers, only takes 
a single handle to identify the particular conversatioon.  It's finding 
this handle in the absence of any other identifying attribute that I'm 
sure led MS to opt for the connection as the place to store it.  
Probably that plus (in thread per connection model) impersonation 
requirements.

Adrien