Subject: Re: Rationale for Nonce in Time Stamp Protocol

From: Peter Sylvester <[email-masked]>
Date: Tue, 30 May 2000 16:58:32 +0200 (MET DST)

> 
> François,
> 
> Sorry for the delay to answer, but the trafic is currently rather
> heavy on the TSP document and it takes time to prepare answers.
> 
> I do not agree to make the nonce mandatory since there exists cases
> where it is not needed. I also do not think that the case of a
> subverted TSA falls under the topic of "deliberate replay". 
I would even say that I rarely see a case where a client would
really need to use a nonce to avoid whatever kind of replay.

A replay of a response WITH THE SAME HASH is most likely a good
thing for the client. 

What is actually missing is an output nonce from the TSA in order
to avoid known plain text attacks in case when the results are
otherwise predictable. I would suggest to change the text
about the nonce in the following way: 

  The Nonce in the response MUST contain a possible Nonce of the
  request as a prefix. By this, the TSA can add an ouput Nonce
  in order to avoid known-plain text attacks, as well as it gives
  the possibility to front-end proxies to append data to the
  request Nonce when concentrating requests from many requesters
  in such a way that duplicates and replays can be avoided.  
  
> 
> However, in order to address your concern, I could add the following
> text in the security consideration section :
> 
> Inadvertent or deliberate replays for requests incorporating the
> same hash (algorithm and) value may happen. Inadvertent replays
> occur when more than one copy of the same request message gets sent
> to the TSA because of problems in the intervening network elements.
So, where is the problem? 

> Deliberate replays occur when a middleman is replaying legitimate TS
> responses. In order to detect these situations, several techniques
> may be used. Using a nonce always allows to detect replays, and
> hence its use is RECOMMENDED. Another possibility is to use both a
Why recommended? I would like to get a replay to have a proof of
an earlier time.

> local clock and a moving time window during which the requester
> remembers all the hashes sent during that time window. When
> receiving a response, the requester makes sure that both the time of
> the response is within the time window and that there is only once
> the hash value in that time window. If there is the same hash value
> more than once, the requester may either use a nonce, or wait until
> the time window has moved to come back to the previous case where
> the same hash value appears only once during that time window.

If there is the same hash value twice, the requester can just the
previous time stamp, why should one go to the TSA in this case?

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 31 May 2000 14:12:41 +0200 (MET DST)

All,

You can safely forget my comments about the 'chosen plain text'
attack from yesterday. I forgot that the message signing
used in the time stamp always includes signed attributes. 

On the other hand I think one could still weaken the
requierement that the Nonce of the time stamp must be identical
to the one in the request and only require that it must
be a prefix/suffix of it.

Needless to say, that I am not sure whether a Nonce is ever
need anyway, but that's another story. 

Sorry for the irritation that my comment might not have caused.
peter