RE: Review of Management Authorization -00 document

["David B. Nelson" <dnelson@elbrysnetworks.com>]

> My experience with Service-Type=NAS-Prompt (if memory serves) was
> for administering a NAS over a serial port, with authentication 
> protected by a token system.   As I recall, it was possible to 
> utilize Service-Type=NAS-Prompt alongside token authentication.

That may well be one use case.  There are others.  Password authentication
is commonly used. The NAS-Prompt Service-Type has been used to authorize
local console access to the CLI as well as remote console access to the CLI.
Many implementations distinguish the two cases by the value of
NAS-Port-Type, which may be Async (0) for the physical console or Virtual
(5) for any form of remote console (e.g. telnet, shh, rlogin, et. al.).

> In those scenarios, I would guess that the NAS would send
> Service-Type=NAS-Prompt in the Access-Request, along with no
> Transport-Protocol attribute.  If the user came in via Telnet or
> SSH, the Transport-Protocol would change depending on what
> was used.

The Management-Transport-Protocol attribute could certainly be used in
conjunction with the NAS-Port-Type attribute of Virtual (5), as is the
current practice.

> Is this more or less the usage model that is envisaged, where
> the NAS tells the RADIUS server what type of access is being 
> requested, and the server decides whether to authorize it?

Yes, that's an important element of this proposal.  Just because someone is
authorized to obtain network service from the NAS doesn't mean they are
authorized to manage the NAS.  If a single RADIUS server (or set of
primary/backup servers) is used to handle all authentication requests, it is
important for the server to be able to authorize management access only for
those in the system administration group.

In that sense, the usage of the Management-Transport-Protocol attribute
usage as a hint is as important, or more important, than the provisioning
usage.

Do you think it is important to have an attribute that says "telnet" or
"rlogin" in addition to one that says "over SSH" or "over TLS"?


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