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

From: "Harrington, David" <[email-masked]>
Date: Mon, 24 Mar 2003 13:26:55 -0500

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
> 
> 
> 
> 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: Michael Kirkham <[email-masked]>
Date: Mon, 24 Mar 2003 16:00:55 -0800 (PST)

> encapsulated in the message, and that is not desirable for snmpv3.

Yes, this is true (well, my approach "suggests" looking into the PDU to
interpret...), although it's true anyway, with or without the approach.
The MPD document requires that the PDU type, if it is known/has been
determined, overrides the state of the 'reportable' flag.  ie.:

   The reportableFlag is a secondary aid in determining whether a Report
   PDU MUST be sent.  It is only used in cases where the PDU portion of
   a message cannot be decoded, due to, for example, an incorrect
   encryption key.  If the PDU can be decoded, the PDU type forms the
   basis for decisions on sending Report PDUs. [RFC 3412, $6.4]

So basically what I'm saying is, since the PDU portion of the message can
in fact be decoded if you just decrypt it before timeliness checking, then
you may as well go ahead and do so, even though you are not required to do
so by the literal order of operations.

--
Michael Kirkham
www.muonics.com