RE: Do we need to authenticate error status and nonce information in TSA responses?

[Sarbari Gupta <sgupta@xxxxxxxxxxxx>]

Denis:

I recognize your point with respect to the nonce needing to be signed
when the messageImprint included in the TSAToken is either absent or
non-unique. Basically, in those cases, you are using the "nonce" as a
reference/identifier to enable the pairing between the TSA request and
response. I guess in my mind the term "nonce" came with associated
connotations that imply some kind of transient information. However, I
think in the usage model you illustrated, the nonce is not really
transient info - it may be the ONLY way to establish the association
between a request and a response. 

Perhaps the "nonce" field can be renamed to "requestIdentifier" or
something similar? This renaming may help to avoid the misinterpretation
that the nonce field is transient info that is non-essential to the
verification and usage of the TSAToken.

- Sarbari
=================================
Sarbari Gupta
CygnaCom Solutions
(703)848-0883 (voice)
(703)848-0960(FAX)
sgupta@cygnacom.com
=================================

> -----Original Message-----
> From: Denis Pinkas [mailto:Denis.Pinkas@bull.net]
> Sent: Tuesday, June 01, 1999 7:03 AM
> To: Sarbari Gupta
> Cc: Robert Zuccherato (E-mail); PKIX (E-mail)
> Subject: Re: Do we need to authenticate error status and nonce
> information in TSA responses?
> 
> 
> Sarbari,
> 
> There has ben an avalanche of messages from you on May the 20 
> th and since
> then I have had no time to reply and apparently Robert has not replied
> either.
> 
> You proposed the following:
> 
> TSAResponse ::= SEQUENCE {
>         status  PKIStatusInfo,
>         nonce   Integer OPTIONAL,
>         timeStampToken  SignedData }
> 
> I strongly support the separation of the PKIStatusIngfo from 
> the TST. There
> are other supporters for this (e.g. Michael Zolotarev).
> 
> The nonce CANNOT be outside the TST for security reasons. 
> When the client
> has no local time refrence, it picks a nonce at random and 
> sends it. The
> fact that the same nonce is sent back and that the response 
> is within its
> allowed time frame  (replay is only possible within that time 
> window) allows
> to make sure of the timeliness of the response. If the nonce 
> were outside
> the signed structure then it could be substituted then no 
> guarantee about
> timeliness could be given. The hash cannot be used as a 
> substitute for the
> nonce for two reasons:
> 
> 1) a requester could have the need to time-stamp the same 
> information (hence
> the same hash) at two different instants of time, and thus a 
> replay would be
> possible in that situation.
> 
> 2) the hash is now optional, if someone simply wants to get 
> the time back.
> 
> I thought these explanations were pretty obvious. Apparently, 
> there are
> not.   :-)
> 
> I thus propose something along the following
> 
> TSAResponse ::= SEQUENCE {
>         status  PKIStatusInfo,
>         timeStampToken  SignedData }
> 
> Regards,
> 
> Denis
> 
> 
> > Robert,
> >
> > I have been thinking some more about the actual need to 
> authenticate the
> > error messages that come back from the TSA. The conclusion 
> I came to,
> > is, that it buys us very little or nothing. Information is 
> only worth
> > securing if there is a way for someone to profit from it when the
> > information is not secured. So, Denis' proposal for unsigned error
> > returns seems adequate.
> >
> > Let's think about it from the point of view of an attacker. 
> What happens
> > if we don't sign an error message from the TSA? An attacker can
> > substitute the actual error code with a different error 
> code and make
> > the TSA client think that their request failed for a 
> different reason.
> > The only gain for the attacker is thus denial-of-service 
> against the TSA
> > client. Now consider the opposite scenario where signed 
> error messages
> > are sent out by the TSA. Even in this case, the attacker can mount a
> > denial-of-service attack by simply deleting the signed 
> error message and
> > not letting the TSA client receive it.
> >
> > My feeling is that the only item that a TSA can return that 
> requires to
> > be authenticated is a time stamp token (TST), which, of 
> course, needs to
> > be signed.
> >
> > I would claim that the protocols in the timestamp I-D can 
> be simplified
> > by using the SignedData structure to hold the TST (without 
> status and
> > nonce) while the status and nonce are passed back 
> (unsigned). Thus, the
> > response from a TSA can be defined as a TSAResponse structure as
> > follows.
> >
> > TSAResponse ::= SEQUENCE {
> >         status  PKIStatusInfo,
> >         nonce   Integer OPTIONAL,
> >         timeStampToken  SignedData }
> >
> > In spite of the above, if someone wants to add 
> authentication to the TSA
> > response, they can make use of a secure transport mechanism.
> >
> > Comments? Thoughts?
> >
> > - Sarbari
> >
> > =================================
> > Sarbari Gupta
> > CygnaCom Solutions
> > (703)848-0883 (voice)
> > (703)848-0960(FAX)
> > sgupta@cygnacom.com
> > =================================
>