|
|
Эта страница руководства для версии 10.9 Mac OS XЕсли Вы выполняете различную версию Mac OS X, просматриваете документацию локально:
Читать страницы руководстваСтраницы руководства предназначаются как справочник для людей, уже понимающих технологию.
|
RACOON.CONF(5) BSD File Formats Manual RACOON.CONF(5)
NAME
racoon.conf -- configuration file for racoon
DESCRIPTION
racoon.conf is the configuration file for the racoon(8) ISAKMP daemon. racoon(8) negotiates security
associations for itself (ISAKMP SA, or phase 1 SA) and for kernel IPsec (IPsec SA, or phase 2 SA). The
file consists of a sequence of directives and statements. Each directive is composed by a tag and
statements, enclosed by `{' and `}'. Lines beginning with `#' are comments.
Meta Syntax
Keywords and special characters that the parser expects exactly are displayed using this font. Parame-ters Parameters
ters are specified with this font. Square brackets (`[' and `]') are used to show optional keywords
and parameters. Note that you have to pay attention when this manual is describing port numbers. The
port number is always enclosed by `[' and `]'. In this case, the port number is not an optional key-word. keyword.
word. If it is possible to omit the port number, the expression becomes [[port]]. The vertical bar
(`|') is used to indicate a choice between optional parameters. Parentheses (`(' and `)') are used to
group keywords and parameters when necessary. Major parameters are listed below.
number means a hexadecimal or a decimal number. The former must be prefixed with `0x'.
string
path
file means any string enclosed in `"' (double quotes).
address means IPv6 and/or IPv4 address.
port means a TCP/UDP port number. The port number is always enclosed by `[' and `]'.
timeunit is one of following: sec, secs, second, seconds, min, mins, minute, minutes, hour, hours.
Path Specification
This section specifies various paths used by racoon. When running in privilege separation mode,
certificate and script paths are mandatory. A racoon(8) restart is required if you want path changes to
be taken into account.
path include path;
Specifies a path to include a file. See File Inclusion.
path pre_shared_key file;
Specifies a file containing pre-shared key(s) for various ID(s). See Pre-shared key File.
path pidfile file;
Specifies file where to store PID of process. If path starts with / it is treated as an abso-lute absolute
lute path. Otherwise, it is treated as a relative path to the VARRUN directory specified at
compilation time. Default is racoon.pid.
path logfile file;
Specifies a file to which logs generated by racoon(8) are stored. When the file's size exceeds
200KB, racoon(8) will trim the logfile by dropping the oldest events. If path starts with / it
is treated as an absolute path. Otherwise, it is treated as a relative path to the VARRUN
directory specified at compilation time.
File Inclusion
include file
Specifies other configuration files to be included.
Identifier Specification
is obsolete. It must be defined at each remote directive.
Timer Specification
timer { statements }
This section specifies various timer values used by racoon.
counter number;
The maximum number of retries to send. The default is 5.
interval number timeunit;
The interval to resend, in seconds. The default time is 10 seconds.
persend number;
The number of packets per send. The default is 1.
phase1 number timeunit;
The maximum time it should take to complete phase 1. The default time is 15 seconds.
phase2 number timeunit;
The maximum time it should take to complete phase 2. The default time is 10 seconds.
natt_keepalive number timeunit;
The interval between sending NAT-Traversal keep-alive packets. The default time is 20
seconds. Set to 0s to disable keep-alive packets.
Listening Port Specification
listen { statements }
If no listen directive is specified, racoon(8) will listen on all available interface
addresses. The following is the list of valid statements:
isakmp address [[port]];
If this is specified, racoon(8) will only listen on the defined address. The default
port is 500, which is specified by IANA. You can provide more than one address defini-tion. definition.
tion.
isakmp_natt address [port];
Same as isakmp but also sets the socket options to accept UDP-encapsulated ESP traffic
for NAT-Traversal. If you plan to use NAT-T, you should provide at least one address
with port 4500, which is specified by IANA. There is no default.
strict_address;
Requires that all addresses for ISAKMP be bound. This statement will be ignored if you
do not specify address definitions.
Remote Nodes Specifications
remote (address | anonymous) [[port]] [inherit parent] { statements }
Specifies the IKE phase 1 parameters for each remote node. The default port is 500. If
anonymous is specified, the statements will apply to any peer that does not match a more spe-cific specific
cific remote directive.
Sections with inherit parent statements (where parent is either address or a keyword anonymous)
that have all values predefined to those of a given parent. In these sections it is enough to
redefine only the changed parameters.
The following are valid statements.
exchange_mode (main | aggressive | base);
Defines the exchange mode for phase 1 when racoon is the initiator. It also means the
acceptable exchange mode when racoon is the responder. More than one mode can be spec-ified specified
ified by separating them with a comma. All of the modes are acceptable. The first
exchange mode is what racoon uses when it is the initiator.
doi ipsec_doi;
Means to use IPsec DOI as specified in RFC 2407. You can omit this statement.
situation identity_only;
Means to use SIT_IDENTITY_ONLY as specified in RFC 2407. You can omit this statement.
identifier idtype;
This statment is obsolete. Instead, use my_identifier.
my_identifier [qualifier] idtype ...;
Specifies the identifier sent to the remote host and the type to use in the phase 1
negotiation. address, fqdn, user_fqdn, keyid, and asn1dn can be used as an idtype.
The qualifier is currently only used for keyid, and can be either file or tag. The
possible values are :
my_identifier address [address];
The type is the IP address. This is the default type if you do not specify an
identifier to use.
my_identifier user_fqdn string;
The type is a USER_FQDN (user fully-qualified domain name).
my_identifier fqdn string;
The type is a FQDN (fully-qualified domain name).
my_identifier keyid [file] file;
The type is a KEY_ID, read from the file.
my_identifier keyid tag string;
The type is a KEY_ID, specified in the quoted string.
my_identifier asn1dn [string];
The type is an ASN.1 distinguished name. If string is omitted, racoon(8) will
get the DN from the Subject field in the certificate.
xauth_login [string];
Specifies the login to use in client-side Hybrid authentication. It is available only
if racoon(8) has been built with this option. The associated password is looked up in
the pre-shared key files, using the login string as the key id.
peers_identifier idtype ...;
Specifies the peer's identifier to be received. If it is not defined then racoon(8)
will not verify the peer's identifier in ID payload transmitted from the peer. If it
is defined, the behavior of the verification depends on the flag of verify_identifier.
The usage of idtype is the same as my_identifier except that the individual component
values of an asn1dn identifier may specified as * to match any value (e.g. "C=XX,
O=MyOrg, OU=*, CN=Mine"). Alternative acceptable peer identifiers may be specified by
repeating the peers_identifier statement.
verify_identifier (on | off);
If you want to verify the peer's identifier, set this to on. In this case, if the
value defined by peers_identifier is not the same as the peer's identifier in the ID
payload, the negotiation will fail. The default is off.
certificate_type certspec;
Specifies a certificate specification. certspec must be as follows:
x509 in_keychain keychain_identifier;
in_keychain means the certificate is in the system keychain.
keychain_identifier is the keychain ID for the certificate in base64 format.
certificate_verification verification_spec;
Specifies how the certificate is verified. This is required. verification_spec must be
as follows:
sec_framework use_peers_identifier;
sec_framework means the certificate is verified by the security framework.
use_peers_identifier means the certificate must contain the peers ID.
mode_cfg (on | off);
Gather network information through ISAKMP mode configuration. Default is off.
weak_phase1_check (on | off);
Tells racoon to act on unencrypted deletion messages during phase 1. This is a small
security risk, so the default is off, meaning that racoon will keep on trying to estab-lish establish
lish a connection even if the user credentials are wrong, for instance.
send_cert (on | off);
If you do not want to send a certificate, set this to off. The default is on.
send_cr (on | off);
If you do not want to send a certificate request, set this to off. The default is on.
verify_cert (on | off);
By default, the identifier sent by the remote host (as specified in its my_identifier
statement) is compared with the credentials in the certificate used to authenticate the
remote host as follows:
Type asn1dn:
The entire certificate subject name is compared with the identifier, e.g.
"C=XX, O=YY, ...".
Type address, fqdn, or user_fqdn:
The certificate's subjectAltName is compared with the identifier.
If the two do not match the negotiation will fail. If you do not want to verify the
identifier using the peer's certificate, set this to off.
lifetime time number timeunit;
Define a lifetime of a certain time which will be proposed in the phase 1 negotiations.
Any proposal will be accepted, and the attribute(s) will not be proposed to the peer if
you do not specify it (them). They can be individually specified in each proposal.
ike_frag (on | off | force);
Enable receiver-side IKE fragmentation if racoon(8) has been built with this feature.
If set to on, racoon will advertise itself as being capable of receiving packets split
by IKE fragmentation. This extension is there to work around broken firewalls that do
not work with fragmented UDP packets. IKE fragmentation is always enabled on the
sender-side, and it is used if the peer advertises itself as IKE fragmentation capable.
By selecting force, IKE Fragmentation will be used when racoon is acting as the initia-tor initiator
tor even before the remote peer has advertised itself as IKE fragmentation capable.
esp_frag fraglen;
This option is only relevant if you use NAT traversal in tunnel mode. Its purpose is
to work around broken DSL routers that reject UDP fragments, by fragmenting the IP
packets before ESP encapsulation. The result is ESP over UDP of fragmented packets
instead of fragmented ESP over UDP packets (i.e., IP:UDP:ESP:frag(IP) instead of
frag(IP:UDP:ESP:IP)). fraglen is the maximum size of the fragments. 552 should work
anywhere, but the higher fraglen is, the better the performance.
Note that because PMTU discovery is broken on many sites, you will have to use MSS
clamping if you want TCP to work correctly.
initial_contact (on | off);
Enable this to send an INITIAL-CONTACT message. The default value is on. This message
is useful only when the responder implementation chooses an old SA when there are mul-tiple multiple
tiple SAs with different established time and the initiator reboots. If racoon did not
send the message, the responder would use an old SA even when a new SA was established.
For systems that use a KAME derived IPSEC stack, the sysctl(8) variable net.key.pre-ferred_oldsa net.key.preferred_oldsa
ferred_oldsa can be used to control this preference. When the value is zero, the stack
always uses a new SA.
passive (on | off);
If you do not want to initiate the negotiation, set this to on. The default value is
off. It is useful for a server.
proposal_check level;
Specifies the action of lifetime length, key length and PFS of the phase 2 selection on
the responder side, and the action of lifetime check in phase 1. The default level is
strict. If the level is:
obey The responder will obey the initiator anytime.
strict If the responder's lifetime length is longer than the initiator's or the
responder's key length is shorter than the initiator's, the responder will use
the initiator's value. Otherwise, the proposal will be rejected. If PFS is
not required by the responder, the responder will obey the proposal. If PFS is
required by both sides and the responder's group is not equal to the initia-tor's, initiator's,
tor's, then the responder will reject the proposal.
claim If the responder's lifetime length is longer than the initiator's or the
responder's key length is shorter than the initiator's, the responder will use
the initiator's value. If the responder's lifetime length is shorter than the
initiator's, the responder uses its own length AND sends a RESPONDER-LIFETIME
notify message to an initiator in the case of lifetime (phase 2 only). For
PFS, this directive behaves the same as strict.
exact If the initiator's lifetime or key length is not equal to the responder's, the
responder will reject the proposal. If PFS is required by both sides and the
responder's group is not equal to the initiator's, then the responder will
reject the proposal.
support_proxy (on | off);
If this value is set to on, then both values of ID payloads in the phase 2 exchange are
always used as the addresses of end-point of IPsec-SAs. The default is off.
generate_policy (on | off | require | unique);
This directive is for the responder. Therefore you should set passive to on in order
that racoon(8) only becomes a responder. If the responder does not have any policy in
SPD during phase 2 negotiation, and the directive is set to on, then racoon(8) will
choose the first proposal in the SA payload from the initiator, and generate policy
entries from the proposal. It is useful to negotiate with clients whose IP address is
allocated dynamically. Note that an inappropriate policy might be installed into the
responder's SPD by the initiator, so other communications might fail if such policies
are installed due to a policy mismatch between the initiator and the responder. on and
require values mean the same thing (generate a require policy). unique tells racoon to
set up unique policies, with a monotoning increasing reqid number (between 1 and
IPSEC_MANUAL_REQID_MAX). This directive is ignored in the initiator case. The default
value is off.
nat_traversal (on | off | force);
This directive enables use of the NAT-Traversal IPsec extension (NAT-T). NAT-T allows
one or both peers to reside behind a NAT gateway (i.e., doing address- or port-transla-tion). port-translation).
tion). If a NAT gateway is detected during the phase 1 handshake, racoon will attempt
to negotiate the use of NAT-T with the remote peer. If the negotiation succeeds, all
ESP and AH packets for the given connection will be encapsulated into UDP datagrams
(port 4500, by default). Possible values are:
on NAT-T is used when a NAT gateway is detected between the peers.
off NAT-T is not proposed/accepted. This is the default.
force NAT-T is used regardless of whether a NAT gateway is detected between the peers
or not.
Please note that NAT-T support is a compile-time option. Although it is enabled in the
source distribution by default, it may not be available in your particular build. In
that case you will get a warning when using any NAT-T related config options.
dpd_delay delay;
This option activates the DPD and sets the time (in seconds) allowed between 2 proof of
liveliness requests. The default value is 0, which disables DPD monitoring, but still
negotiates DPD support.
dpd_retry delay;
If dpd_delay is set, this sets the delay (in seconds) to wait for a proof of liveliness
before considering it as failed and send another request. The default value is 5.
dpd_maxfail number;
If dpd_delay is set, this sets the maximum number of liveliness proofs to request
(without reply) before considering the peer is dead. The default value is 5.
nonce_size number;
define the byte size of nonce value. Racoon can send any value although RFC2409 speci-fies specifies
fies that the value MUST be between 8 and 256 bytes. The default size is 16 bytes.
ph1id number;
An optionnal number to identify the remote proposal and to link it only with sainfos
who have the same number. Defaults to 0.
proposal { sub-substatements }
encryption_algorithm algorithm;
Specifies the encryption algorithm used for the phase 1 negotiation. This
directive must be defined. algorithm is one of following: des, 3des, aes for
Oakley. For other transforms, this statement should not be used.
hash_algorithm algorithm;
Defines the hash algorithm used for the phase 1 negotiation. This directive
must be defined. algorithm is one of following: md5, sha1, sha256, sha384,
sha512 for Oakley.
authentication_method type;
Defines the authentication method used for the phase 1 negotiation. This
directive must be defined. type is one of: pre_shared_key, hybrid_rsa_server,
hybrid_rsa_client, xauth_rsa_server, xauth_rsa_client, xauth_psk_server or
xauth_psk_client, eap_psk_client, eap_rsa_client.
dh_group group;
Defines the group used for the Diffie-Hellman exponentiations. This directive
must be defined. group is one of following: modp1024, modp1536, modp2048,
modp3072, modp4096, modp6144 or modp8192. Or you can define 2 , 5 , 14 , 15 ,
16 , 17 or 18 as the DH group number. When you want to use aggressive mode,
you must define the same DH group in each proposal.
lifetime time number timeunit;
Defines the lifetime of the phase 1 SA proposal. Refer to the description of
the lifetime directive defined in the remote directive.
Policy Specifications
The policy directive is obsolete, policies are now in the SPD. racoon(8) will obey the policy config-ured configured
ured into the kernel by setkey(8), and will construct phase 2 proposals by combining sainfo specifica-tions specifications
tions in racoon.conf, and policies in the kernel.
Sainfo Specifications
sainfo (source_id destination_id | source_id anonymous | anonymous destination_id | anonymous) [from
idtype [string]] [group string] { statements }
defines the parameters of the IKE phase 2 (IPsec-SA establishment). source_id and
destination_id are constructed like:
address address [/ prefix] [[port]] ul_proto
or
subnet address [/ prefix] [[port]] ul_proto
or
idtype string
An id string should be expressed to match the exact value of an ID payload (source is the local
end, destination is the remote end). This is not like a filter rule. For example, if you
define 3ffe:501:4819::/48 as source_id. 3ffe:501:4819:1000:/64 will not match.
In the case of a longest prefix (selecting a single host), address instructs to send ID type of
ADDRESS while subnet instructs to send ID type of SUBNET. Otherwise, these instructions are
identical.
The group keyword allows an XAuth group membership check to be performed for this sainfo sec-tion. section.
tion. When the mode_cfg auth source is set to system or ldap, the XAuth user is verified to be
a member of the specified group before allowing a matching SA to be negotiated.
pfs_group group;
define the group of Diffie-Hellman exponentiations. If you do not require PFS then you
can omit this directive. Any proposal will be accepted if you do not specify one.
group is one of following: modp1024, modp1536, modp2048, modp3072, modp4096, modp6144
or modp8192. Or you can define 2 , 5 , 14 , 15 , 16 , 17 or 18 as the DH group number.
lifetime time number timeunit;
define how long an IPsec-SA will be used, in timeunits. Any proposal will be accepted,
and no attribute(s) will be proposed to the peer if you do not specify it(them). See
the proposal_check directive.
remoteid number;
Sainfos will only be used if their remoteid matches the ph1id of the remote section
used for phase 1. Defaults to 0, which is also the default for ph1id.
my_identifier idtype ...;
is obsolete. It does not make sense to specify an identifier in the phase 2.
racoon(8) does not have a list of security protocols to be negotiated. The list of security
protocols are passed by SPD in the kernel. Therefore you have to define all of the potential
algorithms in the phase 2 proposals even if there are algorithms which will not be used. These
algorithms are define by using the following three directives, with a single comma as the sepa-rator. separator.
rator. For algorithms that can take variable-length keys, algorithm names can be followed by a
key length, like ``blowfish 448''. racoon(8) will compute the actual phase 2 proposals by com-puting computing
puting the permutation of the specified algorithms, and then combining them with the security
protocol specified by the SPD. For example, if des, 3des, hmac_md5, and hmac_sha1 are speci-fied specified
fied as algorithms, we have four combinations for use with ESP, and two for AH. Then, based on
the SPD settings, racoon(8) will construct the actual proposals. If the SPD entry asks for ESP
only, there will be 4 proposals. If it asks for both AH and ESP, there will be 8 proposals.
Note that the kernel may not support the algorithm you have specified.
encryption_algorithm algorithms;
des, 3des, des_iv64, des_iv32, null_enc ,rijndael, aes (used with ESP)
authentication_algorithm algorithms;
des, 3des, des_iv64, des_iv32, hmac_md5, hmac_sha1, hmac_sha256, hmac_sha384,
hmac_sha512, non_auth (used with ESP authentication and AH)
compression_algorithm algorithms;
deflate (used with IPComp)
Logging level
log level;
Defines the logging level. level is one of following: error, warning, notify, info, debug and
debug2. The default is info. If you set the logging level too high on slower machines, IKE
negotiation can fail due to timing constraint changes.
Specifies the way to pad
padding { statements }
specifies the padding format. The following are valid statements:
randomize (on | off);
Enables the use of a randomized value for padding. The default is on.
randomize_length (on | off);
The pad length will be random. The default is off.
maximum_length number;
Defines a maximum padding length. If randomize_length is off, this is ignored. The
default is 20 bytes.
exclusive_tail (on | off);
Means to put the number of pad bytes minus one into the last part of the padding. The
default is on.
strict_check (on | off);
Means to constrain the peer to set the number of pad bytes. The default is off.
Special directives
complex_bundle (on | off);
defines the interpretation of proposal in the case of SA bundle. Normally ``IP AH ESP IP
payload'' is proposed as ``AH tunnel and ESP tunnel''. The interpretation is more common to
other IKE implementations, however, it allows very limited set of combinations for proposals.
With the option enabled, it will be proposed as ``AH transport and ESP tunnel''. The default
value is off.
Pre-shared key File
The pre-shared key file defines pairs of identifiers and corresponding shared secret keys which are
used in the pre-shared key authentication method in phase 1. The pair in each line is separated by
some number of blanks and/or tab characters like in the hosts(5) file. Key can include blanks because
everything after the first blanks is interpreted as the secret key. Lines starting with `#' are
ignored. Keys which start with `0x' are interpreted as hexadecimal strings. Note that the file must
be owned by the user ID running racoon(8) (usually the privileged user), and must not be accessible by
others.
EXAMPLES
The following shows how the remote directive should be configured.
path pre_shared_key "/usr/local/v6/etc/psk.txt" ;
remote anonymous
{
exchange_mode aggressive,main,base;
lifetime time 24 hour;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 2;
}
}
sainfo anonymous
{
pfs_group 2;
lifetime time 12 hour ;
encryption_algorithm 3des, aes ;
authentication_algorithm hmac_sha1, hmac_md5 ;
compression_algorithm deflate ;
}
The following is a sample for the pre-shared key file.
10.160.94.3 mekmitasdigoat
172.16.1.133 0x12345678
194.100.55.1 whatcertificatereally
3ffe:501:410:ffff:200:86ff:fe05:80fa mekmitasdigoat
3ffe:501:410:ffff:210:4bff:fea2:8baa mekmitasdigoat
foo@kame.net mekmitasdigoat
foo.kame.net hoge
SEE ALSO
racoon(8), racoonctl(8), setkey(8)
HISTORY
The racoon.conf configuration file first appeared in the ``YIPS'' Yokogawa IPsec implementation.
BUGS
Some statements may not be handled by racoon(8) yet.
Diffie-Hellman computation can take a very long time, and may cause unwanted timeouts, specifically
when a large D-H group is used.
SECURITY CONSIDERATIONS
The use of IKE phase 1 aggressive mode is not recommended, as described in
http://www.kb.cert.org/vuls/id/886601.
BSD September 19, 2006 BSD
|
Сообщение о проблемах
Способ сообщить о проблеме с этой страницей руководства зависит от типа проблемы:
- Ошибки содержания
- Ошибки отчета в содержании этой документации со ссылками на отзыв ниже.
- Отчеты об ошибках
- Сообщите об ошибках в функциональности описанного инструмента или API через Генератор отчетов Ошибки.
- Форматирование проблем
- Отчет, форматирующий ошибки в интерактивной версии этих страниц со ссылками на отзыв ниже.