Internet DRAFT - draft-zhang-karp-rapd
draft-zhang-karp-rapd
Network Working Group D. Zhang
Internet-Draft Huawei
Intended status: Experimental S. Hartman
Expires: April 24, 2014 Painless Security
W. Atwood
Concordia University/CSE
October 21, 2013
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 24, 2014.
Copyright Notice
Zhang, et al. Expires April 24, 2014 [Page 1]
Internet-Draft RAPD October 2013
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
2. Contents of an RAPD Entry . . . . . . . . . . . . . . . . . . 3
3. RAPD Authentication Information for IKEv2 . . . . . . . . . . 4
4. Organization and Lookup . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
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
Zhang, et al. Expires April 24, 2014 [Page 2]
Internet-Draft RAPD October 2013
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:
o Identifying the peers or groups of peers that are authorized for a
particular routing protocol
o Judging whether automated key management is expected for a
particular routing protocol peer or group
o Specifying the key management protocols that this router needs to
participate in and on what interfaces
o Provisioning the identities and credentials used to authenticate
to a remote key-management peer
o Constraining the acceptable identities and credentials when a
remote key-management peer authenticates to the local system
o 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:
o Identity of the local system to use
o Identities acceptable for the remote endpoint
Zhang, et al. Expires April 24, 2014 [Page 3]
Internet-Draft RAPD October 2013
o Credential to use for the local system
o Authentication information for the remote system; see Section 3.
o Lifetime information
o Acceptable transforms
In order to establish a routing SA keyed by an IKE SA, the following
information is needed:
o Peer and protocol
o 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.
Zhang, et al. Expires April 24, 2014 [Page 4]
Internet-Draft RAPD October 2013
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.
Zhang, et al. Expires April 24, 2014 [Page 5]
Internet-Draft RAPD October 2013
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
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[I-D.ietf-karp-crypto-key-table]
Housley, R., Polk, T., Hartman, S., and D. Zhang,
"Database of Long-Lived Symmetric Cryptographic Keys",
draft-ietf-karp-crypto-key-table-08 (work in progress),
July 2013.
[I-D.ietf-karp-ops-model]
Hartman, S. and D. Zhang, "Operations Model for Router
Keying", draft-ietf-karp-ops-model-09 (work in progress),
October 2013.
[I-D.mahesh-karp-rkmp]
Jethanandani, M., Weis, B., Patel, K., Zhang, D., Hartman,
S., Chunduri, U., Tian, A., and J. Touch, "Negotiation for
Keying Pairwise Routing Protocols in IKEv2", draft-mahesh-
karp-rkmp-04 (work in progress), February 2013.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
Authors' Addresses
Zhang, et al. Expires April 24, 2014 [Page 6]
Internet-Draft RAPD October 2013
Dacheng Zhang
Huawei
Email: zhangdacheng@huawei.com
Sam Hartman
Painless Security
Email: hartmans@painless-security.com
William Atwood
Concordia University/CSE
1455 de Maisonneuve Blvd, West
Montreal, QC H3G 1M8
Canada
Phone: +1(514)848-2424 ext3046
Email: william.atwood@concordia.ca
URI: http://users.encs.concordia.ca/~bill
Zhang, et al. Expires April 24, 2014 [Page 7]
