Subject: AW: L2TP Tunnel Authentication with RADIUS

From: Klausberger Walter <[email-masked]>
Date: Fri, 1 Sep 2000 14:06:52 +0200

Well, we will do so. I think it depends on which side of the tunnel you
are...

In LAC case you can use the tunnel password to setup an appropriate tunnel
to an LNS. During user authentication (with PPP PAP, CHAP,...) you do an
Access-Request and you get the tunnel password in return. That's ok, so
far...

I think your problem is really on the LNS side. A tunnel comes in and there
may be a tunnel password stored on the RADIUS for the incomming session tied
to the username. You are correct. This will not work.

1.) The user may come at different times from different LACs. So there is no
use to bind the password to the username.

2.) As you stated before, it is too late when you get the username.

A solution would be:
You get a LAC host name together with the incomming tunnel. You can use an
Access-Request with this hostname to get a tunnel password from the RADIUS.
So you can answer the challenge and issue your own challenge at the same
time. Nobody said that RADIUS can only be used together with PPP. We even
use a DNIS String as username to get centrally stored information and
configuration.

with best regards
Walter Klausberger
Siemens AG Austria

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]]
Gesendet am: Dienstag, 22. August 2000 13:51
An: [email-masked]
Betreff: L2TP Tunnel Authentication with RADIUS

Are there any L2TP implementations that use RADIUS for L2TP tunnel
authentication ?

Looking through the various RADIUS RFCs it looks like RADIUS can be used
for PPP authentication after the tunnel and call are established but I
can't see a way to get a RADIUS Server to send back a MD5 Hash value or a
password to use for a Challenge-Response for tunnel authentication. There
is a Tunnel-Password attribute but it is only sent back in an Access-Accept
packet. From an LNS standpoint it looks to me that I would need a tunnel
password stored locally in order to generate a Challenge-Response which
would defeat the purpose of using RADIUS to consolidate authentication
administration to a single system.

Am I missing something ?

Thanks,

Kurt Streifert
IBM AS/400 Endicott Programming Lab

---

From: Motonori Shindo <[email-masked]>
Date: Mon, 04 Sep 2000 10:13:15 +0900 (JST)

All,

I do agree with Walter's comment. 

Tunnel authentication and user authentication (associated with an
incoming call) are totally two different things, and more importantly,
the establishment of a tunnel does not necessarily happen at the same
time as the session (ie. PPP) establishment.

From this point of view, a straight-forward LAC implementation should
work in the following way:

 1) LAC gets to know the user name (via PAP/CHAP or whatever) and
    queries to RADIUS to authenticate this user and obtain information
    associated with it. If this user is an L2TP user, then the
    RADIUS entry for this user would contain a Tunnel-Server-Endpoint
    attribute associated with this user.

 2) If a tunnel for the LNS specified by Tunnel-Sever-Endpoint hasn't 
    already existed and if the LAC is configured to do tunnel
    authentication, then a LAC queries to RADIUS again to obtain a tunnel
    passowrd. In this case, the RADIUS entry has a LNS name (identified
    by a Tunnel-Server-Endpoint in the previous query) as a user
    name, and should include a Tuennel-Password attribute in its reply
    item.

Please note that this sequence involves two RADIUS queries, one for
user authentication and another for tunnel authentication. To make it
work in more efficent way, an optimization is possible by piggybacking
a Tunnel-Password attribute on the first RADIUS query for the user
authentication. Since there's a one-to-one relationship between
Tunnel-Server-Endpoint and Tunnel-Password, this optimization works
without any problem.

Howerver, on the LNS side, as Walter pointed out, this optimization
can not be applied and two RADIUS queries are required. That is, when
the LNS receives an SCCRQ from the LAC (along with an L2TP's CHALLENGE
attribute), the LNS first queries to RADIUS about the tunnel password
associated with a name specified in the L2TP's HOSTNAME attribute (the
use of HOSTNAME attribute for this purpose is not explicitly defined
in the RFC but it is a good choice, I believe). After the tunnel
authentication is finished and the tunnel is successfully established,
the ICRQ follws and then user authentication happens through, again,
RADIUS.

Regards,

From: Klausberger Walter <[email-masked]>
Subject: AW: L2TP Tunnel Authentication with RADIUS
Date: Fri, 1 Sep 2000 14:06:52 +0200 

> IBM AS/400 Endicott Programming Lab

=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=
 +----+----+     
 |.. .|    |     Motonori Shindo
 |_~__|    |     
 | .. |~~_~|     Sr. Systems Engineer
 | .  |    |     CoSine Communications Inc.
 +----+----+     
 C o S i n e     e-mail:  [email-masked] 
Communications
=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=

---

From: Sridhar Malarothu <[email-masked]>
Date: Wed, 27 Sep 2000 13:42:00 +0530

Hi All,

   Since the same secret which is used for Tunnel Authentication is also
used in hiding the AVP's, I think its not simple for LNS to get the Tunnel
password(secret) from RADIUS(based on peer's host name in the SCCRQ msg),
if both the tunnel authentication and AVP's hiding are used at the same time.
   Even though the Hostname AVP in the SCCRQ msg is not hidden, the other
AVP's like Assigned Tunnel ID etc, can be hidden. 
   Since Hostname is required to get the Tunnel Password from Radius, we
may just extract the Hostname AVP from SCCRQ and differ the decoding of rest
of the message till the RADIUS response is received. But we cannot ZLB ack the
SCCRQ message, since the Assigned Tunnel ID in SCCRQ may be hidden.

Best Regards
Sridhar

---

From: Motonori Shindo <[email-masked]>
Date: Fri, 29 Sep 2000 06:28:23 +0900 (JST)

Sridhar,

Good point. When attribute hiding is used along with a tunnel
authentication, it introduces a little bit of complication
(i.e. necessity of deferring the decoding of hidden attributes until
the tunnel password is retrieved from RADIUS). Yet, tunnel auth at LNS
via RADIUS is doable and almost mandatory from the operational point
of view. Tunnel auth at LNS without RADIUS support is a nightmare! 
Everytime LAC is added to the network, all LNSes have to be
reconfigured to reflect a new tunnel password for the LAC.

Regards,

From: Sridhar Malarothu <[email-masked]>
Subject: Re: AW: L2TP Tunnel Authentication with RADIUS
Date: Wed, 27 Sep 2000 13:42:00 +0530