Database of Long-Lived Symmetric Cryptographic Keys
Extracted elements (27)
Separate SendLifetime and AcceptLifetime windows are defined to support orderly key rollover with overlapping valid periods. Operators should configure SendLifetimeStart several hours after AcceptLifeTimeStart to guarantee overlap and address clock-skew issues.
The conceptual database is designed to separate protocol-specific aspects from both manual and automated key management, avoiding the need to build knowledge of any security protocol into key management protocols. This minimizes protocol-specific knowledge in operational interfaces and allows many different implementation approaches.
The database supports both direct use of long-lived keys and use via a key derivation function to produce short-lived keys, because some security protocols use the long-lived key directly while others derive short-term session keys. The KDF field set to 'none' indicates direct use.
The format of the database fields was purposefully chosen to allow updates with a plain-text editor and to provide equivalent display on multiple systems, in order to accommodate manual key management. This includes the human-readable AdminKeyName and the hexadecimal key representation.
A protocol using the key table database must specify nine items: how to map table rows to outgoing messages, how to locate peer identifier and LocalKeyName in incoming messages, how to verify messages, form and validation rules for LocalKeyName/PeerKeyName, form and validation rules for Peers, supported algorithms and KDFs, form of ProtocolSpecificInfo, canonicalization rules, and whether Interfaces support is required.
Routing protocols that use security protocols such as TCP-AO may need to supply keys to databases specific to those security protocols as entries in this conceptual database are manipulated. Specifications mapping routing protocols onto this database must describe how the Security Policy Database is updated as rows are added or removed.
AdminKeyName that uses characters outside the ASCII range MUST be encoded using UTF-8 and SHOULD be normalized using Unicode Normalization Form KC to maximize the chance that strings will compare correctly.
If characters from the ASCII range are sufficient for a key name, they SHOULD be used. If characters outside that range are desirable or required, they MUST be in an encoding of Unicode.
ProtocolSpecificInfo MUST NOT be required for a protocol to locate an appropriate key; it contains only supplementary information that helps a protocol apply the key correctly after it has been found.
The KDF MAY use inputs from the row in the key table and the message being sent or received, but MUST NOT depend on other configuration state. This ensures cryptographic separation without hidden dependencies.
Four lifetime fields control key usage windows: SendLifetimeStart and SendLifeTimeEnd bound when the key may be used for sending; AcceptLifeTimeStart and AcceptLifeTimeEnd bound when the key may be used for processing received traffic. All are in UTC with format YYYYMMDDHHSSZ.
The AlgID field indicates which cryptographic algorithm is used with the security protocol (e.g., AES-128-CBC, HMAC-SHA1-96, AES-128-CMAC). When KDF is 'none', the long-lived key is used directly; otherwise the derived short-lived key is used. When a set of short-lived keys is generated, AlgID identifies a ciphersuite.
The conceptual key database is structured as a table where each row represents a single long-lived symmetric cryptographic key. Columns include AdminKeyName, LocalKeyName, PeerKeyName, Peers, Interfaces, Protocol, ProtocolSpecificInfo, KDF, AlgID, Key, Direction, and lifetime fields. Normally each key should have only one row.
The Direction field indicates whether a key may be used for inbound traffic ('in'), outbound traffic ('out'), both directions ('both'), or is disabled ('disabled'). The Protocol field determines which of these values are valid for a given protocol.
The KDF field indicates the key derivation function used to generate short-lived keys from the long-lived Key field value. When the long-lived key is intended for direct use, KDF is set to 'none'. A KDF is a one-way function that provides cryptographic separation of key material.
The LocalKeyName field contains a string identifying the key that can be used to retrieve it in the local database when received in a message. Many routing protocols restrict this to integers representable in 16 or 32 bits. Key names requiring internationalization must address canonicalization and normalization for binary comparison.
The PeerKeyName field is the name of the key used by the local system in an outgoing message. For unicast, PeerKeyName on the local system matches LocalKeyName on the peer. For group keys, this field is typically an empty string since sending and receiving key names must be the same.
IANA established the 'KeyTable AlgIDs' registry for cryptographic algorithm identifiers. Assignments are on a First Come First Served basis. Initial entries are: 'AES-128-CMAC' (RFC 4493), 'AES-128-CMAC-96' (truncated to 96 bits, RFC 5926), and 'HMAC-SHA-1-96' (HMAC SHA-1 truncated to 96 bits, RFC 2104).
IANA established the 'KeyTable KDFs' registry for key derivation function identifiers. Assignments are on a First Come First Served basis. Initial entries are: 'none' (no KDF), 'AES-128-CMAC' (RFC 4493), and 'HMAC-SHA-1' (RFC 2104), based on algorithms defined for TCP-AO.
IANA established the 'KeyTable Protocols' registry for protocol names that use the key table database. Assignments are made on a Specification Required basis. Each entry contains a Protocol Name (unique), Protocol-Specific Info description, and a reference. There are no initial registrations.
Automated key management provides features impossible or extremely cumbersome with manual key management: confirming peer liveness, protecting against replay, authenticating the source of short-term session keys, associating protocol state with session keys, ensuring fresh key generation, and supporting cryptographic algorithm negotiation.
Management of encryption and authentication keys has been a significant operational problem in terms of key synchronization and key selection. The conceptual database is designed to accommodate both manual key management and automated key management, with automated population of the database envisioned for future specifications.
Incoming key validation requires: (1) Peers field includes H, (2) Protocol field matches P, (3) Interfaces field includes I or 'all', (4) Direction is 'in' or 'both', (5) LocalKeyName equals L, and (6) AcceptLifeTimeStart <= current time <= AcceptLifeTimeEnd. Exceeding an established security association's lifetime does not immediately tear it down.
Outgoing key selection requires: (1) Peers field includes the peer H, (2) Protocol field matches P, (3) Interfaces field includes I or 'all' if interface is specified, (4) Direction is 'out' or 'both', and (5) SendLifetimeStart <= current time <= SendLifeTimeEnd. When multiple valid keys exist, the one with the most recent SendLifetimeStart is preferred to support rollover.
The Key field contains a long-lived symmetric cryptographic key encoded as a lowercase hexadecimal string with the most significant octet first. The length depends on the KDF and AlgID; for example, KDF=none and AlgID=AES128 requires a 128-bit key represented by 32 hexadecimal digits.
Timestamp fields (SendLifetimeStart, SendLifeTimeEnd, AcceptLifeTimeStart, AcceptLifeTimeEnd) use the format YYYYMMDDHHSSZ encoding year (4 digits), month, day, hour, minute, and second (each 2 digits) in UTC. The trailing 'Z' explicitly indicates UTC.
When a key for a given protocol is identified by an integer key identifier, the associated key name is represented as lowercase hexadecimal digits with the most significant octet first, padded with leading zeros to the width of the key identifier field in the protocol.