This is a sample "passwd" file used for ANSI X9.9 token authentication.
Actually, it's not a sample file, but it does document the format and
legal values. The default location is /etc/x99passwd.
This file must be mode 0400 or 0600 and owned by the user the radius
server runs as.
The format is username:card_type:key, eg
bob:cryptocard-d8-es:0101010101010101
The username is limited in that the ':' character may not appear.
The key must be 8 octets (sixteen hex digits) and must be a valid DES key.
The valid card types are:
x9.9 A generic x9.9 card. random challenge, 8 digit hex response.
generic synonym for x9.9
cryptocard-h8-rc random challenge, 8 digit hex response.
cryptocard-d8-rc random challenge, 8 digit decimal response.
cryptocard-h7-rc random challenge, 7 digit hex response.
cryptocard-d7-rc random challenge, 7 digit dec response.
cryptocard-h8-es event synchronous (only), 8 digit hex response.
cryptocard-d8-es event synchronous (only), 8 digit decimal response.
cryptocard-h7-es event synchronous (only), 7 digit hex response.
cryptocard-d7-es event synchronous (only), 7 digit decimal response.
cryptocard-h8-rs rc or es, 8 digit hex response.
cryptocard-d8-rs rc or es, 8 digit decimal response.
cryptocard-h7-rs rc or es, 7 digit hex response.
cryptocard-d7-rs rc or es, 7 digit decimal response.
The -es and -rs options may require some explanation. CRYPTOCard supports
two event synchronous modes, one in which the challenge is presented to
the user (so he can verify it against the challenge given to him by the
server), and one in which the challenge is not presented. The latter mode
is easier to use when the user cannot be presented with a challenge, or
if the presented challenge is not expected to match the token's displayed
challenge (as we do), since the user is not confused as to which number
he is supposed to enter as his password. This mode (-es) is easier for
the user, but it precludes the user being able to resync his token.
The reason the two modes are distinguished is so that the server doesn't
have to generate state and test if a response is an async response
(for -es); this saves at least one DES operation and two hmac operations
per authentication.
STATE:
Along with the passwd file is a "state file" which contains state
needed to authenticate synchronously, along with other persistent data.
There is one state file per user, with the same name as the user.
The default location for state files is in /etc/x99sync.d. For most
filesystems, this doesn't scale well beyond a few thousand users.
The format is
"version:user:challenge:key:last_auth_s:last_auth_t:last_auth_p:".
Note that the trailing colon is required.
version: 2
user: this is a sanity check field
challenge: the next synchronous challenge
key: the key used for the next challenge (currently unused)
last_auth_s: 0 if the last auth was successful,
number of consecutive failures if unsucessful
last_auth_t: the last time the user authenticated (success or failure)
last_auth_p: >1 if the last auth was sync+correct and user is in softfail,
0 otherwise; if >1, it is the ewindow position of the last auth.
If this file does not exist, the user must authenticate asynchronously.
Once that happens, the server will create this file. For tokens/modes
that don't support async auth at all (or if you disallow it anyway),
you will need to create this file at the time you add the user to
/etc/x99passwd. For CRYPTOCard, you can obtain the first sync challenge
by compiling crcalc.c, included with the module. When prompted for the
challenge, just hit return. This will encrypt a zero block, which is
what the token will also do upon programming. crcalc will display the
next challenge, which you can then use to initialize the state file.
For example:
1:bob:12345678:deadbeefdeadbeef:0:0:
When creating this file, make sure it is owned by the user the server
runs as.
To reset locked-out users, you can set the failures field to 0. You
may also need to reset the challenge field if they are too far out of
sync. (Determine the next challenge from the token's display.)