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

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

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

Robert, 

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? [BTW, what
verifier are we talking about? I believe the entity receiving the error
message is the TSA client.] How do other protocols such as OCSP handle
this issue?  

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? Conversely, why can't the recipient act on an unsigned
error message? 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?

The bottom line is that the only attack possible on an unsigned error
message is denial-of-service. 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. 

- Sarbari
=================================
Sarbari Gupta
CygnaCom Solutions
(703)848-0883 (voice)
(703)848-0960(FAX)
[email-masked]
=================================

> -----Original Message-----
> From: Robert Zuccherato [mailto:[email-masked]]
> Sent: Tuesday, June 01, 1999 2:39 PM
> To: Sarbari Gupta; 'Denis Pinkas'
> Cc: PKIX (E-mail)
> Subject: RE: Do we need to authenticate error status and nonce
> information in TSA responses?
> 
> 
> 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?
> > 
> > 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).
> > 
> 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: Shabnam Erfani <[email-masked]>
Date: Tue, 01 Jun 1999 16:07:06 -0400

Sarbari,
	We should differentiate between denial of service attacks vs. integrity
attacks. In case of denial of service, the attacker simply deletes the
error message. In this case the client will timeout and probably retry,
so an action is taken. Anyway, a denial of service attack can go on
forever, and there is not much that we can do about it. The attacker can
also delete a SUCCESSFUL result, or the request itself.

In case of integrity attacks, it still is beneficial for the receiver to
detect them. First, some error codes may be handled by clients. For
example, if one TSA is not available, the client can decide to use a
backup, or just wait and resend the request later. A corrupted message
can send the client to another TSA for sure. Another point is that the
error information may be logged and used for auditing in the system, and
if corruption is detected, this information can be used to detect
possible intrusion attempts in the system if the pattern persists. For
auditing purposes we need accurate information, and signed error message
help build the assurance needed for auditing.

Regards,

Shabnam