JARI: Comments marked with "JARI:". JARI: Overall comments: A very much needed document, in my opionion. I agree with much what is said here, though further work is needed in the following areas: - Interoperability should be mentioned as a benefit of automatic key management, e.g. the selection of cryptographic algorithms is smoother with an automatic mechanism. - There are limitations and/or disadvantages of automatic key management mechanisms as well. These should be more thoroughly listed and discussed. Some of these limitations are discussed in my comments below. In some applications these limitations can cause significant trouble or even make the use of automatic keying impossible (IPv6 ND is one such application). - I get a sense that some of the requirements about the use of automatic key management are really more about the use of public key -based mechanisms. For instance, the n^2 keying problem isn't solved just by upgrading to IKE but continuing to use shared secrets. This should be spelled out in the document. 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 JARI: s/whther/whether/ 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. JARI: There seems to be cases where automatic key management too would have some disadvantages. A couple of years ago I run into a case where we couldn't employ automatic key management to secure IPv6 ND, because key management packets could not be sent before IPv6 ND had been run. Obviously, by the time ND had already been run, it was already too late to secure ND. This may be a very special case, though. 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.) JARI: The multicast case needs better treatment in the document. JARI: In IKEv1, if one uses shared secrets in an environment with dynamic IP addresses, the available authentication alternatives are either aggressive mode or the use of group pre-shared secrets. Either way, there are problems. While I believe this has been fixed in IKEv2, the wide deployment of IKEv1 implies that we have to live with the implications for some time. Perhaps this should be spelled out in the document. The likely operational environment is one where personnel (or device) turnover is reasonably frequent, thus creating a requirement for frequent rekeying. JARI: I don't understand the above requirement. Given the first requirement (not n^2 static keys), it seems apparent that manual keying would only be used in a peer-to-peer fashion, right? For instance, a central party handles n static keys towards n peers. In this situation, what exactly is the difference between manual and automated keying? If its IKE preshared secrets vs. manually keyed IPsec SAs, its a config change in both ends. If its certs, its getting a new cert on the other end and handing out a cert on the other end, plus invalidating the previous cert. Either way, I don't see the difference. I think the real issue is the n^2 vs. n keying, not turnover. Or is this about the transition problems? JARI: I would include "interoperability" in the above list. Experience over the years in IPsec bakeoffs indicates that not all vendors support manual keying, and that the "normal" config i.e. through IKE is more like to succeed that manual keying. 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. JARI: Good point. Question: Are the IPsec SPIs and policy mechanisms sufficient to do this? I suppose you can e.g. install two SAs on the central party while you wait for the remote party to upgrade to the new key. Perhaps the central party should accept either one of the incoming SAs and stick to the use of the old SA for the outgoing packets? The remote peer should use a similar policy. When the transition period is over, the parties can independently delete the old SAs because the other party should have the new SAs in place. JARI: What are the key change provisions in automatic key management? Obviously, its easy to change session keys. But do we need mechanisms for dealing with e.g. the change of an IKE preshared secret? If yes, will the above mechanism be applicable? Is this documented somewhere? 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. JARI: I would prefer to see the list spelled out in more detail. 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.) JARI: It would be interesting to know what functionality is contained in this 200 KB figure. Draft-ietf-ips-security-19.txt lists some example implementations, but only one is under 200 KB. In my experience, certificate and public key handling, bignum math, enrollment procedures are a major part of the code size for a good IKE implementation. In fact, it can be an order of magnitude larger than pure IKE itself. 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. JARI: The above comment seems out of place for this document. Is there some specific case we are talking about here? There seems to be significant work in every application to figure out who the principals are, and why should they be allowed to communicate with their peers in a certain way. This is work that needs to get done right, regardless of whether manual or automatic keying is used. 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. JARI: Perhaps a note about the improvements in IKEv2 vs. IKEv1 would be appropriate here. My understanding is that the number of used round-trips is smaller. JARI: Also, the high round-trip times... this seems to be not so much about the high round-trip times as such, but rather about the product of the needed rekeying frequency and the round-trip times. For instance, both IKEv1 and IKEv2 are incapable of retaining phase 1 state through movements when a new IP address is assigned. This leads to a situation where a frequent rekeying is (rather unnecessarily) needed. If the frequency of movement is high enough, this can be problematic even if the round-trip times are small. Bellovin [Page 3] Internet Draft draft-bellovin-mandate-keymgmt-00.txt April 2003 Low value of the information JARI: I don't understand this. Low value of what information? Low value of the protected information? This seems to be an issue where e.g. lack of session key refresh causes the ciphers to be breakable. Perhaps this should be spelled out along with the conditions required for this to happen. JARI: If my above interpretation of the issue is correct, then it seems that "Low amount of communications over the lifetime of the key" would be a candidate for using manual keying as well. For instance, is the amount of bytes sent over the SA (over say, 2 years) smaller the number of bytes considered safe to be protected by AES? There are signaling and low-bandwidth applications where the amount of traffic is fairly limited even if you sum it over a long period of time. Very limited scale of each deployment JARI: I would add "small devices" to the above list. Smaller than a cellphone, say a sensor of some kind. But these may fall under the "low amount of communications" rule too. JARI: What about the multicast case? Perhaps I should check what the current progress is in MSEC. Are we at a state where we can reasonably expect to secure multicast traffic? If not, we need a rule for multicast traffic in this list. (IPv6 ND multicast may be an issue even if MSEC has a protocol out.) JARI: What about limitations of specific key management protocols. I'm somewhat unhappy about the lack of "address agility" support in IKEv1 and IKEv2, which I mentioned already above. But there may be other limitations. In some of the protocols that we worked with over the years, we were told by the IESG to use TLS for inter-domain case and allow IKE only for intra-domain, due to (a) certificate fragmentation issue and (b) lack of general support for application-specific cert policies, such as different trust roots for apps 1 and 2. Are these considered as limitations today? What other limitations are there? While the document strictly speaking avoids this issue by not talking about specific protocols, this is still a practical problem for protocols that wish to mandate a specific key management protocol. 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]