Subject: [saag] The quest to replace passwords

From: Paul Hoffman <[email-masked]>
Date: Sun, 8 Jul 2012 16:52:41 -0700

Greetings again. A few times on this list, people have spoken of the need to replace passwords with an unstated assumption that if we just work hard enough, we'll have a good solution. Another unstated assumption is that we know how to measure what a good replacement is. A recent excellent academic paper, referenced at <http://www.lightbluetouchpaper.org/2012/05/22/the-quest-to-replace-passwords/>, may make us (well, the less single-minded among us) a tad less confident in both of those assumptions. This work is certainly relevant in a few IETF WGs as well as SAAG in general.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 09 Jul 2012 01:22:04 +0100

I agree with their opening (*) and with thinking more,
and seriously, about this topic.

 (*) "The continued domination of passwords over all
      other methods of end-user authentication is a
      major embarrassment..."

I entirely disagree that we ought give up, if that's the
conclusion someone might draw.

If we wanted to solve this, we could, IMO. SSH and PGP are
perfectly good protocol models, and usability has to be
easier than installing linux, which seems to have been
doable for a few million folks.

S.

PS: Full disclosure - I got frustrated that nobody else did
it, so I wrote up a scheme for http/2.0 aiming specifically
at tackling this issue. [1] IMO, it could work, if the
browser folks actually felt the embarrassment mentioned
above. I hope they do. (And don't care if this or some other
scheme is the non-password one that gets adopted.)

[1] http://tools.ietf.org/html/draft-farrell-httpbis-hoba

On 07/09/2012 12:52 AM, Paul Hoffman wrote:
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 09 Jul 2012 09:29:46 +0300

Passwords are not "the enemy". More like a wild animal that we, as a 
community, need to tame.

This paper presents a very important classification. Unlike Stephen, I 
think that moving forward we should not aim to drop passwords 
altogether. Rather, we should combine the usability benefits of 
passwords (primarily the fact that a password can be used from anywhere, 
with no need for credentials to live on a device) with one or more of 
the password "replacement" technologies. For example, a master password 
can be used to unlock a public-key store.

