RE: [Issue] ClockSkew

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

I think it would be far superior to require (strongly recommend) that NTP be
implemented than invent some kind of poor man's NTP.

Hal

> -----Original Message-----
> From: Simon Y. Blackwell [mailto:sblackwell@psoom.com]
> Sent: Monday, June 04, 2001 9:55 PM
> To: 'security-services@lists.oasis-open.org'
> Subject: RE: [Issue] ClockSkew
> 
> 
> 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.
> > 
>