Re: SNMPv3 security

Hi -

> From: "Fleischman, Eric" <[email protected]>
> To: "Randy Presuhn" <[email protected]>
> Cc: "Uri Blumenthal" <[email protected]>; "Wijnen, Bert (Bert)" <[email protected]>; <[email protected]>; "Eliot Lear"
<[email protected]>; "EXT-Weller, Michael K" <[email protected]>
> Sent: Thursday, August 07, 2003 9:31 AM
> Subject: RE: SNMPv3 security
>

> Thanks for your feedback, Randy. I concur with you that this belongs on the SNMPv3 list, but if it is moved
> there, then I will have no access to what is being posted, due to the fact that I am not a list member.

subscribing is not that painful, and the list administrator has, at least in
my past experience, been very good about granting posting rights.

> I disagree with your analysis paragraph below. Moving DES to AES will have almost no (zero)
> impact upon the SNMPv3 system because it doesn't address SNMPv3's totally broken Session
> Key approach.

???  Key lifetime is under control of the user / security administrator.  If you want to update
your keys every ten minutes, you can, though it doesn't address the more fundamental
question of the strength of the crypto algorithm

> All you are doing by transitioning from using DES to AES is perhaps delaying the bad guys a few
> hours before these keys are broken. That's almost nothing -- a false sense of security that accomplishes little.

You must know something about AES that I don't.  Any references to back up this claim
of relative lack of strength vis-a-vis DES?

> The interrelationship of the keys means that breaking one key greatly eases the breaking of them all,
> even if we are talking about dozens-of-remote-admins * thousands-of-SNMP-agents worth of keys,
> as we are in our system. The whole thing can be rolled up fairly quickly by security professionals
> because encryption in SNMPv3 is being applied in a barefoot manner.

It sounds like you're assuming that the key localization algorithm is insufficiently one-way.
I know there's been some speculation that MD5 might be inadequate for this purpose,
but has anyone actually demonstrated it?  In any case, I think Uri's AES i-d addresses
this (at least earlier versions did).

> The only way this can be remedied is not by doing minor tweaks of encryption algorithms
> but rather by redesigning the security system to place it upon a solid footing. Session
> Keys should have very short, finite lifetimes.

Nice in theory, but brings other costs and other risks, like
the possibility that session establishment will fail in highly
stressed networks.

> They should be established in real time for a predetermined time period by a Diffie-Hellman
> variant (e.g., consider the Oakley Key Determination Protocol). [If this is too heavy, then
> encrypt the session key with the localized key for that quorum or else look at the composite
> key approaches that have been considered by the secure multicast and IPSec working groups.]

Did you look at RFC 2786?

I still challenge your original assertion that SNMPv3
USM (possibly with AES) is inadequate.   All this
speculation about other ways that it might have been
done doesn't prove that any real problem exists.

> This may mean that either you switch to TCP as your underlying transport or else you invent an
> association of UDP packets having the same source-destination addresses within a
> bounded timeframe quorum. [Note: using UDP makes things difficult, but no harder than
> what one has to do at the IP Layer.] There should be no algorithmic relationship between
> any keys -- each should be independent from the other.

The decision to use key localization was made because implementation and
deployment experience with various flavours of SNMPv2 showed that using
totally independent keys scaled badly.  The assertion that key localization
presents a point of attack is based on the assumption that compromising a localized
key would provide information that would be useful in deriving either the initial
passphrase or some other localized key.  As far as I know, no one has been able
to justify such an assumption.

> These keys should be distributable
> via already existing key distribution systems (e.g., Kerberos, PKI), perhaps by using "seed
> key values", or else composite keys. In addition, whatever you do at the SNMPv3 application
> layer should be designed to work with security provisions at another layer.

Sure, the architecture allows you to define other security models like these, but
see the SNMPv3 WG archives for lots of reasons why one wouldn't want to mandate this.

> This means leveraging either the IP Layer using IPSec or the Transport layer using TLS
> or the application layer using SSH port forwarding (tunneling) -- or any or all of them --
> should be available to supplement SNMPv3's security provisions by SNMPv3's basic design.
> That is, when a deployment (i.e., an end user) is feeling exposed, SNMP is in a
> much better position offering many security options ranging from light-weight to
> extremely heavy, rather than the current posture of saying "we only play by ourselves
> so take it or leave it."

It sounds like you've missed the point of RFC 3411.

> --Eric
>
> -----Original Message-----
> From: Randy Presuhn [mailto:[email protected]]
> Sent: Wednesday, August 06, 2003 5:33 PM
> To: Fleischman, Eric
> Subject: Re: SNMPv3 security
>
>
> Hi -
>
>> From: "Fleischman, Eric" <[email protected]>
>> To: "Randy Presuhn" <[email protected]>
>> Sent: Wednesday, August 06, 2003 4:47 PM
>> Subject: FW: SNMPv3 security
>...
>
>> I'm sorry, Randy, but I didn't notice your request to be part of this discussion until after I had sent my reply
>> (below) to Uri and Bert.
>...
>
>Thanks.
>
>As a procedural matter, this *really* belongs on the snmpv3 WG mailing list.
>
>I prefer to avoid back-room discussions.   FWIW, all the issues you raise have been
>discussed in some form in that WG in the past.  The important ones from my perspective
>are the concern about cryptographic strength, which is addressed by Uri's AES I-D,
>and the fact that key management is a pain.  The latter is partially addressed by
>RFC 2786, but initial key establishment for "headless" boxes is simply hard
>to do well, and PKI doesn't make it any easier.
>
>Randy

Randy