We can reduce the usage of passwords significantly, thereby reducing the 
associated risk. We can also use under-utilized technologies to improve 
the remaining uses of passwords. These include password-based 
authentication protocols (EKE and the like), and amplification of 
passwords into long-term cryptographic secrets, when appropriate 
(http://tools.ietf.org/html/rfc6631#section-3.5).

Thanks,
	Yaron

---

From: Nico Williams <[email-masked]>
Date: Mon, 9 Jul 2012 02:01:38 -0500

> Passwords are not "the enemy". More like a wild animal that we, as a

I think we'll end up with more than one standard replacement for the
current web authentication mess.  Passwords will continue to have a
place.  I like HOBA, and to the extent that soon enough everyone
everywhere will have a smartphone (or more, + tablets) it certainly
has a place.  I just don't think it will be the only solution we end
up with.  E.g., for as long as the desktop remains king of the
corporate world we'll need something else, and probably even after
BYOD triumphs -- if it does.  Even if everyone carries smartphones
we'll still need failsafe account recovery systems, and those are
likely to continue to be... password based (only it will be worse when
users rarely type in passwords, since they'll then rarely practice
their recall).

> This paper presents a very important classification. [...]

I think classification is really the first step towards choosing from
among proposals, and perhaps even for choosing techniques on which to
base proposals.

Nico
--

---

From: Eliot Lear <[email-masked]>
Date: Mon, 09 Jul 2012 10:41:09 +0200

Paul,

I take away something quite different, that in fact the Internet
technical community is doing the exactly right thing, by creating a
toolbox to allow for a more nuanced evolution away from passwords.  That
table they provide shows also that there is likely to be a consolidation
as things progress, but perhaps not before a few more methods are created!

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 09 Jul 2012 10:27:58 +0100

> Passwords are not "the enemy". More like a wild animal that we, as a

Fair enough that "enemy" is exaggeration. I'm guilty of
that:-0

FWIW, I don't think we ought try get rid of passwords. I think
a practical goal though is to try reduce the rate of growth of
password database entries.

And I think we ought try do that via non-password based auth
schemes, in http and elsewhere.

So I don't think we're really disagreeing.

S.

>>> Greetings again. A few times on this list, people have spoken of the
>>> need to replace passwords with an unstated assumption that if we just
>>> work hard enough, we'll have a good solution. Another unstated
>>> assumption is that we know how to measure what a good replacement is.
>>> A recent excellent academic paper, referenced at
>>> <http://www.lightbluetouchpaper.org/2012/05/22/the-quest-to-replace-passwords/>,
>>> may make us (well, the less single-minded among us) a tad less
>>> confident in both of those assumptions. This work is certainly
>>> relevant in a few IETF WGs as well as SAAG in general.
>>>
>>> --Paul Hoffman
>>>

---

From: Ben Laurie <[email-masked]>
Date: Mon, 9 Jul 2012 10:54:21 +0100

> doable for a few million folks.

One has to wonder why they are not included in that paper?

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 09 Jul 2012 12:58:18 +0300

So it's mostly a question of where to focus. I would say that, *in 
addition* to non-password based auth methods, we also need to work on 
more modern password based auth methods, in HTTP and elsewhere. We will 
probably need both for a long time.

Thanks,
	Yaron

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 09 Jul 2012 12:22:40 +0100

> probably need both for a long time.

I sort of agree, though I personally think the most
pressing need (in the IETF, for http) is to provide a
usable non-password based auth scheme that has a good
chance to get used. That last is outside our control of
course, but the current work on http/2.0 does provide
a window of opportunity maybe.

For "more modern" (whatever that means) schemes based on
passwords, if they still require a database that can leak
and be dictionary attacked, then I'm not so interested,
since the overall benefit provided doesn't seem that
great given the kinds of attack seen in the wild.

But I do agree that better support for kerberos-like
auth-schemes in http is probably worth effort and maybe
EKE-like things are also, but less so IMO.

I'd encourage folks to go look at the set of http/2.0
auth scheme proposals [1] and send the kind of comments
requested [2] to the httpbis wg. [3] There's a deadline
for that of July 15th btw.

S.

[1] http://trac.tools.ietf.org/wg/httpbis/trac/wiki/HttpAuthProposals
[2] http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0008.html
[3] http://tools.ietf.org/wg/httpbis/

---

From: Sam Hartman <[email-masked]>
Date: Mon, 09 Jul 2012 10:45:27 -0400

I'll note that the usable deployments of ssh public keys I've
seen--things widely deployed enough that a commercial organization is
willing to support it for a public of developer communities--all fall
back to passwords to reset/change your ssh keys. I'm thinking of things
like github/launchpad/sourceforge/etc.

Ssh alone does not solve the key management problem ; how do I get a
particular ssh key authorized. In practice, beyond fairly small
deployments that ends up boiling down to passwords and TLS.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 09 Jul 2012 15:56:40 +0100

Hi Sam,

> deployments that ends up boiling down to passwords and TLS.

I agree that those are issues that need to be tackled
but I don't think they are insurmountable.

My thesis is that there are now enough people with
multiple capable devices that we can solve these
problems in a useful number of situations by taking
advantage of that fact. I fully accept that that's
somewhat speculative but the potential payoff is
IMO worth the effort of trying (again;-).

Cheers,
S.

---

From: Tim Bray <[email-masked]>
Date: Mon, 9 Jul 2012 08:03:13 -0700

Hmm... most organizations I’ve worked with/for that really care about
security seem to think the old something-you-have+something-you-know,
implemented well, hits a good 80/20 point.  I’m inclined to agree.

I’d also be unsurprised if someone came up with something better, and
that table is a handy tool to help think about replacements.

The problem with passwords is trying to scale them across the
Internet.  I don’t mind at all logging on once, and even doing some
extra-security song-and-dance about it.  I just want to use the
identity thus established everywhere I go, to the extent possible.  -T

---

From: Sam Hartman <[email-masked]>
Date: Mon, 09 Jul 2012 11:06:23 -0400

>>>>> "Stephen" == Stephen Farrell <[email-masked]> writes:

    Stephen> Hi Sam,

    >> deployments that ends up boiling down to passwords and TLS.

    Stephen> I agree that those are issues that need to be tackled
    Stephen> but I don't think they are insurmountable.

Perhaps.  However, if I were going to look at successful models of
non-password auth I'd look at Blizard (World of Warcraft), Google and
various business banking tokens rather than SSH for success stories and
motivation.  Those deployments seem to focus on OTP of some kind or
another or a presumed secure back channel in the case of some SMS
schemes.

Obviously I believe this is an important problem. I've been working on
various ways to decouple authentication mechanism from the rest of the
exchange and various ways to abstract out authentication for the past 15
years or so. The reason I've been working on that is in part to support
move away from passwords where it makes sense.

---

From: Nico Williams <[email-masked]>
Date: Mon, 9 Jul 2012 10:39:47 -0500

> great given the kinds of attack seen in the wild.

All password-based schemes must have either password equivalent or
password verifier databases.  Necessarily.  ZKPPs included.  These
usually are amenable to HSM implementation, so that helps.  Also, some
such schemes have trusted infrastructure, and that too helps (put the
HSMs in the infrastructure, and you've minimized and reasonably
secured the number of places where material can get stolen for
off-line dictionary attacks).

> EKE-like things are also, but less so IMO.

We have roughly these choices for cryptographic, password-based security:

 - no trusted third parties (e.g., SCRAM and all plain ZKPPs)

 - trusted infrastructure, with client doing the talking (Kerberos)

 - trusted infrastructure, with server doing the talking (ABFAB)

Any variation on the first that adds trusted third parties ends up
looking like Kerberos or ABFAB or a hybrid.

> for that of July 15th btw.

For comments?  I've seen very few, if any comments so far on all of
the proposals.  Makes me question actual WG inteterst.

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 09 Jul 2012 16:51:58 +0100

On 07/09/2012 04:39 PM, Nico Williams wrote:
> For comments?  

Yep.

> I've seen very few, if any comments so far on all of

Agreed. However to be fair, I guess "SPDY vs.the rest"
is probably more of a deal for most wg participants.

I'm not sure what the chair plans if there're few or
no comments on the auth schemes, but I'd bet it'll be
seen as a lack of interest and will make it less likely
that we'll get security improvements as part of http/2.0,
so if folks here do have thoughts, sharing those on the
httpbis list would be welcome, esp. if they relate to
things you'd implement/deploy. (I doubt that a bunch
of "+1 for more security" mails will help very much;-)

