Re: Question about Time Window in USM

Hi -

> From: <[email protected]>
> To: <[email protected]>
> Sent: Wednesday, June 25, 2003 7:13 AM
> Subject: Question about Time Window in USM
>

> Hello,
>
> If I understand RFC3414 well, the Time Window for USM is a fix value and
> equal to 150s. My questions are the following :
> -Is there a possibility to change this value (besides an
> implementation-dependent way) remotely (of course with authentication) ? I
> didn't find a MIB Object in the SNMP-USER-BASED-SM-MIB module who reflects
> this Time Window object.

There is no way to change it defined in the standard.  Changing it would
potentially adversely affect interoperability.  (Admittedly, the value is
too small to permit interplanetary SNMPv3.)

> -Why RFC3414 proposes a value of 150s for this object ? In 150s a

See the WG archives.  Short version: the interoperability problems that
could arise as a consequence of making it configurable would be far
greater than any benefit doing so might have.  The synchronization
algorithm is one of the things that underwent significant evolution since
the early days.  See RFC 1446 for one early approach that was rather
more complex than what we have now.

> read-request (for certain variables who are sensitive) can easily be
> replayed by another non-authoritative SNMP engine. He doesn't need to change
> anything in the SNMP message just change the source UDP address to get the
> answer from the authoritative SNMP engine send back to him and so get the
> value of variables normally only visible to authorized persons. (He doesn't
> need to know the authorization key to see if the response is authentic
> because he doesn't care). Or did I miss something ?

If one is worried about evesdropping (this "replay attack" does not
expose anything that wouldn't be exposed to an evesdropper), then
the security level should be AuthPriv, rather than merely Auth.

> Thanks for your feedback,
>
> Koen Kennes.
>
> P.S. : If some questions look silly, I apologize because I'm a snmpv3
> novice.

The questions are reasonable, but the following notice is not, and is in my
opinion quite inappropriate for an IETF mailing list, since it appears to
violate both the letter and spirit of RFC 2026 section 10.  See also
http://www.ietf.org/maillist.html

> "The information contained in this e-mail and any attachment thereto is confidential and
> may contain information which is protected by intellectual property rights.
> This information is intended for the exclusive use of the recipient(s) named above.
> This e-mail does not constitute any binding relationship or offer toward any of the addressees.
> If you are not one of the addressees , one of their employees or a proxy holder entitled
> to hand over this message to the addressee(s), any use of the information contained
> herein (e.g. reproduction, divulgation, communication or distribution,...) is prohibited.
> If you have received this message in error, please notify the sender and destroy it immediately after.
> The integrity and security of this message cannot be guaranteed and it may be subject to
> data corruption, interception and unauthorized amendment, for which we accept no liability."
>

Randy