idnits 2.17.1 draft-bellovin-mandate-keymgmt-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2003) is 7679 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'AESMODE' Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Steven M. Bellovin 3 Internet Draft AT&T Labs Research 5 Expiration Date: October 2003 April 2003 7 Guidelines for Mandating Automated Key Management 9 draft-bellovin-mandate-keymgmt-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 The question often arises of whether or not a given security system 35 requires some form of automated key management, or whether manual 36 keying would suffice. This memo proposes guidelines for making such 37 decisions; the presumption is that automated key management is 38 generally but not always needed; if manual keying is proposed, the 39 burden of proof is on the proposer. 41 1. Introduction 43 The question often arises of whther or not a given security system 44 requires some form of automated key management, or whether manual 45 keying would suffice. 47 There is no one answer to that question; circumstances differ. In 48 general, automated key management SHOULD be used. Occasionally, 49 relying on manual key management is reasonable; we propose some 50 guidelines for making that judgment. 52 On the other hand, relying on manual key management has its 53 disadvantages. We thus outline concerns that would suggest that 54 manual key management would be a bad idea. 56 1.1. Terminology 58 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 59 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 60 document, are to be interpreted as described in [RFC2119]. 62 2. Requirements 64 These are a set of guidelines, not rules, for evaluating when 65 automated key management should or shouldn't be used. Informed 66 judgment is necessary when applying them. 68 In this context, "key management" is automatic derivation of session 69 key(s), as opposite to long-term keys used to authenticate the 70 derived key(s). How this long-term key gets to the talking entities 71 and what kind of a key it is (pre-shared secret, RSA public key, DSA, 72 you-name-it) is beyond the scope of this document. Examples of key 73 management systems include IKE and Kerberos; S/MIME and TLS include 74 key management functions. 76 A session key is used to protect application data. 78 In general, automated key management SHOULD be used. This is a very 79 strong "SHOULD". 81 Key management MUST be used if: 83 A central party will have to manage n^2 static keys. 85 A stream cipher such as RC4 or AES counter mode [AESMODE] is 86 used. 88 Long-lived session keys are used by more than two parties. 89 (Except for multicast, this is a dubious situation in the first 90 place, and should generally be discouraged no matter what.) 92 The likely operational environment is one where personnel (or 93 device) turnover is reasonably frequent, thus creating a 94 requirement for frequent rekeying. 96 Even manually-keyed systems need some provision for key changes; there 97 must be some way to indicate which key is in use, to avoid problems 98 during transition. Designs should sketch plausible mechanisms for 99 deploying new keys and/or revoking compromised keys. If done well, such 100 mechanisms can later be used by an add-on key management scheme. 102 Lack of automated key management can lead to vulnerabilities, including 103 (but not limited to) cryptographic weaknesses or loss of some 104 functionality, such as replay protection. 106 Key management software is not always large or bloated; even IKEv1 can 107 be done in <200K, and TLS in half that much space. (TLS includes other 108 functionality as well.) 110 Lack of clarity about who the principals are is not a valid reason for 111 avoiding key management. Rather, it tends to indicate a deeper problem 112 with the underlying security model. 114 Key management schemes should not be designed by amateurs; it is almost 115 certainly inappropriate for WGs to design their own. To put it in 116 concrete terms, the very first key management protocol in the open 117 literature was published in 1978. A flaw was published in 1983. The 118 fix proposed in 1983 was cracked in 1994. In 1996, a new flaw was found 119 in the original 1978 version, in an area not affected by the 1983/1994 120 issue. All of these flaws were blindingly obvious once described -- but 121 no one spotted them earlier. Note that the original protocol 122 (translated to know about certificates, which hadn't been invented at 123 the time) was only 3 messages. 125 Situations where a desire to avoid key mangement may be reasonable 126 include: 128 Very limited available bandwidth or very high round-trip times. 129 There are interactions here -- public key systems tend to require 130 long messages and lots of computation; symmetric key alternatives, 131 such as Kerberos, often require several round trips and interaction 132 with third parties. 134 Low value of the information 136 Very limited scale of each deployment 138 Note that assertions about such things should often be viewed with the 139 skepticism afforded to claims that "this will only be used on a LAN or 140 two". In other words, the burden of demonstrating that manual key 141 management is appropriate should be on the proponents --- and it's a 142 fairly high barrier that they need to overcome. 144 3. References 146 [AESMODE] "Recommendation for Block Cipher Modes of Operation - 147 Methods and Techniques", NIST Special Publication SP 148 800-38A, December 2001. 150 [RFC2119] "Key words for use in RFCs to Indicate Requirement 151 Levels", S. Bradner. RFC 2119. March 1997. 153 4. Author Information 155 Steven M. Bellovin 156 AT&T Labs Research 157 Shannon Laboratory 158 180 Park Avenue 159 Florham Park, NJ 07932 160 Phone: +1 973-360-8656 161 email: bellovin@acm.org