S.

---

From: Nico Williams <[email-masked]>
Date: Mon, 9 Jul 2012 11:46:19 -0500

> identity thus established everywhere I go, to the extent possible.  -T

+1.  This basically means trusted third parties.  I'm ok with that.  I
don't think we'll do much better than this.  We can make the crypto not
suck, we can use HSMs, and we can make authentication federations scale to
whatever size is appropriate (the smaller the better for authenticating
services to users).

Nico
--

---

From: Mouse <[email-masked]>
Date: Mon, 9 Jul 2012 12:52:30 -0400 (EDT)

> Ssh alone does not solve the key management problem ;

No, but neither do passwords.  ssh is better in that the data the
client (the one who is authenticated) has to give to the server (the
one who checks authentication) is not enough information for someone
who obtains it to falsely authenticate as the client; it's worse in
that that the data the client has to have on hand to authenticate is
larger and, in general, cannot be memorized by humans.

Actually, that's not ssh per se, but ssh's publickey authentication
method.  The ssh protocol does support other authentication methods,
including traditional passwords (though they at least don't generally
appear on the wire in the clear).

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 09 Jul 2012 19:43:45 +0100

> implemented well, hits a good 80/20 point.  I’m inclined to agree.

Sure, token based or two-factor auth is useful where you can
afford the tokens and associated costs.

> Internet.  

There is definitely more than one problem with passwords;-)

For example, if you just use passwords for your service and
do a great job of that in every possible way, you're still
vulnerable to every other less careful service that leaks
its password database, to the extent that you share some
users with the careless folks.

> I don’t mind at all logging on once, and even doing some

That's fine but not everyone has that requirement. Many folks
would rather not have SSO everywhere all the time, and would
prefer to not use the same user identifier across all services,
e.g. for privacy reasons.

S.

---

From: Nico Williams <[email-masked]>
Date: Mon, 9 Jul 2012 14:00:26 -0500

> afford the tokens and associated costs.

They can be soft tokens (on smartphones, tablets), and they can be SMSed.

> users with the careless folks.

My vision is of several/many ID providers participating in several
authentication federations.  Users should pick reputable ID providers,
preferably ones using HSMs for protecting the password verifiers.

To expand on my vision, I see:

 - Large shopping sites (think Amazon, Yahoo!, eBay, ...) forming
   their own federations, possibly allowing third party ID providers
   to participate.

   The benefit here is that the entity running the bazaar can be very
   selective about which *services* the user can authenticate to.
   This scales user populations to Internet scale, but by limiting
   the scale of reachable services these federations can provide
   much-better-than-TLS-server-PKI service authentication.

 - A plethora of ID providers, from user-run, to ISPs, to commercial
   third party ID providers, to the authentication federations
   themselves.

