Re: SNMPv3 security

On 8/7/2003 6:02 PM, Fleischman, Eric wrote:
>>I have no idea why you don't think a simple application can't be written that
>>will update SNMP passphrases as often as you want to on your network........

Only (localized) keys would be sent over the network. And if there's a good
automated management environment, then there would be no passphrase at all.

> Sending passwords out to thousands of devices on a small quantum basis
> consumes large amounts of bandwidth, which is very limited in many
> wireless systems.

Sending passwords out?  Nobody sane is doing that, nor is there any
provision for it in the protocol.  But you contradict yourself - if
session keys were used, establishing those would consume tremendous
amount of bandwidth (because it takes more than just "sending
passwords out" to complete key negotiation).

Looks like you lack understanding of several key (no pun intended) points.

1. Passphrases are not required - they're simply ALLOWED to accomodate
   for the existing practices of network administrators. And measures
   are taken to minimize the security impact of passphrase existence
   (minimize - but not eliminate). A secure installation doesn't
   need them.

2. Traffic protection keys (under which actual encryption and auth are
   done) are cryptographically independent. Since it looks like I need
   to explain what it means: knowing any subset of the localized keys,
   it is not feasible to deduce any bit of any key outside of that set.

   If you feel cryptographically up to it, please show otherwise.


3. SNMP does not have a concept of Session (nor state), so no session
   keys. On the other hand, it is reasonably safe to protect about
   2^60 messages before rekeying is necessary. This is for both
   AES and HMAC (actually, HMAC treshold is even higher, but...).

   If you can show how even one bit of a localized key (which encrypts
   the traffic) can be deduced from say, 2^64 SNMP messages, please be
   nice to all of us and show the attack. Otherwise, consider speaking
   of what you know, not of what you think you heard.

   If a localized key gets compromised (e.g. bad guys applied a hacksaw
   to a stolen router and pried the key out of its dead memory :-), can
   you show how to derive ANY knowledge of ANY other key in the network?

4. Diffie-Hellman is way too heavy for routine SNMP operations. It may
   be (and actually is) used for the initial key distribution - check
   RFC 2786. It might be used [seldom] to achieve PFS in rekeying.

5. Regarding changing the IV value. It is very significant. If you aren't
   doing that, the chance of an adversary collecting a ciphertext dictionary
   becomes real. But your admission of lack of insight on this subject (which
   is coupled with the lack of understanding of SNMP) suggests that it may be
   premature for you to jump to analysis of SNMPv3 security.

6. SNMP is an asymmetric protocol - very much unlike IPsec. Thus the NMS
   "controls" the security (actually, including the policy) of managed
   boxes. So it has the complete control of what the new key should be
   (unlike bilateral key agreements in other protocols).

   What might be useful is defining MIB objects "keyLifeTime" that
   counts the traffic protected by a given key, and treshold for it.
   But then, again unless the NMS decides to change the key on the
   box, the box can do nothing about it.  And NMS doesn't need MIB
   to perform that kind of management. I'm sure David Spakes from
   SNMP Research can talk more about it.

7. Dave Perkins gave an excellent example. IF passphrase is used by an
   admin, then stealing it gives access to all the devices managed by
   that admin - just like stealing an ID card gives an access to all
   the doors that the given card unlocks. Conclusion - if your net
   uses passphrases for security - you better guard them well.

8. You said "weak authentication approach" used in SNMPv3. First of all,
   this very approach is used everywhere throughout IETF: including
   IPsec and TLS, not just SNMP. Second - would you care to to
   explain what's so weak about it?

9. You said "authentication keys....'are the keys to the kingdom'". How
   so? Assuming [practically] impossible - you cracked one auth key. Now
   what? How are you going to attack other boxes (this key was localized)?

10.Yes, I fully support Randy who "seems to think that [AES] is adequately
   strong to defeat cryptanalysis done by a security professional". Only
   we call them "cryptographers" and "cryptanalysts". And I'm not at
   liberty to discuss this type of issue with you.

11.Yes, the current approach presumes that SHA-1 is [practically]
   non-invertible. And not only I "spent some time figuring how to
   break those keys", but people whose job is to attack crypto hashes.
   "Great abundance of ciphertext" gives you little, considering the
   algorithms used (how many known plaintext pairs to you need to
   get a few bits of the AES128 key?). But even if you steal one
   key, how are you planning to reverse SHA-1?

12. You say "The fact that the algorithmic relationship between the keys
    can be leveraged to break additional keys, once an original key has
    been broken, may or may not be evident to the readers of this email.
    Certainly, I am offering no proof, other than implying I have an idea
    for how to do so."

    Please, pretty please - share your idea with us!   Even if it's
    rediculous, I want to see it, and promise not to comment on it.

    Oh, and explaining what you mean by the "original key" would
    help. For if you rediscovered America  (i.e. figured out how
    to compute localized keys if the administrator's passphrase
    became known) - it's neither very interesting nor very new.

13. Enough already.


> Automatically initiating key changes after the quantum expires would
> eliminate this objection, but it would need to be well thought out
> to eliminate possible coordination problems.

Management station can do both - keep track of the amount of traffic
protected by a given key, and initiate the key update when it thinks
necessary. Talk to David Spakes. No protocol change is necessary for
that.


> I think that this is an appropriate topic for the SNMPv3 working group
> to address because, if it is not done here, then we would not have a
> consistent and interoperable solution spanning many implementations.

First one has to ascertain that there's a problem to solve.

> I never once used the word "proprietary". I did use the 
> word "classified" once.

AES-USM approach should be adaptable to any classified crypto,
be it block or stream cipher (because it uses CFB mode - close
enough to stream cipher to be "portable"). Just replace AES
with XXX.


> Changing topics, I remain interested in any insights this group may care to
> offer me on approaches to supplement SNMPv3 security by protocols operating
> at a different layer.

It looks like the first insight necessary is to understand why SNMPv3 is
the way it is. Like - why there is no concept of session (hint: designers
have heard of the "session" idea, contrary to what you may think). [And
there were attempts to introduce it in circa 1994.]


> It does not appear that my postings have resonated with this group,
> perhaps because the group would have a tremendous lot of new work
> cut out for it should it admit to the validity of these concerns.

Perhaps because your postings reveal serious lack of understanding
of both cryptographic issues and SNMP protocol specifics. So their
credibility is too low to create resonance.


> I will try to privately respond to anyone who wishes to continue a
> private discussion with me, however.

You can start with substantiating your claims - show the exploits, for
example.