Routing Authentication Policy Database

This specification introduces a conceptual database, the Routing Authentication Policy Database (RAPD). The RAPD compliments the key table , which provides manually configured keys, while the RAPD provides policies for automated key management. According to the key table, in order to request a key to send a message, a routing protocol implementation needs to specify the information of "peer" and "protocol". The peer is either the identity of a unicast peer or of a group. The form of the peer identifier is specified by the specific routing protocol in question. The peer and protocol values are sufficient to find an existing key. If no proper key exists, the RAPD will be consulted. In this case, the peer and protocol values are also used to locate the appropriate automated key management policies from the RAPD. During the authentication and key distribution with a remote peer, the RAPD is also used by the key management application to obtain the authentication and authorization information necessary for the key management. In this case, the key management application needs to provide the RAPD with the IKE identity of the peer. The critical functions embodied by the RAPD are listed as follows: Identifying the peers or groups of peers that are authorized for a particular routing protocol Judging whether automated key management is expected for a particular routing protocol peer or group Specifying the key management protocols that this router needs to participate in and on what interfaces Provisioning the identities and credentials used to authenticate to a remote key-management peer Constraining the acceptable identities and credentials when a remote key-management peer authenticates to the local system Specifying the parameters and transforms used for a particular security association The services that the RAPD provides are analogus to the services that the Security Policy Database (SPD) and the Peer Authorization Database (PAD) provide to IKEv2 . This document requires the support of the IKEv2 extension specified in . To benefit the discussion, in this document, the IKEv2 extension is used as an example to describe how the RAPD can be applied in securing unicast routing protocol packets.

The RAPD contains an entry for each peer or group of peers to which automated key management mechanisms will be applied by the local system in securing the routing protocol exchanges. An RAPD entry also includes the information identifying the expected automated key management protocol and provides associated information used for authentication by the automated key management protocol. For instance, in order to establish an IKE SA, the following information is needed: Identity of the local system to use Identities acceptable for the remote endpoint Credential to use for the local system Authentication information for the remote system; see . Lifetime information Acceptable transforms In order to establish a routing SA keyed by an IKE SA, the following information is needed: Peer and protocol Acceptable transforms Additional information is required for multicast policy.

An RAPD entry needs to include enough authentication information so that the remote peer can be authenticated according to the pre-specified policies. The required information tends to break down along the same lines as the credential types discussed in section 4 of . For pre-shared keys, mutual authentication is obtained by using the same key in both directions. In this case the credential for outbound authentication is a pre-shared key. For inbound authentication, multiple acceptable credentials can be provided. For public keys used outside of authentication, authentication needs to happen in each direction. Each peer needs a private key and potentially a certificate to send as a credential. Each peer also needs a set of acceptable fingerprints for the remote key-management peer's key or certificate. When a PKI is used, each peer needs a private key and a certificate as a credential. In addition, trust anchors and constraints on how to validate whether an asserted identifier is appropriate for the presented certificate are required. An entry used with certificate-based authentication MAY include additional data to facilitate certificate revocation status, e.g., a pointer to a CRL repository or the name of an Online Certificate Status Protocol (OCSP) server.

One open question is how to organize the RAPD. As described in Section 1, when processing an outgoing packet, the local system will try to find the proper key table entry using the peer and protocol information first. If no proper key material can be found in the key table, the local system will try to use the same information to find a proper RAPD entry. When an incoming packet belongs a automated key management exchange, the RAPD may be consulted by the automated key management mechanism to find out the necessary knowledge to perform authentication and authorization. Use IKEv2 as an example. When a local system receives an IKE_INIT packet, it needs to perform the IKE_INIT exchange with its remote peer without consulting the RAPD, since at this stage, the incoming packet does not contain any information to prove the peer's identity. Then, when receiving an IKE_AUTH packet, the local system can use the remote peer's IKE ID from the Identification Payload, the protocol ID in the Proposal, and the peer information from the Traffic Selector. Therefore, the automated key management mechanism can use peer and protocol information to look up the associated policies in the key table. Note that it is not mandated in the key table to use the protocol IDs specified in to present security or routing protocols in the protocol field. Therefore, the automated key management mechanism needs to transfer the information into the key table compatible format before using them to find the RAPD entry. One approach to organizing the RAPD could be to separate incoming and outgoing policies and use two different databases. This is highly undesirable from an operational standpoint. In general it is not possible to know ahead of time which router will initiate a key management exchange. For this reason, it is strongly desired that the policy be symmetric. That is, an association SHOULD successfully authenticate and be authorized independent of which party initiates the association. There are exceptions; for example, in a multicast association, one router MAY be configured not to take on the role of a Group Controller/Key Server (GCKS) and such a router could not respond to key-management associations. The second approach is to have a single database indexed by the tuple containing peer and protocol as well as the set of acceptable remote identifiers. The third approach is to have two databases. One contains the peer, protocol, unicast key management endpoint and a policy identifier. The second database contains the remaining information along with a policy identifier. It is indexed by the policy identifier and by the set of acceptable remote identifiers. This layout is very similar to the breakdown between IPsec's SPD and PAD. All of these approaches assume that the set of acceptable remote identifiers is enumerated in the policy database. In a PKI this may be undesirable.

This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC.