Subject: (radius) Comments on Tunnel Draft

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

Although I find the document very useful, and think that it should be
moved to proposed standard, I do have a problem with one attribute defined
in the said draft.

The attribute is called the Tunnel-Password. This attribute has been the
subject of quite a bit of controversy in the past, and I am quite surprised
that it wasn't removed. The problem that I have with it is that in
roaming environments, the intermediate nodes have access to the plain
text password. This "encryption" is hop-by-hop, and in roaming environments
traverses "untrusted" hosts. 

The real purpose for the Tunnel-Password is to secure L2TP, but the L2TP draft
does state that if one does want a secure tunnel (and one should), IP Security
MUST be used. There is a whole I-D that discusses how L2TP and IP Security
are used together. Therefore, this attribute has questionable value. 
Furthermore, since the draft doesn't actually state that this attribute is 
ONLY for L2TP tunnels, there are people out there wanting to use this 
attribute for other reasons, such as passing around IKE pre-shared keys in
roaming environments.

In principle I don't have a problem with AAA protocols generating the keys. 
However, due to the nature of the RADIUS protocol, and the security weaknesses 
in roaming networks, I would prefer to see support for the Tunnel-Password 
removed.

Flame on!

PatC

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

---

From: Randy Bush <[email-masked]>
Date: Fri, 10 Dec 1999 07:21:38 -0800

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
-

---

From: "Darran Potter" <[email-masked]>
Date: Fri, 10 Dec 1999 15:58:20 -0000

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.

Darran
[email-masked]

----- Original Message -----
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

-

---

From: "Dave McNamee" <[email-masked]>
Date: Fri, 10 Dec 1999 08:28:52 -0800

Cisco Access Registrar has just completed development of support for this as
well,
at the request of several SP customers.

Dave

[email-masked]

----- Original Message -----
From: Darran Potter <[email-masked]>
To: Randy Bush <[email-masked]>; Patrice Calhoun <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, December 10, 1999 7:58 AM
Subject: Re: (radius) Re: Comments on Tunnel Draft

-

---

From: Ran Atkinson <[email-masked]>
Date: Fri, 10 Dec 1999 11:38:45 -0500

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.

Ran
[email-masked]

-

---

From: "Darran Potter" <[email-masked]>
Date: Fri, 10 Dec 1999 16:52:31 -0000

Isnt the objection really about the Tunnel-Password in a proxy
environment? ..and even then only when some of the proxies are
not yours?

I think the RFC already has a pretty good paragrah under
security considerations.

For many places doing VPN this attribute is KEY. I cant see how you
can deprecate it... Its like "lets do away with User-Password since
PAP isnt as safe as chap."

darran
[email-masked]

----- Original Message ----- 
From: Ran Atkinson <[email-masked]>
To: Darran Potter <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, December 10, 1999 4:38 PM
Subject: Re: (radius) Re: Comments on Tunnel Draft 

-

---

From: "David Mitton" <[email-masked]>
Date: Fri, 10 Dec 1999 12:06:59 -0500

BayDVS Tunneling and our L2TP support depend on this feature too.

         Dave.

>'unsubscribe ietf-radius' in the body of the message.

---------------------------------------------------------------
David Mitton                                  ESN: 248-4570
Consulting Engineer, Nortel Networks           978-288-4570 Direct
Carrier Packet Solutions, Preside              978-288-3030 FAX
Billerica, MA 01821                     [email-masked]

-

---

From: Ran Atkinson <[email-masked]>
Date: Fri, 10 Dec 1999 12:09:55 -0500

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: Randy Bush <[email-masked]>
Date: Fri, 10 Dec 1999 09:15:26 -0800

> prohibited) from implementing/using it for the reasons stated.

more interestingly, i think you want it to mean "don't make new uses of
this."

randy
-

---

From: "Darran Potter" <[email-masked]>
Date: Fri, 10 Dec 1999 17:20:14 -0000

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? How many
clients currently want it? Thats where Cisco's motivation comes from.

Darran

----- Original Message ----- 
From: Ran Atkinson <[email-masked]>
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 

-

---

From: Barry James <[email-masked]>
Date: Fri, 10 Dec 1999 19:13:50 +0000 (GMT)

Does it make any sense to have a tag that tells the intermediate Proxies
(if there are any) that they are to simply pass the AVP along without
validating the data?  Then only the nearest-LAC-RADIUS would have the
trusted relationship with the end-point RADIUS/LNS/whatever and do the
voodoo there?  I can see issues with this (one being how does a RADIUS
server know it's the nearest-LAC-RADIUS - maybe it can look at the
NAS-Identifier or IP and if the remote server is the same then it can
possibly assume it's the nearest-LAC-RADIUS) but I never fully understood
why any intermediate proxies needed to know anything about LAC->LNS tunnel
passwords.

Barry

Barry L James            | Never doubt that a small group of
IP Systems Engineering   | thoughtful, committed citizens can
Level 3 Communications   | change the world.  Indeed, it's 
http://www.level3.com    | the only thing that ever has.
Member IEEE, AAAI        | #include <std_disclaimer>

-