|Applies To||RSA ACE/Server|
|Issue||Why is a consistent time reference important to the ACE/Server/SecurID authentication mechanism?|
ACE/Server system time is not set to UCT (Universal Coordinated Time)
The cornerstone of how SecurID implements strong, two-factor authentication is that access requires two correct pieces of information generated by unrelated sources. The user?s PIN is the first piece of information, and represents something the user knows. A Pseudo Random Number (PRN) generated by the SecurID token assigned to the user is the second piece of information, and represents something the user possesses. Combining the PIN with the PRN (that is, something the user knows with something the user possesses) creates a PASSCODE that can be used to make an access attempt.
The strength of SecurID is greatly enhanced by the mechanism in the token, which changes the electronically generated PRN every sixty seconds. This makes it effectively impossible for an Attacker who knows a user?s PIN and an earlier, valid PRN to replay those values to gain access. For the curious, the obvious follow-on question becomes, how does the ACE/Server differentiate between an expired PASSCODE and a valid one? The answer is Time!
How the ACE/Server predicts the current PRN for the user?s token:
Every SecurID token contains a clock and a unique starting value, known as a seed. The token?s clock, which is always set to Universal Coordinated Time (UCT), along with the seed value, are used to generate the PRN for each 60-second interval. As long as the seed remains secret, it is virtually impossible for an Attacker to correctly guess the current PRN before it expires.
Since the ACE/Server must be able to discern correct PASSCODEs from invalid ones, it must know the token?s seed value and have a reliable source for UCT time. The seed value is provided to customers by RSA manufacturing in an encrypted file that must be imported into the ACE/Server?s database before the token can be used. The time requirement is met by ensuring that the System Time on the ACE/Server is set to within one minute of UCT prior to loading the token seeds, and that the System Time is not allowed to significantly deviate thereafter from its initial setting.
It is well known that the internal clocks on many commercial machines drift and become less accurate over time. The ACE/Server attempts to compensate for this drift on a token-by-token basis. When a user presents a valid PASSCODE to the ACE/Server, some calculations are done to estimate the System Time drift relative to the clock on the token. This information is maintained on a per-token basis in the ACE/Server?s database. The more often a user logs in, the more accurate this information becomes, allowing the ACE/Server to more precisely account for the drift of its own System Clock.
Detecting Attackers and Next Tokencode mode:
An obvious follow-on question is, how does the ACE/Server differentiate between a user who has not logged-in for a long time, and an Attacker that is replaying an estimated, but not entirely accurate PASSCODE? The ACE/Server simply denies access. If the Attacker persists, the ACE/Server puts the burden of proof on the user by requiring them to provide two consecutive valid PASSCODEs before access is granted. In the language of ACE/Server administrators, the token is put into Next Tokencode mode. This has the desired effect of eliminating the Attacker, who will likely not be able to provide two valid consecutive PASSCODEs, and sharpening the ACE/Server?s knowledge of the System Time drift relative to the valid user?s token.
Recovering from Inadvertent Large Changes in the System Time:
Since System Time is a primary input for the ACE/Server?s access calculations, changing the System Time by as little as two minutes can have a seriously detrimental effect on the ACE/Server?s user community. The net result is that the time drift information maintained for each token is no longer accurate, and can cause the ACE/Server to incorrectly predict valid PASSCODEs. As a minimum, the ACE/Server administrator can expect this to cause many, if not most tokens to be put into Next Tokecode mode. There are a couple of options for correcting this dilemma. The ACE/Server administrator can allow users to correct the situation themselves via the Next Tokecode mode dialogue. If the System Time change is caught early enough, and the Administrator knows the precise amount of the time change, he or she can simply change the time back to what it was before. In the event the time change is not known, or the user community is unable to perform the Next Tokecode mode dialogue because of site restrictions, more difficult and time-consuming actions are required in order to recover. At this point, RSA Security recommends that the System Time on the ACE/Server be reset to UCT using a reliable time source. A token utility known as Setsync should then be run. Setsync resets the time drift information maintained for each token in the ACE/Server?s database to zero. The final step in the recovery requires the Administrator to use the ACE/Server administration program to manually perform the Next Tokecode mode dialogue on behalf of the users who are unable to gain legitimate access. Unfortunately it is not possible to predict in advance how many users will require this intervention.
Anyone who wants to correct a significant System Time problem on an otherwise functioning ACE/Server should implement the change in small units, such as five seconds, over a long period of time. Using small units of time change will minimize the number of users who will be forced into Next Tokecode mode. Spreading the change over a number of days, or perhaps weeks, gives users the opportunity to log in, and thus allow the ACE/Server to update the time drift information associated with their tokens. Note that there will always be the chance that users who do not login frequently enough may be denied access and their token put into Next Token Code Mode.
Similar guidance should be observed by anyone who wants to maintain the System Time on their ACE/Server using Network Time Protocol (NTP) or any of the other time management programs. Obviously the best time to install and enable NTP is when the ACE/Server is first being configured, before any tokens have been issued, though this is not always practical. When enabling NTP, or other time management protocols on a working ACE/Server, it is extremely wise to configure the program such that it will not make changes that exceed more than a few seconds. If this is not possible, then the ACE/Server?s time should be gradually adjusted manually, as previously discussed, before the time management program is allowed to operate.
|Legacy Article ID||6.0.1754190.2785997|