Subject: TSP-11 comments.

From: "Parag Namjoshi" <[email-masked]>
Date: Mon, 30 Oct 2000 18:17:33 +0530

Hi Denis,

Some comments about TSP-11 draft.

1. The sixth point in security considerations text does seem to consider the possibility of deliberate replay of requests. Consider a service provider who charges for timestamping. Client sends a (possibly signed) request. The attacker replays the request as many times as he likes !!! The attack will be detected when the subscriber gets an impressive bill at the end of the month :-) This can mess up any logging done by the server. The server could possibly maintain a window of recent nonces to reduce the intensity of this attack (Replay then can be attempted again after the window has moved on.) This can cause big problems with billing systems of the server. To defeat this attack, the requester should include his local time in the request. Server can then verify the timeliness of the request by verifying the time included in the request against its timesource and issue token accordingly.

2. The text for the sixth point is little unclear. Perhaps replay detection at server & client should treated under two different bullets.

3. Removal of 'policyQualifiers' effectively disallows CPS like structures for TSA. I feel "Timestamp Practices Statement" (TPS) is a legitimate requirement for a TSA. Wouldn't it be worthwhile to reintroduce TSAPolicyQualifiers or is it so detestable, that we  sacrifice TPS capability to avoid it ?

4. The draft does not define OID's for  "standard" policies.e.g.
* The conditions under which the time stamp may be used.
* The availability of a time-stamp log, to allow later verification that a time-stamp token is authentic
This may lead to interop problems. Could the draft define a few standard policy OID's like RFC2459 ?

Regards,
Parag.

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 30 Oct 2000 14:07:42 +0100

Parag,
 
> 1. The sixth point in security considerations text does seem to consider
> the possibility of deliberate replay of requests. Consider a service
> provider who charges for timestamping. Client sends a (possibly signed)
> request. The attacker replays the request as many times as he likes !!!
> The attack will be detected when the subscriber gets an impressive bill at
> the end of the month :-) This can mess up any logging done by the server.
> The server could possibly maintain a window of recent nonces to reduce the
> intensity of this attack (Replay then can be attempted again after the
> window has moved on.) This can cause big problems with billing systems of
> the server. To defeat this attack, the requester should include his local
> time in the request. Server can then verify the timeliness of the request
> by verifying the time included in the request against its timesource and
> issue token accordingly.

Authentication of requests is outside the scope of this document and can be
made using various means. Replay protection is dependent upon the data
origin authentication mechanism which is outside the scope of this document.
 
> 2. The text for the sixth point is little unclear. Perhaps replay
> detection at server & client should treated under two different bullets.

If you have a better text, I would be happy to consider it so that it could
possibly be included next year when we will go from Proposed Standard to
Standard.

> 3. Removal of 'policyQualifiers' effectively disallows CPS like structures
> for TSA. I feel "Timestamp Practices Statement" (TPS) is a legitimate
> requirement for a TSA. Wouldn't it be worthwhile to reintroduce
> TSAPolicyQualifiers or is it so detestable, that we  sacrifice TPS
> capability to avoid it ?

Russ Housley gave arguments. This is not necessary. 

> policy OID's like RFC2459 ?

This is a valid proposal. This could be the topic of new document. Let us
discuss this on the amiling list and/or at the coming San Diego meeting. If
this is agreed we would need to extend our charter.

Regards,

Denis