ISAKMPD.CONF(5) OpenBSD Programmer's Manual ISAKMPD.CONF(5)
NAME
isakmpd.conf - configuration file for isakmpd
DESCRIPTION
isakmpd.conf is the configuration file for the isakmpd(8) daemon,
managing security association and key management for the IPsec layer of
the kernel's networking stack.
The file is of a well known type of format called .INI style, named after
the suffix used by an overrated windowing environment for its
configuration files. This format consists of sections, each beginning
with a line looking like:
[Section name]
Between the brackets is the name of the section following this section
header. Inside a section many tag/value pairs can be stored, each one
looking like:
___=_____
If the value needs more space than fits on a single line, it's possible
to continue it on the next by ending the first with a backslash character
immediately before the newline character. This method can extend a value
for an arbitrary number of lines.
Comments can be put anywhere in the file by using a hash mark (`#'). The
comment extends to the end of the current line.
Often the right-hand side values consist of other section names. This
results in a tree structure. Some values are treated as a list of
several scalar values. Such lists always use a comma character as the
separator. Some values are formatted like this: X,Y:Z, which is an
offer/accept syntax, where X is a value we offer and Y:Z is a range of
accepted values, inclusive.
To activate changes to isakmpd.conf without restarting isakmpd(8), send a
SIGHUP signal to the daemon process.
AUTO-GENERATED PARTS OF THE CONFIGURATION
Some predefined section names are recognized by the daemon, avoiding the
need to fully specify the Main Mode transforms and Quick Mode suites,
protocols, and transforms.
For Main Mode:
{______}-{____}[{-_____}][-_______]
where:
{______} is either DES, BLF, 3DES, CAST, AES, AES-128, AES-192 or
AES-256
{____} is either MD5, SHA, or SHA2-{256,384,512}
{_____} is either GRP1, GRP2, GRP5, GRP14, or GRP15
For Quick Mode:
__-{_____}[-___]-{______}[-{____}][-___[-{_____}]]-_____
where:
{_____} is either ESP or AH
{______} is either DES, 3DES, CAST, BLF, AES, AES-128, AES-192,
AES-256, AESCTR, AESGCM-128, AESGCM-192, AESGCM-256,
AESGMAC-128, AESGMAC-192, AESGMAC-256 or NULL
{____} is either MD5, SHA, RIPEMD, or SHA2-{256,384,512}
{_____} is either GRP1, GRP2, GRP5, GRP14, or GRP15
For example, AES-SHA2-256 means: AES encryption, SHA2-256 hash, and
authorization by pre-shared keys. Adding "-RSA_SIG" will enable public
key authentication, e.g. AES-SHA2-256-RSA_SIG. Similarly, QM-ESP-3DES-
SHA-PFS-SUITE means: ESP protocol, 3DES encryption, SHA hash, and use
Perfect Forward Secrecy.
Unless explicitly stated with -GRP1, 2, 5, 14 or 15, transforms and PFS
suites use DH group 2. There are currently no predefined ESP+AH Quick
Mode suites.
The predefinitions include some default values for the special sections
"General", "Keynote", "X509-certificates", and "Default-phase-1-
configuration". These default values are presented in the example below.
All autogenerated values can be overridden by manual entries by using the
same section and tag names in the configuration file. In particular, the
default phase 1 (Main or Aggressive Mode) and phase 2 (Quick Mode)
lifetimes can be overridden by these tags under the "General" section:
[General]
Default-phase-1-lifetime= 3600,60:86400
Default-phase-2-lifetime= 1200,60:86400
The Main Mode lifetime currently defaults to one hour (minimum 60
seconds, maximum 1 day). The Quick Mode lifetime defaults to 20 minutes
(minimum 60 seconds, maximum 1 day).
Also, the default phase 1 ID can be set by creating a <Phase1-ID>
section, as shown below, and adding this tag under the "General" section:
[General]
Default-phase-1-ID= Phase1-ID-name
[Phase1-ID-name]
ID-type= USER_FQDN
Name= foo@bar.com
ROOTS
[General] Generic global configuration parameters
____________
If this tag is defined, isakmpd(8) will not set up
flows automatically. This is useful when flows are
configured with ipsecctl(8) or by other programs like
bgpd(8). Thus isakmpd(8) only takes care of the SA
establishment.
______________
The interval between watchdog checks of connections we
want up at all times, in seconds. The default value is
60 seconds.
__________________
Optional default phase 1 ID name.
________________________
The default lifetime for autogenerated transforms
(phase 1). If unspecified, the value 3600,60:86400 is
used as the default.
________________________
The default lifetime for autogenerated suites (phase
2). If unspecified, the value 1200,60:86400 is used as
the default.
______________________
A list of phase 2 suites that will be used when
establishing dynamic SAs. If left unspecified, QM-ESP-
3DES-SHA-PFS-SUITE is used as the default.
__________________
The interval between RFC 3706 (Dead Peer Detection)
messages, in seconds. The default value is 0 (zero),
which means DPD is disabled.
_________________
How many seconds should an exchange maximally take to
set up before we give up.
_________
A list of IP addresses or interface names OK to listen
on. This list is used as a filter for the set of
addresses the interfaces configured provides. This
means that we won't see if an address given here does
not exist on this host, and thus no error is given for
that case.
________
A list of the form _____=_____, where both _____ and
_____ are numbers. This is similar to the -D command
line switch of isakmpd(8).
__________
If this tag is defined, whatever the value is, verbose
logging is enabled. This is similar to the -v command
line switch of isakmpd(8).
_______________
The number of seconds between NAT-T keepalive messages,
sent by the peer behind NAT to keep the mapping active.
Defaults to 20.
___________
The name of the file that contains keynote(4) policies.
The default is ___________________________.
________________
The directory in which isakmpd.conf looks for
explicitly trusted public keys. The default is
____________________. Read isakmpd(8) for the required
naming convention of the files in here.
__________________
If this tag is defined, whatever the value is,
isakmpd(8) will renegotiate all current phase 2 SAs
when the daemon receives a SIGHUP signal, or an `R' is
sent to the FIFO interface (see isakmpd(8)).
___________
How many times should a message be retransmitted before
giving up.
___________
If this tag is defined, whatever the value is, some
semantics of isakmpd.conf are changed so that multiple
instances can run on top of one SADB and set up SAs
with each other. Specifically this means replay
protection will not be asked for, and errors that can
occur when updating an SA with its parameters a 2nd
time will be ignored.
___________
This tag controls the use of keynote(4) policy
checking. The default value is "yes", which enables
the policy checking. When set to any other value,
policies will not be checked. This is useful when
policies for flows and SA establishment are arranged by
other programs like ipsecctl(8) or bgpd(8).
[Phase 1] ISAKMP SA negotiation parameter root
_______
A name of the default ISAKMP peer. Incoming phase 1
connections from other IP addresses will use this peer
name. This name is used as the section name for
further information to be found. Look at <ISAKMP-peer>
below.
<__________>
A name of the ISAKMP peer at the given IP address.
[Phase 2] IPsec SA negotiation parameter root
___________
A list of directed IPsec "connection" names that should
be brought up automatically, either on first use if the
system supports it, or at startup of the daemon. These
names are section names where further information can
be found. Look at <IPsec-connection> below. Normally
any connections mentioned here are treated as part of
the "Passive-connection" list we present below; however
there is a flag, ___________, that disables this
behaviour. This too is mentioned in the
<IPsec-connection> section, in the "Flags" tag.
___________________
A list of IPsec "connection" names we recognize and
accept initiations for. These names are section names
where further information can be found. Look at
<IPsec-connection> below. Currently only the Local-ID
and Remote-ID tags are looked at in those sections, as
they are matched against the IDs given by the
initiator.
[KeyNote] KeyNote configuration section
____________________
A directory containing directories named after IDs (IP
addresses, ``user@domain'', or hostnames) that contain
files named ``credentials'' and ``private_key''.
The credentials file contains keynote(4) credentials
that are sent to a remote IKE daemon when we use the
associated ID, or credentials that we may want to
consider when doing an exchange with a remote IKE
daemon that uses that ID. Note that, in the former
case, the last credential in the file MUST contain our
public key in its Licensees field. More than one
credentials may exist in the file. They are separated
by whitelines (the format is essentially the same as
that of the policy file). The credentials are of the
same format as the policies described in
isakmpd.policy(5). The only difference is that the
Authorizer field contains a public key, and the
assertion is signed. Signed assertions can be
generated using the keynote(1) utility.
The private_key file contains the private RSA key we
use for authentication. If the directory (and the
files) exist, they take precedence over X509-based
authentication.
[X509-Certificates] X509-certificate configuration section
__________________
If this tag is defined, whatever the value is,
certificates that do not originate from a trusted CA
but are self-signed will be accepted.
____________
A directory containing PEM certificates of
certification authorities that we trust to sign other
certificates. Note that for a CA to be really trusted,
it needs to be somehow referred to by policy, in
isakmpd.policy(5). The certificates in this directory
are used for the actual X.509 authentication and for
cross-referencing policies that refer to Distinguished
Names (DNs). Keeping a separate directory (as opposed
to integrating policies and X.509 CA certificates)
allows for maintenance of a list of "well known" CAs
without actually having to trust all (or any) of them.
______________
A directory containing PEM certificates that we trust
to be valid. These certificates are used in preference
to those passed in messages and are required to have a
subjectAltName extension containing the certificate
holder identity; usually IP address, FQDN, or User
FQDN.
___________
The private key matching the public key of our
certificate (which should be in the "Cert-directory",
and have an appropriate subjectAltName field).
_____________________
A directory containing private keys named after an ID
(IP addresses, ``user@domain'', or hostnames).
REFERRED-TO SECTIONS
Parameters for negotiation with an ISAKMP peer
_______
If existent, the IP address of the peer.
______________
If existent, authentication data for this specific peer.
In the case of a pre-shared key, this is the key value
itself.
_____________
The name of the ISAKMP-configuration section to use.
Look at <ISAKMP-configuration> below. If unspecified,
defaults to "Default-phase-1-configuration".
_____ A comma-separated list of flags controlling the further
handling of the ISAKMP SA. Currently there are no
specific ISAKMP SA flags defined.
__ If existent, the name of the section that describes the
local client ID that we should present to our peer. If
not present, it defaults to the address of the local
interface we are sending packets over to the remote
daemon. Look at <Phase1-ID> below.
_____________
The Local IP address to use, if we are multi-homed, or
have aliases.
_____ The constant `1', as ISAKMP-peers and IPsec-connections
really are handled by the same code inside isakmpd(8).
____ For UDP, the UDP port number to send to. This is
optional; the default value is 500 which is the IANA-
registered number for ISAKMP.
_________
If existent, the name of the section that describes the
remote client ID we expect the remote daemon to send us.
If not present, it defaults to the address of the remote
daemon. Look at <Phase1-ID> below.
_________
The name of the transport protocol; defaults to UDP.
<Phase1-ID> Parameters for Phase 1 negotiation
_______
If the ID-type is IPV4_ADDR or IPV6_ADDR, this tag should
exist and be an IP address.
_______
The ID type as given by the RFC specifications. For
phase 1 this is currently IPV4_ADDR, IPV4_ADDR_SUBNET,
IPV6_ADDR, IPV6_ADDR_SUBNET, FQDN, USER_FQDN, or KEY_ID.
____ If the ID-type is FQDN, USER_FQDN, or KEY_ID, this tag
should exist and contain a domain name, user@domain, or
other identifying string respectively.
In the case of KEY_ID, note that the IKE protocol allows
any octet sequence to be sent or received under this
payload, potentially including non-printable ones.
isakmpd(8) can only transmit printable KEY_ID payloads,
but can receive and process arbitrary KEY_ID payloads.
This effectively means that non-printable KEY_ID remote
identities cannot be verified through this means,
although it is still possible to do so through
isakmpd.policy(5).
_______
If the ID-type is IPV4_ADDR_SUBNET or IPV6_ADDR_SUBNET,
this tag should exist and be a network subnet mask.
_______
If the ID-type is IPV4_ADDR_SUBNET or IPV6_ADDR_SUBNET,
this tag should exist and be a network address.
<ISAKMP-configuration> Parameters for ISAKMP configuration
___ The domain of interpretation as given by the RFCs.
Normally IPSEC. If unspecified, defaults to IPSEC.
_____________
The exchange type as given by the RFCs. For main mode
this is ID_PROT and for aggressive mode it is AGGRESSIVE.
__________
A list of proposed transforms to use for protecting the
ISAKMP traffic. These are actually names for sections
further describing the transforms. Look at
<ISAKMP-transform> below.
<ISAKMP-transform> Parameters for ISAKMP authentication
_____________________
The authentication method as the RFCs name it, or ANY.
____________________
The encryption algorithm as the RFCs name it, or ANY to
denote that any encryption algorithm proposed will be
accepted.
_________________
The group used for Diffie-Hellman exponentiations, or
ANY. The names are symbolic, like MODP_768, MODP_1024,
EC_155, and EC_185.
______________
The hash algorithm as the RFCs name it, or ANY.
__________
For encryption algorithms with variable key length, this
is where the offered/accepted keylengths are described.
The value is of the offer-accept kind described above.
____ A list of lifetime descriptions, or ANY. In the former
case, each element is in itself a name of the section
that defines the lifetime. Look at <Lifetime> below. If
it is set to ANY, then any type of proposed lifetime type
and value will be accepted.
___ The algorithm to use for the keyed pseudo-random function
(used for key derivation and authentication in phase 1),
or ANY.
<Lifetime> Parameters for connection duration
_____________
An offer/accept kind of value; see above. Can also be
set to ANY.
_________
SECONDS or KILOBYTES depending on the type of the
duration. Notice that this field may NOT be set to ANY.
<IPsec-connection> Parameters for IPsec connection configuration
_____________
The name of the IPsec-configuration section to use. Look
at <IPsec-configuration> below.
_____ A comma-separated list of flags controlling the further
handling of the IPsec SA. Currently only one flag is
defined:
___________ If this flag is given and this
<IPsec-connection> is part of the phase 2
connections we automatically keep up, it
will not automatically be used for
accepting connections from the peer.
___________
The name of the ISAKMP-peer to talk to in order to set up
this connection. The value is the name of an
<ISAKMP-peer> section. See above.
________
If existent, the name of the section that describes the
optional local client ID that we should present to our
peer. It is also used when we act as responders to find
out what <IPsec-connection> we are dealing with. Look at
<IPsec-ID> below.
_____ The constant `2', as ISAKMP-peers and IPsec-connections
really are handled by the same code inside isakmpd(8).
_________
If existent, the name of the section that describes the
optional remote client ID that we should present to our
peer. It is also used when we act as responders to find
out what <IPsec-connection> we are dealing with. Look at
<IPsec-ID> below.
______ Add a pf(4) tag to all packets of phase 2 SAs created for
this connection. This will allow matching packets for
this connection by defining rules in pf.conf(5) using the
______ keyword.
The following variables can be used in tags to include
information from the remote peer on runtime:
___ The remote phase 1 ID. It will be
expanded to ________________, e.g.
________________.
_______ Extract the domain from IDs of type FQDN
or UFQDN.
For example, if the ID is ________________ or
__________________, ``PF-Tag=ipsec-$domain'' expands to
``ipsec-bar.org''. The variable expansion for the ______
directive occurs only at runtime, not during
configuration file parse time.
<IPsec-configuration> Parameters for IPsec configuration
___ The domain of interpretation as given by the RFCs.
Normally IPSEC. If unspecified, defaults to IPSEC.
_____________
The exchange type as given by the RFCs. For quick mode
this is QUICK_MODE.
______ A list of protection suites (bundles of protocols) usable
for protecting the IP traffic. Each of the list elements
is a name of an <IPsec-suite> section. See below.
<IPsec-suite> Parameters for IPsec protection suite configuration
_________
A list of the protocols included in this protection
suite. Each of the list elements is a name of an
<IPsec-protocol> section. See below.
<IPsec-protocol> Parameters for IPsec protocol configuration
___________
The protocol as given by the RFCs. Acceptable values are
currently IPSEC_AH and IPSEC_ESP.
____________
The size of the window used for replay protection. This
is normally left alone. Look at the ESP and AH RFCs for
a better description.
__________
A list of transforms usable for implementing the
protocol. Each of the list elements is a name of an
<IPsec-transform> section. See below.
<IPsec-transform> Parameters for IPsec transform configuration
________________________
The optional authentication algorithm in the case of this
being an ESP transform.
__________________
The encapsulation mode as given by the RFCs. This means
TRANSPORT or TUNNEL.
_________________
An optional (provides PFS if present) Diffie-Hellman
group description. The values are the same as those for
GROUP_DESCRIPTION in <ISAKMP-transform> sections shown
above.
__________
For encryption algorithms with variable key length, this
is where the offered keylength is described.
____ List of lifetimes, each element is a <Lifetime> section
name.
____________
The transform ID as given by the RFCs.
<IPsec-ID> Parameters for IPsec ID configuration
_______
If the ID-type is IPV4_ADDR or IPV6_ADDR, this tag should
exist and be an IP address, an interface name, or the
_______ keyword. If an interface is used, the first
address of the appropriate family will be used. The
_______ keyword uses the interface associated with the
default route. In the case of IPv6, link-local addresses
will be skipped if addresses which are not link-local
exist. If the address on the interface changes
isakmpd(8) will not track the change. The configuration
must be reloaded to learn the new address.
_______
The ID type as given by the RFCs. For IPsec this is
currently IPV4_ADDR, IPV6_ADDR, IPV4_ADDR_SUBNET, or
IPV6_ADDR_SUBNET.
_______
If the ID-type is IPV4_ADDR_SUBNET or IPV6_ADDR_SUBNET,
this tag should exist and be a network subnet mask or an
interface. When an interface is specified, the netmask
is the mask associated with the _______. The _______
keyword uses the interface associated with the default
route.
_______
If the ID-type is IPV4_ADDR_SUBNET or IPV6_ADDR_SUBNET,
this tag should exist and be a network address, an
interface, or the _______ keyword. When an interface is
specified, the network is selected as with the _______
tag.
____ If the ID-type is IPV4_ADDR, IPV4_ADDR_SUBNET, IPV6_ADDR,
or IPV6_ADDR_SUBNET, this tag indicates what source or
destination port is allowed to be transported over the SA
(depending on whether this is a local or remote ID). If
left unspecified, all ports of the given transport
protocol will be transmitted (or permitted) over the SA.
The ________ tag must be specified in conjunction with
this tag.
________
If the ID-type is IPV4_ADDR, IPV4_ADDR_SUBNET, IPV6_ADDR,
or IPV6_ADDR_SUBNET, this tag indicates what transport
protocol should be transmitted over the SA. If left
unspecified, all transport protocols between the two
address (ranges) will be sent (or permitted) over that
SA.
OTHER SECTIONS
Parameters to use with IKE mode-config. One ID per peer.
An IKECFG-ID is written as [<ID-type>/<name>]. The following
ID types are supported:
IPv4 [ipv4/A.B.C.D]
IPv6 [ipv6/abcd:abcd::ab:cd]
FQDN [fqdn/foo.bar.org]
UFQDN [ufqdn/user@foo.bar.org]
ASN1_DN [asn1_dn//C=aa/O=cc/...] (Note the double
slashes as the DN itself starts with a `/'.)
Each section specifies what configuration values to return to
the peer requesting IKE mode-config. Currently supported
values are:
_______ The peer's network address.
_______ The peer's netmask.
__________ The IP address of a DNS nameserver.
___________ The IP address of a WINS server.
<Initiator-ID> Parameters for peer initiator configuration
During phase 1 negotiation isakmpd(8) looks for a pre-shared
key in the <ISAKMP-peer> section. If no Authentication data is
specified in that section, and isakmpd(8) is not the initiator,
it looks for Authentication data in a section named after the
initiator's phase 1 ID. This allows mobile users with dynamic
IP addresses to have different shared secrets.
This only works for aggressive mode because in main mode the
remote initiator ID would not yet be known. Note, however,
that use of aggressive mode is discouraged. See _______,
below.
The name of the <Initiator-ID> section depends on the ID type
sent by the initiator. Currently this can be:
IPv4 [A.B.C.D]
IPv6 [abcd:abcd::ab:cd]
FQDN [foo.bar.org]
UFQDN [user@foo.bar.org]
FILES
_________ The default isakmpd(8) configuration file.
EXAMPLES
An example of a configuration file:
# A configuration sample for the isakmpd ISAKMP/Oakley (aka IKEv1) daemon.
[General]
Listen-on= 10.1.0.2
# Incoming phase 1 negotiations are multiplexed on the source IP address
[Phase 1]
10.1.0.1= ISAKMP-peer-west
# These connections are walked over after config file parsing and told
# to the application layer so that it will inform us when traffic wants to
# pass over them. This means we can do on-demand keying.
[Phase 2]
Connections= IPsec-east-west
# Default values are commented out.
[ISAKMP-peer-west]
Phase= 1
#Transport= udp
Local-address= 10.1.0.2
Address= 10.1.0.1
#Port= isakmp
#Port= 500
#Configuration= Default-phase-1-configuration
Authentication= mekmitasdigoat
#Flags=
[IPsec-east-west]
Phase= 2
ISAKMP-peer= ISAKMP-peer-west
Configuration= Default-quick-mode
Local-ID= Net-east
Remote-ID= Net-west
#Flags=
[Net-west]
ID-type= IPV4_ADDR_SUBNET
Network= 192.168.1.0
Netmask= 255.255.255.0
[Net-east]
ID-type= IPV4_ADDR_SUBNET
Network= 192.168.2.0
Netmask= 255.255.255.0
# Quick mode descriptions
[Default-quick-mode]
EXCHANGE_TYPE= QUICK_MODE
Suites= QM-ESP-3DES-SHA-PFS-SUITE,QM-ESP-AES-SHA-PFS-SUITE
# Data for an IKE mode-config peer
[asn1_dn//C=SE/L=SomeCity/O=SomeCompany/CN=SomePeer.company.com]
Address= 192.168.1.123
Netmask= 255.255.255.0
Nameserver= 192.168.1.10
WINS-server= 192.168.1.11
# pre-shared key based on initiator's phase 1 ID
[foo.bar.org]
Authentication= mekmitasdigoat
#
# #####################################################################
# All configuration data below this point is not required as the example
# uses the predefined Main Mode transform and Quick Mode suite names.
# It is included here for completeness. Note the default values for the
# [General] and [X509-certificates] sections just below.
# #####################################################################
#
[General]
Policy-file= /etc/isakmpd/isakmpd.policy
Retransmits= 3
Exchange-max-time= 120
# KeyNote credential storage
[KeyNote]
Credential-directory= /etc/isakmpd/keynote/
# Certificates stored in PEM format
[X509-certificates]
CA-directory= /etc/isakmpd/ca/
Cert-directory= /etc/isakmpd/certs/
CRL-directory= /etc/isakmpd/crls/
Private-key= /etc/isakmpd/private/local.key
# Default phase 1 description (Main Mode)
[Default-phase-1-configuration]
EXCHANGE_TYPE= ID_PROT
Transforms= 3DES-SHA
# Main mode transforms
######################
# DES
[DES-MD5]
ENCRYPTION_ALGORITHM= DES_CBC
HASH_ALGORITHM= MD5
AUTHENTICATION_METHOD= PRE_SHARED
GROUP_DESCRIPTION= MODP_1024
Life= LIFE_MAIN_MODE
[DES-SHA]
ENCRYPTION_ALGORITHM= DES_CBC
HASH_ALGORITHM= SHA
AUTHENTICATION_METHOD= PRE_SHARED
GROUP_DESCRIPTION= MODP_1024
Life= LIFE_MAIN_MODE
# 3DES
[3DES-SHA]
ENCRYPTION_ALGORITHM= 3DES_CBC
HASH_ALGORITHM= SHA
AUTHENTICATION_METHOD= PRE_SHARED
GROUP_DESCRIPTION= MODP_1024
Life= LIFE_MAIN_MODE
# AES
[AES-SHA]
ENCRYPTION_ALGORITHM= AES_CBC
KEY_LENGTH= 128,128:256
HASH_ALGORITHM= SHA
AUTHENTICATION_METHOD= PRE_SHARED
GROUP_DESCRIPTION= MODP_1024
Life= LIFE_MAIN_MODE
# AES-128
[AES-128-SHA]
ENCRYPTION_ALGORITHM= AES_CBC
KEY_LENGTH= 128,128:128
HASH_ALGORITHM= SHA
AUTHENTICATION_METHOD= PRE_SHARED
GROUP_DESCRIPTION= MODP_1024
Life= LIFE_MAIN_MODE
# AES-192
[AES-192-SHA]
ENCRYPTION_ALGORITHM= AES_CBC
KEY_LENGTH= 192,192:192
HASH_ALGORITHM= SHA
AUTHENTICATION_METHOD= PRE_SHARED
GROUP_DESCRIPTION= MODP_1024
Life= LIFE_MAIN_MODE
# AES-256
[AES-256-SHA]
ENCRYPTION_ALGORITHM= AES_CBC
KEY_LENGTH= 256,256:256
HASH_ALGORITHM= SHA
AUTHENTICATION_METHOD= PRE_SHARED
GROUP_DESCRIPTION= MODP_1024
Life= LIFE_MAIN_MODE
# Blowfish
[BLF-SHA]
ENCRYPTION_ALGORITHM= BLOWFISH_CBC
KEY_LENGTH= 128,96:192
HASH_ALGORITHM= SHA
AUTHENTICATION_METHOD= PRE_SHARED
GROUP_DESCRIPTION= MODP_1024
Life= LIFE_MAIN_MODE
# Blowfish, using DH group 4 (non-default)
[BLF-SHA-EC185]
ENCRYPTION_ALGORITHM= BLOWFISH_CBC
KEY_LENGTH= 128,96:192
HASH_ALGORITHM= SHA
AUTHENTICATION_METHOD= PRE_SHARED
GROUP_DESCRIPTION= EC2N_185
Life= LIFE_MAIN_MODE
# Quick mode protection suites
##############################
# DES
[QM-ESP-DES-SUITE]
Protocols= QM-ESP-DES
[QM-ESP-DES-PFS-SUITE]
Protocols= QM-ESP-DES-PFS
[QM-ESP-DES-MD5-SUITE]
Protocols= QM-ESP-DES-MD5
[QM-ESP-DES-MD5-PFS-SUITE]
Protocols= QM-ESP-DES-MD5-PFS
[QM-ESP-DES-SHA-SUITE]
Protocols= QM-ESP-DES-SHA
[QM-ESP-DES-SHA-PFS-SUITE]
Protocols= QM-ESP-DES-SHA-PFS
# 3DES
[QM-ESP-3DES-SHA-SUITE]
Protocols= QM-ESP-3DES-SHA
[QM-ESP-3DES-SHA-PFS-SUITE]
Protocols= QM-ESP-3DES-SHA-PFS
# AES
[QM-ESP-AES-SHA-SUITE]
Protocols= QM-ESP-AES-SHA
[QM-ESP-AES-SHA-PFS-SUITE]
Protocols= QM-ESP-AES-SHA-PFS
# AES-128
[QM-ESP-AES-128-SHA-SUITE]
Protocols= QM-ESP-AES-128-SHA
[QM-ESP-AES-128-SHA-PFS-SUITE]
Protocols= QM-ESP-AES-128-SHA-PFS
# AES-192
[QM-ESP-AES-192-SHA-SUITE]
Protocols= QM-ESP-AES-192-SHA
[QM-ESP-AES-192-SHA-PFS-SUITE]
Protocols= QM-ESP-AES-192-SHA-PFS
# AES-256
[QM-ESP-AES-256-SHA-SUITE]
Protocols= QM-ESP-AES-256-SHA
[QM-ESP-AES-256-SHA-PFS-SUITE]
Protocols= QM-ESP-AES-256-SHA-PFS
# AH
[QM-AH-MD5-SUITE]
Protocols= QM-AH-MD5
[QM-AH-MD5-PFS-SUITE]
Protocols= QM-AH-MD5-PFS
# AH + ESP (non-default)
[QM-AH-MD5-ESP-DES-SUITE]
Protocols= QM-AH-MD5,QM-ESP-DES
[QM-AH-MD5-ESP-DES-MD5-SUITE]
Protocols= QM-AH-MD5,QM-ESP-DES-MD5
[QM-ESP-DES-MD5-AH-MD5-SUITE]
Protocols= QM-ESP-DES-MD5,QM-AH-MD5
# Quick mode protocols
# DES
[QM-ESP-DES]
PROTOCOL_ID= IPSEC_ESP
Transforms= QM-ESP-DES-XF
[QM-ESP-DES-MD5]
PROTOCOL_ID= IPSEC_ESP
Transforms= QM-ESP-DES-MD5-XF
[QM-ESP-DES-MD5-PFS]
PROTOCOL_ID= IPSEC_ESP
Transforms= QM-ESP-DES-MD5-PFS-XF
[QM-ESP-DES-SHA]
PROTOCOL_ID= IPSEC_ESP
Transforms= QM-ESP-DES-SHA-XF
# 3DES
[QM-ESP-3DES-SHA]
PROTOCOL_ID= IPSEC_ESP
Transforms= QM-ESP-3DES-SHA-XF
[QM-ESP-3DES-SHA-PFS]
PROTOCOL_ID= IPSEC_ESP
Transforms= QM-ESP-3DES-SHA-PFS-XF
[QM-ESP-3DES-SHA-TRP]
PROTOCOL_ID= IPSEC_ESP
Transforms= QM-ESP-3DES-SHA-TRP-XF
# AES
[QM-ESP-AES-SHA]
PROTOCOL_ID= IPSEC_ESP
Transforms= QM-ESP-AES-SHA-XF
[QM-ESP-AES-SHA-PFS]
PROTOCOL_ID= IPSEC_ESP
Transforms= QM-ESP-AES-SHA-PFS-XF
[QM-ESP-AES-SHA-TRP]
PROTOCOL_ID= IPSEC_ESP
Transforms= QM-ESP-AES-SHA-TRP-XF
# AES-128
[QM-ESP-AES-128-SHA]
PROTOCOL_ID= IPSEC_ESP
Transforms= QM-ESP-AES-128-SHA-XF
[QM-ESP-AES-128-SHA-PFS]
PROTOCOL_ID= IPSEC_ESP
Transforms= QM-ESP-AES-128-SHA-PFS-XF
[QM-ESP-AES-128-SHA-TRP]
PROTOCOL_ID= IPSEC_ESP
Transforms= QM-ESP-AES-128-SHA-TRP-XF
# AES-192
[QM-ESP-AES-192-SHA]
PROTOCOL_ID= IPSEC_ESP
Transforms= QM-ESP-AES-192-SHA-XF
[QM-ESP-AES-192-SHA-PFS]
PROTOCOL_ID= IPSEC_ESP
Transforms= QM-ESP-AES-192-SHA-PFS-XF
[QM-ESP-AES-192-SHA-TRP]
PROTOCOL_ID= IPSEC_ESP
Transforms= QM-ESP-AES-192-SHA-TRP-XF
# AES-256
[QM-ESP-AES-256-SHA]
PROTOCOL_ID= IPSEC_ESP
Transforms= QM-ESP-AES-256-SHA-XF
[QM-ESP-AES-256-SHA-PFS]
PROTOCOL_ID= IPSEC_ESP
Transforms= QM-ESP-AES-256-SHA-PFS-XF
[QM-ESP-AES-256-SHA-TRP]
PROTOCOL_ID= IPSEC_ESP
Transforms= QM-ESP-AES-256-SHA-TRP-XF
# AH MD5
[QM-AH-MD5]
PROTOCOL_ID= IPSEC_AH
Transforms= QM-AH-MD5-XF
[QM-AH-MD5-PFS]
PROTOCOL_ID= IPSEC_AH
Transforms= QM-AH-MD5-PFS-XF
# Quick mode transforms
# ESP DES+MD5
[QM-ESP-DES-XF]
TRANSFORM_ID= DES
ENCAPSULATION_MODE= TUNNEL
Life= LIFE_QUICK_MODE
[QM-ESP-DES-MD5-XF]
TRANSFORM_ID= DES
ENCAPSULATION_MODE= TUNNEL
AUTHENTICATION_ALGORITHM= HMAC_MD5
Life= LIFE_QUICK_MODE
[QM-ESP-DES-MD5-PFS-XF]
TRANSFORM_ID= DES
ENCAPSULATION_MODE= TUNNEL
GROUP_DESCRIPTION= MODP_1024
AUTHENTICATION_ALGORITHM= HMAC_MD5
Life= LIFE_QUICK_MODE
[QM-ESP-DES-SHA-XF]
TRANSFORM_ID= DES
ENCAPSULATION_MODE= TUNNEL
AUTHENTICATION_ALGORITHM= HMAC_SHA
Life= LIFE_QUICK_MODE
# 3DES
[QM-ESP-3DES-SHA-XF]
TRANSFORM_ID= 3DES
ENCAPSULATION_MODE= TUNNEL
AUTHENTICATION_ALGORITHM= HMAC_SHA
Life= LIFE_QUICK_MODE
[QM-ESP-3DES-SHA-PFS-XF]
TRANSFORM_ID= 3DES
ENCAPSULATION_MODE= TUNNEL
AUTHENTICATION_ALGORITHM= HMAC_SHA
GROUP_DESCRIPTION= MODP_1024
Life= LIFE_QUICK_MODE
[QM-ESP-3DES-SHA-TRP-XF]
TRANSFORM_ID= 3DES
ENCAPSULATION_MODE= TRANSPORT
AUTHENTICATION_ALGORITHM= HMAC_SHA
Life= LIFE_QUICK_MODE
# AES
[QM-ESP-AES-SHA-XF]
TRANSFORM_ID= AES
ENCAPSULATION_MODE= TUNNEL
AUTHENTICATION_ALGORITHM= HMAC_SHA
KEY_LENGTH= 128
Life= LIFE_QUICK_MODE
[QM-ESP-AES-SHA-PFS-XF]
TRANSFORM_ID= AES
ENCAPSULATION_MODE= TUNNEL
AUTHENTICATION_ALGORITHM= HMAC_SHA
GROUP_DESCRIPTION= MODP_1024
KEY_LENGTH= 128
Life= LIFE_QUICK_MODE
[QM-ESP-AES-SHA-TRP-XF]
TRANSFORM_ID= AES
ENCAPSULATION_MODE= TRANSPORT
AUTHENTICATION_ALGORITHM= HMAC_SHA
KEY_LENGTH= 128
Life= LIFE_QUICK_MODE
# AES-128
[QM-ESP-AES-128-SHA-XF]
TRANSFORM_ID= AES
ENCAPSULATION_MODE= TUNNEL
AUTHENTICATION_ALGORITHM= HMAC_SHA
KEY_LENGTH= 128
Life= LIFE_QUICK_MODE
[QM-ESP-AES-128-SHA-PFS-XF]
TRANSFORM_ID= AES
ENCAPSULATION_MODE= TUNNEL
AUTHENTICATION_ALGORITHM= HMAC_SHA
GROUP_DESCRIPTION= MODP_1024
KEY_LENGTH= 128
Life= LIFE_QUICK_MODE
[QM-ESP-AES-128-SHA-TRP-XF]
TRANSFORM_ID= AES
ENCAPSULATION_MODE= TRANSPORT
AUTHENTICATION_ALGORITHM= HMAC_SHA
KEY_LENGTH= 128
Life= LIFE_QUICK_MODE
# AES-192
[QM-ESP-AES-192-SHA-XF]
TRANSFORM_ID= AES
ENCAPSULATION_MODE= TUNNEL
AUTHENTICATION_ALGORITHM= HMAC_SHA
KEY_LENGTH= 192
Life= LIFE_QUICK_MODE
[QM-ESP-AES-192-SHA-PFS-XF]
TRANSFORM_ID= AES
ENCAPSULATION_MODE= TUNNEL
AUTHENTICATION_ALGORITHM= HMAC_SHA
GROUP_DESCRIPTION= MODP_1024
KEY_LENGTH= 192
Life= LIFE_QUICK_MODE
[QM-ESP-AES-192-SHA-TRP-XF]
TRANSFORM_ID= AES
ENCAPSULATION_MODE= TRANSPORT
AUTHENTICATION_ALGORITHM= HMAC_SHA
KEY_LENGTH= 192
Life= LIFE_QUICK_MODE
# AES-256
[QM-ESP-AES-256-SHA-XF]
TRANSFORM_ID= AES
ENCAPSULATION_MODE= TUNNEL
AUTHENTICATION_ALGORITHM= HMAC_SHA
KEY_LENGTH= 256
Life= LIFE_QUICK_MODE
[QM-ESP-AES-256-SHA-PFS-XF]
TRANSFORM_ID= AES
ENCAPSULATION_MODE= TUNNEL
AUTHENTICATION_ALGORITHM= HMAC_SHA
GROUP_DESCRIPTION= MODP_1024
KEY_LENGTH= 256
Life= LIFE_QUICK_MODE
[QM-ESP-AES-256-SHA-TRP-XF]
TRANSFORM_ID= AES
ENCAPSULATION_MODE= TRANSPORT
AUTHENTICATION_ALGORITHM= HMAC_SHA
KEY_LENGTH= 256
Life= LIFE_QUICK_MODE
# AH
[QM-AH-MD5-XF]
TRANSFORM_ID= MD5
ENCAPSULATION_MODE= TUNNEL
AUTHENTICATION_ALGORITHM= HMAC_MD5
Life= LIFE_QUICK_MODE
[QM-AH-MD5-PFS-XF]
TRANSFORM_ID= MD5
ENCAPSULATION_MODE= TUNNEL
GROUP_DESCRIPTION= MODP_1024
Life= LIFE_QUICK_MODE
[Sample-Life-Time]
LIFE_TYPE= SECONDS
LIFE_DURATION= 3600,1800:7200
[Sample-Life-Volume]
LIFE_TYPE= KILOBYTES
LIFE_DURATION= 1000,768:1536
SEE ALSO
keynote(1), openssl(1), ipsec(4), keynote(4), isakmpd.policy(5),
isakmpd(8)
CAVEATS
Using aggressive mode is discouraged due to various design problems. If
your peer only supports aggressive mode, please consider replacing that
peer with a sane ISAKMP/IKE implementation. For details see
________________________.
BUGS
The RFCs do not permit differing DH groups in the same proposal for
aggressive and quick mode exchanges. Mixing both PFS and non-PFS suites
in a quick mode proposal is not possible, as PFS implies using a DH
group.
OpenBSD 4.8 September 22, 2010 OpenBSD 4.8