Subject: Rationale for Nonce in Time Stamp Protocol

From: [email-masked]
Date: Fri, 19 May 2000 15:00:21 -0400

Salut Denis,

I do not remember if this issue was raised before, but in Section 2.2 the
following statement is made:

"the requesting entity .... SHALL then verify the timeliness of the response
by verifying either the time included in the response against a local
trusted time reference, if one is available, and/or the value of the nonce
(large random number with a high probability that it is generated by the
client only once) included in the response against the value included in the
request."
 
A nonce is normally used to detect attempts at replays, which is not
necessarily related to the timeliness of the response to a particular
request as mentioned here.
 
The first part of the statement talks about verifying the time included in
the response against a locally trusted time source.  This could used to
measure round trip path delay for calibration purposes, but unless one could
be certain that the locally trusted source is as accurate as the TSA time
source (or, at least, that the difference between them is fixed and
well-known), I don't see how it would detect/prevent replays.  If one has
such a trusted time source locally, what is the point in using a TTP for
time stamping?
 
Could you please clarify the intent of this statement and if the intent is
to prevent replays or check the timeliness of responses or both?

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[email-masked]      Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com     Fax. (613) 723-5078

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 24 May 2000 11:36:20 +0200

Francois,

I realized that I ommited to reply to your E-mail.
 
> measure round trip path delay for calibration purposes, 

No. This is not the goal. The goal is to make sure that you have no
replay, in particular on the same hash value.

> but unless one could
> well-known), I don't see how it would detect/prevent replays. 

Using a moving time window the caller remembers all the hashes he
sent during that time window.
If there is not the same hash value within that time window, then he
makes sure that the time of the response is within the time window.
If there is the same hash (a very rare situation), it is a little
bit more complicated, and there are several options. Among them:
using the nonce, or waiting until the time window has moved to come
back to the previous case: only one hash value during that time
window. But we are talking implementations details, which is not the
topic of an RFC.

>  If one has

The time is locally trusted, ... which does not mean that other
people will trust that time.

> to prevent replays or check the timeliness of responses or both?

Now, that you have the explanations, if you still believe that the
text is not clear enough, I suggest that you submit a proposal to
clarify the text.

Regards,

Denis