19.1 Introduction

With the introduction of the security architecture for IP (IPsec, described in RFC 2401 [Kent and Atkinson 1998a]), a standard mechanism was needed to manage secret encryption and authorization keys. RFC 2367 [McDonald, Metz, and Phan 1998] introduces a generic key management API that can be used for IPsec and other network security services. Similar to routing sockets (Chapter 18), this API creates a new protocol family, the PF_KEY domain. As with routing sockets, the only type of socket supported in the key domain is a raw socket.

As described in Section 4.2, on most systems, AF_KEY would be defined to the same value as PF_KEY. However, RFC 2367 is quite specific that PF_KEY is the constant that must be used with key management sockets.

Opening a raw key management socket requires privileges. On systems where privileges are segmented, there must be an individual privilege for opening key management sockets. On regular UNIX systems, opening a key management socket is limited to the superuser.

IPsec provides security services to packets based on security associations, or SAs. An SA describes a combination of source and destination addresses (and optionally, transport protocol and ports), mechanism (e.g., authentication), and keying material. More than one SA (e.g., authentication and encryption) can apply to a single stream of traffic. The set of security associations stored for use on a system is called the security association database, or SADB.

The SADB on a system may be used for more than just IPsec; for instance, OSPFv2, RIPv2, RSVP, and Mobile-IP may also have entries in the SADB. For this reason, PF_KEY sockets are not specific to IPsec.

IPsec also requires a security policy database, or SPDB. The security policy database describes requirements for traffic; for example, traffic between host A and host B must be authorized using IPsec AH, and any that is not must be dropped. The SADB describes how to perform the required security steps, such as, if traffic between host A and host B is using IPsec AH, then the SADB contains the algorithm and key to use. Unfortunately, there is no standard mechanism to maintain the SPDB. PF_KEY allows maintenance of the SADB, but not the SPDB. KAME's IPsec implementation uses PF_KEY extensions for SPDB maintenance, but there is no standard for this.

Three types of operations are supported on key management sockets:

A process can send a message to the kernel and all other processes with open key management sockets by writing to a key management socket. This is how SADB entries are added and deleted, and how processes that do their own security like OSPFv2 can request a key from a key management daemon.
A process can read a message from the kernel (or another process) on a key management socket. The kernel can use this facility to request that a key management daemon install a security association for a new TCP session that policy requires be protected.
A process can send a dump request message to the kernel, and the kernel will reply with a dump of the current SADB. This is a debugging feature that may not be available on all systems.

[ Team LiB ]