Re: Thoughts on NetConf Requirements

[Wes Hardaker <wjhns1@hardakers.net>]

>>>>> On Mon, 16 Jun 2003 14:10:27 -0700, Eliot Lear <lear@cisco.com> said:

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

It must be handled in some sense only to make authorization decisions
based upon it.  Tying it to opaque strings is a good way to go.  The
trick is tying it carefully such that given an opaque string you know
enough about it to make decisions.  EG, I'd use a different naming
construct for users authenticated via Kerberos than those
authenticated via a local password file.  (the easiest being append
@realm.com for the kerberos users).

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

Eliot> Only in the grossest sense.  You don't want to even be
Eliot> listen()ing on a port that is insecure because by its very
Eliot> nature this stuff is sensitive.  OTOH it's a knob to listen()
Eliot> on a particular port/service, whether it's port 22, 23, 80,
Eliot> 443, or whatever.

Certainly no one listens to insecure ports anymore.  Certainly no one
accepts poorly-encrypted (eg, DES) packets anymore.

For scalability reasons, there are times you want to use the more
expensive encryption routines for the most important data and fall
back to the lighter weight algorithms and mechanisms for everything
else.  Ever noticed how sites that support https *don't* use https for
everything?  They only protect the data that requires the heavier
protection.  That way their servers scale a whole lot better.

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

Eliot> I see no evidence that this is an operational requirement.
Eliot> Furthermore, I don't see any evidence that we need to
Eliot> standardize this even if it is. You can do that on your box as
Eliot> part of your config.

One option is to certainly let each vendor do their own thing with
respect to authentication.  It makes it harder to securely distribute
and configure access policies across multi-vendor deployments, of
course.
-- 
"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/>