Subject: Re: [kitten] [websec] [saag] HTTP authentication: the next generation

From: Ben Laurie <[email-masked]>
Date: Thu, 6 Jan 2011 15:31:51 +0000

On 6 January 2011 01:28, Robert Sayre <[email-masked]> wrote:

> > Peter Saint-Andre <[email-masked]> wrote:
> > 2. In 2007, Robert Sayre put together a few slides on the topic:
> > http://people.mozilla.com/~sayrer/2007/auth.html
>
> These are back on the Web, in case anyone missed them (probably not).
>
> On Sun, Dec 12, 2010 at 5:39 PM, Roy T. Fielding <[email-masked]>
> wrote:
> >
> > Define them all and let's have a bake-off.  It has been 16 years since
> > HTTP auth was taken out of our hands so that the security experts could
> > define something perfect.  Zero progress so far.
>
> I think the IETF might do better to focus on a smaller problem, at
> first. People often use self-signed certificates with HTTP/TLS, even
> though the first thing their websites ask the user to do is type a
> username and password into a form. There are some well-understood ways
> to make this process more secure. Why hasn't the IETF fixed this
> problem? If this smaller problem has no ready solution, then the
> larger issue of authentication on the entire Web seems like a tough
> nut to crack.
>

Two comments (one really being a response to Roy):

1. The IETF has fixed the problem, but no-one is using the fix - perhaps
because it is not clear that it is the fix. I speak of RFC 4279, TLS
pre-shared keys. These could be derived from a hash of the password and the
site name, for example, and thus provide secure mutual authentication
despite password reuse.

2. I have often heard (though I am not aware of hard evidence for this,
nevertheless I find it plausible) that one reason no-one has bothered to
improve HTTP auth is because no-one would use it since site owners want to
control the user experience around signin. It seems to me, therefore, that
HTTP is the wrong layer to fix the problem at - it needs to be pushed down
into HTML or Javascript so that the page can control the look, while
appropriate HTML elements or JS code can deal with the secure exchange of
data.

Of course, this still leaves the issue of trusted path: although we can
provide elements which are safe to use, even when being phished, how does
the user know those elements are actually being used, rather than simulated
so as to get hold of the underlying password?

The answer to this problem is hard, since it brings us back to taking the UI
out of the sites hands.

> It could be that the reasons for this lack of progress are
> nontechnical. Just throwing that out there.
>

If you think UI is nontechnical, then I agree.

Cheers,

Ben.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 6 Jan 2011 18:16:15 +0000

On 6 January 2011 16:03, David Morris <[email-masked]> wrote:
>
>
> On Thu, 6 Jan 2011, Ben Laurie wrote:
>
> Which is only helpful if you can somehow gaurantee that the user agent
> software hasn't been compromised. Not something I'd bet on...

That's rather overstating it. It's perfectly helpful when the UA
software hasn't been compromised, which is a non-zero fraction of the
time.

When the UA s/w has been compromised I'm quite happy to fail to fix
the problem: the right answer to that is to improve the robustness of
the UA.

---

From: Marsh Ray <[email-masked]>
Date: Thu, 06 Jan 2011 13:51:53 -0600

On 01/06/2011 12:35 PM, der Mouse wrote:
>> Look back far enough and you'll find all kinds of "electronic mail"
>> services implementing the full range of peer and end user
>> authentication, and sender-pays models.  There was no spam on those
>> systems, or at least not enough that anyone felt like they needed a
>> word for it.
>
> There was basically no spam on open-Internet SMTP mail either, at the
> time.  Certainly "no spam" by today's standards.
>
>> Guess why we use the one we use today.
>
> At the time, the services you deride weren't providing a significant
> value-add.

I wasn't so much deriding them but saying there were points all over the 
trade-off curve and the market voted with its feet. Unambiguously.

Of course, the marketing creeps followed.

> Today?  They would be.  Perhaps not enough to make up for their costs;
> probably not, in fact, or there'd be businesses arising in that space.

There are plenty. It's a commoditized low-margin business these days. 
But the network infrastructure costs are not nearly the biggest cost 
once you factor in things like end-user support.
E.g. http://www.google.com/search?q=hosted+vpn

