Subject: [Agentx] SNMP v3 Security Considerations

From: "[email-masked]" <[email-masked]>
Date: Fri, 13 Jun 2008 23:54:10 +0900

After having read all of the latest RFC's concerning SNMP v3, I've
notice that there is no mention about one possible weakness when using a
combination of SNMP v3 or SNMP v3 in combination with v2 and/or v1 in a
single device.

Devices such as Cisco Switches and Routers as well as many other
vendor's devices often allow the ability to specify several types of
SNMP support in their configuration.

In that concern, I think a WARNING should be added for the following
combinatoric usage:

1) If SNMP v3 AuthPriv is used in combination with AuthNoPriv
2) If SNMP v3 AuthPriv is used in combination with NoAuthNoPriv
3) If SNMP v3 AuthPriv is used in combination with SNMP v2c
4) If SNMP v3 AuthPriv is used in combination with SNMP v1

All 4 of the above combinations include Encrypted data as well as
PlainText data.

If any device is configured simultaneously with any one or more of the
above combinations, they will be virtually giving away their Encryption
Key because if a device is configured with any PlainText along side
Encrypted text, it will make it very easy to crack the key!

As such, a WARNING against such usage should be included in one or more
of the latest SNMP v3 RFC's where Encryption is mentioned.

Sincerely,
Walter Benton

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 13 Jun 2008 10:36:42 -0700

Hi -

Though slightly off-topic for this list....

> From: <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, June 13, 2008 7:54 AM
> Subject: [Agentx] SNMP v3 Security Considerations
...
> Encrypted text, it will make it very easy to crack the key!

It may be "very easy to crack the key" (for differing opinions of "very easy"),
but having some unencrypted messages available doesn't really make
the job significantly "easier."

First, the queries coming from most management systems are
rather predictable, except perhaps for the request-id.    Furthermore,
ASN.1 BER  encoding is predictable enough to allow an automated
brute-force attack to determine whether it has found the key. Having
access to other request/response pairs which are not encrypted
doesn't provide the attacker with a plaintext that is better known.

Secondly, and more importantly, having a plaintext is not all that
helpful in figuring out the key for CBC-DES - it just provides a
way of verifying that one has found the correct key.  However,
BER encoding is brittle enough that if the result of decrypting
with an attack key passes the parse unscathed, the key is likely
to be the right one. 

RFC 3826 could also be used if you wanted a different value for
"very easy".

Randy