Re: [Agentx] SNMP v3 Security Considerations

["Randy Presuhn" <[e-mail]>]

Hi -

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

> From: <[e-mail]>
> To: <[e-mail]>
> Sent: Friday, June 13, 2008 7:54 AM
> Subject: [Agentx] SNMP v3 Security Considerations
...
> 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!

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