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 association databases (SADBs) when automated key management is not used. When you invoke the ipseckey command with no arguments, the command enters an interactive mode and 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.

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 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.

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.