Re: HTTP2 Expression of Interest

[Phillip Hallam-Baker <[e-mail]>]

+1

Also note that the major constraint on the design of DIGEST was that
it had to be open and unencumbered which meant not using RSA or
Diffie-Hellman at the time.

We knew better at the time we made the original proposal. The problem
was that we could not do things the way we wanted.

The KGB has an interesting doctrine, every message has to be secured
by two independent mechanisms that have to independently provide for
complete protection of the message based on different principles. [As
a result they ended up killing a few dozen cipher clerks with ionizing
radiation generators in their enclosures prompting the defection of
one of their top crypto people. But that is another issue]

What I am saying is that adding security at the HTTP layer is really
orthogonal to the need for TLS or not. More to the point, even if we
got rid of TLS there would still be a need to authenticate servers and
thus a need for some form of open authentication infrastructure for
servers which means a CA-like entity.


If you want HTTP messages to tunnel through proxies then you are going
to need to be realistic about the practicality of securing headers. If
you don't need that capability (and I haven't used a proxy
intentionally for 15 years) then you can be more aggressive.

If we want to secure anything more than the content in HTTP 2.0 then
we probably need to think about ways to separate out headers that are
content metadata and thus should be inside the security envelope from
routing headers which ain't.

On Fri, Jul 13, 2012 at 3:31 PM, Paul Leach <[e-mail]> wrote:
> 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:[e-mail]]
> Sent: Thursday, July 12, 2012 10:37 PM
> To: Nico Williams
> Cc: Paul Hoffman; [e-mail]
> 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:[e-mail] the same user that other sites accept as acct:[e-mail]
>
>
> 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 <[e-mail]> wrote:
>> On Thu, Jul 12, 2012 at 9:22 PM, Paul Hoffman <[e-mail]> 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/
>
>
>



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