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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




I wonder if it would be helpful for people to outline what they expect are the issues to be solved by doing more work on an HTTP auth mechanism.

I get the feeling that some think the scope would encompass providing auth support for web applications, whereas others are mainly concerned with the transport level auth.

IMO http auth is not particularly suited to solve the issues required for web site authors, for the simple issue of administrative boundaries and realms of accounts.

For example the web server that sits on an OS that has 1 user database, yet hosts 10 web sites each of which require their own independent user database, and require the ability to create and destroy accounts, and these accounts NOT be OS ones (i.e. not grant any access to the OS). Sure these issues could be engineered around, but it would add to the current scope (for change) every web application that currently manages accounts (a great deal of them).

If we're just talking about transport auth, then what's wrong with something like kerberos. As for server logging a client out, the auth mechanism would need a token that can be revoked by the server, since one cannot rely on client co-operation in such a matter. A kerberos ticket seems to fit this bill. then we'd just need a mechanism for a client to request revokation (logout). It is also AFAIK supported on all server platforms, unlike any auth mechanism that requires access to plaintext passwords at the server end - these are not always available.

Adrien


On 26/02/2012 3:03 a.m., Julian Reschke wrote:
On 2012-02-25 14:46, Stephen Farrell wrote:
...
Yeah that's a tricky one. While one might like to
see "one or more" in both places that might not be
practical.

In the proposal above the goal is that httpbis pick one
or more but recognising the reality that we might not get
a new proposal that httpbis will accept and that folks
will really implement and deploy.

So:
Goal = one or more
Reluctant recognition of reality = zero or more

With this plan if httpbis in fact select zero new proposals
that would represent a failure for all concerned. The "zero
or more" term is absolutely not intended to provide a way to
just punt on the question.

Such a failure at the point where httpbis was re-chartering
to work on a HTTP/2.0 selection with no better security than
we now have is probably better evaluated as a whole - I
guess the question for the IETF/IESG at that point would
be whether the Internet would be better with or without
such a beast, or better waiting a while until the security
thing did get fixed.

I can imagine an argument might ensue about that;-)
...

If we just need a new authentication scheme, nothing stops people from working on that right now. I don't see how that should affect HTTP/2.0.

If the "right" way to do security needs changes in the HTTP/1.1 authentication framework, then we should fix/augment/tune HTTP/1.1. It's not going to go away anytime soon.

Best regards, Julian


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

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]