RFC 7210

Database of Long-Lived Symmetric Cryptographic Keys 🎀

Okay bestie, this is RFC 7210 and it's giving serious infrastructure main-character energy 💅✨. Here's the title block tea ☕:

• RFC number: 7210
• Title: Database of Long-Lived Symmetric Cryptographic Keys
• Authors: R. Housley (Vigil Security), T. Polk (NIST), S. Hartman (Painless Security), and D. Zhang (Huawei Technologies Co. Ltd.)
• Category: Standards Track
• ISSN: 2070-1721
• Date: April 2014
• Obsoletes/Updates: the title block doesn't list anything this one obsoletes or updates 🦋

---

Abstract 🌸

Okay so this doc lays out the info that goes into a conceptual database of long-lived cryptographic keys, the kind that tons of different routing protocols use to keep their messages secure 🔐. The database is built to support both manual and automated key management, which is so iconic. 💖 Beyond describing the schema (the blueprint for what goes in the database), it also covers the operations you can do on the database and the requirements for routing protocols that want to use it. Here's the lowkey plot twist 😭: in a lot of typical setups, the protocols don't actually use the long-lived key directly. Instead, a key derivation function takes that long-lived key and derives a short-lived key from it. Iykyk 🧚

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, and it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741 🫶.

For the current status of this document, any errata, and how to give feedback on it, head to http://www.rfc-editor.org/info/rfc7210 🍓.

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) as in effect on the date this document was published. Please actually read these, bestie, because they spell out 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 they're provided without warranty as described in the Simplified BSD License.

---

1. Introduction ✨

Okay, so this document spells out the info 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 stuff from both manual and automated key management, which is so clean 💅. The goal is to let lots of different implementation approaches to this key database exist while keeping specification simple and deployments heterogeneous (mixed, basically) 🌈. It also avoids the need to build knowledge of any security protocol into key management protocols, and it minimizes protocol-specific knowledge in operational and management interfaces, and it constrains where that knowledge can even show up. Iconic restraint, honestly 👑.

Textual conventions are provided for representing keys and other identifiers. These conventions should be used when presenting keys and identifiers to operational or management interfaces, or when reading keys and identifiers from those interfaces. This is the vibe that satisfies the operational requirement that all implementations represent keys and key identifiers in the same way, so cross-vendor configuration instructions can be provided 🧚✨.

Routing protocols can use 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 related entries in this document's conceptual database get manipulated 💖.

Here's the plot twist again 😭: in many cases, the long-lived keys aren't used directly in security protocols. Instead, a key derivation function derives short-lived keys from the long-lived key in the database. In other cases, security protocols will directly use the long-lived key from the database. The database design supports both use cases, and I'm obsessed 🔥.

1.1. Requirements Notation 🎀

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] 💅.

2. Conceptual Database Structure ✨

okay so the database is basically a table, and every row is one long-lived symmetric cryptographic key 🔑 Normally each key gets exactly one row, bestie. The only times a key shows up in multiple rows are the (hopefully) super rare cases where it's used for more than one purpose, or where the same key is paired with multiple key derivation functions (KDFs) 🫶 The columns hold the key value and all of its attributes.

Since humans are gonna be managing these by hand, the fields are formatted so you can edit them in a plain-text editor and they look the same on multiple systems. Very considerate of the spec, honestly 🎀

Here are the columns, in order:

AdminKeyName The AdminKeyName field is a human-readable string that helps the user identify the key 💖 Implementations can use it to uniquely identify rows in the key table. The same string can be used on the local system and on peer systems, but that's not required. Routing protocols don't use this string at all. They use LocalKeyName and PeerKeyName instead. BUT if these strings are going to be used as protocol elements in other protocols, or passed around between systems, they'll need to follow the requirements of Section 5.1 ✨

LocalKeyName The LocalKeyName field is a string that identifies the key 🗝️ It's what you use to look up the key in the local database when it shows up in a message. As Section 4 explains, the protocol decides what form this field takes. For example, lots of routing protocols only allow key names that are integers which fit in 16 or 32 bits. This field usually doesn't hold data in human character sets that need internationalization. If a routing protocol ever does need internationalized key names, its spec will have to deal with canonicalization and normalization, so the names can be compared using binary comparison 🤓

