Routing Authentication Policy Database
draft-zhang-karp-rapd-00

Abstract

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.

Requirements Language

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 [RFC2119].

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 23, 2014.

Copyright Notice

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Contents of an RAPD Entry
• 3. RAPD Authentication Information for IKEv2
• 4. Organization and Lookup
• 5. IANA Considerations
• 6. Security Considerations
• 7. Acknowledgements
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Authors' Addresses

1. Introduction

This specification introduces a conceptual database, the Routing Authentication Policy Database (RAPD). The RAPD compliments the key table [I-D.ietf-karp-crypto-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 [RFC4301].

This document requires the support of the IKEv2 extension specified in [I-D.mahesh-karp-rkmp]. 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.

2. Contents of an RAPD Entry

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 Section 3.
• 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.

3. RAPD Authentication Information for IKEv2

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 [I-D.ietf-karp-ops-model].

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.

4. Organization and Lookup

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 [I-D.mahesh-karp-rkmp] 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.

5. IANA Considerations

This document makes no request of IANA.

Note to RFC Editor: this section may be removed on publication as an RFC.

6. Security Considerations

7. Acknowledgements

8. References

8.1. Normative References

8.2. Informative References

Authors' Addresses