Chapter 21 IP Security Architecture (Reference)

This chapter contains the following reference information:

• IPsec Service Management Facility

• ipsecconf Command

• ipsecinit.conf File

• ipsecalgs Command

• Security Associations Database for IPsec

• Utilities for Key Generation in IPsec

• IPsec Extensions to Other Utilities

For instructions on how to implement IPsec on your network, see Chapter 20, Configuring IPsec (Tasks). For an overview of IPsec, see Chapter 19, IP Security Architecture (Overview).

IPsec Service Management Facility

The service management facility (SMF) provides the following services for IPsec:

• svc:/network/ipsec/policy service – Manages IPsec policy. By default, this service is enabled. The value of the config_file property determines the location of the ipsecinit.conf file. The initial value is /etc/inet/ipsecinit.conf.

• svc:/network/ipsec/ipsecalgs service – Manages the algorithms that are available to IPsec. By default, this service is enabled.

• svc:/network/ipsec/manual-key service – Activates manual key management. By default, this service is disabled. The value of the config_file property determines the location of the ipseckeysconfiguration file. The initial value is /etc/inet/secret/ipseckeys.

• svc:/network/ipsec/ike service – Manages IKE. By default, this service is disabled. For the configurable properties, see IKE Service Management Facility.

For information about SMF, see Chapter 18, Managing Services (Overview), in System Administration Guide: Basic Administration. Also see the smf(5), svcadm(1M), and svccfg(1M) man pages.

ipsecconf Command

You use the ipsecconf command to configure the IPsec policy for a host. When you run the command to configure the policy, the system creates the IPsec policy entries in the kernel. The system uses these entries to check the policy on all inbound and outbound IP datagrams. Forwarded datagrams are not subjected to policy checks that are added by using this command. The ipsecconf command also configures the security policy database (SPD).

• For information about how to protect forwarded packets, see the ifconfig(1M) and tun(7M).

• For IPsec policy options, see the ipsecconf(1M) man page.

• For instructions about how to use the ipsecconf command to protect traffic between systems, see Configuring IKE (Task Map).

You must become superuser or assume an equivalent role to invoke the ipsecconf command. The command accepts entries that protect traffic in both directions. The command also accepts entries that protect traffic in only one direction.

Policy entries with a format of local address and remote address can protect traffic in both directions with a single policy entry. For example, entries that contain the patterns laddr host1 and raddr host2 protect traffic in both directions, if no direction is specified for the named host. Thus, you need only one policy entry for each host.

Policy entries with a format of source address to destination address protect traffic in only one direction. For example, a policy entry of the pattern saddr host1 daddr host2 protects inbound traffic or outbound traffic, not both directions. Thus, to protect traffic in both directions, you need to pass the ipsecconf command another entry, as in saddr host2 daddr host1.

To ensure that the IPsec policy is active when the machine boots, you can create an IPsec policy file, /etc/inet/ipsecinit.conf. This file is read when the network services are started. For instructions on how to create an IPsec policy file, see Protecting Traffic With IPsec (Task Map).

Starting in the Solaris 10 4/09 release, with the -c option, the ipsecconf command checks the syntax of the IPsec policy file that you provide as an argument.

Policy entries that are added by the ipsecconf command are not persistent over a system reboot. To ensure that the IPsec policy is active when the system boots, add the policy entries to the /etc/inet/ipsecinit.conf file. In the current release, refresh or enable the policy service. In a release prior to the Solaris 10 4/09 release, reboot or use the ipsecconf command. For examples, see Protecting Traffic With IPsec (Task Map).

ipsecinit.conf File

To invoke IPsec security policies when you start the Solaris Operating System (Solaris OS), you create a configuration file to initialize IPsec with your specific IPsec policy entries. The default name for this file is /etc/inet/ipsecinit.conf. See the ipsecconf(1M) man page for details about policy entries and their format. After policies are configured, you can use the ipsecconf command to view or modify the existing configuration. Starting in the Solaris 10 4/09 release, you refresh the policy service to modify the existing configuration.

Sample ipsecinit.conf File

The Solaris software includes a sample IPsec policy file, ipsecinit.sample. You can use the file as a template to create your own ipsecinit.conf file. The ipsecinit.sample file contains the following examples:

