Subject: A slight flaw in the order of operations in USM

From: Michael Kirkham <[email-masked]>
Date: Sat, 22 Mar 2003 05:07:04 -0800 (PST)

Well, "slight flaw" may be too strong of a wording, but it's a tiny thorn
that would be simple enough to fix in the future, with little negative
consequence:

I would suggest that step 3.2(7) (timeliness checking) of RFC 3414 ought
to come after step 3.2(8) (decryption) -- at least the part where the
out-of-time-window error is returned to the calling module.  The reason
being that RFC 3412 requires the PDU type, if it can be determined, to
override the settings of the 'reportable' flag.  If an implementation
follows this order to the letter, and receives an authPriv request from
another implementation that erroneously neglects to set the reportable
flag, then time synchronization will fail, where it would otherwise
succeed had the PDU simply been decrypted first, because the PDU type will
be unknown.

The only negative consequence that I can think of for decrypting prior to
timeliness checking is some additional CPU load/processing time for
out-of-time-window messages, which would probably only matter in the case
of a DOS attack via replay flood.

Alternately, the notInTimeWindows report should always be sent, regardless
of the state of the reportable flag, if the message indicates that the
processing engine is authoritative by way of the msgAuthoritativeEngineID
parameter.

Like I said, it's only a slight flaw -- only one that would affect a
non-authoritative engine with a bug in its flag settings -- but I thought
it worth noting, if only because it might cause a new implementor to
scratch their head for a while if they find that time synchronization
works with authNoPriv but not with authPriv.

--
Michael Kirkham
www.muonics.com

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 24 Mar 2003 23:35:25 +0100

Good point Dave. We did indeed discuss this quite
extensively a few years back. It is coming back 
into my mind.

Thanks,
Bert 

> -----Original Message-----
> From: Harrington, David [mailto:[email-masked]]
> Sent: maandag 24 maart 2003 19:27
> To: Michael Kirkham; [email-masked]
> Subject: RE: A slight flaw in the order of operations in USM
> 
> 
> Hi Mike,
> 
> I am in a meeting, so don't have access to the documents right now ;-)
> 
> I think your approach is not consistent with the high-level 
> design goals
> of snmpv3. The reason we have the flags in the header is so the PDU
> format can be independent of header processing, i.e. 
> different PDU types
> could be used and the header processing doesn't need to know 
> the details
> of the PDU format. 
> 
> Your approach requires the header processing sections to look into the
> PDU and interpret the contents/format to determine the 
> operations type.
> That means the header processing must know just which type of PDU is
> encapsulated in the message, and that is not desirable for snmpv3.
> 
> dbh
> 
> > -----Original Message-----
> > From: Michael Kirkham [mailto:[email-masked]] 
> > Sent: Saturday, March 22, 2003 6:07 AM
> > To: [email-masked]
> > Subject: A slight flaw in the order of operations in USM
> > 
> > 
> >