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