#
# Configuration for the ANSI X9.9 module.
#
# This module allows you to use ANSI X9.9 compliant/compatible
# challenge/response tokens for authentication
# (Auth-Type := x99_token). These tokens are available from
# various vendors.
#
# WARNING WARNING WARNING WARNING WARNING WARNING WARNING
#
# ANSI X9.9 has been withdrawn as a standard, due to the weakness
# of DES. An attacker can learn the token's secret by observing
# two challenge/response pairs. See ANSI document X9 TG-24-1999
# <URL:http://www.x9.org/TG24_1999.pdf>.
#
# The obvious fix is to not display the challenge; the attacker
# will not have access to the plaintext. This is possible since
# most (all?) vendors of X9.9 tokens support a synchronous mode.
# So, in synchronous modes, the challenge presented to the user is
# NOT the challenge used for response calculation. See the
# accompanying docs for more information.
#
# You must list this module in BOTH the authorize and authenticate
# sections in order to use it. Challenges are generated by the
# authorization code, and responses verified by the authentication code.
# This is just "how freeradius works".
x99_token {
# File containing user:card_type:key entries.
# See x99passwd.sample for examples of legal entries.
# This file must be mode 0400 or 0600, and owned by the user
# radiusd runs as.
# (default: /etc/x99passwd)
#pwdfile = /etc/x99passwd
# Directory containing sync mode and state info.
# This directory must be mode 0700, and owned by the
# the user radiusd runs as.
# (default: /etc/x99sync.d)
#syncdir = /etc/x99sync.d
# Text to use for the challenge. The '%' character is
# disallowed, except that you MUST have a single "%s"
# sequence in the string; the challenge itself is
# inserted there. (default "Challenge: %s\n Response: ")
#challenge_prompt = "Challenge: %s\n Response: "
# Length of the challenge. Most tokens probably support a
# max of 8 digits. (range: 5-32 digits, default 6)
#challenge_length = 6
# Maximum time, in seconds, that a challenge is valid.
# (The user must respond to a challenge within this time.)
# It is also the minimal time between consecutive async mode
# authentications. This is used to prevent replay attacks.
# (default: 30)
#challenge_delay = 30
# The number of times a user can give an incorrect response
# before they enter into "delay mode". 0 == infinite. In
# delay mode, authentication attempts will always fail during
# the delay period. The delay period starts at 1m and doubles
# for each successive failure up to a max of 32m (the clock
# starts at the time of the last authentication attempt).
# (default: 5)
#softfail = 5
# The number of times a user can give an incorrect response
# before they are locked out completely. 0 == no lockout.
# Any non-zero value is probably only useful if you aren't
# actively monitoring the server logs (tsk tsk), but want to
# know if an (active) user's account is being attacked. This
# value can be less than softfail, in which case users are
# never delayed, just simply locked out.
# (default: 0)
#hardfail = 0
# Whether or not to allow synchronous mode authentication.
# If your X9.9 users can authenticate to multiple RADIUS
# servers, this should be "yes" for the primary/default
# server, and "no" for the others. It is critically
# important that only one server authenticate users
# synchronously as the state information is not shared
# across servers. It's not just the case that a user will
# be out of sync, the user (or an attacker!) will be able
# to reuse a password. This setting allows you to copy
# your /etc/x99passwd file to all servers without changing
# the card_type definition. (default: yes)
#allow_sync = yes
# Whether or not the user can enter the sync response before
# being challenged. This permits authentication where the
# NAS doesn't handle Access-Challenge requests. When using
# fast_sync, challenges are only issued on request
# (see challenge_req, below). allow_sync must be "yes" for
# this to work. If you are using pam_radius as a client,
# and you have fast_sync set to "no", you probably want to use
# the "skip_passwd" option in pam_radius. See also resync_req.
#(default: yes)
#fast_sync = yes
# Whether or not to allow asynchronous ("pure" challenge/
# response) mode authentication. You may wish to disable
# this and require that out-of-sync users resync from
# specifically secured terminals. This is the only
# safe way to allow async responses without implementing
# a site-specific challenge transform. See the accompanying
# docs for more info. (default: no)
#allow_async = no
# Special password that requests a challenge in fast_sync mode.
# allow_async must be "yes" for the response to be handled async.
# That is, if the user uses this as their password, they WILL
# get a challenge; but their response will only be tested against
# the expected async response if allow_async is "yes".
# (default: "challenge")
#challenge_req = "challenge"
# Like challenge_req, except that using this as the password
# additionally resyncs the token. You can set this to the same
# value as challenge_req if you want this behaviour all the time,
# eg if your tokens don't support async-without-resync. When
# not doing fast_sync, the token is always resynced.
# (default: "resync")
#resync_req = "resync"
# Tokens that are event synchronous can easily lose sync with
# the server, eg if the user plays with the token they will
# increment the token's event counter, leaving the server
# behind. This value is the max number of events the server
# will tolerate the user being ahead. Be careful setting
# this value, it is also the number of responses that will
# be accepted. This value has no effect for tokens that
# encode/include the event count in the response. See the
# accompanying docs for more info. (max: 10, default: 0)
#ewindow_size = 0
# If ewindow2_size and ewindow2_delay are both non-zero, two
# consecutive correct sync passwords within the specified window,
# and within ewindow2_delay seconds of each other, will override
# the "delay mode" forced by the softfail option and the user
# will be authenticated. It does not make sense for ewindow2_size
# to be less than ewindow_size. Setting this value very high can
# encourage/aggravate DoS (CPU %util).
# (default ewindow2_size: 0)
# (default ewindow2_delay: 60)
#ewindow2_size = 0
#ewindow2_delay = 60
# The following are MS-CHAP/MPPE items. They don't properly
# belong in x99_token's configuration, but for the time being
# x99_token does it's own CHAP/MS-CHAP/MS-CHAPv2; the freeradius
# core doesn't support the testing of multiple passwords which
# the event window (ewindow_size, above) requires. Hopefully,
# this will change sometime. Note that MS-CHAP (v1) is strongly
# discouraged and does not build by default. All possible values
# are listed as {value = meaning}. Default values are first.
#mschapv2_mppe = {2 = required, 1 = optional, 0 = forbidden}
#mschapv2_mppe_bits = {2 = 128, 1 = 128 or 40, 0 = 40}
#mschap_mppe = {2 = required, 1 = optional, 0 = forbidden}
#mschap_mppe_bits = {2 = 128}
}