[Isms] What granularity of attributes do we need for the secure transport?

["David B. Nelson" <dnelson at elbrysnetworks.com>]

David Harrington writes...

> I am concerned that dropping the choice of transport protocol really
> limits how we can communicate with the lower layer to get information
> we need to determine what level of access control should be applied.
> "any protocol that provides transport layer encryption" may not be
> good enough for operators.

We need to have a further discussion of this issue on the list, and I have
the action item start a thread to discuss it.

Let's start that discussion now.

I have a couple of thoughts to start off:

-- If it turns out that we need something more granular than
Management-Transport-Protection = {No-Protection | Integrity-Protection |
Integrity-Confidentiality-Protection} to address the specific needs of SNMP,
could we at that point in time extend the list of enumerated values for the
Management-Transport-Protection to include special cases for SNMP?  That
would eliminate the need to restore the Management-Transport-Protocol
attribute which caused a number of difficulties in terms of management
transports other than those used for SNMP.  Once you specify the protocol,
then you logically need to specify all sorts of other protocol and security
related parameters.  I think we don't want to go down that path.

-- Why do we think that RADIUS authorization should be used to provision
specific secure transport properties, such as protocol, cipher suite,
authentication mechanism, certificate chains, etc?  It seems to me that
these choices, while important to get right, do not need to be conveyed on
each and every user access to the managed entity.  They would typically be
configured and left static for long periods of time.  Yes, it is required
that both ends of any such connection agree on the parameters, but it seems
RADIUS authorization is not the optimal way to ensure that.  I think that
the choice that needs to be made on an access by access basis is simply
whether or not the access needs to be secure.


_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms