[Issue] ClockSkew

[Hal Lockhart <hal.lockhart@entegrity.com>]

SAML should consider the potential effects of clock skew in environments it
is used.

It is impossible for local system clocks in a distributed system to be
exactly the same, the only question is: how much do they differ by? This
becomes an issue in security systems when information is marked with a
validity period. Different systems will interpret the validity period
according to their local time. This implies:

1. Relying parties may not make the same interpretation as asserting
parties.
2. Distinct relying parties may make different interpretations.

Generally what matters is not the absolute difference, but the difference as
compared to the total validity interval of the information. For example, the
PKI world has tended to (rightly) ignore this issue because CA and EE
certificates tend to have validity intervals of years. Even Attribute
Certificates and SAML Attribute Assertions are likely to have validity
intervals of days or hours. However, it seems likely that Authorization
Decision Assertions may sometimes have validity intervals of minutes or
seconds. Therefore, the issue must be raised.

One common problem is what to set the NotBefore element to. If it is set to
the AP's current time, it may not yet be valid for the RP. If set in the
past, (a common practice) the questions arise 1) how far in the past? and 2)
should the NotAfter time also be adjusted? If NotBefore is omitted, this may
not be satisfactory for nonrepudiation purposes.

The NotAfter value can also be an issue if the assumed clock skew is large
compared to the Validity Interval.

[These paragraphs contain personal observations by Hal Lockhart, others may
disagree. 

In the early 1990's some popular computer systems had highly erratic system
clocks which could drift from the correct time by as much as five minutes
per day. Kerberos's requirement for rough time synchronization (usually 5
minutes) was criticized at that time because of this reality. 

Today most popular computer systems have clocks which keep time accurately
to seconds per month. Therefore the most common current source of time
differences is the manual process of setting time. Therefore, most systems
tend to be accurate within a few minutes, generally less than 10.

By means of NTP or other time synchronization system, it is not hard to keep
systems synchronized to less than a minute, typically within 10 seconds. It
is common for production server systems to be maintained this way. The price
of GPS hardware has fallen to the point where it is not unreasonably
expensive to keep systems synchronized to the true time with sub-second
accuracy. However, few organizations bother to do this. ]

Potential Resolutions:

1.	SAML will leave it up to every deployment how to deal with clock
skew.
2.	SAML will explicitly state that deployments must insure that clocks
differ by no more that X amount of time (X to be specified in the
specification)
3.	SAML will provide a parameter to be set during deployment which
defines the maximum clock skew in that environment. This will be used by
AP's to adjust datetime fields according to some algorithm.
3. SAML will provide a parameter in assertions which indicates the maximum
skew in the environment. RPs should use this value in interpreting all
datetime fields.