PeerKeyName PeerKeyName is the name of the key that the local system uses in an outgoing message 📤 For unicast communication, the PeerKeyName of a key on one system matches the LocalKeyName of the identical key maintained on one or more peer systems. Same as LocalKeyName, the protocol defines the form of this identifier and will often restrict it to an integer 🍓 For group keys, the protocol will typically require this field to be an empty string, because the sending and receiving key names need to be the same 👑

Peers For unicast keys, this field usually lists the peer systems that have this key in their database 🧚 For group keys, it names the groups the key is appropriate for. For example, it might name a routing area for a multicast routing protocol. Basically this field sets a protocol-specific scope on where the key is allowed to be used. The protocol specifies the format of the identifiers in Peers 💅

Interfaces The Interfaces field identifies the set of physical and/or virtual interfaces where it's appropriate to use this key 🦋 When the long-lived value in the Key field is meant to be used on any interface, this field is set to "all". The field is a set of strings, and the implementation decides what those strings look like, totally independent of the protocol 🌈 Protocols might require support for Interfaces, or they might say that constraining keys by interface isn't required. Example time: TCP-AO implementations are unlikely to pick the interface before they pick the key. So in that case they're expected to use the same keying material across all interfaces and then require the "all" setting 😭

Protocol The Protocol field names a single routing protocol that this key may be used with to provide cryptographic protection 🛡️ This specification sets up a registry for this field. The registry also specifies the format of the next field, ProtocolSpecificInfo, for each registered protocol 📚

ProtocolSpecificInfo This field holds protocol-specified information that can help a protocol apply the key correctly ✨ Important bit: such information MUST NOT be required for a protocol to locate an appropriate key. If a protocol doesn't need the information in ProtocolSpecificInfo, it will require this field to be empty. Key table rows MAY specify a Direction of "both". Because of that, the encoding of this field has to support encoding protocol-specific information for sending and receiving in the same row 🙈

KDF The KDF field says which key derivation function is used to generate short-lived keys from the long-lived value in the Key field 🔥 When the long-lived value is meant for direct use, KDF is set to "none". A key derivation function is a one-way function that gives you cryptographic separation of key material 🧠 The KDF MAY use inputs from the row in the key table and from the message being sent or received, but it MUST NOT depend on other configuration state. This document sets up an IANA registry for the values in the KDF field, so future specs can reference them easily 📋 The protocol decides which KDFs (if any) are valid.

AlgID The AlgID field says which cryptographic algorithm gets used with the security protocol for the specified peer or peers 🔐 It can be an encryption algorithm and mode (for example, AES-128-CBC), an authentication algorithm (for example, HMAC-SHA1-96 or AES-128-CMAC), or any other symmetric cryptographic algorithm a security protocol needs 💜 If KDF contains "none", the long-lived key gets used directly with this algorithm. Otherwise, the derived short-lived key is what gets used 🫧 When the long-lived key is used to generate a set of short-lived keys, AlgID identifies a ciphersuite rather than a single algorithm. This document also sets up an IANA registry for the values in AlgID so future specs can reference them 🎀 Protocols decide which algorithms are appropriate.

Key The Key field holds the long-lived symmetric cryptographic key as a lowercase hexadecimal string 🗝️ How big the key has to be depends on the KDF and the AlgID. For instance, KDF=none and AlgID=AES128 need a 128-bit key, which is written as 32 hexadecimal digits 🧮

Direction The Direction field says whether this key can be used for inbound traffic, outbound traffic, both, or whether the key has been disabled and can't be used at all right now 🚫 The supported values are "in", "out", "both", and "disabled", respectively. The Protocol field decides which of these values are valid 🦋

SendLifetimeStart The SendLifetimeStart field specifies the earliest date and time, in Coordinated Universal Time (UTC), at which this key should be considered for use when sending traffic ⏰ The format is YYYYMMDDHHSSZ: four digits for the year, two for the month, two for the day, two for the hour, two for the minute, and two for the second. The "Z" is included as a clear sign that the time is in UTC 🌍

SendLifeTimeEnd The SendLifeTimeEnd field specifies the latest date and time at which this key should be considered for use when sending traffic 🌙 The format is the same as SendLifetimeStart.

AcceptLifeTimeStart The AcceptLifeTimeStart field specifies the earliest date and time, in Coordinated Universal Time (UTC), at which this key should be considered for use when processing received traffic 📥 The format is YYYYMMDDHHSSZ, where four digits specify the year, two digits specify the month, two digits specify the day, two digits specify the hour, two digits specify the minute, and two digits specify the second. The "Z" is included as a clear indication that the time is in UTC 💫

