Subject: Re: (radius) tunnel-password language

From: Barney Wolff <[email-masked]>
Date: Mon, 13 Dec 1999 19:37 EST

Pat, there is nothing in either RADIUS or L2TP that forbids or makes
harder than necessary using ephemeral keys.  Sure, there is nothing
explcit that governs communication between the RADIUS server and the
tunnel destination - just as there is nothing explicit that governs
communication between the RADIUS server and some external DBMS that
holds the user data.  What do you see that forbids it?

Barney

> Date: Mon, 13 Dec 1999 12:52:49 -0800 (PST)
> From: "[email-masked]" <[email-masked]>
> > 
> > Tunnel-Password is exposed to the NAS and any RADIUS proxies between
> > the server and the NAS.  Therefore it SHOULD be ephemeral or unique
> > to the pair of tunnel endpoints, unless the server has great trust
> > in the NAS and every proxy.
> > 
> But the orotocol doesn't allow that. You cannot support ephemeral keys using
> RADIUS and L2TP.
> 
> PatC
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Barney Wolff <[email-masked]>
Date: Mon, 13 Dec 1999 20:08 EST

The way I am doing it is:

1.  NAS makes RADIUS request, which gets to the server.
2.  Server asks LNS for an ephemeral secret for the NAS-IP.
3.  Server returns secret to NAS as Tunnel-Password.
4.  NAS/LAC establishes tunnel with LNS using the secret that the LNS
    is expecting.

As I've tried to point out, this is no different in principle from
a RADIUS server than needs to query an external database to validate
the user, and neither RADIUS nor L2TP has anything to say against it.

Barney

> From: Patrice Calhoun <[email-masked]>
> Date: Mon, 13 Dec 1999 16:50:03 -0800
> 
> So my understanding is that unless one of the two above were done (and I am
> sure that there are other, possible more elegant ways), there is no way for
> ephemeral keys to be supported.
> 
> Please let me know if I did miss something,
> 
> PatC
-

---

From: Patrice Calhoun <[email-masked]>
Date: Mon, 13 Dec 1999 17:25:09 -0800

..and fwiw, customers cannot expect interoperability in this case, which
MAY be more important then a server's database interface. If a customer
uses the same vendor's RADIUS server and LNS, then he/she is ok. Otherwise,
ephemeral keys are not supported.

Whereas, a customer buys the RADIUS server and gets the backend database 
he/she gets with the server.

Right?

PatC

-

---

From: Barney Wolff <[email-masked]>
Date: Mon, 13 Dec 1999 21:49 EST

Pat, you're hard to put down, but I've got you now!
I configure my network so the LNS is the RADIUS proxy.  The LNS
gets the Access-Request, sends it on to the server with the user
database.  When the LNS gets the Access-Accept, it adds the
ephemeral secret and sends the Access-Accept back to the NAS.
My LNS can work with any RADIUS server and any NAS.  Now can we
put some language in the draft and move on?
Regards,
Barney

> From: Patrice Calhoun <[email-masked]>
> Date: Mon, 13 Dec 1999 17:25:09 -0800
> 
-

---

From: Barney Wolff <[email-masked]>
Date: Tue, 14 Dec 1999 11:55 EST

To paraphrase a famous adage of computer science, there's nothing in
RADIUS that can't be solved by introducing another level of proxy. :)
Peace,
Barney

> Date: Tue, 14 Dec 1999 07:14:10 -0800
> 
> Of course, that means that all of the RADIUS servers outside of your
> domain share a security association with all of your LNSes in your
> network, which sounds unmanageable, and unscalable (sp?).
-

---

From: Barney Wolff <[email-masked]>
Date: Tue, 14 Dec 1999 12:42 EST

Ok, I'm going to stop now (I'm sure others wish I had stopped long ago).
If I interpret your message correctly, someone is going to generate
an ID proposing a new encryption algorithm for RADIUS without saying
what's wrong with the existing one, and the WG will adopt it with
alacrity and gratitude.  Then when everybody's updated, people beyond
some inner circle will be told what the problem was.
Yours in expectation,
Barney

> Date: Tue, 14 Dec 1999 12:24:51 -0500
> From: Ran Atkinson <[email-masked]>
> 
> 	Details of the attack ought NOT be noted here in public until things
> get fixed in the spec and in implementations (thus giving operators
> a fighting chance of closing the hole before a truck gets driven
> through their RADIUS-based systems).
> 
> 	The current (pseudo-)cryptographic part of RADIUS needs to be
> replaced.  Dropping in a real encryption algorithm into RADIUS, along with
> a shared key between endpoints would resolve/mitigate the non-proxy aspects
> of RADIUS confidentiality somewhat, for example.  This is feasible
> without changing the protocol radically.  It would involve changing
> running code in lots of implementations.
-