RE: [Issue] ClockSkew

["Simon Y. Blackwell" <sblackwell@psoom.com>]

Although this would by no means solve all the issues with skew, could it not
be the case that PEPs or PDPs could volunteer their respective times to each
other so that they could at least resolve any bi-lateral skew?

> -----Original Message-----
> From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
> Sent: Monday, June 04, 2001 2:35 PM
> To: security-services@lists.oasis-open.org
> Subject: [Issue] ClockSkew
> 
> 
> 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.
>