Subject: [Isms] Where I find answers about USM?

From: Ziv Artzi <[email-masked]>
Date: Mon, 6 Nov 2006 01:05:33 -0800 (PST)

Hello,
   
  this is my first msg here :)
   
  I have recently started investigating SNMP, and SNMP security particulary.
  I read the RFC 3414 (USM) and I have questions about it. The problem is that there is no longer an active working group for that.
   
  I will be glad if you will tell me who can help, or just answer the next q's:
   
  1. What is the need for two counters of time latestReceivedEngineTime and snmpEngineTime that are saved against all source engine. The paragraph 2.3 says that it is against a threat of DoS by Replay attack but does not ellaborate. I think there is no such threat.
  2. The process of Discovery (chapter 4) seems not to be supported by chapter 3. examples: how the discover gets the key that will be used by him in order to secure the 2nd message of his? where in 3.2 there is handling of incoming messages with zero values like the discovery (2nd message also)
   
  Thanks,
  Ziv

---------------------------------
Want to start your own business? Learn how on  Yahoo! Small Business. 

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Sun, 12 Nov 2006 11:40:06 -0500

> However, I still don't understand the threat of preventing
> the snmpEngineTime from advancing. I will explain it in 2 ways:
>
> 1. Replaying authentic message cannot cause the snmpEngineTime
> to move downward..............

But relpaying can cause the notion of snmpEngineTime to "freeze",
effectively moving it backwards against the real clock.

> 2. snmpEngineTime and latestReceivedEngineTime seem to be
> updated together to the same value (from the SNMP header)
> so when are they different?

Not together (one only if the check with the other passed OK) and not to
the same value.

snmpEngineTime is a computed (dynamic) value. A smart engine stores and
adjusts the clock difference. Comparing only with snmpEngineTime is
insufficient.

We have made our decisions 10 years ago based on long and scrupulous
analysis. Since this protocol is a done deal by now - perhaps it's best
to leave the "whys" of it as a home exercise (a recommendation: start
with an approach "if they put it in - they must have had a reason, let
me figure out what it is").