Subject: RE: [Isms] Let's move forward now

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Wed, 9 Feb 2005 02:22:04 +0200

FWIW, I am also in favor of keeping TLS on the table for now. Out of the solutions under discussion it looks to me like the TLS-based one is closer to meet the goal of providing an acceptable security mechanism for different management interfaces, based on a technology quite well understood and deployed. Eliminating it will make it much harder to integrate the transport, security, data modeling, and access control in the future.

Regards,

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of David B Harrington
> Sent: 09 February, 2005 1:08 AM
> To: 'Ken Hornstein'; [email-masked]
> Subject: RE: [Isms] Let's move forward now 
> 
> 
> Hi,
> 
> I made the suggestion to drop the TLS proposal at the last meeting.
> 
> I do have hesitations about discarding this proposal however. Here are
> my thoughts.
> 
> Security is only as strong as its weakest link, and for device
> management, there are multiple links - interactive CLI, CLI scripting,
> web-based management (html/http), the emerging netconf, snmpv1,
> snmpv2c, and snmpv3. To build one of these management interfaces to be
> dramatically more secure than the others, without being able to fully
> retire the others, simply makes that choice not the weakest link; it
> doesn't help to balance the security across all the management
> interfaces.
> 
> CLI and CLI scripting are frequently secured with SSH, and netconf
> plans to utilize SSH as the preferred "application transport", so TLS
> will be used to secure these interfaces. Web-based mgmt utilizes
> HTTP/SSL (or TLS 1.0). Each of these approaches "outsources" the
> message security to the transport layer, and supplements that with a
> session-based user-authentication (for access control) at a higher
> layer.
> 
> For the best integration of SNMP security with the security used for
> other management interfaces, it would seem to make sense to also
> "outsource" the message security to the transport layer, and then
> supplement that with session-based user-authentication for access
> control. Either EUSM or SBSM could be used to provide the
> session-based user authentication for access control.
> 
> One of the charter goals is to "maximize useability in operational
> environments to achieve high deployment success and at the same time
> minimize implementation and deployment costs to minimize the time
> until deployment is possible."
> 
> Utilizing the same security approaches for SNMP as are used for CLI,
> CLI scripting, netconf, and web-based mgmt certainly eases the
> operational and deployment costs, and given that the operators
> indicated SSH as the preferred mechanism for netconf, I expect they
> would also support deploying it for SNMP.
> 
> Utilizing the same security mechanisms that are already in the devices
> in support of secure CLI, CLI scripting, and web-based mgmt helps to
> minimize the implementation costs for vendors, and could minimize time
> to deployment.
> 
> Of course, to utilize the same security mechanisms will require
> supporting a TCP transport for SNMP, something already specified in
> RFC 3430, or adding support for something similar to DTLS. To utilize
> SSH user-authentication (both centralized and local) would require
> adding an SNMP security model to leverage those. Again either EUSM or
> SBSM might be able to be adapted to provide this.
> 
> I believe the long-term benefits of differentiating transport security
> and access control security, and balancing the security across
> management interfaces, would justify keeping the TLS approach on the
> table.
> 
> David Harrington
> [email-masked] 
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Ken Hornstein
> > Sent: Wednesday, February 02, 2005 3:28 PM
> > To: [email-masked]
> > Subject: Re: [Isms] Let's move forward now 
> > 
> > >Vote was a poor choice of words, I agree.  My point was to figure
> out
> > >if one or more of the proposals could be discarded due to consensus
> > >not to head that direction.
> > 
> > Okay, well, in the interest of moving forward .... I suggest that we
> > eliminate the TLS proposal from consideration.  Comments?
> > 
> > --Ken
> > 
> > _______________________________________________
> > Isms mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/isms
> > 
> 
> 
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/isms
> 

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: Ken Hornstein <[email-masked]>
Date: Thu, 10 Feb 2005 13:39:37 -0500

Everyone,

I had gotten the feeling that there might be consensus to take TLS off of
the table from the last WG meeting.  That's really my only reason for
the suggestion (I know a couple of people asked me privately what my
reasoning was).

Clearly, there is _not_ consensus to do so, so TLS will still stay on
the table for now.

--Ken