RE: SNMPv3 security

HI,

On the below (and all of this applies to USM, but not necessarily
to other security models for SNMPv3):
1) A user's passphrase is not ever kept on the managed system (unless
   you want security to be easily compromised for the network)!
2) What is held in persistent storage on a managed system is auth
   and privacy keys. (And how these are protected is a local
   matter, and it better be good)
3) The keys don't have to be generated via the pass phrase to
   localized key algorithm!
4) Learning the SNMP engine ID of any system is not secured, and is a
   "normal" part of interacting with a managed system. There are
   no assumptions in the USM that an SNMP engine ID is sensitive
   info. But the critical part is that determining a user's pass phrase
   basically gives access to all devices managable by the user
   (as long as the keys have been created via the pass phrase
   to localized key algorithm) without any need for crypto
   breaking tools. (It's like stealing an ID card).

>4) SNMP symmetric keys assembled from passwords
>Section 2.6 of RFC 3414 states that the administrator's localized key, Kul, is created by that user's password plus the snmpEngineID for that specific SNMP engine (i.e., that SNMP agent). This result is then hashed by either MD5 or SHA-1 to create the localized key. (As such, this represents an improvement to the earlier algorithm that was previously described in RFC 2274. By the way, how can we know whether the remote systems are using the algorithm of 2274 or the one for 3414 to create the symmetric keys?)
>
>I haven't spent as much time with RFC 3414 as I have with RFC 2274, which it obsoleted, but I assume that the MD5 or SHA-1 HMAC, which is used for SNMPv3 message authentication and integrity, as well as the DES key in CBC mode, which is used for message privacy, still are directly computed from the localized key, as it was in RFC 2274 (i.e., this point is not as obvious in RFC 3414 as it was in RFC 2274). If this is indeed the case, then you can readily understand my concern that the common derivation of the these symmetric keys system-wide means that the compromising of the one half of a user's key, greatly eases the compromization of the remainder of that key. Furthermore, the compromization of one user's key greatly eases the compromization of another user's key. For example, if we assume that that even one administrator's password was exposed, then it is a somewhat straightforward matter to learn the snmpEngineID for that device. Once that is known, then one can see how 
 e!
asy it is to systematically compute other user passwords for that snmpEngineID, and from there other passwords on other snmpEngineIDs, thereby fully exposing the entire SNMPv3 cryptographic system, since these keys are all algorithmically related. I know of no other IETF protocol with similar key composition dependencies.

Regards,
/david t. perkins