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:]
> Sent: Monday, June 04, 2001 9:55 PM
> To: ''
> 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:]
> > Sent: Monday, June 04, 2001 2:35 PM
> > To:
> > 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.
> >
>
