IPsec (Overview)
The IP Security Architecture (IPsec) provides cryptographic protection for IP datagrams in IPv4 and IPv6 network packets. The protection can include confidentiality, strong integrity of the data, partial sequence integrity (replay protection), and data authentication. IPsec is performed inside the IP module, and it can be applied with or without the knowledge of an Internet application. When used properly, IPsec is an effective tool in securing network traffic.
This chapter contains the following information:
Introduction to IPsec
IPsec provides security mechanisms that include secure datagram authentication and encryption mechanisms within IP. When you invoke IPsec, it applies the security mechanisms to IP datagrams that you have enabled in the IPsec global policy file. Applications can invoke IPsec to apply security mechanisms to IP datagrams on a per-socket level.
Figure 19-1 shows how an IP addressed packet, as part of an IP datagram, proceeds when IPsec has been invoked on an outbound packet. As you can see from the flow diagram, authentication header (AH) and encapsulating security payload (ESP) entities can be applied to the packet. Subsequent sections describe how you apply these entities, as well as authentication and encryption algorithms.
Figure 19-1 IPsec Applied to Outbound Packet Process
Figure 19-2 shows the IPsec inbound process.
Figure 19-2 IPsec Applied to Inbound Packet Process
IPsec Security Associations
An IPsec security associations (SA) specifies security properties that are recognized by communicating hosts. Communicating hosts typically require two SAs to communicate securely. A single SA protects data in one direction -- either to a single host or a group (multicast) address. Because most communication is peer-to-peer or client-to-server, two SAs must be present to secure traffic in both directions.
The AH or ESP, destination IP address, and Security Parameter Index (SPI) identifies an IPsec SA. The security parameters index, an arbitrary 32-bit value, is transmitted with an AH or ESP packet. The ipsecah(7P) and ipsecesp(7P) man pages explain the extent of protection that is provided by AH and ESP. An integrity checksum value is used to authenticate a packet. If the authentication fails, the packet is dropped.
Security associations are stored in a security associations database. A socket-based administration engine, the pf_key(7P) interface, enables privileged applications to manage the database. The in.iked(1M)in.iked(1M) daemon provides automatic key management.
Key Management
A security association contains keying information, algorithm choices, endpoint identities, and other parameters. Managing the keying material that SAs require for authentication and for encryption is called key management. The Internet Key Exchange (IKE) protocol handles key management automatically. You can also manage keys manually with the ipseckey(1M) command. Currently, SAs on IPv4 packets can use automatic key management, while SAs on IPv6 packets require manual management.
See "IKE Overview" for how IKE manages cryptographic keys automatically for IPv4 hosts. See "Keying Utilities" for how the administrator can manually manage the cryptographic keys by using the ipseckey command.
Protection Mechanisms
IPsec provides two mechanisms for protecting data:
Authentication Header (AH)
Encapsulating Security Payload (ESP)
Both mechanisms use security associations.
Authentication Header
The authentication header, a new IP header, provides strong integrity, partial sequence integrity (replay protection), and data authentication to IP datagrams. AH protects as much of the IP datagram as it can. AH cannot protect fields that change nondeterministically between sender and receiver. For example, the IP TTL field is not a predictable field and, consequently, not protected by AH. AH is inserted between the IP header and the transport header. The transport header can be TCP, UDP, ICMP, or another IP header when tunnels are being used. See the tun(7M) man page for details on tunneling.
Authentication Algorithms and the AH Module
IPsec implements AH as a module that is automatically pushed on top of IP. The /dev/ipsecah entry tunes AH with ndd(1M). Future authentication algorithms can be loaded on top of AH. Current authentication algorithms include HMAC-MD5 and HMAC-SHA-1. Each authentication algorithm has its own key size and key format properties. See the authmd5h(7M) and authsha1(7M) man pages for details.
Security Considerations
Replay attacks threaten any AH that does not enable replay protection. An AH does not protect against eavesdropping. Adversaries can still see data protected with AH.
Encapsulating Security Payload
The ESP provides confidentiality over what it encapsulates, as well as the services that AH provides, but only over that which it encapsulates. ESP's authentication services are optional. These services enable you to use ESP and AH together on the same datagram without redundancy. Because ESP uses encryption-enabling technology, it must conform to U.S. export control laws.
ESP encapsulates its data, so it only protects the data that follows its beginning in the datagram. In a TCP packet, ESP encapsulates only the TCP header and its data. If the packet is an IP-in-IP datagram, ESP protects the inner IP datagram. Per-socket policy allows self-encapsulation, so ESP can encapsulate IP options when it needs to. Unlike the authentication header (AH), ESP allows multiple kinds of datagram protection. Using only a single form of datagram protection can make the datagram vulnerable. For example, if you use ESP to provide confidentiality only, the datagram is still vulnerable to replay attacks and cut-and-paste attacks. Similarly, if ESP protects only integrity and does not fully protect against eavesdropping, it could provide weaker protection than AH.
Algorithms and the ESP Module
IPsec ESP implements ESP as a module that is automatically pushed on top of IP. The /dev/ipsecesp entry tunes ESP with ndd(1M). ESP allows encryption algorithms to be pushed on top of it, in addition to the authentication algorithms that are used in AH. Encryption algorithms include United States Data Encryption Standard (DES), Triple-DES (3DES), Blowfish, and AES. Each encryption algorithm has its own key size and key format properties. Because of export laws in the United States and import laws in other countries, not all encryption algorithms are available outside of the United States.
Security Considerations
An ESP without authentication is vulnerable to cut-and-paste cryptographic attacks and to eavesdropping attacks. When you use ESP without confidentiality, ESP is as vulnerable to replay as AH is.
Authentication and Encryption Algorithms
IPsec uses two types of algorithms, authentication and encryption. The authentication algorithms and the DES encryption algorithms are part of core Solaris installation. If you plan to use other algorithms that are supported for IPsec, you must install the Solaris Encryption Kit, which is provided on a separate CD.
Authentication Algorithms
Authentication algorithms produce an integrity checksum value or digest that is based on the data and a key. The authentication algorithm man pages describe the size of both the digest and key. The following table lists the authentication algorithms that are supported in the Solaris operating environment. The table also lists the format of the algorithms when they are used as security options to the IPsec utilities and their man page names.
Table 19-1 Supported Authentication Algorithms
Algorithm Name | Security Option Format | Man Page |
|---|---|---|
HMAC-MD5 | md5, hmac-md5 | authmd5h(7M) |
HMAC-SHA-1 | sha, sha1, hmac-sha, hmac-sha1 | authsha1(7M) |
Encryption Algorithms
Encryption algorithms encrypt data with a key. The algorithms operate on data in units of a block size. The encryption algorithm man pages describe the size of both the block size and the key size. By default, the DES-CBC and 3DES-CBC algorithms are installed. You must install the Solaris Encryption Kit to make the AES and Blowfish algorithms available to IPsec. The kit is available on a separate CD that is not part of the Solaris 9 installation box. The Encryption Kit Installation Guide describes how to install the Solaris Encryption Kit.
The following table lists the encryption algorithms that are supported in the Solaris operating environment. The table also lists the format of the algorithms when they are used as security options to the IPsec utilities, their man page names, and the package that contains them.
Table 19-2 Supported Encryption Algorithms
Algorithm Name | Security Option Format | Man Page | Package |
|---|---|---|---|
DES-CBC | des, des-cbc | encrdes(7M) | SUNWcsr, SUNWcarx.u |
3DES-CBC or Triple-DES | 3des, 3des-cbc | encr3des(7M) | SUNWcsr, SUNWcarx.u |
blowfish, blowfish-cbc | encrbfsh(7M) | SUNWcryr, SUNWcryrx | |
AES-CBC | aes, aes-cbc | encraes(7M) | SUNWcryr, SUNWcryrx |
Protection Policy and Enforcement Mechanisms
IPsec separates protection policy and enforcement mechanisms. You can enforce IPsec policies in the following places:
On a system-wide level
On a per-socket level
You use the ipsecconf(1M) command to configure system-wide policy.
IPsec applies system-wide policy to incoming and outgoing datagrams. You can apply some additional rules to outgoing datagrams, because of the additional data that is known by the system. Inbound datagrams can be either accepted or dropped. The decision to drop or accept an inbound datagram is based on several criteria, which sometimes overlap or conflict. Resolving a conflict depends on which rule is parsed first. Except when a policy entry states that traffic should bypass all other policy, the traffic is automatically accepted. Outbound datagrams are either sent with protection or without protection. If protection is applied, the algorithms are either specific or non-specific. If policy normally protects a datagram, it can be bypassed by either an exception in system-wide policy, or by requesting a bypass in per-socket policy.
For intra-system traffic, policies are enforced, but actual security mechanisms are not applied. Instead, the outbound policy on an intra-system packet translates into an inbound packet that has had those mechanisms applied.