Why does the IPsec architecture keep a Peer Authorization Database beside the SPD, and what does it stop an authenticated peer from doing?

## Three databases, three questions RFC 4301 models an IPsec implementation around three nominal databases: | Database | Question it answers | |---|---| | **SPD** (Security Policy Database) | Which traffic is protected, bypassed or discarded, and how? | | **SAD** (Security Association Database) | What state does each existing SA hold? | | **PAD** (Peer Authorization Database) | Which peers may set up SAs, how are they authenticated, and what may each one claim? | The PAD exists because authentication and authorisation are different questions. IKE proves who a peer is; the PAD decides what that peer is allowed to ask for. ## What a PAD entry holds Each entry names an individual peer (a user, an end system or a security gateway) or a group of peers, and specifies: - **The ID that selects it.** RFC 4301 supports six ID types: DNS name, distinguished name, RFC 822 email address, IPv4 address range, IPv6 address range and key ID. The first three allow sub-tree matching, such as every name ending in `.example.com`; key IDs match exactly. - **The authentication protocol and method.** RFC 4301 requires support for X.509 certificates and pre-shared secrets. - **The authentication data.** For certificates, the trust anchor the peer's certificate must chain to, optionally with revocation information; for pre-shared secrets, the secret itself. - **Child SA authorisation.** Whether the peer's IKE ID is used as a symbolic name to find SPD entries, or whether addresses it asserts in traffic selectors are used, in which case the entry carries the IPv4 and IPv6 ranges the peer may claim. - Optionally, location information for peers that sit behind a gateway. Because sub-tree names overlap, the PAD is **ordered** by the administrator, for the same reason the SPD is. ## How the PAD is used during IKE 1. Each side asserts an identity in the IKE ID payload and proves it with the AUTH payload, optionally with certificates. 2. The receiver searches the PAD in order for an entry matching the asserted ID. 3. That entry dictates the authentication method and data, so different peers can use different methods, and the peer is authenticated before any Child SA is created. 4. When the peer proposes traffic selectors, the PAD entry decides how the SPD is searched: by the peer's IKE ID, or by the addresses it asserted, constrained to its authorised ranges. 5. Only then is an SPD entry selected and an SA pair created. ## The threat it closes Picture a hub gateway serving many branch gateways whose certificates all chain to one organisational trust anchor. Every branch can authenticate successfully. Without the PAD's child SA constraint, an authenticated branch, whether misconfigured or compromised, could propose traffic selectors naming another branch's subnet. The hub would find a matching `PROTECT` entry, create the SA, and start sending that subnet's traffic to the wrong peer. RFC 4301 states the purpose directly: the constraints exist to prevent an authenticated peer from spoofing IDs associated with other, legitimate peers. Because the PAD is checked before the SPD is searched, the same binding protects an initiator: any peer it contacts as the presumed gateway for an address must be registered in the PAD, and when that peer claims to represent the address in its traffic selectors, the PAD decides whether it may. The PAD provides a binding of address ranges or name sub-spaces to peers. ## Operating the PAD - **Keep it coordinated with the SPD.** RFC 4301 expects the same administrator to manage both, since an SPD entry is useless if no PAD entry authorises a peer to request it, and dangerous if the PAD authorises too much. - **Bind IDs to certificates.** Implementations MUST let an administrator require the asserted IKE ID to match the certificate's subject name or subject alternative name, which matters when one PAD entry covers a group of peers with distinct SPD entries. - **Remote users.** For users whose addresses are unknown in advance, a named SPD entry matched through the IKE ID is the mechanism, and the user's inner source address is bound into the resulting SAD entry. - **Group entries are a trade-off.** One sub-tree entry for every branch is easy to run, but its ranges must still be per peer, or the entry authorises every branch to claim every subnet.