AcceptLifeTimeEnd The AcceptLifeTimeEnd field specifies the latest date and time at which this key should be considered for use when processing received traffic 🥹 Its format is identical to AcceptLifeTimeStart.

3. Key Selection and Rollover ✨

okay so a protocol can literally peek at the key table to grab the key for an outgoing message 👀 🎀. It hands the key selection function a protocol (P) and a peer identifier (H), and sometimes an interface identifier (I) too if it needs one. A key is fair game if it passes all of these checks:

1. the Peers field includes H;
2. the Protocol field matches P;
3. if the protocol specifies an interface, the Interfaces field in the key table row includes I or "all";
4. the Direction field is either "out" or "both"; and
5. SendLifetimeStart <= current time <= SendLifeTimeEnd.

Multiple entries can be alive at the same time, each tied to a different cryptographic algorithm or ciphersuite 🧁. So systems should support picking keys by algorithm preference, which makes it way easier to switch algorithms later 🔄.

Also, when entries have overlapping valid periods, they're meant to be ready for an orderly key rollover 🦋. The idea is that systems move over to the newest key available. To make that happen, this specification recommends adding one more rule on top of the selection algorithm: pick the long-lived key with the most recent time in the SendLifetimeStart field 💅.

When a protocol wants to check an incoming message, it gives over its protocol (P), the peer identifier (H), the key identifier (L), and optionally the interface (I) 📥. A single key that matches all of these conditions gets selected:

1. the Peer field includes H;
2. the Protocol field matches P;
3. if the Interface field is provided, it includes I or is "all";
4. the Direction field is either "in" or "both";
5. the LocalKeyName is L; and
6. AcceptLifeTimeStart <= current time <= AcceptLifeTimeEnd.

Heads up: the AcceptLifeTime times are only a loose boundary on key usage 🫶. New security associations should not be established outside the period of use in these fields, though some grace time for clock skew is allowed ⏰. If a security association is already up using a long-lived key, going past the lifetime doesn't directly break anything 😌. Implementations of security protocols with long-lived associations should be designed to periodically check the database and roll over to new keys without tearing down the security associations 🔁.

Instead of checking the conceptual database every time, a security protocol like TCP-AO might just update its own tables as keys get added or removed 🧚. In that case, the protocol has to keep its own key information. Some routing protocols use IP Security (IPsec) for integrity 🛡️. If a specification explains how to use the conceptual database in this document to set up keys for those routing protocols, the same concerns apply. That specification also needs to describe how the Security Policy Database is changed as rows are added and removed from the conceptual database 💜.

4. Application of the Database in a Security Protocol ✨

okay so if a protocol wants to use the key table database, its spec has to cover certain things 📝. This section lists what a protocol must specify 🎀.

1. The ways of mapping the information in a key table row to the information needed to produce an outgoing message. This is either an explanation of how to fill in authentication-related fields in a message based on key table information, or (for protocols such as TCP-AO) how to build Master Key Tuples (MKTs) or other protocol-specific structures from a key table row.
2. The ways of finding the peer identifier (a member of the Peers set) and the LocalKeyName inside an incoming message 🔍.
3. The methods for verifying a message given a key table row. This can be stated directly or in terms of protocol-specific structures such as MKTs 🔐.
4. The form and validation rules for LocalKeyName and PeerKeyName. If either of these is an integer, the conventions in Section 5.1 are used as a vendor-independent format 🔢.
5. The form and validation rules for members of the Peers set 👯.
6. The algorithms and KDFs supported 🧪.
7. The form of the ProtocolSpecificInfo field 📦.
8. The rules for canonicalizing LocalKeyName, PeerKeyName, entries in the Peers set, or ProtocolSpecificInfo. This may include normalizations such as lowercasing hexadecimal strings 🔤.
9. The indication of whether support for Interfaces is required by this protocol 🔌.

The form of the interfaces field isn't protocol specific. It's shared across all protocols on an implementation 🤝. If a protocol needs to tell apart instances running over the same interface, that goes in the specification of peers 💅. Generally, it's ideal to define the peers specification so an operator can use the Interfaces field to refer to all instances of a protocol on a link. That way they don't have to specify both generic interfaces information and protocol-specific peer information 🙌.

