Re: HTTP2 Expression of Interest

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

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/