It occurred to me last night that one might recreate the good old days 
of the Internet with a VPN which allowed access to the good old folks 
who were on it back then. Sounds a little crass and elitist now that I 
propose it out loud.

But imagine a global authenticated VPN where the only reason you could 
be banned is for spamming? Or one where you had to be at a university CS 
department? Or a whole set of overlapping criteria and you could choose 
what the membership criteria for your own view of the network?

Your own personal Virtual Public Internet.

> As a side note, it's interesting to see how well the early Internet
> designers built; their systems are routinely being stressed several
> orders of magnitude beyond what they were designed for, and are holding
> up remarkably well.

It is amazing, isn't it?

> The postal system did collapse when it started
> suffering from spam; that's why the paper chain mail is actually
> illegal in many jurisdictions - it took down the postal system, once
> upon a time.

Nice.

> The telphone system would collapse if phone spam
> outnumbered real calls by 10, 25, 100 to 1.  (Actually, in a sense they
> already do.  I have a fax line set up, and get dozens of fax spams for
> every real fax.  I've had to start adapting and applying my email spam
> fighting techniques there....)

We get so many unsolicited calls from telemarketers and robot dialers at 
home we don't answer the phone unless we recognize the caller ID. 
Sometimes family calling from roaming cell phones show up as 
'unidentified caller' and we mistakenly don't answer. How much more 
broken can it be?

- Marsh

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 07 Jan 2011 10:24:21 +0200

[Culling down the mailing lists]

Hi Ben,

No, RFC 4279 should not be used with (a hash of) human-memorable 
passwords, because it would be vulnerable to dictionary attacks. See 
http://tools.ietf.org/html/rfc4279#section-7.2. SRP, EKE and similar 
schemes should be used instead.

Thanks,
	Yaron

On 01/06/2011 05:31 PM, Ben Laurie wrote:
[...]

> pre-shared keys. These could be derived from a hash of the password and
> the site name, for example, and thus provide secure mutual
> authentication despite password reuse.
>
[...]

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 07 Jan 2011 12:57:29 +0100

One way to mitigate the dictionary attack problem is to do PBKDF#2
processing of the password before it hits TLS-PSK.

However I agree that TLS-SRP have superior properties, and it is widely
implemented.  There is no practical reason to prefer TLS-PSK over
TLS-PSK for password-based TLS authentication.  One issue is that RFC
5054 is Informational rather than Standards Track (same issue as for
TLS-OpenPGP), which is due to political reasons.

/Simon

---

From: Ben Laurie <[email-masked]>
Date: Fri, 7 Jan 2011 12:14:32 +0000

On 7 January 2011 08:24, Yaron Sheffer <[email-masked]> wrote:
> No, RFC 4279 should not be used with (a hash of) human-memorable passwords,
> because it would be vulnerable to dictionary attacks. See
> http://tools.ietf.org/html/rfc4279#section-7.2. SRP, EKE and similar schemes
> should be used instead.

Fair point, though there seem to be at least political barriers to
using SRP, and EKE and friends have other issues.

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 07 Jan 2011 14:57:05 +0200

Another issue is that SRP (as opposed to other protocols in this space) 
is not provably secure, and in fact has had relatively little 
cryptographic review, AFAIK. I would be glad to be proven wrong on the 
second point.

Thanks,
	Yaron

On 01/07/2011 01:57 PM, Simon Josefsson wrote:
> Yaron Sheffer<[email-masked]>  writes:
>

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 07 Jan 2011 15:29:40 +0100

The initial paper contains a security analysis with some reduction-style
arguments:

http://srp.stanford.edu/ndss.html#SECTION00040000000000000000

As with any crypto document from that time, it will lack in how the
assumptions are stated and the reductions are made.  That considered, is
there something in particular that you think is missing in there?

We can fix the problem with lack of review by implementing and deploying
the protocol, then certainly researchers are bound to focus on it. ;-)

/Simon

Yaron Sheffer <[email-masked]> writes:

> Another issue is that SRP (as opposed to other protocols in this
> space) is not provably secure, and in fact has had relatively little

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 07 Jan 2011 18:05:09 +0200

- I am not a cryptographer, so I am treading on extremely thin ice here.

- SRP is certainly better than using PSK with passwords, which is 
*definitely* vulnerable to dictionary attacks.

