Subject: Re: Secure Remote Password interest

From: Vernon Schryver <[email-masked]>
Date: Wed, 21 Mar 2001 11:07:02 -0700 (MST)

> From: James Carlson <[email-masked]>

> ...
> I agree that's a problem, but I think it's out of scope.  We don't
> deal with user interfaces here, do we?

On the contrary, we must deal with how PPP can and will be used in real
life.  Real life dictates that the entropy of passwords is low.
Moreover, the draft already makes statements touching on this issue.

> ...
> OK; I can note that good password choice is hard and that choosing bad
> passwords makes a dictionary attack much easier.

I'd feel better with stronger words than those.

Part of my problem is that I've argued in public with Thomas Wu and others
about so called zero knowledge password systems and feel that they advocate
their schemes as ways to make garbage passwords tolerable on Duh Internet.
When pressed on that issue, they agree (Thomas Wu more readily than others)
that garbage passwords are always Double Plus Not Good(tm).

For the sort of thing that has sensitized my hackles, please read
http://www-cs-students.stanford.edu/~tjw/srp/analysis.html
Is is simply wrong to claim as he does that CHAP amounts to "weak
authentication."

> The situation is still far better than CHAP.  If you steal the secrets
> from a CHAP authenticator, then you're in with no work at all.  It
> doesn't matter how good the secrets are.
>
> The real issue is that users have to evaluate the threat model and
> adjust accordingly.  For many common configurations, SRP is simply
> much better than CHAP.  It doesn't have the same exposure.

No, the most important exposure remains unchanged.  That is really
bad passwords, such as username and password the same.  SRP does
nothing against really bad passwords, which is ok, since nothing can
help there.  It's not ok that common sales literature implies that
such protocols do help against really bad passwords.  The IETF should
not endorse or repeat that snake oil.

SRP is like using the stength of the passwords themselves to protect the
CHAP cleartext database.  That's worthwhile, but not what is commonly
claimed, that CHAP is "weak authentication" and SRP is strong.  Contrary
to the claims of SRP and zero-knowledge advocates, because of the random
challenge all but the really bad CHAP passwords are proof against on-line
attacks (only on the wire, no access to the cleartext database).

> > Yes, but that was not the big mistake of MSCHAP.  The mistake was not
> > that MSCHAP was a bad idea, since it was a good idea,  The problem
> > was that the MSCHAP selling was based on snake-oil.  It was sold as
> > being significantly more secure than CHAP, when it fact it was only
> > more secure against the unithinking or unmotivated.
> ...

> No.  In fact, the MD4 hash is the shared secret.  It is therefore
> equivalent to CHAP.  It's not a good idea.  It's not worthwhile.  (And
> yes there are also flaws that make it *less* secure than CHAP.)

Making the shared, cleartext password secret be something other than what
the unthinking user thinks is nothing to write home about and it had no
effect on the security of the system against a motivated and thinking
attacker.  Still, it does significantly protect against casual attackers,
and as you say elsewhere, that is important when what you're talking about
something such as a PPP connection with so little value.

MSCHAP was a major security improvement in protecting the authenticator's
database only if you make the obviously false assumption that no one is
smart enough to use the MD4 hash of the nominal password.  PPP-SRP
similarly protects the authenticator's database only if you make the
obviously false assumption that real passwords resist not only on-line
but also off-line attacks.  When talking about a security protocol, you
can't close a hole by labeling it mere human nature or a user interface
interface issue.  Whether you're selling MSCHAP, SRP, or zero-knowledge
passwords, you don't get to adjust reality to prove a protocol's security.

> ...
> I mean text that would be useful in a draft.  :-/

   The user's choice password SHOULD be restricted to limit the
   effectiveness of dictionary attacks.  However, unless the individaul
   passwords or secrets are uncharacteristically well chosen, the hash
   values stored in the authenticator's database MUST be protected
   against disclosure.  In practice, even when the user's choices of
   passwords is restricted, passwords have only a couple dozen bits
   of entropy.  Off-line dictionary attacks on the database of hashes
   are feasable unless the each password has 100 or more bits of
   entropy.  Even passphrases are rarely that strong.  Thus, the
   authenticator's database MUST also be kept secret much as the UNIX
   /etc/passwd or /etc/shadow are today.

The password generators and limiters I've seen force users to have better
passwords, but they are still far short of resistent to serious dictionary
attacks.  I personally think that the password generators are a bad idea,
since they merely force users to put their passwords on Postit Notes next
to their monitors, but that's not entirely relevant to PPP.

Vernon Schryver    [email-masked]

---

From: James Carlson <[email-masked]>
Date: Wed, 21 Mar 2001 13:26:46 -0500 (EST)

> Is is simply wrong to claim as he does that CHAP amounts to "weak

I agree with that.  The problem with CHAP isn't on the wire.  It's in
the database.

> bad passwords, such as username and password the same.

There's more than one exposure here.  CHAP has the same dictionary
guessing exposure as SRP.  If I trap a CHAP Challenge and Response
from the wire, then I can use a dictionary attack to reveal the shared
password used to generate that given Response from that given
Challenge.  for (i in guesses) if MD5(id,i,chal)=response print i;

At least theoretically, having multiple different Challenges and
Responses should make this attack easier by giving additional key
material.

The random ID does no good here.

SRP essentially moves this same vulnerability out to the database.

>  SRP does

Fine; I can certainly have a "no bad passwords" statement in the
draft.  I've already agreed that this is a reasonable thing to do.

> attacks (only on the wire, no access to the cleartext database).

As described above, that's not true.  If you can mount a dictionary
attack against the SRP hashes, then you can mount the same attack
against the CHAP Response values.  It's no different.

In fact, it's a little easier to do with CHAP; less computation
involved.

> something such as a PPP connection with so little value.

The problem was that the security of the hash itself was sold as an
improvement.  This part is a lie.  It's not an improvement.  In fact,
since administrators often think of the hashes as more secure, it's a
significant problem.  They now have what appear to be nice hashes, but
are actually cleartext passwords.

> passwords, you don't get to adjust reality to prove a protocol's security.

I don't think it's reasonable to say that we're going to somehow
upgrade the users themselves through force of IETF documents.  I'm not
making the assumption that real and bad passwords resist reasonably
determined attacks.  I am making the assumption that good passwords do
resist such attacks, and the current state of the art (prior to SRP)
does *NOT* allow the administrator to take advantage of that.

I don't think it's possible to fix the stupid user problem by IETF
documentation.  I'd like to avoid trying to do the impossible and
stick to the protocols.

Do you disagree that SRP is an improvement over CHAP and PAP?

[...]
>    /etc/passwd or /etc/shadow are today.

Perfect; that fits the situation exactly.  Thanks; I'll add it to the
next update.

> to their monitors, but that's not entirely relevant to PPP.

True ...

-- 
James Carlson, Internet Engineering       <[email-masked]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677
Second Edition now available - http://people.ne.mediaone.net/carlson/ppp