Subject: Re: (radius) tunnel-password language

From: Patrice Calhoun <[email-masked]>
Date: Mon, 13 Dec 1999 16:50:03 -0800

>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?

My understanding, and hopefully I am missing something obvious, is the 
following:

1. user dials into LAC
2. LAC issues a request to home RADIUS server, and a key is returned
3. LAC establishes an L2TP tunnel with LNS, using the above key.

Now, how does the LNS retrieve the key from the RADIUS server? Here are
some options:

1. RADIUS server is stateful, and retains the session key in memory so
that the LNS can issue a request to the RADIUS server to get the key needed
to decypt. I think that this has many problems, especially since one of many
RADIUS servers may issue the key, and there is no way for the LNS to know 
which local server created the key. If the L2TP protocol was able to carry
the KDC identifier, then this problem might go away.

2. Have RADIUS return the key encrypted in two ways, one that the LAC
can understand, and one that the LNS can decrypt. The LAC issues the LNS
encrypted key during tunnel establishment.

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
>
>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.

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

---

From: Ignacio Goyret <[email-masked]>
Date: Mon, 13 Dec 1999 18:24:35 -0800

Pat, Barney,
I think the important part of Pat's problem may be with the use of the
word 'key' in the L2TP context. There is no L2TP key. It is just a password,
and it is no different than a regular user password. If you allow a RADIUS
to server to send a user password to a NAS, there is nothing wrong with
allowing that same RADIUS server to tell the NAS the password it must use
to access a particular L2TP server.

The L2TP control channel has a mechanism to 'hide' AVPs. This mechanism is
not stronger than CHAP. Customers that choose to 'hide' AVPs know (or should
be told) that hiding is not encrypting. Hiding is intended to limit the
amount of stuff that humans can read directly off a network trace, and nothing
more. It is not intended to provide encryption nor full security.

As the L2TP RFC clearly indicates, if you want full security including encryption
(for example, because you don't trust your proxy RADIUS servers), then you better
use IPSEC.

Does this help?
-Ignacio

>3. LAC establishes an L2TP tunnel with LNS, using the above key.

Remember, there is no 'key' in L2TP: there is just a password to access
the L2TP service on the remote's tunnel endpoint. There is no encryption.

-

---

From: Ignacio Goyret <[email-masked]>
Date: Mon, 13 Dec 1999 18:32:28 -0800

>to server to send a user password to a NAS, there is nothing wrong with

Err, I meant to say "...If you allow a NAS to send a user password to a
RADIUS server, ..." :-)

-