- That said, I have done my little bit of due diligence (talked to the 
author of SRP and to several cryptographers who've played with some of 
these schemes). Personally, I would rather use a protocol that's been 
formally proven (PACE, AugPAKE, other descendants of EKE) or has had 
real solid cryptographic review (the original EKE). Again, I would be 
happy to be proven wrong on this.

- Even if we start with a mathematically perfect protocol, we are bound 
to make design and engineering mistakes. And Marsh and his like will 
happily poke holes into these implementations :-) But I'd like to avoid 
compounding the risk with cryptographically unsound protocols.

Thanks,
	Yaron

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 07 Jan 2011 17:54:46 +0100

> *definitely* vulnerable to dictionary attacks.

One final addition here, the situation for PSK depends on the flavour
and whether you are talking about active or passive attackers.  The
statement is true for plain PSK, but less so for DHE_PSK and RSA_PSK.
Section 7.2 of 4279:

   For the PSK ciphersuites, an attacker can get the information
   required for an off-line attack by eavesdropping on a TLS handshake,
   or by getting a valid client to attempt connection with the attacker
   (by tricking the client to connect to the wrong address, or by
   intercepting a connection attempt to the correct address, for
   instance).

   For the DHE_PSK ciphersuites, an attacker can obtain the information
   by getting a valid client to attempt connection with the attacker.
   Passive eavesdropping alone is not sufficient.

   For the RSA_PSK ciphersuites, only the server (authenticated using
   RSA and certificates) can obtain sufficient information for an
   off-line attack.

/Simon

> - Even if we start with a mathematically perfect protocol, we are
> bound to make design and engineering mistakes. And Marsh and his like
> will happily poke holes into these implementations :-) But I'd like to
> avoid compounding the risk with cryptographically unsound protocols.
>
> Thanks,
> 	Yaron
>
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 8 Jan 2011 11:07:38 -0500

I think that Ben is right that we are solving the wrong problem.

The problem is that users are asked to maintain accounts at literally
HUNDREDS of accounts.

And some cretins, some utter morons, some bog-brained berks think it is
reasonable to tell the user to have a different password for every one!

I can't remember the account names, the password is easy as I only had one
(for non financial) - until those cretins at Gawker screwed up. Now I have
to reset my password at all those places.

We have to solve the federated auth problem and it is really, really easy:

Account Name is the RFC 821/822 email address.

This is what the Web has started to adopt of its own accord as a user
account identifier. It is the only one that people can remember reliably.

Authentication service is resolved via DNS service lookup

i.e. SRV or similar. I can show people how to fix up the issues to do with
use of non-canonical names.

Client authenticates to authentication service using any protocol they both
support.

This is quite simple to implement, just stick a list of supported auth
services in the DNS.

