2
# Configuration for the ANSI X9.9 module.
5
# This module allows you to use ANSI X9.9 compliant/compatible
6
# challenge/response tokens for authentication
7
# (Auth-Type := x99_token). These tokens are available from
10
# WARNING WARNING WARNING WARNING WARNING WARNING WARNING
12
# ANSI X9.9 has been withdrawn as a standard, due to the weakness
13
# of DES. An attacker can learn the token's secret by observing
14
# two challenge/response pairs. See ANSI document X9 TG-24-1999
15
# <URL:http://www.x9.org/TG24_1999.pdf>.
17
# The obvious fix is to not display the challenge; the attacker
18
# will not have access to the plaintext. This is possible since
19
# most (all?) vendors of X9.9 tokens support a synchronous mode.
20
# So, in synchronous modes, the challenge presented to the user is
21
# NOT the challenge used for response calculation. See the
22
# accompanying docs for more information.
24
# You must list this module in BOTH the authorize and authenticate
25
# sections in order to use it. Challenges are generated by the
26
# authorization code, and responses verified by the authentication code.
27
# This is just "how freeradius works".
29
# File containing user:card_type:key entries.
30
# See x99passwd.sample for examples of legal entries.
31
# This file must be mode 0400 or 0600, and owned by the user
33
# (default: /etc/x99passwd)
34
#pwdfile = /etc/x99passwd
36
# Directory containing sync mode and state info.
37
# This directory must be mode 0700, and owned by the
38
# the user radiusd runs as.
39
# (default: /etc/x99sync.d)
40
#syncdir = /etc/x99sync.d
42
# Text to use for the challenge. The '%' character is
43
# disallowed, except that you MUST have a single "%s"
44
# sequence in the string; the challenge itself is
45
# inserted there. (default "Challenge: %s\n Response: ")
46
#challenge_prompt = "Challenge: %s\n Response: "
48
# Length of the challenge. Most tokens probably support a
49
# max of 8 digits. (range: 5-32 digits, default 6)
52
# Maximum time, in seconds, that a challenge is valid.
53
# (The user must respond to a challenge within this time.)
54
# It is also the minimal time between consecutive async mode
55
# authentications. This is used to prevent replay attacks.
59
# The number of times a user can give an incorrect response
60
# before they enter into "delay mode". 0 == infinite. In
61
# delay mode, authentication attempts will always fail during
62
# the delay period. The delay period starts at 1m and doubles
63
# for each successive failure up to a max of 32m (the clock
64
# starts at the time of the last authentication attempt).
68
# The number of times a user can give an incorrect response
69
# before they are locked out completely. 0 == no lockout.
70
# Any non-zero value is probably only useful if you aren't
71
# actively monitoring the server logs (tsk tsk), but want to
72
# know if an (active) user's account is being attacked. This
73
# value can be less than softfail, in which case users are
74
# never delayed, just simply locked out.
78
# Whether or not to allow synchronous mode authentication.
79
# If your X9.9 users can authenticate to multiple RADIUS
80
# servers, this should be "yes" for the primary/default
81
# server, and "no" for the others. It is critically
82
# important that only one server authenticate users
83
# synchronously as the state information is not shared
84
# across servers. It's not just the case that a user will
85
# be out of sync, the user (or an attacker!) will be able
86
# to reuse a password. This setting allows you to copy
87
# your /etc/x99passwd file to all servers without changing
88
# the card_type definition. (default: yes)
91
# Whether or not the user can enter the sync response before
92
# being challenged. This permits authentication where the
93
# NAS doesn't handle Access-Challenge requests. When using
94
# fast_sync, challenges are only issued on request
95
# (see challenge_req, below). allow_sync must be "yes" for
96
# this to work. If you are using pam_radius as a client,
97
# and you have fast_sync set to "no", you probably want to use
98
# the "skip_passwd" option in pam_radius. See also resync_req.
102
# Whether or not to allow asynchronous ("pure" challenge/
103
# response) mode authentication. You may wish to disable
104
# this and require that out-of-sync users resync from
105
# specifically secured terminals. This is the only
106
# safe way to allow async responses without implementing
107
# a site-specific challenge transform. See the accompanying
108
# docs for more info. (default: no)
111
# Special password that requests a challenge in fast_sync mode.
112
# allow_async must be "yes" for the response to be handled async.
113
# That is, if the user uses this as their password, they WILL
114
# get a challenge; but their response will only be tested against
115
# the expected async response if allow_async is "yes".
116
# (default: "challenge")
117
#challenge_req = "challenge"
119
# Like challenge_req, except that using this as the password
120
# additionally resyncs the token. You can set this to the same
121
# value as challenge_req if you want this behaviour all the time,
122
# eg if your tokens don't support async-without-resync. When
123
# not doing fast_sync, the token is always resynced.
124
# (default: "resync")
125
#resync_req = "resync"
127
# Tokens that are event synchronous can easily lose sync with
128
# the server, eg if the user plays with the token they will
129
# increment the token's event counter, leaving the server
130
# behind. This value is the max number of events the server
131
# will tolerate the user being ahead. Be careful setting
132
# this value, it is also the number of responses that will
133
# be accepted. This value has no effect for tokens that
134
# encode/include the event count in the response. See the
135
# accompanying docs for more info. (max: 10, default: 0)
138
# If ewindow2_size and ewindow2_delay are both non-zero, two
139
# consecutive correct sync passwords within the specified window,
140
# and within ewindow2_delay seconds of each other, will override
141
# the "delay mode" forced by the softfail option and the user
142
# will be authenticated. It does not make sense for ewindow2_size
143
# to be less than ewindow_size. Setting this value very high can
144
# encourage/aggravate DoS (CPU %util).
145
# (default ewindow2_size: 0)
146
# (default ewindow2_delay: 60)
150
# The following are MS-CHAP/MPPE items. They don't properly
151
# belong in x99_token's configuration, but for the time being
152
# x99_token does it's own CHAP/MS-CHAP/MS-CHAPv2; the freeradius
153
# core doesn't support the testing of multiple passwords which
154
# the event window (ewindow_size, above) requires. Hopefully,
155
# this will change sometime. Note that MS-CHAP (v1) is strongly
156
# discouraged and does not build by default. All possible values
157
# are listed as {value = meaning}. Default values are first.
158
#mschapv2_mppe = {2 = required, 1 = optional, 0 = forbidden}
159
#mschapv2_mppe_bits = {2 = 128, 1 = 128 or 40, 0 = 40}
160
#mschap_mppe = {2 = required, 1 = optional, 0 = forbidden}
161
#mschap_mppe_bits = {2 = 128}
added
removed
raddb/x99.conf
