Re: Thoughts on NetConf Requirements

[Andy Bierman <abierman@cisco.com>]

At 01:04 PM 6/16/2003, Wes Hardaker wrote:
>>>>>> 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"].

This is more than an aside terminology issue.  Filtering implies
almost boundless complexity for all kinds of conditions and
combinations.  For example, filters such as "user joe is
allowed to set parameter X on interface 37 to the value 7 between
the hours of 3 and 5 am on every other friday" would be very
complex to describe and implement in a standard way.  Agreeing
on a useful filter subset and standardizing it is a huge effort
which should not be allowed to slow down the initial netconf work.


>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).

This is debatable. IMO, the WG should only standardize
transport mappings that meet our security requirements.
If an operator wants to do configuration over a non-secure
protocol, then that's their decision.  This is how CLI
configuration is done today.  Both telnet and SSH transports
are provided and the user can choose which one to use.



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

This is a recipe for over-engineering the netconf protocol.
We should engineer for the working protocol scenario, not
how we may hack around unforeseen bugs in auxiliary protocols
later on.


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

This is just more authorization rules.  You set up access rights
based on (user, operation, content). Firewall policies are just
different content from a management POV.



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

Perhaps they are doing out-of-band management to increase
robustness or use non-secure management protocols instead
of upgrading to secure protocols.  In either case, there
are proprietary methods (access lists) to insure only
certain protocols can traverse certain interfaces.
I think a generalized access list standard would be
more appropriate than netconf-specific mechanisms
for this feature, but let's hear what the WG has to
say about it.

Andy


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