Security Considerations
If, for example, the /etc/inet/ipsecinit.conf file is sent from an NFS-mounted file system, an adversary can modify the data contained in the file. The outcome would be a change to the configured policy. Consequently, you should use extreme caution if transmitting a copy of the ipsecinit.conf file over a network.
Policy cannot be changed (is "latched") for TCP/UDP sockets on which a connect(3SOCKET) or accept(3SOCKET) has been issued. Adding new policy entries does not affect the latched sockets. This latching feature might change in the future, so you should not depend on this feature.
Ensure that you set up the 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.
If your source address is a host that can be looked up over the network, and your naming system itself is compromised, then any names that are used are no longer trustworthy.
Security weaknesses often lie in misapplication of tools, not the tools themselves. You should be cautious when using the ipsecconf command. Use a console or other hard-connected TTY for the safest mode of operation.
IPsec Security Associations Database
Keying information for IPsec security services is maintained in a security association database (SADB). Security associations protect both inbound and outbound packets. A user process (or possibly multiple cooperating processes) maintains SADBs by sending messages over a special kind of socket. This is analogous to the method that is described in the route(7P) man page. Only a superuser can access an SADB.
The operating system might spontaneously emit messages in response to external events, such as a request for a new SA for an outbound datagram, or to report the expiration of an existing SA. You open the channel for passing SADB control messages by using the socket call that is described in the previous section. More than one key socket can be open per system.
Messages include a small base header, followed by a number of extension messages (zero or more). Some messages require additional data. The base message and all extensions must be 8-byte aligned. The GET message serves as an example. This message requires the base header, the SA extension, and the ADDRESS_DST extension. See the pf_key(7P) man page for details.
Keying Utilities
The IKE protocol is the automatic keying utility for IPv4 addresses. See Chapter 21, Internet Key Exchange for how to set up IKE. The manual keying utility is the ipseckey(1M) command.
You use the ipseckey command to manually manipulate the security association databases with the ipsecah(7P) and ipsecesp(7P) protection mechanisms. You can also use the ipseckey command to set up security associations between communicating parties when automated key management is not available. An example is communicating parties that have IPv6 addresses.
While the ipseckey command has only a limited number of general options, it supports a rich command language. You can specify that requests should be delivered by means of a programmatic interface specific for manual keying. See the pf_key(7P) man page for additional information. When you invoke ipseckey with no arguments, it enters an interactive mode that displays a prompt that enables you to make entries. Some commands require an explicit security association (SA) type, while others permit you to specify the SA type and act on all SA types.
Security Considerations
The ipseckey command enables a privileged user 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. Changing keys guards against potential weaknesses of the algorithm and keys, and limits the damage of an exposed key.
Is the TTY going over a network (interactive mode)?
If the TTY is in interactive mode, then 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.
Is the file accessed over the network or readable to the world (-f option)?
An adversary can read a network-mounted file as it is being read. You should avoid using a world-readable file with keying material in it.
If your source address is a host that can be looked up over the network, and your naming system is compromised, then any names used are no longer trustworthy.
Security weaknesses often lie in misapplication of tools, not the tools themselves. 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 IPsec policy on a tunnel interface, and the snoop command can parse AH and ESP headers.
ifconfig Command
To support IPsec, the following security options have been added to the ifconfig(1M) command:
auth_algs
This option enables IPsec AH for a tunnel, with the authentication algorithm specified. The auth_algs option has the following format:
auth_algs authentication_algorithm |
The algorithm can be either a number or an algorithm name, including the parameter any, to express no specific algorithm preference. You must specify all IPsec tunnel properties on the same command line. To disable tunnel security, specify the following option:
auth_alg none |
See Table 19-1 for a list of available authentication algorithms and for pointers to the algorithm man pages.
encr_auth_algs
This option enables IPsec ESP for a tunnel, with the authentication algorithm specified. 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.
See Table 19-1 for a list of available authentication algorithms and for pointers to the algorithm man pages.
encr_algs
This option enables IPsec ESP for a tunnel with the encryption algorithm specified. The option has the following format:
encr_algs encryption_algorithm |
For the algorithm, you can specify either a number or an algorithm name. You must specify all IPsec tunnel properties on the same command line. To disable tunnel security, specify the following option:
encr_alg none |
If you specify an ESP authentication algorithm, but not an encryption algorithm, the ESP encryption value defaults to the parameter null.
See the ipsecesp(7P) man page or Table 19-2 for a list of available encryption algorithms and for pointers to the algorithm man pages.
snoop Command
The snoop command can now parse AH and ESP headers. Because ESP encrypts its data, snoop cannot see encrypted headers that are protected by ESP. AH does not encrypt data, so traffic can still be inspected with snoop. The snoop -V option shows when AH is in use on a packet. See the snoop(1M) man page for more details.