#
# For example,
#
#	 {rport 23} ipsec {encr_algs des encr_auth_algs md5}
#
# will protect the telnet traffic originating from the host with ESP using
# DES and MD5. Also:
#
#	 {raddr 10.5.5.0/24} ipsec {auth_algs any}
#
# will protect traffic to or from the 10.5.5.0 subnet with AH 
# using any available algorithm.
#
#
# To do basic filtering, a drop rule may be used. For example:
#
#	 {lport 23 dir in} drop {}
#	 {lport 23 dir out} drop {}
# will disallow any remote system from telnetting in.
#
# If you are using IPv6, it may be useful to bypass neighbor discovery
# to allow in.iked to work properly with on-link neighbors. To do that,
# add the following lines:
#
#        {ulp ipv6-icmp type 133-137 dir both } pass { }
#
# This will allow neighbor discovery to work normally.

Security Considerations for ipsecinit.conf and ipsecconf

Use extreme caution if transmitting a copy of the ipsecinit.conf file over a network. An adversary can read a network-mounted file as the file is being read. If, for example, the /etc/inet/ipsecinit.conf file is accessed or is copied from an NFS-mounted file system, an adversary can change the policy that is contained in the file.

Ensure that you set up IPsec policies before starting any communications, because existing connections might be affected by the addition of new policy entries. Similarly, do not change policies in the middle of a communication.

Specifically, IPsec policy cannot be changed for SCTP, TCP, or UDP sockets on which a connect() or accept() function call has been issued. A socket whose policy cannot be changed is called a latched socket. New policy entries do not protect sockets that are already latched. For more information, see the connect(3SOCKET) and accept(3SOCKET) man pages.

Protect your naming system. If the following two conditions are met, then your host names are no longer trustworthy:

• Your source address is a host that can be looked up over the network.

• Your naming system is compromised.

Security weaknesses often arise from the misapplication of tools, not from the actual tools. You should be cautious when using the ipsecconf command. Use a console or other hard-connected TTY for the safest mode of operation.

ipsecalgs Command

The Solaris cryptographic framework provides authentication and encryption algorithms to IPsec. The ipsecalgs command can list the algorithms that each IPsec protocol supports. The ipsecalgs configuration is stored in the /etc/inet/ipsecalgs file. Typically, this file does not need to be modified. However, if the file needs to be modified, use the ipsecalgs command. The file must never be edited directly. In the current release, the supported algorithms are synchronized with the kernel at system boot by the svc:/network/ipsec/ipsecalgs:default service.

The valid IPsec protocols and algorithms are described by the ISAKMP domain of interpretation (DOI), which is covered by RFC 2407. In a general sense, a DOI defines data formats, network traffic exchange types, and conventions for naming security-relevant information. Security policies, cryptographic algorithms, and cryptographic modes are examples of security-relevant information.

Specifically, the ISAKMP DOI defines the naming and numbering conventions for the valid IPsec algorithms and for their protocols, PROTO_IPSEC_AH and PROTO_IPSEC_ESP. Each algorithm is associated with exactly one protocol. These ISAKMP DOI definitions are in the /etc/inet/ipsecalgs file. The algorithm and protocol numbers are defined by the Internet Assigned Numbers Authority (IANA). The ipsecalgs command makes the list of algorithms for IPsec extensible.

For more information about the algorithms, refer to the ipsecalgs(1M) man page. For more information on the Solaris cryptographic framework, see Chapter 13, Solaris Cryptographic Framework (Overview), in System Administration Guide: Security Services.

Security Associations Database for IPsec

Information on key material for IPsec security services is maintained in a security associations database (SADB). Security associations (SAs) protect inbound packets and outbound packets. The SADBs are maintained by a user process, or possibly multiple cooperating processes, that send messages over a special kind of socket. This method of maintaining SADBs is analogous to the method that is described in the route(7P) man page. Only superuser or a user who has assumed an equivalent role can access the database.

The in.iked daemon and the ipseckey command use the PF_KEY socket interface to maintain SADBs. For more information on how SADBs handle requests and messages, see the pf_key(7P) man page.

Utilities for Key Generation in IPsec

The IKE protocol provides automatic key management for IPv4 and IPv6 addresses. See Chapter 23, Configuring IKE (Tasks) for instructions on how to set up IKE. The manual keying utility is the ipseckey command, which is described in the ipseckey(1M) man page.

You use the ipseckey command to manually populate the security associations database (SADB). Typically, manual SA generation is used when IKE is unavailable for some reason. However, if the SPI values are unique, manual SA generation and IKE can be used at the same time.

The ipseckey command can be used to view all SAs that are known to the system, whether the keys were added manually or by IKE. Starting in the Solaris 10 4/09 release, with the -c option, the ipseckey command checks the syntax of the keys file that you provide as an argument.

