Explanation of the 'Unable to create token' and 'unable to decrypt token' errors for the RSA Access Manager Agent

[#1]

Article Number

000029518

Applies To

RSA Product Set: ClearTrust
RSA Product/Service Type: Access Manager
RSA Version/Condition: 6.x
RSA Product/Service Type: Access Manager Agent
RSA Version/Condition: 4.9, 5.0

Issue

The following symptoms are seen:

• This error on the RSA ClearTrust Agent:

Unable to create token

• The Auth server debug output reports:

16:36:56:853 EST,Client IP Address = 255.255.255.255,Client Port = 1058,Result Code = 0,Result Action = User Token Failed,Result Reason = Token error

• The ctagent.log file displays the following error message:

Mar 30, 2004 8:52:39 AM EST - [8240] - <Critical> - Unable to create token. Authorization server returned: 15

• The ctagent.log files shows the following error message:

Dec 22, 2005 11:42:53 AM CST - [2336] - <Debug> - exception_type=TokenException, msg=(Token decryption failed)

Cause

Typically these error messages appear as expected behavior, and can be ignored.

More information on cookie decryption errors

All ClearTrust cookies are encrypted with an encryption key that is changed on a periodic basis. The frequency of key creation is determined by the cleartrust.keyserver.session_key_life setting in the keyserver.conf file. By default, this value is 30 minutes. The keyserver holds 14 old keys in a first-in first-out buffer. Once created, the key is held in that buffer for a period determined by the cleartrust.keyserver.token_lifetime which is one hour by default.

If a new key is created every 30 minutes, and held in this buffer for one hour, this means that old keys are retained, on average, for 1 1/2 hours.  Testing  and internal logic shows that it is actually greater and is actually two hours (see note #2).

With these numbers the buffer usually has three to four keys in it after it has been up for few hours and maintains that number while the site is up. The newly created key is used for both encryption and decryption while the older keys are used just for decryption.

ClearTrust-encrypted cookies are presented to the client web browsers and are stored in the browser for as long as the browser session is active by default (they can be persisted). These cookies are updated if the user access a web page; but if the user's browser is inactive, the cookies maintained by the web browser are not updated.

Users who are inactive are normally required to re-authenticate based on the value of the cleartrust.agent.idle_timeout (default is 15 minutes). If a user presents with a cookie, it is decrypted, and the last touch time is read. If the cookie is older than 15 minutes, the user is asked to re-authenticate. 

Once the key expires after two hours, it is dropped from the buffer. Any token/cookie encrypted by that key cannot be decrypted and generates one of the token errors below, depending on the version used:

Unable to extract session information from token. Authorization server returned: 15

or

Token Error
 

That is usually the case for sessions that are left open and idle for greater than two hours.  For example. this is common if a user leaves their session open at the end of the day and then tries to resume working the following morning.  At that point, the user will be forced to reauthenticate. In this case, instead of logging a user idle event, the aserver will log the cookie decryption event error.

The quantity of cookie decryption errors in the log files is not a one-to-one correspondence with the number of users being asked to authenticate. Cookies are presented to the web server for each element of a web page and each cookie will cause an error message in the log file. The cookies will be presented to the server during the display of the logon page itself. This means when a user presents with an old browser session, they may see a dozen or so messages logged for each event. In newer versions of the product features were added to reduce the redundant error messages. 

Resolution

In specific instances if this error is noted in increased frequency, the error may indicate a problem with keyserver synchronization.  In these instances the error message is associated with authenticated users being prompted for reauthentication before the idle timeout period.  This problem may occur when more than one aserver is in use, and the aservers are unable to retrieve new keys from their keyserver, or the keyservers are not in sync.  Look to the aserver and keyserver logs.  Restart the aservers and keyserver so that you know they are in sync. 

Also see articles:

• 000024719    Error: 'Unable to create token. Authorization server returned 15.' in agent log at log level 'Critical' in RSA ClearTrust Agent 4.5 for Microsoft IIS
• 000014966    AXM- unable to login to Cleartrust agent error: 'Cookie creation failed authorization server returned an unexpected value CT_COOKIE_ERROR'000014966    
• 000015054    AxM Agent 4.9.1 for Apache 2.X: 'Token decryption failed' when using some browsers.

 

Notes

Note 1

As of hot fix 4.5.0.16, the agent log file message has been changed from <critical> to <warning> level for this error.

Note 2

The keyserver starts counting the keys after the encryption key has moved down a slot in the table so it's always 1+ the ratio of the two numbers and then there is potentially and extra one as it creates the keys on even boundaries ( i. e., 1/2, 1, 1 1/2),  so when we check again at 1 1/2, there may be a delay and by the time we check a fourth has already been created. It is ratio of keys +2 times the key life.

Note 3

This solution supercedes  solution 000021220.