Re: Authentication over HTTP

On 18/07/2013 6:00 a.m., Nico Williams wrote:
> On Wed, Jul 17, 2013 at 12:59 AM, Amos Jeffries <squid3@treenet.co.nz> wrote:
>> On 17/07/2013 5:34 a.m., Nico Williams wrote:
>>> On Tue, Jul 16, 2013 at 7:54 AM, Amos Jeffries <squid3@treenet.co.nz>
>>> wrote:
>>>> *Every single claim* that HTTP-auth is broken and needs re-designing
>>>> seems
>>>> to me to be based on the flawed assumption that HTTP-auth is not
>>>> extensible
>>>> and that the common existing schemes are the only ones HTTP permits. Or
>>>> that
>>>> somehow a user authenticating with N different and fragile mechanisms for
>>>> one transaction is a good thing (I rather disagree, the UX on that would
>>>> be
>>>> tricky and implementation nightmares).
>>> That's either a strawman or you misunderstood the arguments against
>>> doing authentication in HTTP.  It's not that "HTTP auth is broken",
>>> but that HTTP is the *wrong layer* -- that's not because HTTP or HTTP
>>> auth is broken, but because properties of the stack of protocols
>>> spoken make HTTP auth a problematic proposition.
>>>
>>> BTW, I've not see any arguments about N different mechanisms (fragile
>>> or not) being a problem.
>> Maybe I have been misunderstanding some of them. But the auth proposals I've
>> seen in the last few years all seem to fall into three brackets with regards
>> to their claims about HTTP:
> But you don't even list here the argument you listed above, nor give
> examples.  Why argue about this anyways?  You and I seem to agree:
>
>> 1) "HTTP auth is broken". Aka "do it all in payload entities and have HTTP
>> endpoints interpret those" ... well so what? payload format is not HTTP.
>> Good luck but go away and do it at a different layer.
> Yes, do it at a different layer: that's my answer.
>
>> 2) "HTTP auth is broken". Aka the headers dont let me login user X to proxy
>> A and proxy B at the same time, in the same chain, with different
>> credentials all controlled by user X ... seem to be making a few wrong
>> assumptions about how HTTP works there. Go away and do (1) instead the
>> user-application ha sa lot more control over end-to-end pathways in
>> application layer.
> Oh, I'd never seen this argument.  This is an interesting one because
> authentication to proxies is very interesting.  So this one is
> definitely a legitimate argument, and one I would make.  Also, this
> means I have to think about proxy auth for RESTauth (well, it's
> straightforward, but I have to add it).  This is very helpful, thanks!

The answr may surprise you. HTTP *already* provides teh necessary 
mechanism to do auth like that...

HTTP as a protocol offers no such thing as a NEXTHOP routing method, so 
the only way for a user to exactly specify that proxy-A is to relay the 
request to proxy-B (and not elsewhere) is for the user to send CONNECT. 
A CONNECT to proxy-A carries the credentials for proxy-auth on A, and 
the traffic inside be HTTP or HTTPS to proxy-B with proxy-auth 
credentials to the proxy B. CONNECT like that can be layered arbitrarily 
deep and sent between any two hops in the chain for arbitrary 
hopX-to-hopY auth credential delivery. Also, if one were to spec a 
NEXTHOP equivalent method, it would have to work very similarly to CONNECT.

I dont see anything particularly broken broken about the HTTP layer in 
the above, but that does not seem to stop proposals for new features to 
duplicate the ability. Most proposals seems  to be more driven by 
implementations application-layer lack of functionality than HTTP itself.

>
>> 3) "HTTP auth is broken". Aka its missing a scheme to do mechanism Z ... and
>> we do see these followed by specs to do Z in HTTP. But none of them are
>> exactly replacing the existing HTTP mechanism design, just extending it as
>> it was intended to be extended.
>>
>> What am I missing?
> At least the argument you'd made above:
>
>>>> *Every single claim* that HTTP-auth is broken and needs re-designing
>>>> seems
>>>> to me to be based on the flawed assumption that HTTP-auth is not
>>>> extensible
>>>> and that the common existing schemes are the only ones HTTP permits. Or
>>>> that
>>>> somehow a user authenticating with N different and fragile mechanisms for
>>>> one transaction is a good thing (I rather disagree, the UX on that would
>>>> be
>>>> tricky and implementation nightmares).
> I've never seen that argument.


For Yoav, by "fragile" I mean that each auth layer may fail to 
authenticate successfully, or have some implementation flaw. The more 
you add into one transaction the more reasons it has to error out and 
break the UX. Breaking the UX when error do happen is the right thing 
IMO, but having so many ways to hit errors in the first place is the 
problem.
  The existing HTTP auth header features/mechanism and methods seem to 
be able to cope with almost everything the HTTP layer specifically needs 
to cope with.

NOTE: The one niche use-case I have not been able to find clean 
algorithms for that work within existing HTTP semantics and applicatino 
layer logics. That case is automated logout between two proxies in the 
middle of a chain which have logged in automatically and independently 
of any user being aware of the login happening (thus no UA logout button 
possibility). That one still seems to require connection tear-down. 
Although that said, I've not seen it requested by anyone either.

Amos

Received on Thursday, 18 July 2013 00:37:08 UTC