Menu
▾
▴
Re: Regarding to timeliness checking
|
From: srikkanth s. <sri...@ya...> - 2005-10-25 05:38:57
|
Hi, Please find answers to the questions below 1.To enable non-authoritative engines to maintain time synchronization, each authoritative engine inserts its current boot and time values, as well as its value of snmpEngineID, in each outgoing Response, Report, or Trap message in the fields msgAuthoritativeEngineBoots, msgAuthoritativeEngineTime, and msgAuthoritativeEngineID. If the message is authentic, and if the message is within the time window, then the receiving non-authoritative engine updates is local variables (snmpEngineBoots, snmpEngineTime, and latestReceived EngineTime) for that remote engine according to the following rules: 1. An update occurs if at least one of the two following conditions is true: - (msgAuthoritativeEngineBoots > snmpEngineBoots) or - [(msgAuthoritativeEngineBoots = snmpEngineBoots) and (msgAuthoritativeEngineTime > latestReceivedEngineTime)] The first condition says that an update should occur if the boot value from the authoritative engine has increased since the last update. The second condition says that if the boot value has not increased, then an update should occur if the incoming engine time is greater than the latest received engine time. The incoming engine time will be less than the latest received engine time if two incoming messages arrive out of order, which can happen, or if a replay attack is underway; in either case, the receiving engine will not perform an update. If an update is called for, then the following changes are made: - set snmpEngineBoots to the value of msgAuthoritativeEngineBoots - set snmpEngineTime to the value of msgAuthoritativeEngineTime - set latestReceivedEngineTime to the value of msgAuthoritativeEngineTime If we turn the logic around, we see that if msgAuthoritativeEngineBoots < snmpEngineBoots, then no update occurs. Such a message is considered not authentic and must be ignored. If msgAuthoritativeEngineBoots = snmpEngineBoots but msgAuthoritativeEngineTime < latestReceivedEngineTime, then again no update occurs. In this case, the message may be authentic, but it may be misordered, in which case an update of snmpEngineTime is not warranted. Note that synchronization is only employed if the authentication service is in use for this message and the message has been determined to be authentic via HMAC. This restriction is essential because the scope of authentication includes msgAuthoritativeEngineID, msgAuthoritativeEngineBoots, and msgAuthoritativeEngineTime, thus assuring that these values are valid. SNMPv3 dictates that a message must be received within a reasonable time window, to avoid delay and replay attacks. The time window should be chosen to be as small as possible given the accuracy of the clocks involved, round-trip communication delays, and the frequency with which clocks are synchronized. If the time window is set too small, authentic messages will be rejected as unauthentic. On the other hand, a large time window increases the vulnerability to malicious delays of messages. We consider the more important case of an authoritative receiver; timeliness testing by a non-authoritative receiver differs slightly. With each incoming message that has been authenticated and whose msgAuthoritativeEngineID is the same as the value of snmpEngineID for this engine, the engine compares the values of msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime from the incoming message with the values of snmpEngineBoots and snmpEngineTime that this engine maintains for itself. The incoming message is considered outside the time window if any one of the following conditions is true: snmpEngineBoots = 231 1 or msgAuthoritativeEngineBoots != snmpEngineBoots or the value of msgAuthoritativeEngineTime differs from that of snmpEngineTime by more than ±150 s The first condition says that if snmpEngineBoots is latched at its maximum value, no incoming message can be considered authentic. The second condition says that a message must have a boot time equal to the local engine's boot time; for example, if the local engine has rebooted and the remote engine has not synchronized with the local engine since the reboot, the messages from that remote engine are considered not authentic. The final condition says that the time on the incoming message must be greater than the local time minus 150 s and less than the local time plus 150 s. If a message is considered to be outside the time window, then the message is considered not authentic, and an error indication (notInTimeWindow) is returned to the calling module. 2.Once the non-auth engine got the snmpEngineboot and snmpEnginetime form the auth-engine by the discovery process, it should maintain the local notion of these values. it should increment the snmpenginetime value once per second so that the time values at local and remote are close to in sync. The values of snmpengineboot and snmpenginetime are placed in msgAuthoratativeEngineboots and msgAuthoratativeEngineTime in the request message and sent across to the agent. 3. snmpEngineID, snmpEngineBoots, and snmpEngineTime of the authoritative engine be placed in the msgSecurityParameters. This requires the non-authoritative engine (i.e. manager) to know these values for the authoritative engine (i.e. agent) before a GET, NEXT, or SET operation can be completed. This is achieved by a discovery process. There are two discovery transactions that occur. The first is to discover the snmpEngineID of the agent. The second is to discover the snmpEngineBoots and snmpEngineTime. The second transaction is only needed if the manager wants to use a security level of authNoPriv or authPriv. This is because the msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime are used by the timeliness module which is part of the authentication process. The first discovery transaction is initiated by the manager sending an SNMPv3 packet with the msgAuthoritativeEngineID containing a bogus value. When the agent receives a packet where the msgAuthoritativeEngineID is different than its own, the packet is discarded and a discovery packet is returned to the manager. The returned discovery packet contains the correct snmpEngineID which must be used by the manager. The second discovery transaction requires an authenticated packet be sent to the agent. This means that the authentication flag is set in the msgFlags, and the msgAuthenticationParameters contains the computed message digest for the packet. The secret key used for authenticating the packet is from the user specified in msgUserName. What makes this a discovery packet is that the msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime contain bogus values. When the agent receives this packet, it is first authenticated. Once the authentication is completed, the msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime values are checked. Since the values are bogus, the packet is discarded and a second discovery packet is returned to the manager. The returned discovery packet is authenticated, using the same user, and contains the correct values of the snmpEngineBoots and snmpEngineTime which must be used by the manager. 4. There is no need for any configuration or settings to make the timeliness checking successful ------------------------------------------------------ Newsgroup net...@li... Subject Regarding to timeliness checking Time Thu 21 Jul 2005 07:35 PM GMT +0800 Sender shufen zhang Hi All, My snmpv3 authNoPrive and authPrive request got error: not in time windows. Can anyone please explain a bit: 1. How timeliness checking is performed internally by the application? 2. How snmpengine Boot and snmpEngineBoot Time are packed in the request message? 3. How does the SNMP acquire the snmpEningeBoot and Time? 4. Do we need to do any configuration or settings to make the timeliness checking successful? Thanks very much! SF ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Net-snmp-users mailing list E-mail Protected Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users Related Messages A question about configure Jordi Martin Tirado (1k) Regarding to timeliness checking shufen zhang (1k) Re: A question about configure Robert Story (1k) openSubscriber is not affiliated with the authors of this message nor responsible for its content. Search for messages... net...@li... entire site © 2005 openSubscriber.com All rights reserved. __________________________________________________________ Yahoo! India Matrimony: Find your partner now. Go to http://yahoo.shaadi.com |
