[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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