IPsec SAs that are added by the ipseckey command are not persistent over system reboot. In the current release, to enable manually added SAs at system boot, add entries to the /etc/inet/secret/ipseckeys file, then enable the svc:/network/ipsec/manual-key:default service. For the procedure, see How to Manually Create IPsec Security Associations.

While the ipseckey command has only a limited number of general options, the command supports a rich command language. You can specify that requests be delivered by means of a programmatic interface specific for manual keying. For additional information, see the pf_key(7P) man page.

Security Considerations for ipseckey

The ipseckey command enables superuser or a role with the Network Security or Network IPsec Management rights profile to enter sensitive cryptographic keying information. If an adversary gains access to this information, the adversary can compromise the security of IPsec traffic.

You should consider the following issues when you handle keying material and use the ipseckey command:

• Have you refreshed the keying material? Periodic key refreshment is a fundamental security practice. Key refreshment guards against potential weaknesses of the algorithm and keys, and limits the damage of an exposed key.

• Is the TTY going over a network? Is the ipseckey command in interactive mode?

  • In interactive mode, the security of the keying material is the security of the network path for this TTY's traffic. You should avoid using the ipseckey command over a clear-text telnet or rlogin session.

  • Even local windows might be vulnerable to attacks by a concealed program that reads window events.

• Have you used the -f option? Is the file being accessed over the network? Can the file be read by the world?

  • An adversary can read a network-mounted file as the file is being read. You should avoid using a world-readable file that contains keying material.

  • Protect your naming system. If the following two conditions are met, then your host names are no longer trustworthy:

    • Your source address is a host that can be looked up over the network.

    • Your naming system is compromised.

Security weaknesses often arise from the misapplication of tools, not from the actual tools. You should be cautious when using the ipseckey command. Use a console or other hard-connected TTY for the safest mode of operation.

IPsec Extensions to Other Utilities

The ifconfig command has options to manage the IPsec policy on a tunnel interface. The snoop command can parse AH and ESP headers.

ifconfig Command and IPsec

In the Solaris 10, Solaris 10 7/05, Solaris 10 1/06, and Solaris 10 11/06 releases: To support IPsec, the following security options are available from the ifconfig command. These security options are handled by the ipsecconf command in the Solaris 10 7/07 release.

• auth_algs

• encr_auth_algs

• encr_algs

You must specify all IPsec security options for a tunnel in one invocation. For example, if you are using only ESP to protect traffic, you would configure the tunnel, ip.tun0, once with both security options, as in:

# ifconfig ip.tun0 encr_algs aes encr_auth_algs md5

Similarly, an ipsecinit.conf entry would configure the tunnel once with both security options, as in:

# WAN traffic uses ESP with AES and MD5.
   {} ipsec {encr_algs aes encr_auth_algs md5}

auth_algs Security Option

This option enables IPsec AH for a tunnel with a specified authentication algorithm. The auth_algs option has the following format:

auth_algs authentication-algorithm

For the algorithm, you can specify either a number or an algorithm name, including the parameter any, to express no specific algorithm preference. To disable tunnel security, specify the following option:

auth_algs none

For a list of available authentication algorithms, run the ipsecalgs command.

The auth_algs option cannot work with NAT-Traversal. For more information, see IPsec and NAT Traversal.

encr_auth_algs Security Option

This option enables IPsec ESP for a tunnel with a specified authentication algorithm. The encr_auth_algs option has the following format:

encr_auth_algs authentication-algorithm

For the algorithm, you can specify either a number or an algorithm name, including the parameter any, to express no specific algorithm preference. If you specify an ESP encryption algorithm, but you do not specify the authentication algorithm, the ESP authentication algorithm value defaults to the parameter any.

For a list of available authentication algorithms, run the ipsecalgs command.

encr_algs Security Option

This option enables IPsec ESP for a tunnel with a specified encryption algorithm. The encr_algs option has the following format:

encr_algs encryption-algorithm

For the algorithm, you can specify either a number or an algorithm name. To disable tunnel security, specify the following option:

encr_algs none

If you specify an ESP authentication algorithm, but not an encryption algorithm, ESP's encryption value defaults to the parameter null.

For a list of available encryption algorithms, run the ipsecalgs command.

snoop Command and IPsec

The snoop command can parse AH and ESP headers. Because ESP encrypts its data, the snoop command cannot see encrypted headers that are protected by ESP. AH does not encrypt data. Therefore, traffic that is protected by AH can be inspected with the snoop command. The -V option to the command shows when AH is in use on a packet. For more details, see the snoop(1M) man page.

For a sample of verbose snoop output on a protected packet, see How to Verify That Packets Are Protected With IPsec.