Subject: (radius) Radius for service authentication?

From: Bernd Viefhues <[email-masked]>
Date: Tue, 04 Apr 2000 16:41:53 +0200

Hi,

as far as I understand the RFCs, the Radius protocol is designed to provide
network access authentication. I wonder if it is also possible to use the Radius
protocol also for application/service access authorization.

The scenario I am currently dealing with, consists of some access server, a
Radius server and some application servers. All machines are sitting on the same
network. I am looking for a method to authenticate users not only to the network
(that works already using the Radius server) but also to the applications
running on the application servers. 

What the applications basically should do when some user tries to connect to
them is to verify that this user (identified by a DHCP IP address) is allowed to
use the application. Is it feasible to use the existing Radius server to do
this? How would this usage scenario fit into the Radius protocol? I would like
to stick to some standard instead of inventing something own...

Best regards,
Bernd

-- 
Bernd Viefhues                      Phone: +49 2407 575 925
Ericsson Eurolab Deutschland GmbH   Fax:   +49 2407 575-7893
52134 Herzogenrath, Germany         [email-masked]
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Paul Krumviede <[email-masked]>
Date: Wed, 05 Apr 2000 20:59:24 +1200

--On Tuesday, 04 April, 2000 16:41 +0200 Bernd Viefhues 
<[email-masked]> wrote:

> Hi,
>
> as far as I understand the RFCs, the Radius protocol is designed to
> provide network access authentication. I wonder if it is also possible
> to use the Radius protocol also for application/service access
> authorization.

Sure. There may be some issues with the kinds of information you can
stick in a response if you want more than a yes/no answer, and there
may be limits to the authentication mechanisms that you can use.

Depending on the actual setup, there could also be interesting questions
as whether a server wants to see accounting messages, but that isn't
really a protocol issue.

-paul

-

---

From: Bernd Viefhues <[email-masked]>
Date: Thu, 06 Apr 2000 12:24:50 +0200

Hi, again,

Maybe I did not come to the point in my first posting, so I'll try to explain my
problem a bit more detailed. 

After a user is authenticated by the Radius server, the network "knows" him. So
there should be no need to login again to specific services/applications.
Instead, an application should query the Radius server for access
authentication. To do that, the Radius server must keep a user privilege
database.

If the user does not have to identify himself explicitly to the applications,
the only information applications have about users are their IP addresses
(that's the current status in the environment I work in).

And that's where I have a problem: How to use the Radius protocol in this case?
RFC 2138 says that I must send a User-Name attribute in an Access-Request
packet. Since I don't have a user name, I can't really do what the RFC
describes.

So, I have some (probably bad) ideas to deal with this:
1) Send the IP address as user name and implement the Radius server in a way
that it
   can handle this. That's not exactly what the RFC says...
2) Use another "standard" solution which is already used by others. That's why
I'm 
   asking here :-)
3) Somehow (mis)use Radius Accounting for this task. Not nice.
4) Define some own packet type and possibly additional attributes. That's what I
want 
   to avoid.

What would you do here? Do I miss something important? Are there other
solutions?

Best regards and thanks for your help,
Bernd

---

From: "David Mitton" <[email-masked]>
Date: Thu, 06 Apr 2000 11:57:58 -0400

>there should be no need to login again to specific services/applications.

This assumption is not valid.  Authorization to access the network is 
different than authorization for a given application.  Furthermore, the 
design of RADIUS, for better or worse, does not presume to keep "state", if 
you will, in the server about the current status of the user in the 
network.  Stateful servers have been built, but that is outside the 
intended design of the RFCs.

>authentication. To do that, the Radius server must keep a user privilege

Most servers do not support this concept.

>packet. Since I don't have a user name, I can't really do what the RFC

I guess this is a problem with your application.
Other IETF applications, like Telnet and FTP do require user identification 
and passwords.  These can easily mapped into a RADIUS solution if needed.

>    can handle this. That's not exactly what the RFC says...

If all you have is an IP address which is sufficient along with server 
state, then you could create a new service-type value and handle this 
message in your custom server.  You are already outside the RFC.

>What would you do here? Do I miss something important? Are there other

I'm not aware of other people doing stuff like this.  But doesn't mean it 
isn't being done quietly somewhere.

         Dave.

>Best regards and thanks for your help,

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

-

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 7 Apr 2000 02:56:08 -0700

>Authorization to access the network is 
>different than authorization for a given application.  

Indeed. Among other things, network access authorization is something
you only need once in a session which can be long-lived. Application
authorization is something that can be needed many times in a session.
This is why application authorization solutions (like Kerberos) support
ticket re-use, so that the app server does not have to go
back to the KDC to validate a ticket. This not only takes load off
the KDC, but it also provides convenience for the user, who doesn't
have to re-enter their password everytime they run an application. 
The concept of re-use is absent in RADIUS and as a result, RADIUS is 
not a scalable or appropriate solution for application authorization. 

>What would you do here? Do I miss something important? Are there other

Why not just existing solutions such as Kerberos, SSL or SSH that were
designed for this purpose?

-