Subject: RE: PPTP AUTHENTICATION

From: Vernon Schryver <[email-masked]>
Date: Wed, 16 Jun 1999 13:10:10 -0600 (MDT)

> From: Gurdeep Singh Pall <[email-masked]>

> ] There's nothing in the standard protocols that would prevent them from
> ] doing that and eliminating MS-CHAP-v-anything.

> James, how do you do change password (a feature in ms-chap-v-anything) with
> a "standard" protocol?

It is a serious mistake to try to cram all possible interactions between
computers into PPP.  We have more than one protocol, because as with
programs, spaghetti protocols are unmaintainable and do not work well if
at all.

It is also widely considered a serious security error or at best very
dangerous to allow the protocol or mechanism that performs identity checks
(i.e. "authorization") to also change the authenicating data.  That common
wisdom has been learned the hard way in many places and times.  If you
think about it for a few minutes from the point of view of a bad guy, it's
obvious why that is the common wisdom.

Nevertheless, there are many ways that ms-chap-v-something could
interoperate with standard CHAP and also support changes in the CHAP shared
secret.  (Note that there is no password in the standard CHAP protocol.
Instead there is a shared secret.  That distinction is important.)
One way that ms-chap-v-something could support changing the password would
be to use some vendor PPP packets to do Diffie-Hellman exchange, first
establishing a temporary shared secret than then communicating the new
CHAP secret.   That would be secure against eavesdroppers, and would
require no more than 1.5 round trips in the absense of packet loss.  
Again, that protocol, like many others, could be entirely compatible and
interoperable with standard CHAP.

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 16 Jun 1999 14:18:26 -0600 (MDT)

> So there is *no* standard protocol that supports change password. 
>
> Thanks for clarifying that you made a mistake in your somewhat loose
> comment.

As you know, his comment was not loose and he made no mistake.

> PS: your plausible attempt to show change password as a "bug" is sure to
> impress some folks. I stopped reading after the small leap "first I steal a
> copy of MD4 hashed registry...." 

As you know, the reason why the NT designers followed UNIX and chose to
not put the cleartext version of the user's password in the registery is
that no file is secure.  You must assume that the bad guys can use any of
the familiar ways to get the contents of any particular file.  That is
why except for network things, the NT registry password scheme is
reasonably secure.

For your implication that the contents of the registery are unlike other
data and magically secure, there is also the problem of snooping for the
old clear-text passwords on any LAN running previous versions of Microsoft
software.  As far as I can tell, those clear text passwords can be hashed
by a bad guy, and then fed into MS-CHAP.  Am I wrong?  True, if I'm right,
then the bad guy would need access to a wire on the target network.  As
you know, there are few places in the world where a bad guy cannot
"social-engineer" access a LAN, and most security problems involve insiders
who start with at least access to the company intranet.

There's something related with the new "encrypted passwords" of SMB that
no one I've asked has taken the time to explain to me.  How does the new
encrypted password required for mounting a share differ from the old NT
registery hash value?  If I put a network snooper (especially any of the
many software products that run on Windows 95, Windows 98, NT, or UNIX)
on a LAN and watch shares mounted, can I use the "encrypted passwords"
what I will see?  My guess is that the so called encrypted passwords are
only a hash of user's password in the grossly insecure style of MS-CHAP,
telnet, and rlogin, and so can be replayed in the time honored fashion.
In other words, I guess that SMB ships cleartext passwords over the wire.
Is that a valid guess?  Actually, my guess is that I could use those
"encrypted passwords" with MS-CHAP, without access to the machine running
the registry or anyone noticing.  Is that the case?

If my guesses are true, what about your implication about security of the
contents of the registry?

Vernon Schryver    [email-masked]

---

From: Eric Michelsen <[email-masked]>
Date: Thu, 17 Jun 1999 09:25:41 -0700

I'm almost afraid to get into this, but I want to acknowledge a small
observation that was made a year or two ago about this.  There are two
small, but non-zero, benefits to using a "hard-to-remember" string of bytes
instead of the user-visible "easy-to-remember" string of bytes as the
password.  

1. If someone is idly using a sniffer to investigate a network problem
(which I have done in the normal line of duty), and they see all kinds of
simple "easy-to-remember" passwords flashing by on the monitor, they can
easily pick out and remember several of the passwords.  And so can anyone
with virtually no technical knowledge who happens to walk by the sniffer,
thus slightly degrading security.

2. Human beings often choose passwords that are related.  Right or wrong, it
is a fact.  If I know your password on one machine is "benson", then I may
well guess that your password on another machine is "hedges".  In a perfect
world, this wouldn't be true.  But in a perfect world, we wouldn't need
security.

I'm not defending anyone's practice, and I'm not saying these benefits are
intentional or worth any particular amount.  But they are real.
-------------------------------------------
Eric L. Michelsen, Copper Mountain Networks 

> -----Original Message-----
> From: James Carlson [mailto:[email-masked]]
> Sent: Thursday, June 17, 1999 3:47
> To: [email-masked]
> Subject: Re: PPTP AUTHENTICATION
> 
> 
> [email-masked] (Gurdeep Singh Pall) writes:
> > The point (I'll spell it out this time) is that once the 
> shared secret is
> > stolen (by stealing the registry, reading clear text 
> password files, etc)
> > any shared secret based authentication method (CHAP, 
> MS-CHAP) is compromised
> > and all bets are off. 
> 
> Absolutely true, at least for PPP authentication.  Of course, systems
> that permit use of a *separate* shared secret for CHAP and a password
> for authentication to network nodes can be more secure than those that
> promiscuously use a single 'password' for all access.
> 
> > I agree that one-way-hashed secret is no more secure on the 
> wire than the
> > secret itself since it too has the time invariant property. 
> I dont recall
> > anyone claiming otherwise.
> 
> Really?  Then why does RFC 2433 say this on page 2:
> 
>       * The MS-CHAP Response packet is in a format designed for
>         compatibility with Microsoft's Windows NT 3.5, 3.51 
> and 4.0, and
>         Windows95 networking products.  The MS-CHAP format does not
>         require the authenticator to store a clear-text or reversibly
>         encrypted password.
> 
> In fact, MS-CHAP *does* require the authenticator to store a
> "clear-text password" in exactly the same manner as standard CHAP.
> That this "password," or secret, is a hard-to-remember string of bytes
> produced automatically by some algorithm is completely irrelevant.
> 
> -- 
> James Carlson, Software Architect                   
> <[email-masked]>
> IronBridge Networks / 55 Hayden Avenue   71.246W   Vox:  +1 
> 781 372 8132
> Lexington MA  02421-7996 / USA           42.423N   Fax:  +1 
> 781 372 8090
> "PPP Design and Debugging" --- 
http://people.ne.mediaone.net/carlson/ppp

---

From: Gurdeep Singh Pall <[email-masked]>
Date: Thu, 17 Jun 1999 10:36:19 -0700

-----Original Message-----

> I agree that one-way-hashed secret is no more secure on the wire than the
> secret itself since it too has the time invariant property. I dont recall

      * The MS-CHAP Response packet is in a format designed for
        compatibility with Microsoft's Windows NT 3.5, 3.51 and 4.0, and
        Windows95 networking products.  The MS-CHAP format does not
        require the authenticator to store a clear-text or reversibly
        encrypted password.

gurdeep> This comment in RFC 2433 is absolutely accurate. You can implement
MS-CHAP if you all you have is the hash instead of the clear text password
stored. 

gurdeep> Wrong. Just so that we align our definition - "clear text password"
is what the user typed in. This is NOT stored as is. The fact that there may
or may not be any value in one-way-obfuscating this "clear text password"
before storing it is not in debate.

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 17 Jun 1999 12:39:07 -0600 (MDT)

> ...

Not so!  The string on the wire may look like gobbledegook, but it is a
cleartext password as the term is understood among the technically
literate.  See for example, page 1 of "Applied Cryptography" by Schneier.

Putting a front-end on PAP that converts (e.g. by hashing) what the user
thinks is the password to something else that goes over the wire would
not change PAP to not use a cleartext password.  If MS-CHAP does not use
a cleartext password, then neither does PAP.  If PAP does use a cleartext
password, then so does MS-CHAP.

That text from RFC 2433 might be literally true in a contorted, user
interface sense, but it conveys a notion that we all (including Microsoft)
in the IETF PPP WG have agreed is false for the last few years.  (Recall
or check the archives for the long discussion in this mailinglist.)  I
wonder what the lawyers at Microsoft or any outfit with deep pockets
would say about the false assurance of security that text conveys if they
knew about it.

> before storing it is not in debate.

The password used by MS-CHAP is a cleartext password as far as the
authentication protocol is concerned and in the eyes of the technically
knowledgable.  What the user types is irrelevant.  Whether the translation
from what the user types to what goes over the wire is the identity map,
hashing, a look-up in a disk file, a conversion of mixed upper and lower
case to upper case, conversion from ASCII to EBCDIC, or something else or
is irrelevant to whether what goes over the wire is a cleartext password.
User-intefaces issues are important, but they have long been outside the
scope of the IETF PPP WG.  Reasonable people might say that's bad, but it
is a fact.

Separately, the value of cleartext goobledygook passwords compared to
easily remembered (by humans) cleartext passwords is overrated.  It might
be harder for someone who does not care to break into a system to remember
cybercrud, but those people are not a threat, since by definition they
don't care.  The people you need to worry about are those who will set
their sniffers to capture the right bits, and then right them down.
Passwords that are vulerable to dictionary attacks are not made
significantly worse by the use of other vulnerable passwords.

---

From: Barney Wolff <[email-masked]>
Date: Thu, 17 Jun 1999 15:57 EDT

Are you folks debating the cleartext-ness of the password as stored by
the authenticator, or what goes over the wire?  I believe that what is
stored is equivalent to cleartext, but unless I'm sadly mistaken,
MS-CHAP is CHAP-like in that what goes over the wire is not the actual
password or a fixed hash of it and does depend on the challenge.

Barney Wolff  <[email-masked]>

> Date: Thu, 17 Jun 1999 12:39:07 -0600 (MDT)
> From: Vernon Schryver <[email-masked]>
>

---

From: Gurdeep Singh Pall <[email-masked]>
Date: Thu, 17 Jun 1999 13:30:46 -0700

You are not mistaken. On the wire CHAP and MS-CHAP are equivalent in that
both produce a response that is a fucntion of the secret and the challenge. 

As far as stored "secrets" are concerned there is no claim that storing
"user password" is significantly worse than storing its one-way-hash if both
are treated as "first order" secrets (as in CHAP or MS-CHAP). But this isnt
the first time on the ppp list that non-issues have been debated ad nauseam
:-)

Gurdeep

---

From: Gurdeep Singh Pall <[email-masked]>
Date: Thu, 17 Jun 1999 11:59:15 -0700

The clear text password and its hash are equivalent from protocol
standpoint. No argument. No one has claimed otherwise.

MS-CHAP does NOT require clear text password (as the user typed in) to be
available since it works off the one-way-hash. Therefore the comment - "The
MS-CHAP format does not require the authenticator to store a clear-text or
reversibly encrypted password." is absolutely true. If you are reading
implications beyond this - thats, er, your problem.

Gurdeep