Re: Thoughts on NetConf Requirements

[Wes Hardaker <wjhns1@hardakers.net>]

>>>>> On Wed, 04 Jun 2003 14:33:48 -0700, Andy Bierman <abierman@cisco.com> said:

Andy> So what's so complex about reads? The authorization model?
Andy> IMO, the authorization model amounts to a set of tuples:
Andy> { user, operations-allowed, element-subtree }.
Andy> Read operations amount to 1 more bit in the operations-allowed field.

[aside: I agree with Juergen that "filter" would be a better word than
"element-subtree"].

Authorization should probably be able to select stuff on more
information than that.  Specifically, you're designing a protocol that
is expected to run over multiple transports each with their own notion
of how security is performed.  Additionally, you're expecting the
authentication to be done with possibly multiple forms of
authentication databases.  Thus, you'll need to have the authorization
model check to see if the incoming request matched a required
transport and was authenticated using a given authentication
mechanism.  You could, in your model above, role the authentication
model into the "user" element in your tuple above but the "transport"
should probably be a separate list item I'd think.

Why is this important?

1) you probably want to build operational policy based on how the data
   is being transferred.  It's likely that you'll want to change what
   your policy allows based on how the requests are arriving.
   Specifically, if I'm using xmlconf over raw telnet, I certainly
   wouldn't want to allow write operations to my data set.  I'd also
   want to reduce the view of the data that could be seen (IE, keys,
   etc, would never be transmitted within get-config results over an
   insecure link).

2) If a security flaw is found in one of the transports or
   authentication mechanism, you'd want to
   limit what could be sent over that transport in the future.  If you
   have a box that supports, say, BEEP/xmlconf and TLS/xmlconf and
   manager M1 can speak BEEP and M2 can speak TLS and, say, BEEP is
   found in the future to contain security flaws then you would
   probably want to limit M1's ability to do things on the network.
   You may not be able to eliminate it entirely, as it may provide a
   fundamental service that you'll let continue (monitoring
   non-critical data) till you can figure out what product to buy that
   can speak TLS instead.

3) Similar arguments as 1 and 2 can be made for authentication (IE,
   don't let RADIUS authenticated sessions do more than a limited set
   of operations on a limited set of data).

Andy> The only other issue related mostly to reads is the volume of
Andy> returned data.  IMO, the application streams data and the transport
Andy> handles fragmentation, so this is a non-issue.

The data itself can be critical.  Policy and security data, for
example, may dictate the firewall policies within my network or
critical security information (keys, etc).  I certainly want to
restrict who can view that data and over what transport its acceptable
to view it.

Today, operators build separate management networks that do not
overlay the real networks to ensure that the management traffic is
going over a private (physically different) link.  What's missing in
many components in the ability to force the device in question to
*only* accept management traffic over that link.

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>