17, 2006, at 5:38 PM, Robert Sayre wrote:
Does anyone think mandatory-to-implement authentication schemes or
transport-layer security mechanisms will be helpful and realistic?

Not without changing the HTTP version number, but I suppose that
I shouldn't assume that is obvious. HTTP/1.1 has already been
deployed and I have no interest in declaring any of those
implementations broken just because they failed to anticipate a
not-yet-specified secure auth mechanism. That ship has sailed.

So, if anyone thinks that a secure authentication scheme is a cool
thing, they should propose one and eventually update RFC 2617 to
include it, at which point it will be an PTINAL secure auth
mechanism for HTTP/1.1 (without any need to change RFC 2616).
The only way to make it a REQUIRED secure auth mechanism for HTTP
is to move on to HTTP/1.2, at which point we open the flood gates.

Roy

Roy T. Fielding wrote:

17, 2006, at 5:38 PM, Robert Sayre wrote:
>Does anyone think mandatory-to-implement authentication schemes or
>transport-layer security mechanisms will be helpful and realistic?

Not without changing the HTTP version number, but I suppose that
I shouldn't assume that is obvious. HTTP/1.1 has already been
deployed and I have no interest in declaring any of those
implementations broken just because they failed to anticipate a
not-yet-specified secure auth mechanism. That ship has sailed.

So, if anyone thinks that a secure authentication scheme is a cool
thing, they should propose one and eventually update RFC 2617 to
include it, at which point it will be an PTINAL secure auth
mechanism for HTTP/1.1 (without any need to change RFC 2616).
The only way to make it a REQUIRED secure auth mechanism for HTTP
is to move on to HTTP/1.2, at which point we open the flood gates.

Roy

Thanks, Roy.

