000027095 - Explanation of Next Token Code Mode and Small  Medium and Large Windows in SecurID Authentication

Document created by RSA Customer Support Employee on Jun 14, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 4Show Document
  • View in full screen mode

Article Content

Article Number000027095
Applies ToSoftware token going into next token code mode unexpectedly
IssueExplanation of how the token seed files relate to when tokens go into next tokencode mode
Customer does not know why his token is going into next tokencode mode
Resolution
Next token mode occurs for 3 common reasons
1) the first use of a token requires a resynchronzation

2) The user has entered too many incorrect passcodes

3) The token presented to the AM server is outside of the automatic acceptance range (typically the previous token code, the expected tokencode and the next tokencode)
4) The server cannot determine the tokencode, because of no Node Secret with a Multihomed or NATed agent, or mismatched RADIUS Shared secret 
 

Note this can be caused by a delay between when the passcode was actually entered by the user, to when the passcode was actually received by the Authentication Manager server.

For example 

1)a user may be entering the passcode on a VPN Client installed on their PC.

2) The VPN Client then communicates with a firewall

3) The firewall actually makes the authentication request on behalf of the user to the Authentication Manager server

At any of these stages there can be a delay, so in order to explain why a token went into next token code mode we need the following times:

1) The time of when the user actually entered the passcode into the vpn client, web page, or agent and then pressed OK to SEND the passcode.

2) An Authentication Activity report on the server which shows when the Passcode was RECEIVED by the server.

The small, medium and large windows are defined in the token seed XML file. These values can not be modified by the user, and attempting to change them will cause the importing of the token file to fail.
If you look at the token seed file header then you will see:


<DefSmallWin>60</DefSmallWin>

        <DefMediumWin>120</DefMediumWin>

        <DefLargeWin>600</DefLargeWin>


The small window in seconds defines the range of codes that will be accepted with automatic acceptance

The Medium Window in seconds defines the range of codes that will force the token into next tokencode mode

The large window is used in the following cases:

a) This is first login (after server start) OR
b) The server has been restarted since the last login OR
c) Token is in new pin mode (only set for native pin token) OR
d) Token is in next tokencode AND client is single-transaction OR
e) Token is in next tokencode AND processing a normal authentication packet OR
f) First login (can only be true for null pin token)

g) User has entered a large number of incorrect passcodes

For a SID800 token the windows are typically defined as:


        <DefSmallWin>60</DefSmallWin>

        <DefMediumWin>120</DefMediumWin>

        <DefLargeWin>600</DefLargeWin>


This corresponds to an automatic acceptance range of + / - 1 minute

A Next Token Code mode range of [-3,-2 ] and [2,3]

And a large window mode of [-10, +10]

Soft Tokens also have these ranges defined.

Two examples are:


        <DefSmallWin>60</DefSmallWin>

        <DefMediumWin>120</DefMediumWin>

        <DefLargeWin>600</DefLargeWin>


This will cause the soft token to behave like a standard hardware token

or:


<DefSmallWin>630</DefSmallWin>

        <DefMediumWin>4320</DefMediumWin>

        <DefLargeWin>4320</DefLargeWin>


Here we can see that the ranges are greatly increased, to allow for the device with a software  token having somewhat incorrect time .
Note, these values are based on the token seed records, and cannot be changed
Legacy Article IDa62010

Attachments

    Outcomes