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

From: "Fleischman, Eric" <[email-masked]>
Date: Tue, 1 Mar 2005 08:55:10 -0800

Due to problems with the USM Authentication system, including
significant weaknesses in SNMP key distribution in large multi-vendor
environments, a very real possibility exists that Bad Guys can learn the
identity of legitimate managers and spoof them. Good session protections
are a helpful but inadequate defense against that.

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.

-----Original Message-----
From: Blumenthal, Uri [mailto:[email-masked]] 
Sent: Monday, February 28, 2005 6:04 PM
To: [email-masked]
Subject: RE: [Isms] achieving market saturation with ISMS (fwd) 

> I certainly agree with you about the need for "session" but I do not 
> believe that "session" alone will meet all of our needs. Specifically,
I
> remain very concerned about weaknesses in the authentication system 
> being exploited by crackers.

What specific weaknesses in what part of authentication system?
Rememeber that the traffic is protected by session-wide keys that are
created when the session is established and are gone once the session is
terminated.

_______________________________________________
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: "Blumenthal, Uri" <[email-masked]>
Date: Tue, 1 Mar 2005 12:15:35 -0500

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

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

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

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

-----Original Message-----
From: Blumenthal, Uri [mailto:[email-masked]] 
Sent: Monday, February 28, 2005 6:04 PM
To: [email-masked]
Subject: RE: [Isms] achieving market saturation with ISMS (fwd) 

I

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Tue, 1 Mar 2005 12:24:05 -0500

I expect this ratio to change favorably once EUSM is out.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Wes Hardaker
Sent: Tuesday, March 01, 2005 12:21 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Isms] achieving market saturation with ISMS (fwd)

David> I have seen many complaints that SNMPv3 is hard to deploy; I
David> have been trying to address the deployment issue, and I think
David> the bulk of the WG are focusing on the deployment issue. In an
David> IAB workshop for network management, with numerous operators
David> present, there were complaints about the SNMP ease-of-use, but
David> none about SNMPv3 not being secure enough. I think 90% of
David> operators are satisifed that USM is secure, and the WG is
David> trying to make it possible for that 90% to deploy SNMPv3 (with
David> security comparable to USM) more easily.

[I've been away or unavailable for the last two weeks and am trying to
catch up...]

The survey I conducted asked operators (reminder: almost entirely from
NANOG advertising, but not a few others responded as well):

When asked the question:

  Is the current SNMPv3 with USM sufficiently secure for your needs?

The responses were:

     38 Abstain
     37 No
     74 Yes

Thus the data from my side resulted in 69% of one set of operators
thought it was secure enough.  This is certainly above half, but
certainly a lot lower than a complete agreement.

-- 
Wes Hardaker
Sparta

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Tue, 1 Mar 2005 16:00:24 -0500

Thank you, I think I've seen enough. I'm through with this discussion.

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

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

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

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

>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

---

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

I apologize to the list for my have used evocative language and
far-too-strong-statements in my posting below. This reflects my growing
frustration with this dialog. Nevertheless, it was very wrong of me to
have used such evocative expressions and statements, which is unworthy
of this list. Please forgive me.

-----Original Message-----
From: Fleischman, Eric 
Sent: Tuesday, March 01, 2005 12:34 PM
To: [email-masked]
Subject: RE: [Isms] achieving market saturation with ISMS (fwd) 

of 

explain 
authentication

--Eric

---

From: "Fleischman, Eric" <[email-masked]>
Date: Wed, 2 Mar 2005 08:38:47 -0800

Good summary, Juergen. The only change that I would suggest to it is that option A should also include PKI and Kerberos support, which the EUSM people said that they could also support. 

-----Original Message-----
From: JÃ¼rgen SchÃ¶nwÃ¤lder [mailto:[email-masked]] 
Sent: Tuesday, March 01, 2005 11:39 PM
To: Fleischman, Eric
Cc: [email-masked]; Ken Hornstein; [email-masked]
Subject: Re: [Isms] achieving market saturation with ISMS (fwd)

[...]

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

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Wed, 2 Mar 2005 19:49:19 -0500

IMHO, while what you're saying is correct - it doesn't address the cause of the problem. Thus it is difficult to properly address it.

The issue is not whether USM is good or bad. The issue is what capabilities are needed, that are currently missing, and what's a good way to add them. I suggest that session establishment and teardown is what's lacking now. Once that is in place - we can check what other services (per-packet authentication, encryption, timeliness verification) are present or missing, and act accordingly.

Desire of modularity suggests that (like in all the other security-related protocols) session establishment mechanisms are separated from those actually protecting the traffic. It allows interchanging on either level.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of JÃ¼rgen SchÃ¶nwÃ¤lder
Sent: Wednesday, March 02, 2005 2:39 AM
To: Fleischman, Eric
Cc: [email-masked]
Subject: Re: [Isms] achieving market saturation with ISMS (fwd)

[...]

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

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