RADEXT Issue 255 (NAS Management Authorization)

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

> 8.1 (and elsewhere)
> Shouldn't Framed-Management-Protocol "Web-based" (2) be HTTP or
> HTML/HTTP?

The attribute in question, Framed-Management-Protocol, is used to describe a
management *application-layer* protocol.  SNMP clearly qualifies.  An
integrated web server, providing management via web pages, also qualifies,
although a web server is by no means limited to management applications --
all sorts of applications can be implemented using a web services model.
When we get to options such as FTP, which means to describe provisioning of
management information by "file copy", the distinction is even less clear.
File copy operations are used for all sorts of things besides network device
management.

This attribute is not attempting to describe a transport protocol.  We had
one of those in a prior version and it was eliminated based on comments
received.  Attempting to provision the transport protocol was causing
confusion without adding any offsetting value.

The value (2) of the Framed-Management-Protocol means a web-services based
management interface.  Yes, it uses HTTP, but the meaning that is intended
here is restricted to a web server application for the purpose of device
management.

> Should we develop acronyms NETCONFS and SNMPS and CLIS so we can just
> lump the non-secure and secure versions into Configuration-based, and
> Polling-based names and so on?

I don't think that this document is the right vehicle to define new
nomenclature for existing management services and protocols.

I'm open to devising some clarifying text here, but I think we need to keep
the scope of semantics for this attribute narrow, i.e. limited to indication
of the management application-layer protocol.

> section 8.2
> "The same "No Protection" semantics are conveyed by omitting this 
> attribute from an Access-Accept packet."
> Why is this the default behavior? Wouldn't it be better to default 
> to full security if the attribute is not present?

I believe that would violate the RADEXT Charter restriction on maintaining
backwards compatibility / interoperability with existing RADIUS standards
and fielded implementations.  I propose to reject this comment.

> Section 8.3
> Paragraph 3 says what to do if one is received; and paragraph talks
> about receiving more than one. What if zero are received?

RADIUS clients and servers must always be prepared to *not* receive any
optional attribute in any message.  There can be no implicit semantics of a
"missing" attribute other than to "do nothing" as regards the semantics of
that particular attribute.  In the case of Management-Policy-Id, the absence
of an attribute means that the NAS applies no management access
control/filtering policy.  This basic to the operation of the RADIUS
protocol, and it is assumed that readers are familiar with that behavior.
Do you think it needs to be reiterated here?

Paragraph 3 says what to do if one is received; and paragraph talks
about receiving more than one. What if zero are received?

> Paragraph 3 says if "the policy rules are incorrectly
> formatted, the NAS MUST treat the packet as if it had been an
> Access-Reject."
>
> Doesn't this potentially override what the management protocol says
> should be done if the rules are incorrectly formatted?

If the underlying management protocol has default rules, in the absence of
any additional provisioning by RADIUS, then these would still apply.

> If the mgmt protocol defines an error condition for incorrectly 
> formatted rules, that error won't be sent because the session is 
> rejected, right?

Yes.  However, I don't think we ought to go down the path of inserting
RADIUS in the middle of a client-server (or peer-peer) applications layer
protocols, management or otherwise.  The standard RAIUS behavior (it has
always been so) is that if the client receives an attribute that it can
interpret, i.e. that it supports, and it cannot decipher or correctly act
upon the value of the attribute, it must "punt" the session, rather than
risk misunderstanding the intent of the system administrator and allowing
more service access than was originally desired.

This is almost always a case of misconfiguration, and it is assumed that
human intervention by the system administrator will be required to resolve
it.

> What happens if it is considered incorrect formatting to have an empty
> table of rules, but the operator is trying to gain mgmt access to set
> the policy rules into the table?  Would RADIUS even know whether the
> rules were incorrectly formatted?

The RADIUS client itself would likely not know, but another portion of the
NAS software that is responsible for making the rules take effect would very
likely know, and would be able to return an error code to the RADIUS client.
This is simply a case of making sure that the security configuration is
valid before you enable security checking.  One more case of "locking the
keys in the car" if you are not careful.  Make sure you have the key before
you push down the lock button.  :-)

I think we could add some sort if "Implementation Note" warning users of the
potential issue. I don't think we want to dilute the security by requiring
that the RADIUS client attempt to "second guess" configuration errors in
favor of granting [greater] access.

> section 8.4
> I don't understand why we need a special Management-Privilege-Level
> attribute. This should be able to specified as a named policy in the
> Management-Policy-ID, such as "Level 1" and "Level 2", or even "1" and
> "2" and "3". Implementations simply need to map between the policy
> name and their privilege-level policy implementation.

This attribute was added to support legacy access level mechanisms that are
integer-value based, without conflating them with the newer
text-string-valued, policy-named based mechanism.  In the "green fields"
case, i.e. in the absence of a fairly wide deployment of the legacy
mechanism, I would fully agree with you.  What you suggest *could* be made
to work.  I think it has greater risk because of its interaction with legacy
mechanisms.  I would propose to retain the separate attributes, unless there
is WG consensus to combine them.

> section 9:
> I have a concern about protocol versions. What if I want SSHv2
> because I don't think SSHv1 is adequate? Should I be able to make the
> distinction? or is that simply an operator-provisioning task to
> disallow SSHv1 to the device?

I would argue it ought to be the latter.  It is not always clear where to
draw the line as to how granular AAA-based provisioning ought to be.
AAA-based provisioning is not intended to supplant all operator provisioning
requirements.  I've been attempting to apply the "less is more" philosophy
in the absence of a clear use-case that dictates "more is more".  :-)

> Section 9:
> Example #5 mentions SNMPv3, but the attribute says only SNMP.

Ooops.  Editorial cruft.  Will fix in -03.

> Section 9:
> I would change the paragraph in example #5:
> OLD: Note that there is currently no standardized way of
> implementing this management policy mapping within SNMPv3. Such 
> mechanisms are implementation specific.
> NEW: "A standardized way of mapping from Management-Policy-ID to a
> particular access control policy in SNMP is under research."

OK.  Will fix in -03.

> Section 9:
> Example #6 talks about using the Secure Shell Transport Model,
> but most existing SNMP implementations do not support this yet. 
>The "transport model" approach supports a binding between the SSH
> authenticated identity and the SNMP database access controls. Some
> SNMP implementations support running SNMP (any version) over an
> SSH tunnel, but they provide no such binding. I think it is an 
> SNMP internal matter for SNMP access controls to say "they must 
> use transport model to get database access". So I would remove 
> the mention of the Secure Shell Transport Model from the example:
> OLD: 6. SNMP secure Transport Model access, using the Secure Shell
> Transport Model:
> NEW: 6. SNMP access, via a fully-protected secure tunnel of SSH,
> to an undefined management access level:

OK.  Will fix in -03.

> Section 9:
> Example#8 doesn't mention which transport protocol should be 
> used to provide security services. Should it, or is it intentional
> to allow any transport protocol be used that can provide
> Confidentiality-Protection?

We've previously decided to not provision the specific transport protocol,
but rather to only provision the security properties of the protocol.  This
is another of those "less is more" arguments.



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