Scaling user populations to Internet scale means effective SSO.

Special-purpose federations with small service populations means
effective mutual authentication.

> e.g. for privacy reasons.

I didn't think that's what Tim meant.  I share my tablet with my
household.  I find one-device-one-ID to be rather obnoxious.  But
that's NOT a function of the authentication method/credentials used.
It's a function of the tablet OS and application developers... i
dunno, not having gotten to multi-ID support.

Identity selection is a complicated topic, but fortunately it's
orthogonal to the web authentication topic and we can leave it for a
different thread, on a different day.

Nico
--

---

From: Josh Howlett <[email-masked]>
Date: Mon, 9 Jul 2012 19:59:28 +0000

>> I don¹t mind at all logging on once, and even doing some

That scenario does not preclude the use of a federated authentication
mechanism; you can, after all, have a federation of one. The interesting
part is generalising this so that it is merely a question for deployers to
decide the scope of their federation, rather than it being an inherent
property of an authentication mechanism.

Josh.

Janet is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Jul 2012 18:36:51 +0100

So yet another example of why this problem deserves
effort. [1]

Again, I'm not saying we can get rid of passwords,
but we shouldn't give up on offering better options
IMO.

S.

[1]
http://news.slashdot.org/story/12/07/11/1344231/formspring-hacked---420000-password-hashes-leaked

---

From: Nico Williams <[email-masked]>
Date: Wed, 11 Jul 2012 12:57:16 -0500

> but we shouldn't give up on offering better options

Anything we can do to reduce the *number* of passwords users must
carry will help them pick stronger passwords, not least because
carrying two or three strong passwords on a piece of paper in their
wallets/purses is reasonable, while carrying hundreds, or even tens,
is not.  This means SSO/federation/PBKDF type solutions.

The PBKDF approach (deriving site passwords from a master password)
has been tried, but failed, probably because of lack of deep
integration between new login pages and browser password managers.
The other password count reduction schemes wouldn't need the same
changes, but browsers would still have to get decent integration.

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Jul 2012 19:23:56 +0100

Hi Nico,

On 07/11/2012 06:57 PM, Nico Williams wrote:
> carry will help them pick stronger passwords, 

So I'd be interested in any evidence that that is
correct. It appears to make sense, but of course that
doesn't mean its what'd actually happen. I'd be
surprised to be honest if it were found to be the
case.

S

> not least because

---

From: Nico Williams <[email-masked]>
Date: Wed, 11 Jul 2012 13:47:43 -0500

> surprised to be honest if it were found to be the

No need for evidence, just don't let the user pick the password:
generate the passwords for them and tell them to write them down.

Also, even if you let them pick their passwords, fewer passwords will
not likely lead to the user picking worse ones than before (it's
always possible, I suppose, but it makes no sense that they would).
And if you instruct the user to write down the passwords, and offer
suggestions for stronger passwords, I think users can pick stronger
passwords.  But I can assure you that users will NOT pick or use
stronger passwords if they have to have dozens of them (again, no
evidence, just an assertion of common sense).

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Jul 2012 20:03:31 +0100

Hiya,

On 07/11/2012 07:47 PM, Nico Williams wrote:
> No need for evidence, 

I disagree. We ought be able to quote numbers here
since we've been doing web authentication at scale
for over a decade now, so many variants of password
scheme have already been tried.

> just don't let the user pick the password:

I think that fails on usability grounds to be honest.
I guess there may be figures for how many people let
Ubuntu generate good passwords, but I suspect its
a small percentage.

> always possible, I suppose, but it makes no sense that they would).

I didn't say the passwords chosen would be worse. I
said I doubted they'd be any better.

> passwords.  

I think you're being *very* optimistic there.

> But I can assure you that users will NOT pick or use

My guess is that dozens would remain the case. There
have been mega-sized password databases/login services
around for years but the number of passwords people
have has only kept increasing as far as I know.

S

---

From: Nico Williams <[email-masked]>
Date: Wed, 11 Jul 2012 14:09:12 -0500

> scheme have already been tried.

I call foul.  Breaking up the quote like you did makes it look like I
said something entirely different from what I actually wrote.

> Ubuntu generate good passwords, but I suspect its

