svcadm(8)을 검색하려면 섹션에서 8 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
ikev2.config(5)
ikev2.config(5) File Formats ikev2.config(5)
NAME
ikev2.config - configuration file for IKEv2 policy
SYNOPSIS
/etc/inet/ike/ikev2.config
DESCRIPTION
The /etc/inet/ike/ikev2.config file contains rules for matching inbound
IKE requests and preparing outbound IKEv2 requests. This file is logi‐
cally part of the peer authentication database (PAD) as described in
RFC 4301.
You can test the syntactic correctness of the IKEv2 configuration file
and load the configuration file without starting the daemon by using
the -c option of in.ikev2d(8). You might need to use the -f option if
it is not in /etc/inet/ike/ikev2.config.
For in.ikev2d to verify the identity of a peer using certificates, it
must be able to verify the certificate that contains that identity. In
the case of self-signed certificates, the public certificate of the
peer must be loaded into the local system's IKEv2 certificate keystore.
For CA signed certificates, the public certificate of the signing CA,
and any intermediatory certificates, must be loaded into the local sys‐
tem's IKEv2 keystore. See ikev2cert(8) for examples.
The ikev2.config policy file does not define certificate trust or vali‐
dation policy. Instead, all certificates added to the local system's
IKEv2 certificate keystore are trusted implicitly. Trust anchors and
certificate validation policy are configured by invoking kmfcfg(1) to
modify the IKEv2 specific KMF policy governing usage of the keystore.
For additional details, see in.ikev2d(8), pktool(1), and kmfcfg(1).
Lexical Components
On any line, an unquoted # character introduces a comment. The remain‐
der of that line is ignored. Additionally, on any line, an unquoted //
sequence introduces a comment. The remainder of that line is ignored.
All keywords are case-sensitive.
There are several special types of lexical tokens in the ikev2.config
file:
num
A decimal, hex, or octal number representation is as in C.
IPaddr/prefix/range
An IPv4 or IPv6 address with an optional /NNN suffix, (where NNN is
a num) that indicates an address (CIDR) prefix (for example,
10.1.2.0/24). An optional /ADDR suffix (where ADDR is a second IP
address) indicates an address/mask pair (for example,
10.1.2.0/255.255.255.0). An optional -ADDR suffix (where ADDR is a
second IPv4 address) indicates an inclusive range of addresses (for
example, 10.1.2.0-10.1.2.255). The / or - can be surrounded by an
arbitrary amount of white space.
{ XXX | YYY | ZZZ }
Either the words XXX, YYY, or ZZZ, for example, { yes | no}.
id-type
An IKEv2 identity type. The value of the id-type is checked to en‐
sure that the format matches the type. For example, an EMAIL id-
type must contain an @ character. IKEv2 identity types include:
DN An X.509 distinguished name in text format. For example,
"C=US, O=Oracle, CN=Example Name"
FQDN A fully qualified domain name. A leading '.' might be used
as a wildcard. For example, "myhost.example.com" or ".ex‐
ample.com".
EMAIL An email address. An empty value before the '@' symbol in‐
dicates a wildcard. For example, "joe.example@mail.exam‐
ple.com" or "@example.com".
IP An IP address. Address ranges or prefixes might be used
for wildcard matching. For example, "10.1.2.3", "10.0.1.1
- 10.0.1.15", or "0.0.0.0/0".
IPV6 An IPv6 address. Address ranges or prefixes might be used
for wildcard matching. For example, "fe80::1", "fe80::1 -
fe80::12", or "::/0".
KEYID A key ID. Typically, this is the 160-bit hash of a cer‐
tificate's public key. For example,
"3f:a0:6a:a1:e6:73:6b:c8:d7:7b:4d:de:b8:b4:3d:5d:ff:26:69:80".
auth-method
An IKEv2 authentication method. IKEv2 authentication method values
include:
preshared Authenticate using pre-shared keys. Refer to the
ikev2.preshared(5) man page.
cert Authenticate using a certificate signature. The
signature method is determined automatically and
might be any of the methods described below.
rsa_sig Authenticate using a RSA certificate signature.
dss_sig Authenticate using a DSS certificate signature.
ec_sha256_sig Authenticate using an ECDSA certificate signature
with the SHA256 hash algorithm. The certificate
must use a public key from the secp256r1 curve.
ec_sha384_sig Authenticate using an ECDSA certificate signature
with the SHA384 hash algorithm. The certificate
must use a public key from the secp384r1 curve.
ec_sha512_sig Authenticate using an ECDSA certificate signature
with the SHA512 hash algorithm. The certificate
must use a public key from the secp521r1 curve.
"string"
A quoted string.
Examples include:"Label foo", or "C=US, OU=Sun Microsystems\\,
Inc., N=olemcd@eng.example.com"
A backslash (\) is an escape character. If the string needs an ac‐
tual backslash, two must be specified.
File Body Entries
There are four main types of entries:
o IKEv2 SA transform defaults
o IKEv2 SA transforms
o IKEv2 rule defaults
o IKEv2 rules
The IKEv2 SA transform defaults are as follows:
IKEv2 SA transform defaults
These values are used as defaults for all subsequent ikesa_xform
entries in the file.
ikesa_lifetime_secs num The default lifetime, in seconds, of an
IKEv2 security association (SA).
IKEv2 SA transforms
An IKEv2 SA transform specifies a set of methods used to to protect
and authenticate traffic for an IKEv2 security association, as well
as additional parameters dependent on the security methods chosen.
During establishment of an IKEv2 SA, the initiator might offer sev‐
eral transforms; in this case, the responder will accept one of
them, assuming it has at least one matching transform configured.
The order of the transforms within this file determines the order
of preference when multiple transforms are offered.
IKEv2 SA transforms may be configured globally, outside of any
IKEv2 rule, or within an IKEv2 rule. Multiple transform entries at
either scope accumulate. However, if any transforms are specified
within an IKEv2 rule, that set of transforms overrides the globally
defined transforms for that rule only.
Each IKEv2 rule must include at least one transform, either di‐
rectly within the rule, or inherited from global definitions. Glob‐
ally defined transforms must appear before any IKEv2 rules to which
they should apply.
This is the format of an IKEv2 SA transform:
ikesa_xform { parameter-list }
The parameter-list is an unordered list of attribute value pairs.
Unless specified as optional, attributes in the parameter-list must
occur exactly once. The following attributes are defined:
dh_group number
The Oakley Diffie-Hellman group is used for IKEv2 SA key de‐
rivation. The group numbers are defined in RFC 2409, Appendix
A, RFC 3526, RFC 4753, and RFC 5114.
The list of acceptable values may be retrieved by using the
following command:
# ikeadm dump groups
encr_alg { aes | 3des | camellia }
An encryption algorithm.
The AES and CAMELLIA algorithms allows an optional key-size
setting, using the syntax (low value to high value), the same
as specified in ipsecconf(8) for the keylen specifier. To spec‐
ify a single AES or CAMELLIA key size, the low value must equal
the high value or single number must be used. If no range is
specified, all key sizes are allowed.
The list of supported encryption algorithms may be retrieved
using the following command:
# ikeadm dump encralgs
Note that the syntax described above uses abbreviated identi‐
fiers that omit the -cbc suffix.
auth_alg { sha | sha1 | sha256 | sha384 | sha512 }
An authentication algorithm.
The list of supported authentication algorithms can be re‐
trieved by using the following command:
# ikeadm dump authalgs
prf { sha | sha1 | sha256 | sha384 | sha512 }
Optional. The pseudo-random function to use. The same algo‐
rithms available for auth_algs may be used for prf. By default,
the value specified for auth_alg will be used.
ikesa_lifetime_secs num
Optional. The lifetime for the IKEv2 SA.
IKEv2 rule defaults
The following IKEv2 rule attributes can be prefigured by using
file-level defaults. Values specified within any given rule over‐
ride global defaults.
local_id
remote_id
auth_lifetime_secs
childsa_lifetime_secs
childsa_softlife_secs
childsa_idletime_secs
childsa_lifetime_kb
childsa_softlife_kb
childsa_pfs
In each case, the usage and required arguments for these keywords
is the same as inside an IKEv2 rule.
IKEv2 rules
An IKEv2 rule describes a set of peer system's with which the IKEv2
service is allowed to establish IKEv2 SAs, along with the local
identity and other parameters to be used with that set of peers.
When a new IPsec SA is requested by the kernel, or a peer system
attempts to initiate an IKEv2 SA, the set of IKEv2 rules is
searched in the order they were added. Initially, a rule is found
by matching the IP/IPv6 addresses of the local and peer system's.
If multiple matches are possible based on addresses, a different
rule may be selected during authentication based on the peer's
identity and the contents of any certificate request payloads.
At least one IKEv2 rule must be defined in the configuration file.
This is the format of an IKEv2 rule:
{ parameter-list }
The parameter-list is an unordered list of attributes, each with
one or more additional parameters. The following attributes are
valid within an IKEv2 rule:
label string
Required parameter. The string is used to identify the IKEv2
rule when using various administrative interfaces, and in de‐
bugging output. Only one label parameter is allowed per rule.
local_addr IPaddr/prefix/range
Required parameter. The local address, address prefix, or ad‐
dress range for this rule. Multiple local_addr parameters accu‐
mulate within a given rule.
remote_addr IPaddr/prefix/range
Required parameter. The remote address, address prefix, or ad‐
dress range for this rule. Multiple remote_addr parameters ac‐
cumulate within a given rule.
auth_method auth-method
Identifies the method to be used for both local and remote au‐
thentication during establishment of the IKEv2 SA. The values
for auth-type are described in the Lexical Components section
above. This attribute is required unless both local_auth_method
and remote_auth_method are set, in which case it is disallowed.
local_auth_method auth-method
Similar to auth_method, but identifies the method for authenti‐
cating the local system only.
remote_auth_method auth-method
Similar to auth_method, but identifies the method for authenti‐
cating the peer system only.
local_id id-type = "string"
The local ID to use during authentication.
When local_auth_method is preshared, any valid id-type and
value may be used. The id-type and value must match one of the
remote_id parameters configured on the peer for authentication
to succeed.
When local_auth_method uses certificates, local_id value will
be used to select which certificate is used during authentica‐
tion. There must be a certificate matching the value assigned
to the id-type and the corresponding private key for this cer‐
tificate present in the local system's IKEv2 keystore. The pri‐
vate key is used to generate the AUTH value in the IKEv2 proto‐
col.
The receiving system will verify the AUTH value using the cer‐
tificate identified here. This certificate may be sent to the
peer during the IKEv2 protocol exchange (by default) or manu‐
ally exchanged. See the cert_payload_limit parameter below for
details.
The public certificates of the signing CAs and intermediaries
also need to be present in the receiving system's IKEv2 key‐
store in order to verify the identity of the peer's certificate
for the receiving system.
This attribute may occur any number of times within a rule.
Multiple local_id attributes within a given rule accumulate.
When pre-shared key authentication is in use, values beyond the
first are not used. When certificate-based authentication is in
use, all local_id values are considered. The best local_id is
chosen using any certificate request payloads received from the
peer and the remaining validity time of the relevant certifi‐
cates.
If this attribute is omitted, the local IP address of the IKEv2
SA will be used as the local_id. In the case where the local
system is behind a NAT, this will result in a local_id derived
from the system's internal address, which is undesirable in
most cases. For this reason, local_id should always be explic‐
itly configured when NAT is in use.
The possible values for id-type and format of string are de‐
scribed above in the Lexical Components section.
The string values for local_id must not be wildcards.
remote_id id-type = "string"
remote_id ANY
The remote ID to use during authentication.
When remote_auth_method is preshared, any valid id-type and
value may be used. The id-type and value must match one of the
local_id parameters configured on the peer for authentication
to succeed.
When remote_auth_method uses certificates, the remote ID will
be used to select which certificate is used for authentication
during IKEv2 SA establishment.
The peer may choose to send the certificate as a payload, in
which case the remote ID value must be present in the certifi‐
cate it sends. The public certificate of the signing CA also
needs to be the local system's IKEV2 keystore so that it can
verify the certificates signature.
If the peer system chooses not to send its certificate as a
payload, the local system's IKEv2 keystore needs a copy of the
peer's public certificate and the signing CA's certificate in
order to verify its identity.
This attribute may occur any number of times within a rule. If
it is omitted, the peer's IP address will be used to compute a
default remote_id. Multiple remote_id attributes within a given
rule accumulate. The identity asserted by the peer must match
one of these values for the authentication to succeed.
The form remote_id ANY will allow any remote ID asserted by the
peer. The identity still must be authenticated using certifi‐
cates or pre-shared keys.
The possible values for id-type and format of string are de‐
scribed above in the Lexical Components section.
required_issuer id-type = "string"
Require that the peer's certificate be signed by particular is‐
suer. Self-signed certificates are considered to be their own
issuers, and can pass this check. This directive provides an
additional verification step. It does not allow self-signed
certificates not present in the keystore to be trusted.
If multiple required_issuer attributes are provided, they accu‐
mulate with the IKE rule. A peer's certificate is acceptable if
it was issued by any of the required_issuers.
This parameter may only be used within IKE rules that employ
certificates for remote authentication.
cert_payload_limit num
Limit the number of certificate payloads sent during the IKEv2
AUTH exchange. By default, the local end-entity and all inter‐
mediate certificates are sent. Setting this attribute to 1 will
cause only the end-entity certificate to be sent, while setting
it to 0 will disable the sending of certificate payloads en‐
tirely. This attribute may be used to significantly reduce the
amount of data exchanged during IKEv2 SA creation in the case
where it is known that the peer system has some or all of the
required certificates installed locally.
send_cert_requests { yes | initiator-only | no }
This attribute determines whether certificate request payloads
are sent to the peer during the AUTH exchange. This parameter
is optional, and useful only when the remote authentication
method relies on certificates. The default value is yes.
Certificate payloads help the peer select which local identity
and certificate to use during authentication. By including this
payload, the public key hashes of the trust-anchors in the lo‐
cal keystore are disclosed to the peer before the peer's iden‐
tity has been authenticated.
Depending on the configuration, enabling certificate request
payloads may allow untrusted third parties to gather informa‐
tion about the set of locally configured trust-anchors. This is
especially true when this attribute is set to yes.
request_http_certs { yes | no }
This attribute determines whether to allow the peer system to
use HTTP (aka. hash and URL) certificate payloads during au‐
thentication. If this value is set and the peer sends HTTP cer‐
tificate payloads during authentication, the IKEv2 daemon will
retrieve certificates from the URLs specified and cache them
locally.
Unlike other credentials exchanged during IKEv2 authentication,
certificates downloaded via HTTP are not protected by the en‐
cryption mechanism of the IKEv2 SA.
Because certificate payload processing is performed before au‐
thentication is complete, enabling this option allows any re‐
mote system matching the rule's remote_addr attribute to cause
in.ikev2d to download any arbitrary URL. Reasonable size limi‐
tations are enforced on the downloaded file.
The default value is no.
cert_base_url "url"
This attribute specifies the prefix to prepend to a certifi‐
cate's SHA1 hash value when generating URLs for HTTP (aka. hash
and URL) certificate payloads. If this value is set and the
peer system supports HTTP certificate payloads, the IKEv2 dae‐
mon will send an HTTP URL and confirmation hash in each cer‐
tificate payload, rather than embedding the entire certificate.
This reduces the size of IKEv2 protocol packets and helps to
prevent fragmentation.
It is the administrator's responsibility to make sure that cer‐
tificates are available for download at the generated URLs. For
example, a system using a local cert with label=mycert in the
keystore with SHA1 hash
"3dc0279b27cd6b2d0bbc01c917d3f03dbed5d352" and cert_base_url =
"http://pki.example.com/certs/" would send a URL that is the
concatenation of those two values. It would be necessary to ex‐
tract the public certificate mycert and store the file on the
web server pki.example.com, in the certs subdirectory, with
filename equal to the sha1 hash value of the certificate.
Certificates files intended for use with HTTP certificate pay‐
loads must be in ASN.1 DER format. Use the outformat=der option
when exporting certificates using ikev2cert to produce files in
the correct format.
The following command may be used to generate the SHA1 hash of
a certificate in the correct format to be used as the certifi‐
cate's file name. This example uses certificate label=mycert.
ikev2cert list objtype=cert label=mycert | \
@ + nawk 'BEGIN {f=0} /SHA1 Cert/ {f=1;next}; \
@ + {if (f) { gsub(/:/,""); print $1; } f=0}'
auth_lifetime_secs num
Optional. The time in seconds after creation during which this
IKEv2 SA may be rekeyed. After this time, a IEv2 SA must be
created.
childsa_lifetime_secs num
childsa_lifetime_kb num
Optional. Determines the lifetime, in seconds or KB, of all
IPsec SAs created using IKEv2 SAs established under this rule.
childsa_softlife_secs num
childsa_softlife_kb num
Optional. Determines the soft lifetime, in seconds or KB, of
all IPsec SAs created using IKEv2 SAs established under this
rule. Once this value is depleted, the IKEv2 service will rekey
the IPsec SA if possible.
childsa_idletime_secs num
Optional. Determines the idle time in seconds for all IPsec SAs
created using IKEv2 SAs established under this rule. IPsec SAs
that are idle will not be rekeyed when their soft lifetime ex‐
pires.
childsa_pfs { num | auto }
Optional. Enables perfect forward secrecy for IPsec SA cre‐
ation. If selected, the Oakley group specified is used for PFS.
Acceptable values are the same as for the dh_group parameter
listed above. The value of auto may be used, in which case the
same dh_group negotiated during IKEv2 SA establishment will be
used.
ikesa_xform { parameter-list }
Specifies an IKEv2 SA transform specifically for this IKEv2
rule. Transforms defined within an IKEv2 rule accumulate and
override any globally defined transforms. Refer the IKEv2 SA
transforms section above for additional details.
EXAMPLES
Example 1 A Sample ikev2.config File
The following is an example of an ikev2.config file:
### BEGINNING OF FILE
#
# This default value will apply to all transforms that follow
#
ikesa_lifetime_secs 3600
#
# Global transform definitions. The algorithms choices are
# based on RFC 4921.
#
# Group 20 is 384-bit ECP
ikesa_xform { encr_alg aes(256..256) auth_alg sha384 dh_group 20 }
# Group 19 is 256-bit ECP
ikesa_xform { encr_alg aes(128..128) auth_alg sha256 dh_group 19 }
#
# Basic example rules using pre-shared keys. For these rules to
# function, the file /etc/inet/ike/ikev2.preshared must be
# populated with pre-shared keys for the local and remote
# addresses.
#
# In the next three examples, local_id and remote_id have
# been omitted, and will default to the actual addresses in
# use between the local system and the peer.
#
{
label "IP identities and PSK auth"
auth_method preshared
local_addr 10.0.0.1
remote_addr 10.0.0.2
}
{
label "IP address prefixes and PSK auth"
auth_method preshared
# Any of our IP addresses
local_addr 0.0.0.0/0
# Any peer on either of two subnets
remote_addr 10.0.0.0/24
remote_addr 10.1.0.0/24
}
{
label "IPv6 address prefixes and PSK auth"
auth_method preshared
# Any of our IPv6 addresses
local_addr ::/0
# Any peer on our WAN
remote_addr fd23:0738:dc9d::/48
}
#
# Example rules using certificates and a wide range of ID
# types. For these rules to function, certificates must be
# present in the PKCS#11 softtoken keystore for user
# ikeuser. For local identities, certificate and private
# keys must be present. In order to validate peer
# identities, the appropriate trust anchors must be
# configured for CA signed certificates. Any self-signed
# end-entity certificates must be present in the keystore or
# they will not be trusted.
#
{
label "Certificate auth with DN identities"
# Any type of certificate signature is allowed
auth_method cert
local_addr 10.0.0.1
remote_addr 10.2.0.0/24
local_id DN = "C=US, O=Oracle, CN=Example IKEv2 Local"
remote_id DN = "C=US, O=Oracle, CN=Example IKEv2 Peer1"
}
{
label "Certificate auth with many peer ID types"
# Any type of certificate signature is allowed
auth_method cert
local_addr 10.0.0.1
remote_addr 10.3.0.0/24
local_id DN = "C=US, O=Oracle, CN=Example IKEv2 Local"
# Certificates will be searched based on which ID the peer
# asserts.
remote_id DN = "C=US, O=Oracle, CN=Example IKEv2 Peer2"
remote_id EMAIL = "jack@example.com"
remote_id EMAIL = "jill@example.com"
remote_id FQDN = "generic.example.com"
remote_id IP = "10.3.200.42"
# The identities used for AUTH are divorced from the type of
# address used to communicate
remote_id IPV6 = "fd23:0738:dc9d:1:1:2:3:4"
remote_id KEYID =
"3f:a0:6a:a1:e6:73:6b:c8:d7:7b:4d:de:b8:b4:3d:5d:ff:26:69:80"
}
{
label "Certificate auth with wildcard peer IDs"
auth_method cert
local_addr 10.0.0.1
remote_addr 10.4.0.0/24
# Wildcard local IDs are not allowed
local_id DN = "C=US, O=Oracle, CN=Example IKEv2 Local"
# Any email address in the example.com domain
remote_id EMAIL = "@example.com"
# Any subdomain of example.com
remote_id FQDN = ".example.com"
# Any IP identity in the 10.4.x.y subnet
remote_id IP = "10.4.0.0/16"
# Any IPv6 address in the fd23:0738:dc9d:2:: subnet
remote_id IPV6 = "fd23:0738:dc9d:2::/64"
}
#
# This example shows how to override the transform list for
# a rule. In this example, the peer doesn't support ECDH so
# we need to fall back. We also want to ensure the use of
# RSA signature authentication.
#
{
label "Override transforms"
auth_method rsa_sig
local_addr 10.0.0.1
remote_addr 10.5.1.13
local_id DN = "C=US, O=Oracle, CN=Example IKEv2 Local"
remote_id DN = "C=US, O=Oracle, CN=Deficient IKEv2 Peer"
# Override the globally defined ikesa_xform list
# Group 16 is 4096-bit MODP
ikesa_xform { encr_alg aes(128..256) auth_alg sha1 dh_group 16 }
# Group 14 is 2048-bit MODP
ikesa_xform { encr_alg aes(128..256) auth_alg sha1 dh_group 14 }
# Group 2 is 1024-bit MODP
ikesa_xform { encr_alg aes(128..256) auth_alg sha1 dh_group 2 }
# Camellia is accepted as an alternative to AES. The key size has
# not been specified, so all supported key lengths are OK.
ikesa_xform { encr_alg camellia auth_alg sha1 dh_group 2 }
}
#
# This example shows how to mix authentication types. The
# local system will use a pre-shared key to authenticate to
# the peer, while the peer's identity will be authenticated
# using a DSS certificate signature.
#
{
label "Mixed auth types"
local_auth_method preshared
remote_auth_method dss_sig
local_addr 10.0.0.1
remote_addr 10.6.0.0/16
# Pre-shared key auth can be used with any ID type.
local_id EMAIL = "jack@example.com"
remote_id EMAIL = "jill@example.com"
}
#
# This example shows how to use the generic wildcard ID as well
# as the required_issuer attribute. In this case, we will
# allow any peer on a remote subnet to connect so long as
# that peer presents a certificate issued by the signer.
#
{
label "Wildcard with required signer"
local_auth_method cert
remote_auth_method cert
local_addr 10.0.0.1
remote_addr 10.7.0.0/16
local_id DN = "C=US, O=Oracle, CN=Example IKEv2 Local"
# Match any remote_id regardless of type
remote_id ANY
required_issuer DN = "C=US, O=Oracle, CN=Example IPsec Cert Signer"
}
ATTRIBUTES
See attributes(7) for descriptions of the following attributes:
tab() box; cw(2.75i) |cw(2.75i) lw(2.75i) |lw(2.75i) ATTRIBUTE TYPEAT‐
TRIBUTE VALUE _ Availabilitysystem/network/ike _ Interface Stability‐
Committed
SEE ALSO
kmfcfg(1), pktool(1), ikev2.preshared(5), attributes(7), labels(7),
cryptoadm(8), ikeadm(8), in.ikev2d(8), ipsecalgs(8), ipsecconf(8),
ipseckey(8), svccfg(8)
Oracle Solaris 11.4 21 Jun 2021 ikev2.config(5)