[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [Issue] ClockSkew
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. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC