Re: Straw-man charter for http-bis

[Henrik Nordstrom <[e-mail]>]

fre 2007-06-08 klockan 15:45 +0100 skrev Eliot Lear:

> I disagree in the strongest possible terms.  This *is* a problem we can 
> solve technically.  It's just that no one has the will to do it and 
> we've organized ourselves so that the work cannot be done in one place.  
> If you had a component that was separate from your workstation, that had 
> but a single function – authentication – we could write appropriate APIs 
> and protocols to access that device such that you would never log in 
> without using it.

Note: My comment was regarding seeing stronger authentication in HTTP as
a method to solve phishing. It is not.

Stronger authentication in HTTP is means to secure the wire protocol for
exchanging user credentials, nothing else.

Regarding stronger authentication in general. Sure, and I fully agree.
And what you say is already supported by using smartcards and TLS for
authentication, and is used by quite many today. Here in Sweden I can
get identity cards with a embedded trusted certificate, and use this to
identify myself to the tax authorities, social services etc. (not yet to
the banks who issue these certificates, but that's a completely
different discussion in administrative policies and not wire
protocols..)

But if you read the current discussions regarding phishing it's claimed
that having a hard token requirement is not acceptable and that the
solution must work with just a login+password.

What I am saing is just the simple fact that designing a protocol to
prevent phishing of static secrets of any kind is rather fruitless as
the phishing problem as such is really mainly is an UA and education
problem, not so much a wire protocol problem. As long as the user is
capable of giving out the information and don't need to think twice in
doing so phishing will continue, no matter how strong wire protocols is
designed for exchanging these user known secrets with trusted parties.

> The riskiest functions would be registration.  In 
> that single area would I view this an education problem, but even there, 
> if we came up with a standard way to legitimately register individuals 
> we could probably make that problem much more solvable.

And we already have that in TLS, with appointed trusted CAs and where
each service provider selects what level of trust he appoints the
different CAs in verifying the user identities.

> I disagree with you on this as well, but then the term "single sign-on" 
> is so overloaded we really can't argue the point without debating the 
> term first.  So I'll define it as only requiring one password to do 
> whatever it is I want to do (what the DIX/WAE BoFs called "Eliot's Dad's 
> Problem").

In what way do not Digest fit that? (putting aside the security concerns
regarding Digest use of MD5 and how)

What is missing for Digest is some standard means for esablishing the
password without exchaning the password, but it's possible to do such
exchange, at least to a reasonable level.

> But I also think there's no use in me whining about the lack of this 
> stuff, and so I suppose it's time to shut up and either write a draft 
> that actually attempts to address Sam's concerns or build some code to 
> match some existing drafts, and then we can see how far off we are.

It's fully possible to come up with an replacement for Digest solving
the wire concerns.

The relevance to RFC2616 in such work is the need for some standard way
of establishing the password in a secure manner. The rest is relevant to
RFC2617 only.

Regards
Henrik