RE: USM time windows check question

At 1/5/2003:06:29 PM, Wijnen, Bert (Bert) wrote:

Hi Bert,

Ok, thanks again for taking the time to consider and advise.
While I don't agree that RFC3414 is at all consistent in its
guidance re the purpose of Time Window and still don't believe
that the specific directions in 3.2.7b are the most beneficial
approach, I agree that it's time for me to fold the cards on
this one and accept the situation as it s.

In fairness to both the spec authors/editors and myself :-),
it took a very badly behaving CR to expose the kind of problem
that, in my opinion, suggests a flaw.  This is not a situation
that many CGs are going to encounter in the real world!

The guidance you give in your last paragraph below re how the
CG might be able to work around the problem is, in fact, very
close to how the CG app owner is addressing it in this case.

Cheers,

BobN
- - - - -
>Rather than trying to go down the exact text and what it means
>or how it could be interpreted, I would like to focus on the
>possible issue/concerns. So, in summary:
>
>- I think that in your example, the response is actually within
>  the time window (at least from your description, I assume that
>  the response in realtime actually comes back within a second
>  or so). The problem is caused by the fact that the CR lags far
>  behind and did not properly reject the request with a 
>  not-in-time window error.
>  So from a security point of view, your example is OK and does 
>  not cause harm. Theoretically.. maybe it does, but in practice
>  it does not.
>- Now it could have been, that you had send this message at 
>  t1+75, and that the CR was not lagging, but that the response
>  would have been suppresed by an intruder, and that now the
>  response was replayed at t1+300. So now the response would
>  really be out-of-time-window and would indeed be replayed
>  more than 150 seconds after it was generated.
>  So we are not catching it from a timeliness point of view.
>  However, the response is still authenticated, and so still
>  is kind of valid. 
>  The provision now is that you need to check the msgID (as 
>  stated in RFC 3414 too), and supposedly your application would
>  not have been waiting 200 seconds (or in fact the assumtion
>  is not more than 150 seconds... but maybe this is not clearly
>  stated) for the response and canceled the request, and so the
>  response would still be rejected.
>  So again, I think the security risk is very very low (if any).
>- If the intruder had not suppresed the response, but instead 
>  just captured it and was now resending it, then of course
>  the response was already processed by the CG and so the
>  message would also be out-of-time-window since B <= C.
>
>So the question that remains (I think) is, if at the APP level
>(e.g. above the SNMP engine code) one needs to know about the
>timeliness of messages (in this case of a buggy CR), and if so,
>if the timeliness values in the messages were intended for that.
>
>A solution in your situation would be to send a simple (but
>authenticated) SNMP GET request (say for snmpEngineTime.0)
>every 140 seconds or so, just to ensure you stay in sync
>with the authoritative engine.
>
>Thanks,
>Bert 
>
>> -----Original Message-----
>> From: Bob Natale [mailto:[email protected]]
>> Sent: zondag 5 januari 2003 21:01
>> To: Wijnen, Bert (Bert)
>> Cc: [email protected]
>> Subject: RE: USM time windows check question
>> 
>> 
>> At 1/5/2003:08:13 AM, Wijnen, Bert (Bert) wrote:
>> 
>> Hi Bert,
>> 
>> >OK, here is my assessment.
>> 
>> Thanks for the analysis, especially out of yuor weekend time!
>> ...responses inline:
>> 
>> >- Strange CG system.
>> 
>> Just to avoid any confusion here, it's the *CR system* that's
>> behaving strangely (seems like just a typo from the rest of your
>> response).  Yes, it's very strange...indeed, the full set of
>> circumstances is even *much* stranger (but not important here)!
>> 
>> > In the first 30 secs it lags 5 seconds
>> >  In the next 300 secs it lags 200 secs (I would have expected 50)
>> >  But... it does not matter to the problem at hand. I just noticed.
>> 
>> Correct...the point is that such an exchange sequence can (and
>> does!) occur in reality.
>> 
>> >- I think the behaviour that results from following the steps as
>> >  outlined in 3414 is correct and if you reverse the sequence,
>> >  then you get incorrect behaviour. It allows the CG SNMP engine
>> >  to come back in sync with the (lagging) CR without having to
>> >  go through an elaborate resync process. Remember that the msg
>> >  was authenticated, so no matter what you do, the message does
>> >  contain the correct CR engineTime, and a resync will not change
>> >  that.
>> 
>> I understand that.  But I must admit that the overall text of
>> 3414 wrt the purpose of the Time Window would imply that the CG
>> should remain in sync with the CR as long as the CR's timeliness
>> values do not exceed the Time Window.  That use of Time Window
>> has some beneficial aspects for applications that incorporate
>> CG functionality (within a larger body of app functionality).
>> More on that below.  For now, let me take a quick look at the
>> specs again...
>> 
>> ...ok, here's a quote from Sec 1.3:
>> 
>> "- Message timeliness and limited replay protection is the provision
>>    of the property that a message whose generation time is outside of
>>    a specified time window is not accepted."
>> 
>> Remembering that the USM Time-Window value is +/- 150 seconds,
>> that text does not distinguish between messages generated by
>> CGs vs CRs.
>> 
>> ...or, how about this from Sec 1.5.2.3) -- which happens to be
>> titled "Detection of messages which were not recently generated":
>> 
>> " On receipt, the values are checked to ensure that the indicated
>>   timeliness value is within a Time Window of the current time.  The
>>   Time Window represents an administrative upper bound on acceptable
>>   delivery delay for protocol messages."
>> 
>> ...and, finally, from Sec 2.2.3, "Time Window":
>> 
>> " The Time Window is a value that specifies the window of 
>> time in which
>>   a message generated on behalf of any user is valid."
>> 
>> Granted, Sec 2.3, "Time Synchronization" does say:
>> 
>> "These values must be (and remain) within the authoritative 
>> SNMP engine's
>>  Time Window."
>> 
>> But I don't think that a reasonable interpretation of that is at all
>> as clear-cut as one might hope in light of the much larger body of
>> preceding text from the spec about the purpose of Time Window.
>> 
>> >I think that the CR should have responded with a Not-In-Time-Window
>> >error. This is according to sect 3.2.7(a), 3rd bullet. The 
>> >received new request is >+150 seconds according to its local
>> >(authoritative) notion of the egineTime.
>> 
>> Yes, that is what we would like to see happen...but we have
>> to accept the situation as it is in this case (for now).  I am
>> trying to explore whether the spec handles this kind of case
>> in a sensible way.
>> 
>> >So that should have caused the CG SNMP engine to re-sync with the 
>> >CR SNMP Engine. 
>> 
>> Yes...again, that would have been good...but this CR does not
>> respond in that way.
>> 
>> >We can now wonder if the CG SNMP Engine should still accept this 
>> >response (that should never have been send by a compliant CR).
>> 
>> Right...that is the issue.  I think the bulk of the guidance
>> about the purpose of Time Window in 3414 suggests that the
>> from the CR should fail the Time Window test at the CG.
>> 
>> >Some considerations:
>> >- is it realistic to assume that the CR lags so badly in time so
>> >  as to lag 2 seconds every 3 seconds of real time?
>> 
>> We've actually seen worse in this debug scenario (in the case
>> where someone apparently changed system dates/times on one or more
>> machines).
>> 
>> >- the message is authenticated, we have had no other communication
>> >  with the CR and so, the response MUST (by definition) contain
>> >  the authoritate engineTime of the CR.
>> >- If we do reject it because our time runs (correct or faster) then
>> >  we end up rejecting this response, we do the more complicate resync
>> >  hoopla/polka and the end result is that we find out that the
>> >  authortative value is indeed 100. So with that we send another
>> >  request to the agent and now succeed. Sounds like a lot of
>> >  extra work for nothing, no? And that is what you get if you do
>> >  step 3.2.7b.2 first
>> >So I think the behaviour as per 3414 is correct, or at least 
>> acceptable,
>> >cause it does not create a problem at the CG end.
>> 
>> Ok...whether or not it creates a problem on the CG end --
>> considering that the CG app as a whole might be much more
>> than just the SNMP component -- might depend on how important
>> notions of system time are to the overall app.  In some environments
>> that notion is taken very seriously.  Having the Time-Window
>> "violation" (in my current interpretation) at the protocol level
>> kick off something like an app-level "SNMPAPI_RPT_NOTINTIMEWINDOW"
>> indication can be very helpful at the app level.  This is
>> especially true in those kinds of environments and where the
>> app is actually multi-threading exchanges with multiple CRs
>> that it would like to see as a secure distributed system.
>> 
>> [As an aside, while I totally support the idea of making the
>> protocol as efficient as possible and using it as efficiently
>> as possible in apps, consistent with other requirements, I must
>> say that the empirical data we have after several years of
>> SNMPv3 deployment shows the engine discovery and time sync are
>> not particularly burdensome operations.  Yes, some app designs
>> can abuse them, but those apps have been fairly rare and have
>> usually been caught early enough to be corrected without undue
>> costs.]
>> 
>> >Now let us first change your scenario, such that the CR would not
>> >cause a not-in-time-window response. 
>> >- Let us define t2 as t1+150 seconds
>> >- Let us assume that the CR has lagged 
>> >  have passed
>> >- That is, I believe that the response in
>> 
>> Sorry...I think maybe some of your text got dropped there...?
>> If the CR does not generate the anomalous condition, then I have
>> no problem with the specs.
>> 
>> >Now, w.r.t. to your claim that a message would never be considered
>> >out-of-time window. In fact it will, but that would happen if
>> >some old response comes back. Let us say at t3 (+600 seconds), 
>> >you have another good CG-CR interaction and the B' and C values
>> >get set to 200. Now let us assume that after that response t1 comes
>> >back once more. Then B<C and so it skips step 3.7.2b.1 and runs
>> >into the not-in-time-window. (see also 2nd para on page 30).
>> 
>> Yes, I understand that case.  The issue that if the CR's clock
>> advances at all then, regardless of how badly it lags, the CG
>> will never report a Time Window violation.  I don't think that's
>> the most sensible behavior and, more importantly, I don't think
>> it's consistent with the overall guidance about the purpose of
>> Time Window in 3414.  From the app owner's perspective, I'd
>> rather have the protocol report the (apparent) Time Window
>> violation and pay the cost of the re-sync operation.
>> 
>> >Hope this helps... 
>> 
>> Yes, very much...and much appreciated...but I don't really
>> feel like I've achieved closure on this.
>> 
>> Is it the general consensus that Time Window does not apply
>> when the CR's reported engineTime exceeds the Time Window
>> (by however large an amount) as long as its value advances
>> (by however small an amount)?
>> 
>> Since that is what 3.2.7b equates to, let me also ask if
>> it's the general consensus that that behavior is consistent
>> with the overall guidance re Time Window in 3414?
>> 
>> If so, then at the very least, I suggest that any future
>> revision of 3414 should make that clear in Sec 1.3, 1.5.2.3),
>> and 2.2.3 (and perhaps elsewhere).
>> 
>> Thanks,
>> 
>> BobN
>> 
>> >> -----Original Message-----
>> >> From: Bob Natale [mailto:[email protected]]
>> >> Sent: zaterdag 4 januari 2003 22:29
>> >> To: Wijnen, Bert (Bert)
>> >> Cc: [email protected]
>> >> Subject: RE: USM time windows check question
>> >> 
>> >> 
>> >> At 1/4/2003:07:30 AM, Wijnen, Bert (Bert) wrote:
>> >> 
>> >> Hi Bert,
>> >> 
>> >> Please refer to the data at:
>> >> 
>> >>    http://www.winsnmp.com/TimeWindow-Debug.htm
>> >> 
>> >> Ok...I hope I'm not wasting people's time with this...
>> >> and I *really* hope it's not some stupid oversight on my
>> >> part :-(...but we have been debugging a customer problem
>> >> report for a scenario in which our WinSNMP SNMPv3 stuff
>> >> powers a command generator (CG) app interacting with
>> >> a v3 command responder (CR) app from another source
>> >> and this particular CR has some (known) problems with
>> >> its implementation of engineTime and appears to run on
>> >> a system whose clock runs slower than the system which 
>> >> hosts the CG app.  Due to customer circumstances, we
>> >> have to accept these attributes of the problem space
>> >> for now.  The known problems with the CR's implementation
>> >> of engineTime are blatant but are thought to be not
>> >> immediately material to the problem scenario discussed
>> >> herein (but might affect other aspects of the problem).
>> >> 
>> >> The customer/problem thing is, of course, a matter for
>> >> the parties involved and not the IETF community.  However,
>> >> this particular problem scenario caused us to review more
>> >> closely our relatively very tight implementation of RFC3414
>> >> and that review has revealed a *possible* problem with the
>> >> spec.  (Also, in doing related research we found secondary
>> >> sources and other implementation code that specifically
>> >> avoided the "tight" implementation approach wrt RFC3414 3.2.7b).)
>> >> 
>> >> So, please look at the data in the (html) spreadsheet URL'd
>> >> above.  I've tried to keep the details as simple as possible.
>> >> Think of the three "Events" (columns t0, t1, and t2) as as
>> >> three separate CG Request messages happening at times t0 = 0,
>> >> t1 = t0 + 30 seconds, and t2 = t1 + 300 seconds.  Event t0
>> >> includes Report-based engine discovery and initial time sync
>> >> with the CR.
>> >> 
>> >> Ok...remembering that the CR in this case runs consistently
>> >> slower than the CG...it appears that the protocol attribute
>> >> values at t2 lead to the CR's response being accepted as
>> >> valid (within Time-Window) if 3.2.7b.1} is executed before
>> >> 3.2.7b.2), whereas the response is considered outside the
>> >> Time-Window if 3.2.7b.2) is executed first.  The latter
>> >> result looks like the "right" one in this case...?  The
>> >> items in red and green font color in column t2 are highlighted
>> >> as the suspect problems.
>> >> 
>> >> It is also clear from this spreadsheet that the tests in
>> >> rows 16 and 17 (from 7b.2) can never fail if the sets in
>> >> rows 10 and 11 (from 7b.1) are executed first, leaving
>> >> only the case where the local notion of snmpEngineBoots
>> >> now equals the latch value where Not-In-Time-Window will
>> >> be asserted (in this problem scenario...in which the CR's
>> >> clock advances but at a rate consistently behind the CG's
>> >> clock).
>> >> 
>> >> For ease of reference, I am including the text of RFC3414
>> >> 3.2.7b after my .sig below.
>> >> 
>> >> Perhaps I have mis-interpreted the text?
>> >> 
>> >> Perhaps I have erred in translating the text to the
>> >> operations/values in rows 6 thru 18 of the spreadsheet...?
>> >> 
>> >> Perhaps I have overlooked some other part of the spec that
>> >> would nullify the conditions set out for one or both of
>> >> columns t1 or t2?
>> >> 
>> >> Perhaps I am mis-interpreting my own data?
>> >> 
>> >> I feel like it's a lot to ask, but I would appreciate
>> >> anyone's assessment re the above.  And despite what I
>> >> said at the outset, I really do hope that I end up with
>> >> egg on my face here!
>> >> 
>> >> Cheers,
>> >> 
>> >> BobN
>> >> ----- From RFC3414 -----
>> >>    7)  If the securityLevel indicates an authenticated 
>> >> message, then the
>> >>        local values of snmpEngineBoots, snmpEngineTime and
>> >>        latestReceivedEngineTime corresponding to the value of the
>> >>        msgAuthoritativeEngineID field are extracted from the Local
>> >>        Configuration Datastore.
>> >> 
>> >>        a) If the extracted value of msgAuthoritativeEngineID 
>> >> is the same
>> >>           as the value of snmpEngineID of the processing 
>> SNMP engine
>> >>           (meaning this is the authoritative SNMP engine), 
>> then if any
>> >>           of the following conditions is true, then the message is
>> >>           considered to be outside of the Time Window:
>> >> 
>> >>           - the local value of snmpEngineBoots is 2147483647;
>> >> 
>> >>           - the value of the msgAuthoritativeEngineBoots 
>> field differs
>> >>             from the local value of snmpEngineBoots; or,
>> >> 
>> >>           - the value of the msgAuthoritativeEngineTime 
>> field differs
>> >>             from the local notion of snmpEngineTime by more 
>> >> than +/- 150
>> >>             seconds.
>> >> 
>> >>           If the message is considered to be outside of the 
>> >> Time Window
>> >>           then the usmStatsNotInTimeWindows counter is 
>> incremented and
>> >>           an error indication (notInTimeWindow) together 
>> with the OID,
>> >>           the value of the incremented counter, and an 
>> indication that
>> >>           the error must be reported with a securityLevel of 
>> >> authNoPriv,
>> >>           is returned to the calling module
>> >> 
>> >>        b) If the extracted value of msgAuthoritativeEngineID 
>> >> is not the
>> >>           same as the value snmpEngineID of the processing 
>> SNMP engine
>> >>           (meaning this is not the authoritative SNMP 
>> engine), then:
>> >> 
>> >>           1) if at least one of the following conditions is true:
>> >> 
>> >>              - the extracted value of the 
>> msgAuthoritativeEngineBoots
>> >>                field is greater than the local notion of 
>> the value of
>> >>                snmpEngineBoots; or,
>> >> 
>> >>              - the extracted value of the 
>> msgAuthoritativeEngineBoots
>> >>                field is equal to the local notion of the value of
>> >>                snmpEngineBoots, and the extracted value of
>> >>                msgAuthoritativeEngineTime field is greater than the
>> >>                value of latestReceivedEngineTime,
>> >> 
>> >>              then the LCD entry corresponding to the 
>> >> extracted value of
>> >>              the msgAuthoritativeEngineID field is updated, 
>> >> by setting:
>> >> 
>> >>              - the local notion of the value of 
>> snmpEngineBoots to the
>> >>                value of the msgAuthoritativeEngineBoots field,
>> >> 
>> >>              - the local notion of the value of 
>> snmpEngineTime to the
>> >>                value of the msgAuthoritativeEngineTime field, and
>> >> 
>> >>              - the latestReceivedEngineTime to the value of 
>> >> the value of
>> >>                the msgAuthoritativeEngineTime field.
>> >> 
>> >>           2) if any of the following conditions is true, then the
>> >>              message is considered to be outside of the 
>> Time Window:
>> >> 
>> >>              - the local notion of the value of snmpEngineBoots is
>> >>                2147483647;
>> >> 
>> >>              - the value of the 
>> msgAuthoritativeEngineBoots field is
>> >>                less than the local notion of the value of
>> >>                snmpEngineBoots; or,
>> >> 
>> >>              - the value of the 
>> msgAuthoritativeEngineBoots field is
>> >>                equal to the local notion of the value of 
>> >> snmpEngineBoots
>> >>                and the value of the 
>> >> msgAuthoritativeEngineTime field is
>> >>                more than 150 seconds less than the local 
>> notion of the
>> >>                value of snmpEngineTime.
>> >> 
>> >>              If the message is considered to be outside of the Time
>> >>              Window then an error indication (notInTimeWindow) is
>> >>              returned to the calling module.
>> >> 
>> >>              Note that this means that a too old (possibly 
>> replayed)
>> >>              message has been detected and is deemed unauthentic.
>> >> 
>> >>              Note that this procedure allows for the value of
>> >>              msgAuthoritativeEngineBoots in the message to 
>> be greater
>> >>              than the local notion of the value of 
>> snmpEngineBoots to
>> >>              allow for received messages to be accepted as 
>> authentic
>> >>              when received from an authoritative SNMP 
>> engine that has
>> >>              re-booted since the receiving SNMP engine last
>> >>              (re-)synchronized.
>> >> ----- End of excerpt from RFC3414 -----
>> >> >Inline
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Bob Natale [mailto:[email protected]]
>> >> >> Sent: zaterdag 4 januari 2003 9:38
>> >> >> 
>> >> >> Hi,
>> >> >> 
>> >> >> In considering RFC3414 Sec 3.2.7b, I am curious
>> >> >> as to whether the ordering of the sub-sections
>> >> >> 1) and 2) has any significance...?  That is,
>> >> >> is that ordering supposed to indicate that the
>> >> >> tests and actions in 1) should be performed
>> >> >> first and then the tests and actions in 2) should
>> >> >> be performed...?
>> >> >> 
>> >> >I think so, as I think all the steps are to be executed 
>> >> >in the sequence as documented. It is maybe possible that 
>> >> >other sequences are valid too... but we have all been 
>> >> >evaluating this sequence and we have done interoeprability
>> >> >testing using this sequence.
>> >> >
>> >> >> Common-sense would suggest that the ordering
>> >> >> means something (generally we do step 1 before
>> >> >> step 2), but there are some reasons for thinking
>> >> >> that might not apply here.  :-)
>> >> >
>> >> >I'd like to understand the reasons why you think it may 
>> >> >not apply in this case.
>> >> >
>> >> >> First, there is no "then" or "else" prefixed to
>> >> >> 2)...suggesting that the two sets of tests and
>> >> >> actions are performed independently.
>> >> >
>> >> >Well, none (or very few) of our numbered sequenced 
>> >> >statemens start with "then"... so why would we do it
>> >> >in this case?
>> >> >
>> >> >> Second, as it
>> >> >> turns out, however, the two sets of "if" conditions
>> >> >> are not mutually exclusive and for certain values
>> >> >> of the subject variables, performing 1) before 2)
>> >> >> can lead to invalid, but unavoidable, results.
>> >> >> (It's late here now, so I'm going to skip laying
>> >> >> out a detailed example...but if anyone thinks it's
>> >> >> necessary, I'll add it in a follow-up.)
>> >> >> 
>> >> >Pls post an example where you think we come to 
>> >> >invalid results. I am not saying this is not true, 
>> >> >but I believe we have gone through this a number of 
>> >> >times in the past, and I think we came to the 
>> >> >conclusion that this is what needs to be done.
>> >> >We still may have overlooked a specific case, so
>> >> >I'd love to hear it.
>> >> >
>> >> >> The bottom line is that I think the tests and
>> >> >> actions described in 2) need to be performed
>> >> >> before those in 1) and that this ordering and
>> >> >> the specific dependency need to be spelled out
>> >> >> in any future revision of the spec.  That is,
>> >> >> the time window check should be done before
>> >> >> checks that might lead to updating the local
>> >> >> record of the authEngine's timeliness variables.
>> >> >> Doing them in reverse order (i.e., as currently
>> >> >> ordered in the spec) can lead to situations in
>> >> >> which otherwise out of time window messages
>> >> >> morph into valid messages or, at the very least,
>> >> >> inappropriately lead to "updates" of the local
>> >> >> record of the authEngine's timeliness variables.
>> >> >> 
>> >> >Pls do realize, that at this point (3.2.7b) we are
>> >> >dealing with an authenticated message. So this MUST 
>> >> >be the real value that the AUTHORITATIVE engine
>> >> >tells us about, no? So what is wrong with using that
>> >> >value to update our local notion at the 
>> >> >non-AUTHORITATIVE side of the communication?
>> >> >
>> >> >Bert
>> >> >> I will appreciate any and all feedback on this
>> >> >> topic.
>> >> >> 
>> >> >> Cheers,
>> >> >> 
>> >> >> BobN
>> >> 
>>