Subject: RE: Rationale for Nonce in Time Stamp Protocol

From: [email-masked]
Date: Fri, 26 May 2000 13:26:34 -0400

Denis,

We probably need to be clear on the requirement and then we can be sure that
the text in the document reflects the requirement.

You seem quite clear that the requirement is to prevent replays - but we
need to be clear on whether we are trying to detect and/or prevent
deliberate or inadvertent replay or both.  Inadvertent replay could occur
when more than one copy of a request message gets sent to the TSA because of
problems in the intervening network elements.  In this case the TSA because
of its "no look" policy would just blindly generate time stamps for each of
the copies it receives.  Deliberate replay, on the other hand, assumes that
the TSA has been subverted or its signing key has been compromised, or that
a middleman is replaying legitimate TS responses.  Each of the various
potential replays needs to be considered to ensure that the protocol
protects against it.

1. Deliberate middleman replay.  Since each response contains a signed TS
Token which includes the message imprint, serial number and time, this type
of attack is easily detected within the currently proposed protocol.

2. Replay by subverted TSA.  A subverted TSA could generate any number of TS
Tokens containing the same message imprint at any time.  Because each could
have different serial number and/or time, each would be unique and there is
no way the client could detect a replay on the basis of the response.  The
only way this could be detected would be for every request to include a
nonce and for the client to maintain a record of all nonces generated to
verify against the responses.

3. Inadvertent replay.  Again, the only way for the client to distinguish
this type of replay would be through the use of a nonce. In this case,
however, it should not be necessary to maintain a record of all nonces
generated but only those generated within a time window as you suggest. If
the window length is set to, for example, twice the expected delay between
request and response, the client could be quite confident that there have
been no inadvertent replays if no duplicate nonce values are detected.

To summarize, the nonce should not be an optional component of replay
detection (as suggested by the current wording) - it is necessary if the
client is trying to protect against anything other than deliberate middleman
replays.

It is suggested that the wording in the fourth sentence of the second
paragraph of Section 2.2 (page 3) be changed to:

"It SHALL then verify the value of the nonce (large random number with high
probability that is generated by the client only once) included in the
response against the nonce value included in the corresponding request to
ensure that no replay has occurred."

In Section 2.4.1 remove the OPTIONAL qualifier from nonce in the definition
of TimeStampReq (page 4).

Change the wording of first sentence of the nonce description in Section
2.4.1 (page 5)to read:

"The nonce allows the client to verify the response against replay."

In Section 2.4.2 remove the OPTIONAL qualifier from nonce in the definition
of TSTInfo (page 7).

Change the wording of the nonce description in Section 2.4.2 (page 5)to
read:

"The nonce field MUST be equal to the value provided in the TimeStampReq
structure."

If you agree with this approach, then I would suggest we prepare a short
annex to describe the two different cases - subverted TSA vice inadvertent
replay.

Have a good weekend!

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

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Wednesday, May 24, 2000 5:36 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Rationale for Nonce in Time Stamp Protocol

Francois,

I realized that I ommited to reply to your E-mail.
 
> 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, 

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
> 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. 

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
> such a trusted time source locally, what is the point in using a TTP for
> time stamping?

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

> 
> 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?

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

> 
> 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: Tue, 30 May 2000 12:08:56 +0200

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". 

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.
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
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 you prefer a different wording, please provide the amended text.

Denis