Re: Authentication over HTTP

On Mon, Jul 15, 2013 at 1:51 AM, Yoav Nir <ynir@checkpoint.com> wrote:
> On Jul 15, 2013, at 2:15 AM, M Stefan <mstefanro@gmail.com> wrote:
>> As HTTP is fundamentally an old protocol, it has not kept up with
>> the more recent developments in cryptography and security. I believe
>> that a major change in the protocol version should also take into account
>> some security concerns.
>
> Basic and Digest are pretty outdated. There is a working group to deal with this: http://tools.ietf.org/wg/httpauth/

+1.  Please look at the proposals at HTTPauth WG.

>> Not every admin cares about security equally, and for those that,
>> for one reason or another, choose not to use HTTPS, there should be
>> some lighter alternative. It may not have the security guarantees of
>> HTTPS but would still be better than current approaches.
>
> Encrypting stuff and then sending it to someone who may be the intended recipient or may be an attacker makes no sense. Good authentication is way more important than encryption. Unfortunately, it's also much harder.

Well, it made sense to me when we pursued BTNS, with the express
purpose (for me anyways) of using it and RFC5660 to use for channel
binding to application-layer user/service authentication.

The lower in the stack one goes, the less relevant the layer's
identification and authentication capabilities are to the higher
layers.  Paradoxically, the lower in the stack one goes, the easier it
may be for hardware/firmware to provide session cryptography.  That
was the theory for IPsec channels and BTNS.  However, there was no
take-up.

>> According to a very popular train of thought, concerns should be separated,
>> in that security protocols should be built at a lower layer (and therefore be
>> independent) from the HTTP protocol.
>
> Yeah, IPsec is great, TLS is great. But assuming your application supplies different services to different users, the application has to be aware of the user identity. User identity is hard in both IPsec and TLS, so most application opt to do the authentication by themselves. The fact that this pretty much replicates the security properties of HTTP Basic notwithstanding.

We have the following layers: application, HTTP, TLS, IPsec, IP, link, ...

The link layer doesn't help, and neither does IP.  IPsec doesn't
either in practice, though it could if by some miracle we got the
pieces in place to use it.

TLS is still too low a layer: there may be a world of caching and
routing proxies between the server-side end-point of the TLS
connection and the actual service, and the service might be spread
over many nodes.  At the very least we'd need to standardize how the
services and TLS are to interact.

That leaves two layers as useful for authentication: HTTP and the
application layer.  HTTP is closer to TLS in the architecture than to
the application layer, therefore we have roughly the same problems as
with TLS.

That leaves only the application layer as the best suited for
authentication of identities (and/or resolution to attributes) that
the service needs for authorization (or even in the other direction).
This, I know, is a bit of a controversial opinion.  My proposal is
here: http://tools.ietf.org/html/draft-williams-http-rest-auth-01
(ah, I need to submit the WG version).

>> As tempting as it sounds to fragment components into smaller ones as much
>> as possible, I believe that a protocol that has the popularity of
>> HTTP must address this concerns itself. To find evidence of this fact,
>> you don't have to look very far. Simply observe how many websites currently
>> send your log in password as plain text. Even IMAP has STARTTLS.
>
> They do that because a form gives the designers more control over the user experience than using any facilities within HTTP. That is something I'm afraid the http-auth working group will not be able to solve, regardless of all the cool crypto that they might add.

My proposal (RESTauth) is not incompatible with application-defined
UIs, but it does constrain things a bit so that the application cannot
get access to raw credentials that it must not have access to.

> Note also that form-based login can never be more secure than that. I've seen forms that use Javascript to encrypt the password with an RSA key from the server. But those forms are visually indistinguishable from forms that send the password in the clear. So unless we expect the users to read the javascript before entering their password, they will be duped by a look-alike form from an attacker.

Right!

>> One could also claim that there is no way to have a great deal of security
>> without the web host owning a trusted (signed) certificate. While this may
>> be true, some security guarantees can still be made even in the absence
>> of such a certificate. It makes no sense to believe that "some security" is
>> just as bad as "no security".
>
> Disagree. Some security guarantees are not necessarily the security guarantees that matter, and to me it's far more important to know that I'm talking to the correct server than knowing that my traffic is encrypted en route.

A zero-knowledge proof protocol can certainly get by without a server
certificate.

The problem with ZKPPs is that they don't scale: they require
pair-wise shared secrets.  The standard answer to this in the past has
been Kerberos, but now the new cool kids on the block are BrowserID
(roughly: an online CA that pre-authenticates users however it wishes,
and issues short-lived certs) and ABFAB (roughly: based on EAP +
RADIUS + SAML).

>> For instance, an EKE (encrypted key exchange) mechanism could be embedded in HTTP2.0 for
>> [...]

See http://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual/

See also my comments above about scalability of ZKPPs.

Nico
--

Received on Tuesday, 16 July 2013 06:24:43 UTC