Refining the IPsec Peer Authorization Database Steve Kent 2401bis PAD Highlights • The PAD specifies how to authenticate each peer, e.g., via shared secret or use of a certificate, and how to obtain revocation status info if certificates are used • The PAD specifies the TSi addresses or symbolic names that a peer is authorized to represent when (child) SAs are negotiated and that are used for SPD lookup • If symbolic names are specified, they are compared to the IKE ID, otherwise the TSi values from CREATE CHILD SA are used • The ID of the peer is taken from the IKE ID payload (this identity may be completely independent from child SA IDs) PAD Model Auth method Child SA Revocation Peer ID flag & auth data constraints status address range or address range or symbolic name symbolic name Use IKE ID or TSi? Pointer to CRL or OCSP data, if Shared secret or certificates are Certificate (EE or TA) used Why Constraints? • Need to know whether SAs created by a peer will be identified in the SPD by symbolic name, or by address • For name, use IKE ID to locate SPD entry, otherwise use TSi • Apply constraints before doing SPD lookup, to prevent an authenticated peer from creating SAs for which it is not authorized Matching Rules for the PAD • Two forms of matching take place in the PAD – Using the IKE ID payload as a key to locate a PAD entry – Using child SA constraints to filter the TSi address or IKE ID, before doing an SPD lookup • The PAD should accommodate matching rules for names, and range matching for IP addresses, to facilitate concise expression of both sets of info More Matching • The Peer ID may be a symbolic name (DN, FQDN, or RFC 822 address) or an IP address (v4 or v6) • The child SA constraints may be of the same types, to accommodate named SPD entries • For FQDN and RFC 822 address, star-name matching seems appropriate • For DNs, there are matching rules from X.500 • For addresses, ranges seem appropriate Example PAD Entries IKE IKE Auth SA Revocation Peer ID Data Constraints info sg.bbn.com Certificate for IPv4: 220.127.116.11- OCSP server sg.bbn.com 18.104.22.168 name and public key *@bbn.com Certificate for *@bbn.com (user LDAP server bbn.com (TA) names) name for bbn.com CRL *@bbn.com Certificate for IPv4: 22.214.171.124- OCSP server bbn.com (TA) 126.96.36.199 name and public key More Example PAD Entries IKE Peer IKE Auth SA Revocation ID Data Constraints info C = US, O = Shared IPv4: 188.8.131.52- N/A BBN, OU = secret 184.108.40.206 Security Dept, CN = Stephen Kent NOT IPv4: N/A 220.127.116.11- 18.104.22.168 22.214.171.124 Shared IPv4: 126.96.36.199- N/A secret 188.8.131.52 Is This What We Need? • Does it cover what implementations do today? • Does the PAD need to be ordered, like the SPD, because of possible peer ID name overlaps? • Are any important cases not covered? • Do we need to accommodate self-signed certificates, and if so, how? • Do we need negative SA constraints entry to accommodate self-signed certificates while also accommodating other, authenticated peers?