RFC 4107

RFC 4107: Guidelines for Cryptographic Key Management 🎀

Okay bestie, this one is RFC 4107, also known as BCP 107 for the fancy people 💅 It's a Best Current Practice, titled Guidelines for Cryptographic Key Management, and it came out in June 2005. The authors are Steven M. Bellovin (Columbia University) and Russell Housley (Vigil Security). Its header doesn't list any RFCs it obsoletes or updates, so it's just vibing on its own ✨ This is part 1 of 2, so let's go 🫶

---

Status of This Memo 🧚

So this section says the document is a Best Current Practice for the whole Internet Community, and it's basically asking everyone to talk about it and suggest improvements. Distribution is unlimited, so share away 🦋

Copyright Notice

Copyright (C) The Internet Society (2005).

Abstract 💖

The big question is whether a security system needs automated key management, or whether manual keying is totally fine. This memo gives guidelines for making that call. When symmetric cryptographic mechanisms are used in a protocol, the presumption is that automated key management is generally but not always needed. And if someone proposes manual keying, the burden of proving that automated key management isn't required falls on them 💅

1. Introduction ✨

Okay so the question comes up a lot: does a security system need some form of automated key management, or is manual keying enough? 🤔

There isn't one answer, because circumstances differ. In general, automated key management SHOULD be used. Sometimes relying on manual key management is reasonable, though, so the memo proposes some guidelines for making that judgment 🌸

On the flip side, relying on manual key management has real downsides, and the memo lays out the security concerns that justify preferring automated key management. But there are situations where manual key management is acceptable, so don't panic 🫶

1.1. Terminology 🎀

Quick terminology check: the keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they show up in this document, are to be interpreted as described in RFC 2119 [B].

2. Guidelines 💅

These guidelines are for IETF working groups and protocol authors who are deciding whether to mandate automated key management, and whether manual key management is acceptable. Informed judgment is needed 🧠

"Key management" here means establishing cryptographic keying material for use with a cryptographic algorithm, to provide protocol security services, especially integrity, authentication, and confidentiality. Automated key management derives one or more short-term session keys. The key derivation function may use long-term keys to build authentication into the process. How that long-term key gets distributed to the peers, and what type of key it is (a pre-shared symmetric secret, an RSA public key, a DSA public key, and others), is outside the scope of this document. It's still part of the overall key management solution, though. Manual key management is used to distribute such values, and it can also be used to distribute long-term session keys 🔑

Automated and manual key management give you very different features. The protocol behind automated key management 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. An automated key management protocol can also improve interoperability by including negotiation mechanisms for cryptographic algorithms. These features are impossible or extremely cumbersome to get with manual key management 😭

For some symmetric cryptographic algorithms, implementations must prevent overuse of a given key. An implementation of those algorithms can use automated key management when the usage limits are nearly exhausted, to set up replacement keys before the limits are reached. That way communications stay secure 🔥

Examples of automated key management systems include IPsec IKE and Kerberos. S/MIME and TLS also have automated key management functions 🦋

Key management schemes should not be designed by amateurs, so it's almost certainly inappropriate for working groups to design their own. Let me give you the receipts 🧾 The very first key management protocol in the open literature was published in 1978 [NS]. A flaw and a fix were published in 1981 [DS], and the fix got cracked in 1994 [AN]. Then in 1995 [L], a new flaw was found in the original 1978 version, in an area the 1981/1994 issue didn't touch. All of these flaws were obvious once someone described them, yet nobody spotted them earlier 🙈 Also, the original protocol (translated to use certificates, which didn't exist yet back then) was only three messages.

Key management software isn't always big or bloated, either. Even IKEv1 [HC] can be done in less than 200 Kbytes of object code, and TLS [DA] fits in half that space. Just note that this TLS estimate includes other functionality too 🍓

A session key protects a payload, and what the payload is depends on the layer where the symmetric cryptography gets applied 🧚

In general, automated key management SHOULD be used to establish session keys. A proposal that uses manual key management needs strong justification in its security considerations section 💜

2.1. Automated Key Management 🌈

Automated key management MUST be used if any of these conditions hold:

• A party will have to manage n^2 static keys, where n may become large.
• Any stream cipher (such as RC4 [TK], AES-CTR [NIST], or AES-CCM [WHF]) is used.
• An initialization vector (IV) might be reused, especially an implicit IV. Random or pseudo-random explicit IVs aren't a problem unless the probability of repetition is high.
• Large amounts of data might need to be encrypted in a short time, which causes frequent changes of the short-term session key.
• Long-term session keys are used by more than two parties. Multicast is a necessary exception, though multicast key management standards are emerging to avoid this in the future. Sharing long-term session keys should generally be discouraged.
• The likely operational environment is one where personnel (or device) turnover is frequent, which causes frequent changes of the short-term session key.

2.2. Manual Key Management 🌸

Manual key management may be a reasonable approach in any of these situations:

• The environment has very limited available bandwidth or very high round-trip times. Public key systems tend to need long messages and lots of computation, and symmetric key alternatives such as Kerberos often need several round trips and interaction with third parties.
• The information being protected has low value.
• The total volume of traffic over the entire lifetime of the long-term session key will be very low.
• The scale of each deployment is very limited.

Be skeptical of claims like these, bestie 🙄 The burden of showing that manual key management is appropriate falls on the proponents, and it's a fairly high hurdle.

Systems that use manual key management need provisions for key changes. There MUST be some way to indicate which key is in use, so you don't get problems during the transition. Designs SHOULD also sketch plausible mechanisms for deploying new keys and replacing old ones that might have been compromised. If it's done well, those mechanisms can later be reused by an add-on key management scheme 🔄

And lack of clarity about who's involved in authentication is not a valid excuse for skipping key management. It usually points to a deeper problem with the underlying security model 💀

2.3. Key Size and Random Values 🔢

Guidance on cryptographic key size for public keys used to exchange symmetric keys can be found in BCP 86 [OH].

When manual key management is used, long-term shared secret values SHOULD be at least 128 bits.

Guidance on random number generation can be found in BCP 106 [ESC].

When manual key management is used, long-term shared secrets MUST be unpredictable "random" values. That way an adversary has no greater expectation than 50% of finding the value after searching half the key search space. Iconic, right? ✨

(To be continued in part 2 🫶)

Full Copyright Statement ✨

Okay, legal bit but make it cute 🎀. The Internet Society owns the copyright here (2005 vibes 🧚). This document is subject to the rights, licenses and restrictions in BCP 78, and except for what's said there, the authors keep all their rights 💅.

The document and its info are given to you "AS IS" 🫶. The contributor, the org they represent or are sponsored by (if any), the Internet Society, and the Internet Engineering Task Force all say no warranties, express or implied. That includes no promise that using the info won't infringe anyone's rights, and no implied warranties of merchantability or fitness for a particular purpose 💀. Not them being messy, just legally protecting themselves lol.

Intellectual Property 🦋

Okay so the IETF doesn't take a side on whether any IP rights claimed around this tech are valid or how far they reach, and it doesn't claim it has looked into whether any such rights exist 🙈. If you want the procedures for rights in RFC documents, check BCP 78 and BCP 79 📚.

Copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses, or the results of trying to get a general license or permission for implementers or users, can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr 🔥.

The IETF invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💌.

Acknowledgement 🌸

Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society, you're literally keeping the lights on 🫶✨.