Subject: RADEXT Issue 255 (NAS Management Authorization)

From: "David B. Nelson" <[email-masked]>
Date: Tue, 10 Jun 2008 14:17:00 -0400

> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "Greg Weber" <[email-masked]>
Date: Tue, 10 Jun 2008 14:26:55 -0400

> of the management application-layer protocol.

Slightly less diplomatically, RADEXT is having trouble tying its own
shoestrings.  We don't need to worry about the shoes of others...

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 11 Jun 2008 14:58:21 +0700

> integrated web server, providing management via web pages, also

It's not at all clear to me that "Web services" qualifies as any type of
protocol at all.  W3C defines a "Web service" as ""a software system
designed to support interoperable Machine to Machine interaction over a
network."  Certainly, this definition requires the operation of one or more
network protocols but there is no requirement that HTTP be one of them.  I
think that the Attribute needs to be renamed -- maybe
"Framed-Management-Method"?

...

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 11 Jun 2008 10:07:45 +0200

> "Framed-Management-Method"?

I had the same reaction but then I read the text that is contained in
the ID and found that rather clear. And yes, it helps to avoid the
phrase "web services".

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 11 Jun 2008 07:55:24 -0400

Glen Zorn writes...

> It's not at all clear to me that "Web services" qualifies as any type
> of protocol at all.

I wasn't proposing that we formally characterize embedded web management, as
it's deployed in many NASes today, as "web services".  There is something of
a nomenclature issue here, though, specifically how best to "name" the form
of management that uses an embedded web server to serve up web pages (HTML
content) over the HTTP application-layer protocol to a web browser
application?  The issue is not that HTML/HTTP fails describe the protocol,
but rather that other things besides management can be served in this
fashion. It's my understanding that lots of things are "tunneled" in HTTP
these days, firewall avoidance being but one reason.

What's important, at the end of the day, is that there be an unambiguous
binding between the values of this attribute and the framed (i.e.
non-textual) management mechanisms they represent.

> I think that the Attribute needs to be renamed -- maybe 

I have no objection to that choice of attribute name, but I'm wondering if
it really addresses the underlying issue.  The issue is to pick one
identifying characteristic of framed management to serve as the "name".  The
application layer protocol seemed a logical choice.

Does anyone else have thoughts to share on this, one way or another?