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

From: "Fleischman, Eric" <[email-masked]>
Date: Tue, 1 Mar 2005 12:34:05 -0800

From: Blumenthal, Uri [mailto:[email-masked]] 
>> Due to problems with the USM Authentication system,

>For the second time in this exchange I'm asking what 
>specific problems you're talking about.

The problems are due to loosely-defined concepts and ill-advised
assumptions/oversights, when viewed from a system perspective, within
the SNMPv3 USM itself coupled with the many optional elements in the
specs (i.e., RFCs). These create uneven vendor implementations that
cause inherent security gaps and flaws in multi-vendor deployments.
These problems are exacerbated by the following security blemishes in
the USM itself, which enable these gaps to be leveraged into
***significant*** security vulnerabilities:
1) no provisions for two-factored authentication
2) SNMP symmetric keys may be assembled from passwords
3) Key updates do not provide for Perfect Forward Security
4) Inherent Symmetric Key distribution problems
5) Lack of viable session keys
6) SNMPv3 USM keys are unrelated to any existing authentication system
within a deployment (e.g., Kerberos, PKI, Radius, etc.)

>> including significant weaknesses in SNMP key distribution in large 
>> multi-vendor environments,

>Weaknesses such as...? Be specific please.  And what does
"multi-vendor" have to do with this?!

For example, some commendable SNMP products support RFC 2786 (see
http://www.ietf.org/rfc/rfc2786.txt), which provides a
Diffie-Hellman-like key exchange mechanism that is available for SNMPv3
systems to use. Most/many vendors have not implemented this. Some SNMPv3
products require that keys must be based on passwords due to their
inherently weak key distribution capabilities. Some don't have any key
distribution systems at all. 

"Multi-vendor" is the key operative word in my communications because a
function of extremely large deployments is that we have "at least one of
everything." Thus, we don't have the luxury of choosing only the vendors
with so-called "good" USM implementations but rather have to leverage
whatever capabilities are supported in the products and try to make a
coherent system out of it. This often devolves into the least common
divisor -- a horrific result from the security perspective. This is
characteristic for large deployments in general, which also have to
address inherent scalability issues that do not exist in small
deployments (e.g., less than 100,000 devices). 

>> a very real possibility exists that Bad Guys can learn the identity
of 
>> legitimate managers and spoof them.

>Identities of the entities that establish the session must be revealed
- 
>unless you're willing to pay for anonymous Diffie-Hellman. Please
explain 
>how one can spoof a legitimate manager (as this implies that
authentication
>mechanism is broken).

No. You are still thinking that USM doing its own authentication system
is viable. It isn't, not by a long shot. SNMP is only one
application!!!! It is prohibitively expensive to create authentication
systems deployment-wide. Large institutions usually have several generic
authentication systems deployed within the Enterprise including PKI
(e.g., primarily for application authentication), Kerberos (e.g., for MS
Windows), and Radius (e.g., perimeter or security zone access control).
Few companies can afford to create a separate authentication system for
SNMP only. Please note that SNMP's security is distinct from other IETF
protocols (I state this because I've studied the key management
approaches used by ALL of the IETF protocols) and is also unlike any
other system deployed in our infrastructure (that I've encountered, at
least). 

>>: You are putting all of your eggs in the session security basket. 
>> However, what is needed is good defense in depth protections for the 
>> system as a whole. This is an elementary security precept, which is
made
>> all the more important for SNMPv3 due to widespread system 
>> blemishes/flaws with the USM security system as a whole when deployed

>> within large, multi-vendor environments.

>Please be specific. I'm getting tired watching all this hand-waving 
>about some unspecified indescribable "widespread system 
>blemishes/flaws". This is not a PR forum, after all.

And I'm getting tired of providing elementary, Security 101 explanations
as to why it is so very easy to crack SNMP systems!!! What do you want:
a list of 30 different step-by-step ways to crack SNMP? Egads! That
would demonstrate NOTHING because each instance is a function that the
USM security *****SYSTEM***** itself is not viable. This is partially
evidenced by the fact that the security capabilities of different
vendors SNMP products do not adequately work together and partially
evidenced by the flaws in the USM security system itself that I have
been highlighting. 

All security systems, including USM, are subject to a similar set of
traditional threats. These traditional threats include: bypass
(unauthorized leaking of info (e.g., between security zones/COIs)),
compromise (unauthorized reading of data), tamper (unauthorized writing
of data), cascade (failure in one partition/security subsystem causing
failure in another), covert channel (malicious or erroneous code using
authentication processes and side effects in order to leak information),
subversion (trick an authorized person to install bad software into the
system believing that it is good software or to reveal key
authentication info; etc.), and virus (use of tamper to have malicious
code replicate itself throughout the system). Of course, many of these
are artifacts of USM being deployed within specific environments (e.g.,
operational security), but these vulnerabilities are greatly magnified
by inherent weaknesses within the USM itself. For example, the fact that
the USM implements a unique authentication system within the deployment
makes it orders-of-magnitude more vulnerable to subversion, for example,
than had it used a generic, infrastructure-wide authentication system
(e.g., Kerberos, PKI, Radius, etc). 

These are NOT difficult concepts to understand. Any CISSP should
intuitively understand these elementary issues without my having to
mention them.

--Eric

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

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 01 Mar 2005 15:50:14 -0500

>within a deployment (e.g., Kerberos, PKI, Radius, etc.)

While I agree that the above things are not ideal, I don't think any of
these points are what I would call "signficant" security vulnerabilities.

>From a _protocol_ standpoint, USM has had signficant peer review.
Considering it's goals, I think it's a reasonable protocol.  The only
downside I see in it is that the base spec only specifies DES and MD5
(but a later draft did specify AES).  I don't even think DES was a huge
problem in practice, because crackers aren't really doing DES brute-force
attacks currently (they have so many other avenues).  That's not to
say we shouldn't be moving away from DES, but I don't think it's
currently a fatal flaw.

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