Security AD Statement on IPSEC Key Management
"Jeffrey I. Schiller" <jis@mit.edu> Fri, 20 September 1996 03:04 UTC
Received: from ietf.org by ietf.org id aa15437; 19 Sep 96 23:04 EDT
Received: from BIG-SCREW.MIT.EDU by ietf.org id aa14509; 19 Sep 96 23:00 EDT
Received: by big-screw id AA03126; Thu, 19 Sep 96 22:59:18 -0400
Message-Id: <32420858.505B@mit.edu>
Date: Thu, 19 Sep 1996 22:58:32 -0400
Sender: ietf-request@ietf.org
From: "Jeffrey I. Schiller" <jis@mit.edu>
Reply-To: jis@mit.edu
Organization: Massachusetts Institute of Technology
X-Mailer: Mozilla 3.0 (Macintosh; U; 68K)
Mime-Version: 1.0
To: ipsec@tis.com, ietf@ietf.org
Subject: Security AD Statement on IPSEC Key Management
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
-----BEGIN PGP SIGNED MESSAGE----- Introduction Standardized security technology is urgently needed on the Internet today. The IPSEC Working Group has been working to provide solutions applicable to the IP Layer of the protocol stack. Over a year ago, consensus was reached on the packet formats necessary to provide data authentication, integrity and confidentiality. However the mechanism to exchange required cryptographic material was not yet ready for standardization. Since then the IPSEC Working Group has been struggling with several competing key management proposals. To have competing proposals within an IETF working group is neither new nor novel. However the time comes when either the proponents of the various proposals come to consensus (along with the rest of the working group) or a decision among them has to be made. That time is now. In Montreal (at the June IETF meeting) I saw several factions at work in the IPSEC working group. There were people supporting each of the proposed key management solutions and a larger number of people who were looking for a single solution to emerge, but who themselves were not in a position to have a technical opinion one way or the other. But one thing was clear, they wanted a solution and they wanted it then. Shortly after the meeting I was approached by several people offering to have a "design team" meeting with the principals behind the various proposals. The goal of the team was to come up with a compromise that all could live with. I considered this very good news, but I was also cautious. The last thing I wanted was to have a working group meeting at the December 1996 IETF and still be where we were in Montreal, namely without a solution! To this end I established a time limit. The charge to the design team was to come up with a compromise solution (or enough progress on a compromise) by September 1. After September 1, if the working group could not decide upon a course of action, then I would step in as Security Area Director and propose one myself. As those of you on the IPSEC list already know, the design team failed in their effort to come up with a compromise. I am both saddened and disappointed by this outcome. The purpose of this document is to end the controversy and establish a productive direction for future work. History To understand the situation requires a bit of history and explanation. Although most Internet problems can be solved by a single protocol, this doesn't always have to be the case. For example, we have TCP and UDP which both provide a transport service, but with very different characteristics to address different problem domains. Similarly we have both the RIP and OSPF routing protocols. Each protocol has features different from the other, and each has its appropriate domain of applicability. Why is IPSEC different? To understand this we have to go back to the original decision reached by the IETF in the IPv6 selection process. Specifically the IETF decided that security, namely IPSEC, was a mandatory requirement for a compliant implementation of IPv6. This was decided upon because the community felt that without such a mandatory feature, security would not be implemented in a lot of products, even though there is a pressing need for security on the Internet. The reasons for this belief are many and varied and beyond the scope of this document. Suffice it to say that IPSEC technology is mandatory in IPv6. The mandatory nature of IPSEC means that for its various protocols, several variants may exist, but one of each class of protocol will need to be designated as mandatory to provide guidance to vendors wishing to build IPv6 compliant versions of products. The mandatory to implement protocols may not necessarily be the ideal solution for any particular problem. Instead they are selected to provide two basic requirements: o Strong Security o Interoperability The goal is for two compliant implementations of IPSEC to be able to communicate securely because they, at a minimum, have the mandatory to implement protocols common between them. They may have other protocols, such as other Authentication Header (AH) and Encapsulated Security Protocol (ESP) transforms, in common which they may negotiate the use of instead of the mandatory protocols. The mandatory transforms may not always be the ideal approach for a particular network application. For example, the mandatory ESP transform involves the use of the U.S. Data Encryption Standard (DES). This encryption algorithm is widely regarded as being secure enough for most applications. It is also commonly recognized that DES is a slow algorithm and applications requiring high speed data transfer (in the absence of high speed DES hardware) may elect to use a faster cipher such as the International Data Encryption Algorithm (IDEA) or RSA Data Security's RC2 or RC4 ciphers. Analysis Keeping in mind that the primary goal of the mandatory protocols is to provide strong security and interoperability, I have read and evaluated the approaches in the two main contenders for the IPSEC key management mandatory standard, SKIP and ISAKMP/Oakley. ISAKMP/Oakley ISAKMP defines a Security Association management protocol for establishing security contexts and keys between a pair of hosts on the Internet. By itself it does not define a key management function. Oakley provides a key management function which can operate within the ISAKMP protocol. The combination provides for complete security association and cryptographic key material management. Oakley itself provides several protocol variations which trade-off between protocol overhead (the number of messages sent between communicating hosts) and services provided (such as identity confidentiality). ISAKMP/Oakley imposes a cost of several packet exchanges between host pairs before secure communication can take place. There is no per-packet overhead to use ISAKMP/Oakley (other then the AH and ESP header overhead itself) once associations are in place. For a set of hosts which communicate with each other on a frequent basis, it is expected that associations will remain in place and the overhead of setting new ones up will not be a significant factor. The primary disadvantage of the ISAKMP/Oakley approach is that it imposes significant overhead in the case where hosts communicate infrequently as it is likely that associations will not exist when needed and will have to be setup. If either party to a security association looses or changes state, so that existing associations are no longer operative, then a new set of security associations can be established. Messages, protected by the new associations, can communicate the demise of the failed associations. SKIP The SKIP proposal is based on in-line keying. Each packet is encrypted in a key which is provided in the packet itself, encrypted in a key that is setup between the communicating host pair. SKIP's advantage is that the protocol for setting up inter-host keys is fairly lightweight. If both hosts already have the other hosts public key certificate, no packet exchanges are required as the arriving data packet will contain sufficient information for the receiving host to compute the shared key and respond accordingly. Computing the shared key requires significant computation (exponentiation). However a communicating host pair can choose to cache their shared keys to avoid this computational overhead. There is a trade-off between computation of shared keys and secure storage to hold already computed keys. In SKIP if a received packet cannot be decrypted, there is little fallback available as SKIP does not naturally support multiple security associations. Put another way, the lightweight key management does not have a heavyweight fallback in the event that key management fails for any reason. The result is that messages must be sent without security enhancements to indicate the failure. However such messages will be indistinguishable from forged messages originated by an attacker for the purpose of disrupting communication. The implication of the lightweight approach of SKIP is that no significant negotiation of algorithms, certificates and other options are possible. The assumption is that certain parameters, such as the Diffie Hellman prime and generator will be constant among members of a community of hosts using SKIP. Among a small community of hosts, e.g., within an autonomous system (AS), such parameters need not be negotiated in real-time, but rather can be configured in advance in the hosts. If at some future point they need to be changed, the amount of management overhead necessary is bounded by the size of the AS. SKIP will also likely be faster at recovery from normal system failure (reboot) when a host communicates with a significant number of peers. In this situation the lightweight approach provides for faster re-establishment of secure communication. Note: Some features of SKIP, including Certificate Discovery and Algorithm Discovery improve its ability to cope with some classes of failures. However this additional mechanism comes at the cost of additional packet exchanges and protocol complexity. It is my opinion that SKIP could be further modified to deal with these issues as well as ISAKMP/Oakley does. However I believe such a modified protocol will be as complicated if not more so then the ISAKMP/Oakley protocol combination. Conclusion I had hoped that the design team would have recognized that each of the two proposals above have domains where they are particularly well suited. It is conceivable to this author that a merged mechanism could exist that provides the benefits of SKIP within an AS (or similar community) and ISAKMP/Oakley when more protocol negotiation is required. A simple (from my point of view) solution would be to require both SKIP and ISAKMP/Oakley be implemented in a compliant IPv6 protocol stack. However it is clear to me that there is significant overlap of functionality between these two protocols and without a compromise (presumably a compromise protocol would result in a lot of shared mechanism and code in implementations) implementors would have to write a lot of excess code. Therefore we have to pick one approach as the mandatory solution. This does not mean that the other approach cannot become an ELECTIVE Internet Standard. Going back to my original view of the goal behind the "mandatory" approach leads me to conclude that if we must pick between ISAKMP/Oakley and SKIP, then ISAKMP/Oakley should be the mandatory standard. My rationale is simple. It is my belief that given an arbitrarily chosen pair of hosts, it is likelier that an ISAKMP/Oakley approach will result in a working security association than SKIP. Furthermore going back to the original working group charter, the ISAKMP/Oakley approach more closely follows the goals established in the charter to the IKMP portion of the IPSEC work. I would like to see the IPSEC working group create three sets of RFCs. o A Set of RFCs which fully define the ISAKMP/Oakley approach. These RFCs will follow the normal IETF standards track ultimately resulting in a protocol that is ELECTIVE for IPv4 and is MANDATORY for IPv6. o A Set of RFCs which fully define the SKIP approach. These RFCs will follow the normal IETF standards tack ultimately resulting in a protocol that is ELECTIVE for IPv4 and is ELECTIVE for IPv6. o One or more RFCs that describe the application domain for ISAKMP/Oakley and SKIP. Although I believe that ISAKMP/Oakley should become the IPv6 Mandatory protocol, I also believe that there exist significant domains of application where the SKIP approach makes more sense. I would like the working group to address this. Recommendation I formally recommend, as Security Area Director, that the charter for the IPSEC working group be amended to charge the working group with the tasks above. The arguments between the ISAKMP/Oakley and SKIP factions should no longer be considered appropriate discussion for the working group, either at its in person meetings or on the working group mailing list. If some people would like to continue that line of discussion they are welcome to form a separate mailing list, not part of the IETF. Proposed New Charter (with change bars) IP Security Protocol (ipsec) Charter Chair(s) * Ran Atkinson <rja@cisco.com> * Paul Lambert <palamber@us.oracle.com> Security Area Director(s): * Jeffrey Schiller <jis@mit.edu> Mailing List Information * General Discussion:ipsec@tis.com * To Subscribe: ipsec-request@tis.com * Archive: ftp://ftp.tis.com/pub/lists/ipsec Description of Working Group Rapid advances in communication technology have accentuated the need for security in the Internet. The IP Security Protocol Working Group (IPSEC) will develop mechanisms to protect client protocols of IP. A security protocol in the network layer will be developed to provide cryptographic security services that will flexibly support combinations of authentication, integrity, access control, and confidentiality. The protocol formats for the IP Authentication Header (AH) and IP Encapsulating Security Payload (ESP) will be independent of the cryptographic algorithm. The preliminary goals will specifically pursue host-to-host security followed by subnet-to-subnet and host-to-subnet topologies. Protocol and cryptographic techniques will also be developed to support the key management requirements of the network layer security. The Internet Key Management Protocol (IKMP) will be specified as an application layer protocol that is independent of the | lower layer security protocol. The protocol will be based on the | ISAKMP/Oakley work begun in: | | <draft-ietf-ipsec-isakmp-05.txt>, | <draft-ietf-ipsec-oakley-01.txt> and | <draft-ietf-ipsec-isakmp-oakley-00.txt>. | | A follow on work item may incorporate mechanisms based on SKIP as | defined in: | | <draft-ietf-ipsec-skip-07.txt> | | and related documents. Flexibility in the protocol will allow | eventual support of Key Distribution Centers (KDC), such as are used | by Kerberos. Goals and Milestones Done Submit Internet-Draft of Internet Key Management Protocol to the IESG for consideration as a Proposed Standard. Done Post as an Internet-Draft the IP Security Protocol. Done Post as an Internet-Draft the specification for Internet key management. Done Conduct initial interoperability testing of Encapsulating Security payload (ESP) and Authentication Header (AH). | Done Submit revised Internet-Drafts for ESP, AH, and IP Security Architecture. | Dec 96 Submit revised Internet-Drafts of IP Security Architecture, ESP, and AH to the IESG for consideration as Draft Standards. | Jan 97 | Submit Internet-Draft of the Internet Key Management Protocol (IKMP). | based on ISAKMP/Oakley to the IESG for consideration as a Proposed | Standard. | Jul 97 | Submit IKMP to IESG for consideration as a Draft Standard. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMkHj78UtR20Nv5BtAQEiAgP/XTqrl8Wn4jFpOgtukCbIgDUrsqzKiMDy HCl6pX4BbXGpdiHlayCdhS1g5zbdwRa4J4TQg8sESbDkD49Zcs4a9bIDjY31gIB4 HnP7twW1/sEls5Rp/j9vBHTDHQIMJFVWluuJOrQQfPxcLAEFjH+3enfFRAJXQVmo SOwHCHPmW7I= =mr47 -----END PGP SIGNATURE-----
- Security AD Statement on IPSEC Key Management Jeffrey I. Schiller