Database of Long-Lived Symmetric Cryptographic Keys
RFC 7210
Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 7210 Vigil Security
Category: Standards Track T. Polk
ISSN: 2070-1721 NIST
S. Hartman
Painless Security
D. Zhang
Huawei Technologies Co. Ltd.
April 2014
Database of Long-Lived Symmetric Cryptographic Keys
Abstract
This document specifies the information contained in a conceptual
database of long-lived cryptographic keys used by many different
routing protocols for message security. The database is designed to
support both manual and automated key management. In addition to
describing the schema for the database, this document describes the
operations that can be performed on the database as well as the
requirements for the routing protocols that wish to use the database.
In many typical scenarios, the protocols do not directly use the
long-lived key, but rather a key derivation function is used to
derive a short-lived key from a long-lived key.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7210.
Housley, et al. Standards Track [Page 1]
RFC 7210 Table of Cryptographic Keys April 2014
Copyright Notice
Copyright (c) 2014 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.
1. Introduction
This document specifies the information that needs to be included in
a database of long-lived cryptographic keys in order to key the
cryptographic authentication of routing protocols. This conceptual
database is designed to separate protocol-specific aspects from both
manual and automated key management. The intent is to allow many
different implementation approaches to the specified cryptographic
key database, while simplifying specification and heterogeneous
deployments. This conceptual database avoids the need to build
knowledge of any security protocol into key management protocols. It
minimizes protocol-specific knowledge in operational/management
interfaces, and it constrains where that knowledge can appear.
Textual conventions are provided for the representation of keys and
other identifiers. These conventions should be used when presenting
keys and identifiers to operational/management interfaces or reading
keys/identifiers from these interfaces. This satisfies the
operational requirement that all implementations represent the keys
and key identifiers in the same way so that cross-vendor
configuration instructions can be provided.
Routing protocols can employ the services of more-generic security
protocols such as TCP-AO [RFC5925]. Implementations of routing
protocols may need to supply keys to databases specific to these
security protocols as the associated entries in this document's
conceptual database are manipulated.
In many instances, the long-lived keys are not used directly in
security protocols, but rather a key derivation function is used to
derive short-lived keys from the long-lived key in the database. In
other instances, security protocols will directly use the long-lived
key from the database. The database design supports both use cases.
Housley, et al. Standards Track [Page 2]
RFC 7210 Table of Cryptographic Keys April 2014
1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Show full document text