1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
|
#
# Configuration for the OTP module.
#
# This module allows you to use various handheld OTP tokens
# for authentication (Auth-Type := otp). These tokens are
# available from various vendors.
#
# WARNING WARNING WARNING WARNING WARNING WARNING WARNING
#
# Many tokens use ANSI X9.9 to generate passcodes. Ask your
# vendor what algorithm they use. If they won't tell you, don't
# buy their product!
#
# 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/docs/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".
otp {
# File containing user:card_type:key entries.
# See otppasswd.sample for examples of legal entries.
# This file must be mode 0400 or 0600, and owned by the user
# radiusd runs as.
# (default: /etc/otppasswd)
#pwdfile = /etc/otppasswd
# State manager rendezvous point.
# (default: /var/run/lsmd/socket)
#lsmd_rp = /var/run/lsmd/socket
# 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, a necessary restriction due to an inherent
# weakness of the RADIUS protocol which allows 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/otppasswd 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"
# Whether the soft PIN (see accompanying docs) is prepended (yes)
# or appended (no) to the passcode.
# (default: yes)
#prepend_pin = yes
# 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 rwindow_size and rwindow_delay are both non-zero, two
# consecutive correct sync passwords within the specified window,
# and within rwindow_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 rwindow_size
# to be less than ewindow_size. Setting this value very high can
# encourage/aggravate DoS (CPU %util).
# (default rwindow_size: 0)
# (default rwindow_delay: 60)
#rwindow_size = 0
#rwindow_delay = 60
# The following are MPPE settings. The otp module must be aware
# of these (at least for now), because we can't properly offload
# this to the mschap module. 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}
}
|