Re: Thoughts on NetConf Requirements

[Wes Hardaker <wjhns1@hardakers.net>]

>>>>> On Tue, 17 Jun 2003 09:56:38 -0700, Eliot Lear <lear@cisco.com> said:

Eliot> For instance, some OSS networks don't *want* encryption.

I never meant to imply mandating it.  All I've been trying to say is
that the appropriate options must be present for administrators to
make smart (or dumb) choices with.  You shouldn't put a MUST in front
of encryption.

Eliot> All of this having been said, if you would like I don't see any
Eliot> reason why we couldn't standardize an error message indicating
Eliot> that stronger encryption is required.

What Andy has been trying to advocate is that the authorization checks
won't know if encryption was turned on or not (you only know about the
user name, the operation and the "filter").  Therefore it would be
impossible to generate the above error message (from the xmlconf side,
of course...  you could do it via TLS (or whatever) configuration)

Eliot> What has to pass muster is what will be implemented and used.  If the
Eliot> IESG mandates functionality that is not used, they will damage the
Eliot> industry by raising the cost of goods and services.  However...

What I was trying to make clear is not that the IESG should mandate
something (they shouldn't) but they should mandate that appropriate
security policies can be configured.  They *are* mandating today that
security must be implemented in new versions of specs (or at least the
lack of security to be documented in the security considerations section).

Eliot> All of this argues for ONE transport and that we get the ONE
Eliot> transport right, and that we do away with transport mappings.
Eliot> That way we reduce the number of combinations of potentially
Eliot> insecure configurations of the transport.

I'd certainly be in support of that.  I think doing multiple
transports is probably a mistake from both a inter-operable point of
view and a security point of view.  That doesn't mean that I think
things should be tied together such that replacing the transport can't
be possible, however.  It means I think that a second probably
shouldn't be standardized until the first is proven to be problematic
in some fashion.

>> Different content that requires a greater level of protection than
>> interface information, for example.  It's impossible, in your model,
>> to disallow "user" from sending the firewall rules over an insecure
>> transport.  IE, there is nothing to prevent a user from requesting the
>> keys to the kingdom across an insecure transport.

Eliot> How about a simple "permission denied"?  You can do this in your
Eliot> implementation without any extension to the protocol.

We weren't talking about the protocol.  We were discussion the data
model requirements for the authorization module.  Under Andy's
suggested set of data that the authorization module must deal with,
you can't return a "permission denied" error based on the fact that
the connection is insecure or not secure enough; because you don't
know anything about it.

For those more familiar with the SNMPv3 world, it would be like
removing the vacmAccessSecurityLevel and vacmAccessSecurityModel
objects from the vacmAccessTable table.

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