RE: RADIUS Extension for Management Authorization Draft

["Nelson, David" <dnelson@enterasys.com>]

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.

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

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

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

Thanks for your time to review the draft and for your thoughtful
comments.

Regards,

Dave



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