wsu:Timestamp, first or last?

There seem to be two schools of thought as to where the best place is for the wsu:Timestamp element in the wsse:Security header. One approach is to put the timestamp at the end of the header;
 
<wsse:Security>
 <wsse:BinarySecurityToken … >
 …
 </wsse:BinarySecurityToken>
 <ds:Signature>
 …
 </ds:Signature>
 <wsu:Timestamp>
  <wsu:Created …>2005-09-08T10:05:27Z</wsu:Created>
 </wsu:Timestamp>
</wsse:Security>
 
the other approach is to put the timestamp at the beginning;

<wsse:Security>
 <wsu:Timestamp>
   <wsu:Created …>2005-09-08T10:06:15Z</wsu:Created>
 </wsu:Timestamp>
 <wsse:BinarySecurityToken … >
 …
 </wsse:BinarySecurityToken>
 <ds:Signature>
 …
 </ds:Signature>
</wsse:Security>
 
 
So which approach is best? Processing the timestamp in a security header usually involves checking message freshness. In other words, has the message arrived at its destination within a reasonable time period. Let's for the sake of argument assume that the message must be less than 5 minutes old in order for it to pass muster in this regard.
 
If the timestamp is at the end of the security header, then it's possible that a whole load of processing relating to token processing, keys, decryption, digest computation and signature verification might occur, only for the receiver to subsequently find out that the message is more than 5 minutes old, hence is stale and has to be thrown away…
 
If the timestamp is at the beginning of the security header, the service can check for freshness and immediately stop processing the message if it's found to be stale. Thus avoiding all that expensive cryptographic processing.
 
Now, the alert among you will be thinking to yourselves at this point, "didn't the service just make a decision based on unverified data?". That is, the service checked the timestamp for freshness before verifying that the timestamp hadn't been tampered with in transit. And you know what? You're quite right. But you know what else? It doesn't matter!
 
There are the following possibilities;
  1. Message appears stale. Timestamp NOT tampered with.
  2. Message appears fresh. Timestamp NOT tampered with.
  3. Message appears stale. Timestamp tampered with.
  4. Message appears fresh. Timestamp tampered with.
 
In cases 1 and 3 we can safely throw away the message as soon as we see the timestamp indicates the message is stale. Why? Because in case 1 it really is stale, and in case 3, if we don't throw it away due to it being stale, we'll throw it away due to signature verification failure. In case 2 we don't want to throw the message away, everything is fine. And in case 4, we'll throw the message away due to signature verification failure.
 
Net; it's much more efficient to have the timestamp be the first element in the security header because the service can avoid a whole bunch of processing.
 
More to come on security header layout in subsequent entries.
 

 
 

Posted Sep 10 2005, 11:33 AM by martin-gudgin

Comments

Erik Johnson wrote re: wsu:Timestamp, first or last?
on 09-10-2005 9:57 AM
The 5 minute gap idea seems reasonable. But if the sender's clock is 1 second ahead of the receiver, WSE (2.0) likes to bounce the message since it seems to be coming from the future.

Is there any way to tune "future tolerance"?
John Kemp wrote re: wsu:Timestamp, first or last?
on 09-12-2005 5:37 AM
I think it's interesting that the timestamp is inside the WSSE header when it is being used to ensure *message* freshness. What if no security token is present in the message? One could imagine a freshness check being applied to other SOAP headers too...
Gudge wrote re: wsu:Timestamp, first or last?
on 09-12-2005 10:30 AM
John,

Indigo actually uses a security header containing just the timestamp in such cases. This can happen, for example, when using https.

Gudge
Gudge wrote re: wsu:Timestamp, first or last?
on 09-25-2005 5:30 PM
Erik,

We're tracking the 'future tolerance' issue internally, I'll let you know where we land.

Gudge

Add a Comment

(required)  
(optional)
(required)  
Remember Me?