The key word is "let".  Also, local passwords are a different beast,
so I don't think Ubuntu stats here would help the analysis.

> said I doubted they'd be any better.

Indeed, but I think we should first see if they could be worse on the
way to arguing likelihood of improvement.

> I think you're being *very* optimistic there.

Which is why I'd rather passwords be generated.  Give the user no choice.

> have has only kept increasing as far as I know.

I addressed this.  Any such solution will require proper integration
with the browsers.  If the browsers don't play along then we might as
well go home.

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Jul 2012 20:17:43 +0100

> said something entirely different from what I actually wrote.

Sorry. But honestly we really oughtn't have to
depend solely on intuition here and I wanted to
emphasise that.

> so I don't think Ubuntu stats here would help the analysis.

Well, if the argument is about password strength then
I would think it'd be just as good a metric of adoption.

I can't see that users behaviour will depend on the whether
or not the password is sent in a protocol. (It probably
does depend on how important they perceive the service
for a good chunk of users.)

But any source for credible evidence would be fine, and
I'm sure there are more.

> way to arguing likelihood of improvement.

If you look at lists of common passwords, its hard to
imagine it could be any worse:-)

S.

---

From: Nico Williams <[email-masked]>
Date: Wed, 11 Jul 2012 15:04:20 -0500

> depend solely on intuition here and I wanted to

You can make that point without misquoting me.

My point was that we don't need evidence for one particular assertion
if we don't need that assertion -- a perfectly valid, logical point,
even if it starts with "we don't need evidence".  Where as "we don't
need evidence" as a complete, stand-alone assertion, damns anyone
making it.

> I would think it'd be just as good a metric of adoption.

I don't.  The user got a choice.  That some/many/all users chose to
pick their own may well only tell us something about user preferences
for the very first password they must use and nothing at all about web
authentication.  Only if most/all users had picked the generated
password option would that help us extrapolate to web auth.

> for a good chunk of users.)

No, but it will depend on whether it's the very first one they must
type, thus not subject to, e.g., password managers.

> imagine it could be any worse:-)

Right.  We can't do worse.  I don't think we need evidence for that
particular assertion... :^)

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Jul 2012 21:19:36 +0100

> You can make that point without misquoting me.

Again, sorry.

I really wasn't trying to misquote you but I continue
to think that we can and ought have more backing than
just intuition for the kind of assertion you made
earlier.

> need evidence" as a complete, stand-alone assertion, damns anyone

Fair enough.

I can agree that if never let uses choose passwords
then stronger passwords can be given to users. That's
clearly true. I don't agree that that's a good basis
on which to figure out what to do though.

S

---

From: Nico Williams <[email-masked]>
Date: Wed, 11 Jul 2012 15:48:00 -0500

>> You can make that point without misquoting me.

NP.

> on which to figure out what to do though.

Well, I want to distinguish device passwords from all others.  Given
that distinction the next question is: can generated passwords be made
usable?  I think the answer is: a) only if there are few such
passwords for any given user, b) only if they rarely have to enter
them.  If not, forget it.  Keep in mind that (b) is probably the most
important factor because I suspect that having to enter passwords
frequently leads users to picking short, easy to type passwords.  I
have no data to back up that suspicion, just my intuition.  I suppose
I should go find some professor at the local university whom I might
con into conning some graduate students into doing a study about this.
 Or maybe we can find existing studies.  But note that this is a
difficult study proposition as it requires monitoring and testing the
habits of study participants, as opposed to merely studying a leaked
password hash DB.

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Jul 2012 22:25:56 +0100

To be honest, I think that spending a lot of effort
on this is not very worthwhile until someone's
done the work you describe below and come back with
a design and some evidence that its worthwhile.

My (admittedly biased) intuition is that it'll
amount to no more than tinkering at the edges in
terms of overall system and Internet security.

If current proportions of bad passwords continue
to be shared over O(10) [1] sites and if databases
continue to leak then I don't see that adding a
few large scale SSO services helps very much.
But I'd love to see the evidence that it might.

And of course, such large services would be very
attractive targets for all the usual suspects.

And DB leak events have a lot of associated costs,
both for the site that's leaked its DB, for its
users and for other sites where those users have
accounts and for the general perception of the
security of the network.

Overall, I think its just compelling to try to
get rid of that leaked-password-database threat
via signatures. (As in hoba or whatever.) Its
not a panacea, but is entirely worth trying.

S.