5. Textual Conventions 🎀

5.1. Key Names

When a key for a given protocol is identified by an integer key identifier, the key name is written as lowercase hexadecimal digits, most significant octet first 🔢. The integer is padded with leading zero digits until it reaches the width of the key identifier field in the protocol 📏. If a key name has non-integer human-readable text, its format and encoding can get messy, especially when it's used in protocols between two different types of systems 😬. If ASCII range characters [RFC20] are enough for a key name, then they SHOULD be used 🌸. If characters outside that range are wanted or needed, then they MUST be in an encoding of Unicode [UNICODE] 🌈.

For an AdminKeyName with characters outside the ASCII range, the AdminKeyName MUST be encoded using UTF-8 [RFC3629] and SHOULD be normalized using Unicode Normalization Form KC [UAX15]. This gives strings the best chance of comparing correctly 💖.

Still, Unicode Normalization Form KC alone doesn't solve every string comparison issue 🙈. Check [PRECIS-FRAMEWORK] for more info 📚.

5.2. Keys

A key is written as a lowercase hexadecimal string, with its most significant octet first 🧚. As discussed in Section 2, how long this string is depends on the associated algorithm and KDF 📏.

6. Operational Considerations 🌷

If the valid periods for long-lived keys don't overlap, or the system clocks are out of sync, some scenarios can happen where systems just can't agree on a long-lived key 😭. When installing a series of keys to be used one after another, operators should set the SendLifetimeStart field of the key to several hours after the AcceptLifeTimeStart field of the key. That way there's guaranteed overlap ⏳. The overlap is there to handle clock skew and cover basic operational stuff 🫧. Operators may choose a longer overlap (for example, several days) for exceptional circumstances 🗓️.

7. Security Considerations 💀

Managing encryption and authentication keys has been a huge operational headache, both for key synchronization and key selection 😩. For example, the current guidance [RFC3562] warns against sharing TCP MD5 keying material between systems and recommends changing keys on a schedule 🔑. The same general operational issues come up for managing other cryptographic keys too 🥺.

[RFC4107] points out that automated key management isn't viable in multiple scenarios 🚫. The conceptual database in this document is built to handle both manual and automated key management 🤖. A future specification to automatically fill rows in the database is envisioned ✨.

Designers should keep in mind the warning from [RFC4107] 👀:

Automated key management and manual key management provide very different features. In particular, the protocol associated with an automated key management technique will confirm the liveness of the peer, protect against replay, authenticate the source of the short-term session key, associate protocol state information with the short-term session key, and ensure that a fresh short-term session key is generated. Further, an automated key management protocol can improve interoperability by including negotiation mechanisms for cryptographic algorithms. These valuable features are impossible or extremely cumbersome to accomplish with manual key management.

8. IANA Considerations 📋

This specification defines three registries 🗂️.

8.1. KeyTable Protocols

Per this document, IANA has set up a registry called "KeyTable Protocols" 🎀.

All assignments to the KeyTable Protocols registry are made on a Specification Required basis per Section 4.1 of [RFC5226] 📝.

Each registration entry must contain these three fields:

• Protocol Name (unique within the registry);
• Protocol-Specific Info; and
• Reference.

The specification needs to describe the parameters required for using the conceptual database as outlined in Section 4. Typically, that means the specification focuses on applying security protocols with the key tables, rather than being a brand new general-purpose security protocol 💅. Of course, new protocols can combine info on how to use the key table database with the protocol spec too 🫶.

The registry has three columns 🧾. The first column is a string of Unicode characters encoded in UTF-8, showing the name of the protocol. The second column is a string of Unicode characters encoded in UTF-8, giving a brief description of Protocol-Specific Info. The third column is a reference to a specification that defines how the protocol is used with the key table 📚.

There are no initial registrations 🫥.

8.2. KeyTable KDFs

Per this document, IANA has set up a registry called "KeyTable KDFs". The rest of this section describes the registry 🌈.

All assignments to the KeyTable KDFs registry are made on a First Come First Served basis per Section 4.1 of RFC 5226 🏃‍♀️.

The registry has three columns 💜. The first column is a string of Unicode characters encoded in UTF-8, showing the name of a KDF. The second column is a string of Unicode characters encoded in UTF-8, giving a brief description of the KDF. The third column is a reference to a specification that defines the KDF, if one is available 🔖.

