Subject: RE: [Isms] achieving market saturation with ISMS (fwd)

From: "Fleischman, Eric" <[email-masked]>
Date: Tue, 1 Mar 2005 13:46:25 -0800

From: Ken Hornstein [mailto:[email-masked]] 
>I think we all agree that from a _deployment_ perspective, 
>USM's problem is Key Mangement (which is basically the root 
>of most of your above points).  That's why we're here.  But 
>strictly speaking, this is outside of the scope of the USM 
>_protocol_ (the USM RFC also specifies some of the USM key 
>management, so it's a bit confusing).  Uri's talking about 
>the protocol; you're talking about the deployment/key management.  
>Can we all move on now?

Ken, 

Actually, Uri was stating that enhancing Session management alone would
meet the ISMS goals. While I agree that session management is needed, I
was arguing that we also need enhanced key management. I believe that my
arguments are consistent with the ISMS charter, which says (in part):
"The ISMS working group will focus on finding and identifying a solution
for the first of the two above mentioned problems: creating a security
model for SNMPv3 that will meet the security and operational needs of
network administrators." If you concur, then we should move on.

However, I don't see how we can move on profitably until we have defined
a common set of requirements and common set of criteria in order to
evaluate the three proposals. That is the view from my knothole. How do
Juergen and you propose that the WG proceed from this point? That is, I
don't see how the published agenda for the forthcoming IETF will enable
us to reach our March 5th milestone. Would you mind sharing with the
group how you expect that the WG to achieve that milestone? 

--Eric

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

---

From: "Ken Hornstein (Contractor)" <[email-masked]>
Date: Tue, 01 Mar 2005 17:34:07 -0500

>was arguing that we also need enhanced key management.

I went back and read Uri's messages; my interpretation of his messages is
that adding a session will facilitate many things ... including enhanced
key management (sure, I suppose we could do a session _without_ enhanced
key management, that would be theoretically possible, but there would
be no point and I think that everyone agrees on this).

>I believe that my

I think we _all_ concur on that one.

>group how you expect that the WG to achieve that milestone? 

We are having a conference with our AD, hopefully this week.  I am
sure this will be a discussion item.  So ... "we're working on it".

--Ken

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 1 Mar 2005 17:37:57 -0500

Hi Eric,

I agree it would be helpful to have a more concrete set of goals.

I have a question for you. It's a hard and detailed question. You and
I disagree on the nature of the security requirements. I think RFC3411
documents the security requirements; you have a different list. 

I am not a security dweeb; I'm an NM dweeb ;-)

Understand that your comments that the USM specs are "too loose" or
"vendor implementations are too inconsistent" just doesn't give us
enough to go on to understand the nature of the security threat
enabled by the difference between USM and your requirements, that we
could actually address as protocol developers.

Can you explain (in reasonable detail to a non-security person) the
nature of the threats that are enabled by the difference between the
RFC3411/USM security requirements and your requirements, and how those
threats will drive implementation compliance by vendors and deployment
compliance by operators? 

Vendor implementations are inconsistent because economic forces work
against our desire to have better compliance to our standards. There
is nothing we as protocol designers can do to overcome that fact. What
we can do is try to better understand your concerns and try to address
them. But I for one do not "grok" the security benefits of each of
your requirements over USM enough to be able to understand the
engineering cost/benefit ratios involved. 

How often are you getting hit with attacks that would be thwarted by
support of two-factored authentication? How critical are those attacks
to your network? Are the attacks that are enabled by non-two-factored
authentication well-documented as a serious problem with no other
solution to mitigate their seriousness? Are these attacks something
that are especially attractive to attackers for attacking a management
protocol like SNMP, or are these attacks so easy to do and effective
in other instances, like network access that most attackers wouldn't
bother attacking SNMP? What are the implementation and operational
costs and corresponding benefits? Vendors don't implement according to
the IETF standards now; what economic drivers that are ineffective
getting compliance now will kick in to motivate them to support
two-factored authentication if we write a standard that specifies it?

If you can't provide solid justification for increasing the
requirements above the RFC3411/USM level, I have trouble justifying
committing resources to do so. As the network management architect of
a vendor, I would need to sell such solutions to engineering, product
management, and marketing and I would need to justify the resources it
would take to offer such solutions. Customers continue to buy products
from vendors that do not comply with IETf standards. You said yourself
you need to buy the equipment, and cannot choose to buy only a
compliant product. How will having these features in their products
increase a vendors' sales? How will lack of these features hurt a
vendors sales?

I would have tremendous difficulty justifying the engineering expense
of migrating from USM to a model that offers the features you want
because I don't know what concrete benefits this migration would
yield, and I wouldn't know how to market to our customers the benefits
of having such features in our product lines. We can't even convince
customers they need the increased security provided by USM and VACM.
Can you help me understand how to justify moving from RFC3411/USM
requirements to your specific requirements? 

Thanks,
David Harrington
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Fleischman, Eric
> Sent: Tuesday, March 01, 2005 4:46 PM
> To: Ken Hornstein; [email-masked]
> Subject: RE: [Isms] achieving market saturation with ISMS (fwd) 
> 
>