Subject: Re: NT RAS CCP oddity

From: Vernon Schryver <[email-masked]>
Date: Wed, 19 Jan 2000 12:20:13 -0700 (MST)

> From: Glen Zorn <[email-masked]>

> ...
> > > Now my interpretation is that it should be possible to transfer IP data as
> > > soon as IPCP negotiation has completed, regardless of the state of CCP
> > > negotiation.
>
> It depends.  If encryption (MPPE) is configured on the NT side, then it makes no
> sense to transmit data until the CCP negotiation is complete, in fact it would be
> a serious security hole.  This is because MPPE is negotiated as part of CCP.

Ah, yes, I'd forgotten that design flaw in Microsoft's proprietary,
non-standard, embrace-and-extend MPPE.

Note that the characterization "serious security hole" is based on the
unsupported and not generally accepted assumption that running with MPPE
is noticably more secure than running without MPPE.

Vernon Schryver    [email-masked]

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 19 Jan 2000 14:22:17 -0700 (MST)

> Be that as it may, the IPSec folks seem to think that negotiating crypto
> and compression at the same time is not a bad idea...

Nonsense!  It is often good to compress before encrypting, and if you're
encrypting, you don't want to pass any unencrypted data.  However, the
right way to have designed a PPP encryption scheme with obiligatory
compression would be to call it encryption and Configure-Reject or
Protocol-Reject CCP, and certainly not send any CCP Configure-Requests.
It would be a minor, irrelevant detail for an encryption scheme to put
ciphertext of fewer bits on the wire than the corresponding corresponding
cleartext.  It is simply and obviously wrong to intertwine CCP and ECP as
Microsoft has done with MPPE.

> Sure, encryption, cleartext, it's all the same, right?

In many cases, that is right.  Outside of what I recently saw described
in either the Wall Street Journal or ABC News as the "unusually insular"
culture at Redmond is the common observation that many home grown
encryption schemes are not usefully different from cleartext.  In other
words, has MPPE been examined by independent experts, and if so, did they
find it better than the other Microsoft PPP encryption efforts?

It should also be noted that link layer encryption by its nature adds
little or no real security.  People who understand the issue and really
need encryption do it at a higher layer, such as with IPSec, so that none
of their cleartext is routers controlled by potentially interested
strangers.

---

From: Jonathan Goodchild <[email-masked]>
Date: Thu, 20 Jan 2000 17:20:28 -0000

From Glen Zorn:

> If encryption (MPPE) is configured on the NT side, then it makes no
> a serious security hole.

Hmmm, I'm not sure that I agree with this.  It seems to me that there are 3
possibilities with encryption:

1) You don't do any encryption;
2) You don't need to do encryption, but you're quite happy to do so if the
peer wants to;
3) You insist upon encryption.

Why should the state of ECP (or CCP in the case of MPPE) negotiation affect
what you do with received data packets in any of these cases?

Obviously in case #3 you never send any clear text data and always discard
received clear text data.  Equally obviously, in case #1 you should be able
to transfer data as soon as the NCP negotiation has completed.  

That leaves case #2 (and frankly I don't see how it's any different from
case #1 from a security viewpoint): seeing as you're prepared to accept
clear text data eventually, I don't see how a security hole is introduced by
accepting the data packets before ECP negotiation has completed.  

Jonathan Goodchild