Re: [saag] Channel binding is great but not a silver bullet

[Nicolas Williams <[e-mail]>]

On Mon, Mar 02, 2009 at 07:22:31PM -0500, Stephen Kent wrote:
> I'm unclear on the exact constraints you're trying to satisfy with 
> the channle binding model, but here are some observations anyway.

Again, channel binding is incidental.  I'll lay out the constraints
below.

> Mutual authentication is certainly desirable for most communication 
> contexts. But, in contexts where neither party has a relationship 
> with the other a priori, I don't think there is any magic bullet.

This true, but there is a subtlety here: enrolment is rare, much rarer
than login events.  Enrolment still presents the same problem as typical
web app logins today.  But the fact that enrolment events are rare
helps.

I helps in several ways:

1) phishers would need to be luckier if all they could phish were
   enrolment attempts (just how much luckier than now depends on a
   variety of details, like how easy it is to poison every significant
   ISP's every DNS cache);

2) throw in federated authentication mechanisms and truly-initial
   enrolment events get rarer, which enhances effect #1 and,

3) allows one to leverage existing relationships for securing enrolment
   (at a cost in terms of anonymity, but then, this is optional).

> The primary, large scale, global PKI to which PHB alluded is the only 
> major example we have where a user can get a reasonable level of 
> assurance for one-way authentication.

Agreed.  (But see (2) in conjunction with (3) above with regards to
"one-way authentication" (meaning that it's the server that gets
authenticated) in the context of enrolment.

Non-enrolment-related needs for one-way authentication are probably much
rarer than normal logins, and probably don't present as much of a
phishing target (but I admit I'm not sure of this last).

>                                       That model enables a 
> (conceptually simple) transition to two-way, cert-based 
> authentication, where each web site can act as a CA for its users. 
> However, the poor tools we have to manage a plethora of certs from 
> these narrowly-scoped CAs makes it hard for users to buy into that 
> model.

Agreed.

> In other parts of the world (especially in Asia)) there are large 
> PKIs that serve substantial user communities. Often governments take 
> the lead in issuing certs to individuals in these PKIs, and in 
> creating CAs or bridge CAs to certify government and private sector 
> organizations.

Even here, Stateside, the DoD has a huge PKI.

> But, none of this is free. Absent government subsidies, mandated use, 
> or hidden taxes, one ought not surprised by business models that 
> require users and/or web site owners to pay for certs.  After all, in 
> most contexts, at best you get what you pay for :-).

Exactly.  I'm not, I should add, trying to cut out what Peter called
"nuissance fees."  If authentication federations took off it's very
likely that they'd have their own nuissance fees.

> The lack of a single credential that authenticates a user to 
> everywhere is a good thing from a privacy perspective. Federated 

Indeed.  But users also want convenience and are willing to trade off
between the two.  Thus one might have 100 accounts with no federation,
or 10 with, using, say, one just for one's preferred dating site, etc...
-- most accounts in my home are related to shopping, where privacy is
somewhat less important, particularly considering the current online
payment system).

> identity management schemes create lots of opportunities to link 
> islands of authenticated users (and organizations), but they have 
> sever drawbacks re security. I tend to think of such schemes as 
> having all the charming features of Wikipedia :-).

The ones that exist today, yes!  But that's partly because they are all
constrained to usign HTML forms for logins and redirects and all sorts
of funny business.

The constraints as I see them:

a) Must have mutual authentication.

b) Must use passwords (but need not necessarily be a DISGEST-MD5-like
   mechanism -- for example, Radia once proposed using SACRED to
   retrieve private keys and certs).

c) Corollary of (a): must not send passwords to the server (whether over
   TLS or not).

d) Must be acceptable to web application developers (they are the
   reason, after all, that DIGEST-MD5 is not used, they); specifically:

    - the user experience must be acceptable to web application
      developers.

e) Password-based mechanisms (as opposed to, e.g., Radia's proposal
   mentioned above) must be federatable, if only because of the need to
   reduce truly-initial enrolment events, but likely also because of
   (d).

   This in order to minimize the number of times a user must type in a
   password in a browser-controlled dialog, under the theory that web
   app developers hate those).

Cheers,

Nico
--