PS: The above are (I hope obviously) personal
views. If there's consensus in some wg to do work
such as you envisage, my personal views won't get
in the way of that. Put another way: requiring the
evidence is not part of IETF process, and I'm not
trying to make it so. But it is part of arguing:-)

[1] http://wwwconference.org/www2007/papers/paper620.pdf

---

From: Nico Williams <[email-masked]>
Date: Wed, 11 Jul 2012 16:49:24 -0500

But I don't see passwords going away, at least for account recovery
purposes.  HOBA is nice, but it can't be the sole solution.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Jul 2012 22:52:02 +0100

> purposes.  HOBA is nice, but it can't be the sole solution.

When did *anyone* propose that?

S.

---

From: Nico Williams <[email-masked]>
Date: Wed, 11 Jul 2012 16:53:01 -0500

> When did *anyone* propose that?

Dunno that anyone did.  Just that we still need to do something about
passwords that isn't avoiding passwords.

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Jul 2012 23:05:46 +0100

On 07/11/2012 10:53 PM, Nico Williams wrote:
> Dunno that anyone did.  

Then I'm puzzled. But whatever.

> Just that we still need to do something about

FWIW, I'm not at all convinced of that, if by
"do something" you mean "improve security" or
some equivalent.

I don't buy that there's a great security
justification for such work since I suspect that
it won't change the overall situation much, even
if deployed on a medium-large scale. Again, I'd
be happy to be convinced otherwise (by evidence:-).

There may well however probably good protocol or
engineering reasons for work related to password
auth in e.g. http/2.0 that independently justify
that effort, but that's another discussion, that
isn't and doesn't need to be, driven by improving
the security situation.

S

---

From: Nico Williams <[email-masked]>
Date: Wed, 11 Jul 2012 17:11:58 -0500

> isn't and doesn't need to be, driven by improving

Well, certainly for corporate environments we need GSS/Kerberos (and
other) support.  But I still think we'll need something like
GSS/Kerberos or GSS/ABFAB on the web at large.

Nico
--

---

From: Josh Howlett <[email-masked]>
Date: Thu, 12 Jul 2012 02:30:59 +0000

>But I'd love to see the evidence that it might.

I'm not personally aware of any such evidence; but I wonder if that
evidence is really necessary to move forwards. IMO we should seek to
provide technologies and infrastructure that will enable the market to
select between alternate authentication mechanisms (and authentication
providers), and I believe that the framework-orientated approach that Nico
advocates satisfies that criterion. Prescribing one or a particular set of
prescribed or approved mechanisms from the ivory tower does not; consider
the level of market acceptance of HTTP Basic and Digest.

Josh.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 11 Jul 2012 22:58:59 -0400

> GSS/Kerberos or GSS/ABFAB on the web at large.

We already have a WG for that
<http://tools.ietf.org/wg/oauth>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Jul 2012 11:24:15 +0100

> the level of market acceptance of HTTP Basic and Digest.

So if asking for evidence generates immediate "ivory tower"
responses like this that's probably a signal of a sort;-)

Like I said, there are reasons to work on frameworks like
that, but that work is just not addressing the leaky
password database threat, which is a real and current
problem.

S.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 12 Jul 2012 10:34:59 -0400

>>>>> "Richard" == Richard L Barnes <[email-masked]> writes:

    >> GSS/Kerberos or GSS/ABFAB on the web at large.

    Richard> We already have a WG for that

Which one are you thinking of?
Using GSS or ABFAB with HTTP is outside of the charters of kitten, abfab
and krb-wg at least as far as I know.

---

From: Nico Williams <[email-masked]>
Date: Thu, 12 Jul 2012 09:45:57 -0500

> responses like this that's probably a signal of a sort;-)

The IETF is about running code and rough consensus.  The IETF is not a
scientific organization.  Of course, running code is itself evidence
of something, typically that e good enough solution exists right then
to whatever problem -- good enough from an economic point of view.
Running code can also include can kicking exercises that put off
economic costs.

For example, we have running code right now that takes care of web
auth -- it's not *great*, and its occasional failures are starting to
grate, but it's certainly good enough from an IETF point of view.  Can
we do better?  Sure, but whether we do will depend on economics, and
we don't have to prove anything about the economics: that will work
out on its own.  Of course, it sure helps to have an accurate
understanding of the issues, so please do not get confused about what
I'm saying (I'm NOT  saying that "we don't need no stinkin'
evidence").

> password database threat, which is a real and current

