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

From: "Fleischman, Eric" <[email-masked]>
Date: Wed, 2 Feb 2005 11:17:44 -0800

I think that this is a good idea. However, I'd also like to know *why*
that person voted as he/she did including the specific problems he/she
had with the proposals they did not vote for. 

-----Original Message-----
From: Wes Hardaker [mailto:[email-masked]] 

<snip>

So another thought would be why don't we request feedback from the WG
now about which proposals they think should go forward and see if we can
eliminate some now?

Options:
  1) vote for 1
  2) vote for up to 2
  3) vote for up to 3

I actually think #2 is useful, but probably #1 will produce better
direction assuming there is no dead-even split.

We've certainly had enough banter about them all so in theory we should
be informed enough about them to make a choice (even if the there is
disagreement about their analysis of the costs and benefits of each
one).

Anyone else feel this would be worthwhile?

-- 
Wes Hardaker
Sparta

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

---

From: "McDonald, Ira" <[email-masked]>
Date: Tue, 8 Feb 2005 15:59:40 -0800

Hi,

I agree with David's rationale for keeping TLS on the table.

Bear in mind that currently RADIUS has no mind-share at all 
as an authentication mechanism for systems management but
(as David observes below) SSL/TLS has all the marbles.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of David B Harrington
Sent: Tuesday, February 08, 2005 6:08 PM
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] 

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