On Tue, Dec 14, 2010 at 03:47:55PM -0600, Marsh Ray wrote:
> On 12/14/2010 02:56 PM, Nicolas Williams wrote:
> >Well, let's see, we have:
> >
> >  - HTTPS with user certs.
> >
> >    Not used because... people tend to put useful information in user
> >    certs, and independently tend to need multiple validation paths,
> >    resulting in a multiplicity of certs, resulting in difficulty
> >    selecting one credential or another in any given context.  End
> >    result: ick.
> 
> Another is perhaps browsers are unwilling to authenticate with a
> client cert that they can't validate themselves. Which effectively
> means a browser has to trust the site's custom CA, or the site has
> to get its users into some kind of a commercial arrangement. Not
> very flexible.
> 
> But aren't these mostly solvable implementation details?

Not just.  They're also deployment problems.  If everyone were satisfied
with RP-only, self-signed user certs then the only problem left is that
the user might, for privacy reasons, still want to have different certs
for different RPs.  The moment the user has multiple user certs you get
into credential selection difficulties.

But I don't think it'll be easy to wean anyone from using certs with
meaningful content...  And that's a huge problem because by itself it
leads to multiple user certs.

> >  - DIGEST-MD5.
> >
> >    Legacy.  MD5.  Ancient.  Not federated.  Ugly browser dialogs.  End
> >    of story.
> 
> Other than the recent upward trend towards openid, there didn't seem
> to be much demand for federated auth.

I would say that ABFAB WG exists because there is demand for federated
auth.  Same for OAuth and certain SAML profiles.

> As for the ugly browser dialogs, is there anyone other than the
> browser vendors to blame?

They're certainly part of the problem, but browser vendors stopped
improving this situation when everyone stopped using DIGEST-MD5.

> >  - HTTP/Negotiate
> >
> >    Currently used only with Kerberos and NTLM.  Kerberos could be
> >    deployed on an Internet scale, but like a one-root PKIX PKI, never
> >    will be.  No need to explain why NTLM isn't taking over the Internet.
> 
> Yeah, it's not what people want.
> 
> Theory aside, it creeps people out that they would be be strongly
> authenticated everywhere they surf. I'm just not going to sign up
> with my drivers license or US passport officially legal credentials
> to leave a comment on some random blog. I'm not necessarily seeking
> anonymity either.

There is that too.  Users *must* have control over when they are
authenticated and _what_ credential is used.

The way I picture it is that there should be an "authenticate" or
"login" button on wbpages, which when clicked, triggers browser chrome
credential selection GUI (note, note necessarily a dialog -- think more
of the way FF tells you that you're offline, for example), with the
user's last choice for this site pre-selected, the user clicks OK and if
necessary enters whatever password/passphrase/PIN might be needed.

> Schemes that expect users to sign up to a central registry are just
> not what people want.

Well, not all the time nor for all services.  With that caveat (which I
think you meant to state anyways) I strongly agree.

> What users seem to want is an easily-remembered password they can
> use all over the place. Hopefully we can get them something better.

Plus something that works when they don't have their password wallet
with them (e.g., when using hotel business center kiosks).

> What most web sites seem to want is an authentication scheme that
> they can customize according to their style and needs and never
> denies access to anyone plausibly legitimate. Often they don't even
> want the user to have to log in more than once, ever. They don't

Modulo session refresh.

> want the user to see another 50ms of latency or bear another 10%
> server CPU overhead for TLS. They want to be able to load Javascript
> from 5 different affiliates and marketing companies.

And they want the whole thing to not cost very much.

HTML form POSTing costs providers very little.  And the marginal cost
for users is also low.  The total cost for users is an unusable system.

> >    Given recent work on HTTP/Negotiate and the ABFAB WG and possible new
> >    mechanisms from the KITTEN WG, we'll have many more mechanisms than
> >    just Kerberos and NTLM for use in HTTP/Negotiate.  I'm not sure that
> >    they'll be used extensively through HTTP/Negotiate -- that will
> >    depend on what else we do in terms of HTTP auth NG, no?
> 
> Will any of that change what we think of as the barriers to adoption?
> 
> I.e., is the problem or solution really at the HTTP protocol layer?

See my other post today on constraints.

> >    Also, HTTP/Negotiate provides no generic way to customize credential
> >    selection and credential initiation forms/dialogs.  Such
> >    customization will generally have to be mechanism-specific -- and I
> >    expect that to be true for all cases where we use pluggable security
> >    frameworks.
> >
> >Am I missing any other existing HTTP authentication schemes?
> 
> Well, there's the one used by the vast majority of web sites:
> 
> Initial HTML form POST of plaintext username and password and
> subsequent session cookies (occasionally within required TLS).

That's NOT an HTTP authentication scheme.  That's an application-layer
authentication scheme for applications that a) use HTTP and b) are
browser-based.  I realize that from a user's perspective this
distinction is irrelevant and way too subtle for them to care.  But for
us it should matter a lot.  See my constraints post.

> It's infinitely customizable by the web site and supported
> universally by browsers and web app frameworks.
> 
> If we want to propose something that might be widely used, that's
> what we're up against.

Yes.

> To review, the main problems that might motivate a willingness to change:
> * vulnerable to spoofing

Because of weak authentication of servers to users.

> * vulnerable to script and cookie origin badness

I believe these are orthogonal to the problem at hand.

> * doesn't integrate naturally with non-browser clients

Or at all.

> * doesn't integrate naturally with federated, single sign on,
> multi-factor, or any other auth schemes

Or at all.

> * doesn't have a standard way to log in, log out, change password,
> enroll, etc.

Yup.

> * not necessarily a natural fit for the latest generation of phones
> and tablets which are trending away from keyboard-oriented
> interaction
> 
> Missing any?

Yes: it's completely unmanageable for users, leading to password re-use
and what not.

Nico
--