RE: HTTP2 Expression of Interest

I'd like to quibble a little with the description of the "authentication activities"; they all have the same flaw which can be illustrated by a proposed modification to the first one:

	CREDENTIAL-Authentication: Is this the user _who sent this HTTP request_ and claiming to be the owner of account 'X' the same user who was issued account 'X'?

Why is the change necessary? Because one of the biggest problems with current security mechanisms at the HTTP layer is that there is very little binding between the identity of the user making the connection and the request coming over the connection. None of the existing in use mechanisms except Digest even tries, and Digest usually only binds the request URI and method of the request to the authenticated identity. As a result, any MITM can almost completely change the request, so that knowledge of who sent the Authentication header is basically irrelevant if real security is needed.

As a further result, the only time that HTTP layer authentication has any real security value is when it is tunneled inside of TLS, and _has its channel bound_ to the authentication.

Note that Digest also (in a less-used feature) has a way to bind the request body and the response body to the identity of the requesting user. Unfortunately, it doesn't bind the rest of request and response headers; that's because proxy servers are allowed to rearrange them, and coming up with a canonical form that allowed for that seemed intractable. Also, Digest doesn't support chunked encoding, so that very large or indefinite length entity bodies are at best problematic. 

Also note that Digest has an "MD5-sess" mode that provides for the "RE-authentication" mode that Phillip defines.

(The biggest problem with Digest is that the construction of the keys it uses from the password does not specify how to handle any character set other than ASCII. I was clueless about that in those days.)


-----Original Message-----
From: Phillip Hallam-Baker [mailto:hallam@gmail.com] 
Sent: Thursday, July 12, 2012 10:37 PM
To: Nico Williams
Cc: Paul Hoffman; ietf-http-wg@w3.org
Subject: Re: HTTP2 Expression of Interest

I really dislike the idea of having a platform inside a platform

TLS is way too big for comfort. GSSAPI has mechanism on mechanism.


I don't want a choice of fifty ways to authenticate. I want exactly one mechanism to support each type of authentication. I certainly don't want a choice of crypto protocols to verify passwords. In fact I don't want passwords to be flowing over the net at all. The proper use of a password is to unlock the user's credential on their authentication device.

SAML and OAUTH and the rest already define an interaction with HTTP.
If we want to adopt those as mechanisms we should adopt them directly into HTTP and not introduce a platform step.

But even there we should not accept the whole of either spec. Much of the argument in SAML went into the design of a mechanism that could be used with legacy Web browsers. Same for OAUTH. Now it will certainly be necessary to consider how we transition to HTTP 2.0 but I would want to jettison the entire transition structure once we get there.


But really we have a much smaller set of concerns. In particular we should distinguish between the different things that are called 'authentication' and we should not incorporate any mechanism into the spec that is incompletely specified. By which I mean relying on out of band configuration or exchange of credentials.

Specifically we have the following activities that are all known as
'authentication':

CREDENTIAL-Authentication Is this the user claiming to be the owner of account 'X' the same user who was issuedaccount 'X'

RE-Authentication: Is this the same user that authenticated previously?

FED-Authentication: Is the user claiming to be acct:user@example.com the same user that other sites accept as acct:user@example.com


Now credential authentication is a strict subset of the federated case so it may not be desirable to distinguish the two on an ongoing basis but RE-Authentication is something rather different.



On Fri, Jul 13, 2012 at 1:16 AM, Nico Williams <nico@cryptonector.com> wrote:
> On Thu, Jul 12, 2012 at 9:22 PM, Paul Hoffman <paul.hoffman@gmail.com> wrote:
>> draft-williams-rest-gss relies on GSSAPI, which has thin adoption 
>> even after many years. [...]
>
> If you consider that the SSPI is very similar to the GSS-API, and 
> wire-compatible with it anyways, then that assertion is quite clearly 
> incorrect.  SSPI is extremely widely used, both in proprietary 
> application protocols and standard ones (including TLS, since SSPI is 
> the interface to TLS in Windows).
>
> The GSS-API has had a dearth of mechanisms for it deployed, but this 
> is beginning to change.  We now have all of these standardized and/or
> deployed:
>
>  - Kerberos (including IAKERB)
>  - GSS-EAP (see ABFAB WG)
>  - SCRAM
>  - Microsoft's PKU2U (PKI, based on Kerberos w/ PKINIT)
>  - the GSI mechanism that is really just TLS repackaged as GSS
>
>    (See again how SSPI is the interface to TLS in Windows.
>     It's also the interface to SASL.)
>
>  - OAuth and SAML-based mechanisms are in the works as well.
>
> It's easy enough to add new GSS-API mechanisms, but between GSS-EAP, 
> Kerberos (particularly with trust routing and bootstrapping 
> enhancements), PKU2U, OAuth, and SAML I think we have most needs 
> covered.  A ZKPP mechanism or three should be added, but unless that's 
> done in a way that federates then I think it's best to make sure that 
> GSS-EAP can use ZKPP EAP methods and Kerberos can use ZKPP 
> pre-authentication mechanisms.
>
> The biggest Internet protocol users of the GSS-API are SSHv2 (yes, 
> really, SSHv2 w/ GSS and Kerberos is widely deployed in corporate 
> networks), LDAP (see again Windows), and NFS.  But also IMAP (see 
> Exchange), DNS (GSS-TSIG, see Active Directory and Windows) and 
> others.  There's also widely deployed non-Internet standards-track 
> protocols, such as SMB, as well as many proprietary protocols.  And 
> then there's HTTP/Negotiate -- how could I forget!  (though to be sure 
> I don't really like HTTP/Negotiate, otherwise I might just have 
> proposed that.)
>
> Nico
> --
>



--
Website: http://hallambaker.com/

Received on Friday, 13 July 2012 19:32:03 UTC