Subject: Re: SNMPv3 security

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 7 Aug 2003 11:18:34 -0700

Hi -

> From: "Fleischman, Eric" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: "Uri Blumenthal" <[email-masked]>; "Wijnen, Bert (Bert)" <[email-masked]>; <[email-masked]>; "Eliot Lear"
<[email-masked]>; "EXT-Weller, Michael K" <[email-masked]>
> 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-masked]]
> Sent: Wednesday, August 06, 2003 5:33 PM
> To: Fleischman, Eric
> Subject: Re: SNMPv3 security
>
>
> Hi -
>
>> From: "Fleischman, Eric" <[email-masked]>
>> To: "Randy Presuhn" <[email-masked]>
>> 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

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 08 Aug 2003 09:40:18 -0700

>>>>> On Thu, 7 Aug 2003 11:18:34 -0700, "Randy Presuhn" <[email-masked]> said:

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

This has been discussed several times.  Just one more point that I
think Eric is trying to get across but most people are missing: Having
the key lifetime controlled by the manager means that if the box gets
disconnected from the network then the key can't be updated.  This is
important if the box contains critical data.  An attacker that can
sever the network connection (a simple DoS attack would suffice for
this) between the manager and the agent can then spend all the time
the needs to figure out the keys and access the contents of the box.
This is a big difference between other protocols (kerberos, IKE, etc)
that hold a key to a given lifetime at the box itself.  IE, after a
period of time the box itself refuses to reuse the key in question.
Eric's concern in this area is valid, IMHO, but is also nothing new.
Still, I think many people are missing this point.
-- 
Wes Hardaker
Sparta

---

From: Uri Blumenthal <[email-masked]>
Date: Fri, 8 Aug 2003 13:32:17 -0400

On Friday 08 August 2003 12:40 pm, Wes Hardaker wrote:
> disconnected from the network then the key can't be updated. 

And if the key update is not controlled by the manager and the box
got disconnected or DoS'ed - how will the box and the manager run 
their key renegtiation?

> that can

How? By sending messages to the box and watching how the box responds?
Please consider that the underlying crypto algorithms are designed to
withstand such an attack. And also, mis-encrypted packets will elicit 
no response at all, and mis-authenticated packets will at best (for
the attacker) elicit a trap.

There's no known cryptanalytic attack (even if you're using DES :-)
against such setup - and the exhaustive search (guessing of the key
going through every possible one) isn't likely to succeed against 
either AES or HMAC (success probability 2^-127).

> that hold a key to a given lifetime at the box itself. 

I agree that it may be a good idea to add a MIB object "keyLifeTime"
measured in bytes, 64-bit counter. 

> IE, after a

OK, from security point of view it's fine. In practical language it
may mean that somebody has to go to the device and change the key.
(In a smart setup there would a "privilleged" user/key used
only for key updates and not for traffic :-).

> Still, I think many people are missing this point.

:-)

[You don't know how difficult it was to just get agreement to move
from plain MD5 to HMAC. And it wouldn't have happened without Jeff
Schiller. :-]

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 08 Aug 2003 10:45:30 -0700

>>>>> On Fri, 8 Aug 2003 13:32:17 -0400, Uri Blumenthal <[email-masked]> said:

Uri> And if the key update is not controlled by the manager and the box
Uri> got disconnected or DoS'ed - how will the box and the manager run 
Uri> their key renegtiation?

They can't.  I didn't say this should be mandatory to use (which you
seem to think I was saying).  The option should be there, however
(which you later agreed with, so your statement above is a bit odd).

Point being, is that if I want a key lifetime of 1 week, for example,
I'd likely renegotiate daily (for example) and if I failed that for an
entire week, I probably don't want the box to respond to anyone as
there is likely a severe problem with it and I'll want to scrub it.

>> that can sever the network connection (a simple DoS attack would
>> suffice for this) between the manager and the agent can then spend
>> all the time the needs to figure out the keys and access the
>> contents of the box.

Uri> How? By sending messages to the box and watching how the box
Uri> responds?

Many ways.  We both agree that attacking the current algorithms is not
an efficient way to go about it.  However, attacking via human
passwd->key conversions works (and hence shouldn't be used but as
you yourself stated, people do it).  Attacking the humans themselves
work as well (wait till they get off work and threaten them outside
their secured work environment to get the key that the replacement
operators changed on all the boxes "they could get to").
...

>> that hold a key to a given lifetime at the box itself. 

Uri> I agree that it may be a good idea to add a MIB object "keyLifeTime"
Uri> measured in bytes, 64-bit counter. 

Agreed almost.  A configurable integer might wiser, however (again, it
doesn't mean you can't turn of write-access to it if you don't want it
remotely manageable).

>> IE, after a period of time the box itself refuses to reuse the key
>> in question.

Uri> OK, from security point of view it's fine. In practical language it
Uri> may mean that somebody has to go to the device and change the
Uri> key.

Only in the extreme cases where you fail to update the key remotely.

-- 
Wes Hardaker
Sparta

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 08 Aug 2003 10:53:36 -0700

Oh, and I meant to add "using a public-key based renegotiation", IE a
DH based re-init would also work.

-- 
Wes Hardaker
Sparta