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

From: Denis Pinkas <[email-masked]>
Date: Tue, 01 Jun 1999 13:03:04 +0200

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)
> [email-masked]
> =================================

---

From: Robert Zuccherato <[email-masked]>
Date: Tue, 1 Jun 1999 14:38:37 -0400

Denis;

> ----------
> From: 	Denis Pinkas[SMTP:[email-masked]]
> 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?
> 
As I have stated previously on this list, there is a good reason for not
having unsigned error messages.  You cannot trust an unsigned error message,
but you can trust a signed error message.  As David Kurn said (in his May 20
message to the list), "A signed result lets the verifier conclude something
and act upon it.  An unsigned result leaves the verifier unable to act."  

Therefore, in the absence of a good reason to allow unsigned error messages,
I am opposed to them.

	Robert.

---

From: Sarbari Gupta <[email-masked]>
Date: Tue, 1 Jun 1999 15:42:08 -0400

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

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]

---

From: Robert Zuccherato <[email-masked]>
Date: Tue, 1 Jun 1999 17:45:40 -0400

Sarbari;

> ----------
> From: 	Sarbari Gupta[SMTP:[email-masked]]
> Sent: 	Tuesday, June 01, 1999 3:24 PM
> To: 	'Robert Zuccherato'; 'Denis Pinkas'
> Cc: 	PKIX (E-mail)
> Subject: 	RE: Do we need to authenticate error status and nonce
> You cite David Kurn's note as a justification for signed error messages
> - however, the argument does not sound very convincing to me. Why does
> an unsigned error leave the "verifier" unable to act? 
> 
Because it has no way of determining who that unsigned error message came
from.

> [BTW, what
> verifier are we talking about? I believe the entity receiving the error
> message is the TSA client.] 
> 
Yes, the "verifier" here is the verifier of the signed error message, or the
requester of the time stamp token.

> How do other protocols such as OCSP handle
> this issue?  
> 
Whether or not other drafts containing other protocols decided to protect
signed messages is not really relevant to whether or not this protocol
should use signed or unsigned error messages.

> We must be careful to distinguish between an "unsigned result" and an
> "unsigned error result". I agree that an unsigned SUCCESSFUL result is
> meaningless. However, in the case of the TSA protocols, I would still
> claim that an unsigned ERROR result need not be signed. 
> 
> In order to determine whether a signed error response is necessary or
> overkill, we need to consider the type of attacks that are possible in
> either case. The statement "an unsigned result leaves the verifier
> unable to act" is somewhat vague. What would the "verifier" do if the
> attacker deleted the signed error response - would the "verifier" now be
> able to act? 
> 
If the verifier knew that the TSA would always respond with a signed error
message when it could and it didn't receive one, then one of two possible
things happened.  Either the server is completely down, or the response was
deleted somehow in transit.  In either situation, the verifier would
probably want to contact the server in some other method to find out what is
going on and resolve the situation.

> Conversely, why can't the recipient act on an unsigned
> error message? 
> 
Because, if I get an error message saying "request not properly formed" then
I have no reason to trust it.  That message could just as easily have been
returned by any attacker.  Since I should not trust that message, I am
reduced to the same situation as above.  I should contact the server through
some other method to find out what is really going on.

> If an attacker were changing the error type, what could
> the attacker gain from that action that they couldn't achieve by simply
> deleting the entire (signed or unsigned) error response?
> 
They could change "time not available for the next week" with "malformed
request" which would cause me to repeatedly try and fix my request for a
week.  Or, they could change "malformed request" with "time not available"
which may cause me not to get the document timestamped until next week.  Or,
they could change any error with "TSA XXX down, please try TSA YYY" where
TSA YYY is a competitor.  There are many possibilities.

> The bottom line is that the only attack possible on an unsigned error
> message is denial-of-service. 
> 
No, they can cause the person requesting the service to change their actions
based on the contents of the error message.

