Subject: Time Stamping: comments on nonce field

From: "Juan G. de la Vega" <[email-masked]>
Date: Wed, 7 Apr 1999 11:39:04 +0200

Hi PKIX-ers,
 
    I have some comments on Time Stamping protocols regarding "nonce" field:
 
        First of all, the declaration of this field in the request and token is somehow incoherent, while the nonce is mandatory in TimeStapReq (it is not declared OPTIONAL), the TimeStampToken´s nonce is OPTIONAL but it is stated that "...must be present if the similar field in TimeStampReq is present..." and hence the clause OPTIONAL is meaningless and confusing for this field shall always be present. I would suggest this field to be declared OPTIONAL both in the request and token or better deleted if we take into account the following:
 
    As far as I understand, a nonce value is present in the request and token in order for the requester to be able to match the responses from the TSA with her requests when using an asynchronous transport. It can be argued that such functionality should be left to the transport layer when required, but furthermore I must say that the nonce is not necessary since matching can be performed using the "messageImprint" field.
    The only justification at hand to defend the "nonce" is when asking a TSA "What time it is" (not including messageImprints field), and in order to defeat replay attacks in this case... Anyway, this use of a TSA steps aside from "providing a proof-of-existence for a particular message in an instant in time" and personally don't like it; I would call that a STS (secure time source) (i.e.: authenticated NTP) and would not force TS protocols modifications for that use.
 
    Regards,
 
    Juan.
____________________________________________
Juan González-de-la-Vega
Software Engineer
E-mail: <[email-masked]>
FNMT - Fábrica Nacional de Moneda y Timbre
Phone: +34 (91) 506 48 40.
Fax: +34 (91) 506 48 59

---

From: Robert Zuccherato <[email-masked]>
Date: Thu, 8 Apr 1999 10:26:40 -0400

Okay.  I will make it optional in both the request and response.

> ----------
> From: 	Denis Pinkas[SMTP:[email-masked]]
> Sent: 	Thursday, April 08, 1999 6:10 AM
> To: 	Robert Zuccherato
> Cc: 	[email-masked]; 'Juan G. de la Vega'
> Subject: 	Re: Time Stamping: comments on nonce field
> 
> Robert,
> 
> Some refinements to your response.
> 
> The nonce is there for systems that do not have their own reliable clock
> and
> thus cannot test the freshness of the response by simply looking at the
> signing
> time. This is a replay protection. This has nothing to do whether a hash
> of the
> message is or is not present.
> 
> I would make it OPTIONAL both in the request and in the response and
> maintain
> the current text that says: " ...must be present if the similar field in
> TimeStampReq is present ..."
> 
> Regards,
> 
> Denis
> 
> 
> > > ----------
> > > From:         Juan G. de la Vega[SMTP:[email-masked]]
> > > Sent:         Wednesday, April 07, 1999 5:39 AM
> > > To:   [email-masked]
> > > Subject:      Time Stamping: comments on nonce field
> > >
> > >         First of all, the declaration of this field in the request and
> > > token is somehow incoherent, while the nonce is mandatory in
> TimeStapReq
> > > (it is not declared OPTIONAL), the TimeStampToken´s nonce is OPTIONAL
> but
> > > it is stated that "...must be present if the similar field in
> TimeStampReq
> > > is present..." and hence the clause OPTIONAL is meaningless and
> confusing
> > > for this field shall always be present.
> > >
> > As I have said in the past, this was a mistake that I made because I did
> not
> > manage to fully include support for TSA production of a "signed time".
> This
> > would be a token which does not include a nonce or message imprint.
> TSA's
> > could produce these tokens and make them available (for example on a
> > website) for anyone who wants to obtain them.  This will be rectified in
> the
> > upcoming draft.
> >
> > > I would suggest this field to be declared OPTIONAL both in the request
> and
> > > token or better deleted if we take into account the following:
> > >
> > >     As far as I understand, a nonce value is present in the request
> and
> > > token in order for the requester to be able to match the responses
> from
> > > the TSA with her requests when using an asynchronous transport. It can
> be
> > > argued that such functionality should be left to the transport layer
> when
> > > required, but furthermore I must say that the nonce is not necessary
> since
> > > matching can be performed using the "messageImprint" 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.
> >
> >         Robert.
>

---

From: "Juan G. de la Vega" <[email-masked]>
Date: Fri, 9 Apr 1999 09:00:33 +0200

-----Mensaje original-----
De: Denis Pinkas <[email-masked]>
Para: Robert Zuccherato <[email-masked]>
CC: [email-masked] <[email-masked]>; 'Juan G. de la Vega'
<[email-masked]>
Fecha: jueves 8 de abril de 1999 13:06
Asunto: Re: Time Stamping: comments on nonce field

maintain

>TimeStampReq is present ..."

Completely agreed.

Juan.
____________________________________________
Juan González-de-la-Vega
Software Engineer
e-mail: <[email-masked]>
FNMT - Fábrica Nacional de Moneda y Timbre
Phone: +34 (91) 506 48 40.
Fax: +34 (91) 506 48 59

---

From: "Juan G. de la Vega" <[email-masked]>
Date: Fri, 9 Apr 1999 08:56:16 +0200

Hi again,

-----Mensaje original-----
De: Robert Zuccherato <[email-masked]>
Para: [email-masked] <[email-masked]>; 'Juan G. de la Vega'
<[email-masked]>
Fecha: miércoles 7 de abril de 1999 19:06
Asunto: RE: Time Stamping: comments on nonce field

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

---

From: "Juan G. de la Vega" <[email-masked]>
Date: Fri, 9 Apr 1999 09:16:15 +0200

That´s fine.

-----Mensaje original-----
De: Robert Zuccherato <[email-masked]>
Para: Robert Zuccherato <[email-masked]>; 'Denis Pinkas'
<[email-masked]>
CC: [email-masked] <[email-masked]>; 'Juan G. de la Vega'
<[email-masked]>
Fecha: jueves 8 de abril de 1999 17:30
Asunto: RE: Time Stamping: comments on nonce field