Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 20 Jan 1999 09:18:01 -0800

>- Threats that are appropriate to different scenarios
>

For PPP-based tunneling (L2TP & PPTP), the threat model is
covered in draft-ietf-pppext-l2tp-security-03.txt. 

I would remind people that in PPP-based tunneling, PPP security is
negotiated between the client and the tunnel server, and covers
the entire length of the path. This is because the client does not
have a way to know that they are being tunneled. Thus, any
security the NAS may negotiate with the tunnel server will occur
in addition to that negotiated between the client and NAS. 

In L2TP compulsory tunneling, this means that PPP encryption 
and compression will be negotiated between the client and the
tunnel server. In addition, the NAS may bring up an IPSEC ESP SA
between itself and the tunnel server. This adds protection against
a number of possible attacks which are discussed in the L2TP
security draft. 

This means that it is not correct to say that the NAS is completely
responsible for the security of the tunnel. 

I would also note that people should not assume that the tunneling
will always occur over IP. L2TP can run over non-IP media, such
as Frame Relay and in these cases, it will be common to not have
any NAS-LNS security. 

I would also note that many of the arguments that have been made
here can also be made against IPSEC tunnel mode operating in a
router-router environment. After all, if the router does not set up the
tunnel correctly, then the encapsulated IP packets will be sent in
the clear. It is interesting to note that L2TP is actually *more* secure
than IPSEC tunnel mode in this case, since PPP security can
be negotiated between the client and LNS. 

>- Available or needed protection mechanisms for each scenario
>

You are essentially asking for a security analysis for each 
tunneling protocol. 

Such an analysis belongs in the relevant protocol drafts, not in
this set of documents. 

In particular, if there are objections to the use of compulsory
tunneling for L2TP or IPSEC, then these objections should have
been raised to the protocol drafts. To my knowledge they have
not been raised. 

-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 25 Jan 1999 01:00:13 +0100

>a number of possible attacks which are discussed in the L2TP

Bernard, these two paragraphs form a completely adequate (to me)
security section for the tunnel-impl draft!
(Of course, this depends on L2TP always using PPP inside; is this
always true?)
Glenn, Bernard, is it OK to take this text and put it there?

>You are essentially asking for a security analysis for each 

Absolutely.
That is *exactly* what a security section is supposed to be.
Or rather, for the tunnel-auth draft: The list of questions that each
mode of operation raises, which each tunnelling protocol has to answer.

>Such an analysis belongs in the relevant protocol drafts, not in

The answers, yes. The questions, no.

>been raised to the protocol drafts. To my knowledge they have

Failures of others.....the L2TP documents have been yelled at,
objected to, commented and asked for revisions of on so many other
points (including the need to document numerous security problems)
that the particular issues that pertain to operating a NAS box that
is not implicitly in the same trust domain as the tunnel endpoint
have not been raised.
It does not excuse us; WE are the ones responsible for the multi-domain
situation.

                  Harald

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

-