Database of Long-Lived Symmetric Cryptographic Keys
RFC 7210

Document Type RFC - Proposed Standard (April 2014; Errata)
Authors Tim Polk  , Russ Housley  , Sam Hartman  , Dacheng Zhang 
Last updated 2020-01-21
Replaces draft-housley-saag-crypto-key-table
Stream IETF
Formats plain text html pdf htmlized with errata bibtex
Stream WG state Submitted to IESG for Publication
Document shepherd Brian Weis
Shepherd write-up Show (last changed 2013-08-06)
IESG IESG state RFC 7210 (Proposed Standard)
Consensus Boilerplate Yes
Telechat date
Responsible AD Adrian Farrel
Send notices to (None)
IANA IANA review state Version Changed - Review Needed
IANA action state RFC-Ed-Ack
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


   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

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
   ( 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