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