I think that makes it clear that a revision of HTTP/1.1 can't make that
change, unless all existing implementations already comply to these new
requirements (which they don't).

Best regards, Julian

Robert, Roy,

Does anyone think mandatory-to-implement authentication schemes or
transport-layer security mechanisms will be helpful and realistic?

Not without changing the HTTP version number, but I suppose that
I shouldn't assume that is obvious. HTTP/1.1 has already been
deployed and I have no interest in declaring any of those
implementations broken just because they failed to anticipate a
not-yet-specified secure auth mechanism. That ship has sailed.

So, if anyone thinks that a secure authentication scheme is a cool
thing, they should propose one and eventually update RFC 2617 to
include it, at which point it will be an PTINAL secure auth
mechanism for HTTP/1.1 (without any need to change RFC 2616).
The only way to make it a REQUIRED secure auth mechanism for HTTP
is to move on to HTTP/1.2, at which point we open the flood gates.
I would agree that it is in fact a bad idea to require
the implementation of any mandatory authentication scheme
within the core protocol definition.
There are applications where a server may want to implement
only the smallest subset of the protocol, remaining still
conforming but without the need for authentication (e.g.
high-performance static-content servers like a typical
"image" or "media" server used and tuned to deliver high
volume static data).
This is what Paul Leach points out:
"so much of HTTP access is legitimately anonymous"

The strategy of making any authentication scheme optional
and moving the detailed specification out to a different
standards track seems to be quite an eligible feature of
http/1.1 and I consider it a major improvement over http/1.0
doing this.

From that point of view and imho the only viable way to
grind out interoperable and "acceptable" authentication
schemes would be to establish them apart from the core
protocol and "heal the wounds" of existing schemes (be
they widely deployed or not) in-place.

The only requirements that could be tied down to the core
protocol are things NT to do, the most important being not
to use plain-text password transmission, thus dropping the
"compatibility to http/1.0" which is not near to being
considered as a standard anyway.
A formulation within an updated http/1.1 document could be
that a conforming server implementation MUST NT use the
Basic auth scheme (or equally weak schemes), while clients
MAY support it, but if they do they MUST warn the user
decidedly -- if this seems to be too restrictive a SHULD NT
could still suffice.

From a practical point of view this could be done, because
it is easy for a server implementation to drop an existing
feature. It should be done, because it poses an unacceptable
risk if used over unencrypted connections, which is quite
common habit.

As for rfc2617 I still consider it feasible to "fix" it in
the sense of replacing it with a document that tightens the
requirements, clarifies the ambiguous parts and drops the
unused or unusable parts while sticking to the mechanisms that
are widely implemented and could not be expected to be changed
without major updates of existing implementations.

Kind regards

Ingo Struck

ons 2006-10-18 klockan 09:24 +0000 skrev Ingo Struck:

A formulation within an updated http/1.1 document could be
that a conforming server implementation MUST NT use the
Basic auth scheme (or equally weak schemes), while clients
MAY support it, but if they do they MUST warn the user
decidedly -- if this seems to be too restrictive a SHULD NT
could still suffice.

I would add "without adequate transport level security" to the above.

Exchanges of plain-text passwords is often required for interoperability
reasons far beyond the HTTP protocol as such. In very many applications
the server simply MUST know the plain-text password of the user.

The main reason why Digest auth hasn't been widely deployed and most
still using Basic is because of these reasons. There is not very much as
such wrong with Digest auth even if there is areas which can be improved
(and many broken implementations), but in practice it's often completely
useless as the backend systems doesn't support Digest auth, only other
proprietary authentication protocols or plain text.

Quite recently there was a standardisation effort which have brought
Digest auth a bit closer to something deployable by extending RADIUS
with Digest auth support. Hopefully this will make Digest a more
available alternative.

Regards
Henrik

PGP SIGNATURE
Version: GnuPG v1.4.5 (GNU/Linux)

lmIjBrpGTJib0kTbEDMYMfo=
=ht0V
PGP SIGNATURE

17, 2006, at 7:30 PM, Roy T. Fielding wrote:

17, 2006, at 5:38 PM, Robert Sayre wrote:
>Does anyone think mandatory-to-implement authentication schemes or
>transport-layer security mechanisms will be helpful and realistic?
>
Not without changing the HTTP version number, but I suppose that
I shouldn't assume that is obvious. HTTP/1.1 has already been
deployed and I have no interest in declaring any of those
implementations broken just because they failed to anticipate a
not-yet-specified secure auth mechanism. That ship has sailed.

Not only is that not obvious, I'm not sure it's true. Publishing a
new RFC is not a declaration that implementations of previous RFCs
are broken. Nobody expects functioning crystal balls. Changing a
version number is a choice that's subject to all kinds of
consideration and judgement, rather than a choice that's subject to
hard-and-fast rules. (Even if there were rules/guidelines in a given
spec about when a version number should change, future protocol
authors might find good reasons to violate those, and HTTP has little
or no such guidelines.)

What's the utility of a version number in HTTP? This is helpful as
an explanation of the last change in number:
"the proliferation of incompletely-implemented
applications calling themselves "HTTP/1.0" has necessitated a
protocol version change in order for two communicating applications
to determine each other's true capabilities."

and
" No change is made to the version
number for the addition of message components which do not affect
communication behavior or which only add to extensible field
values."

So I guess a decision that CLIENTS MUST support Basic and Digest in a
new HTTP RFC, might be signalled by a minor version bump. The
version bump could signal that support along with a bundle of other
capabilities if necessary. The server can use that information to
change its behavior and work better with that client. My personal
opinion on that is it's probably not of sufficient usefulness for the
disruption it would cause -- unless the bundle overall were more than
just auth improvements -- because servers can already send auth
challenges prompting the client to use Digest if it can. But if a WG
were to decide it was worthwhile, then that would be fine and
reasonable.

But a decision that SERVERS MUST support Basic and Digest -- well
that doesn't need a version bump at all to work. We already have a
way for servers to advertise support insofar as that's necessary for
those algorithms.

Lisa

r 2006-11-04 klockan 10:47 -0800 skrev Lisa Dusseault:

So I guess a decision that CLIENTS MUST support Basic and Digest in a
new HTTP RFC, might be signalled by a minor version bump.

I too don't see thy a version bump would even be remotely needed in this
case. It's already the server who dictates which authentication
protocols is acceptable to the server, the client just selects what it
thinks is best among the available choices. If there is no match
communication is not possible, such as would be the case for a resource
requiring strong secure authentication.

The change to require support for strong authentication is not a
technical change, it's a administrative policy change. The protocol
isn't changed by this, only how the protocol may be applied.

HTTP version numbers do have an implicit defined meaning:

- Minor numbers signify a change in transport related features, but
keeping the basic message format and meanings of headers intact.

- Major numbers signify a change in message format, incompatible with
earlier versions. For example if the header format is changed, or if
already well defined headers is redefined to another meaning.

Also remember that HTTP message numbers are hop-by-hop, while most
headers describing capabilities such as authentication requirements is
end-to-end.

Regards
enrik

PGP SIGNATURE
Version: GnuPG v1.4.5 (GNU/Linux)

82EC1tTGRHNzSACI=
=nXxN
PGP SIGNATURE

Am 04.11.2006 um 21:16 schrieb Robert Sayre:

11/4/06, Robert Sayre <sayrer (AT) gmail (DOT) comwrote:
>"An HTTP client MUST NT send a version for which it is not at least
>conditionally compliant.'
>>
>
Sorry, that's from RFC 2145. The send button was clicked a bit
early. :)

In any case, the requirements and semantics of HTTP version numbers
seem clear as a bell to me. I don't see any interpretation that allows
something as radical as the addition of a mandatory security mechanism
without incrementing the version number.

+1.

And besides, I fail to see what shall be accomplished here. I get the
feeling that people think that waving the magic wand of specification
revisions will instantaneously change the world around them. It will
not.

If the spec would be changed in this way, all a reasonable server
could deduce from a HTTP/1.1 request is that the client *may*
implement the now mandatory to implement authentication schemes. That
seems a bit thin a gain compared to the current situation, e.g. the
server can assume that the client *may* implement basic and digest.

//Stefan

Lisa Dusseault wrote:

So I guess a decision that CLIENTS MUST support Basic and Digest in a
new HTTP RFC, might be signalled by a minor version bump.[]

But a decision that SERVERS MUST support Basic and Digest -- well that
doesn't need a version bump at all to work. We already have a way for
servers to advertise support insofar as that's necessary for those
algorithms.

