Subject: Re: (radius) Re: Comments on Tunnel Draft

From: Barney Wolff <[email-masked]>
Date: Fri, 10 Dec 1999 11:50 EST

There has been much discussion of Tunnel-Password, and RADIUS proxying
in general.  That both User-Password and Tunnel-Password will be
visible to proxies is well known.  I believe deprecating Tunnel-Password
is overkill - not everybody uses proxies, proxies may in fact be
within a single organization or otherwise trusted, or the attribute
may be added by the proxy closest to the NAS.  There is no necessary
relationship between the tunnel destination and the RADIUS server.

Using Tunnel-Password to distribute an IKE secret is clearly a misuse,
but nothing in the draft suggests this use.

In addition to the implementations already cited, both 3Com and AT&T
support and use Tunnel-Password.

I would support adding a warning that the attribute will be visible
to proxies, but nothing beyond that.

Barney Wolff  <[email-masked]>

> Date: Fri, 10 Dec 1999 11:38:45 -0500
> From: Ran Atkinson <[email-masked]>
> 
> Based on Darran's note, I'd suggest:
> 	- Formally deprecate Tunnel-Password with text explaining
> 	  how it means that one gets ZERO effective security,
> 	  but keep it documented.  Actually recommend that folks
> 	  either not implement it or provide a configuration knob
> 	  to disable it.
> 
> This means existing users aren't completely hosed and that we've
> done our part to make it clear that the usage is insecure as heck
> and should go away in future.
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 10 Dec 1999 09:14:27 -0800

>relationship between the tunnel destination and the RADIUS server.

I guess I don't get it. It sounds like L2TP is being run over a 
non-trusted network since the key is used to encrypt L2TP AVPs. However,
running L2TP over a non-trusted network is a Bad Thing (TM). There are
simply so may denial of attacks, and theft of tunnels that can occur
that I don't see why this particular attribute will solve L2TP over
non-secure networks.

I understand the reason why some people that have current implementations
are reluctant to remove it, but keep in mind that the security ADs will
probably have a field day with this one :(

>but nothing in the draft suggests this use.

Well, one of the Tunnel-Types is IP Security. So, if one reads the
draft, one SHOULD assume that the Tunnel-Password can be used for pretty
much any of the Tunnel-Types, including IKE or even ESP and AH!

PatC

-

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 10 Dec 1999 09:32:05 -0800

>one thinks one is being baited.
>
>I think several other major "foolish" vendors have also implemented this
>attribute... most likely because they had big accounts shouting
>for it.
>
>Deprecation usually implies something better. Where is it? 

http://www.ietf.org/internet-drafts/draft-ietf-pppext-l2tp-security-05.txt.

If there are too many people that have actually implemented the draft,
and these same vendors also sell this to their customers as a "security"
feature, I agree that removing it altogether will be very difficult.

just to be clear, I think that the draft is needed, and should move ahead.
I just had a problem with this attribute. If it isn't as clear cut as 
simply removing the attribute because L2TP is not being secured using IP
security, then move the draft ahead. I still think it's a bad idea, but I 
won't pursue this avenue any longer.

PatC

>How many
>clients currently want it? Thats where Cisco's motivation comes from.
>
>Darran
>
>----- Original Message ----- 
>To: Darran Potter <[email-masked]>
>Cc: Ran Atkinson <[email-masked]>; <[email-masked]>
>Sent: Friday, December 10, 1999 5:09 PM
>Subject: Re: (radius) Re: Comments on Tunnel Draft 
>
>
>> 
>> Darran,
>> 
>> You don't seem to follow the meaning of "deprecated".
>> 
>> A deprecated variable is still _defined_, so folks foolish enough
>> to use it may do so.  However, folks are explicitly discouraged (not
>> prohibited) from implementing/using it for the reasons stated.
>> 
>> This variable is basically insecure in all conditions that I can
>> think of, so it should be deprecated.  It will continue to be used, 
>> regardless of how insecure it is, so it needs to continue to be defined.
>> 
>> Mind, there are other bits of RADIUS that are also insecure.  
>> The whole use of "authentication" in the context of RADIUS is actually
>> pretty amusing (a kind of schadenfreude, for those who know Deutsch).
>> 
>> Ran
>> [email-masked]
>> 
>> 
>> -

-

---

From: Barney Wolff <[email-masked]>
Date: Fri, 10 Dec 1999 12:40 EST

> From: Patrice Calhoun <[email-masked]>
> Date: Fri, 10 Dec 1999 09:14:27 -0800
> 

In order for an attacker who cannot sniff packets to destroy or steal
a tunnel, he must get all of the following right:
  2 IP addresses
  2 random UDP ports (assuming ports are chosen sensibly)
  1 tunnel id
  Ns within the window

Yes, if the attacker can see as well as inject packets nothing short
of IPSEC will do.  I will point out that an active attacker can put
quite a load on an IPSEC host, even though the attack will not break
its security.

Tunnel-Password's use in adding some minimal assurance of partner
identity is my primary need for it.  There are major networks that
are source-addr-spoofable but not sniffable, and in some cases we
have to partner with them.

---

From: Ignacio Goyret <[email-masked]>
Date: Fri, 10 Dec 1999 11:39:36 -0800

Trying a second time, to see if the mailing list filter let's me through.

>Date: Fri, 10 Dec 1999 08:41:50 -0800
>To: "Darran Potter" <[email-masked]>
>From: Ignacio Goyret <[email-masked]>
>Cc: "Randy Bush" <[email-masked]>, "Patrice Calhoun" <[email-masked]>, <[email-masked]>
>
>Ascend (now Lucent) supports Tunnel-Password in all recent versions of
>TAOS (MAX and TNT). It is not used for IPSEC or IKE.
>-Ignacio
>
>
>At 03:58 PM 12/10/99 -0000, Darran Potter wrote:
>>Both UNIX and NT versions of CiscoSecure support the Tunnel-Password. On the
>>NT side, at least, we have clients who use it as
>>a key part of their business. IOS has has support for a while too.
>>
>>We also interoperate with Ascend customers who use it.
>>
>>I'd say removal at this stage would probably upset a lot of people.

A lot of our customers would be extremely unhappy, to say the least.

>>[email-masked]
>>From: Randy Bush <[email-masked]>
>>To: Patrice Calhoun <[email-masked]>
>>Cc: <[email-masked]>
>>Sent: Friday, December 10, 1999 3:21 PM
>>Subject: (radius) Re: Comments on Tunnel Draft
>>
>>
>>> is the tunnel password feature actually in use?  if so, it will be hard to
>>> justify removing it from the doc.  though it sounds as if a large warning
>>> would be well advised.
>>>
>>> if it is not actually used, or is used in an extemely minor place/way,
>>then
>>> removing it might be appropriate.  if it is removed, a note might go in as
>>> a placeholder.
>>>
>>> randy
>>> -
-