The initial contents of this registry and the one in Section 8.3 are based on the algorithms defined for TCP-AO [RFC5926] 🧁.

KDF             Description                     Reference
------------    ----------------------------    ---------
none            No KDF is used with this key    N/A
AES-128-CMAC    AES-CMAC using 128-bit keys     [RFC4493]
HMAC-SHA-1      HMAC using the SHA-1 hash       [RFC2104]

8.3. KeyTable AlgIDs 🔐

Okay so, per this document, IANA set up a registry called "KeyTable AlgIDs" 🎀 Everything below describes that registry, so let's dive in ✨

Assignments to the KeyTable AlgIDs registry are made on a First Come First Served basis per Section 4.1 of RFC 5226. Basically first come, first served 💅

The registry has three columns 📋 The first is the algorithm identifier (AlgID), a string of Unicode characters encoded in UTF-8. The second is a brief description of the algorithm, also Unicode in UTF-8. The third is a reference to the specification that defines the algorithm 🦋

The starting contents of this registry, and the ones in Section 8.2, were picked based on the algorithms defined for TCP-AO [RFC5926]. Very on-brand for TCP-AO, honestly 🫶

   AlgID             Description                          Reference
   ------------      ---------------------------------    ---------
   AES-128-CMAC      AES-CMAC using 128-bit keys          [RFC4493]
   AES-128-CMAC-96   AES-128-CMAC truncated to 96 bits    [RFC5926]
   HMAC-SHA-1-96     HMAC SHA-1 truncated to 96 bits      [RFC2104]

---

9. Acknowledgments 💜

This document reflects many discussions with many different people over many years 🌸 The authors want to thank Jari Arkko, Ran Atkinson, Ron Bonica, Ross Callon, Lars Eggert, Pasi Eronen, Adrian Farrel, Gregory Lebovitz, Acee Lindem, Sandy Murphy, Eric Rescorla, Mike Shand, Dave Ward, and Brian Weis for their insights 🧚 They also thank Brian Weis for writing text to address IANA concerns and for helping with formatting 🙈

Sam Hartman's work on this document is funded by Huawei 💖

---

10. Normative References 📚

[RFC20]    Cerf, V., "ASCII format for network interchange", RFC 20,
           October 1969.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[UAX15]    The Unicode Consortium, "Unicode Standard Annex #15:
           Unicode Normalization Forms", Unicode 6.3.0, September
           2013, <http://www.unicode.org/reports/tr15/tr15-39.html>.

[UNICODE]  The Unicode Consortium, "The Unicode Standard, Version
           6.3.0", (Mountain View, CA: The Unicode Consortium, 2013.
           ISBN 978-1-936213-08-5),
           <http://www.unicode.org/versions/Unicode6.3.0/>.

---

11. Informative References 🌈

[PRECIS-FRAMEWORK]
           Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
           Preparation and Comparison of Internationalized Strings in
           Application Protocols", Work in Progress, March 2014.

[RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
           Hashing for Message Authentication", RFC 2104, February
           1997.

[RFC3562]  Leech, M., "Key Management Considerations for the TCP MD5
           Signature Option", RFC 3562, July 2003.

[RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
           10646", STD 63, RFC 3629, November 2003.

[RFC4107]  Bellovin, S. and R. Housley, "Guidelines for Cryptographic
           Key Management", BCP 107, RFC 4107, June 2005.

[RFC4493]  Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
           AES-CMAC Algorithm", RFC 4493, June 2006.

[RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
           IANA Considerations Section in RFCs", BCP 26, RFC 5226,
           May 2008.

[RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
           Authentication Option", RFC 5925, June 2010.

[RFC5926]  Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms
           for the TCP Authentication Option (TCP-AO)", RFC 5926,
           June 2010.

---

Authors' Addresses 🎀

Russell Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
USA
EMail: housley@vigilsec.com

Tim Polk
National Institute of Standards and Technology
100 Bureau Drive, Mail Stop 8930
Gaithersburg, MD 20899-8930
USA
EMail: tim.polk@nist.gov

Sam Hartman
Painless Security, LLC
USA
EMail: hartmans-ietf@mit.edu

Dacheng Zhang
Huawei Technologies Co. Ltd.
China
EMail: zhangdacheng@huawei.com