It's one problem.  There's also phishing and other problems.  We can't
get a 100% solution.  That said, for those passwords that users can
get help managing, it's OK to generate them for the user, in which
case the leaky password database problem disappears completely.

Also, the framework approach fits other solutions *including* HOBA
(e.g., because TLS is the wrong layer for user auth), smartcards,
OTPs, and so on.

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Jul 2012 15:48:12 +0100

On 07/12/2012 03:45 PM, Nico Williams wrote:
> scientific organization.  

Thanks. The smiley above was there for a reason. You can relax.:-)

And I already said all that myself in an earlier mail.

S

---

From: Nico Williams <[email-masked]>
Date: Thu, 12 Jul 2012 09:50:24 -0500

> And I already said all that myself in an earlier mail.

Heh.  My turn.  Sorry!

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Jul 2012 15:51:29 +0100

Hi Sam,

On 07/12/2012 03:30 PM, Sam Hartman wrote:
>     Stephen> Like I said, there are reasons to work on frameworks like
>     Stephen> that, but that work is just not addressing the leaky
>     Stephen> password database threat, which is a real and current
>     Stephen> problem.
> 
> I think you're wrong when you say the framework work is not part of the
> leaky password database problem.

Not quite what I meant. I think the justification for frameworks
is far more related to engineering than security. (But that's ok.)

I reckon we could have much more impact on security via usable
non password schemes (if we can agree on 'em;-) than via frameworks
which mostly get put in front of password DBs.

> 1) Decoupling applications from their authentication mechanisms seems
> like it makes it easier to deploy non-password mechanisms.

Well, only if all services have shifted to the federated thing.
If a lot haven't then all clients and serves need to change for
any new scheme anyway.

> 2) It seems fairly likely that deploying non-password mechanisms will be 
> easier in the framework cases. That is, someone like Google and facebook
> are in a much better position to actually deploy tokens of some kind
> than some random website.

Maybe. I dunno about "fairly likely" since a lot of that is
about business issues, but I would hope sites like those must
be fairly nervous about how broad an impact leaking their
password databases might have.

> 3) Reuse of identity makes dealing with a compromise easier; I need to
> change a password in one place. Mitigating consequences of an attack is
> a valuable thing to do. Note of course that this concentration may
> create higher-value targets. In practice, people do enough credential
> re-use that it's not clear how real this is.

Right.

S.

PS: Another one today. [1] Sigh.

[1]
http://it.slashdot.org/story/12/07/12/1243217/nearly-half-a-million-yahoo-passwords-leaked

---

From: Derek Atkins <[email-masked]>
Date: Thu, 12 Jul 2012 11:47:34 -0400

> and krb-wg at least as far as I know.

Sam, You missed the rest of Richard's sentence, and didn't even deign to
quote it.  He said, in full, "We already have a WG for that: oauth".
And you can certainly use GSS or ABFAB for the "user<->AS" authN path
(because that flow is not defined by OAuth).

> https://www.ietf.org/mailman/listinfo/saag

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: "Adam W. Montville" <[email-masked]>
Date: Thu, 12 Jul 2012 09:13:42 -0700

> which mostly get put in front of password DBs.

I'm stepping out of comfort here, but it seems that we could realize some benefit with a framework generating sufficiently long pass phrases rather than pass "words."  Four randomly chosen words (of sufficient length) separated by spaces, for example, would increase the effort required for offline brute force attacks under many circumstances.  

A 100% solution this is not, but it would be something that might get some traction in the short term.

I like the notion of avoiding passwords entirely, however, if it can be done or at least moved toward.

Adam

---

From: Sam Hartman <[email-masked]>
Date: Thu, 12 Jul 2012 12:26:29 -0400

>>>>> "Derek" == Derek Atkins <[email-masked]> writes:

    >> and krb-wg at least as far as I know.

    Derek> Sam, You missed the rest of Richard's sentence, and didn't even deign to
    Derek> quote it.  He said, in full, "We already have a WG for that: oauth".
    Derek> 

my apologies.
I certainly would not have sent the message at all had I seen the rest
of the sentence.
I can't explain how I missed that but it was an honest mistake.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Jul 2012 17:35:07 +0100

> I like the notion of avoiding passwords entirely, however, if it can be done or at least moved toward.

I'd recommend a look at the phd thesis mentioned earlier. [1] It has
a very good state of the art chapter.

To be clear though: I don't think the way to replace passwords is
with....passwords:-)

