summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLinus Nordberg <linus@nordberg.se>2010-06-01 09:58:40 +0200
committerLinus Nordberg <linus@nordberg.se>2010-06-01 09:58:40 +0200
commit0b2d74529d19b4b25bb96736e005b2c38ac6d257 (patch)
tree22b5872ed4a551307810b5d1df44cd7f861abcbe
parent205865cfc023decf9e8b917dd2224ae4ee85423c (diff)
* radsecproxy.conf.5: Remove since it's generated from
radsecproxy.conf.5.xml (make target 'man').
-rw-r--r--radsecproxy.conf.5551
1 files changed, 0 insertions, 551 deletions
diff --git a/radsecproxy.conf.5 b/radsecproxy.conf.5
deleted file mode 100644
index e385c95..0000000
--- a/radsecproxy.conf.5
+++ /dev/null
@@ -1,551 +0,0 @@
-'\" -*- coding: us-ascii -*-
-.if \n(.g .ds T< \\FC
-.if \n(.g .ds T> \\F[\n[.fam]]
-.de URL
-\\$2 \(la\\$1\(ra\\$3
-..
-.if \n(.g .mso www.tmac
-.TH "radsecproxy.conf " 5 2009-03-12 "radsecproxy devel 2009-03-12" ""
-.SH NAME
-radsecproxy.conf
-\- Radsec proxy configuration file
-.SH DESCRIPTION
-When the proxy server starts, it will first check the command line arguments,
-and then read the configuration file. Normally radsecproxy will read the
-configuration file \*(T<\fI/etc/radsecproxy.conf\fR\*(T>. The command
-line \*(T<\fB\-c\fR\*(T> option can be used to instead read an alternate
-file (see
-\fBradsecproxy\fR(1)
-for details).
-.PP
-If the configuration file can not be found, the proxy will exit with an
-error message. Note that there is also an include facility so that any
-configuration file may include other configuration files. The proxy will
-also exit on configuration errors.
-.SH "CONFIGURATION SYNTAX"
-When the configuration file is processed, whitespace (spaces and tabs) are
-generally ignored. For each line, leading and trailing whitespace are ignored.
-A line is ignored if it is empty, only consists of whitespace, or if the first
-non-whitespace character is a \*(T<#\*(T>. The configuration is
-generally case insensitive, but in some cases the option values (see below)
-are not.
-.PP
-There are two types of configuration structures than can be used. The first
-and simplest are lines of the format \fIoption value\fR. That
-is, an option name, see below for a list of valid options, followed by
-whitespace (at least one space or tab character), followed by a value. Note
-that if the value contains whitespace, then it must be quoted using
-\*(T<""\*(T> or \*(T<''\*(T>. Any whitespace
-in front of the option or after the value will be ignored.
-.PP
-The other type of structure is a block. A block spans at least two lines, and
-has the format:
-.RS
-.nf
-
-blocktype name {
- option value
- option value
- ...
-}
-.fi
-.RE
-
-That is, some blocktype, see below for a list of the different block types, and
-then enclosed in braces you have zero or more lines that each have the
-previously described \fIoption value\fR format. Different block
-types have different rules for which options can be specified, they are listed
-below. The rules regarding white space, comments and quotes are as above. Hence
-you may do things like:
-.RS
-.nf
-
-blocktype name {
-# option value
- option "value with space"
- ...
-}
-.fi
-.RE
-.PP
-Option value characters can also be written in hex. This is done by writing the
-character \*(T<%\*(T> followed by two hexadecimal digits. If a
-\*(T<%\*(T> is used without two following hexadecimal digits, the
-\*(T<%\*(T> and the following characters are used as written. If you
-want to write a \*(T<%\*(T> and not use this decoding, you may of
-course write \*(T<%\*(T> in hex; i.e., \*(T<%25\*(T>.
-.PP
-There is one special option that can be used both as a basic option and inside
-all blocks. That is the option \*(T<include\*(T> where the value
-specifies files to be included. The value can be a single file, or it can use
-normal shell globbing to specify multiple files, e.g.:
-.RS
-include /etc/radsecproxy.conf.d/*.conf
-.RE
-
-The files are sorted alphabetically. Included files are read in the order they
-are specified, when reaching the end of a file, the next file is read. When
-reaching the end of the last included file, the proxy returns to read the next
-line following the \*(T<include\*(T> option. Included files may again
-include other files.
-.SH "BASIC OPTIONS"
-The following basic options may be specified in the configuration file. Note
-that blocktypes and options inside blocks are discussed later. Note that none
-of these options are required, and indeed in many cases they are not needed.
-Note that you should specify each at most once. The behaviour with multiple
-occurences is undefined.
-.TP
-\*(T<logLevel\*(T>
-This option specifies the debug level. It must be set to 1, 2, 3 or 4, where 1
-logs only serious errors, and 4 logs everything. The default is 2 which logs
-errors, warnings and a few informational messages. Note that the command line
-option \*(T<\fB\-d\fR\*(T> overrides this.
-.TP
-\*(T<logDestination\*(T>
-This specifies where the log messages should go. By default the messages go to
-syslog with facility \*(T<LOG_DAEMON\*(T>. Using this option you can
-specify another syslog facility, or you may specify that logging should be to
-a particular file, not using syslog. The value must be either a file or
-syslog URL. The file URL is the standard one, specifying a local file that
-should be used. For syslog, you must use the syntax:
-\*(T<x\-syslog:///FACILITY\*(T> where \*(T<FACILITY\*(T> must
-be one of \*(T<LOG_DAEMON\*(T>, \*(T<LOG_MAIL\*(T>,
-\*(T<LOG_USER\*(T>, \*(T<LOG_LOCAL0\*(T>,
-\*(T<LOG_LOCAL1\*(T>, \*(T<LOG_LOCAL2\*(T>,
-\*(T<LOG_LOCAL3\*(T>, \*(T<LOG_LOCAL4\*(T>,
-\*(T<LOG_LOCAL5\*(T>, \*(T<LOG_LOCAL6\*(T> or
-\*(T<LOG_LOCAL7\*(T>. You may omit the facility from the URL to
-specify logging to the default facility, but this is not very useful since
-this is the default log destination. Note that this option is ignored if
-\*(T<\fB\-f\fR\*(T> is specified on the command line.
-.TP
-\*(T<listenUDP\*(T>
-Normally the proxy will listen to the standard RADIUS UDP port
-\*(T<1812\*(T> if configured to handle UDP clients. On most systems it
-will do this for all of the system's IP addresses (both IPv4 and IPv6). On some
-systems however, it may respond to only IPv4 or only IPv6. To specify an
-alternate port you may use a value of the form \*(T<*:port\*(T> where
-port is any valid port number. If you also want to specify a specific address
-you can do e.g. \*(T<192.168.1.1:1812\*(T> or
-\*(T<[2001:db8::1]:1812\*(T>. The port may be omitted if you want the
-default one (like in these examples). These examples are equivalent to
-\*(T<192.168.1.1\*(T> and \*(T<2001:db8::1\*(T>. Note that
-you must use brackets around the IPv6 address.
-This option may be specified multiple times to listen to multiple addresses
-and/or ports.
-.TP
-\*(T<listenTCP\*(T>
-This option is similar to the \*(T<listenUDP\*(T> option, except
-that it is used for receiving connections from TCP clients. The default port
-number is \*(T<1812\*(T>.
-.TP
-\*(T<listenTLS\*(T>
-This is similar to the \*(T<listenUDP\*(T> option, except that it is
-used for receiving connections from TLS clients. The default port number is
-\*(T<2083\*(T>. Note that this option was previously called
-\*(T<listenTCP\*(T>.
-.TP
-\*(T<listenDTLS\*(T>
-This is similar to the \*(T<listenUDP\*(T> option, except that it is
-used for receiving connections from DTLS clients. The default port number is
-\*(T<2083\*(T>.
-.TP
-\*(T<sourceUDP\*(T>
-This can be used to specify source address and/or source port that the proxy
-will use for sending UDP client messages (e.g. Access Request).
-.TP
-\*(T<sourceTCP\*(T>
-This can be used to specify source address and/or source port that the proxy
-will use for TCP connections.
-.TP
-\*(T<sourceTLS\*(T>
-This can be used to specify source address and/or source port that the proxy
-will use for TLS connections.
-.TP
-\*(T<sourceDTLS\*(T>
-This can be used to specify source address and/or source port that the proxy
-will use for DTLS connections.
-.TP
-\*(T<TTLAttribute\*(T>
-This can be used to change the default TTL attribute. Only change this if
-you know what you are doing. The syntax is either a numerical value
-denoting the TTL attribute, or two numerical values separated by column
-specifying a vendor attribute, i.e. \*(T<vendorid:attribute\*(T>.
-.TP
-\*(T<addTTL\*(T>
-If a TTL attribute is present, the proxy will decrement the value and
-discard the message if zero. Normally the proxy does nothing if no TTL
-attribute is present. If you use the addTTL option with a value 1-255,
-the proxy will when forwarding a message with no TTL attribute, add one
-with the specified value. Note that this option can also be specified
-for a client/server. It will then override this setting when forwarding
-a message to that client/server.
-.TP
-\*(T<loopPrevention\*(T>
-This can be set to \*(T<on\*(T> or \*(T<off\*(T> with
-\*(T<off\*(T> being the default. When this is enabled, a request
-will never be sent to a server named the same as the client it was received
-from. I.e., the names of the client block and the server block are compared.
-Note that this only gives limited protection against loops.
-.TP
-\*(T<include\*(T>
-This is not a normal configuration option; it can be specified multiple times.
-It can both be used as a basic option and inside blocks. For the full
-description, see the configuration syntax section above.
-.SH BLOCKS
-There are five types of blocks, they are \*(T<client\*(T>,
-\*(T<server\*(T>, \*(T<realm\*(T>, \*(T<tls\*(T>
-and \*(T<rewrite\*(T>. At least one instance of each of
-\*(T<client\*(T> and \*(T<realm\*(T> is required. This is
-necessary for the proxy to do anything useful, and it will exit if not. The
-\*(T<tls\*(T> block is required if at least one TLS/DTLS client or
-server is configured. Note that there can be multiple blocks for each type.
-For each type, the block names should be unique. The behaviour with multiple
-occurences of the same name for the same block type is undefined. Also note
-that some block option values may reference a block by name, in which case
-the block name must be previously defined. Hence the order of the blocks may
-be significant.
-.SH "CLIENT BLOCK"
-The client block is used to configure a client. That is, tell the proxy about a
-client, and what parameters should be used for that client. The name of the
-client block must (with one exception, see below) be either the IP address
-(IPv4 or IPv6) of the client, an IP prefix (IPv4 or IPv6) of the form
-IpAddress/PrefixLength, or a domain name (FQDN). Note that literal IPv6
-addresses must be enclosed in brackets.
-.PP
-If a domain name is specified, then this will be resolved immediately to all
-the addresses associated with the name, and the proxy will not care about any
-possible DNS changes that might occur later. Hence there is no dependency on
-DNS after startup.
-.PP
-When some client later sends a request to the proxy, the proxy will look at the
-IP address the request comes from, and then go through all the addresses of
-each of the configured clients (in the order they are defined), to determine
-which (if any) of the clients this is.
-.PP
-In the case of TLS/DTLS, the name of the client must match the FQDN or IP
-address in the client certificate. Note that this is not required when the
-client name is an IP prefix.
-.PP
-Alternatively one may use the \*(T<host\*(T> option inside a client
-block. In that case, the value of the \*(T<host\*(T> option is used as
-above, while the name of the block is only used as a descriptive name for the
-administrator. The host option may be used multiple times, and can be a mix of
-addresses, FQDNs and prefixes.
-.PP
-The allowed options in a client block are \*(T<host\*(T>,
-\*(T<type\*(T>, \*(T<secret\*(T>, \*(T<tls\*(T>,
-\*(T<certificateNameCheck\*(T>,
-\*(T<matchCertificateAttribute\*(T>,
-\*(T<duplicateInterval\*(T>, \*(T<addTTL\*(T>,
-\*(T<rewrite\*(T>, \*(T<rewriteIn\*(T>,
-\*(T<rewriteOut\*(T> and \*(T<rewriteAttribute\*(T>.
-We already discussed the
-\*(T<host\*(T> option. The value of \*(T<type\*(T> must be
-one of \*(T<udp\*(T>, \*(T<tcp\*(T>, \*(T<tls\*(T>
-or \*(T<dtls\*(T>. The value of \*(T<secret\*(T> is the
-shared RADIUS key used with this client. If the secret contains whitespace,
-the value must be quoted. This option is optional for TLS/DTLS.
-.PP
-For a TLS/DTLS client you may also specify the \*(T<tls\*(T> option.
-The option value must be the name of a previously defined TLS block. If this
-option is not specified, the TLS block with the name
-\*(T<defaultClient\*(T> will be used if defined. If not defined, it
-will try to use the TLS block named \*(T<default\*(T>. If the
-specified TLS block name does not exist, or the option is not specified and
-none of the defaults exist, the proxy will exit with an error.
-.PP
-For a TLS/DTLS client, the option \*(T<certificateNameCheck\*(T>
-can be set
-to \*(T<off\*(T>, to disable the default behaviour of matching CN or
-SubjectAltName against the specified hostname or IP address.
-.PP
-Additional validation of certificate attributes can be done by use of the
-\*(T<matchCertificateAttribute\*(T> option. Currently one can only do
-some matching of CN and SubjectAltName. For regexp matching on CN, one can use
-the value \*(T<CN:/regexp/\*(T>. For SubjectAltName one can only do
-regexp matching of the URI, this is specified as
-\*(T<SubjectAltName:URI:/regexp/\*(T>. Note that currently this option
-can only be specified once in a client block.
-.PP
-The \*(T<duplicateInterval\*(T> option can be used to specify for how
-many seconds duplicate checking should be done. If a proxy receives a new
-request within a few seconds of a previous one, it may be treated the same if
-from the same client, with the same authenticator etc. The proxy will then
-ignore the new request (if it is still processing the previous one), or
-returned a copy of the previous reply.
-.PP
-The \*(T<addTTL\*(T> option is similar to the
-\*(T<addTTL\*(T> option used in the basic config. See that for
-details. Any value configured here overrides the basic one when sending
-messages to this client.
-.PP
-The \*(T<rewrite\*(T> option is deprecated. Use
-\*(T<rewriteIn\*(T> instead.
-.PP
-The \*(T<rewriteIn\*(T> option can be used to refer to a rewrite block
-that specifies certain rewrite operations that should be performed on incoming
-messages from the client. The rewriting is done before other processing.
-For details, see the rewrite block text below. Similarly to
-\*(T<tls\*(T> discussed above, if this option is not used, there is a
-fallback to using the \*(T<rewrite\*(T> block named
-\*(T<defaultClient\*(T> if it exists; and if not, a fallback to a
-block named \*(T<default\*(T>.
-.PP
-The \*(T<rewriteOut\*(T> option is used in the same way as
-\*(T<rewriteIn\*(T>, except that it specifies rewrite operations that
-should be performed on outgoing messages to the client. The rewriting is done
-after other processing. Also, there is no rewrite fallback if this option is
-not used.
-.PP
-The \*(T<rewriteAttribute\*(T> option currently makes it possible to
-specify that the User-Name attribute in a client request shall be rewritten in
-the request sent by the proxy. The User-Name attribute is written back to the
-original value if a matching response is later sent back to the client. The
-value must be of the form User-Name:/regexpmatch/replacement/. Example usage:
-.RS
-rewriteAttribute User-Name:/^(.*)@local$/\\1@example.com/
-.RE
-.SH "SERVER BLOCK"
-The server block is used to configure a server. That is, tell the proxy about a
-server, and what parameters should be used when communicating with that server.
-The name of the server block must (with one exception, see below) be either the
-IP address (IPv4 or IPv6) of the server, or a domain name (FQDN). If a domain
-name is specified, then this will be resolved immediately to all the addresses
-associated with the name, and the proxy will not care about any possible DNS
-changes that might occur later. Hence there is no dependency on DNS after
-startup. If the domain name resolves to multiple addresses, then for UDP/DTLS
-the first address is used. For TCP/TLS, the proxy will loop through the
-addresses until it can connect to one of them. In the case of TLS/DTLS, the
-name of the server must match the FQDN or IP address in the server certificate.
-.PP
-Alternatively one may use the \*(T<host\*(T> option inside a server
-block. In that case, the value of the \*(T<host\*(T> option is used as
-above, while the name of the block is only used as a descriptive name for the
-administrator. Note that multiple host options may be used. This will then be
-treated as multiple names/addresses for the same server. When initiating a TCP/TLS
-connection, all addresses of all names may be attempted, but there is no failover
-between the different host values. For failover one must use separate server
-blocks.
-.PP
-Note that the name of the block, or values of host options may include a
-port number (separated with a column). This port number will then override the
-default port or a port option in the server block. Also note that literal IPv6
-addresses must be enclosed in brackets.
-.PP
-The allowed options in a server block are \*(T<host\*(T>,
-\*(T<port\*(T>, \*(T<type\*(T>, \*(T<secret\*(T>,
-\*(T<tls\*(T>, \*(T<certificateNameCheck\*(T>,
-\*(T<matchCertificateAttribute\*(T>, \*(T<addTTL\*(T>,
-\*(T<rewrite\*(T>,
-\*(T<rewriteIn\*(T>, \*(T<rewriteOut\*(T>,
-\*(T<statusServer\*(T>, \*(T<retryCount\*(T>,
-\*(T<retryInterval\*(T> and \*(T<dynamicLookupCommand\*(T>.
-.PP
-We already discussed the \*(T<host\*(T> option. The
-\*(T<port\*(T> option allows you to specify which port number the
-server uses. The usage of \*(T<type\*(T>, \*(T<secret\*(T>,
-\*(T<tls\*(T>, \*(T<certificateNameCheck\*(T>,
-\*(T<matchCertificateAttribute\*(T>, \*(T<addTTL\*(T>,
-\*(T<rewrite\*(T>,
-\*(T<rewriteIn\*(T> and \*(T<rewriteOut\*(T> are just as
-specified for the \*(T<client block\*(T> above, except that
-\*(T<defaultServer\*(T> (and not \*(T<defaultClient\*(T>)
-is the fallback for the \*(T<tls\*(T>, \*(T<rewrite\*(T>
-and \*(T<rewriteIn\*(T> options.
-.PP
-\*(T<statusServer\*(T> can be specified to enable the use of
-status-server messages for this server. The value must be either
-\*(T<on\*(T> or \*(T<off\*(T>. The default when not
-specified, is \*(T<off\*(T>. If statusserver is enabled, the proxy
-will during idle periods send regular status-server messages to the server
-to verify that it is alive. This should only be enabled if the server
-supports it.
-.PP
-The options \*(T<retryCount\*(T> and
-\*(T<retryInterval\*(T> can be used to specify how many times the
-proxy should retry sending a request and how long it should wait between each
-retry. The defaults are 2 retries and an interval of 5s.
-.PP
-The option \*(T<dynamicLookupCommand\*(T> can be used to specify a
-command that should be executed to dynamically configure and use a server.
-The use of this feature will be documented separately/later.
-.SH "REALM BLOCK"
-When the proxy receives an Access-Request it needs to figure out to which
-server it should be forwarded. This is done by looking at the Username attribute
-in the request, and matching that against the names of the defined realm blocks.
-The proxy will match against the blocks in the order they are specified, using
-the first match if any. If no realm matches, the proxy will simply ignore the
-request. Each realm block specifies what the server should do when a match is
-found. A realm block may contain none, one or multiple \*(T<server\*(T>
-options, and similarly \*(T<accountingServer\*(T> options. There are
-also \*(T<replyMessage\*(T> and \*(T<accountingResponse\*(T>
-options. We will discuss these later.
-.SS "REALM BLOCK NAMES AND MATCHING"
-In the general case the proxy will look for a \*(T<@\*(T> in the
-username attribute, and try to do an exact case insensitive match between what
-comes after the \*(T<@\*(T> and the name of the realm block. So if you
-get a request with the attribute value \*(T<anonymous@example.com\*(T>,
-the proxy will go through the realm names in the order they are specified,
-looking for a realm block named \*(T<example.com\*(T>.
-.PP
-There are two exceptions to this, one is the realm name \*(T<*\*(T>
-which means match everything. Hence if you have a realm block named
-\*(T<*\*(T>, then it will always match. This should then be the last
-realm block defined, since any blocks after this would never be checked. This
-is useful for having a default.
-.PP
-The other exception is regular expression matching. If the realm name starts
-with a \*(T</\*(T>, the name is treated as an regular expression. A
-case insensitive regexp match will then be done using this regexp on the value
-of the entire Username attribute. Optionally you may also have a trailing
-\*(T</\*(T> after the regexp. So as an example, if you want to use
-regexp matching the domain \*(T<example.com\*(T> you could have a
-realm block named \*(T</@example\e\e.com$\*(T>. Optinally this can also
-be written \*(T</@example\e\e.com$/\*(T>. If you want to match all
-domains under the \*(T<.com\*(T> top domain, you could do
-\*(T</@.*\e\e.com$\*(T>. Note that since the matching is done on the
-entire attribute value, you can also use rules like
-\*(T</^[a\-k].*@example\e\e.com$/\*(T> to get some of the users in this
-domain to use one server, while other users could be matched by another realm
-block and use another server.
-.SS "REALM BLOCK OPTIONS"
-A realm block may contain none, one or multiple \*(T<server\*(T>
-options. If defined, the values of the \*(T<server\*(T> options must
-be the names of previously defined server blocks. Normally requests will be
-forwarded to the first server option defined. If there are multiple server
-options, the proxy will do fail-over and use the second server if the first
-is down. If the two first are down, it will try the third etc. If say the
-first server comes back up, it will go back to using that one. Currently
-detection of servers being up or down is based on the use of StatusServer (if
-enabled), and that TCP/TLS/DTLS connections are up.
-.PP
-A realm block may also contain none, one or multiple
-\*(T<accountingServer\*(T> options. This is used exactly like the
-\*(T<server\*(T> option, except that it is used for specifying where
-to send matching accounting requests. The values must be the names of
-previously defined server blocks. When multiple accounting servers are
-defined, there is a failover mechanism similar to the one for the
-\*(T<server\*(T> option.
-.PP
-If there is no \*(T<server\*(T> option, the proxy will if
-\*(T<replyMessage\*(T> is specified, reply back to the client with
-an Access Reject message. The message contains a replyMessage attribute with
-the value as specified by the \*(T<replyMessage\*(T> option. Note
-that this is different from having no match since then the request is simply
-ignored. You may wonder why this is useful. One example is if you handle say
-all domains under say \*(T<.bv\*(T>. Then you may have several realm
-blocks matching the domains that exists, while for other domains under
-\*(T<\&.bv\*(T> you want to send a reject. At the same time you might
-want to send all other requests to some default server. After the realms for
-the subdomains, you would then have two realm definitions. One with the name
-\*(T</@.*\e\e.bv$\*(T> with no servers, followed by one with the name
-\*(T<*\*(T> with the default server defined. This may also be useful
-for blocking particular usernames.
-.PP
-If there is no \*(T<accountingServer\*(T> option, the proxy will
-normally do nothing, ignoring accounting requests. There is however an option
-called \*(T<accountingResponse\*(T>. If this is set to
-\*(T<on\*(T>, the proxy will log some of the accounting information
-and send an Accounting-Response back. This is useful if you do not care much
-about accounting, but want to stop clients from retransmitting accounting
-requests. By default this option is set to \*(T<off\*(T>.
-.SH "TLS BLOCK"
-The TLS block specifies TLS configuration options and you need at least one
-of these if you have clients or servers using TLS/DTLS. As discussed in the
-client and server block descriptions, a client or server block may reference
-a particular TLS block by name. There are also however the special TLS block
-names \*(T<default\*(T>, \*(T<defaultClient\*(T> and
-\*(T<defaultServer\*(T> which are used as defaults if the client or
-server block does not reference a TLS block. Also note that a TLS block must
-be defined before the client or server block that would use it. If you want
-the same TLS configuration for all TLS/DTLS clients and servers, you need
-just a single tls block named \*(T<default\*(T>, and the client and
-servers need not refer to it. If you want all TLS/DTLS clients to use one
-config, and all TLS/DTLS servers to use another, then you would be fine only
-defining two TLS blocks named \*(T<defaultClient\*(T> and
-\*(T<defaultServer\*(T>. If you want different clients (or different
-servers) to have different TLS parameters, then you may need to create other
-TLS blocks with other names, and reference those from the client or server
-definitions. Note that you could also have say a client block refer to a
-default, even \*(T<defaultServer\*(T> if you really want to.
-.PP
-The available TLS block options are \*(T<CACertificateFile\*(T>,
-\*(T<CACertificatePath\*(T>, \*(T<certificateFile\*(T>,
-\*(T<certificateKeyFile\*(T>,
-\*(T<certificateKeyPassword\*(T>, \*(T<cacheExpiry\*(T>,
-\*(T<CRLCheck\*(T> and \*(T<policyOID\*(T>.
-When doing RADIUS over TLS/DTLS, both the
-client and the server present certificates, and they are both verified by
-the peer. Hence you must always specify \*(T<certificateFile\*(T>
-and \*(T<certificateKeyFile\*(T> options, as well as
-\*(T<certificateKeyPassword\*(T> if a password is needed to decrypt
-the private key. Note that \*(T<CACertificateFile\*(T> may be a
-certificate chain. In order to verify certificates, or send a chain of
-certificates to a peer, you also always need to specify
-\*(T<CACertificateFile\*(T> or \*(T<CACertificatePath\*(T>.
-Note that you may specify both, in which case the certificates in
-\*(T<CACertificateFile\*(T> are checked first. By default CRLs are
-not checked. This can be changed by setting \*(T<CRLCheck\*(T> to
-\*(T<on\*(T>. One can require peer certificates to adhere to certain
-policies by specifying one or multiple policyOIDs using one or multiple
-\*(T<policyOID\*(T> options.
-.PP
-CA certificates and CRLs are normally cached permanently. That is, once a CA
-or CRL has been read, the proxy will never attempt to re-read it. CRLs may
-change relatively often and the proxy should ideally always use the latest
-CRLs. Rather than restarting the proxy, there is an option
-\*(T<cacheExpiry\*(T> that specifies how many seconds the CA and
-CRL information should be cached. Reasonable values might be say 3600
-(1 hour) or 86400 (24 hours), depending on how frequently CRLs are updated
-and how critical it is to be up to date. This option may be set to zero to
-disable caching.
-.SH "REWRITE BLOCK"
-The rewrite block specifies rules that may rewrite RADIUS messages. It can be
-used to add, remove and modify specific attributes from messages received
-from and sent to clients and servers. As discussed in the client and server
-block descriptions, a client or server block may reference a particular
-rewrite block by name. There are however also the special rewrite block names
-\*(T<default\*(T>, \*(T<defaultClient\*(T> and
-\*(T<defaultServer\*(T> which are used as defaults if the client or
-server block does not reference a block. Also note that a rewrite block must
-be defined before the client or server block that would use it. If you want
-the same rewrite rules for input from all clients and servers, you need just
-a single rewrite block named \*(T<default\*(T>, and the client and
-servers need not refer to it. If you want all clients to use one config, and
-all servers to use another, then you would be fine only defining two rewrite
-blocks named \*(T<defaultClient\*(T> and
-\*(T<defaultServer\*(T>. Note that these defaults are only used for
-rewrite on input. No rewriting is done on output unless explicitly specifed
-using the \*(T<rewriteOut\*(T> option.
-.PP
-The available rewrite block options are \*(T<addAttribute\*(T>,
-\*(T<removeAttribute\*(T>, \*(T<removeVendorAttribute\*(T>
-and \*(T<modifyAttribute\*(T>. They can all be specified none, one
-or multiple times.
-.PP
-\*(T<addAttribute\*(T> is used to add attributes to a message. The
-option value must be of the form \*(T<attribute:value\*(T> where
-attribute is a numerical value specifying the attribute.
-.PP
-The \*(T<removeAttribute\*(T> option is used to specify an
-attribute that should be removed from received messages. The option value
-must be a numerical value specifying which attribute is to be removed.
-Similarly, \*(T<removeVendorAttribute\*(T> is used to specify a
-vendor attribute that is to be removed. The value can be a numerical value
-for removing all attributes from a given vendor, or of the form
-\*(T<vendor:subattribute\*(T>, where vendor and subattribute are
-numerical values, for removing a specific subattribute for a specific
-vendor.
-.PP
-\*(T<modifyAttribute\*(T> is used to specify modification of
-attributes. The value must be of the form
-\*(T<attribute:/regexpmatch/replacement/\*(T> where attribute is
-a numerical attribute type, regexpmatch is regexp matching rule and
-replacement specifies how to replace the matching regexp. Example usage:
-.RS
-modifyAttribute 1:/^(.*)@local$/\\1@example.com/
-.RE
-.SH "SEE ALSO"
-\fBradsecproxy\fR(1),
-.URL http://tools.ietf.org/html/draft-ietf-radext-radsec " RadSec internet draft "