Subject: RE: [Isms] Reminder: ISMS proposals due October 18th

From: "Fleischman, Eric" <[email-masked]>
Date: Thu, 14 Oct 2004 16:57:38 -0700

Friends,

I've seriously considered securing SNMPv3 via TLS. I concluded that it was an enhancement for the SNMPv3 privacy provisions, but that it was not a significant improvement for the authentication/authorization needs that we were seeking in our environment. Rather, what I really wanted was to leverage our existing key management infrastructure into SNMPv3 so that we could create consistent system wide (and multi-application) security policies. This is why my own preference is for approaches that leverage PKI or Kerberos or some other existing key management system. 

I know that an articulation of what key management systems are more desirable for our community to support is inherently controversial, to the extent of being a non-starter (i.e., probably a waste of time). However, speaking from my own very parochial knot hole, a PKI-based approach would be very much in synch with the strategic goals of my employer for our own internal networked systems. Therefore, my own preference, when considering ISMS alternatives, are for systems that support PKI.

--Eric

-----Original Message-----
From: Wes Hardaker [mailto:[email-masked]]
Sent: Thursday, October 14, 2004 3:11 PM
To: McDonald, Ira
Cc: [email-masked]
Subject: Re: [Isms] Reminder: ISMS proposals due October 18th

>>>>> On Thu, 14 Oct 2004 23:55:00 +0200, Juergen Schoenwaelder <[email-masked]> said:

Juergen> There are also a bunch of question how you would support
Juergen> SASL. Do you do an ad-hoc SASL exchange before you declare
Juergen> the SNMP/TLS session to be open for SNMP or do you SNMP style
Juergen> messages to actually wrap a SASL exchange, potentially
Juergen> running the SASL exchange as part of the security model box
Juergen> of the architecture. There are serious design decisions here
Juergen> and it is unlikely that these will be solved by Monday.

The chairs would have to answer how much of an complete architecture
it needs to have to be considered.  I'd write up both possibilities
most likely and say the choice needs to be made in the future.  The
intent of the deadline was to have a thought out architecture that was
believed to be suitable so we could consider it as a path forward.  I
don't think it needs to be perfect, just plausible.  I'd assume that
it'd be ok to define both solutions or pick one that you like and we
can debate whether that solution was right after it gets selected as
the candidate to work on.

If there are so many people interested in a TLS solution, how come
no-one is willing to do the work?  If thats the case, then even if we
all agreed that TLS is the right way to go would be we better off if
no one agreed to do it?  We need an author to step forward with
enthusiasm ASAP.

-- 
Wes Hardaker
Sparta

_______________________________________________
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: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 15 Oct 2004 11:16:13 +0200

On Thu, Oct 14, 2004 at 04:57:38PM -0700, Fleischman, Eric wrote:

> I've seriously considered securing SNMPv3 via TLS. I concluded that it 
> was an enhancement for the SNMPv3 privacy provisions, but that it was 
> not a significant improvement for the authentication/authorization needs 
> that we were seeking in our environment. Rather, what I really wanted 
> was to leverage our existing key management infrastructure into SNMPv3 
> so that we could create consistent system wide (and multi-application) 
> security policies. This is why my own preference is for approaches that 
> leverage PKI or Kerberos or some other existing key management system. 

I am using SASL enabled protocols all the day and so I would think that
authenticating SNMP users via SASL should fit at least some operational
requirements. Sure, in a kerberos environment, leveraging kerberos
services makes sense. The problem I see is that not all environments
are the same nor that all SNMP interaction patterns are the same. So
searching for the holy grail is kind of doomed to failure (and that
probably reduces my enthusiam here a bit).
 
> I know that an articulation of what key management systems are more 
> desirable for our community to support is inherently controversial, 
> to the extent of being a non-starter (i.e., probably a waste of time). 

Exactly.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany