[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Review of Management Authorization -00 document
That may well be one use case. There are others. Password authentication
is commonly used.
What attributes go along with that? User-Password? CHAP-Password?
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.).
OK. My memory is returning...
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.
OK. It would make sense to say that in the document;. Is there a situation
where NAS-Port-Type = Async (0) would make much sense along with
a Management-Transport-Protocol, attribute?
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.
OK. It might be useful to have an example or two to make this clear.
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"?
The scenario here is to provide more info in the case where
NAS-Port-Type=virtual,
and Server-Type=NAS-Prompt, right? I guess there are scenarios where this
could make a difference to the RADIUS server (e.g. router mistakenly enables
an insecure management protocol and RADIUS server wants to make sure it
that only secure protocols are authorized).
--
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/>