The IP Security feature of AIX provides the following functions:
The following features are available with Internet Key Exchange, AIX versions 4.3.2 and later:
In the first RFC versions of the IP Security headers, authentication data was sent using an Authentication Header (RFC 1826). Encrypted data, or ciphertext was sent in a separate ESP header (RFC 1829). In 1997, the ESP header format was extended to include a field for the authentication digest to enable both encryption and authentication information to be processed in one header. In addition, both AH and ESP formats were extended for replay protection by including a sequence number that prevents old replay packets being accepted. (See figure.) A new HMAC (Hashed Message Authentication Code) standard for strengthening the security of authentication algorithms was adopted in RFC 2104. In this book, these proposed formats are referred to as the 1997 drafts.
In the IP Sec support for AIX 4.3, the RFC versions of the headers and the 1997 draft standards are implemented. Supported authentication algorithms in AIX 4.3 are HMAC MD5 (Message Digest 5, RFC 1321), HMAC SHA1 (Secure Hash Algorithm) and Keyed MD5 (for backward compatibility). The selection of the header format is determined by the authentication algorithm.
Encryption algorithms include DES CBC 8 (Data Encryption Standard Cipher Block Chaining with 64-bit Initial Vector), DES CBC 4 (Data Encryption Standard Cipher Block Chaining with 32-bit Initial Vector), 3 DES CBC (Triple DES, AIX versions 4.3.1 and later), and an exportable version of DES known as CDMF (Common Data Masking Facility). The most commonly used encryption algorithm is DES CBC 8. The ability to send authentication data in the ESP header is also supported. Either HMAC SHA1 or HMAC MD5 may be used with any of the encryption algorithms.
Once the 1997 drafts are promoted to RFC standards and are widely used, configuration will be much simpler and IP Security will be implemented in a consistent manner.
The security standards used by AIX are the standards being produced by the IP Security group of the Internet Engineering Task Force (IETF). Some of these standards are currently in draft mode and may become accepted RFCs before the next AIX version release. A current and complete list of RFC standards is maintained on the Internet at the following URL:
http://ds.internic.net/ds/rfc-index.html
The following sections list the standards on which the IP Sec code is based for AIX version 4.3.2.
The building block on which secure communications is built is a concept known as a security association. Security associations (SAs) relate a specific set of security parameters to a type of traffic. With IP Security-protected data, a separate SA exists for each direction and for each header type, AH or ESP. The information contained in the SA includes the IP addresses of the communicating parties, a unique identifier known as the Security Parameters Index (SPI), the algorithms selected for authentication and/or encryption, the authentication and encryption keys, and the key lifetimes (see figure). The goal of key management is to negotiate and compute the SAs that will be used when protecting IP traffic.
To set up a secure communication between two hosts, SAs must be negotiated and managed during the use of the tunnel. Key management is a complex issue for IP Security and new standards are being developed to ensure interoperability. Two types of tunnels are supported by AIX version 4.3 and an additional type is supported by AIX versions 4.3.2 and later. Each uses different key management techniques. They are:
Manual tunnels provide backward compatibility to all header types and will interoperate with machines that do not have IBM or, for AIX versions 4.3.2 and later, IKE key management protocol. The disadvantage of manual tunnels is that the key values are static. In other words, the encryption and authentication keys are the same for the life of the tunnel and must be manually updated. The manual tunnel support has the widest choice of header and encryption options, as shown in the following table:
| Algorithm | AH IPV4 | AH IPV6 | ESP IPV4 | ESP IPV6 | RFC Format | 1997 Draft Format |
|---|---|---|---|---|---|---|
| Keyed MD5 | X | X | ||||
| HMAC MD5 | X | X | X | X | X | |
| HMAC SHA1 | X | X | X* | X* | X | |
| DES CBC 8 | X | X | X | X | ||
| DES CBC 4 | X | X | X | X | ||
| CDMF | X | X | X | X | ||
| 3 DES CBC* | X | X | X | X | ||
| ESP Null | X | X | X | X |
Note: In the previous table, items shown with an asterisk (*) are available in AIX versions 4.3.1 and later.
IBM tunnels negotiate and refresh security parameters. This protocol predates the IKE protocol available with AIX versions 4.3.2 and later, and many aspects of IBM tunnel protocol are the basis of the IKE design. They support the original RFC formats on IP Version 4.
IKE tunnels are recommended over IBM tunnels, except when communicating with IBM equipment that does not yet support IKE tunnels. IBM tunnels offer a more dynamic and secure method for providing IP Security tunnels than manual tunnels, and should be considered in situations where IKE tunnel support is not available. IBM tunnel support is shown in the following table:
| Algorithm | AH IPV4 | ESP IPV4 | RFC Format | 1997 Draft Format |
|---|---|---|---|---|
| Keyed MD5 | X | X | ||
| DES CBC 8 | X | X | ||
| DES CBC 4 | X | X | ||
| CMDF | X | X | ||
| 3 DES CBC |
IKE tunnels are available in AIX versions 4.3.2 and later. Based on the ISAKMP/Oakley standards developed by the IETF, IKE tunnels negotiate and refresh security parameters and exchange keys securely. Three types of authentication are described in the standards, preshared key, digital signature and public key. AIX version 4.3.2 implements Preshared Key.
The negotiation uses a two phase approach. The first phase authenticates the communicating parties and specifies the method for security communications. In phase 2, IP security associations (SAs) are negotiated and keys are exchanged.
IKE tunnels are the most desired key management method. Since it is a very new technology, it supports the new draft formats with only industry standard encryption. (CDMF is being considered but is not yet adopted by the IETF.) In AIX, IKE tunnels support IP Version 4 only, as shown in the following table:
| Algorithm | AH IPV4 | ESP IPV4 | RFC Format | 1997 Draft Format |
|---|---|---|---|---|
| HMAC MD5 | X | X | X | |
| HMAC SHA1 | X | X | X | |
| DES CBC 8 | X | X | ||
| DES CBC 4 | X | X | ||
| 3 DES CBC | X | X | ||
| ESP Null | X | X |
Filtering is a basic function in which incoming and outgoing packets can be accepted or denied based on a variety of characteristics. This allows a user or system administrator to configure the host to control the traffic between this host and other hosts. Filtering is done on a variety of packet properties, such as source and destination addresses, IP version (4 or 6), subnet masks, protocol, port, routing characteristics, fragmentation, interface, and tunnel definition.
Rules, known as filter rules, are used to associate certain kinds of traffic with a particular tunnel. In a basic AIX configuration, when a user defines a tunnel, filter rules are autogenerated to direct all traffic from that host through the secure tunnel. If more specific types of traffic are desired, the filter rules can be edited or replaced to allow precise control of the traffic using a particular tunnel.
Similarly, when the tunnel is modified or deleted, the filter rules for that tunnel are automatically deleted. This greatly simplifies IP security configuration and helps reduce human error. Tunnel definitions can be propagated and shared among AIX machines and AIX firewalls using import and export utilities, which greatly simplifies the administration of a large number of machines.
Filter rules are necessary to associate particular types of traffic with a tunnel, but data being filtered does not necessarily need to travel in a tunnel. Rules allow AIX to provide basic firewall functionality for users who want to restrict the flow of certain types of traffic to or from their machine. This is especially useful for the administration of machines in an intranet or do not have the protection of a firewall.
Once the filter rules are generated, they are stored in a table and loaded into the kernel. When packets are ready to be sent or received from the network, the filter rules are checked in the list from top to bottom to determine whether the packet should be permitted, denied, or sent through a tunnel. The criteria of the rule is compared to the packet characteristics until a match is found or the default rule is reached.
The IP Sec function also implements filtering of non-secure packets based on very granular user-defined criteria, which can be useful when controlling IP traffic between networks and machines that do not require the use of IP Sec.
