From ipsec-request@ans.net Tue Nov 1 10:23:57 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05387 (5.65c/IDA-1.4.4 for ); Tue, 1 Nov 1994 05:35:51 -0500 Received: by interlock.ans.net id AA14844 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 1 Nov 1994 05:24:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 1 Nov 1994 05:24:18 -0500 Message-Id: <199411011024.AA24824@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 1 Nov 1994 05:24:18 -0500 Organisation: University College London, CS Dept. Phone: +44 71 380 7777 ext 3462 or +44 71 387 7050 ext 3462 Fax: ++44 71 387 1397 To: ipsec@ans.net Cc: A.Ballardie@cs.ucl.ac.uk Subject: IEEE Symposium on Security and Privacy Date: Tue, 01 Nov 94 10:23:57 +0000 From: Tony Ballardie Sorry to bombard the list with this request for information, but I've been trying, so far unsuccessfully, to find out the submission details for IEEE Symposium on Security and Privacy, held next May 8th-10th, Oakland, CA. All I know is that the submission deadline is November 7th. Can anyone help? Thanks in advance, Tony From ipsec-request@ans.net Tue Nov 1 11:02:56 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05605 (5.65c/IDA-1.4.4 for ); Tue, 1 Nov 1994 06:14:02 -0500 Received: by interlock.ans.net id AA07666 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 1 Nov 1994 06:06:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 1 Nov 1994 06:06:31 -0500 X400-Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 1 Nov 1994 06:06:31 -0500 X400-Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 1 Nov 1994 06:06:31 -0500 Date: Tue, 1 Nov 1994 11:02:56 +0000 X400-Originator: P.V.McMahon@rea0803.wins.icl.co.uk X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;rea0803 0000016300011661] Original-Encoded-Information-Types: undefined (0) X400-Content-Type: P2-1984 (2) Content-Identifier: 11661 From: P.V.McMahon@rea0803.wins.icl.co.uk Message-Id: <"11661*/I=PV/S=McMahon/OU=rea0803/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: Tony Ballardie Cc: ipsec@ans.net Subject: RE: IEEE Symposium on Security and Privacy Tony, See attached CFP. Piers -- Newsgroups: alt.security,comp.security.misc,comp.specification,sci.crypt Subject: CFP: IEEE Symposium on Security and Privacy Date: Fri, 22 Jul 1994 21:30:33 GMT CALL FOR PAPERS 1995 IEEE Symposium on May 8-10, 1995 Security and Privacy Oakland, California sponsored by IEEE Computer Society Technical Committee on Security and Privacy in cooperation with The International Association for Cryptologic Research (IACR) The Symposium on Security and Privacy has for fifteen years been the premier forum for the presentation of developments in computer security, and for bringing together researchers and practitioners in the field. This year, we seek to build on this tradition of excellence by re-emphasizing work on engineering and applications as well as theoretical advances. We also seek to broaden the scope of the Symposium by introducing new topics. We want to hear not only about new theoretical results, but also about work in the design and implementation of secure systems and work on policy relating to system security. We are particularly interested in papers on policy and technical issues relating to privacy in the context of the information infrastructure, papers that relate software and system engineering technology to the design of secure systems, and papers on hardware and architectural support for secure systems. The symposium will focus on technical aspects of security and privacy as they arise in commercial and industrial applications, as well in government and military systems. It will address advances in the theory, design, implementation, analysis, and application of secure computer systems, and in the integration and reconciliation of security and privacy with other critical system properties such as reliability and safety. Topics in which papers and panel session proposals are invited include, but are not limited to, the following: Secure systems Privacy Issues Access controls Security verification Network security Policy modeling Information flow Authentication Database security Data integrity Security Protocols Viruses and worms Auditing Biometrics Smartcards Commercial and industrial security Intrusion Detection Security and other critical system properties Distributed systems A new feature of the symposium this year will be a special session of very brief (5-minute) talks. Our goal is to make it possible for us to hear from people who are advancing the field in the areas of system design and implementation, and who would like to present their ideas to the symposium audience but may lack the time and resources needed to prepare a full paper. Submissions for this session will be accepted up to five weeks before the symposium, to permit us to hear of the most recent developments. Abstracts of these talks will be distributed at the conference. INSTRUCTIONS TO AUTHORS: Send six copies of your paper and/or proposal for a panel session to Catherine Meadows, Program Co-Chair, at the address given below. Papers and panel proposals must be received by November 7, 1994. Papers, which should include an abstract, must not exceed 7500 words. The names and affiliations of the authors should appear on a separate cover page only, as a ``blind'' refereeing process is used. Authors must certify prior to December 25, 1994 that any and all necessary clearances for publication have been obtained. Papers must report original work that has not been published previously, and is not under consideration for publication elsewhere. Abstracts, overlength papers, electronic submissions, late submissions, and papers that cannot be published in the proceedings will be rejected without review. Authors will be notified of acceptance by January 16 , 1995. Camera-ready copies are due not later than March 6, 1995. Panel proposals should describe, in two pages or less, the objective of the panel and the topic(s) to be addressed. Names and addresses of potential panelists (with position abstracts if possible) and of the moderator should also be included. Submitters of abstracts for the special session of five-minute talks should submit one page abstracts to Catherine Meadows, program co-chair, at the address given below. Abstracts must be received by April 3, 1995. Authors will be notified of acceptance or rejection of abstracts by April 17. Submitted abstracts that are accepted will be distributed at the conference. The Symposium will also include informal poster sessions where preliminary or speculative material, and descriptions or demonstrations of software, may be presented. Send one copy of your poster session paper to Carl Landwehr, at the address given below, by January 31, 1995, together with certification that any and all necessary clearances for presentation have been obtained. Also for the first time this year, we will attempt to counsel prospective authors. If you have questions about whether or how to present your work to the symposium, please send e-mail to the Chair (landwehr@itd.nrl.navy.mil), and we will do our best to assist you. Information about this conference will be also be available by anonymous ftp from chacs.itd.nrl.navy.mil in directory /pub/SP95, by World Wide Web from http://www.itd.nrl.navy.mil/ITD/5540/announce/SP95.html, or by sending email to sp95@itd.nrl.navy.mil. PROGRAM COMMITTEE Ross Anderson, Cambridge University, UK Steve Bellovin, AT&T, USA Tom Berson, Anagram Laboratories, USA Oliver Costich, Independent Consultant, USA George Dinolt, Loral, USA Cristi Garvey, TRW, USA Li Gong, SRI, USA Sushil Jajodia, GMU, USA Steve Kent, BBN, USA Steve Lipner, TIS, USA Teresa Lunt, ARPA/CSTO, USA John McLean, NRL, USA Jonathan Millen, Mitre, USA Birgit Pfitzmann, Universit"at Hildesheim, Germany Sylvan Pinsky, DoD, USA Michael Reiter, AT&T, USA Jaisook Rho, TIS, USA Peter Ryan, DRA, UK Tom Schubert, Portland State University, USA Paul Syverson, NRL, USA Vijay Varadharajan, HP, UK Raphael Yahalom, Hebrew University, Israel For further information concerning the symposium, contact: Carl Landwehr, General Chair Catherine Meadows, Program Co-Chair Naval Research Lab., Code 5542 Naval Research Laboratory, Code 5543 4555 Overlook Ave., SW 4555 Overlook Ave., SW Washington DC 20375, USA Washington DC 20375, USA Tel: +1 (202) 404-8888 Tel: +1 (202) 767-3490 FAX: +1 (202) 404-7942 FAX: +1 (202) 404-7942 landwehr@itd.nrl.navy.mil meadows@itd.nrl.navy.mil Dale Johnson, Vice Chair John McHugh, Program Co-Chair The MITRE Corporation Computer Science Department Mailstop A156 Portland State University 202 Burlington Rd P.O. Box 751 Bedford, MA 01730-1420, USA Portland OR 97207-0751, USA Tel: +1 617-271-8894 Tel: +1 (503) 725-5842 Fax: +1 617-271-3816 Fax: +1 (503) 725-3211 dmj@mitre.org mchugh@cs.pdx.edu Charles Payne, Treasurer Naval Research Lab., Code 5542 4555 Overlook Ave., SW Washington DC 20375, USA Tel: +1 (202) 404-8763 FAX: +1 (202) 404-7942 payne@itd.nrl.navy.mil Peter Ryan, European Contact Jim Gray, Asia/Pacific Contact Defence Research Agency Department of Computer Science Room NX17 Hong Kong Univ. of Science & Technology St Andrew's Rd Clear Water Bay, Kowloon, Hong Kong Malvern Tel: +852 358-7012 Worcs WR14 3PS,UK Fax: +852 358-1477 Tel +44 (0684) 895845 gray@cs.ust.hk Fax +44 (0684) 894303 ryan@rivers.dra.hmg.gb ------------------------------------------------------- P V McMahon 01NOV94 ICL Enterprises post: Kings House, 33 Kings Road, Reading, RG1 3PX, UK email: p.v.mcmahon@rea0803.wins.icl.co.uk OR p.mcmahon@xopen.co.uk phone: +44 734 634882 fax: +44 734 855106 ------------------------------------------------------- From ipsec-request@ans.net Wed Nov 2 12:33:23 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19674 (5.65c/IDA-1.4.4 for ); Wed, 2 Nov 1994 17:42:34 -0500 Received: by interlock.ans.net id AA35682 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 2 Nov 1994 17:33:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 2 Nov 1994 17:33:19 -0500 Message-Id: <199411022233.AA03934@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 2 Nov 1994 17:33:19 -0500 Date: Wed, 2 Nov 94 17:33:23 EST From: "Juan A. Garay ((914) 784-6852)" X-Addr: IBM T.J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598 To: ipsec@ans.net Cc: amir@watson.ibm.com, hugo@watson.ibm.com, pau@watson.ibm.com Subject: Modular approach to key management for IPSP Hello all, In order to have a useful and productive IETF meeting next month on the issue of key management for IPSP, it'd help to have some preliminary discussions on the subject in this working group. Since the last IETF meeting the only relevant posting (that we are aware of) on key management in this list was the recent announcement by Aziz of his draft on the "SKIP" proposal. Although SKIP has some nice features and functionality, we believe that IPSP requires a different approach to key management which may include some aspects of SKIP but cannot be solely based on it. (We defer to a future note a more thorough discussion of the benefits and limitations of SKIP). THE BASIC APPROACH ****************** Our basic approach to the key management problem for IPSP is that any viable solution needs to follow a modular approach. We advocate the separation of a key management scheme into the following two modules: Un upper module in which a long-lived ("master") key is exchanged between the communicating parties; and a lower module, in which the already shared (master) key is used for the derivation, sharing and/or refreshment of additional short-lived keys to be used for the cryptographic transformations applied to the data, e.g., encryption and authentication. (Short-lived keys can be thought of as "session" keys, but the existence of a session is not necessarily required or implied.) Moreover, we believe this WG needs to concentrate on establishing first the lower ("short-lived") module protocol and then to go into the upper ("long-lived") module, with the former being *independent* of the specifics of the latter. This approach is consistent with the way this group has structured its development strategy for IPSP, namely, first come up with an agreed-upon network-layer encapsulation protocol (IPSP), and then complement it with a key management protocol. This methodology supports both a gradual development effort, as well as the independence of IPSP from the particular key management techniques. In the same way, a gradual and bottom-up independent approach is desirable for key management. We elaborate more on this in the rest of this note. WHAT ARE THE MODULES? ********************* First let us briefly state the basic functionality that needs to be provided by each of these modules. LONG-LIVED KEY MODULE: Will provide a mechanism for authenticated sharing of a secret (symmetric) key between the communicating parties. This protocol would not assume the existence of an already shared key but is based on some form of shared trust. This trust can be physical (e.g., manual/over-the-phone/etc. installation techniques), based on a trusted third party acting as a key distribution center (e,g,, the Kerberos model), or based on the possession by the parties of authenticated public keys of each other. Periodic (although not frequent) refreshment of long-lived keys needs also to be provided, but this can be accomplished by the basic exchange mechanism (i.e., long-lived key refreshment does not require to assume the existence of an already shared secret key between the parties). SHORT-LIVED KEYS MODULE: This is the most "busy" module of key management. This module is responsible for the exchange of short-lived keys, the authentication of the parties, the derivation of "data keys" (the actual keys used for encryption and authentication of the IP payload), the periodic (and relatively frequent) refreshment of these keys, and the communication of SAID's for the indexing of the keys (especially in the desirable model where SAID's are chosen by the local implementation and need to be transmitted to the other party). Notice that there is no duplication of functions between the two modules. Regardless of whether these modules are designed in a hierarchical way as we propose or not, the above functions need to exist in any secure and sound key management solution. One important issue that is not addressed in the above modules is the negotiation between the parties of the security attributes for the security associations served by the above keys. This attributes include the specific functions to be performed on the data (encryption only, authentication only, both of them, etc), the particular algorithms (CBC-DES, MD5, etc.), the frequency of key updates (based on time, usage, unilateral decision by any party, etc.), support of timestamps in addition to nonces, interactive vs. non-interactive updates, and so on. The exact list of possible attributes is to be decided by this WG, and usually involves trade-off considerations between flexibility and simplicity. Moreover, it will be the decision of this WG where this negotiation module is to be located. It can be attached either to the master-key module or to the short-lived key module. Or, following our modular approach, it may reside "in between" these modules. We defer the discussion and further treatment of this issue to a future note. RATIONALE BEHIND THE MODULAR APPROACH ************************************* There is a full spectrum of reasons behind the conceptual and practical separation of the above two key management levels. A first classification of these issues is presented next. Notice the full compliance of these considerations with the summary on Key Management Requirements posted in this list by Dave Solo in February of this year. Some of the elements below are a re-statement of these requirements while other present complementary aspects (e.g., the need for a bottom-up development methodology). FUNCTIONALITY: Whatever the master-key exchange mechanism is, a method for derivation of data keys from a shared key is necessary. Notice that multiple security transformations on the data require multiple keys (e.g, encryption and authentication). Moreover, even a single function may require more than one key (for example, stream cipher encryption may require directional keys, i.e., different keys depending on the direction of the data). Also, the communication of SAID's is essential for a model that supports unstructured and locally generated SAID's. SECURITY: There is a well-recognized need for *frequent* key updates. Frequent updates are not just a good cryptographic practice (e.g., to reduce the damage caused by a compromised key; to reduce the time/data available for cryptanalysis; etc.), but are of particular importance in cases where weak algorithms are used. (Weak algorithms will be part of the Internet's repertoire of cryptographic algorithms both because of export rules as well as for efficiency needs.) EFFICIENCY: Efficiency is a universal consideration. It is particularly important to have efficient key management protocols in computationally- constrained environments (e.g., weak/loaded devices; wireless devices; etc.). Inefficient methods would effectively lead to less key updates, with the corresponding impact on security. While techniques like Diffie-Hellman (complemented with authentication mechanisms) have an important role for long-lived key exchange, much more efficient techniques (e.g. based on MD5) can be used for the relatively frequent updates of data keys. DEPLOYMENT: A key management protocol needs to support and interoperate with a variety of existing key distribution technologies. Key distribution centers (e.g., Kerberos), and even manual key installation (e.g., in existing intra-enterprise firewalls) are popular and widely-deployed technologies. The view that only public key can provide a full-scale solution to key management for the Internet is well understood and agreed upon. However, equally well-understood is that we are not going to wait until a full certification infrastructure is in place to start providing security for IP. Therefore, not taking advantage of the above handy technologies would be irresponsible. Notice that we are proposing an *inclusive* approach, in which all these technologies may co-exist. Still, the short-lived key engine is common to (and independent from) all of them. DEVELOPMENT METHODOLOGY: Finally, the specification of a short-lived key management protocol supports the *gradual development* of the standard, summarized in the following list: 1) The encapsulation protocol (IPSP); 2) short-lived/working key management (which assumes master key); 3) attribute negotiation (input to policy engine); and 4) master key management. Agreement on a standard for the sharing of master keys may not be easy to achieve due to the variety of existing techniques and very complex trade-offs (e.g., public-key algorithms, certification authorities, key distribution centers, etc.). In contrast, the management of short-lived keys once a shared master key already exists can be based on very simple, efficient and well-understood mechanisms. Moreover, while one can start working with IPSP even with manually-installed shared keys, a good management (including periodic refreshment) of the derived short-lived keys is essential for a secure working IPSP. Note that the above model is broad enough to accommodate a variety of key management proposals, including SKIP (which basically contains the above two modules: a master key exchange based on DH certificates, and a short-lived key exchange based on encrypting the data keys in the IPSP packet). The question behind the suitability of SKIP involves the need for non-interactive key exchange as opposed to interactive solutions. But this is a subject for future discussion. This is it for now. Feedback/comments will be appreciated. A more complete contribution (based on our presentation at the last IETF meeting) including specific solutions for the short-lived key management will soon follow. But the above methodology is independent of specific protocol realizations, therefore discussions on these issues can be started right away. Regards, Amir-Hugo-Juan-Pau From ipsec-request@ans.net Fri Nov 4 02:41:36 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17507 (5.65c/IDA-1.4.4 for ); Fri, 4 Nov 1994 13:51:55 -0500 Received: by interlock.ans.net id AA31847 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 4 Nov 1994 13:46:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 4 Nov 1994 13:46:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 4 Nov 1994 13:46:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 4 Nov 1994 13:46:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 4 Nov 1994 13:46:02 -0500 Date: Fri, 4 Nov 94 10:41:36 PST From: Ashar.Aziz@eng.sun.com (Ashar Aziz) Message-Id: <9411041841.AA09708@miraj.Eng.Sun.COM> To: ipsec@ans.net, garay@watson.ibm.com Subject: Re: Modular approach to key management for IPSP Cc: amir@watson.ibm.com, hugo@watson.ibm.com, pau@watson.ibm.com, whitfield.diffie@eng.sun.com Juan,Amir,Hugo,Pau, Let me offer a few comments on your note. First of all, I completely agree with the basic modular approach that you advocate. As you noted, it is already embodied in our SKIP proposal. Sounds as if you have concerns about SKIP. I would be glad to hear what they are, and see if they can be addressed in some manner. SKIP is a proposal. As such, it is not cast in stone. I would like for all of us to work together as a group in identifying and solving problems. This, I believe, is the whole purpose of the open standards process. With respect to the issue of the Public Key Infrastructure (PKI), I believe we differ in our approach. We at Sun dont believe that the PKI is a train that is going to arrive at the station, for which we are all waiting passengers. We believe that the PKI is a train that needs to be *driven* by us as the industry. If we all wait for it to arrive, it will never arrive. While I agree that it would be irresponsible for us to ignore building bridges to what exists today, it would be equally if not more irresponsible for us to ignore the task of building the PKI, which I believe falls on our shoulders (where by "our" I mean the industry as represented at the IETF). We realize that paper documents do not make up an infrastructure. Sun (and my group in particular) will play its part in providing concrete solutions and working with other interested parties to share technology and pool resources where it makes sense. We dont intend the leave the PKI as an IOU for the end-users, who will ultimately benefit from this. This, of course, is not completely altruistic. It makes business sense for us (and others) to provide the solutions that will work best for the Internet community. Peace, Ashar. From ipsec-request@ans.net Fri Nov 4 09:51:15 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15359 (5.65c/IDA-1.4.4 for ); Fri, 4 Nov 1994 14:56:58 -0500 Received: by interlock.ans.net id AA04884 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 4 Nov 1994 14:51:20 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 4 Nov 1994 14:51:20 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 4 Nov 1994 14:51:20 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 4 Nov 1994 14:51:20 -0500 Date: Fri, 4 Nov 1994 14:51:15 +0500 From: Theodore Ts'o Message-Id: <9411041951.AA11615@dcl.MIT.EDU> To: "Juan A. Garay 784-6852)" Cc: ipsec@ans.net, amir@watson.ibm.com, hugo@watson.ibm.com, pau@watson.ibm.com In-Reply-To: Juan A. Garay's message of Wed, 2 Nov 94 17:33:23 EST, <199411022233.AA03934@interlock.ans.net> Subject: Re: Modular approach to key management for IPSP Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 841 Correct me if I'm wrong, but you are assuming in your design that there will always be a long-term shared symmetric key between the communicating parties. That doesn't seem to be a good assumption. You could generate the short-lived keys from a public key exchange, or the communicating parties may have a long-term symmetric key which they both share with a trusted third party (Kerberos). As near as I can tell, you're proposing that if you use one of these schemes, such as Kerberos or X.509 public-key certificates, they be used only to establish a long-term shared secret key --- and that long-term secret key would only be used to establish short-term session keys. Is this a fair characterization? If so, it would seem that in some cases there will be a needless extra indirection in setting up the session key. - Ted From ipsec-request@ans.net Fri Nov 4 10:50:11 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14778 (5.65c/IDA-1.4.4 for ); Fri, 4 Nov 1994 16:11:19 -0500 Received: by interlock.ans.net id AA28122 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 4 Nov 1994 15:50:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 4 Nov 1994 15:50:06 -0500 Message-Id: <199411042050.AA28118@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 4 Nov 1994 15:50:06 -0500 Date: Fri, 4 Nov 94 15:50:11 EST From: hugo@watson.ibm.com To: Ashar.Aziz@eng.sun.com, ipsec@ans.net Subject: Modular approach to key management for IPSP Ref: Your note of Fri, 4 Nov 94 10:41:36 PST (attached) Ashar, we are the last to try to stop any advance towards the construction of a PKI. We are definitely interested to contribute in that direction. However, this important goal should not come at the expense of ignoring the other ways people do key distribution today (and will keep doing for long time). Especially, that there is no contradiction between the different approaches. All we are saying is let them co-exist. (And they will, no matter what we decide.) I believe that we are essentially in accord on this issue. Hugo PS: as for comments on SKIP I still owe them to you and to the list. Hope to do it soon. From ipsec-request@ans.net Fri Nov 4 21:12:48 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13819 (5.65c/IDA-1.4.4 for ); Fri, 4 Nov 1994 16:19:51 -0500 Received: by interlock.ans.net id AA27934 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 4 Nov 1994 16:12:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 4 Nov 1994 16:12:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 4 Nov 1994 16:12:45 -0500 Message-Id: <9411042112.AA16737@columbia.sparta.com> To: garay@watson.ibm.com Cc: ipsec@ans.net, amir@watson.ibm.com, hugo@watson.ibm.com, pau@watson.ibm.com, hh@columbia.sparta.com Subject: Re: Modular approach to key management for IPSP In-Reply-To: Your message of "Wed, 02 Nov 94 17:33:23 EST." <199411022233.AA03934@interlock.ans.net> Date: Fri, 04 Nov 94 16:12:48 -0500 From: Hugh Harney Juan, In September, the Group Key Management Protocol (GKMP) was posted as an Internet drafts (architecture and specification). The GKMP describes a public key approach to distributing grouped keys. The GKMP was presented at the last ARPA PI meeting and will be presented at the next IEEE 802.10c meeting. The GKMP fits within the lower module described in your posting. I believe discussion of the GKMP would be useful at the next IETF. While the GKMP was not specifically tied to IP, it certainly is applicable to the multicast IP key management issues. In fact, the issues the GKMP addressed for group keys are exactly the same issues faced by a pairwise key management protocol. Hugh From ipsec-request@ans.net Fri Nov 4 11:27:14 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA01681 (5.65c/IDA-1.4.4 for ); Fri, 4 Nov 1994 16:37:37 -0500 Received: by interlock.ans.net id AA33724 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 4 Nov 1994 16:27:10 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 4 Nov 1994 16:27:10 -0500 Message-Id: <199411042127.AA29368@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 4 Nov 1994 16:27:10 -0500 Date: Fri, 4 Nov 94 16:27:14 EST From: "Juan A. Garay ((914) 784-6852)" To: tytso@MIT.EDU Cc: ipsec@ans.net, amir@watson.ibm.com, hugo@watson.ibm.com, pau@watson.ibm.com Subject: Modular approach to key management f 11/04/94 14:51:15 Reference: Your note of Fri, 4 Nov 1994 14:51:15 +0500 Hello Ted, > Correct me if I'm wrong, but you are assuming in your design that there > will always be a long-term shared symmetric key between the > communicating parties. No, we don't assume this. The derivation of long-term shared keys is exactly the function of the "upper" module in our proposal. As explained in the note, this protocol [module] would not assume the existence of an already shared key, but is based on some form of shared trust (e.g., manual key installation, KDC or public key). The long-lived key is then used for the derivation of short-lived keys. Reasons for having these short-lived keys are explained in our note (in the "RATIONALE BEHIND THE MODULAR APPROACH" part). > That doesn't seem to be a good assumption. You could generate the > short-lived keys from a public key exchange, or the communicating > parties may have a long-term symmetric key which they both share with a > trusted third party (Kerberos). > > As near as I can tell, you're proposing that if you use one of these >schemes, such as Kerberos or X.509 public-key certificates, they be used > only to establish a long-term shared secret key --- and that long-term > secret key would only be used to establish short-term session keys. > Is this a fair characterization? > > If so, it would seem that in some cases there will be a needless extra > indirection in setting up the session key. > > - Ted Our proposal doesn't force a user to use the "lower" module, thru which short-lived keys are derived . However, distributing keys thru the means mentioned above is more expensive, and we believe ipsec has to provide a more modular and efficient option. Our proposal accommodates this situation. Juan From ipsec-request@ans.net Tue Nov 8 09:39:42 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14489 (5.65c/IDA-1.4.4 for ); Tue, 8 Nov 1994 14:46:26 -0500 Received: by interlock.ans.net id AA18357 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 8 Nov 1994 14:39:38 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 8 Nov 1994 14:39:38 -0500 Message-Id: <199411081939.AA15793@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 8 Nov 1994 14:39:38 -0500 Date: Tue, 8 Nov 94 14:39:42 EST From: hugo@watson.ibm.com To: IPSEC@ans.net Subject: On SKIP and non-interactive key management This is a long note most of which is dedicated to comment on the SKIP proposal for IPSP key management (draft-ietf-ipsec-aziz-skip-00.txt). However, the most important issue here is not the specific comments on SKIP but the need to decide on the right approach and requirements for key management for IPSP. SKIP brings up a particular dimension of this problem, namely, whether the basic key management protocols need to be "interactive" or "non-interactive". By interactive I mean protocols based on periodic handshakes between the communicating parties in which keys, SAID's and other security parameters are established (the frequency of these handshakes can be hours, days, weeks, etc. depending on the security requirements of the specific parties). In contrast, non-interactive solutions do not require handshaking and are based on unilateral derivation/transmission of keys. It may seem at a first glance that the second approach is better since it is more general. It applies even for those cases in which handshaking is not possible or convenient. However, the choice becomes harder when one realizes the security cost of non-interactive (only) solutions. Actually, let me already "SKIP" to the conclusions of this note: Non-interactive solutions are acceptable ONLY in those scenarios where the nature of the communications does not allow for periodic handshakes; whenever handshakes are possible then an interactive approach is the right choice. If this conclusion is accepted then the next step is to decide on the kind of dominant traffic in the Internet. If, as I feel, most of the traffic is between parties that can afford periodic handshakes then the interactive approach is to be chosen. Otherwise, non-interactive solutions, and SKIP is a good basis for them, are the right choice. Of course, there exist mixed approaches. I particularly see the final key management solution as being based on interactive methods with some options for non-interactive secured communications. Indeed, such options can be added to an otherwise interactive solution at a moderate cost in the complexity of the whole system (e.g., by taking advantage of the STPI field in the IPSP packet). Now, let me turn to the comments on SKIP. Most of these comments are not particular for SKIP but hold for the general non-interactive approach. SKIP is a good illustration of these methods and issues. I assume the reader is familiar with the draft. SKIP is composed of two (mostly) independent modules. (I'd recommend making this distinction more explicit in the draft). The first module deals with the sharing of a long-lived (master) key between two parties (i.e., two IP addresses). The second deals with the establishment of keys for data authentication and/or encryption in the IPSP level. The implicit independence between modules implies that the second one could use any form of master-key establishment algorithm (interactive, non-interactive, public-key based, KDC-based, etc). The comments below are separated according to the module they apply to. Master key sharing ****************** A first issue with the particular SKIP proposal is that it does not provide for master-key sharing using alternative techniques (manual installation, KDC, etc). However, this is in a sense not essential since, due to the independence of modules pointed out above, the master key sharing module could be replaced or co-exist with other mechanisms. SKIP uses Diffie-Hellman in a somewhat non-standard and very elegant way. It allows two parties to establish a shared secret key without ever (directly) communicating between them, except for the sharing of certified public-keys of each other. This functionality and elegancy come at the expense of several important disadvantages and constraints. NONE of which applies to (good) interactive solutions. Some of these issues are described below. * SKIP relies on the ONLY known (to me) technique that achieves the above "implicit" sharing of a master-key. This violates the very desirable property that a solution should be implementable using different algorithms (a property especially desirable in the case of cryptographic algorithms). Notice that PK systems that allow for encryption (e.g., RSA) can be used to communicate a key from one party to the other, however, the uniqueness of SKIP is that it provides a shared key even *before* any message is transmitted between the parties. * The compromise of a party's private key exposes ALL the traffic TO and FROM this party for the whole period this key was active (e.g., two years). Contrast this with the "standard" DH that provides the property that the compromise of any key does not expose any other key (on the other hand, the standard DH does not provide an authenticated exchange). * SKIP forces parties to maintain VERY long-lived shared keys, namely, for the same periods of time for which a public key is to be kept fixed (1, 2 or more years!). One could argue that the maintenance of very long-lived secrets is a property of any public key system. However, there is a significant difference between a system that requires ONE secret to be well protected as opposed to a LOT of simultaneous secrets as is the case in SKIP. I am assuming here that nodes cache most of the shared keys with other nodes with which they have significant communication, otherwise the scheme turns impractical (without caching the decryption of each IP packet would involve the computation of a long exponentiation). The draft says (page 8) that protection of these cryptographic keys is "beyond the scope of this document", however in a case in which you need to maintain so many secret keys that are unchanged for two years this is a prime consideration. * The purely non-interactive solution does not accommodate any form of security attributes negotiation. How do I know what algorithms and other parameters I am supposed to use with a given party. Is this published in the certificates? Is it a fixed policy for the whole Internet? If an initial interaction for negotiation is provided why not use that communication to interactively exchange keys without all of the above disadvantages? * SKIP requires public key certificates which do not provide for signature capability. In principle, this could be alleviated by extending these certificates to provide signature capability, e.g. via the DSS. * Some additional observations: - Referring to the alternative of using RSA to encrypt the transient key Kp, the draft says (line -3 page 2) that "the protocol and computational overhead of such scheme [i.e., RSA-based] is very high". I agree that the space overhead is significant and that SKIP does much better (that's THE advantage of SKIP). I agree also that the computational overhead is very high, however SKIP does not do better. (In fact, SKIP does worst since RSA encryption+decryption is a few times faster than a DH exponentiation - depending on the public exponent and implementation). Moreover, notice that the very significant space advantage of SKIP relative to RSA is for the cases where the IP node caches the master keys it shares with others. Without this caching one could use RSA and utilize the "wasted" bits beyond Kp to encrypt under the same RSA encryption (part of) the data bits. In this way the space overhead is the same as in SKIP (except if the whole packet is less than the modulus size minus Kp size). - Is the derivation of Kij as the high-order bits of a^{ij} optimal? Or, is it better to derive it, say, by applying MD5 to a^{ij}? What about derivation of multiple keys (e.g., for key encryption and key authentication). Should such a scheme support more than one way to derive Kij? This would require the specification of this algorithm in the IPSP header (adding to the space demands). Data key sharing **************** * Attaching keys to each packet. The most significant protocol penalty of SKIP is probably the need to transmit the data key(s) Kp in each packet. Even if you have most of your traffic directed to a single node (or group of nodes) with which you use an unchanged Kp for many packets still you transmit this key with each packet. This results in 100 or more bits for communicating a redundant information (much less bits can do that job, e.g. via a SAID). This significant space overhead is clearly undesirable; moreover, it "encourages" the implementation of shortcuts to alleviate this situation. An example is provided by the draft itself that after recognizing the need for both data encryption and authentication keys proposes to have one key as the prefix of the other (page 7). That's a bad cryptographic practice that compromises security and is solely motivated by the above need to alleviate the space overhead. * The transmission of algorithm identifiers and possibly other security attributes with each packet adds to the overhead even if these values are most of the time fixed for a pair of nodes. * The IPSP packet becomes key management dependent (and viceversa) * The attractive notion of unstructured SAIDs that are decided by the local implementation and transmitted to the other party is lost here. Only structured, standardized SAIDs make sense. * Replay of Kp. There is nothing in the current proposal to prevent the replay of the data key Kp. To be more specific let Kp be a key used by node i to authenticate some information transmitted to node j. Assume that an adversary A happens to know this Kp. A can then resend the key Kp encrypted under Kij in a packet to j and authenticate the new information (as coming from i) by using Kp. (Notice that A knows how the encryption of Kp under Kij looks just by taking it from the original packet from i to j). One could wonder how does A know Kp. We usually hope that this does not happen but our role as security designers is to have less hope and more safeguards. Indeed, Kp (which is a transient key and then possibly less protected or may be even a cryptanalyzable weak key) can be broken with time (the above attack does not require the replay to happen shortly after the legitimate use of Kp) or could be legitimately known by A. To illustrate the later point, consider a scenario where i sends to both j and A the same information authenticated with Kp and then transmits Kp to each of them encrypted under the respective master keys Kij and KiA. In this case, A legitimately learns Kp (and, with some added curiosity, also the value of Kij(Kp)). * The above attack can be alleviated by the use of timestamps (or in some cases key sequence numbers). Even in this case, this provides weaker security than achievable by interactive key exchange. Some issues to be considered are: - addition of safeguards against replay (of Kp) - if timestamps are used (can we trust them? i.e., assume reasonably synchronized clocks even in the presence of a malicious adversary?) they could be used as arguments to a pseudorandom function in order to derive the key(s) Kp instead of explicitly encrypting Kp. This saves space. - combine non-interactive options into a basically interactive key management scheme (we plan to do that for our proposal). Can use the STPI field for the case in which per-packet keys are transmitted. Can use both structured and unstructured SAIDs (one bit is enough to differentiate between them). Note: I have not commented about the specifics of the SKIP extension for multicast since I personally do not feel I understand all the issues involved in that problem. However, from the SKIP proposal itself it looks that extensions for multicast can be added to basically interactive key management solutions as well. Hugo From ipsec-request@ans.net Tue Nov 8 21:36:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17882 (5.65c/IDA-1.4.4 for ); Tue, 8 Nov 1994 18:55:15 -0500 Received: by interlock.ans.net id AA30032 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 8 Nov 1994 18:48:21 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 8 Nov 1994 18:48:21 -0500 X400-Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 8 Nov 1994 18:48:21 -0500 X400-Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 8 Nov 1994 18:48:21 -0500 X400-Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 8 Nov 1994 18:48:21 -0500 Date: Tue, 8 Nov 1994 16:36:00 -0500 X400-Originator: /dd.id=1748733/g=dragan/i=d/s=grebovich/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.743:08.10.94.21.51.21] X400-Content-Type: P2-1984 (2) Content-Identifier: re:On SKIP an... From: "dragan (d.) grebovich" Sender: "dragan (d.) grebovich" Message-Id: <"11757 Tue Nov 8 16:51:39 1994"@bnr.ca> To: ipsec@ans.net Subject: re:On SKIP and non-interactive key management On November 8, Hugo Krawczyk wrote: [...] >Actually, let me already "SKIP" to the conclusions of this note: > > Non-interactive solutions are acceptable ONLY in those scenarios where > the nature of the communications does not allow for periodic handshakes; > whenever handshakes are possible then an interactive approach is the > right choice. > Maybe prematurely, but you have not presented a single piece of evidence to support your statement. Now, you use this conclusion to develop a theory... >If this conclusion is accepted then the next step is to decide on the kind ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >of dominant traffic in the Internet. If, as I feel, most of the traffic is >between parties that can afford periodic handshakes then the interactive >approach is to be chosen. Otherwise, non-interactive solutions, and SKIP >is a good basis for them, are the right choice. Well, I do not believe that all the systems I periodically access 'know' me to keep me in their records. If I were to access my system at work, it may be different, my bank to check my balance - yes. But, yesterday I called U. of XYZ, tomorrow I may want to call the ABC Company, ... Do I have to register bilaterally, in order to obtain a record? > >Of course, there exist mixed approaches. I particularly see the final key >management solution as being based on interactive methods with some options >for non-interactive secured communications. OK. >Indeed, such options can be >added to an otherwise interactive solution at a moderate cost in the >complexity of the whole system (e.g., by taking advantage of the STPI field >in the IPSP packet). > >Now, let me turn to the comments on SKIP. Most of these comments are >not particular for SKIP but hold for the general non-interactive approach. >SKIP is a good illustration of these methods and issues. I assume the >reader is familiar with the draft. > >SKIP is composed of two (mostly) independent modules. >(I'd recommend making this distinction more explicit in the draft). >The first module deals with the sharing of a long-lived (master) key between >two parties (i.e., two IP addresses). The second deals with the establishment >of keys for data authentication and/or encryption in the IPSP level. >The implicit independence between modules implies that the second one >could use any form of master-key establishment algorithm (interactive, >non-interactive, public-key based, KDC-based, etc). > >The comments below are separated according to the module they apply to. > >Master key sharing >****************** > >A first issue with the particular SKIP proposal is that it does not provide >for master-key sharing using alternative techniques (manual installation, >KDC, etc). However, this is in a sense not essential since, due to the >independence of modules pointed out above, the master key sharing module >could be replaced or co-exist with other mechanisms. > >SKIP uses Diffie-Hellman in a somewhat non-standard and very elegant >way. It allows two parties to establish a shared secret key without >ever (directly) communicating between them, except for the sharing of >certified public-keys of each other. > >This functionality and elegancy come at the expense of several important >disadvantages and constraints. NONE of which applies to (good) interactive >solutions. Some of these issues are described below. > >* SKIP relies on the ONLY known (to me) technique that achieves the above >"implicit" sharing of a master-key. This violates the very desirable property >that a solution should be implementable using different algorithms (a >property especially desirable in the case of cryptographic algorithms). I am sorry, but I do not understand your point. Within a KMP, crypto-algorithms should be replaceable, not the key-management protocol we have chosen to implement. If you change the key-management protocol, you are talking about a completely different KM environment. >Notice that PK systems that allow for encryption (e.g., RSA) can be used >to communicate a key from one party to the other, however, the uniqueness >of SKIP is that it provides a shared key even *before* any message is >transmitted between the parties. Exactly - doesn't it make it better? > >* The compromise of a party's private key exposes ALL the traffic TO >and FROM this party for the whole period this key was active (e.g., two >years). Contrast this with the "standard" DH that provides the property >that the compromise of any key does not expose any other key (on the >other hand, the standard DH does not provide an authenticated exchange). > Here, you have a point. However, that is limited to the 'long-lived' shared keys, the adversary still has to calculate the 'short-lived keys'. Thus, we should demand stronger transformations between the two modules. >* SKIP forces parties to maintain VERY long-lived shared keys, namely, >for the same periods of time for which a public key is to be kept fixed >(1, 2 or more years!). One could argue that the maintenance of very >long-lived secrets is a property of any public key system. However, there >is a significant difference between a system that requires ONE secret >to be well protected as opposed to a LOT of simultaneous secrets as is >the case in SKIP. I am assuming here that nodes cache most of the shared >keys with other nodes with which they have significant communication, >otherwise the scheme turns impractical (without caching the decryption >of each IP packet would involve the computation of a long exponentiation). >The draft says (page 8) that protection of these cryptographic keys is >"beyond the scope of this document", however in a case in which you need >to maintain so many secret keys that are unchanged for two years this >is a prime consideration. > Keys could be kept for a 'reasonable time' in a cache. After that, it could be kept of an off-line medium or simply re-computed, which ever is cheaper. Which is better, to keep a last year's key (that has never been used since) or to spend several miliseconds more recalculating the long exponentiation? I would prefer the latter. :-) > >* The purely non-interactive solution does not accommodate any form of >security attributes negotiation. How do I know what algorithms and other >parameters I am supposed to use with a given party. Is this published in the >certificates? Is it a fixed policy for the whole Internet? Good point. How often does one change algorithms? Do we change them more often than 'long-term' secrets (e.g. 2-3 years)? Data-keys are changed per-session or per-message basis, but not the 'long-term' secrets, let alone algorithm changes. The first time one obtains a certificate, one receives 'expiration'. In case of sudden changes, there is always a CRL. The worst thing that could happen is that a user does not receive service he/she demanded. Requesting another certificate from a CA should resolve this problem. >If an initial interaction for negotiation is provided why not use that >communication to interactively exchange keys without all of the above >disadvantages? > I agree with the first part of the sentence - that is just what we do, but I did not see any disadvantages, so far. >* SKIP requires public key certificates which do not provide for signature >capability. In principle, this could be alleviated by extending these >certificates to provide signature capability, e.g. via the DSS. > [ ...] > >Data key sharing >**************** > >* Attaching keys to each packet. >The most significant protocol penalty of SKIP is probably the need to transmit >the data key(s) Kp in each packet. Even if you have most of your traffic >directed to a single node (or group of nodes) with which you use an unchanged >Kp for many packets still you transmit this key with each packet. This >results in 100 or more bits for communicating a redundant information >(much less bits can do that job, e.g. via a SAID). This significant >space overhead is clearly undesirable; moreover, it "encourages" the >implementation of shortcuts to alleviate this situation. Yes, something should be done about it, perhaps through SAID. >An example is >provided by the draft itself that after recognizing the need for both >data encryption and authentication keys proposes to have one key as the >prefix of the other (page 7). That's a bad cryptographic practice that >compromises security and is solely motivated by the above need to alleviate >the space overhead. > Agreed. [...] > >Hugo Now, your 'conclusion' from the begining isn't air-tight. I agree, there are things to improve, but the concept is sound. After all, this I-D is only -00.txt. :-) Regards Dragan -------------------------------------- Dragan Grebovich Bell-Northern Research P.O.Box 3511 Station C Ottawa K1Y 4H7 Ontario Canada Phone: + (613) 765-3524 Fax: + (613) 763-8385 E-mail: dragan@bnr.ca From ipsec-request@ans.net Tue Nov 8 22:44:09 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17822 (5.65c/IDA-1.4.4 for ); Tue, 8 Nov 1994 22:44:09 -0500 Received: by interlock.ans.net id AA11688 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 8 Nov 1994 22:34:21 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 8 Nov 1994 22:34:21 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 8 Nov 1994 22:34:21 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 8 Nov 1994 22:34:21 -0500 Date: Tue, 08 Nov 94 19:22:22 From: "Housley, Russ" Encoding: 639 Text Message-Id: <9410087843.AA784351342@spysouth.spyrus.com> To: tytso@MIT.EDU, "Juan A. Garay ((914) 784-6852)" Cc: ipsec@ans.net, amir@watson.ibm.com, hugo@watson.ibm.com, pau@watson.ibm.com Subject: Re: Modular approach to key management Juan A. Garay Says: Our proposal doesn't force a user to use the "lower" module, thru which short-lived keys are derived . However, distributing keys thru the means mentioned above is more expensive, and we believe ipsec has to provide a more modular and efficient option. Our proposal accommodates this situation. But, the proposal suggests that we start by standardizing the lower module. In my opinion, the upper module is the one that needs our attention. The upper module is the one that uses key distribution centers, certificate-based key management, or manual key management. Russ From ipsec-request@ans.net Wed Nov 9 09:36:45 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06530 (5.65c/IDA-1.4.4 for ); Wed, 9 Nov 1994 14:55:43 -0500 Received: by interlock.ans.net id AA32846 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 9 Nov 1994 14:36:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 9 Nov 1994 14:36:41 -0500 Message-Id: <199411091936.AA32842@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 9 Nov 1994 14:36:41 -0500 Date: Wed, 9 Nov 94 14:36:45 EST From: hugo@watson.ibm.com To: dragan@bnr.ca, ipsec@ans.net Subject: re:On SKIP and non-interactive key management Ref: Your note of Tue, 8 Nov 1994 16:36:00 -0500 Dragan (and other IKMP-interested parties), before commenting directly on your note let me stress the following point. I said in my note that I feel that we need a proposal that is basically interactive with non-interactive options. I believe you are saying that we need a non-interactive approach complemented with some interactive features. If I interpret you correctly then we are both saying that we need a mixed approach. Now, the discussion boils down to assesing trade-offs that involve both system issues and security considerations. I tried to make as clear as I could the security cost of a pure non-interactive approach; the intention was not to *eliminate* that approach but to create a basis for judging the trade-offs. I believe we will need more discussion and more opinions in order to balance the system and security needs, and still keeping a relatively simple design. SO, LET'S WORK TOGETHER TOWARDS THIS GOAL. My responses to the specifics of your note are "hidden" below. Hugo > > >Actually, let me already "SKIP" to the conclusions of this note: > > > > Non-interactive solutions are acceptable ONLY in those scenarios where > > the nature of the communications does not allow for periodic handshakes; > > whenever handshakes are possible then an interactive approach is the > > right choice. > > > Maybe prematurely, but you have not presented a single piece of evidence to > support your statement. Now, you use this conclusion to develop a theory... The conclusion was moved to the begining of the note just to make the interactive vs. non-interactive point clear also to people that wouldn't go all the way to the end of the note because of its length. But I do think I presented a lot of points (later in the note) to support this conclusion. > > >If this conclusion is accepted then the next step is to decide on the kind > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >of dominant traffic in the Internet. If, as I feel, most of the traffic is > >between parties that can afford periodic handshakes then the interactive > >approach is to be chosen. Otherwise, non-interactive solutions, and SKIP > >is a good basis for them, are the right choice. > > Well, I do not believe that all the systems I periodically access 'know' me to > keep me in their records. If I were to access my system at work, it may be > different, my bank to check my balance - yes. But, yesterday I called U. of > XYZ, tomorrow I may want to call the ABC Company, ... Do I have to register > bilaterally, in order to obtain a record? > Again, some provision for non-interactive key management is necessary. But shouldn't we take advantage of the added secuirty provided by periodic handshakes for the cases where these handshakes are possible? A CRUCIAL QUESTION IS: how much of the traffic does not allow for such handshakes? > > > >Of course, there exist mixed approaches. I particularly see the final key > >management solution as being based on interactive methods with some options > >for non-interactive secured communications. > > OK. > > >Indeed, such options can be > >added to an otherwise interactive solution at a moderate cost in the > >complexity of the whole system (e.g., by taking advantage of the STPI field > >in the IPSP packet). > > > >Now, let me turn to the comments on SKIP. Most of these comments are > >not particular for SKIP but hold for the general non-interactive approach. > >SKIP is a good illustration of these methods and issues. I assume the > >reader is familiar with the draft. > > > >SKIP is composed of two (mostly) independent modules. > >(I'd recommend making this distinction more explicit in the draft). > >The first module deals with the sharing of a long-lived (master) key between > >two parties (i.e., two IP addresses). The second deals with the establishment > >of keys for data authentication and/or encryption in the IPSP level. > >The implicit independence between modules implies that the second one > >could use any form of master-key establishment algorithm (interactive, > >non-interactive, public-key based, KDC-based, etc). > > > >The comments below are separated according to the module they apply to. > > > >Master key sharing > >****************** > > > >A first issue with the particular SKIP proposal is that it does not provide > >for master-key sharing using alternative techniques (manual installation, > >KDC, etc). However, this is in a sense not essential since, due to the > >independence of modules pointed out above, the master key sharing module > >could be replaced or co-exist with other mechanisms. > > > >SKIP uses Diffie-Hellman in a somewhat non-standard and very elegant > >way. It allows two parties to establish a shared secret key without > >ever (directly) communicating between them, except for the sharing of > >certified public-keys of each other. > > > >This functionality and elegancy come at the expense of several important > >disadvantages and constraints. NONE of which applies to (good) interactive > >solutions. Some of these issues are described below. > > > >* SKIP relies on the ONLY known (to me) technique that achieves the above > >"implicit" sharing of a master-key. This violates the very desirable property > >that a solution should be implementable using different algorithms (a > >property especially desirable in the case of cryptographic algorithms). > > I am sorry, but I do not understand your point. Within a KMP, crypto-algorithms > should be replaceable, not the key-management protocol we have chosen to > implement. If you change the key-management protocol, you are talking about a > completely different KM environment. > I am talking about the cryptographic algorithm. If you use public-key encryption in your system this can be done using RSA, ElGamal, etc. or tomorrow's great invention that will let you do encryption and decryption with just 17 multiplications (a somewhat optimistic but not impossible dream). If in the PROTOCOL you rely on a function that let you have a shared secret key with other party by just having each other's public key then I do not know how to accomplish it except for DH (here DH is a particular cryptographic primitive). If somebody breaks DH tomorrow (a very pesimistic but not impossible nightmare) or extends the license to another 17 years or for whatever other reason you need to replace DH by another thing you're stucked until somebody invents an alternative solution. I am NOT saying that this consideration by itself should make us drop the idea of using this solution, I am only saying that it IS a disadvantage. > >Notice that PK systems that allow for encryption (e.g., RSA) can be used > >to communicate a key from one party to the other, however, the uniqueness > >of SKIP is that it provides a shared key even *before* any message is > >transmitted between the parties. > > Exactly - doesn't it make it better? YES! But it has some undesirable side effects. > > > > >* The compromise of a party's private key exposes ALL the traffic TO > >and FROM this party for the whole period this key was active (e.g., two > >years). Contrast this with the "standard" DH that provides the property > >that the compromise of any key does not expose any other key (on the > >other hand, the standard DH does not provide an authenticated exchange). > > > Here, you have a point. However, that is limited to the 'long-lived' shared > keys, the adversary still has to calculate the 'short-lived keys'. Thus, we > should demand stronger transformations between the two modules. > This is not clear to me: what are the two modules and what transformations you refer to? In any case in SKIP's proposal if you know Kij you know ALL the short-lived keys. > >* SKIP forces parties to maintain VERY long-lived shared keys, namely, > >for the same periods of time for which a public key is to be kept fixed > >(1, 2 or more years!). One could argue that the maintenance of very > >long-lived secrets is a property of any public key system. However, there > >is a significant difference between a system that requires ONE secret > >to be well protected as opposed to a LOT of simultaneous secrets as is > >the case in SKIP. I am assuming here that nodes cache most of the shared > >keys with other nodes with which they have significant communication, > >otherwise the scheme turns impractical (without caching the decryption > >of each IP packet would involve the computation of a long exponentiation). > >The draft says (page 8) that protection of these cryptographic keys is > >"beyond the scope of this document", however in a case in which you need > >to maintain so many secret keys that are unchanged for two years this > >is a prime consideration. > > > Keys could be kept for a 'reasonable time' in a cache. After that, it could be > kept of an off-line medium or simply re-computed, which ever is cheaper. Which > is better, to keep a last year's key (that has never been used since) or to > spend several miliseconds more recalculating the long exponentiation? I would > prefer the latter. :-) > I prefer neither to keep unused keys nor to compute exponentiations. > > > >* The purely non-interactive solution does not accommodate any form of > >security attributes negotiation. How do I know what algorithms and other > >parameters I am supposed to use with a given party. Is this published in the > >certificates? Is it a fixed policy for the whole Internet? > > Good point. How often does one change algorithms? Do we change them more often > than 'long-term' secrets (e.g. 2-3 years)? Data-keys are changed per-session or > per-message basis, but not the 'long-term' secrets, let alone algorithm changes. > The first time one obtains a certificate, one receives 'expiration'. In case of > sudden changes, there is always a CRL. The worst thing that could happen is > that a user does not receive service he/she demanded. Requesting another > certificate from a CA should resolve this problem. > > >If an initial interaction for negotiation is provided why not use that > >communication to interactively exchange keys without all of the above > >disadvantages? > > > I agree with the first part of the sentence - that is just what we do, but I did > not see any disadvantages, so far. > WHo is "we"? There is no initial negotiation in SKIP. And again: if we add that initial negotiation then why not negotiate a master key in that interaction? If you do not see the disadvantages read my note again. You may decide to live with the disadvantges but you cannot deny their existence. > >* SKIP requires public key certificates which do not provide for signature > >capability. In principle, this could be alleviated by extending these > >certificates to provide signature capability, e.g. via the DSS. > > > [ ...] > > > >Data key sharing > >**************** > > > >* Attaching keys to each packet. > >The most significant protocol penalty of SKIP is probably the need to transmit > >the data key(s) Kp in each packet. Even if you have most of your traffic > >directed to a single node (or group of nodes) with which you use an unchanged > >Kp for many packets still you transmit this key with each packet. This > >results in 100 or more bits for communicating a redundant information > >(much less bits can do that job, e.g. via a SAID). This significant > >space overhead is clearly undesirable; moreover, it "encourages" the > >implementation of shortcuts to alleviate this situation. > > Yes, something should be done about it, perhaps through SAID. > > >An example is > >provided by the draft itself that after recognizing the need for both > >data encryption and authentication keys proposes to have one key as the > >prefix of the other (page 7). That's a bad cryptographic practice that > >compromises security and is solely motivated by the above need to alleviate > >the space overhead. > > > Agreed. > > > [...] > > > >Hugo > > Now, your 'conclusion' from the begining isn't air-tight. I agree, there are > things to improve, but the concept is sound. After all, this I-D is only > -00.txt. :-) > > Regards > > Dragan > -------------------------------------- > Dragan Grebovich > Bell-Northern Research > P.O.Box 3511 Station C > Ottawa K1Y 4H7 > Ontario > Canada > Phone: + (613) 765-3524 > Fax: + (613) 763-8385 > E-mail: dragan@bnr.ca > > From ipsec-request@ans.net Wed Nov 9 11:56:46 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14657 (5.65c/IDA-1.4.4 for ); Wed, 9 Nov 1994 17:15:27 -0500 Received: by interlock.ans.net id AA15595 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 9 Nov 1994 16:56:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 9 Nov 1994 16:56:42 -0500 Message-Id: <199411092156.AA16615@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 9 Nov 1994 16:56:42 -0500 Date: Wed, 9 Nov 94 16:56:46 EST From: "Juan A. Garay ((914) 784-6852)" To: tytso@MIT.EDU Cc: ipsec@ans.net Subject: Modular approach to key management f 11/04/94 14:51:15 Reference: Note sent to you on 4 November 1994, 15:33:54 EST Ted, I believe I misinterpreted part of your note when I replied to your comments on the key management note that I posted last week (remember, we are talking about a modular approach for key management, where short-lived keys are derived from long-lived ("master") keys): > That doesn't seem to be a good assumption. You could generate the > short-lived keys from a public key exchange, or the communicating > parties may have a long-term symmetric key which they both share with a > trusted third party (Kerberos). > > As near as I can tell, you're proposing that if you use one of these >schemes, such as Kerberos or X.509 public-key certificates, they be used > only to establish a long-term shared secret key --- and that long-term > secret key would only be used to establish short-term session keys. > Is this a fair characterization? > > If so, it would seem that in some cases there will be a needless extra > indirection in setting up the session key. > > - Ted You're right, and the point is well-taken. As presented, the note suggests two different types of exchange, as I guess the main point was to emphasize the need for the two models, and to separate the functional aspects of the two. However, in our original proposal (a note posted a couple of months back) we indicate how the two protocols can be combined to obtain both a master key (the proposal example was from public key) and a short-lived key in one shot. Following our "gradual development of the standard" approach, the relationship between the two modules requires thorough consideration and a well-defined interface/API/etc. We are looking at these issues right now, and hope to be able to contribute something soon. Regards, Juan From ipsec-request@ans.net Wed Nov 9 12:26:40 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13756 (5.65c/IDA-1.4.4 for ); Wed, 9 Nov 1994 17:30:59 -0500 Received: by interlock.ans.net id AA31179 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 9 Nov 1994 17:26:36 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 9 Nov 1994 17:26:36 -0500 Message-Id: <199411092226.AA33991@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 9 Nov 1994 17:26:36 -0500 Date: Wed, 9 Nov 94 17:26:40 EST From: "Juan A. Garay ((914) 784-6852)" X-Addr: IBM T.J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598 To: housley@spyrus.com Cc: ipsec@ans.net Subject: Modular approach to key management 11/08/94 19:22:22 Reference: Your note of Tue, 08 Nov 94 19:22:22 > Juan A. Garay Says: > > Our proposal doesn't force a user to use the "lower" module, thru > which short-lived keys are derived . However, distributing keys thru > the means mentioned above is more expensive, and we believe ipsec has > to provide a more modular and efficient option. Our proposal > accommodates this situation. > > But, the proposal suggests that we start by standardizing the lower module. > In my opinion, the upper module is the one that needs our attention. The > upper module is the one that uses key distribution centers, > certificate-based key management, or manual key management. > > Russ Russ, we are not proposing to forget about the upper module but, rather, follow a "first things first" approach. We believe that there are *very* convincing reasons (security and efficiency - need for frequent key updates; deployment and interoperability - support the variety of existing key distribution technologies. and it's fundamental to have a common module!; methodological; etc.) to do the lower module first and get us going. Juan From ipsec-request@ans.net Wed Nov 9 09:08:16 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05545 (5.65c/IDA-1.4.4 for ); Wed, 9 Nov 1994 20:16:11 -0500 Received: by interlock.ans.net id AA20692 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 9 Nov 1994 20:11:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 9 Nov 1994 20:11:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 9 Nov 1994 20:11:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 9 Nov 1994 20:11:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 9 Nov 1994 20:11:23 -0500 Date: Wed, 9 Nov 94 17:08:16 PST From: Ashar.Aziz@eng.sun.com (Ashar Aziz) Message-Id: <9411100108.AA12084@miraj.Eng.Sun.COM> To: hugo@watson.ibm.com, ipsec@ans.net Subject: Re: On SKIP and non-interactive key management >From ipsec-request@ans.net Tue Nov 8 13:58:42 1994 >If this conclusion is accepted then the next step is to decide on the kind >of dominant traffic in the Internet. If, as I feel, most of the traffic is >between parties that can afford periodic handshakes then the interactive >approach is to be chosen. Otherwise, non-interactive solutions, and SKIP >is a good basis for them, are the right choice. Hugo, Thanks for the detailed comments. Let me provide some general perspective of why we decided on a scheme like SKIP, before I comment on the specific issues you raise. It was not just that some environments can not afford periodic handshakes, as you suggest, although having no handshakes is clearly desirable in many circumstances. Examples of this include "lightning bolt" (secure) system management, infrequent or sparse traffic applications etc. The primary motivation of SKIP is simplicity along with a high level of security. What we wanted to avoid was the complexity of creating and managing pseudo-sessions underneath IP. An example of what this entails can be found in the 115 page SAMP document that Paul Lambert distributed at the last IETF meeting. And this only talks about session management, not key-management. We wanted something that we could easily implement without a legion of programmers. And to a large extent, sundry bugs in the current document notwithstanding, I believe we achieved our basic goals with SKIP. I'll point out that we had a working prototype of SKIP in an IPSP like protocol, just 4 weeks after we started building it, with a total of 2 people. The primary reason for this is the simplicity of the scheme. I brought this along with me at the July IETF meeting in Toronto, which occurred 7 weeks after we started writing software. And it has worked fine ever since, requiring little or no maintenance of the basic system other than performance tuning of various cryptosystem implementations on our part, and bringing it in compliance with the IPSP "strawman" that was discussed at the last meeting. We already had a session-oriented key-management protocol that Whit Diffie and I had designed (on paper) earlier (which is quite secure) for a connection oriented protocol and we could have simply plugged that in for IP, but we didn't for the reasons I mentioned above. >Master key sharing >****************** > >A first issue with the particular SKIP proposal is that it does not provide >for master-key sharing using alternative techniques (manual installation, >KDC, etc). However, this is in a sense not essential since, due to the >independence of modules pointed out above, the master key sharing module >could be replaced or co-exist with other mechanisms. This is not true. I mention the use of manual key-distribution in section 2.5. I dont mention KDC, because KDC can also be used for session key establishment, and therefore I didn't think it was necessary to mention just for the master key establishment. >* SKIP relies on the ONLY known (to me) technique that achieves the above >"implicit" sharing of a master-key. This violates the very desirable property >that a solution should be implementable using different algorithms (a >property especially desirable in the case of cryptographic algorithms). >Notice that PK systems that allow for encryption (e.g., RSA) can be used >to communicate a key from one party to the other, however, the uniqueness >of SKIP is that it provides a shared key even *before* any message is >transmitted between the parties. This isn't true either. SKIP is generalizable to other DH like algorithms. By other, I mean algorithms that involve different number theoretic constructions, and also different number theoretic approaches to cryptanalysis. An example of this is DH like key-agreement using elliptic curves over finite fields. The nature of the Discrete Log (DL) problem is different for elliptic curves over finite fields than the basic DH DL problem. Also, the objection you raise against SKIP applies to any protocol that uses DH. I'll note that DH is in various stages of standardization in, e.g 802.10 and X9 committees. To the extent that there is a drop replacement for DH (use your secret and combine that with another to public to compute a shared secret), it will be useable by SKIP. >* The compromise of a party's private key exposes ALL the traffic TO >and FROM this party for the whole period this key was active (e.g., two >years). Contrast this with the "standard" DH that provides the property >that the compromise of any key does not expose any other key (on the >other hand, the standard DH does not provide an authenticated exchange). Some comments on this issue: Forward secrecy (which is what you are referring to) is desirable in many circumstances. Clear examples of this include protocols for secure telephones, where what is discussed doesn't reside in easily accessible storage devices. It is also good for computer data protocols which involve transient data. However, many commonly used network protocols transfer data that is long lived on storage devices. Any compromise of long-term keys does compromise authentication, and therefore the privacy of the data that lives on long-term storage. Examples of this include file transfer protocols, e-mail etc, which are common uses of the Internet. Therefore, from a system design perspective, since authentication failures lead to privacy failures, protection of long term keys is important whether or not the protocol sports some form of forward secrecy. Forward secrecy also does not make sense in cases where weak cryptosystems are used, because it is easier to brute force attack the traffic than it is to actively recover keys from tamper-resist devices. (Many circumstances oblige us to use weak cryptosystems.) This is not an argument against forward-secrecy, just an attempt to highlight the various issues. Protocol design involves making tradeoffs. I note that in your original proposal you dont propose perfect forward secrecy (a la DH), but rather good forward secrecy, where compromise of both parties' private keys *does* compromise past encrypted data. This one example of a tradeoff that people (like yourselves) make in favor of other issues, like performance. At the last IETF I did mention how one could combine traditional DH with SKIP to achieve authenticated perfect forward secrecy (and with better performance than other authenticated perfect forward secrecy solutions), but have resisted putting this in the draft in order to avoid the complexity issue I described earlier. >* SKIP forces parties to maintain VERY long-lived shared keys, namely, >for the same periods of time for which a public key is to be kept fixed >(1, 2 or more years!). One could argue that the maintenance of very >long-lived secrets is a property of any public key system. However, there >is a significant difference between a system that requires ONE secret >to be well protected as opposed to a LOT of simultaneous secrets as is >the case in SKIP. I am assuming here that nodes cache most of the shared >keys with other nodes with which they have significant communication, >otherwise the scheme turns impractical (without caching the decryption >of each IP packet would involve the computation of a long exponentiation). This is purely an implementation issue. One doesn't have to forever cache a computed shared key. For example, in our current implementation the cache of shared secrets is flushed on reboot. The secrets are easily recovered using a single exponentiation for each one, and are then cached for the duration of that power-up period. The tradeoff isn't: do it forever, or else do DH for each packet. >The draft says (page 8) that protection of these cryptographic keys is >"beyond the scope of this document", however in a case in which you need >to maintain so many secret keys that are unchanged for two years this >is a prime consideration. The reason I state that is because, in standards parlance, this is a "local issue". It is not a protocol issue. But I will describe this and other implementation issues in a "SKIP: Design and Implementation" paper that I am currently writing, and hope to finish before the next IETF. >* The purely non-interactive solution does not accommodate any form of >security attributes negotiation. How do I know what algorithms and other >parameters I am supposed to use with a given party. Is this published in the >certificates? Is it a fixed policy for the whole Internet? How does an end node decide what should be the outcome of a particular negotiation? This cannot be hard coded in an implementation for all possible applications above IP. The answer is: system management. This is the way we control the choice of algorithms etc. I will mention these issues as well in the paper I am writing. >If an initial interaction for negotiation is provided why not use that >communication to interactively exchange keys without all of the above >disadvantages? Because what algorithms to use with a given node doesn't change as often as keys need to change. >* SKIP requires public key certificates which do not provide for signature >capability. In principle, this could be alleviated by extending these >certificates to provide signature capability, e.g. via the DSS. Can you provide reasons for why one might need signature capability at the IP layer? SKIP accomplishes, privacy, authenticty etc. for both unicast and multicast IP without using signatures. If there is a demonstrable need, I would have no problems in accepting DSS or RSA or whatever signature algorithm in addition to DH public keys. >* Some additional observations: > > - Referring to the alternative of using RSA to encrypt the transient key Kp, > the draft says (line -3 page 2) that "the protocol and computational overhead > of such scheme [i.e., RSA-based] is very high". I agree that the space > overhead is significant and that SKIP does much better (that's THE advantage > of SKIP). I agree also that the computational overhead is very high, > however SKIP does not do better. (In fact, SKIP does worst since RSA > encryption+decryption is a few times faster than a DH exponentiation - > depending on the public exponent and implementation). > Moreover, notice > that the very significant space advantage of SKIP relative to RSA is > for the cases where the IP node caches the master keys it shares with > others. Without this caching one could use RSA and utilize the "wasted" > bits beyond Kp to encrypt under the same RSA encryption (part of) the > data bits. In this way the space overhead is the same as in SKIP (except > if the whole packet is less than the modulus size minus Kp size). > I am afraid I cant agree here. What you suggest is infinitely worse than the comparison I was making between RSA and DH. I was comparing the case of cached shared keys (derived using DH) used to decrypt the inline packet keys as they changed. I was comparing that with inline RSA encrypted keys, for which you would do an RSA decryption when the key *changed*, (not on every packet). Of course SKIP does better computationally here. What you are suggesting, RSA encrypting the key and part of the data packet requires an RSA decryption on *every* received packet (since the data will change in every packet, even if the key doesn't). This is infinitely worse than SKIP, and has no hope of ever being better, no matter what caching strategy is employed. > - Is the derivation of Kij as the high-order bits of a^{ij} optimal? > Or, is it better to derive it, say, by applying MD5 to a^{ij}? MD5 is a one-way function. So is modular exponentiation. Computing the MD5 of the output of DH is much like computing the MD5 of an MD5 output, if one doesn't need the whole MD5 output. It isn't necessary. (I'll note that a draft X9.42 document uses essentially the SKIP technnique for deriving a key from a DH exchange). I'll stop here, as this note is already too long, and continue with the rest of the issues you raise in a follow-up note. This will give you (and others) to comment on my responses, and we will hopefully be able to do this work in parallel. Please keep the comments coming! Ashar. From ipsec-request@ans.net Thu Nov 10 02:22:46 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15351 (5.65c/IDA-1.4.4 for ); Thu, 10 Nov 1994 13:32:21 -0500 Received: by interlock.ans.net id AA28265 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 10 Nov 1994 13:22:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 10 Nov 1994 13:22:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 10 Nov 1994 13:22:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 10 Nov 1994 13:22:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 10 Nov 1994 13:22:31 -0500 Date: Thu, 10 Nov 94 10:22:46 PST From: Ashar.Aziz@eng.sun.com (Ashar Aziz) Message-Id: <9411101822.AA12491@miraj.Eng.Sun.COM> To: hugo@watson.ibm.com Subject: re:On SKIP and non-interactive key management Cc: ipsec@ans.net Here is the second part of my responses to Hugo's comments. > From: hugo@watson.ibm.com > What about derivation of multiple keys (e.g., for key encryption and key > authentication). Should such a scheme support more than one way to derive > Kij? This would require the specification of this algorithm in the IPSP > header (adding to the space demands). What is the benefit of this? If a packet is authenticated, and the packet key verifies it, doesn't this authenticate the key as well? Why is there a need to have multiple ways of deriving Kij? >Data key sharing >**************** > >* Attaching keys to each packet. >The most significant protocol penalty of SKIP is probably the need to transmit >the data key(s) Kp in each packet. Even if you have most of your traffic >directed to a single node (or group of nodes) with which you use an unchanged >Kp for many packets still you transmit this key with each packet. This >results in 100 or more bits for communicating a redundant information >(much less bits can do that job, e.g. via a SAID). This significant >space overhead is clearly undesirable; The penalty of inline keys is approx 1% of a typical 1024 byte IP packet. How much this matters depends on the bandwidth of the networks on which this is to operate. On very slow links this is a disadvantage. On fast links, this is less of an issue. I'll note that the *fixed* header overhead of link protocols like ATM (designed for high-bandwidth physical links) is ~10%. For slow links, the combination of SKIP and compression (allowed in the basic SKIP proposal) will do far better than unencrypted and uncompressed IP. This is because compression can gain us a factor of 200-300% in space savings, whereas the inline keys only add 2% and the total IPSP header is approx 6% penalty of a 512 byte packet (even assuming smaller MTU size for slow links). >moreover, it "encourages" the >implementation of shortcuts to alleviate this situation. An example is >provided by the draft itself that after recognizing the need for both >data encryption and authentication keys proposes to have one key as the >prefix of the other (page 7). That's a bad cryptographic practice that >compromises security and is solely motivated by the above need to alleviate >the space overhead. I agree completely that this is a bad idea. However, the reason is simply inadequate reflection on the issue. This was one of the last things that I put in the draft, and didn't get to think for too long about the issue. Soon after I sent the draft, I realized this was a bad idea, and now I propose a simple fix to it. Instead of using a subset bits of Kp for encryption, compute the ICV of the concatentaion of (Kij + Kp) and use the upper n bits of the ICV. The ICV algorithm is the same as the ICV algorithm for packet authentication (ICV alg). This doesn't incur any extra space overhead, and solves the problem you mention. >* The transmission of algorithm identifiers and possibly other security >attributes with each packet adds to the overhead even if these values are >most of the time fixed for a pair of nodes. Of course, this kind of argument can be made against an IP header as well. One can end up arguing in favor of a connection oriented network protocol like X.25 instead of IP, with this line of argument. (And precisely some of these arguments were made by X.25 proponents). >* The attractive notion of unstructured SAIDs that are decided by the local >implementation and transmitted to the other party is lost here. Only >structured, standardized SAIDs make sense. What is attractive about unstructured SAIDs? I realize the need for IPSP to allow all kinds of key-management, and hence unstructured SAIDs, but fail to see anything terribly attractive about unstructured SAIDs. The only thing about SAIDs is that they are decided by a receiving node, and if a receiving node chooses structured SAIDs, and advertises that in advance, what is wrong with that? Once again, I'll stop here, and complete the rest of my responses to the remainder of your comments in another follow-up message. And again, thanks for the thoughtful comments. Ashar. From ipsec-request@ans.net Thu Nov 10 18:34:10 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17686 (5.65c/IDA-1.4.4 for ); Thu, 10 Nov 1994 13:36:55 -0500 Received: by interlock.ans.net id AA13627 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 10 Nov 1994 13:34:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Thu, 10 Nov 1994 13:34:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 10 Nov 1994 13:34:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 10 Nov 1994 13:34:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 10 Nov 1994 13:34:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 10 Nov 1994 13:34:16 -0500 Message-Id: <9411101834.AA28517@gimili.watson.ibm.com> To: ipsec@ans.net Cc: hamid@watson.ibm.com Subject: What should we do first X-Mailer: exmh version 1.2 1/14/94 Date: Thu, 10 Nov 1994 13:34:10 -0500 From: " " Juan put it very well: we need to focus and standardize _real_soon_ a module that would alow secure IP-layer security. Jeff Schiller put it to us very clearly in the last IETF: `... the internet is bleeding'. This is a critical problem which is a major concern to many of our customers. In the higher layers, there would probably be a prolifiration of techniques, regardless of our efforts to standardize - where this prolifiration is the result of existing systems, efficiency, licensing, and many other reasons some of which are even justified... It is up to us - IP-SEC and IKMP working groups - to create the security equivalent of IP: a small protocol that would enable interoperability. Let's work together to make it happen. Best, Amir Herzberg ------- Forwarded Message Return-Path: root Received: from yktvmv-ob.watson.ibm.com by gimili.watson.ibm.com (AIX 3.2/UCB 5.64/930311) id AA37038; Wed, 9 Nov 1994 17:38:57 -0500 Received: from watson.vnet.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 5559; Wed, 09 Nov 94 17:38:58 EST Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.0" id for amir@watson; Wed, 09 Nov 94 17:38:58 -0500 Received: from interlock.ans.net by watson.ibm.com (IBM VM SMTP V2R3) with TCP; Wed, 09 Nov 94 17:38:56 EST Received: by interlock.ans.net id AA31179 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 9 Nov 1994 17:26:36 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 9 Nov 1994 17:26:36 -0500 Message-Id: <199411092226.AA33991@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 9 Nov 1994 17:26:36 -0500 Date: Wed, 9 Nov 94 17:26:40 EST From: "Juan A. Garay ((914) 784-6852)" X-Addr: IBM T.J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598 To: housley@spyrus.com Cc: ipsec@ans.net Subject: Modular approach to key management 11/08/94 19:22:22 Reference: Your note of Tue, 08 Nov 94 19:22:22 > Juan A. Garay Says: > > Our proposal doesn't force a user to use the "lower" module, thru > which short-lived keys are derived . However, distributing keys thru > the means mentioned above is more expensive, and we believe ipsec has > to provide a more modular and efficient option. Our proposal > accommodates this situation. > > But, the proposal suggests that we start by standardizing the lower module. > In my opinion, the upper module is the one that needs our attention. The > upper module is the one that uses key distribution centers, > certificate-based key management, or manual key management. > > Russ Russ, we are not proposing to forget about the upper module but, rather, follow a "first things first" approach. We believe that there are *very* convincing reasons (security and efficiency - need for frequent key updates; deployment and interoperability - support the variety of existing key distribution technologies. and it's fundamental to have a common module!; methodological; etc.) to do the lower module first and get us going. Juan ------- End of Forwarded Message From ipsec-request@ans.net Thu Nov 10 09:30:19 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15569 (5.65c/IDA-1.4.4 for ); Thu, 10 Nov 1994 21:48:24 -0500 Received: by interlock.ans.net id AA16346 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 10 Nov 1994 21:30:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 10 Nov 1994 21:30:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 10 Nov 1994 21:30:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 10 Nov 1994 21:30:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 10 Nov 1994 21:30:22 -0500 Date: Thu, 10 Nov 94 17:30:19 PST From: Ashar.Aziz@eng.sun.com (Ashar Aziz) Message-Id: <9411110130.AA12926@miraj.Eng.Sun.COM> To: hugo@watson.ibm.com Subject: re:On SKIP and non-interactive key management Cc: ipsec@ans.net Here is the third part of my responses to Hugo's comments. >From: hugo@watson.ibm.com >* Replay of Kp. There is nothing in the current proposal to prevent the >replay of the data key Kp. To be more specific let Kp be a key used by >node i to authenticate some information transmitted to node j. Assume >that an adversary A happens to know this Kp. A can then resend the key >Kp encrypted under Kij in a packet to j and authenticate the new information >(as coming from i) by using Kp. (Notice that A knows how the encryption >of Kp under Kij looks just by taking it from the original packet from >i to j). One could wonder how does A know Kp. We usually hope that this >does not happen but our role as security designers is to have less hope >and more safeguards. Indeed, Kp (which is a transient key and then possibly >less protected or may be even a cryptanalyzable weak key) can be broken >with time (the above attack does not require the replay to happen shortly >after the legitimate use of Kp) or could be legitimately known by A. I am not convinced about the actual danger of this kind of attack. The attack involves compromise of an authentication key and doesn't really apply to privacy keys. There is no reason whatsoever for an authentication key to be weak. No performance reason, and no export control reason. For fast ICV computation, one can compute a message-digest and compute the MAC code over the digest or encrypt that using a strong cryptosystem. There is no performance penalty here to using something like multiple encryption DES (say triple DES), since we are only talking about 8-16 bytes per packet. And of course, the encryption of Kp doesn't have to weak either, for the same reasons. Note that the encryption of Kp under Kij overhead is not per packet but per key-change. Also, the weak cryptosystem export requirement is only for privacy algorithms, not authentication algorithms. So there is no reason *at all* for this key to be weak (and this is part of the reason why SKIP separates authentication and privacy keys). If we are going to be hypothetical about weak keys, just for the sake of discussion, the key-management keys (the equivalent of Kij in SKIP) could also be weak (why not?). This would compromise the long-term keys, and therefore allow attacks from authentication failure as well. This kind of argument can be made against any conceivable protocol. If there is a legitimate reason for Kp or the encryption of Kp to be weak, I would be happy to learn of it. Because of this, I dont think that there is any reason to complicate the protocol just for the sake of this issue. If this is really a hot button, then I can suggest solutions (not right now, but in a future message) that can prevent this which don't require synchronized clocks or the need for interactive key-management with its associated complexity. However, I am personally not convinced that this is such a big issue. >To illustrate the later point, consider a scenario where i sends to both >j and A the same information authenticated with Kp and then transmits >Kp to each of them encrypted under the respective master keys Kij and >KiA. In this case, A legitimately learns Kp (and, with some added curiosity, >also the value of Kij(Kp)). This, of course, is even less likely, because there is no reason to reuse keys Kp for different nodes. They are always randomly generated for each end node. If by chance they happen to be the same for different end nodes, (near zero probability) the end nodes will never learn of this because they are encrypted under different master keys. Peace, Ashar. From ipsec-request@ans.net Fri Nov 11 17:00:11 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13322 (5.65c/IDA-1.4.4 for ); Fri, 11 Nov 1994 22:13:56 -0500 Received: by interlock.ans.net id AA19407 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 11 Nov 1994 22:08:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 11 Nov 1994 22:08:14 -0500 Message-Id: <199411120308.AA26315@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 11 Nov 1994 22:08:14 -0500 Date: Fri, 11 Nov 94 22:00:11 EST From: hugo@watson.ibm.com To: Ashar.Aziz@eng.sun.com, ipsec@ans.net Cc: hugo@watson.ibm.com Subject: Re: On SKIP and non-interactive key management Ashar, Thanks for taking seriously my comments. In this note instead of going into a detailed response to the many issues raised in our previous notes, I will stress several points that I believe are mostly important regarding your design and the general issues we face in the design of key management for IPSP. These points already incorporate what I learned from your responses. 1) We need to decide whether the basis for IPSP key management is an interactive protocol or non-interactive (SKIP is a good example of the later). Even if I believe we'll finally have a mixed protocol, deciding on the basis is significant for trade-off assessment. 2) Simplicity is indeed a fundamental issue. But simplicity is not a 0/1 parameter, and it involves trade-offs with a lot of considerations, in particular, system and security considerations. One needs to optimize simplicity together with these considerations. Having interactive protocols for key sharing does NOT necessarily carry a big complexity. We have implemented our short-lived (or session) key management protocol from scratch in one month by one person (including debugging and testing). This is not the whole IKMP but is basically the only piece that can be somehow saved in non-interactive solutions. 3) Space penalty. In my opinion you underestimate this issue much below it deserves. People have been arguing against ICVs in the IP packets (by not having them at all or using 32 bit checksums or other insecure solutions) and against the use of IV's just because they feel the savings in bits are important to them. And now you come and say that the overhead of a key (and some algorithm id's) in the IPSP header is not big deal. One could possibly live with it if that's the only solution. But since there are not less (and possibly, more) sound alternatives we have to consider them. 4) Keeping symmetric shared keys unchanged for very very long period of time. This is a weak design property (and not just "a purely implementation issue" as you say) that needs to be avoided whenever possible. Even if you do things as you mention like flushing keys on reboot, still the accumulated time in which they are exposed to intruders during their long useful life is dangerous. Remember that attackers will multiply their efforts according to the size of the reward. Your very long lived keys are in fact an attractive reward. As said above, if there is no alternative or the associated advantages justify it you can think of doing this. But is this the case here? If you do interactive refreshments (even each 3 months) you already are in much better shape. 5) Compromising on security without a clear system gain. I believe that some aspects of your design compromise on security beyond what is needed (and I am in favor of compromising on security when the system requirements call for it). The maintenance of very long-lived keys without changes, the exposure of all traffic to and from a party by compromising only its private key, the exposure to some forms of replay attacks on packet contents, are examples. Your arguments in some of your responses that you do not see the exact scenarios where some attacks may happen is not enough. Internet is very heterogeneous, there are very different scenarios, different policies and all of this evolves over time. One needs to try to be sound even in spite of this "uncertainty". The fact, for example, that you do "not see any reason to use weak keys for authentication" does not mean that people will not compromise on it (you suggest triple-DES but how many will do that?), or that weaknesses will not be found in algorithms, or that people will not discard keys with the whole care they require, etc. The design needs to maximize security as much as possible even in the presence of "non-aware" users/applications and system evolution. That's one of our roles. I will repeat it: this shouldn't come at the expense of a complicated design or hurting system performance beyond acceptable. But again: all these aspects have better solutions under the interactive model. Finally, I'll come back to the point of modular design. I believe that a key refreshment and key derivation protocol common to different (KDC,PK,etc) scenarios of key distribution is a great design point and a realistic development step. And we should work on that. But this is an issue for other note(s). I hope to find some time to answer more specific issues you raise, but somehow the usefulness of going into details in these long notes is dubious. I preferred to start with the more essential points as expressed above. Peace, peace, peace Hugo From ipsec-request@ans.net Sun Nov 13 11:09:30 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14797 (5.65c/IDA-1.4.4 for ); Sun, 13 Nov 1994 11:09:30 -0500 Received: by interlock.ans.net id AA31191 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 13 Nov 1994 10:59:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sun, 13 Nov 1994 10:59:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 13 Nov 1994 10:59:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 13 Nov 1994 10:59:23 -0500 Date: Sun, 13 Nov 94 07:44:55 From: "Housley, Russ" Encoding: 2531 Text Message-Id: <9410137847.AA784741495@spysouth.spyrus.com> To: garay@watson.ibm.com Cc: ipsec@ans.net Subject: Re: Modular approach to key management 11/08/94 19 ______________________________ Reply Separator _________________________________ Subject: Modular approach to key management 11/08/94 19:22: Author: "Juan A. Garay ((914) 784-6852)" at internet Date: 11/9/94 5:26 PM Reference: Your note of Tue, 08 Nov 94 19:22:22 First, Juan A. Garay Said: Our proposal doesn't force a user to use the "lower" module, thru which short-lived keys are derived . However, distributing keys thru the means mentioned above is more expensive, and we believe ipsec has to provide a more modular and efficient option. Our proposal accommodates this situation. I replied: But, the proposal suggests that we start by standardizing the lower module. In my opinion, the upper module is the one that needs our attention. The upper module is the one that uses key distribution centers, certificate-based key management, or manual key management. Then Juan said: we are not proposing to forget about the upper module but, rather, follow a "first things first" approach. We believe that there are *very* convincing reasons (security and efficiency - need for frequent key updates; deployment and interoperability - support the variety of existing key distribution technologies. and it's fundamental to have a common module!; methodological; etc.) to do the lower module first and get us going. My reply to this: For IPSP to be widely deployed, automated key management is required. By postponing the definition of KDC or certificate-based key management to establish traffic encryption keys, then the "lower module" is forced to use a manual approach. While manual key management has its uses, I do not think that manual key management will facilitate the deployment of IPSP in the Internet. In the IEEE 802.10c Key Management Protocol, all three forms of key management are supported: KDC, certificate-based, and manual. Each of these techniques can be used to establish a traffic encryption key, then a common attribute negotiation technique is used. I think that IPSEC can adopt all of this work with minimal adaption to the Internet. By starting with IEEE 802.10c, the "upper module" is nearly complete. All that remains is to define the syntax for negotiation of IPSP attributes. In my opinion, IEEE 802.10c offers the shortest time to market solution for IPSP key management. Russ From ipsec-request@ans.net Mon Nov 14 12:58:04 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA33957 (5.65c/IDA-1.4.4 for ); Mon, 14 Nov 1994 08:14:45 -0500 Received: by interlock.ans.net id AA38311 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 14 Nov 1994 08:01:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 14 Nov 1994 08:01:35 -0500 From: Ran Atkinson Message-Id: <9411140758.ZM27031@sundance.itd.nrl.navy.mil> Date: Mon, 14 Nov 1994 07:58:04 -0500 In-Reply-To: "Housley, Russ" "Re: Modular approach to key management 11/08/94 19" (Nov 13, 7:44) References: <9410137847.AA784741495@spysouth.spyrus.com> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.1 04apr94) To: ipsec@ans.net Subject: Re: Modular approach to key management Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: atkinson@sundance.itd.nrl.navy.mil Hugh, Russ, Hugo, Ashar, and others, I'd like to know _exactly_ what the patent status is of each of the proposals on the table. By this I mean that I'd like to see the following become crystal clear: 1) Is any aspect of the proposal patented (including patents pending) ? 1b) If so, which parts are patented by which patent numbers and who are the inventors and assignees ? 2) If some prior agreement has been reached that the patent will be made available to all comers at no cost (e.g. as part of IEEE 802 work), that would be worth knowing about. Otherwise, under what terms are the patents available ? We have had strongly negative history within the past year in the Mobile IP working group where people knew they had patents but did not disclose those patents up front. The IETF way is to disclose the existence of patents IMMEDIATELY and to the ENTIRE working group, not just the chairpeople. I'd really like to avoid hidden patent issues in this work. Even if (2) isn't immediately answerable, it is very important to openly disclose (1) and (1b) immediately and to the entire list. I think most folks are aware of the Diffie-Hellman and RSA patents. I believe the use of the RSA-Ref software package legally excludes individuals (but not vendors) from having to pay monetary license fees on those 2 patents. Regards, Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Mon Nov 14 13:38:17 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA34684 (5.65c/IDA-1.4.4 for ); Mon, 14 Nov 1994 08:46:58 -0500 Received: by interlock.ans.net id AA39201 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 14 Nov 1994 08:38:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 14 Nov 1994 08:38:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 14 Nov 1994 08:38:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 14 Nov 1994 08:38:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 14 Nov 1994 08:38:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 14 Nov 1994 08:38:22 -0500 Message-Id: <9411141338.AA19916@gimili.watson.ibm.com> To: "Housley, Russ" , ipsec@ans.net Subject: Re: Modular approach to key management 11/08/94 19 In-Reply-To: Your message of "Sun, 13 Nov 1994 07:44:55." <9410137847.AA784741495@spysouth.spyrus.com> X-Mailer: exmh version 1.2 1/14/94 Date: Mon, 14 Nov 1994 08:38:17 -0500 From: " " Russ, you said: > > For IPSP to be widely deployed, automated key management is required. Agreed! > By > postponing the definition of KDC or certificate-based key management to > establish traffic encryption keys, then the "lower module" is forced to use > a manual approach. Or use another key distribution method both ends support - many candidates exist... Having to agree on the mechanism is not the same as having to agree on a key (manual key distribution). However, I agree that it would be much better if we had automated negotiation of methods i.e. a standard high-level key management alg. The questions are: 1. Should we do a small common module already, without waiting to resolve the higher layer problem? We believe the answer is YES. 2. How do we solve the higher layer problem? I think there are too many possibilities rather than too few... You seem to suggest a specific one: > In the IEEE 802.10c Key Management Protocol, all three forms of key > management are supported: KDC, certificate-based, and manual. Each of > these techniques can be used to establish a traffic encryption key, then a > common attribute negotiation technique is used. I think that IPSEC can > adopt all of this work with minimal adaptation to the Internet. By starting > with IEEE 802.10c, the "upper module" is nearly complete. We (in particular Juan) tried to learn and re-use IEEE 802.10c as much as we could. (Juan, you may want to elaborate.) Maybe you (and others) can help the WG to use more of it - that would be great. In particular, if it is really so easy to solve the `higher layer' problem by adopting much of 802.10c, great! We need somebody who understands it very well (better than us...) to make a contribution. However, even if we have this contribution, it would still make sense to have the `lower level' mechanism for short-lived keys, to increase interoperability and get more products to market quicker. One factor to remember is that there are many candidates for the higher layer, including many existing products (e.g. our own NetSP) and emerging standards such as SHTTP which could be re-used or merged. This is a very important discussion and we hope to help. But, we believe this WG(s?) should first provide the lower layer. Even if used with manual key management by some pairs of partners, it would still help to `stop the bleeding' - and this is what we were told to do by the IESG. Best, Amir Herzberg From ipsec-request@ans.net Mon Nov 14 14:13:19 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA34761 (5.65c/IDA-1.4.4 for ); Mon, 14 Nov 1994 09:17:23 -0500 Received: by interlock.ans.net id AA24794 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 14 Nov 1994 09:13:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 14 Nov 1994 09:13:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 14 Nov 1994 09:13:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 14 Nov 1994 09:13:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 14 Nov 1994 09:13:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 14 Nov 1994 09:13:26 -0500 Message-Id: <9411141413.AA19907@gimili.watson.ibm.com> To: ipsec@ans.net Cc: circjwl@rhqvm07.watson.ibm.com Subject: Re: Modular approach to key management In-Reply-To: Ran's message of "Mon, 14 Nov 1994 07:58:04 EST." <9411140758.ZM27031@sundance.itd.nrl.navy.mil> From: " " X-Mailer: exmh version 1.2 1/14/94 Date: Mon, 14 Nov 1994 09:13:19 -0500 Sender: amir@watson.ibm.com Ran, Thank you for asking. As you may remember, at the previous IETF I said that I was already making every effort to convince IBM that security in the internet is so important to us and our customers, that we should give our relevant patent for free. The patent, as I've described before, is US 5,148,479, invented by Bird, Gopal, Janson, Kutten, Molva and Yung and assigned to IBM. (Personally I find the claims in this patent to be too broad.) I'm happy to inform you that, after many efforts, the issue seems to have been resolved in the right way (i.e. no fees for use of that patent to implement our proposal). IBM lawyers are working this week on the precise statement (so I did not announce until you asked). I hope and believe there wouldn't be any `trap-doors'. If we find any such problems with the text, I'll again work on getting it resolved. If you so desire, the lawyers are actually willing to discuss the statement (I'm not sure what this means): contact John Lowe at 1-914-742-6275 (cc:ed above). Of course, I cannot fully guarantee that IBM (or others) do not have other patents covering our (or other) proposals. However, we did a substantial effort to search the entire IBM portfolio (including patents filed but not issued), and found none. Again, this is no guarantee... Let me just mention that we have already made the fact that our proposal is covered by IBM patent well known. Your point in the note is correct: initially we just discussed this with the chairpersons, this was due to mis-interpreting the process (we thought that we should write the patent issue as a part of our formal proposal and were not aware that we are expected to announce it before any technical discussion). After you and others have pointed to us that the norm is to announce immediately, we did just that. Thanks for this clarification. Now that we have addressed this issue, I hope that you (and others) would help us to get this done! Best, Amir Herzberg ------- End of Forwarded Message From ipsec-request@ans.net Mon Nov 14 14:31:54 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27575 (5.65c/IDA-1.4.4 for ); Mon, 14 Nov 1994 09:41:42 -0500 Received: by interlock.ans.net id AA37819 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 14 Nov 1994 09:31:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 14 Nov 1994 09:31:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 14 Nov 1994 09:31:43 -0500 Message-Id: <9411141431.AA11999@columbia.sparta.com> To: atkinson@itd.nrl.navy.mil Cc: ipsec@ans.net, hh@columbia.sparta.com Subject: Re: Modular approach to key management In-Reply-To: Your message of "Mon, 14 Nov 94 07:58:04 EST." <9411140758.ZM27031@sundance.itd.nrl.navy.mil> Date: Mon, 14 Nov 94 09:31:54 -0500 From: Hugh Harney Ran, The GKMP is not patented. We considered applying, but decided not to. Hugh From ipsec-request@ans.net Mon Nov 14 14:48:44 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15531 (5.65c/IDA-1.4.4 for ); Mon, 14 Nov 1994 10:06:51 -0500 Received: by interlock.ans.net id AA35921 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 14 Nov 1994 09:57:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 14 Nov 1994 09:57:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 14 Nov 1994 09:57:25 -0500 X-Nupop-Charset: English Date: Mon, 14 Nov 1994 16:48:44 +0200 (EET) From: "Sara Bitan" Sender: sarab@radmail.rad.co.il Message-Id: <199411141649238540.sarab@radmail.rad.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Ashar.Aziz@eng.sun.com, hugo@watson.ibm.com, ipsec@ans.net Subject: SKIP and interactive key management Ashar, Hugo, Why not use a hybrid solution, i.e., add periodic handshakes to SKIP? On November 8, Hugo Krawczyk wrote: >SKIP is composed of two (mostly) independent modules. >(I'd recommend making this distinction more explicit in the draft). >The first module deals with the sharing of a long-lived (master) key between >two parties (i.e., two IP addresses). The second deals with the establishment >of keys for data authentication and/or encryption in the IPSP level. >The implicit independence between modules implies that the second one >could use any form of master-key establishment algorithm (interactive, >non-interactive, public-key based, KDC-based, etc). > > >* The compromise of a party's private key exposes ALL the traffic TO >and FROM this party for the whole period this key was active (e.g., two >years). Contrast this with the "standard" DH that provides the property >that the compromise of any key does not expose any other key (on the >other hand, the standard DH does not provide an authenticated exchange). > >* SKIP forces parties to maintain VERY long-lived shared keys, namely, >for the same periods of time for which a public key is to be kept fixed >(1, 2 or more years!). One could argue that the maintenance of very >long-lived secrets is a property of any public key system. However, there >is a significant difference between a system that requires ONE secret >to be well protected as opposed to a LOT of simultaneous secrets as is >the case in SKIP. I am assuming here that nodes cache most of the shared >keys with other nodes with which they have significant communication, >otherwise the scheme turns impractical (without caching the decryption >of each IP packet would involve the computation of a long exponentiation). >The draft says (page 8) that protection of these cryptographic keys is >"beyond the scope of this document", however in a case in which you need >to maintain so many secret keys that are unchanged for two years this >is a prime consideration. > To solve the problem of a very long-lived shared key, and the problem of the whole traffic exposure, try to devise a way to use SKIP as the SHORT-LIVED KEYS MODULE, and add a LONG-LIVED KEY MODULE that will be used to establish a shared symmetric key between the parties. I.e., the packet key, Kp will be encrypted by a shared master key. The master key will be derived from the parties personal keys, and will be periodically changed. Personal keys can be certified public keys, keys assigned by KDC, etc. Various protocols can be used for the establishment of the master key. The life time of the master key should be relatively long, but not too long (e.g. a month, a week). The parties will use periodic handshakes to establish a current master key, and a master key ID - the master key ID will be one bit. One of the 22 zero bits of the SAID field in the SKIP draft can be used as the master-key ID. The master-key ID bit will be toggled when a new master key is established. After a new master key is established, there is a fixed period of time during which the two master keys (the new key and the previous key) overlap. After this period of time the old master key will be discarded and all the packets that arrive with the old master-key ID will be rejected (i.e. discarded). Regards, Sara Bitan RadGuard LTD. Israel 972-3-6459592 From ipsec-request@ans.net Mon Nov 14 04:21:34 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA31512 (5.65c/IDA-1.4.4 for ); Mon, 14 Nov 1994 21:20:47 -0500 Received: by interlock.ans.net id AA37773 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 14 Nov 1994 21:06:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 14 Nov 1994 21:06:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 14 Nov 1994 21:06:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 14 Nov 1994 21:06:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 14 Nov 1994 21:06:37 -0500 Date: Mon, 14 Nov 94 12:21:34 PST From: Ashar.Aziz@eng.sun.com (Ashar Aziz) Message-Id: <9411142021.AA15218@miraj.Eng.Sun.COM> To: ipsec@ans.net, atkinson@itd.nrl.navy.mil Subject: Re: Modular approach to key management >From ipsec-request@ans.net Mon Nov 14 05:19:13 1994 > I'd like to know _exactly_ what the patent status is of each of the >proposals on the table. Let me make the SKIP patent status known as well. There aren't any patents that exist today, but there will be soon to issue patents. Because these patents dont exist today, there aren't any numbers I can give you. I will be the inventor, and Sun Microsystems will be the assignee. Let me be clear about the patent license issue. Sun will use the SKIP patents in a defensive manner, only. Sun will license on a royalty-free basis the SKIP patents to all comers. There will be a ONE-TIME fee of $99, which is required for legal reasons, not financial. This is because the only purpose of the license is defensive (Sun disclaims all liability) and the reason for the fee is that contract law stipulates that something of value has to exchange for a contract to bind. A nominal one-time fee of $99 is something that was considered adequate for this purpose. This is for commercial use of the patent. For non-commercial use, (individual, internal business, experimental etc.) there is no license and no fee. Until there are actual US patent numbers, Sun will use its internal file numbers to license the patents. For more information/questions, send mail to "SKIP_administrator@eunuchs.Sun.COM". I expect that that the license forms will be available for IESG/ISOC consideration soon, and definitely before the San Jose IETF meeting. Naturally, we cant guarantee anything about non-Sun patents (if there are any) being implicated in our proposal. We have already taken steps to inform the IESG and WG chairs of this. We are also working on arranging a BOF on Intellectual Property (IP) issues as they relate to IETF standardization at the next IETF meeting. We are doing this because we need a more appropriate forum for discussing suitability of patents/licenses than mailing lists like the ipsec, which are more appropriate for technical discussions. Indeed, Jeff Schiller has advised against debating suitability of patent licenses etc. at the WG meeting. For the same reason, we didn't mention this on this list, until an appropriate mailing list was constructed, probably out of the BOF activity at the upcoming IETF. That way we could have directed follow-up questions to that list, after we made the announcement on ipsec. However, since you have raised this issue, I decided not to wait until the next IETF meeting. We believe that defensive patents are a good thing from an IETF standardization point of view, because they are a good defense against future patent claims. We would be happy to explain this and other issues at the BOF on IP issues at the San Jose meeting, where we have invited our patent attorneys to attend. Based on what we have told them, Security AD Jeff Schiller and the WG chairs dont have any objections to discussing SKIP for IETF standardization purposes, from a patent/licensing point of view. Other than this, it is important to note that the PKP DH patent (the most important part of SKIP) expires sometime in 1997. Regards, Ashar. From ipsec-request@ans.net Tue Nov 15 13:00:54 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20661 (5.65c/IDA-1.4.4 for ); Tue, 15 Nov 1994 08:21:16 -0500 Received: by interlock.ans.net id AA08133 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 15 Nov 1994 08:01:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 15 Nov 1994 08:01:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 15 Nov 1994 08:01:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 15 Nov 1994 08:01:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 15 Nov 1994 08:01:25 -0500 Message-Id: <9411151300.AA02216@snark.imsi.com> To: Ashar.Aziz@eng.sun.com (Ashar Aziz) Cc: ipsec@ans.net Subject: Re: Modular approach to key management In-Reply-To: Your message of "Mon, 14 Nov 1994 12:21:34 PST." <9411142021.AA15218@miraj.Eng.Sun.COM> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 15 Nov 1994 08:00:54 -0500 From: "Perry E. Metzger" Ashar Aziz says: > Sun will license on a royalty-free basis the SKIP patents to all > comers. There will be a ONE-TIME fee of $99, which is required > for legal reasons, not financial. This is because the only > purpose of the license is defensive (Sun disclaims all liability) > and the reason for the fee is that contract law stipulates that > something of value has to exchange for a contract to bind. Nominal fees of this sort are usually set at $1, not $99. I have never in all my years heard of a token consideration being set at $99. However, I refuse to pay even $1. If Sun truly wants to give up making money on the patent it can do what Bell Labs did with the patent on the SUID bit -- assign it to the public domain so that anyone can use it. If Sun truly wishes not to make money on this patent this is the traditional course of action. Anything else makes me suspicious. In any case, I, for one, will not support ANY barriers to the use of IETF standard protocols. That means that it makes no difference what the fee is -- the problem is that paperwork has to be filed, which means that public implementations cannot be freely distributed and then commercially used. As I said, if sun truly has no financial interest in this, it can just give up rights to the patent, period. Perry From ipsec-request@ans.net Tue Nov 15 05:04:34 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA34799 (5.65c/IDA-1.4.4 for ); Tue, 15 Nov 1994 10:35:54 -0500 Received: by interlock.ans.net id AA15198 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 15 Nov 1994 10:03:17 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 15 Nov 1994 10:03:17 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 15 Nov 1994 10:03:17 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 15 Nov 1994 10:03:17 -0500 Date: Tue, 15 Nov 94 10:04:34 EST From: tdn@tdn.xyplex.com (Thomas D. Nadeau) Message-Id: <9411151504.AA00277@eng.xyplex.com> To: ipsec@ans.net In-Reply-To: <9411151300.AA02216@snark.imsi.com> (perry@imsi.com) Subject: Re: Modular approach to key management Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: tdnadeau@xap.xyplex.com "perry" == Perry E. Metzger writes: > Ashar Aziz writes: > Sun will license on a royalty-free basis the SKIP patents to all > comers. There will be a ONE-TIME fee of $99, which is required for > legal reasons, not financial. This is because the only purpose of > the license is defensive (Sun disclaims all liability) and the > reason for the fee is that contract law stipulates that > something of value has to exchange for a contract to bind. How can SKIP be distributed freely if one must apply for patent rights? This will IMHO, contrain its wide-spread use to those who can affort the fee. We should put the pressure on SUN to stop this foolishness, so that *everyone* adopts and implements SKIP. --tOm -- /---------------------------------------------------------------------/ \ \ / Thomas D. Nadeau ======== ======== / \ Internetworking Software ======= ========= \ / Xyplex, Inc. ======= ====== / \ 295 Foster Street, ======== == \ / Littleton, MA 01460 -------======= ------- / \ ======== == \ / Voice: (508) 952-4837 ======= ====== / \ FAX: (508) 952-4887 ======= ========= \ / email: tdnadeau@eng.xyplex.com ======== ========== / \ \ /---------------------------------------------------------------------/ From ipsec-request@ans.net Tue Nov 15 16:15:15 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA34814 (5.65c/IDA-1.4.4 for ); Tue, 15 Nov 1994 11:37:26 -0500 Received: by interlock.ans.net id AA24589 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 15 Nov 1994 11:15:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 15 Nov 1994 11:15:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 15 Nov 1994 11:15:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 15 Nov 1994 11:15:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 15 Nov 1994 11:15:43 -0500 Message-Id: <9411151615.AA02491@snark.imsi.com> To: tdnadeau@xap.xyplex.com Cc: ipsec@ans.net Subject: Re: Modular approach to key management In-Reply-To: Your message of "Tue, 15 Nov 1994 10:04:34 EST." <9411151504.AA00277@eng.xyplex.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 15 Nov 1994 11:15:15 -0500 From: "Perry E. Metzger" Thomas D. Nadeau says: > > How can SKIP be distributed freely if one must apply for > patent rights? This will IMHO, contrain its wide-spread use to those > who can affort the fee. We should put the pressure on SUN to stop this > foolishness, so that *everyone* adopts and implements SKIP. > SKIP isn't so clearly important to me that I'd necessarily want to make such an effort. However, if people working at Sun want us to consider it they are going to have to do better than a "token" $99. Putting the patent in the public domain would be better. (BTW, I'll point out that $99 is not so token at all -- Bill Gates made billions charging less for DOS. However, cost isn't the issue -- encumberances are.) .pm From ipsec-request@ans.net Tue Nov 15 17:33:27 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06518 (5.65c/IDA-1.4.4 for ); Tue, 15 Nov 1994 12:45:33 -0500 Received: by interlock.ans.net id AA12954 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 15 Nov 1994 12:29:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 15 Nov 1994 12:29:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 15 Nov 1994 12:29:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 15 Nov 1994 12:29:00 -0500 From: hughes@hughes.network.com (James P. Hughes) Message-Id: <9411151133.ZM10219@hughes.network.com> Date: Tue, 15 Nov 1994 11:33:27 -0600 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: ipsec@ans.net Subject: Key Management Proposal Cc: ted.doty@nsco.network.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Network Systems would like the opportunity to present a proposal for key management at the next IETF. NSC has implemented a 2 message interactive authentication, key management, algorithm negotiation protocol. The device uses RSA for authentication, D-H for key exchange, a number of symmetric ciphers, MD5 for data integrity and also provides data compression. Public keys are distributed (at this time) via sneakernet, but in the future, it would be desirable to implement secure DNS to reliably get the public keys. At this time, NSC intends to offer this protocol and message formats to the IPSEC working group for their consideration. NSC does have the rights to use IDEA, RSA and D-H in this product, but NSC does not have any rights to offer these patents to the IETF at large. NSC would like to offer this protocol and to discuss the relative merits of this as an actual implementation. Regardless of what is adopted, NSC intends to follow the recommendations and implement the results of the IPSEC working group. If the group is interested, a set of working prototypes could be brought to the next IETF. The press release can be obtained via Mosaic from: http://www.network.com/external/news_releases/security.shtml jim From ipsec-request@ans.net Tue Nov 15 21:43:18 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17994 (5.65c/IDA-1.4.4 for ); Tue, 15 Nov 1994 16:50:10 -0500 Received: by interlock.ans.net id AA36607 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 15 Nov 1994 16:43:24 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Tue, 15 Nov 1994 16:43:24 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 15 Nov 1994 16:43:24 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 15 Nov 1994 16:43:24 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 15 Nov 1994 16:43:24 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 15 Nov 1994 16:43:24 -0500 Message-Id: <9411152143.AA15977@gimili.watson.ibm.com> To: "Sara Bitan" , ipsec@ans.net Cc: charlie_kaufman@iris.com Subject: Re: SKIP and interactive key management In-Reply-To: Your message of "Mon, 14 Nov 1994 16:48:44 +0200." <199411141649238540.sarab@radmail.rad.co.il> X-Mailer: exmh version 1.2 1/14/94 Date: Tue, 15 Nov 1994 16:43:18 -0500 From: " " Hi Sara! We have considered several ways of combining SKIP and the modular key management proposal. What you suggest is to take the non-interactive part from SKIP, but to use a general master key which is refreshed in some yet-to-be-specified way. Namely, to adopt the `encrypt packet key in the packet' idea, but not the specific DH key distribution choice of Master key. I think this makes lots of sense; if somebody wants DH key distribution, they would be welcome to use it to get the original master key, and then use our scheme to refresh it. So, the idea essentially boils down to allowing also this non-interactive option in our protocol, to be used if there are no short lived keys. Let me admit that our experiments suggest that in most common networking scenarios, the overhead would not be justified, and it'll be better to use the interactive method. But then, I agree that there may be scenarios where the interaction would be expensive or impossible. I hate to raise the patent issue again but this is a small concern I do have: I'll welcome inputs from the list on this. Namely, should we have this if it would require license fees? Maybe as an option it is Ok? I've asked Aziz about it off-list, i.e. what exactly is the aspect they applied for patent for. But, I think DEC has a patent which may cover this technique as well. I'm cc:ing Charlie Kaufman on this note so he can tell us more details. Best, Amir Herzberg From ipsec-request@ans.net Tue Nov 15 22:04:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05467 (5.65c/IDA-1.4.4 for ); Tue, 15 Nov 1994 18:19:16 -0500 Received: by interlock.ans.net id AA22318 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 15 Nov 1994 18:11:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Tue, 15 Nov 1994 18:11:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 15 Nov 1994 18:11:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 15 Nov 1994 18:11:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 15 Nov 1994 18:11:42 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 15 Nov 1994 18:11:42 -0500 Date: 15 Nov 94 16:04:00 -0600 To: ipsec@ans.net Subject: IPSEC at Dec IETF Message-Id: IPSEC Working Group Members, IPSEC working group sessions are scheduled for the 31st Internet Engineering Task Force meeting (December in San Jose). Working group sessions will be held on the IP Security Protocol (IPSP) and on the Internet Key Management Protocol (IKMP - key management for IPSP). The exact days a still being arranged and will be posted very soon. Presentations are currently scheduled to discuss the proposals for IPSP (a new I-D will be out next week). Several presentations and demonstrations of experimental implementations of IKMP are scheduled. The focus of the IKMP discussions will be on comparing the proposals and creating a consensus approach. Additional contributions to the meeting are always welcome. If you have technical progress to report relevant to network layer cryptographic security and/or key management and are interested in giving a presentation on that work, please contact Jim Zmuda (zmuda@spyrus.com 714-458-0781) or me. Regards, Paul A. Lambert Motorola, Inc. M/S AZ49-R1209 Internet: Paul_Lambert@email.mot.com 8220 E. Roosevelt Rd. Phone: +1-602-441-3646 Scottsdale, Az. Fax: +1-602-441-8864 85257 USA From ipsec-request@ans.net Tue Nov 15 03:14:34 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18020 (5.65c/IDA-1.4.4 for ); Tue, 15 Nov 1994 20:18:51 -0500 Received: by interlock.ans.net id AA34513 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 15 Nov 1994 20:15:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 15 Nov 1994 20:15:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 15 Nov 1994 20:15:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 15 Nov 1994 20:15:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 15 Nov 1994 20:15:44 -0500 Date: Tue, 15 Nov 94 11:14:34 PST From: Ashar.Aziz@eng.sun.com (Ashar Aziz) Message-Id: <9411151914.AA15745@miraj.Eng.Sun.COM> To: tdnadeau@xap.xyplex.com, perry@imsi.com Subject: Re: Modular approach to key management Cc: ipsec@ans.net >From ipsec-request@ans.net Tue Nov 15 10:50:48 1994 >(BTW, I'll point out that $99 is not so token at all -- Bill Gates >made billions charging less for DOS. However, cost isn't the issue -- >encumberances are.) Clearly there is a difference between a one-time fee and a per-copy fee, which is how DOS is sold. This nit aside, I respect your views, and will present them to management/legal here. They are coming (all of them) to the BOF that I mentioned, and so everyone can present their concerns/issues at the BOF. I will do whatever I can to minimize the WG concerns regarding patents/licenses/encumberances, and will promote the solution inside Sun that the WG is most comfortable with. Having said this, I really would prefer to have this discussion at the BOF and not here. Ashar. From ipsec-request@ans.net Thu Nov 17 13:23:32 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05581 (5.65c/IDA-1.4.4 for ); Thu, 17 Nov 1994 08:28:29 -0500 Received: by interlock.ans.net id AA06490 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 17 Nov 1994 08:23:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Thu, 17 Nov 1994 08:23:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 17 Nov 1994 08:23:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 17 Nov 1994 08:23:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 17 Nov 1994 08:23:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 17 Nov 1994 08:23:37 -0500 Message-Id: <9411171323.AA26636@gimili.watson.ibm.com> To: ipsec@ans.net Subject: Defensive patents X-Mailer: exmh version 1.2 1/14/94 Date: Thu, 17 Nov 1994 08:23:32 -0500 From: " " One more note on patents until Ashar gets us the right forum to discuss it... Ashar, I understood that your (Sun) motivation is to defend against other patents. I'm not sure why this requires any fees in addition to a patent (even our lawyers were not concerned about this, and believe me, they are very careful people and were concerned about many other things...). But, I"m not even sure this requires a patent at all; legally a publication should be enough (which you already did). Maybe you are afraid the patent office would not be aware of the publication (which is a reasonable cocern - one of the problem with the patent process is that these poor people are supposed to read our conferences - even most of us don't... :-). So, you may be interested to know that Allan Schiffman thinks there is a non-patent way to do this (see below)... And believe me, filing for a patent very painful process which you want to avoid if you can (and it cost money so Sun should agree)... Best, Amir p.s. Let me recommend again to everybody interested in the higher layers of the key management to give a look also to SHTTP. It has many good points. The new version should come out Real Soon Now (says Allan). > Date: Tue, 15 Nov 94 23:11:49 PST > From: ams@eit.com (Allan M Schiffman) > Message-Id: <9411160711.AA22171@eitech.eit.com> > To: cmcmanis@scndprsn.Eng.Sun.COM > Subject: Re: Secure HTTP mailing list > Cc: treese@openmarket.com, www-security@ns1.rutgers.edu > > > Since public key > > technology appears at this stage to be essential to any useful secure > > protocol, RSADSI, PKP, and EIT have the rest of the net by their > > cyber short hairs. > RSADSI/PKP, maybe, but EIT disclaims intent to patent any of the > techniques embodied in the protocol. In fact, we understand that the > Patent Office has a "public disclosure" mechanism for non-patented work > to be incorporated into their prior-art database, and if we can just > figure out how to use it, we'll file such disclosures to prevent others > from obstructing S-HTTP implementations via patent. > > -Allan > ------- End of Forwarded Message From ipsec-request@ans.net Thu Nov 17 21:40:39 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA31821 (5.65c/IDA-1.4.4 for ); Thu, 17 Nov 1994 17:24:43 -0500 Received: by interlock.ans.net id (InterLock SMTP Gateway 1.1 for archive-ipsec@nis.ans.net); Thu, 17 Nov 1994 17:18:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 17 Nov 1994 17:18:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 17 Nov 1994 17:18:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-0); Thu, 17 Nov 1994 17:18:39 -0500 Date: Thu, 17 Nov 94 21:40:39 GMT From: "William Allen Simpson" Message-Id: <3472.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Free Patents > From: "Perry E. Metzger" > Ashar Aziz says: > > Sun will license on a royalty-free basis the SKIP patents to all > > comers. There will be a ONE-TIME fee of $99, which is required > > for legal reasons, not financial. This is because the only > > purpose of the license is defensive (Sun disclaims all liability) > > and the reason for the fee is that contract law stipulates that > > something of value has to exchange for a contract to bind. > That's called "consideration". > Nominal fees of this sort are usually set at $1, not $99. I have never > in all my years heard of a token consideration being set at > $99. However, I refuse to pay even $1. > I'm with Perry on this one. I won't support any fee or even a license! > In any case, I, for one, will not support ANY barriers to the use of > IETF standard protocols. That means that it makes no difference what > the fee is -- the problem is that paperwork has to be filed, which > means that public implementations cannot be freely distributed and > then commercially used. > We went round and round with this in the PPP WG for compression patents. Finally, Stac agreed to let us use theirs for PPP links with no fee. They even provided C source. The "consideration" was the listing of Stac in printed documentation, same as Berkeley. Seemed easy enough. The benefit to them is that they are in the chip business, so all those free implementations floating around should have given their business a boost. And free implementations wouldn't have had the resources to pay, so they get name recognition where they would have had none before. Well, we still needed to get signed copies of these "free" licenses. It turns out to be quite a hassle! Multiple copies wending their way back and forth, contract language problems, lawyers, etc. I'm a co-author of the Stac internet-draft, and *I* still don't have a license! Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Fri Nov 18 15:33:42 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA25586 (5.65c/IDA-1.4.4 for ); Fri, 18 Nov 1994 15:33:42 -0500 Received: by interlock.ans.net id AA22701 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 18 Nov 1994 15:23:55 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 18 Nov 1994 15:23:55 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 18 Nov 1994 15:23:55 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 18 Nov 1994 15:23:55 -0500 Date: Fri, 18 Nov 94 12:05:15 From: "Housley, Russ" Encoding: 1660 Text Message-Id: <9410187851.AA785189115@spysouth.spyrus.com> To: ipsec@ans.net, Paul_Lambert-P15452@email.mot.com Subject: Re: IPSEC at Dec IETF Paul: I plan to be in San Jose on Monday Afernoon, Tuesday, and Wednesday. I am flying out on Monday morning, and I have a meeting on Thursday. I hope the schedule can accompdate these restrictions. Russ ______________________________ Reply Separator _________________________________ Subject: IPSEC at Dec IETF Author: Paul_Lambert-P15452@email.mot.com at internet Date: 11/15/94 16:04 IPSEC Working Group Members, IPSEC working group sessions are scheduled for the 31st Internet Engineering Task Force meeting (December in San Jose). Working group sessions will be held on the IP Security Protocol (IPSP) and on the Internet Key Management Protocol (IKMP - key management for IPSP). The exact days a still being arranged and will be posted very soon. Presentations are currently scheduled to discuss the proposals for IPSP (a new I-D will be out next week). Several presentations and demonstrations of experimental implementations of IKMP are scheduled. The focus of the IKMP discussions will be on comparing the proposals and creating a consensus approach. Additional contributions to the meeting are always welcome. If you have technical progress to report relevant to network layer cryptographic security and/or key management and are interested in giving a presentation on that work, please contact Jim Zmuda (zmuda@spyrus.com 714-458-0781) or me. Regards, Paul A. Lambert Motorola, Inc. M/S AZ49-R1209 Internet: Paul_Lambert@email.mot.com 8220 E. Roosevelt Rd. Phone: +1-602-441-3646 Scottsdale, Az. Fax: +1-602-441-8864 85257 USA From ipsec-request@ans.net Mon Nov 21 16:48:55 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA25414 (5.65c/IDA-1.4.4 for ); Mon, 21 Nov 1994 16:48:55 -0500 Received: by interlock.ans.net id AA20525 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 21 Nov 1994 16:47:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 21 Nov 1994 16:47:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 21 Nov 1994 16:47:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 21 Nov 1994 16:47:11 -0500 Date: Mon, 21 Nov 94 13:28:50 From: "Housley, Russ" Encoding: 2368 Text Message-Id: <9410217854.AA785453330@spysouth.spyrus.com> To: ipsec@ans.net, atkinson@itd.nrl.navy.mil Subject: Re[2]: Modular approach to key management Ran: IEEE 802.10 has a letter on file from PKP that states that their patents will be made available on a fair, equitable, nondiscriminatory, and non-onerous basis. Based on this letter, work on IEEE 802 is proceeding. Under the IEEE rules, the working group is responsible for getting such a letter, but the determination concerning whether or not the term are actually fair, equitable, nondiscriminatory, and non-onerous is not left to the working group. This decision is made my lawyers at IEEE if anyone raises an issue during the ballot process. Crypto systems based on elliptic curves are likely to be standardized by the IEEE P1363 group. They claim that no patents are infringed by these algorithms. Russ ______________________________ Reply Separator _________________________________ Subject: Re: Modular approach to key management Author: atkinson@itd.nrl.navy.mil Date: 11/14/94 09:29 Hugh, Russ, Hugo, Ashar, and others, I'd like to know _exactly_ what the patent status is of each of the proposals on the table. By this I mean that I'd like to see the following become crystal clear: 1) Is any aspect of the proposal patented (including patents pending) ? 1b) If so, which parts are patented by which patent numbers and who are the inventors and assignees ? 2) If some prior agreement has been reached that the patent will be made available to all comers at no cost (e.g. as part of IEEE 802 work), that would be worth knowing about. Otherwise, under what terms are the patents available ? We have had strongly negative history within the past year in the Mobile IP working group where people knew they had patents but did not disclose those patents up front. The IETF way is to disclose the existence of patents IMMEDIATELY and to the ENTIRE working group, not just the chairpeople. I'd really like to avoid hidden patent issues in this work. Even if (2) isn't immediately answerable, it is very important to openly disclose (1) and (1b) immediately and to the entire list. I think most folks are aware of the Diffie-Hellman and RSA patents. I believe the use of the RSA-Ref software package legally excludes individuals (but not vendors) from having to pay monetary license fees on those 2 patents. Regards, Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Mon Nov 21 16:48:55 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24645 (5.65c/IDA-1.4.4 for ); Mon, 21 Nov 1994 16:48:55 -0500 Received: by interlock.ans.net id AA09239 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 21 Nov 1994 16:45:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 21 Nov 1994 16:45:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 21 Nov 1994 16:45:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 21 Nov 1994 16:45:54 -0500 Date: Mon, 21 Nov 94 13:28:41 From: "Housley, Russ" Encoding: 1515 Text Message-Id: <9410217854.AA785453321@spysouth.spyrus.com> To: hugo@watson.ibm.com, Ashar.Aziz@eng.sun.com (Ashar Aziz) Cc: ipsec@ans.net Subject: Re[2]: On SKIP and non-interactive key management Ashar: >>* The transmission of algorithm identifiers and possibly other security >>attributes with each packet adds to the overhead even if these values are >>most of the time fixed for a pair of nodes. > >Of course, this kind of argument can be made against an IP header >as well. One can end up arguing in favor of a connection oriented >network protocol like X.25 instead of IP, with this line of >argument. (And precisely some of these arguments were made >by X.25 proponents). The SAID should be used to indirectly tell which algorithms and modes are being used. In a sence, the agreement of a key between two parties is the establishment of a connection, only we call it a security association. >>* The attractive notion of unstructured SAIDs that are decided by the local >>implementation and transmitted to the other party is lost here. Only >>structured, standardized SAIDs make sense. > >What is attractive about unstructured SAIDs? I realize the need >for IPSP to allow all kinds of key-management, and hence unstructured >SAIDs, but fail to see anything terribly attractive about unstructured >SAIDs. > >The only thing about SAIDs is that they are decided by a receiving >node, and if a receiving node chooses structured SAIDs, and >advertises that in advance, what is wrong with that? I thought that this group agreed on 32 bit SAIDs with the high order bit reserved for multicast security associations. When did the issue get reopened? Russ From ipsec-request@ans.net Mon Nov 21 16:48:59 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24669 (5.65c/IDA-1.4.4 for ); Mon, 21 Nov 1994 16:48:59 -0500 Received: by interlock.ans.net id AA19956 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 21 Nov 1994 16:44:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 21 Nov 1994 16:44:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 21 Nov 1994 16:44:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 21 Nov 1994 16:44:40 -0500 Date: Mon, 21 Nov 94 13:28:36 From: "Housley, Russ" Encoding: 3031 Text Message-Id: <9410217854.AA785453316@spysouth.spyrus.com> To: amir@watson.ibm.com Cc: ipsec@ans.net Subject: Re: Modular approach to key management Amir: > I agree that it would be much better if we had automated negotiation > of methods i.e. a standard high-level key management alg. The questions are: > 1. Should we do a small common module already, without waiting to resolve > the higher layer problem? We believe the answer is YES. > 2. How do we solve the higher layer problem? I think there are too many > possibilities rather than too few... You seem to suggest a specific one: > > > In the IEEE 802.10c Key Management Protocol, all three forms of key > > management are supported: KDC, certificate-based, and manual. Each of > > these techniques can be used to establish a traffic encryption key, then a > > common attribute negotiation technique is used. I think that IPSEC can > > adopt all of this work with minimal adaptation to the Internet. By starting > > with IEEE 802.10c, the "upper module" is nearly complete. > > We (in particular Juan) tried to learn and re-use IEEE 802.10c as much as we > could. (Juan, you may want to elaborate.) Maybe you (and others) can help the > WG to use more of it - that would be great. I think that we agree more than we disagree. IEEE 802.10c defines a protocol that can be used with certificate-based key management, KDC-based key management, and manual key management. Since the protocol is so flexible, the IPSEC WG would be faced with choosing one (or more) technique that would be standardized for the Internet community of users. For example, Kerberos might be the basis for a KDC-based key management technique for the Internet. Likewise, the PEM certificate infrastructure might be the basis for a certificate-based key management technique for the Internet. Another certificate-based alternative might be based on the draft X9.42 variant of Diffie-Hellman. My suggestion is that we adopt the IEEE work, then select particular algorithms for use in the Internet. Of course, the IPSEC WG would also have to define the attributes that are part of security association negotiation. These attributes have to be defined regardless of the approach taken, so this is neither a plus nor a minus to the IEEE 802.10c approach. NASA has agreed to make some space available on a machine that supports anonymous FTP. We hope to have the latest draft of IEEE 802.10c available before the IETF meeting. I will gladly spend time with anyone at the IETF to expalin the direction that we are going. Good ideas are welcome from any source. > ... Even if used with manual key management by some pairs of partners, it > would still help to 'stop the bleeding' - and this is what we were told to > do by the IESG. In my opinion, IEEE 802.10c decreases the time to market. Protocol development can take alot of time, especially in an open environment like the IEEE and the IETF. Therefore, take advantage of the investement that has already been made by the IEEE 802.10 participants, and take a working solution to the Internet sooner. Russ From ipsec-request@ans.net Tue Nov 22 17:14:23 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17286 (5.65c/IDA-1.4.4 for ); Tue, 22 Nov 1994 12:28:45 -0500 Received: by interlock.ans.net id AA21722 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 22 Nov 1994 12:14:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Tue, 22 Nov 1994 12:14:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 22 Nov 1994 12:14:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 22 Nov 1994 12:14:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 22 Nov 1994 12:14:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 22 Nov 1994 12:14:29 -0500 Message-Id: <9411221714.AA49127@gimili.watson.ibm.com> To: "Housley, Russ" Cc: amir@watson.ibm.com, ipsec@ans.net Subject: Re: Modular approach to key management In-Reply-To: Your message of "Mon, 21 Nov 1994 13:28:36." <9410217854.AA785453316@spysouth.spyrus.com> X-Mailer: exmh version 1.2 1/14/94 Date: Tue, 22 Nov 1994 12:14:23 -0500 From: " " Hi Russ and all, > > Amir: > > > I agree that it would be much better if we had automated negotiation > > of methods i.e. a standard high-level key management alg. The questions are: > > 1. Should we do a small common module already, without waiting to resolve > > the higher layer problem? We believe the answer is YES. > > 2. How do we solve the higher layer problem? I think there are too many > > possibilities rather than too few... You seem to suggest a specific one: > > > > > In the IEEE 802.10c Key Management Protocol, all three forms of key > > > management are supported: KDC, certificate-based, and manual. ..... (omitted text) starting > > > with IEEE 802.10c, the "upper module" is nearly complete. > > > > We (in particular Juan) tried to learn and re-use IEEE 802.10c as much as we > > could. (Juan, you may want to elaborate.) Maybe you (and others) can help the > > WG to use more of it - that would be great. > > I think that we agree more than we disagree. I also think so. My questions to you are: 1. Do you agree with the `modular approach' to the problem? Namely, do you see the need and value of having a lower layer mechanism which refreshes the keys in an efficient and fault-tolerant manner on top of IP, whose input is a shared long-lived key from some higher layer mechanism? This is one critical design issue we need to get resolved. 2. Would you like to help us by contributing text on the higher-layer key management based on 802.10c to be merged into our proposal? We are working on a draft to be released Real Soon Now and would welcome help and cooperation toward reaching rough consensus. > IEEE 802.10c defines a protocol > that can be used with certificate-based key management, KDC-based key > management, and manual key management. Since the protocol is so flexible, the > IPSEC WG would be faced with choosing one (or more) technique that would be > standardized for the Internet community of users. For example, Kerberos might > be the basis for a KDC-based key management technique for the Internet. > Likewise, the PEM certificate infrastructure might be the basis for a > certificate-based key management technique for the Internet. Another > certificate-based alternative might be based on the draft X9.42 variant of > Diffie-Hellman. If I understand you correctly, you propose that for the higher layers, we'll try to use the base 802.10c protocol while selecting the proper components. Sounds reasonable to me, and again I'll welcome a concrete proposal (which we may merge into our modular proposal). Of course we need to keep a reasonable balance between generality and interoperability, but I see you are aware of this. Great, let's get moving! > > My suggestion is that we adopt the IEEE work, then select particular algorithms > for use in the Internet. Of course, the IPSEC WG would also have to define the > attributes that are part of security association negotiation. These attributes > have to be defined regardless of the approach taken, so this is neither a plus > nor a minus to the IEEE 802.10c approach. Agreed. > > NASA has agreed to make some space available on a machine that supports > anonymous FTP. We hope to have the latest draft of IEEE 802.10c available > before the IETF meeting. I will gladly spend time with anyone at the IETF to > expalin the direction that we are going. Good ideas are welcome from any > source. I hope we can discuss this at the IETF, both during the sessions and off line. If you'll like to coordinate such discussions in advance, send me e-mail off list. (This invitation is open to others too.) > > > > ... Even if used with manual key management by some pairs of partners, it > > would still help to 'stop the bleeding' - and this is what we were told to > > do by the IESG. > > In my opinion, IEEE 802.10c decreases the time to market. Protocol development > can take alot of time, especially in an open environment like the IEEE and > the IETF. Therefore, take advantage of the investement that has already > been made by the IEEE 802.10 participants, and take a working solution to > the Internet sooner. I agree with all your points. However, I still recommend we proceed first with a simple and efficient common solution to refreshing `short lived' keys, to provide a minimal level of interoperability and a much quicker solution, as well as deal with the efficiency and fault-tolerance issues which we need to add to existing higher-layer key management designs. Best, Amir Herzberg From ipsec-request@ans.net Tue Nov 22 23:12:29 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA33704 (5.65c/IDA-1.4.4 for ); Tue, 22 Nov 1994 23:12:29 -0500 Received: by interlock.ans.net id AA19935 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 22 Nov 1994 22:59:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 22 Nov 1994 22:59:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 22 Nov 1994 22:59:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 22 Nov 1994 22:59:19 -0500 Date: Tue, 22 Nov 94 19:46:33 From: "Housley, Russ" Encoding: 1168 Text Message-Id: <9410227855.AA785562393@spysouth.spyrus.com> Cc: amir@watson.ibm.com, ipsec@ans.net Subject: Re: Modular approach to key management Amir: > 1. Do you agree with the `modular approach' to the problem? Namely, do > you see the need and value of having a lower layer mechanism which > refreshes the keys in an efficient and fault-tolerant manner on top > of IP, whose input is a shared long-lived key from some higher layer > mechanism? This is one critical design issue we need to get resolved. Yes, modular is good. No, the "lower layer" does not have to be at the IP layer. X9.17 includes a three tier key management approach that meets the modular idea, but all of the key management is done at the application layer. I think that key management should be done in the application layer, not IP. > 2. Would you like to help us by contributing text on the higher-layer > key management based on 802.10c to be merged into our proposal? We are > working on a draft to be released Real Soon Now and would welcome help > and cooperation toward reaching rough consensus. I an very interested in confributing to this topic; however, I am under a very tight schedule between now and New Year's Day. I cannot commit to any writing assignment in that time period. Russ From ipsec-request@ans.net Wed Nov 23 12:37:54 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06650 (5.65c/IDA-1.4.4 for ); Wed, 23 Nov 1994 07:45:25 -0500 Received: by interlock.ans.net id AA16427 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 23 Nov 1994 07:37:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 23 Nov 1994 07:37:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 23 Nov 1994 07:37:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 23 Nov 1994 07:37:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 23 Nov 1994 07:37:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 23 Nov 1994 07:37:59 -0500 Message-Id: <9411231237.AA21014@gimili.watson.ibm.com> To: "Housley, Russ" Cc: amir@watson.ibm.com, ipsec@ans.net Subject: Re: Modular approach to key management In-Reply-To: Your message of "Tue, 22 Nov 1994 19:46:33." <9410227855.AA785562393@spysouth.spyrus.com> X-Mailer: exmh version 1.2 1/14/94 Date: Wed, 23 Nov 1994 07:37:54 -0500 From: " " Russ, I think we are going on a good path of identifying common ground vs. differences and trying to decide. Let's proceed; I hope others will join this discussion stating their own views. To begin, it appears that you agree with the need for a modular approach with a lower layer that refreshes short-lived keys from a long-lived (`master') shared key: > > Amir: > > > 1. Do you agree with the `modular approach' to the problem? Namely, do > > you see the need and value of having a lower layer mechanism which > > refreshes the keys in an efficient and fault-tolerant manner on top > > of IP, whose input is a shared long-lived key from some higher layer > > mechanism? This is one critical design issue we need to get resolved. > > Yes, modular is good. But then, we may differ on the requirements, design and function of this lower layer. > No, the "lower layer" does not have to be at the IP > layer. X9.17 includes a three tier key management approach that meets the > modular idea, but all of the key management is done at the application > layer. I think that key management should be done in the application > layer, not IP. > Let me clarify I also think the lower layer could be an application. However I suggest we use an application over UDP for two reasons: efficiency and minimizing the requirements (as we hope that the key management for IP would be implemented in routers etc.). Do you agree? What do you consider as the most detailed existing specification of this lower layer? As I've explained before, we've been looking into the standards you mentioned, and found only abstract descriptions to which we believe our proposal corresponds. Maybe there are newer versions. I'll appreciate if you can point us to them; we certainly would like to use whatever exists. Best, Amir From ipsec-request@ans.net Wed Nov 23 14:51:55 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16667 (5.65c/IDA-1.4.4 for ); Wed, 23 Nov 1994 10:06:16 -0500 Received: by interlock.ans.net id AA22225 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 23 Nov 1994 09:52:48 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 23 Nov 1994 09:52:48 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 23 Nov 1994 09:52:48 -0500 Message-Id: <9411231451.AA08631@columbia.sparta.com> To: " " Cc: "Housley, Russ" , ipsec@ans.net, hh@columbia.sparta.com Subject: Re: Modular approach to key management In-Reply-To: Your message of "Wed, 23 Nov 94 07:37:54 EST." <9411231237.AA21014@gimili.watson.ibm.com> Date: Wed, 23 Nov 94 09:51:55 -0500 From: Hugh Harney Hello Amir, I strongly disagree with the goal of implementing key management for IP in routers. This would make the routers, and anyone or thing with access to them, a potential vulnerability. I believe that keys should only exist at the actual enpoints where encryption takes place. This reduces the exposure of the keys to the minimum set and results in a more secure solution. If we intend to place key management at the routers and have a secure system, we place an burden of trust on the routers. The routers have to be trusted to enforce access control policy for the keys. This means that the routers need to be able to treat the key data as separate from other data it may contain. This line quickly leads one to a "requirement" for a trusted operating system at the routers. >> No, the "lower layer" does not have to be at the IP >> layer. X9.17 includes a three tier key management approach that meets the >> modular idea, but all of the key management is done at the application >> layer. I think that key management should be done in the application >> layer, not IP. > >Let me clarify I also think the lower layer could be an application. >However I suggest we use an application over UDP for two >reasons: efficiency and minimizing the requirements (as we hope that the >key management for IP would be implemented in routers etc.). >Do you agree? Best, Hugh From ipsec-request@ans.net Wed Nov 23 15:05:48 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16933 (5.65c/IDA-1.4.4 for ); Wed, 23 Nov 1994 10:17:15 -0500 Received: by interlock.ans.net id AA10671 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 23 Nov 1994 10:05:58 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 23 Nov 1994 10:05:58 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 23 Nov 1994 10:05:58 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 23 Nov 1994 10:05:58 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 23 Nov 1994 10:05:58 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 23 Nov 1994 10:05:58 -0500 Message-Id: <9411231505.AA41108@gimili.watson.ibm.com> To: Hugh Harney , ipsec@ans.net Subject: Re: basic question: should we allow firewall-like implementations? In-Reply-To: Hugh's message of "Wed, 23 Nov 1994 09:51:55 EST." <9411231451.AA08631@columbia.sparta.com> X-Mailer: exmh version 1.2 1/14/94 Date: Wed, 23 Nov 1994 10:05:48 -0500 From: " " Hello Russ, Hugh and all, I do not suggest that everybody should implement key management for IP, and IP layer security, in routers. However I believe this would be a practical solution for many scenarios, in conjunction with end to end solutions. Of course I understand and respect your viewpoint. However, the question is: should the standard exclude the implementation on small, router-like machines? I believe the reality is that we need a solution which could be implemented in a router (or gateway, filtering firewall,...), to protect an entire network in one access point. This is one of the benefits of doing an IP-layer solution in the first place, and has been frequently mentioned as a req' for IP-SEC. I think this is an important point that the WG should consider. Namely, I urge all of you IP-Sec-ers to voice your opinion on this and have a discussion on net and in the IETF. While I believed we have agreement on this, it appears that even such basic design decisions are not clear yet. Best, Amir From ipsec-request@ans.net Wed Nov 23 15:05:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23810 (5.65c/IDA-1.4.4 for ); Wed, 23 Nov 1994 11:15:53 -0500 Received: by interlock.ans.net id AA09611 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 23 Nov 1994 11:11:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 23 Nov 1994 11:11:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 23 Nov 1994 11:11:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 23 Nov 1994 11:11:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 23 Nov 1994 11:11:35 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 23 Nov 1994 11:11:35 -0500 Date: 23 Nov 94 09:05:00 -0600 To: amir@watson.ibm.com, ipsec@ans.net Subject: Re[2]: basic question: should we allow firewall-like impleme Message-Id: Hello Amir, The IPSEC charter supports host-to-host, subnet-to-subnet and host-to-subnet topologies. Subnet in this context can be considered a router-like implementation. As you point out router-like implementations are one of the main advantages of network layer security and represent a feature not an issue to discuss. Regards, Paul From ipsec-request@ans.net Wed Nov 23 15:18:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA33782 (5.65c/IDA-1.4.4 for ); Wed, 23 Nov 1994 11:25:42 -0500 Received: by interlock.ans.net id AA14364 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 23 Nov 1994 11:21:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 23 Nov 1994 11:21:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 23 Nov 1994 11:21:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 23 Nov 1994 11:21:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 23 Nov 1994 11:21:30 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 23 Nov 1994 11:21:30 -0500 Date: 23 Nov 94 09:18:00 -0600 To: hh@columbia.sparta.com, ipsec@ans.net Subject: Re[2]: Modular approach to key management Message-Id: Hugh, What about when router-like systems are the end-points? I disagree with your text, >I strongly disagree with the goal of implementing key management for IP in >routers. This would make the routers, and anyone or thing with access to them, >a potential vulnerability. I believe that keys should only exist at the actual >enpoints where encryption takes place. This reduces the exposure of the keys >to the minimum set and results in a more secure solution. ,but if you are referring to the IPv6 proposals for router-like security implementations that share a key with the actual end-systems, then you have raise a valid issue. Sharing keys with intermediate systems reduces the security of the system. The same functionality could be provided more securely by three pair-wise security associations (assuming only a single intermediate Firewall/router system). One security association would be end-to-end for each host system. The other two security associations would encapsulate the end-to-end ipsp and provide host-to- router-like and router-like-to-host security services. Paul From ipsec-request@ans.net Wed Nov 23 16:21:55 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA31696 (5.65c/IDA-1.4.4 for ); Wed, 23 Nov 1994 11:24:39 -0500 Received: by interlock.ans.net id AA28704 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 23 Nov 1994 11:21:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 23 Nov 1994 11:21:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 23 Nov 1994 11:21:32 -0500 Message-Id: <9411231621.AA08803@columbia.sparta.com> To: " " Cc: Hugh Harney , ipsec@ans.net, hh@columbia.sparta.com Subject: Re: basic question: should we allow firewall-like implementations? In-Reply-To: Your message of "Wed, 23 Nov 94 10:05:48 EST." <9411231505.AA41108@gimili.watson.ibm.com> Date: Wed, 23 Nov 94 11:21:55 -0500 From: Hugh Harney Hello Amir, >should the standard exclude the implementation on small, router-like >machines? I believe that key management needs to be performed where IP-security is performed. That location is an IP security end point. Yes, there is a real need for gateways and filtering firewalls. They provide a critical service in todays Internet environment. They are security end points. >I believe the reality is that we need a solution which could be implemented >in a router (or gateway, filtering firewall,...), to protect an entire network >in one access point. This is one of the benefits of doing an IP-layer solution >in the first place, and has been frequently mentioned as a req' for IP-SEC. I believe gateway encryption service is useful for some systems today. I don't believe it should be the goal architecture for the network. The goal should be to have the endsystems perform IP security. An encryption gateway based architecture burdens the routers with having to worry about how a message is delivered to a network. Today routers know about connectivity. Encryption gateways force routers to know about the topology of the network. Hugh From ipsec-request@ans.net Wed Nov 23 16:31:17 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23698 (5.65c/IDA-1.4.4 for ); Wed, 23 Nov 1994 11:38:52 -0500 Received: by interlock.ans.net id AA27847 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 23 Nov 1994 11:30:55 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 23 Nov 1994 11:30:55 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 23 Nov 1994 11:30:55 -0500 Message-Id: <9411231630.AA08867@columbia.sparta.com> To: Paul_Lambert-P15452@email.mot.com Cc: hh@columbia.sparta.com, ipsec@ans.net, hh@columbia.sparta.com Subject: Re: Re[2]: Modular approach to key management In-Reply-To: Your message of "23 Nov 94 09:18:00 CST." Date: Wed, 23 Nov 94 11:31:17 -0500 From: Hugh Harney Paul, You are correct. I was referring to the IPv6 proposals where routers share a key with the actual end system. I believe I clarified myself in my last posting. In my mind, gateways and routers, that perform IP security, are the security end systems. Hugh From ipsec-request@ans.net Thu Nov 24 12:23:45 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17262 (5.65c/IDA-1.4.4 for ); Thu, 24 Nov 1994 09:32:33 -0500 Received: by interlock.ans.net id AA19569 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 24 Nov 1994 09:15:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 24 Nov 1994 09:15:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 24 Nov 1994 09:15:11 -0500 X-Nupop-Charset: English Date: Thu, 24 Nov 1994 14:23:45 +0200 (EET) From: "Sara Bitan" Sender: sarab@radmail.rad.co.il Message-Id: <199411241424206206.sarab@radmail.rad.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipsec@ans.net, sarab@radmail.rad.co.il, charlie_kaufman@iris.com Subject: SKIP and key management lower module alternatives Hello All, Assuming the approach to key management can be a modular one, I would like, if possible, to have the opinions of people from the list, as to the nature of the lower level module. As I see it, there are two possible approachs, 1) Encrypted key as key ID: This is the method adopted by SKIP. In this approach an encrypted packet key is carried in the packet. 2) Short key ID: The short key ID is part of the SAID, that appears in the IPSP header. The key ID can serve as an index to a key table. The SKIP approach is connection less. In this sense it is very IP-oriented. Key refreshment doesn't require handshake. An additional advantage it has, is that it is indeed very simple. Only the encryption keys used to encrypt the packet key has to be managed, and there is no exchange of key IDs. As I see it, SKIP has three main disadvantages: 1) Security weaknesses : there are several issues raised in an e-mail sent by Hugo (8-Nov-94). In SKIP a shared master key, under which the packet key is encrypted is established once, and never changed. Most of the issues raised by Hugo can be avoided, if SKIP is extended by adding a higher level interactive protocol for master key refreshment. 2) Space overhead : each packet size is enlarged by at least 8 bytes. 3) DEC patent: As mentioned in a e-mail Amir sent (15-Nov-94) Digital holds a patent on using an encrypted key as a key identifier, see Charli Kaufman's attached mail as to a relevant patent. In the short key ID approach, the SAID contains a key ID, which serves as an index to a key table. This approach doesn't have the above disadvantages, but on the other hand, it doesn't have the simplicity and the elegance of the first approach. I'll appreciate getting opinions, as to which approach is more suitable for the IPSEC purposes, Thanks, Sara Bitan RadGuard LTD. Israel 972-3-6459592 ----- Begin Included Message ----- >From ipsec-request@ans.net Mon Aug 8 21:57:48 1994 To: ipsec@ans.net Cc: atkinson@itd.nrl.navy.mil, amir@watson.ibm.com, kaufman@zk3.dec.com Subject: Encrypted Key Patent Date: Mon, 08 Aug 94 17:57:48 -0400 From: kaufman@zk3.dec.com X-Mts: smtp Content-Length: 4601 There has been some confusion around a patent Digital holds on using an encrypted key as a key identifier. As one of the guilty parties having filed the patent, I'd like to try to clear it up. Reference: Patent #5,081,678 filed 6/28/89 issued 1/14/92: "Method for Utilizing an Encrypted Key as a Key Identifier in a Data Packet in a Computer Network". Q: What is patented: A: The technique of encrypting a session key under a per-node private master key and putting that encrypted key in the packet header. Q: Why would anyone want to do that??: A: As Phil Karn pointed out, this consumes network bandwidth by having a large (8 bytes) key identifier when a small one (1-2 bytes) would do with no obvious savings. We needed to do it because of a particular type of cryptographic hardware we built. We wanted the hardware to be able to decrypt packets as they arrive off the net before they enter the node's memory. The conventional way to do this is to have a key table in the hardware looks up keys based on a key-id (or connection id) in the packet header. Because we didn't want to have enough memory in the hardware to store keys for the largest possible number of connections, we came up with putting the encrypted key in the packet header. An anomoly of hardware solutions is that sometimes they can decrypt faster than they can do table lookups. Q: And we wanted the IETF to standardize that kludge!? A: No. We wanted the IETF standard to permit it. Almost any protocol is going to have some sort of key identifier in the packet header. We needed two things: 1) For the key identifier to be allowed to be large enough to hold an encrypted key. That's 8 bytes for DES and more for better algorithms. 2) For the key establishment algorithm to permit the destination to specify the key id to use rather than having one somehow selected algorithmically. This is useful in other contexts as well; a conventional implementation, for example, is likely to want the key identifier to be a small integer used to index into a table. For best use of memory, it would like that integer to be chosen from a dense space. Q: So is this on the standards track now? A: Sort of. We had proposed a variable length "SAID" that could hold the big key identifier. It was pointed out that this data need not be in the SAID, but rather could be in the algorithm-specific header. Since we aren't yet debating algorithm specific formats, the debate has effectively been postponed. Since this has to be settled before we can actually build things that interoperate, I hope it will come up again soon. >From: Ran Atkinson > >> Note- DEC has patented this clever technique. > >I'd like to put out a request and reminder since there are many on this >list who are somewhat new to the IETF way of doing things. > >1) The IETF normally tries to avoid using patented techniques in IETF >specifications, though it is not always possible (sigh). > >2) In any event, it is ALWAYS important to note ALL possible >intellectual property claims relating to any proposal in the FIRST >note or presentation of the proposal. It is not good practice to >propose a technology which is subject to intellectual property claims >(e.g. patents) without that up front disclosure. > As noted above, it is not necessary or even useful for the standard to prescribe use of the patented technique, so I don't think that is an issue. I was up-front about mentioned the existence of the patent when I proposed the formats. At issue is to what degree should the IETF go out of its way to accomodate a technique that is not freely available. Clearly, the answer is not very far. I don't think it needs to, but reasonable people will differ on how far is too far (and unreasonable people will flame). > >However clever one might consider the DEC technique, I don't want to >include it in any portion of the standards-track specification UNLESS >DEC formally agrees in writing to license it to all comers at no cost. > I'm sure Digital's policy is the same as that vague one quoted from IBM about reasonable, non-discriminatory, etc. etc. There was a time when we might have been willing to sign up for free licenses to grease the path through standards. Today, this effort has a much lower priority and I wouldn't know how to motivate someone with the authority to do this to spend the time to think about it. I continue to advocate this approach because I think it is sound engineering that someone may take advantage of someday. --Charlie (kaufman@zk3.dec.com) ----- End Included Message ----- ! From ipsec-request@ans.net Tue Nov 29 05:22:57 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16937 (5.65c/IDA-1.4.4 for ); Tue, 29 Nov 1994 16:30:19 -0500 Received: by interlock.ans.net id AA13412 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 29 Nov 1994 16:22:09 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 29 Nov 1994 16:22:09 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 29 Nov 1994 16:22:09 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 29 Nov 1994 16:22:09 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 29 Nov 1994 16:22:09 -0500 Date: Tue, 29 Nov 94 13:22:57 PST From: Ashar.Aziz@eng.sun.com (Ashar Aziz) Message-Id: <9411292122.AA21918@miraj.Eng.Sun.COM> To: ipsec@ans.net Subject: SKIP & Patent #5,081,678 Sara, Amir and other interested parties, Since this issue has been raised a few times by members of this WG, I have reviewed the claims of patent #5,081,678 (assigned to DEC) to see if an implementation of the SKIP specification would infringe on this patent. It is clear that what is described in the SKIP specification is *not* covered by patent #5,081,678. I will review the essential claims of this patent to explain why. Patent #5,081,678 starts by stiplulating that each node has a unique master key that only *it* knows. This master key is *not* shared with any other node. This essentially rules out the possibility that this master key can be used to *establish* traffic keys, since one node is not in a position to encrypt a traffic key in another node's master key (because it doesn't know the other node's master key). To start secure communications, the pair of nodes first negotiate a session key, using some interactive session key-negotiation protocol (which is not specified). Concurrent or subsequent to this, each node encrypts the session key in its *own* master key, and reveals this encrypted session key to the other side. This allows the other side to send the session key encrypted in the master key of the other side, as part of the packet header. (The patent refers to the session key as "the shared key".) Note that one side is not in a position to compute the encryption of the session key in the master key of the other side. The patent then describes how this eliminates the need for a look-up of the session key in a table in system memory. The motivation for doing all this is to avoid this look-up of the session key in a table, because this was perceived to be a performance problem. In order to change keys, the communicating pair has to interactively negotiate another session key. Again, each side will inform the other of the encryption of the session key in its own master key, so it can be sent as part of the packet header. By contrast, in SKIP, the first step is to establish a *shared* master key (using a public-key agreement protocol like DH, or manual techniques). Traffic encryption keys are *established* by sending them encrypted in this shared master key. There is no interactive session key establishment protocol for this. In fact there are no sessions. Traffic keys can be spontaneously changed in a similar manner. SKIP uses inline encrypted keys as fundamentally a *key-management* technique. By contrast what the DEC patent describes is fundamentally a *key look-up* technique. Let's look at an example patent claim, to see if implementing the SKIP specification would require performing the method steps claimed in the DEC patent. Looking at, e.g., claim 1 of the DEC patent, it comprises the following steps. (The rest of the DEC patent claims are similar from the point of view of this comparison.) step a) coupling the first node to the second node, the second node having a master key that is unique to that node and known only by the second node, both nodes having a shared key; (The SKIP specification does not utilize unique per-node master keys. Instead it uses *shared* master keys.) step b) encrypting the shared key at the second node under the control of the master key of the second node to form an encrypted version of the shared key (Since the SKIP specification does not have per-node master keys or prior session keys, this step isn't performed either. SKIP does not involve encrypting a shared session key as specified here.) and step c) transmitting the encrypted version of the shared key from the second node to the first node so that the encrypted version of the shared key can be incorporated by the first node into encrypted data packets transmitted to the second node and used by the second node to decrypt data in transmitted encrypted data packets to establish secure communications between the first node and the second node. (This transmission of the encrypted session key between the two nodes does not follow the SKIP spec, for the reasons already mentioned. Since the master keys are shared, one side can communicate traffic encryption keys to the other side using the shared master key and a randomly generated traffic key. This clearly cannot be done using the DEC scheme.) Would implementing the SKIP specification require performing steps a, b and c? The answer is clearly, no. *None* of steps a, b and c would be used in an implementation of the SKIP specification. Therefore, implementing the SKIP specification would NOT infringe on the DEC patent (#5,081,678). Regards, Ashar. From ipsec-request@ans.net Tue Nov 29 08:33:06 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21036 (5.65c/IDA-1.4.4 for ); Tue, 29 Nov 1994 19:45:11 -0500 Received: by interlock.ans.net id AA24690 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 29 Nov 1994 19:33:57 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 29 Nov 1994 19:33:57 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 29 Nov 1994 19:33:57 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 29 Nov 1994 19:33:57 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 29 Nov 1994 19:33:57 -0500 Date: Tue, 29 Nov 94 16:33:06 PST From: Ashar.Aziz@eng.sun.com (Ashar Aziz) Message-Id: <9411300033.AA22037@miraj.Eng.Sun.COM> To: housley@spyrus.com Subject: Re: Re[2]: On SKIP and non-interactive key management Cc: ipsec@ans.net >From housley@spyrus.com Mon Nov 21 13:47:31 1994 >The SAID should be used to indirectly tell which algorithms and modes are being >used. In a sence, the agreement of a key between two parties is the >establishment of a connection, only we call it a security association. Russ, If you read the SKIP draft, you will realize why interactivley negotiating SAIDs is not a good idea, when one is not interactively negotiating keys. >I thought that this group agreed on 32 bit SAIDs with the high order bit >reserved for multicast security associations. When did the issue >get reopened? Actually, there was some verbal agreement at the last WG to use 4 bits of the SAID for the IPSP protocol version number, and the remaining as part of the SAID. Since, at this point in time, there isn't yet an online draft of the IPSP, I think it is premature to say that important issues like this one have been settled. Ashar. From ipsec-request@ans.net Tue Nov 29 09:25:05 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20344 (5.65c/IDA-1.4.4 for ); Tue, 29 Nov 1994 20:31:09 -0500 Received: by interlock.ans.net id AA14103 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 29 Nov 1994 20:26:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 29 Nov 1994 20:26:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 29 Nov 1994 20:26:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 29 Nov 1994 20:26:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 29 Nov 1994 20:26:28 -0500 Date: Tue, 29 Nov 94 17:25:05 PST From: Ashar.Aziz@eng.sun.com (Ashar Aziz) Message-Id: <9411300125.AA22055@miraj.Eng.Sun.COM> To: housley@spyrus.com Subject: Re: Modular approach to key management Cc: ipsec@ans.net >From ipsec-request@ans.net Mon Nov 21 15:33:39 1994 >My suggestion is that we adopt the IEEE work, then select particular algorithms >for use in the Internet. Of course, the IPSEC WG would also have to define the >attributes that are part of security association negotiation. These attributes >have to be defined regardless of the approach taken, so this is neither a plus >nor a minus to the IEEE 802.10c approach. I am afraid that I, for one, am not amenable to adopting IEEE 802.10c as something suitable for use with IPSP, for a number of reasons which I'll describe below. (This is based on the IEEE 802.10c draft that was available sometime before the last IETF meeting so if things have substantially changed since then, I am not aware of that.) o IEEE 802.10c is quite a complex document. In my view, unnecessarily so. If this groups decides to adopt it, it needs to be much clearer and easier to understand than it currently is. o IEEE 802.10c utilizes OSI upper layer services and concepts like Application Entity Titles etc. I dont think that the Internet community needs to buy into (and implement) the OSI upper layer services, with its associated complexities, just for the sake of IP layer key-management. Especially since much simpler alternatives already exist. o IEEE 802.10c multicast design uses a single key obtained from a Multicast KDC. Changing this key requires obtaining a new key from the Multicast KDC. This may work for small multicast groups as may arise on a single 802.x subnet (which is what 802.10 is intended for) but this will not scale to the number of nodes possible in an Internet wide multicast group. o Using the same key for all members of a multicast group eliminates using some of the highest performance stream ciphers commercially available for traffic encryption purposes. This is a major disadvantage for high-performance multicast applications like encrypted video. o The fact that IEEE 802.10 was designed for subnets (and not internets, for which scalability to a large number of nodes is criticial) shows in places like how to determine which application entity to use in order to negotiate session keys. In one of the appendices, it states that each node will have a local table of mappings between 802.x MAC addresses and AE-Titles. This might work for a single subnet. This will clearly not work for the Internet, where it is not feasible to have a local table of mappings between IP addresses and AE-Titles for the entire Internet. >In my opinion, IEEE 802.10c decreases the time to market. Protocol development >can take alot of time, especially in an open environment like the IEEE and >the IETF. Therefore, take advantage of the investement that has already >been made by the IEEE 802.10 participants, and take a working solution to >the Internet sooner. I think that IEEE 802.10c is the wrong solution for the Internet. It will substantially increase time to market because of the complexities inherent a complete OSI upper layer implementation (truly unnecessary for the task at hand). It also does not adequately address the needs of the Internet, because of various subnet oriented design decisions. Regards, Ashar. From ipsec-request@ans.net Wed Nov 30 14:09:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA31959 (5.65c/IDA-1.4.4 for ); Wed, 30 Nov 1994 10:24:00 -0500 Received: by interlock.ans.net id AA18790 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 30 Nov 1994 10:17:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 30 Nov 1994 10:17:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 30 Nov 1994 10:17:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 30 Nov 1994 10:17:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 30 Nov 1994 10:17:50 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 30 Nov 1994 10:17:50 -0500 Date: 30 Nov 94 08:09:00 -0600 To: Ashar.Aziz@eng.sun.com, housley@spyrus.com Cc: ipsec@ans.net Subject: Re[4]: On SKIP and non-interactive key management Message-Id: >Actually, there was some verbal agreement at the last WG to use >4 bits of the SAID for the IPSP protocol version number, and >the remaining as part of the SAID. Since, at this point in time, >there isn't yet an online draft of the IPSP, I think it is premature >to say that important issues like this one have been settled. There will be a draft late this week. A new editing team is scrambling to pull it complete it. The draft contains a 32 bit SAID field. The top order bits will be reserved (5 or 6 high order bits set to zero) to allow for possible Version Number, PDU Type, and multicast bit. Paul _______________________________________________________________________________ Subject: Re: Re[2]: On SKIP and non-interactive key management Author: Ashar.Aziz@eng.sun.com@INTERNET Date: 11/29/94 6:33 PM >From housley@spyrus.com Mon Nov 21 13:47:31 1994 >The SAID should be used to indirectly tell which algorithms and modes are being >used. In a sence, the agreement of a key between two parties is the >establishment of a connection, only we call it a security association. Russ, If you read the SKIP draft, you will realize why interactivley negotiating SAIDs is not a good idea, when one is not interactively negotiating keys. >I thought that this group agreed on 32 bit SAIDs with the high order bit >reserved for multicast security associations. When did the issue >get reopened? Actually, there was some verbal agreement at the last WG to use 4 bits of the SAID for the IPSP protocol version number, and the remaining as part of the SAID. Since, at this point in time, there isn't yet an online draft of the IPSP, I think it is premature to say that important issues like this one have been settled. Ashar.