This doesn't parse - it would immediately break a massive number of web
applications, much as microsoft recently did in the IE client 'security'
patches through their re-PST of failed PST requests sans-request-body.
Requirements even on the server side can't realistically be altered
within the confines of HTTP/1.0 /1.1.

The only answer is to remove Basic for HTTP/1.2 or /2.0 in the future
revision of the spec as a fundamentally broken mechanism, much as the
HTTP/1.1 spec introduced manditory Host headers to force all browsers
over to mass vhosting by-name.

Bill

Lisa, Robert,

"An HTTP client MUST NT send a version for which it is not at least
conditionally compliant.'

Sorry, that's from RFC 2145. The send button was clicked a bit early. :)

In any case, the requirements and semantics of HTTP version numbers
seem clear as a bell to me. I don't see any interpretation that allows
something as radical as the addition of a mandatory security mechanism
without incrementing the version number.
Agreed -- just like indicated in my email from 2006-10-18:
there is no reasonable way to add mandatory requirements
without changing version numbers or breaking conformance
of existing implementations (regardless whether server or client).
imho to drop to require broken legacy stuff (basic auth) seems
feasible, to add to require the impl of any mandatory auth scheme
seems not.
Moreover I would consider the introduction of such a requirement
a regression due to the existence of applications with
"legitimately anonymous" usage of http (see my aforementioned mail
to the wg list).

Kind regards

Ingo Struck

r 2006-11-04 klockan 14:59 -0500 skrev Robert Sayre:

An HTTP/1.1 message is not a guarantee that the sender supports any
authentication mechanism. Servers receiving a hypothetical HTTP/1.2
message could make that assumption.

Neither is a HTTP/1.2 message as it says nothing about what protocol
version the client supports, only the protocol version of the last hop.

Attacking this via protocol version numbers is not the correct approach.
It's done by advertising the support in a header which is the only
end-to-end concept there is in HTTP.

Making the use of a new header mandatory does not require a new protocol
version, just a new standard strack RFC defining the header as
mandatory.

Bumping the protocol version simplifies compliance specifications as it
becomes sufficient to say one is compliant with HTTP/X.Y instead of a
list of RFCs.

Any major changes in the protocol such as moving away from being a
message based protocol to being a connection oriented protocol would
require a major version bump.

Any change in message format on the hop-by-hop level such as the
introduction of something on the same level a Connect header or a
another transfer-encoding model would require a minor version bump. So
does changing the requirements on how trailers may be used to a must.

Regards
Henrik

PGP SIGNATURE
Version: GnuPG v1.4.5 (GNU/Linux)

l3614HlJnsSdsiRoy1HGJZo=
=ky2Y
PGP SIGNATURE

r 2006-11-04 klockan 17:07 -0500 skrev Robert Sayre:

A new RFC can make a header mandatory for RFCNNNN compliance, but not
HTTP/1.1 compliance.

Exacly what I said.

Regards
Henrik

PGP SIGNATURE
Version: GnuPG v1.4.5 (GNU/Linux)

EHssjEpULSmfAU=
=uvh9
PGP SIGNATURE

r 2006-11-04 klockan 17:27 -0500 skrev Robert Sayre:
11/4/06, Henrik Nordstrom <hno (AT) squid-cache (DOT) orgwrote:
r 2006-11-04 klockan 17:07 -0500 skrev Robert Sayre:

A new RFC can make a header mandatory for RFCNNNN compliance, but not
HTTP/1.1 compliance.

Exacly what I said.

K. Then I submit that such an RFC cannot claim to define HTTP/1.1.

Agreed. It's at most an standards track extension to HTTP/1.1.

Also for the record I am against that implementation of strong
authentication should be mandatory for HTTP protocol compliance.

A requirement of implementation of a well defined strong authentication
scheme IF authentication is implemented is fine however.

Regards
Henrik

PGP SIGNATURE
Version: GnuPG v1.4.5 (GNU/Linux)

kZmi+HQL8WVdieBlPgvIAl0=
=ibs6
PGP SIGNATURE

lists (AT) ingostruck (DOT) de schrieb:
Lisa, Robert,

"An HTTP client MUST NT send a version for which it is not at least
conditionally compliant.'
>Sorry, that's from RFC 2145. The send button was clicked a bit early. :)
>>
>In any case, the requirements and semantics of HTTP version numbers
>seem clear as a bell to me. I don't see any interpretation that allows
>something as radical as the addition of a mandatory security mechanism
>without incrementing the version number.
Agreed -- just like indicated in my email from 2006-10-18:
there is no reasonable way to add mandatory requirements
without changing version numbers or breaking conformance
of existing implementations (regardless whether server or client).

unless it could be demonstrated that in practice all implementation
already are compliant to that new requirement (which I doubt is going to
happen :-).

imho to drop to require broken legacy stuff (basic auth) seems
feasible, to add to require the impl of any mandatory auth scheme
seems not.

Yep.

HTTP/1.1 is widely deployed. Changing the mandatory requirements so that
existing compliant implementations become non-compliant just doesn't
compute.

Best regards, Julian