Re: Authentication and TCP Connection State

On 6 October 2014 05:37, Michael B Allen <ioplex@gmail.com> wrote:
> And BTW I never said anything about NTLM. I don't know why everyone
> keeps mentioning it like it's THE problem. I'm not concerned with
> NTLM. I have a generic "Security Provider" API. So I will just
> implement whatever gets the job done. I pretty much have Kerberos 5
> provider but I don't feel the pressure to roll it out because right
> now, performance wise, NTLM is kickn' ass. And AFAIK it is secure if
> NTLMv2 is used and there's no hijacked proxy in between.
>
> My concern is with what will *replace* NTLM?
>
> It's not obvious to me that "stateless authentication" is really
> possible in practice.
>
> Digest only works because it carries the nonce with it and that is a
> pretty significiant constraint on the authentication mechanism itself.
>
> Kerberos only works because it's not actually doing a complete
> authentication - only a "ticket" is submitted.
>
> NTLM will break with HTTP 2.

NTLM is entirely broken with HTTP/1.x - I say this as one of the
primary authors in Squid of the pluggable authentication framework,
and the ntlm module we wrote at the same time. We had to do bizarre
things to tunnel ntlm properly through the core of Squid. As Amos said
- all the features of HTTP/1.x that were concerned with performance
improvements are turned off when NTLM is detected. And subsequently to
that folk(I forget who, but I want to say Henrik Nordstrom) added
logic to turn Squid into little more than a TCP proxy when NTLM is
detected from an origin server: we stop multiplexing requests from
different clients onto one server connection.

HTTP + NTLM != HTTP. It is TCP with a vague resemblence to HTTP. And
when it works on the internet its just damn luck. Country wide
intercepting proxies (e.g. Thailand, New Zealand), and firewalls
(China and perhaps more) play havoc with it.

> I don't know much about PKI / HTTP authentication methods but it
> sounds like it's effectively what Kerberos is doing.
>
> So there is no stateless complete HTTP-only authentication mechanism
> in existence today that will work with HTTP 2.

The exact same hacks that made NTLM work can be done with HTTP/2:
refuse to carry traffic for multiple users, authenticate the TCP
connection, serialise all request processing until authentication is
complete.

I'm sure that Microsoft will have little choice, given backwards
compatibility concerns, but I for one would be delighted if they were
to sunset all the non-Kerberos tunnelled authentications schemes in
their HTTP/2 support, and find a good way to do tickets per request.
(Perhaps a very short lifespan limited-use ticket with less bits in
it).

Transport security + an appropriately sized bearer token would be a lot saner.

> I'm just saying - the whole "stateless authentication" thing is a
> little dubious. The Auth-ID will need to be routed back to the server
> that issued it.

So Auth-ID is from the "Multi-legged Authentication for HTTP
Multiplexing" draft - its not part of HTTP yet, and I suspect a great
deal of work is needed to sanely support that - I've just re-read it
and its got  (IMHO) holes you could drive a bus through. [Such as
Auth-ID being redundant with the persistent-auth marker,  the failure
to reconcile the impedance mismatch between request and connection
authentication, and permitting some auth schemes to be 'well known as
session based' which pushes complexity onto proxies - they have to be
updated for every scheme that has that characteristic even if the
proxy is only forwarding traffic, not doing the authentication itself.

Digest works today, even in AD environments - enterprises
(http://msdn.microsoft.com/en-us/library/aa292114(v=vs.71).aspx) -
though they claim it is replayable which says to me that the IIS
implementation isn't handling nonces correctly. But the big issue is
this: "Note   After configuring Active Directory to store passwords
using reversible encryption, all users must change their passwords for
Active Directory to store each password in this manner." - which I
expect to freak out every sysadmin on the planet - both because of the
reversible encryption (which digest doesn't actually require - though
you are sharply limited on the encryption possible) and because of the
need to reset every users password.

SCRAM is better but suffers from exchanging the salt in clear text,
which is where its dependency on transport layer security comes in.
Sadly it seems designed to encourage the use of channel binding, which
is precisely as hostile to HTTP as NTLM and SPNEGO were. Any HTTP/2
forward proxy will result in channel binding failing. And - unless MS
integrate SCRAM into AD+IIS, enterprises will still likely prefer
kerberos - SSO is a powerful thing.

If I may suggest, working with MS on per-request kerberos based auth
is probably the single most useful thing to do to encourage HTTP/2
adoption in the enterprise.

-Rob


-- 
Robert Collins <rbtcollins@hp.com>
Distinguished Technologist
HP Converged Cloud

Received on Sunday, 5 October 2014 18:51:49 UTC