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

From: "Fleischman, Eric" <[email-masked]>
Date: Tue, 1 Mar 2005 17:31:54 -0800

David,

I believe your true issue, David, is whether the USM can simultaneously
leverage public authentication systems and remain otherwise unchanged in
a backward compatible manner or whether a more capable alternative to
USM needs to be devised that is distinct from USM. If we do the latter,
I urge you to please create an SNMPv3 security environment that can meet
every deployments' security needs (i.e., the current ISMS charter).

SNMP security is inherently difficult. If that were not so, then there
would have been security within SNMPv2. Thus, my criticisms of SNMPv3
USM should not be interpreted as deprecating the important and difficult
accomplishments of the SNMPv3 USM community. However, simultaneously,
there were oversights and unfortunate assumptions which that community
made, which are largely due (in my opinion) from not having a system or
end user perspective -- but this is a characteristic weakness within
IETF work in general because there are so few of us end users
participating in the IETF. Less controversial is the observation that
security aids (such as viable enterprise-wide authentication systems)
now exist that the SNMP security community can leverage today that
weren't similarly widely available in the past. Also, other relevant
IETF protocols have matured (e.g.,
http://www.ietf.org/internet-drafts/draft-rescorla-dtls-03.txt) such
that they offer attractive technology alternatives that previously could
not be on the table.

My list of security requirements are basically tools to enable SNMP to
have normal defense in depth protections that are common on most other
systems, including many other IETF-defined protocols. For example, two
factor authentication is only needed if one is insecure about the
viability of the SNMP authentication system due to possible compromises
during key distribution, or having doubts about the controls that
protect the integrity of the authentication system itself (e.g., the
controls to defend against subversion, covert channel, or other
well-known threats). In many multi-vendor environments, there is plenty
of reason to be skeptical about the integrity of the USM authentication
system, unless adequate controls have been explicitly introduced to
mitigate those concerns, which isn't always possible and may be quite
expensive. For example, SSH can implement two factor authentication
capabilities that system administrators may want to implement if they
are worried about the viability of the user's crypto-identity. It's not
that that capability has to always be implemented, it is rather that it
is a good tool to address certain classes of threats -- or perceived
threats. If SNMP does not similarly implement this capability, then that
type of control will not be available to the system administrator if
needed.

I am not comfortable about talking about specific exploits, other than
to say that it is my perception that SNMP security is the weakest
security system, with the fewest number of available controls, of the
systems I deal with.  

I assume that you are familiar with the practices and philosophy behind
quantitative risk analysis and qualitative risk analysis. That is,
security has costs and so each infrastructure needs to determine how to
get the best protection for their critical systems within their
available budget. This often results in trade-offs that can be partially
mitigated by defense in depth protections. Thus, no two networks
necessarily have identical strengths and weaknesses, and thus their
susceptibility to specific types of exploits may vary. This is why some
infrastructures will not implement SNMP security at all, trusting other
systems (e.g., perimeter firewall) to protect them. Other systems are
well served by USM security as it is currently defined, particularly the
smaller or homogeneous deployments. However, other systems, the type I
work with, need the type of defense in depth protections/provisions I
have been arguing for.

Why should you migrate from USM if USM fully meets your needs? However,
if USM doesn't and can't meet the needs of many other communities, then
why aren't you willing to permit a robust SNMPv3 security alternative to
USM to be defined (i.e., fulfilling the ISMS WG charter that says
"creating a security model for SNMPv3 that will meet the security and
operational needs of network administrators")? From where I sit, both
the "no security" and "USM security" options remain on the table. What I
am urging is to have a third alternative that meets the more robust
security needs of my type of deployment.

--Eric

-----Original Message-----
From: David B Harrington [mailto:[email-masked]] 
Sent: Tuesday, March 01, 2005 2:38 PM
To: Fleischman, Eric; 'Ken Hornstein'; [email-masked]
Subject: RE: [Isms] achieving market saturation with ISMS (fwd) 

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

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

---

From: Jürgen Schönwälder<[email-masked]>
Date: Wed, 2 Mar 2005 08:39:20 +0100

[...]

Having read all these messages, I still believe we have a very simple
situation. We have the following proposals on the table:

a) Leave the USM protocol largely unchanged and add sessions, session
   keys and AAA support to it. (EUSM)

b) Replace the USM protocol with a new security protocol which is 
   designed to leverage already deployed keying protocols and 
   potentially also session based security protocols. (TLSM is trying 
   to leverage existing security protocols while SBSM is a new 
   security protocol trying to interface to keying protocols if
   I got that right.)

The point here is that depending on your environment, you either 
prefer a) over b) or b) over a). While I know what the answer 
would be for the environments I am working in, I do understand 
that other environments are simply different.

In case the above reading of the state of affairs is true, we should
IMHO work towards agreement on these two fundamentally different 
approaches and we should have a constructive dialog with the powers 
how to handle this situation. Arguing against each other just creates 
unnecessary heat and does not help us to move forward.

/js

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