Subject: RE: [Isms] FW: RADIUS integration

From: "Blumenthal, Uri" <[email-masked]>
Date: Tue, 27 Jun 2006 13:26:18 -0400

Jeffrey,

Of course you are correct - but since RADIUS is an old protocol, and its
implementations are equally old and very much entrenched - I do not know
how practical would it be to attempt to enforce a cleaner model over it.
After all, there is DIAMETER that was supposed to address shortcomings
of RADIUS - and where is it?

It may be that you'd have to authenticate twice - to the peer entity and
then to RADIUS to receive authorization information. And yes it is ugly.

-----Original Message-----
From: Jeffrey Hutzelman [mailto:[email-masked]] 
Sent: Monday, June 26, 2006 2:08 PM
To: Nelson, David; [email-masked]
Cc: Jeffrey Hutzelman
Subject: RE: [Isms] FW: RADIUS integration

On Friday, June 23, 2006 06:20:40 PM -0400 "Nelson, David" 
<[email-masked]> wrote:

> That was the expressed preference.  It has not been determined that
> RADIUS can (should) be used in that fashion. That is the subject of
> ongoing study.  Today, RADIUS is defined to provide separate
> authorization services only when the original authentication was via
> RADIUS and the RADIUS client and server share a state cookie.

And that model is no longer sufficient.  Authentication and
authorization 
_are_ separate concepts, and people are beginning to recognize that and 
treat them separately.  Authentication is no longer always about
usernames 
and passwords, and some authentication methods do not lend themselves to

authenticating to some entity other than the one you want to talk to. 
Whether it's SSHSM, an SSH login session, 802.1x, or PPP dialup, 
authentication may take place via a mechanism that is outside the RADIUS

server's control.  Once that happens, the application needs to make a 
decision as to whether to provide access and at what level, and RADIUS
is 
an appropriate tool for that, even though it did not handle
authentication. 
But it can only be used that way if a RADIUS client can say "this is the

user's identity; tell me what I need to know to make an access
decision".

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 27 Jun 2006 13:48:18 -0400

> of RADIUS - and where is it?

DIAMETER was an attempt to replace RADIUS from scratch.  Last time I went 
to an AAA working group meeting was in 2000.  I was there because I was 
trying to help the author of a document on Kerberos authentication for 
DIAMETER to get it right.  The working group seemed to be interested in 
spending its time designing a transport protocol.  Maybe they still are.

I'm not trying to "enforce a cleaner model".  What RADIUS provides is an 
authentication backend and authorization and provisioning service for 
devices providing network access (or whatever).  The model is already 
reasonably clean; IMHO its only major architectural wart is the insistence 
on conflating authentication with authorization.  The RADUIS server doesn't 
provide any services to the end user; therefore, it doesn't need to 
authenticate the end user's identity except to be able to assert that 
identity to its client.

I'm proposing a model in which the RADIUS client asserts the end user's 
identity to the server, instead of the other way around.  This is a fairly 
straightforward extension.

> then to RADIUS to receive authorization information. And yes it is ugly.

RADIUS is supposed to be invisible to the end user.  How do I get a 
Kerberos ticket for a service that I don't even know exists?  Or are you 
suggesting that after I authenticate to the SSH server using GSS-krb5, 
which allowed me to avoid giving it my password, I then have to give it my 
password anyway to satisfy the RADIUS server?

Worse, broken as that approach is, SSH can handle it, because the protocol 
is designed such that servers can require multiple authentications using 
different methods before a user is granted access.  Most network access 
protocols don't work that way, so this doesn't help me with my PPP dialups 
or my wireless or my VPN.

I suspect we're reaching the point where we should take this discussion out 
of ISMS and over to RADEXT instead.

-- Jeff

---

From: "David Harrington" <[email-masked]>
Date: Tue, 27 Jun 2006 13:54:16 -0400

Hi,

The ISMS WG is supposed to prepare a request for RADEXT, explaining
the requirements we would like to see addressesd, so this discussion
may be in the right place. We just need to make sure we actually
generate a request from ISMS to RADEXT, or the discussion is wasted.

dbh

> Sent: Tuesday, June 27, 2006 1:48 PM
> To: Blumenthal, Uri; Nelson, David; [email-masked]
> Cc: Jeffrey Hutzelman