S.

[1] http://www.cl.cam.ac.uk/~jcb82/doc/2012-jbonneau-phd_thesis.pdf

---

From: Mouse <[email-masked]>
Date: Thu, 12 Jul 2012 15:46:00 -0400 (EDT)

> I'm stepping out of comfort here, but it seems that we could realize some be$

I agree.  Randall totally nailed this in xkcd #936.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Yoav Nir <[email-masked]>
Date: Thu, 12 Jul 2012 23:05:42 +0300

> I agree.  Randall totally nailed this in xkcd #936.

I don't think he did. While there are only a few thousand common words that might be chosen for the base word, 2^28 is a very large number for guessing over the 'net. Any system worth its salt won't let an attacker guess 1000 times a second, and he overestimates the difficulty of remembering it.

On the other hand, 4 random common words are very hard to remember - you forget the order, you replace words, and the story you invent doesn't make sense, and gets mixed up with the stories for last month's passphrase. People would naturally not choose 4 independently random words. If the first word is "correct", the next is likely to be either something that is correct, or another adjective. Not a horse.

Make this the rule for wiki passwords for IETF meetings, and you'll have more than one instance of "explore strange new worlds", "rough consensus running code", and maybe even "d**n you perry platypus". These are the equivalents of "password", "pass1234", and "passw0rd", except this time, nobody's making us use numerals or symbols and mixed case to add unpredictability.

Yoav

---

From: "Adam W. Montville" <[email-masked]>
Date: Thu, 12 Jul 2012 18:44:36 -0700

>> I agree.  Randall totally nailed this in xkcd #936.

I like that one.

> I don't think he did. While there are only a few thousand common words that might be chosen for the base word, 2^28 is a very large number for guessing over the 'net. Any system worth its salt won'…

There are nearly 100,000 words in the English language (granted not more than 10,000 or so are likely to be considered common).  And, we're looking at database leaks, not brute-force.  If brute-force were the only problem, then properly designed systems (and many are not) could tolerate password lengths of eight with low complexity (just letters and numbers).

> On the other hand, 4 random common words are very hard to remember - you forget the order, you replace words, and the story you invent doesn't make sense, and gets mixed up with the stories for las…

Writing them down would help here, and that's not necessarily bad advice anymore.

> Make this the rule for wiki passwords for IETF meetings, and you'll have more than one instance of "explore strange new worlds", "rough consensus running code", and maybe even "d**n you perry platy…

Completely agree on this.  It changes the game somewhat, and the crackers would need to adjust their tactics.  But, what if it could buy some time in the short-term - until a better solution is available?

---

From: "Adam W. Montville" <[email-masked]>
Date: Thu, 12 Jul 2012 18:45:29 -0700

> To be clear though: I don't think the way to replace passwords is

Well, why not?  We replace keys with…keys ;-)

---

From: "Adam W. Montville" <[email-masked]>
Date: Thu, 12 Jul 2012 19:32:24 -0700

> There are nearly 100,000 words in the English language (granted not more than 10,000 or so are likely to be considered common).  And, we're looking at database leaks, not brute-force.  If brute-for…

Typed too fast on that one - potentially about 1 million words…

http://www.slate.com/articles/life/the_good_word/2006/04/word_count.html

---

From: Joel jaeggli <[email-masked]>
Date: Thu, 12 Jul 2012 20:20:34 -0700

>From a slide I present about once a year.

How good does a password/phrase have to be in order to
protect against brute-force or dictionary attacks against the
password itself?

● Entropy found in language.

– A typical english sentence has 1.2 bits of entropy per
character, you need 107 characters to get a statistically
random md5 hash.

– Using totally random english characters you need 28
characters.

– Using a random distribution of all 95 printable ascii
characters you need 20 characters.

* Derived from the PGP passphrase faq

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 13 Jul 2012 13:12:10 +0100

> Well, why not?  We replace keys with…keys ;-)  

Well, I meant replacing a password-based mechanism
with another password-based mechanism is not what I
think we want to do.

Replacing one password with another is of course a fine
thing to do sometimes. (As in today, for another 1M
account holders. [1] )

S.

[1]
http://www.zdnet.com/android-forums-hacked-1-million-user-credentials-stolen-7000000817/

---

From: "Adam W. Montville" <[email-masked]>
Date: Fri, 13 Jul 2012 06:12:53 -0700

> thing to do sometimes. (As in today, for another 1M

Point.