We can re-use all those existing auth protocols that work (SAML would be a
good choice but we don't need to be overly restrictive here.)

HTTP carries a standardized, non-linkable auth token

I have some ideas on how we could modify DIGEST to do this. DIGEST would not
be problematic if the password had 128 bits of ergodicity and we upgraded
the digest function.

The reason for re-using DIGEST here would be to avoid patent encumbrances. I
considered the issue of linkability at great length when writing the
original DIGEST design.

At the moment I am focused on getting the foundation laid. But I will try to
come up with a full proposal before Prague.

I know that you can achieve some of the desired authentication properties
with public keys at the client. The problem is that our current use of
computers has gone way beyond the one-machine-per-person paradigm

On a recent trip to Europe with the family I counted that we had 10
computers with us capable of supporting IP (3 laptops, 3 iPhones, 2
Nintendos, 1 iPad and a kindle).

Cardspace has some really, really great properties but they are totally lost
when you try to make the service accessible from multiple machines by
putting it 'in the cloud'. In fact, other than a manager, I have never found
anyone who reven thinks they know what they mean by 'in the cloud' for
CardSpace. I certainly have never seen an explanation I can understand.

Devices get lost. Devices get stolen. We don't want to encourage that so
there needs to be something more than just a certificate based client auth
scheme.

I think we need some form of centralized (for given account) account
management in the mix so that the user can authorize/deauthorize devices for
use (c.f. Amazon's Kindle account management)

So there are basically two architectural options for using public key. One
is to use it strictly between the client and the auth service and use a
token like approach as discussed above. Another is for the auth service to
issue an assertion of the form 'you can tell its fred by this public key
(amongst others)'.

SAML already has support for both approaches BTW.

> pre-shared keys. These could be derived from a hash of the password and
the
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>
>

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 8 Jan 2011 11:21:42 -0500

> the problem: the right answer to that is to improve the robustness of

+1

If the UA is stuffed then the user is totally and utterly stuffed anyway.

In particular if the UA is stuffed then a forms based experience is just as
stuffed. If we are going to hypothecate attack models people have to be
willing to apply them to their preferred solution too.

The sensible approach is to work out how to stop the user from being stuffed
e.g.

 * Comodo's free Anti-Virus with Default Deny Protection (TM)
 * Use code signing + trustworthy computing
 * Use a restricted browser

Now I have a lot of ideas on how we can tackle these, but they are not
relevant to this debate.

I do however have a different take on the UI issue.

HTML forms did have an advantage over the pathetic UI that browsers provided
for BASIC and DIGEST (most don't even tell the user which is in use).

But a federated auth scheme supported at the HTTP level could be simpler
still. Instead of the user having to register for each site, they register
once. Instead of the user having to log in to each site they log in once per
session. Instead of the site having to manage lost passwords and forgotten
accounts because the user has hundreds, this problem does not exist.

It is a user interface crisis that is driving this need in my view.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 8 Jan 2011 12:52:45 -0500

OAUTH and Webfinger are both pretty much as good as you can expect to
achieve if you decide at the start that you are not going to modify the
infrastructure.

But that decision limits what you can expect to achieve.

A particular problem with OAuth is that you can only use the identity
providers that are supported by the particular site. So I had to use my
Twitter account to play spymaster. And when Twitter got shirty and started
blocking other players accounts they lost their game account and their
twitter account at the same time.

There are people who think I should get a facebook account just so that I
can use their application. Not happening.

As for WebFinger, it works, but not nearly as well as a clean DNS scheme.
DNS is designed to address this problem, HTTP is not. And solving the
problem with HTTP requires us to have a scheme that involves DNS + HTTP +
SSL + PKIX which is rather a lot of moving parts and to make matters work
some those parts are not just moving, they are changing.

I think it is a very good idea to look at WebFinger and OAuth and see how to
realize these approaches direct in the infrastructure. But they should be
seen as starting points, not ends.

On Sat, Jan 8, 2011 at 12:37 PM, Blaine Cook <[email-masked]> wrote:

> Two points:
>
> 1. In this entire thread, no-one has mentioned OAuth. Maybe y'all
> don't like it, but it's used to authenticate more HTTP requests by
> volume and users than everything-except-cookies combined. You may want
> to consider the design of OAuth when proceeding with these
> discussions, rather than the laundry list of [completely] failed
> protocols.
>
> 2. With respect to federated auth, especially using email address-like
> identifiers, there has been a bevy of (deployed) work in this regard.
> The effort is called webfinger, and is worth a look. Instead of DNS,
> we use host-meta based HTTP lookups to dereference the identifiers.
> Many diaspora and status.net installs are using it today, and there
> are several proposals towards building a security & privacy
> infrastructure on top of webfinger (webid is one such proposal whose
> incorporation of client-side TLS certificates in a browser context
> makes me very weary of its potential for success).
>
> b.
>
> On 8 January 2011 08:21, Phillip Hallam-Baker <[email-masked]> wrote:
> > apps-discuss mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/apps-discuss
> >
> >
>

---

From: William Mills <[email-masked]>
Date: Wed, 19 Jan 2011 18:47:05 -0800

Greetings.

Now that I've finally gotten permission to put my code out into open source I have an implementation of a SASL mechanism in the Cyrus SASL framework.  The draft spec (about to expire) is 

	http://www.ietf.org/id/draft-mills-kitten-sasl-oauth-00.txt 

and you can find the code at

	https://github.com/sweetums/SASL-OAuth

Many warts, and lots to fix, but it's out there.  TODO list includes:

-	work on channel binding with the newish Cyrus SASL source drop that includes it.
-	update to conform with the -11 or later OAuth2 core spec and the bearer token spec
-	update the draft spec to handle the above

Regards,

-bill