> However, the same attack is also possible
> on a signed error message. So, I would agree with Denis that an unsigned
> error response is adequate in this protocol.
> 
> Looking at the problem from another angle, the TSA protocol needs to
> change in some way to get the status info out of the TSA token. I have
> seldom seen a design where error codes get packaged into long-term
> objects - this problem needs to be fixed whether or not the error
> response gets signed or not. 
> 
Error codes are not packaged with long-term objects.  If an error is
present, the response is an error message, not a valid token.  If no error
is present, a status code indicating that a valid token was produced does
appear within the token.  But this is so that we do not have to produce
responses that consist of a signed token inside of another signed object
which contains the error codes (assuming that the status codes must be
signed).  Until I see a convincing reason why they should be contained in a
separate layer, I think we should leave things as they are and keep
everything simple.

	Robert.

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 2 Jun 1999 09:01:56 +0200

I have asked the question about how to react using http as a transport
in the case where the TSA cannot produce a signed response.

I would like to see how an http server should react (just drop
the http session, the tcp connection, keep it alive forever, or
create an http error.)

---

From: Robert Zuccherato <[email-masked]>
Date: Wed, 2 Jun 1999 09:36:14 -0400

Peter;

How about if I add something like the following to Section 3.4:
"Upon receiving a valid request, the server must respond with either a valid
response with content type application/timestamp or with an HTTP error."

	Robert.

> ----------
> From: 	Peter Sylvester[SMTP:[email-masked]]
> Sent: 	Wednesday, June 02, 1999 3:01 AM
> To: 	[email-masked]
> Cc: 	[email-masked]

---

From: Sarbari Gupta <[email-masked]>
Date: Wed, 2 Jun 1999 12:42:03 -0400

Robert,

> should use signed or unsigned error messages.

The OCSP case is absolutely relevant to this discussion. It also returns
a signed token when successful and an (unsigned) error message when
unsuccessful. The OCSP token is also long-lived exactly like the
TSAToken. The OCSP document, just like the TSA document, is an Intenet
Draft and is undergoing review.

As a group, PKIX should be able to justify design decisions it has made
in various I-Ds that are currently being reviewed. Decisions made should
be consistent for documents that are in parallel paths (at the very
least). I don't see how or why OCSP should be treated differently with
respect to error messages being signed or unsigned. The fundamental
characteristics are identical! 

> which may cause me not to get the document timestamped until 
> next week.  

All of the above scenarios are examples of denial-of-service attacks,
whereby the attacker is preventing the client from obtaining a valid
TSAToken. 

> Or,

This is not a valid example. The TSA client trusts the TSA for
timestamping. A TSA is not supposed to offer referral services, and even
if it does, the TSA client is under no obligation to use that referral
unless it has reason to trust TSA YYY through a valid certificate chain.
In that case, the referral is immaterial, the TSA client trusts TSA YYY
anyway, and would probably have used TSA YYY if TSA XXX were not
responding. 

I will send you a separate note on the issue of removing the statuscode
from the TSA Token.

- Sarbari

---

From: Robert Zuccherato <[email-masked]>
Date: Wed, 2 Jun 1999 15:38:51 -0400

Sarbari;

> Sent: 	Wednesday, June 02, 1999 12:42 PM
> To: 	'Robert Zuccherato'
> Cc: 	PKIX (E-mail)
No, they are not.  In OCSP the basic protocol does not link the request and
response.  This allows caching of responses.  Therefore, a signed error
message could be returned by an attacker in response to any request and thus
signed error messages are of no more value than unsigned error messages in
the OCSP case.  In this protocol, requests are always linked with responses,
and thus signed error messages are of value.  Since the underlying
assumptions and protocol characteristics are different, the OCSP case is not
relevant.  Could we now stick to discussing this protocol?

> whereby the attacker is preventing the client from obtaining a valid
Yes, they are examples of denial-of-service attacks.  However, they are
preventable by using signed error messages.  Also, because of these kinds of
attacks, I cannot trust any unsigned error message and every unsigned error
message is indistinguishable from a "no response".  As I said earlier, when
you receive a "no response" you probably want to contact your server by some
other method to find out what is going on.  Do we really want to design a
protocol that forces users to contact the server every time an error is
produced?

> anyway, and would probably have used TSA YYY if TSA XXX were not
Of course, these are just three examples that came into my head as I was
writing the email.  I'm sure we could all think of other, similar attacks.

	Robert.