Routing Authentication Policy Database
Huawei
zhangdacheng@huawei.com
Painless Security
hartmans@painless-security.com
Concordia University/CSE
1455 de Maisonneuve Blvd, West
Montreal
QC
H3G 1M8
Canada
+1(514)848-2424 ext3046
william.atwood@concordia.ca
http://users.encs.concordia.ca/~bill
This document proposes a conceptual database, the Routing
Authentication Policy Database (RAPD), which cooperates with the key
table to provide the configuration information for the automated key
management protocols in generating key materials for routing protocols.
Additionally, the RAPD also provides authorization policies so as to
guarantee that the keying material for securing routing protocol
exchanges is distributed only to the appropriate peers.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
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.