Best Practices - Timestamps & Nonces

Long lived signatures should include a timestamp to indicate the time of
signing just as a handwritten signature does. Note that in the absence
of a trusted time source, such a timestamp should be viewed as
indicating a minimum, but not a maximum age. This is because we assume
that a date in the future would be noticed during processing. So if the
date does not indicate when the signature was computed it at least
indicates earliest date it might have been made available for
processing.

DSS Profiles contain timestamps.

It is considered desirable for ephemeral signature to be relatively
recently signed and not to be replayed. A timestamp is useful for either
or both of these. The use for freshness is obvious. A timestamp is not
ideal for preventing replay, since depending on the granularity,
duplicates are possible. 

A better scheme is to use a nonce and a timestamp. The nonce is checked
to see if it duplicates a previously presented value. The timestamp
allows receivers to limit how long nonces are retained (or how many are
retained).

In many cases replay detection is provided as a part of application
logic, often and a by product of normal processing. For example, if
purchase orders are required to have a unique serial number, duplicates
may be automatically discarded. In these cases, it is not strictly
necessary for the security mechanisms to provide replay detection.
However, since application logic may be unknown or change over time,
providing replay detection is the safest policy.

Nonces and passwords must fall under at least one signature to be
effective. In addition, the signature should include at least a critical
portion of the message payload, otherwise an attacker might be able to
discard the timestamp and its signature without arousing suspicion.

WSS defines a timestamp element which can contain a Created value and/or
a Expires value. The Created value obviously represents an observation
made. The expires value is more problematic, as it represents a policy
choice which should belong to the receiver not the sender. Setting an
expiration date on a Token may reflect how long the data is expected to
be correct or how long the secret may remain uncompromised. However, the
semantics of a signature "expiring" is not clear.

WSS provides for the use of a nonce in conjunction with hashed
passwords, but not for general use with asymmetric or symmetric
signatures.

WSS sets a limit of one timestamp per Security header, but their can be
several signatures. In the typical case where all signatures are
generated at about the same time, this is not a problem, but SOAP
messages may pass through multiple intermediaries and be queued for a
time, so this limitation could possibly create problems. In general
Senders should ensure and receivers should assume that the timestamp
represents the first (oldest) signature. It is not clear how if at all a
timestamp relates to encrypted data.

Received on Tuesday, 15 April 2008 02:29:37 UTC