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;
Message appears stale. Timestamp NOT tampered with.
Message appears fresh. Timestamp NOT tampered with.
Message appears stale. Timestamp tampered with.
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