#
#  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}

}

