Gervase Markham <[EMAIL PROTECTED]> writes: >Peter Gutmann wrote: >> OCSP doesn't scale at all, which is why recent "high-performance" OCSP >> proposals break the protocol's security to allow replay attacks (Verisign for >> example broke their implementation last year some time in order to get it to, >> uhh, "scale", other vendors have done the same). The result is that you're >> not getting a real certificate status any more, just a replay of an old out- >> of-date status that may or may not be coming from an attacker. Nice warm >> fuzzies, but little else.
>If the status has a timestamp and a validity duration embedded in it, >how can a replay attack be effective? See "Lessons Learned in Implementing and Deploying Crypto Software" on my home page about the accuracy of typical computer clocks: Many security protocols, and in particular almost all PKI protocols which deal with validity intervals and time periods, assume they.re operating in the presence of precisely-synchronised clocks on all systems. The fact that this frequently isn.t the case was recognised a decade ago both by security researc hers (mostly as a result of Kerberos V4.s use of timestamps) [ 27] [28][29] and by implementers of post-Kerberos V4 protocols such as IBM.s KryptoKnight, which replaced the timestamps with nonces [30][31][32][33], Bell-Atlantic.s Yaksha [ 34][35], and to some extent Kerberos V5, which allows for (but doesn.t require) nonces [ 36]. More recently, one of the few published papers on PKI implementation experience pointed out the problems inherent in using timestamps for synchronisation in the CMP PKI protocol [37]. The author has seen Windows machines whose time was out by tens of minutes (incorrect settings or general clock drift), one or more hours (incorrect settings or incorrect time zone/daylight savings time adjustment), one or more days (incorrect settings or incorrect time zone, for example a machine in New Zealand set to GMT), and various larger units (weeks or months). In the most extreme case the time was out by several decades but wasn.t noticed by the user until cryptlib complained about a time problem while processing certificates with a known validity period. In addition to the basic incorrect time problems, combinations such as an offset of one day + one hour + 15 minutes have been spotted. In addition to problems due to incorrect settings, there are also potential implementation problems. One PKI pilot ran into difficulties because of differences in the calculation of offsets from GMT in different software packages [38]. Time zone issues are extremely problematic because some operating systems handle them in a haphazard manner or can be trivially misconfigured to get the offset wrong. Even when everything is set up correctly it can prove almost impossible to determine the time offset from a program in one time zone with daylight savings time adjustment and a second program in a different time zone without daylight savings time adjustment. A further problem with a reliance on timestamps is the fact that it extends the security baseline to something which is not normally regarded as being security-relevant, and which therefore won.t be handled as carefully as obviously - security-related items such as passwords and crypto tokens: .If timestamps are used as freshness guarantees by reference to absolute time, then the difference between local clocks at various machines must be much less than the allowable age of a message deemed to be valid. Furthermore, the time maintenance mechanism everywhere becomes part of the trusted computing base. [39]. To complicate things further, times are often deliberately set incorrectly to allow expired certificates to continue to be used without paying for a new one, a trick which shareware authors countered many years ago to prevent users from running trial versions of software indefinitely. For example Netscape.s code signing softwa re will blindly trust the date incorporated into a JAR file by the signer, allowing expired certificates to be rejuvenated by backdating the signature generation time. It would also be possible to resuscitate a revoked certificate using this trick, except that the software doesn.t perform revocation checking so it.s possible to use it anyway. [Read the paper for the rest] Using timestamps is a nice way of making synchronisation Someone Else's Problem, but it doesn't help security much. This is why the OCSP "performance fix" did away with replay protection, because now you can be as lax as you like without it causing any problems. When there were proper timeliness guarantees, you had to at least provide a fresh response, even if it came from a week-old CRL. Peter. _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
