Re: RADIUS Extension for Management Authorization Draft

[Barney Wolff <barney@databus.com>]

On Thu, Jul 15, 2004 at 09:37:09AM -0400, Nelson, David wrote:
> Barney Wolff writes...
> 
> > It seems to in effect provide single-sign-on for NAS administration.
> 
> I had not thought of this proposal in terms of single-sign-on, as it
> does not include additional authentication elements, but rather
> additional authorization elements, but, that may indeed be a valid way
> to think about the issue.
> 
> > I infer
> > this, because if there were further authentication steps intended
> after
> > the user was communicating with the NAS, that could be accomplished
> > simply with an appropriate Filter-Id which allowed the necessary
> packets
> > to pass - on the assumption, which I consider the only sane one, that
> > ordinary users are prevented from sending any packets whatsoever to
> > the NAS itself.
> 
> One *could* implement such functionality (at least in part) using the
> Filter-ID attribute.  IMHO, this would be over-loading the Filter-ID
> semantics with additional functionality.  My interpretation is that the
> Filter-ID attribute provisions the packet forwarding service of the NAS.
> One *could* decide that the local management interfaces (e.g. the local
> IP stack) exist behind the filter, from any port on the NAS (Console,
> WAN, LAN, WLAN, etc).  I think it would be better to introduce explicit
> attributes to authorize various forms and levels of management access,
> rather than over-loading the definition of Filter-ID.

I'm not proposing overloading the definition of Filter-ID, simply that
filters can exist that allow access to nas-ip/udp/161, nas-ip/tcp/443,
etc.  That is a simple and straightforward use of Filter-Id without
changing its meaning.

> > But SSO for NAS administration strikes me as a bad idea.  The NAS
> already
> > has authentication and authorization procedures in place to enable and
> > control administration from within the network.
> 
> Yes, but at the level of granularity I'm proposing those control and
> authorization functions are entirely local to the NAS.  The intent of
> this proposal is to allow those local functions to be performed by
> RADIUS remote AAA.  The same reasons we found RADIUS was useful in the
> initial instance, e.g. network scalability and centralized control of
> access, motivate this proposal. 
> 
> > Why should these be
> > bypassed simply because the user has "dialed" in?
> 
> I'm confused about two points in this question.  First, the access
> control is being "bypassed" solely to the extent that RADIUS, as
> currently defined, "bypasses" local password authentication and moves it
> to a server-based system.  I think there is agreement that that is a
> Good Thing (tm).   Second, none of the elements of the proposal are tied
> in any way, that I can see, to "dial-in".  Could you please elaborate?

Ok, what I missed in reading the draft was that the NAS can send stuff
in the Access-Request to indicate what service is being requested.  That
covers the scenario where the user is inside, accesses the NAS via
telnet/ssh/http/ssl/snmpv{1,3} and the NAS uses RADIUS rather than eg
TACACS to authenticate+authorize the user.  I agree that extending the
service types to indicate how the user got to the NAS is helpful.  My
concern is really in the access from outside scenario.  I have a
superstitious fear of SSO.

> > Do we really trust
> > RADIUS authentication as much as the NAS's native procedures?
> 
> I would *hope* so.  Isn't that level of trust fundamental to the RADIUS
> model?
> 
> > Suppose
> > we're in a proxy situation and the user's home RADIUS server decides
> to
> > grant administrative access to a provider's NAS?
> 
> There may be additional text required in the Proxy Considerations
> portion of the draft. However, today we have the Admin Service-Type that
> grants "super-user" or privileged access to the management CLI of the
> NAS.  How would the issues you raise be different for that attribute?

The issues would be identical.  As I recall, the Admin service types go
back to a time before people had thought seriously about proxies.  I
wonder how many existing proxies check for servers authorizing more
than the access network owner would like.

> > Is dialup administration so common that it's important to allow SSO?
> 
> I did not have "dial-up" access in mind.  In fact, the primary driver is
> LAN access via Telnet, SSH, SNMPv3, etc.  Although the draft would apply
> to local console access and dial-up access, that isn't the design
> center.

Inside access seems fine, and reflects the reality that lots of people
have written RADIUS clients to do such things as Unix login validation.

Regards,
Barney

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>