Subject: Re: PPP encryption documents

From: Vernon Schryver <[email-masked]>
Date: Wed, 24 Jun 1998 14:09:49 -0600 (MDT)

> From: Thomas Narten <[email-masked]>

> ...
> During the IESG discussions, we observed that the two PPP encryption
> drafts only do encryption, and do not include any authentication. The
> IPSec folks were convinced a while back that encryption without
> authentication (i.e., integrity protection) is a Bad Thing.
> ...

How is that?  Why doesn't having enough valid keys to encrypt and decrypt
the data implicitly authenticate the identity of the sender to the
receiver?  (assuming, of course, there is protection against replay, etc.)

> ...
> The WG may also decide that its worth defining a stronger transform
> that does both encryption/authentication.  ...

Given the very unfortunate history of PPP authentication (bugs, holes,
bad implementations, after LCP instead of during), having yet another kind
of PPP thing also called authentication sounds like can of worms.

> ...
> It is probably also worth noting that the use/deployment of L2TP
> tunnels may increase the desirability of having a per-packet PPP
> authentication capability, something that is missing now (one can
> authenticate the creation of a session, but not each individual packet
> of the session).

Given the problems the L2TP people have had with security, that sounds a
little messy.  At the very least, such considerations should not be allowed
to derail or delay L2TP. 

Besides, isn't the L2TP position that anyone who really cares about
security below the application layer will be using IPSEC below the L2TP-PPP
tunnel?

Consider that PPP is a link-layer protocol, even when used for tunneling.
Wouldn't it be cleaner all around to say "if you want security, use
IPSEC"?

And again, if the bad guy has enough keys to encrypt or decrypt data,
why won't he also have enough keys to authenticate forgeries?

Vernon Schryver    [email-masked]

---

From: Thomas Narten <[email-masked]>
Date: Thu, 25 Jun 1998 07:02:58 -0400

> little messy.  At the very least, such considerations should not be allowed

I mentioned L2TP only in the sense that a stronger PPP authentication
mechanism might be useful to L2TP. Actually, to a client running PPP
that suspects that L2TP is being used. Specifically, if you are a
client, and you don't know anything about how L2TP is being used by
your ISP, the standard thing to do is assume the worst and do you own
end-to-end encryption/authentication. Right now, that does not include
strong authentication at the PPP level.

I would agree that using IPSec as part of the L2TP infrastructure
makes sense, but that is not something the end user has control
over. (The end user could also of course run IPSec end-to-end across
PPP, but that would only help IP traffic.)

Also, to clarify, although L2TP is being considered by the IESG at
present, it's outcome is not tied to this discussion.

> security below the application layer will be using IPSEC below the L2TP-PPP

The end user doesn't have control over this. Isn't one of the goals of
L2TP that it is completely transparent to the client? I.e., the client
doesn't even know it's being used.

Thomas

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 25 Jun 1998 10:45:20 -0400 (EDT)

There are two issues here. Protecting L2TP, and protecting PPP that is
being tunneled by L2TP. There are also two deployment models. 

Thomas is referring to the model where L2TP is transparent to the PPP
user. Assuming the peer dialing into the ISP even knows that L2TP is being
used to create his/her VPN, it is not up to the PPP peer (from the
protocol's perspective) to dictate whether or not IPSec or any other type
of protection over the L2TP tunnel is used. In this case, the ISP is
initiatiating the tunnel, thus it is the ISP's responsibility to provide
whatever level of protection that the client is paying for and that the
ISP is willing to live with. If the client is truly concerned about the
*privacy* of his or her data, then a form of end to end encryption should
always be used (PPP, IP, Application level or otherwise). 

If the end user is not only running PPP, but initiating L2TP as well
(sometimes referred to a PPP/LAC client), then it is up to the client
provide whatever L2TP protection is desired. In this case, IPSec can and
should be used by the client. PPP encryption alone would of course only
serve to protect the PPP data, not the L2TP control messages and
encapsulation (not to mention UDP/IP running under L2TP). The bonus here
is that since L2TP and PPP are intiated and controlled by the same source,
if L2TP is protected, PPP is protected as well, so PPP encryption is not
necessary.

---

From: Chip Sharp <[email-masked]>
Date: Thu, 25 Jun 1998 11:31:35 -0400

Some additional comments:
>always be used (PPP, IP, Application level or otherwise). 

The client can run IPSEC end to end (assuming the client's IP stack
supports it of course).  PPP encryption only runs from the client to the
LNS.  Of course, this could/would end up with the ISP protecting the
tunnel with IPSEC and the client protecting their transmission with IPSEC.
>if L2TP is protected, PPP is protected as well, so PPP encryption is not

There is an interesting component to client tunneling.  Running IPSEC on
the transport IP stack would protect the L2TP info, but only runs from the
client to the LNS.  True "end-to-end" encryption would use IPSEC on the
upper IP stack.  This would protect the data from the client to the
destination application, but would not protect the L2TP control messages.
Of course, you could run IPSEC on the upper IP layer to protect the
end-to-end data and (a different instance) on the transport IP stack to
protect the L2TP control messages. aaack!

M.C. Escher could probably draw a good diagram of this. ;-\
Chip 

>> doesn't even know it's being used.
--------------------------------------------------
Chip Sharp			voice: +1 (919) 851-2085 
Cisco Systems		Mgr - Telco Consulting  			
--------------------------------------------------

---

From: Philip Rakity <[email-masked]>
Date: Thu, 25 Jun 1998 11:56:32 -0700 (PDT)

We run RFC1669 PPP DES Encryption over a L2TP link to provide security
between the LAC (eg our L2TP Client) and the LNS.  The encrypted tunnel is
created between us and the LNS and is not visible to the ISP, and the
link is secured between the LAC and the ISP since it is encrypted. 

The security of the encrypted link depends upon the ablility to break DES
and the ability to break the MD5 hash for CHAP (assuming that one is NOT
stupid enough to use DES without authentication).  We have implementated a
DES key exchange mechanism using public keys.   All of this was done
without IPSec.

The major security hole with this scheme is that it assumes that the LNS
is in a secure environment as per Chip's observation and that
authentication is done by both parties.

regards,

Philip Rakity
FlowPoint Corporation

---

From: Karl Fox <[email-masked]>
Date: 25 Jun 1998 15:11:54 -0400

> We run RFC1669 PPP DES Encryption over a L2TP link to provide security
            ^^^^1969
> and the ability to break the MD5 hash for CHAP

Are you sure about this?  If someone cracks your DES key but not the
CHAP MD5 key, can't they inject encrypted packets into your L2TP
stream?
-- 
Karl Fox, servant of God, employee of Ascend Communications
655 Metro Place South, Suite 370, Dublin, Ohio  43017   +1 614 760 4041

---

From: Philip Rakity <[email-masked]>
Date: Thu, 25 Jun 1998 12:14:55 -0700 (PDT)

If they break my des key then no authenication helps.

Philip