[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Thoughts on NetConf Requirements

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

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

The protocols are going to serve as substrates. The semantics will remain within XMLCONF. To do otherwise means you have multiple protocols that will all prove equally difficult to mediate to and from a native operating environment.

Authorization should be tied to opaque strings such as users or distinguished names, if it is to be handled at all (and I believe it is a big if) prior to any agreement on a meta-data model (which may take quite some time to get).

I also do not agree with the following:
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).
Only in the grossest sense. You don't want to even be listen()ing on a port that is insecure because by its very nature this stuff is sensitive. OTOH it's a knob to listen() on a particular port/service, whether it's port 22, 23, 80, 443, or whatever.

And...

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).
I see no evidence that this is an operational requirement. Furthermore, I don't see any evidence that we need to standardize this even if it is. You can do that on your box as part of your config.

Eliot




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