RE: Time Stamping: comments on nonce field

["Juan G. de la Vega" <jgonzalez@xxxxxxx>]

Hi again,

-----Mensaje original-----
De: Robert Zuccherato <robert.zuccherato@entrust.com>
Para: ietf-pkix@imc.org <ietf-pkix@imc.org>; 'Juan G. de la Vega'
<jgonzalez@fnmt.es>
Fecha: miércoles 7 de abril de 1999 19:06
Asunto: RE: Time Stamping: comments on nonce field

>Actually, the reason that the nonce is there and mandatory is to prevent
>replay attacks.  Someone else could have obtained a time stamp on the data
>before your request.  Thus, it is possible that the time stamp you received
>is not "fresh".  Without a nonce, determining the freshness of the
timestamp
>is difficult.
Now, I have get it right.

Freshness of a time stamp is a delicate issue. Theoretically, replay can be
avoided by adding some information provided by the requester to the request,
this added info must be processed by the server and the result returned in
the response in a way that authenticates that server "at that moment" (with
regard to the matching request).

    In our case the "server process" roughly consists of adding the actual
time and signing the bunch, and the added information provided by the
requester can be the hash value (one-way, collision resistant and 2^128
possibilities being a very large range). As I said in the prev. message,
only when there is no hash value the nonce becomes neccessary to defeat
replay.

In relation to this, the scenario you depict seems odd to me; if someone
else had my data before I want to time-stamp it, I already have a bigger
problem, if the data are public and I still want to time-stamp it, a replay
attack would mean that someone would provide me with a signed token that
backdates (in regard to me) the data I possess (umm!, interesting in some
cases... just kidding: I agree with you that an additional mechanism would
fit in this case).

If you mean that a previous message of mine could have been intercepted in
transit and someone else has my hash value (not my data), we have a branch
here:

    1) Passive eavesdropping: I have the token returned from the TSA. The
reason for me to restamp my data is token renewal, but in this case the
messageImprints field will be different from the old request since the token
should be tied to the document and hashed together in order to transitively
extend the validity of the time stamp from the past to the present.

    2)Interception: If I later try to stamp the data and replay-attacked I
will get the original time when I first wanted to time stamp it. I woudn´t
attack that way but simply would intercept all messages (An additional
replay mechanism?).

What I am trying to say is that freshness of a time stamp is not
neccessarily related to the possibility of replay, i.e. we find the problem
of "hostage messages" (someone intercepts your message, keeps it, and time
stamps it at a much later time) that not even the nonce solves. Can we
afford an intentionally produced delay in time stamping?.
 Sadly, the best way to determine the "freshness" of a time stamp is
comparing its time to the local time and check if the interval
request-response fits your local policy (the bad news are that you can do
nothing "a posteriori").

regards,

Juan.