/usr/lib/inet/in.iked [-d] [-f filename] [-p level]
/usr/lib/inet/in.iked -c [-f filename]
in.iked performs automated key management for IPsec using the Internet Key Exchange (IKE) protocol.
in.iked implements the following:
IKE authentication with either pre-shared keys, DSS signatures, RSA signatures, or RSA encryption.
Diffie-Hellman key derivation using either 768, 1024, 1536, 2048, 3072, or 4096-bit public key moduli, or 256, 384, or 521-bit elliptic curve moduli.
Authentication protection with cipher choices of AES, DES, Blowfish, or 3DES, and hash choices of either HMAC-MD5 or HMAC-SHA-1. Encryption in in.iked is limited to the IKE authentication and key exchange. See ipsecesp(7P) for information regarding IPsec protection choices.
in.iked is managed by the following smf(5) service:
This service is delivered disabled because the configuration file needs to be created before the service can be enabled. See ike.config(4) for the format of this file.
See “Service Management Facility” for information on managing the smf(5) service.
in.iked listens for incoming IKE requests from the network and for requests for outbound traffic using the PF_KEY socket. See pf_key(7P).
The ikeadm(1M) command can read the /etc/inet/ike/config file as a rule, then pass the configuration information to the running in.iked daemon using a doors interface.
example# ikeadm read rule /etc/inet/ike/config
Refreshing the ike smf(5) service provided to manage the in.iked daemon sends a SIGHUP signal to the in.iked daemon, which will (re)read /etc/inet/ike/config and reload the certificate database.
The preceding two commands have the same effect, that is, to update the running IKE daemon with the latest configuration. See “Service Management Facility” for more details on managing the in.iked daemon.
When Trusted Extensions are enabled (see labeld(1M)), in.iked can be used in the global zone to negotiate labeled security associations. On labeled systems using in.iked, UDP ports 500 and 4500 must be configured as multi-level ports for the global zone in the tnzonecfg file (see tnzonecfg(4), part of the Solaris Trusted Extensions Reference Manual). See ike.config(4) for more information on configuring in.iked to be label-aware.
The IKE daemon (in.iked) is managed by the service management facility, smf(5). The following group of services manage the components of IPsec:
svc:/network/ipsec/ipsecalgs (See ipsecalgs(1M)) svc:/network/ipsec/policy (See ipsecconf(1M)) svc:/network/ipsec/manual-key (See ipseckey(1M)) svc:/network/ipsec/ike (see ike.config(4))
The manual-key and ike services are delivered disabled because the system administrator must create configuration files for each service, as described in the respective man pages listed above.
The correct administrative procedure is to create the configuration file for each service, then enable each service using svcadm(1M).
The ike service has a dependency on the ipsecalgs and policy services. These services should be enabled before the ike service. Failure to do so results in the ike service entering maintenance mode.
If the configuration needs to be changed, edit the configuration file then refresh the service, as follows:
example# svcadm refresh ike
The following properties are defined for the ike service:
Defines the level that ikeadm(1M) invocations can change or observe the running in.iked. The acceptable values for this property are the same as those for the –p option. See the description of –p in OPTIONS.
Defines the configuration file to use. The default value is /etc/inet/ike/config. See ike.config(4) for the format of this file. This property has the same effect as the –f flag. See the description of –f in OPTIONS.
Defines the amount of debug output that is written to the debug_logfile file, described below. The default value for this is op or operator. This property controls the recording of information on events such as re-reading the configuration file. Acceptable value for debug_level are listed in the ikeadm(1M) man page. The value all is equivalent to the –d flag. See the description of –d in OPTIONS.
Defines where debug output should be written. The messages written here are from debug code within in.iked. Startup error messages are recorded by the smf(5) framework and recorded in a service-specific log file. Use any of the following commands to examine the logfile property:
example# svcs -l ike example# svcprop ike example# svccfg -s ike listprop
The values for these log file properties might be different, in which case both files should be inspected for errors.
A boolean value that controls in.iked's behavior should the configuration file have syntax errors. The default value is false, which causes in.iked to enter maintenance mode if the configuration is invalid.
Setting this value to true causes the IKE service to stay online, but correct operation requires the administrator to configure the running daemon with ikeadm(1M). This option is provided for compatibility with previous releases.
These properties can be modified using svccfg(1M) by users who have been assigned the following authorization:
PKCS#11 token objects can be unlocked or locked by using ikeadm token login and ikeadm token logout, respectively. Availability of private keying material stored on these PKCS#11 token objects can be observed with: ikeadm dump certcache. The following authorizations allow users to log into and out of PKCS#11 token objects:
# svccfg -s ipsec/ike setprop config/config_file = \ /new/config_file # svcadm refresh ike
Administrative actions on this service, such as enabling, disabling, refreshing, and requesting restart can be performed using svcadm(1M). A user who has been assigned the authorization shown below can perform these actions:
The service's status can be queried using the svcs(1) command.
The in.iked daemon is designed to be run under smf(5) management. While the in.iked command can be run from the command line, this is discouraged. If the in.iked command is to be run from the command line, the ike smf(5) service should be disabled first. See svcadm(1M).
IKE configuration and activation is managed in Location profiles (refer to netcfg(1M) for more information about location profiles). These profiles are either fixed, meaning the network configuration is being managed in the traditional way, or reactive, meaning the network configuration is being managed automatically, reacting to changes in the network environment according to policy rules specified in the profiles.
When a fixed location (there can currently be only one, the DefaultFixed location) is active, changes made to the SMF repository will be applied to the location when it is disabled, and thus will be restored if that location is later re-enabled.
When a reactive location is active, changes should not be applied directly to the SMF repository; these changes will not be preserved in the location profile, and will thus be lost if the location is disabled, or if the system's network configuration, as managed by svc:/network/physical:default and svc:/network/location:default, is refreshed or restarted. Changes should instead be applied to the location itself, using the netcfg(1M) command; this will save the change to the location profile repository, and will also apply it to the SMF repository (if the change is made to the currently active location).
The name of the file containing IKE configuration rules is stored in the ike-config-file property of a location profile. If this property has a value set svc:/network/ipsec/ike will be enabled, with the specified rules file applied. If this property is not set, the service will be disabled.
The following options are supported:
Check the syntax of a configuration file.
Use debug mode. The process stays attached to the controlling terminal and produces large amounts of debugging output. This option is deprecated. See “Service Management Facility” for more details.
Use filename instead of /etc/inet/ike/config. See ike.config(4) for the format of this file. This option is deprecated. See “Service Management Facility” for more details.
Specify privilege level (level). This option sets how much ikeadm(1M) invocations can change or observe about the running in.iked.
Valid levels are:
Access to preshared key info
Access to keying material
If –p is not specified, level defaults to 0.
This option is deprecated. See “Service Management Facility” for more details.
This program has sensitive private keying information in its image. Care should be taken with any core dumps or system dumps of a running in.iked daemon, as these files contain sensitive keying information. Use the coreadm(1M) command to limit any corefiles produced by in.iked.
Default configuration file.
Private keys. A private key must have a matching public-key certificate with the same filename in /etc/inet/ike/publickeys/.
Public-key certificates. The names are only important with regard to matching private key names.
Public key certificate revocation lists.
IKE pre-shared secrets for Phase I authentication.
See attributes(5) for descriptions of the following attributes:
See tnzonecfg(4), part of the Solaris Trusted Extensions Reference Manual.
Harkins, Dan and Carrel, Dave. RFC 2409, Internet Key Exchange (IKE). Network Working Group. November 1998.
Maughan, Douglas, Schertler, M., Schneider, M., Turner, J. RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP). Network Working Group. November 1998.
Piper, Derrell, RFC 2407, The Internet IP Security Domain of Interpretation for ISAKMP. Network Working Group. November 1998.
Fu, D.; Solinos, J., RFC 4753, ECP Groups for IKE and IKEv2. Network Working Group. January 2007.
Lepinski, M.; Kent, S., RFC 5114, Additional Diffie-Hellman Groups for Use with IETF Standards. Network Working Group. January 2008.