Network Working Group Steven M. Bellovin Internet Draft AT&T Labs Research Expiration Date: October 2003 April 2003 Guidelines for Mandating Automated Key Management draft-bellovin-mandate-keymgmt-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The question often arises of whether or not a given security system requires some form of automated key management, or whether manual keying would suffice. This memo proposes guidelines for making such decisions; the presumption is that automated key management is generally but not always needed; if manual keying is proposed, the burden of proof is on the proposer. Bellovin [Page 1]
Internet Draft draft-bellovin-mandate-keymgmt-00.txt April 2003 1. Introduction The question often arises of whther or not a given security system requires some form of automated key management, or whether manual keying would suffice. There is no one answer to that question; circumstances differ. In general, automated key management SHOULD be used. Occasionally, relying on manual key management is reasonable; we propose some guidelines for making that judgment. On the other hand, relying on manual key management has its disadvantages. We thus outline concerns that would suggest that manual key management would be a bad idea. 1.1. Terminology The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. 2. Requirements These are a set of guidelines, not rules, for evaluating when automated key management should or shouldn't be used. Informed judgment is necessary when applying them. In this context, "key management" is automatic derivation of session key(s), as opposite to long-term keys used to authenticate the derived key(s). How this long-term key gets to the talking entities and what kind of a key it is (pre-shared secret, RSA public key, DSA, you-name-it) is beyond the scope of this document. Examples of key management systems include IKE and Kerberos; S/MIME and TLS include key management functions. A session key is used to protect application data. In general, automated key management SHOULD be used. This is a very strong "SHOULD". Key management MUST be used if: A central party will have to manage n^2 static keys. A stream cipher such as RC4 or AES counter mode [AESMODE] is Bellovin [Page 2]
Internet Draft draft-bellovin-mandate-keymgmt-00.txt April 2003 used. Long-lived session keys are used by more than two parties. (Except for multicast, this is a dubious situation in the first place, and should generally be discouraged no matter what.) The likely operational environment is one where personnel (or device) turnover is reasonably frequent, thus creating a requirement for frequent rekeying. Even manually-keyed systems need some provision for key changes; there must be some way to indicate which key is in use, to avoid problems during transition. Designs should sketch plausible mechanisms for deploying new keys and/or revoking compromised keys. If done well, such mechanisms can later be used by an add-on key management scheme. Lack of automated key management can lead to vulnerabilities, including (but not limited to) cryptographic weaknesses or loss of some functionality, such as replay protection. Key management software is not always large or bloated; even IKEv1 can be done in <200K, and TLS in half that much space. (TLS includes other functionality as well.) Lack of clarity about who the principals are is not a valid reason for avoiding key management. Rather, it tends to indicate a deeper problem with the underlying security model. Key management schemes should not be designed by amateurs; it is almost certainly inappropriate for WGs to design their own. To put it in concrete terms, the very first key management protocol in the open literature was published in 1978. A flaw was published in 1983. The fix proposed in 1983 was cracked in 1994. In 1996, a new flaw was found in the original 1978 version, in an area not affected by the 1983/1994 issue. All of these flaws were blindingly obvious once described -- but no one spotted them earlier. Note that the original protocol (translated to know about certificates, which hadn't been invented at the time) was only 3 messages. Situations where a desire to avoid key mangement may be reasonable include: Very limited available bandwidth or very high round-trip times. There are interactions here -- public key systems tend to require long messages and lots of computation; symmetric key alternatives, such as Kerberos, often require several round trips and interaction with third parties. Bellovin [Page 3]
Internet Draft draft-bellovin-mandate-keymgmt-00.txt April 2003 Low value of the information Very limited scale of each deployment Note that assertions about such things should often be viewed with the skepticism afforded to claims that "this will only be used on a LAN or two". In other words, the burden of demonstrating that manual key management is appropriate should be on the proponents --- and it's a fairly high barrier that they need to overcome. 3. References [AESMODE] "Recommendation for Block Cipher Modes of Operation - Methods and Techniques", NIST Special Publication SP 800-38A, December 2001. [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", S. Bradner. RFC 2119. March 1997. 4. Author Information Steven M. Bellovin AT&T Labs Research Shannon Laboratory 180 Park Avenue Florham Park, NJ 07932 Phone: +1 973-360-8656 email: bellovin@acm.org Bellovin [Page 4]