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

["David Harrington" <ietfdbh at comcast.net>]

In thinking about this, SNMP needs to know what "model" is used to
authentication, and it know sthat RADIUS is the "model".

I think SNMP actually doesn't need to know how the encryption is done,
only that it is done. The operator can configure the underlying SSH or
other transport to use the approrpiate authentication and encryption
parameters.

So this may actually be a non-issue.
Do others agree?

dbh

> -----Original Message-----
> From: David B. Nelson [mailto:dnelson at elbrysnetworks.com] 
> Sent: Thursday, April 03, 2008 6:02 PM
> To: isms at ietf.org
> Cc: 'David Harrington'
> Subject: What granularity of attributes do we need for the 
> secure transport?
> 
> 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