Received: from relay.tis.com by neptune.TIS.COM id aa02975; 3 Jun 96 21:26 EDT Received: by relay.tis.com; id VAA02557; Mon, 3 Jun 1996 21:28:33 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma002550; Mon, 3 Jun 96 21:28:04 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01518; Mon, 3 Jun 96 21:28:10 EDT Received: by relay.tis.com; id VAA02547; Mon, 3 Jun 1996 21:28:03 -0400 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1) id xma002544; Mon, 3 Jun 96 21:27:51 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id SAA20139 for ipsec@tis.com; Mon, 3 Jun 1996 18:30:26 -0700 Message-Id: <199606040130.SAA20139@puli.cisco.com> From: Ran Atkinson Date: Mon, 3 Jun 1996 18:30:25 PDT X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipsec@TIS.COM Subject: AH Transform Results Sender: ipsec-approval@neptune.tis.com Precedence: bulk Paul and I have reviewed and discussed the feedback from the IPsec WG Last Call on the AH transform drafts. There is rough consensus that both the HMAC MD5 AH and HMAC SHA AH transforms co-edited by Rob Glenn should be issued as Proposed Standard RFCs with both being mandatory- to-implement. The IESG has been asked to issue both as Proposed Standard RFCs following normal IESG procedures. RFC-1828 will move to HISTORIC status as a result of these transforms moving onto the standards track. Ran rja@cisco.com Paul palamber@us.oracle.com -- Received: from relay.tis.com by neptune.TIS.COM id aa29191; 7 Jun 96 16:17 EDT Received: by relay.tis.com; id QAA11353; Fri, 7 Jun 1996 16:18:52 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma011345; Fri, 7 Jun 96 16:18:28 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA09756; Fri, 7 Jun 96 16:18:26 EDT Received: by relay.tis.com; id QAA11340; Fri, 7 Jun 1996 16:18:22 -0400 Received: from unknown(147.225.5.5) by relay.tis.com via smap (V3.1) id xma011336; Fri, 7 Jun 96 16:18:17 -0400 Received: by interlock.ans.net id AA17403 (InterLock SMTP Gateway 3.0 for ipsec@ans.net); Fri, 7 Jun 1996 16:20:33 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 7 Jun 1996 16:20:33 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 7 Jun 1996 16:20:33 -0400 Date: Fri, 7 Jun 1996 13:20:14 -0700 From: Matt Bishop Message-Id: <9606072020.AA10083@nob> To: ipsec@ans.net Subject: CFP: 1997 Symposium on Network and Distributed System Security Sender: ipsec-approval@neptune.tis.com Precedence: bulk CALL FOR PAPERS The Internet Society Symposium on Network and Distributed System Security February 10-11, 1997, San Diego Princess Resort, San Diego, California Submissions due: August 1, 1996 Notification to Authors: October 1, 1996 Camera-Ready Copy due: November 1, 1996 GOAL: The symposium will bring together people who are building hardware and software to provide network and distributed system security services. The symposium is intended for those interested in the practical aspects of network and distributed system security, focusing on actual system design and implementation, rather than theory. We hope to foster the exchange of technical information that will encourage and enable the Internet community to apply, deploy, and advance the state of available security technology. Symposium proceedings will be published by the IEEE Computer Society Press. Topics for the symposium include, but are not limited to, the following: * Design and implementation of communication security services: authentication, integrity, confidentiality, authorization, non-repudiation, and availability. * Design and implementation of security mechanisms, services, and APIs to support communication security services, key management and certification infrastructures, audit, and intrusion detection. * Requirements and designs for securing network information resources and tools -- WorldWide Web (WWW), Gopher, archie, and WAIS. * Requirements and designs for systems supporting electronic commerce -- payment services, fee-for-access, EDI, notary -- endorsement, licensing, bonding, and other forms of assurance. * Design and implementation of measures for controlling network communication -- firewalls, packet filters, application gateways, and user/host authentication schemes. * Requirements and designs for telecommunications security especially for emerging technologies -- very large systems like the Internet, high-speed systems like the gigabit testbeds, wireless systems, and personal communication systems. * Special issues and problems in security architecture, such as interplay between security goals and other goals -- efficiency, reliability, interoperability, resource sharing, and cost. * Integration of security services with system and application security facilities, and application protocols -- including but not limited to message handling, file transport, remote file access, directories, time synchronization, data base management, routing, voice and video multicast, network management, boot services, and mobile computing. GENERAL CHAIR: David Balenson, Trusted Information Systems PROGRAM CHAIRS: Clifford Neuman, University of Southern California Matt Bishop, University of California at Davis PROGRAM COMMITTEE: Steve Bellovin, AT&T Research Tom Berson, Anagram Laboratories Doug Engert, Argonne National Laboratory Warwick Ford, Bell Northern Research Richard Graveman, Bellcore Li Gong, SRI Burt Kaliski, RSA Laboratories Steve Kent, BBN Tom Longstaff, CERT Doug Maughan, National Security Agency Dan Nessett, Sun Microsystems Hilarie Orman, DARPA Michael Roe, Cambridge University Christoph Schuba, Purdue University Jonathan Trostle, CyberSafe Theodore Ts'o, Massachusetts Institute of Technology Doug Tygar, Carnegie Mellon University Vijay Varadharajan, University of W. Sydney Roberto Zamparo, Telia Research LOCAL ARRANGEMENTS CHAIR: Thomas Hutton, San Diego Supercomputer Center PUBLICATIONS CHAIR: Steve Welke, Institute for Defense Analyses REGISTRATIONS CHAIR: Donna Leggett, Internet Society SUBMISSIONS: The committee invites technical papers and panel proposals for topics of technical and general interest. Technical papers should be 10-20 pages in length. Panel proposals should be two pages and should describe the topic, identify the panel chair, explain the format of the panel, and list three to four potential panelists. Technical papers will appear in the proceedings. A description of each panel will appear in the proceedings, and may at the discretion of the panel chair, include written position statements from each panelist. Each submission must contain a separate title page with the type of submission (paper or panel), the title or topic, the names of the author(s), organizational affiliation(s), telephone and FAX numbers, postal addresses, Internet electronic mail addresses, and must list a single point of contact if more than one author. The names of authors, affiliations, and other identifying information should appear only on the separate title page. Submissions must be received by 1 August 1996, and should be made via electronic mail in either PostScript or ASCII format. If the committee is unable to print a PostScript submission, it will be returned and hardcopy requested. Therefore, PostScript submissions should arrive well before 1 August. If electronic submission is difficult, submissions should be sent via postal mail. All submissions and program related correspondence (only) should be directed to the program chair: Clifford Neuman, University of Southern California, Information Sciences Institute, 4676 Admiralty Way, Marina del Rey, California 90292-6695, Phone: +1 (310) 822-1511, FAX: +1 (310) 823-6714, Email: sndss97-submissions@isi.edu. Dates, final call for papers, advance program, and registration information will be available at the URL: http://www.isoc.org/conferences/ndss97. Each submission will be acknowledged by e-mail. If acknowledgment is not received within seven days, please contact the program chair as indicated above. Authors and panelists will be notified of acceptance by 1 October 1996. Instructions for preparing camera-ready copy for the proceedings will be sent at that time. The camera-ready copy must be received by 1 November 1996. Received: from relay.tis.com by neptune.TIS.COM id aa25964; 9 Jun 96 22:33 EDT Received: by relay.tis.com; id WAA22845; Sun, 9 Jun 1996 22:35:09 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma022838; Sun, 9 Jun 96 22:34:37 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20399; Sun, 9 Jun 96 22:34:37 EDT Received: by relay.tis.com; id WAA22835; Sun, 9 Jun 1996 22:34:36 -0400 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1) id xma022833; Sun, 9 Jun 96 22:34:07 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id TAA03140 for ipsec@tis.com; Sun, 9 Jun 1996 19:36:34 -0700 Date: Sun, 9 Jun 1996 19:36:34 -0700 From: Ran Atkinson Message-Id: <199606100236.TAA03140@puli.cisco.com> To: ipsec@TIS.COM Subject: FYI: New IPsec base drafts coming soon Sender: ipsec-approval@neptune.tis.com Precedence: bulk Hi, I've just submitted (slightly) revised versions of RFC-1825 through RFC-1827 to the Internet Drafts folks. These should appear online before Montreal. I've been incredibly busy with other matters and just haven't had has much time to edit as I might have preferred, but an interested IAB member has gently reminded me to get them out before Montreal. There will be opportunity to discuss these in Montreal (though they really are drafty at this stage), but they cannot be considered for advancement to Draft Standard until the very end of this year (per IETF standards process rules and timers) so there is no need to rush out and read them right away. As folks might recall from the past, the most useful kinds of comments at this stage of things are email messages to me of the form (existing draft text, proposed revised text, rationale for the change). Ran rja@cisco.com Received: from relay.tis.com by neptune.TIS.COM id aa21881; 11 Jun 96 7:05 EDT Received: by relay.tis.com; id HAA14706; Tue, 11 Jun 1996 07:07:26 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma014685; Tue, 11 Jun 96 07:06:53 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10929; Tue, 11 Jun 96 07:06:40 EDT Received: by relay.tis.com; id HAA14643; Tue, 11 Jun 1996 07:06:39 -0400 Received: from mailserv.esat.kuleuven.ac.be(134.58.56.129) by relay.tis.com via smap (V3.1) id xma014626; Tue, 11 Jun 96 07:06:22 -0400 Received: from domus.esat.kuleuven.ac.be by mailserv (5.67b8/IDA/v1.5) id AA25943; Tue, 11 Jun 1996 13:08:06 +0200 Date: Tue, 11 Jun 1996 13:08:05 +0200 (METDST) From: Bart Preneel To: baldwin Cc: "Robert W. Baldwin" , ipsec@TIS.COM Subject: Re: MD5 vs. SHA-1, Performance & Pedigree In-Reply-To: <9604298333.AA833387131@snail.rsa.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Charset: ISO_8859-1 X-Char-Esc: 29 Sender: ipsec-approval@neptune.tis.com Precedence: bulk On Wed, 29 May 1996, baldwin wrote: > .... > For those who care about performance here are the numbers > from the BSAFE 3.0 crypto toolkit on various platforms. The tests > are run on very large input blocks. The speeds are in megabytes > per second. > > Digest Performance in MegaBytes per Second > > Pentium P5 Power Mac SPARC 4 DEC Alpha > 90 MHz 80 MHz 110 MHz 200 MHz > > MD5 13.1 3.1 5.1 8.5 > > SHA1 2.5 1.2 2.0 3.3 > > The number for the pentium is particularly high because > extensive work was done to optimize the algorithm for the > dual integer pipeline of the pentium. The rest are compiled > from C code with speed optimization turned on. > > --Bob Baldwin > RSA Data Security Inc. > The Pentium figures are not optimal (particularly for SHA-1). Even more extensive work on optimization resulted in following figures for all hash functions in the MD4-family: Performance in Megabytes per Second on a 90 MHz Pentium MD4 MD5 SHA-1 RIPEMD RIPEMD-128 RIPEMD-160 20.9 14.2 6.1 10.3 8.0 5.0 RIPEMD-160 and RIPEMD-128 were presented at the Fast Software Encryption workshop in February 1996. The paper as well as a reference C implementation are available via anonymous ftp to ftp.esat.kuleuven.ac.be in the directory /pub/COSIC/bosselae/ripemd/. For more information about the Pentium figures I refer you to the forthcoming Crypto'96 paper: A. Bosselaers, R. Govaerts, J. Vandewalle: `Fast Hashing on the Pentium'. Antoon Bosselaers & Bart Preneel K.U.Leuven ------------------------------------------------------------------------------- Katholieke Universiteit Leuven tel. +32 16 32 11 48 Dept. Electrical Engineering-ESAT / COSIC fax. +32 16 32 19 86 K. Mercierlaan 94, B-3001 Heverlee, BELGIUM bart.preneel@esat.kuleuven.ac.be ------------------------------------------------------------------------------- Received: from relay.tis.com by neptune.TIS.COM id aa24764; 11 Jun 96 10:21 EDT Received: by relay.tis.com; id KAA19046; Tue, 11 Jun 1996 10:23:15 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma019033; Tue, 11 Jun 96 10:22:53 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22094; Tue, 11 Jun 96 10:22:52 EDT Received: by relay.tis.com; id KAA19022; Tue, 11 Jun 1996 10:22:50 -0400 Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay.tis.com via smap (V3.1) id xma019002; Tue, 11 Jun 96 10:22:25 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13083; 11 Jun 96 9:40 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: ipsec@TIS.COM From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-ipsec-auth-header-00.txt Date: Tue, 11 Jun 96 09:40:23 -0400 Message-Id: <9606110940.aa13083@IETF.CNRI.Reston.VA.US> Sender: ipsec-approval@neptune.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IP Authentication Header Author(s) : R. Atkinson Filename : draft-ietf-ipsec-auth-header-00.txt Pages : 14 Date : 06/10/1996 This document describes a mechanism for providing cryptographic authentication for IPv4 and IPv6 datagrams. An Authentication Header (AH) is inserted after the IP header being authenticated and before the other information being authenticated. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-auth-header-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-auth-header-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-auth-header-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960610121416.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-auth-header-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-auth-header-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960610121416.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- Received: from relay.tis.com by neptune.TIS.COM id aa24765; 11 Jun 96 10:21 EDT Received: by relay.tis.com; id KAA19044; Tue, 11 Jun 1996 10:23:15 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma019031; Tue, 11 Jun 96 10:22:53 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22092; Tue, 11 Jun 96 10:22:51 EDT Received: by relay.tis.com; id KAA19023; Tue, 11 Jun 1996 10:22:50 -0400 Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay.tis.com via smap (V3.1) id xmaa19002; Tue, 11 Jun 96 10:22:26 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13084; 11 Jun 96 9:40 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: ipsec@TIS.COM From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-ipsec-arch-sec-00.txt Date: Tue, 11 Jun 96 09:40:26 -0400 Message-Id: <9606110940.aa13084@IETF.CNRI.Reston.VA.US> Sender: ipsec-approval@neptune.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Security Architecture for the Internet Protocol Author(s) : R. Atkinson Filename : draft-ietf-ipsec-arch-sec-00.txt Pages : 22 Date : 06/10/1996 This memo describes the security mechanisms for IP version 4 (IPv4) and IP version 6 (IPv6) and the services that they provide. Each security mechanism is specified in a separate document. This document also describes key management requirements for systems implementing those security mechanisms. This document is not an overall Security Architecture for the Internet and is instead focused on IP-layer security. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-arch-sec-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-arch-sec-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-arch-sec-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960610120652.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-arch-sec-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-arch-sec-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960610120652.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- Received: from relay.tis.com by neptune.TIS.COM id aa24766; 11 Jun 96 10:21 EDT Received: by relay.tis.com; id KAA19045; Tue, 11 Jun 1996 10:23:15 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma019032; Tue, 11 Jun 96 10:22:53 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22093; Tue, 11 Jun 96 10:22:51 EDT Received: by relay.tis.com; id KAA19021; Tue, 11 Jun 1996 10:22:50 -0400 Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay.tis.com via smap (V3.1) id xmab19002; Tue, 11 Jun 96 10:22:26 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13128; 11 Jun 96 9:40 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: ipsec@TIS.COM From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-ipsec-payload-00.txt Date: Tue, 11 Jun 96 09:40:31 -0400 Message-Id: <9606110940.aa13128@IETF.CNRI.Reston.VA.US> Sender: ipsec-approval@neptune.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IP Encapsulating Security Payload (ESP) Author(s) : R. Atkinson Filename : draft-ietf-ipsec-payload-00.txt Pages : 12 Date : 06/10/1996 This document describes the IP Encapsulating Security Payload (ESP). ESP is a mechanism for providing integrity and confidentiality to IP datagrams. In some circumstances it can also provide authentication to IP datagrams. The mechanism works with both IPv4 and IPv6. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-payload-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-payload-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-payload-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960610120149.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-payload-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-payload-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960610120149.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- Received: from relay.tis.com by neptune.TIS.COM id aa28287; 12 Jun 96 23:33 EDT Received: by relay.tis.com; id XAA27158; Wed, 12 Jun 1996 23:35:29 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma027155; Wed, 12 Jun 96 23:35:04 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27218; Wed, 12 Jun 96 23:34:59 EDT Received: by relay.tis.com; id XAA27152; Wed, 12 Jun 1996 23:34:59 -0400 Received: from unknown(131.112.32.132) by relay.tis.com via smap (V3.1) id xma027150; Wed, 12 Jun 96 23:34:39 -0400 From: Masataka Ohta Message-Id: <199606130324.MAA14563@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id MAA14563; Thu, 13 Jun 1996 12:24:27 +0900 Subject: Re: MD5 vs. SHA-1, Performance & Pedigree To: Bart Preneel Date: Thu, 13 Jun 96 12:24:26 JST Cc: baldwin@rsa.com, ipsec@TIS.COM In-Reply-To: ; from "Bart Preneel" at Jun 11, 96 1:08 pm X-Mailer: ELM [version 2.3 PL11] Sender: ipsec-approval@neptune.tis.com Precedence: bulk > > Digest Performance in MegaBytes per Second > > > > Pentium P5 Power Mac SPARC 4 DEC Alpha > > 90 MHz 80 MHz 110 MHz 200 MHz > > > > MD5 13.1 3.1 5.1 8.5 > > > > SHA1 2.5 1.2 2.0 3.3 > Performance in Megabytes per Second on a 90 MHz Pentium > > MD4 MD5 SHA-1 RIPEMD RIPEMD-128 RIPEMD-160 > > 20.9 14.2 6.1 10.3 8.0 5.0 A problem is that a lot of computation time of a generic hash functions on byte streams is comsumed for adjusting word alignment, which can be avoided on hosts and routers by adjusting alignment of packet buffers. Considering Amdahl's law, the actual performance difference between MD5 and SHA-1 is unnegligibly large. Note that Pentium derived from 8080, is good at handling byte streams and DEC Alpha can access memory only word-by-word. Masataka Ohta Received: from relay.tis.com by neptune.TIS.COM id aa06379; 13 Jun 96 9:38 EDT Received: by relay.tis.com; id JAA02840; Thu, 13 Jun 1996 09:40:38 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma002829; Thu, 13 Jun 96 09:40:14 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08619; Thu, 13 Jun 96 09:40:11 EDT Received: by relay.tis.com; id JAA02822; Thu, 13 Jun 1996 09:40:08 -0400 Received: from unknown(132.151.1.35) by relay.tis.com via smap (V3.1) id xma002789; Thu, 13 Jun 96 09:39:47 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa17542; 13 Jun 96 9:39 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: ipsec@TIS.COM From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-ipsec-cdp-01.txt Date: Thu, 13 Jun 96 09:38:56 -0400 Message-Id: <9606130939.aa17542@IETF.CNRI.Reston.VA.US> Sender: ipsec-approval@neptune.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Certificate Discovery Protocol Author(s) : A. Aziz, T. Markson, H. Prafullchandra, R. Skrenta, G. Caronni Filename : draft-ietf-ipsec-cdp-01.txt Pages : 12 Date : 06/12/1996 Use of Public key cryptography is becoming widespread on the Internet in such applications as electronic mail and IP Security (IPSEC). Currently, however, a common public key certificate infrastructure does not exist which is interoperable with other systems and ubiquitous. In light of this, we describe a protocol which may be used to exchange or retrieve certificates (essentially signed public keys) with or from another entity. The protocol may be used to request certificates from a directory/name server or from the entity who owns the certificate. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-cdp-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-cdp-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-cdp-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960612144430.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-cdp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-cdp-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960612144430.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- Received: from relay.tis.com by neptune.TIS.COM id aa14438; 13 Jun 96 16:33 EDT Received: by relay.tis.com; id QAA16250; Thu, 13 Jun 1996 16:35:42 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma016238; Thu, 13 Jun 96 16:35:16 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01854; Thu, 13 Jun 96 16:35:12 EDT Received: by relay.tis.com; id QAA16231; Thu, 13 Jun 1996 16:35:10 -0400 Received: from nsco.network.com(129.191.1.1) by relay.tis.com via smap (V3.1) id xma016095; Thu, 13 Jun 96 16:33:27 -0400 Received: from (jimsmac.network.com) by nsco.network.com (4.1/1.34) id AA09011; Thu, 13 Jun 96 15:40:31 CDT Message-Id: <31C07B68.1D82@network.com> Date: Thu, 13 Jun 1996 15:35:18 -0500 From: Jim Hughes Reply-To: hughes@nsco.network.com Organization: Network Systems Corporation X-Mailer: Mozilla 3.0b4 (Macintosh; I; PPC) Mime-Version: 1.0 To: ipsec@TIS.COM, internet-drafts@cnri.reston.va.us Cc: hughes@nsco.network.com, Bill Simpson , "D. A. Wagner" , Harry Varnis , James Hughes , Ken Hardwick , Paul Lambert , Perry Metzger , Ran Atkinson , Robert Baldwin Subject: ietf-ipsec-esp-des-md5-03.txt Content-Type: multipart/mixed; boundary="------------5C1F4A73284" Sender: ipsec-approval@neptune.tis.com Precedence: bulk This is a multi-part message in MIME format. --------------5C1F4A73284 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here is the latest ietf-ipsec-esp-des-md5-03.txt jim --------------5C1F4A73284 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="554E4958"; name="esp-des-md5-03.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="esp-des-md5-03.txt" Security Working Group IPsec Working Group Request for Comments: DRAFT J. Hughes, Editor June 1996 Expires in Six months Combined DES-CBC, HMAC and Replay Prevention Security Transform Status of this Memo This document is a submission to the IETF Internet Protocol Security (IPSEC) Working Group. Comments are solicited and should be addressed to the working group mailing list (ipsec@tis.com) or to the editor. This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts draft documents are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract This draft describes a combination of privacy, authentication, integrity and replay prevention into a single packet format. This document is the result of significant work by several major contributors and the IPsec working group as a whole. These contributors, cited later in this document, provided many of the key technical details summarized in this document. Hughes [Page 1] RFC DRAFT June 1996 Discussion This draft allows a combination of MD5 and DES-CBC. In addition to privacy, the goal of this transform is to ensure that the packet is authentic, can not be modified in transit, or replayed. For the purpose of this RFC, the terms conformance and compliance are synonymous. The claims of privacy, integrity, authentication, and replay prevention are made in this draft. A good general text describing the methods and algorithm are in [Schneier95]. Privacy is provided by DES-CBC [FIPS-46] [FIPS-46-1] [FIPS-74] [FIPS-81]. Integrity is provided by HMAC [Krawczyk96]. Authentication is provided since only the source and destination know the HMAC key. If the HMAC is correct, it proves that it must have been added by the source. Replay prevention is provided by the combination of a constantly increasing count, the SPI and the HMAC key. The integrity of the replay field is provided by the HMAC. Hughes [Page 2] RFC DRAFT June 1996 Packet Format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- | Security Parameters Index (SPI) | ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | --- | Replay Prevention Field (count) | | ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | ~ Payload Data ~ | | | |HMAC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DES | | Padding (0-7 bytes) | | CBC +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Pad Length | Payload Type | v | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- | | | | ~ HMAC digest ~ | | | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- Security Parameters Index This field is negotiated at key setup and shall not be 0 [RFC-1825] Replay Prevention Replay Prevention is an unsigned 32 bit incrementing counter starting at a value of 1. The key (K, as described in a later section) must be changed frequently enough so that the counter is not allowed to wrap; in other words, the key must be changed before (2^32)-2 packets are transmitted using this key. For a given SPI, counter wrapping shall be considered to be a replay attack. (While a wrap is a replay attack, there is always the possibility that a packet can get duplicated, so the presence of a single or small number of duplicate packets is not an absolute indication of a replay attack.) The receiver must verify that for a given SPI the packets received have non-repeating (non-duplicate) counter values. This can be implemented as a simple increasing count test or the receiver may choose to accept out-of-order packets as long as it is guaranteed that packets can be received only once. For example, an implementation can use a sliding receive window, the size of which is an implementation detail. If such a receive window is supported, the receiver must ensure that it will accept packets within the current Hughes [Page 3] RFC DRAFT June 1996 window only once, and reject any packets it receives with a value that is less than the lower bound of the window. An example may allow the most recent 32 packets to be allowed to arrive out of order. That is, these 32 packets can arrive in any sequence relative to each other except that these packets are guaranteed to arrive only once. Appendix A has actual code that implement a 32 packet replay window and a test routine. The purpose of this routine is to show how it could be implemented. Payload The payload contains data that is described by the payload type field. This field is an integral number of bytes in length; the following padding and pad length fields will help provide alignment to a double word boundary. Padding The padding (pad bytes and pad length field) is used to align the following "payload type" field to end on a double word boundary (when counting from the start of the replay field). Padding bytes may be initialized with random data. At a minimum, the number of pad bytes added must be enough to align the payload type field on the next appropriate boundary. However, the sender may choose to include additional padding, provided that the alignment is maintained. In total, the sender can add 0-255 bytes of padding. Pad Length The pad length field indicates the number of pad bytes immediately preceding it. The range of valid values is 0-255, where a value of zero indicates that the byte immediately preceding the pad length field is the last byte of the payload. Hughes [Page 4] RFC DRAFT June 1996 Payload Type Describes what the payload is. The values are described in: ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers HMAC Digest The HMAC digest is a 128 bit residue described in [Krawczyk96]. This covers the SPI, replay, payload, padding, pad length, payload type. HMAC is a keyed algorithm and shall use the HMAC key as described in the section on keys. Encryption Transform Procedure CBC chaining with an IV_key is used. IV_key count|x1 x2 x3 | | | | |-------(+) --------(+) --------(+) | | | | | ------- | ------- | -------- k--| DES | | k--| DES | | k--| DES | ------- | ------- | -------- | | | | | |-----| |-----| |----... | | | y1 y2 y3 Where count is the Replay counter. x1, x2, x3 are the plaintext (x1 is 32 bits, all others are 64 bits). y1, y2, y3 are the ciphertext. The process of this transformation is comprised of the following 3 steps. 1. Taking the data and encapsulating it with the SPI, count, pad, pad length, and payload type. 2. Calculating the HMAC using the HMAC_key and creating the digest from the SPI, count, data, pad, pad length, and payload type and placing the result into the HMAC digest field. 3. Encrypting the count, data, pad, pad length, payload type, and HMAC digest using DES and the appropriate DES_key_ and IV_key. Hughes [Page 5] RFC DRAFT June 1996 (Note that the first DES block is a combination of the count and the first word of plaintext.) Decryption Transform Procedure CBC chaining with an IV_key is used. IV_key y1 y2 y3 | | | | | |------ |------ |----... | | | | | | | ------- | ------- | -------- | k--| DES | | k--| DES | | k--| DES | | ------- | ------- | -------- | | | | | | |-------(+) |-------(+) |-------(+) | | | (count|x1) x2 x3 The process of this transformation is comprised of the following 4 steps. 1. (Optional step) Decrypt the first bock of data using the appropriate DES_key and IV_key and then do a quick "sanity check" of the count. If the count has decreased below the window or has increased by more than 65k, then it is safe to discard this packet as either a replay, non-authentic or too old. If the count is within 65K, then the probability that the packet is authentic is 65535/65536. (The following replay check and HMAC check are both still required). 2. Decrypt the count (if not already done), data, pad, pad length, and payload type using DES and the appropriate DES_key_ and IV_key. 3. Calculate the HMAC using the HMAC_key and create the digest from the SPI, count, data, pad, pad length, and payload type and checking the result at digest at the end of the packet. If the digest is incorrect, discard the packet. 4. Check the count using the window algorithm discussed above. If the packet is duplicate or too old, discard the packet. Hughes [Page 6] RFC DRAFT June 1996 Key Material The key K is provided by the key management layer. This key is used to derive the symmetric keys, they are: DES_Key_I is the DES key for traffic from the initiator -> responder. DES_Key_R is the DES key for traffic from the responder -> initiator. HMAC_Key is the key for the HMAC Algorithm (This is the same for both directions, but since these are encrypted by different DES keys, then this is not a problem.) IV_key is used to stop code book attacks on the first block. The vertical bar symbol "|" is used to denote concatenation of bit strings. MD5(x|y) denotes the result of applying the MD5 function to the concatenated bit strings x and y. Truncate(x,n) denotes the result of truncating x to its first n bits. DES_Key_I = Truncate(MD5( D_Pad_I | K ),64) DES_Key_R = Truncate(MD5( D_Pad_R | K ),64) IV_Key = Truncate(MD5( I_Pad | K ),64) HMAC_Key = MD5( H_Pad | K ) where each _Pad_is 512 bit string. D_Pad_I = 0x5C repeated 64 times. D_Pad_R = 0x3A repeated 64 times. I_Pad = 0xAC repeated 64 times. H_Pad = 0x53 repeated 64 times. (Implementation note, The 16 byte intermediate residuals can be precalculated from these constants and stored to reduce processing overhead). Hughes [Page 7] RFC DRAFT June 1996 Security Considerations The ESP-DES-HMAC-RP transform described in this draft is immune to the [Bellovin96] attacks. (AH [RFC-1826], in some modes, can also provide immunity to these attack.) The implications of the size of K can be found in [Blaze96]. References [Bellovin96] Bellovin, S., "Problem Areas for the IP Security Protocols", AT&T Research, ftp://ftp.research.att.com/dist/smb/badesp.ps, July, 1996. [FIPS-46] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46, January 1977. [FIPS-46-1] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46-1, January 1988. [FIPS-74] US National Bureau of Standards, "Guidelines for Implementing and Using the Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 74, April 1981. [FIPS-81] US National Bureau of Standards, "DES Modes of Operation" Federal Information Processing Standard (FIPS) Publication 81, December 1980. [Krawczyk96] Krawczyk, H., Bellare, M., Canetti, R., "HMAC-MD5: Keyed-MD5 for Message Authentication", work-in-progress, http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ipsec- hmac-md5-00.txt, March, 1996 [Maughan96] Maughan, D., Schertler, M. Internet Security Association and Key Management Protocol (ISAKMP), work-in-progress, http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ipsec- isakmp-04.txt, February, 1996 [Orman96] Orman, H., "The Oakley Key Determination Protocol", work- in-progress, http://info.internet.isi.edu:80/in-drafts/files/draft- ietf-ipsec-oakley-00.txt, February, 1996. Hughes [Page 8] RFC DRAFT June 1996 [RFC-1825] Atkinson, R, "Security Architecture for the Internet Protocol", ftp://ds.internic.net/rfc/rfc1825.txt, August 1995. [RFC-1826] Atkinson, R, "IP Authentication Header", ftp://ds.internic.net/rfc/rfc1826.txt, August 1995. [Schneier95] Schneier, B., "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7 [Blaze96] Blaze M., Diffie, W., Rivest, R., Schneier, B., Shimomura, T., Thompson, E., Wiener, M., "Minimal Key Lengths for Symmetric Ciphers to Provide Adequate Commercial Security", http://theory.lcs.mit.edu/~rivest/bsa-final-report.ascii, January, 1996 Acknowledgements This document is the result of significant work by several major contributors. They include (in alphabetical order): Robert W. Baldwin RSA Labs. Kevin Kingdon RSA Labs Hugo Krawczyk IBM Corporation Perry Metzger Piermont Information Services Phil Rogaway University of California at Davis Bill Simpson Computer Systems Consulting Services Hughes [Page 9] RFC DRAFT June 1996 David A Wagner University of California at Berkeley In addition, the contributions of the entire IPSEC Working Group are acknowledged. The IPsec working group can be contacted through the chairs: Ran Atkinson Cisco Systems Paul Lambert Oracle Corporation Editor's Address James P. Hughes Network Systems Corporation Hughes [Page 10] RFC DRAFT June 1996 Appendix A This is a routine that implements a 32 packet window. This is intended on being an implementation sample. #include #include typedef unsigned long u_long; enum { ReplayWindowSize = 32 }; u_long bitmap = 0; /* session state - must be 32 bits */ u_long lastSeq = 0; /* session state */ /* Returns 0 if packet disallowed, 1 if packet permitted */ int ChkReplayWindow(u_long seq); int ChkReplayWindow(u_long seq) { u_long diff; if (seq == 0) return 0; /* first == 0 or wrapped */ if (seq > lastSeq) { /* new larger sequence number */ diff = seq - lastSeq; if (diff < ReplayWindowSize) { /* In window */ bitmap = (bitmap << diff) | 1; /* set bit for this packet */ } else bitmap = 1; /* This packet has a "way larger" */ lastSeq = seq; return 1; /* larger is good */ } diff = lastSeq - seq; if (diff >= ReplayWindowSize) return 0; /* too old or wrapped */ if (bitmap & (1 << diff)) return 0; /* this packet already seen */ bitmap |= (1 << diff); /* mark as seen */ return 1; /* out of order but good */ } Hughes [Page 11] RFC DRAFT June 1996 char string_buffer[512]; #define STRING_BUFFER_SIZE sizeof(string_buffer) int main() { int result; u_long last, current, bits; printf("Input initial state (bits in hex, last msgnum):\n"); if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) exit(0); sscanf(string_buffer, "%lx %lu", &bits, &last); if (last != 0) bits |= 1; bitmap = bits; lastSeq = last; printf("bits:%08lx last:%lu\n", bitmap, lastSeq); printf("Input value to test (current):\n"); while (1) { if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) break; sscanf(string_buffer, "%lu", ¤t); result = ChkReplayWindow(current); printf("%-3s", result ? "OK" : "BAD"); printf(" bits:%08lx last:%lu\n", bitmap, lastSeq); } return 0; } Hughes [Page 12] --------------5C1F4A73284-- Received: from relay.tis.com by neptune.TIS.COM id aa18301; 13 Jun 96 20:30 EDT Received: by relay.tis.com; id UAA19978; Thu, 13 Jun 1996 20:32:44 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma019974; Thu, 13 Jun 96 20:32:16 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA09113; Thu, 13 Jun 96 20:32:16 EDT Received: by relay.tis.com; id UAA19967; Thu, 13 Jun 1996 20:32:14 -0400 Received: from unknown(198.95.250.59) by relay.tis.com via smap (V3.1) id xma019964; Thu, 13 Jun 96 20:31:44 -0400 Received: from kingtut.mcom.com (h205-217-251-173.mcom.com [205.217.251.173]) by urchin.netscape.com (8.6.12/8.6.9) with SMTP id RAA12608; Thu, 13 Jun 1996 17:34:12 -0700 Message-Id: <31C0B4B1.1BD2@netscape.com> Date: Thu, 13 Jun 1996 17:39:13 -0700 From: Taher Elgamal X-Mailer: Mozilla 2.01Gold (Win95; I) Mime-Version: 1.0 To: ipsec@TIS.COM, ietf-pkix@tandem.com Subject: CALL FOR PAPERS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk CALL FOR PAPERS Multimedia Data Security Part of IS&T/SPIE's 1997 Symposium on Electronic Imaging: Science & Technology 8-14 February 1997 San Jose Convention Center San Jose, California USA Conference Chair: Taher Elgamal, Netscape Communications The growth of the use of public networks as the platform for multimedia applications in the past year has made it important to devise mechanisms for ensuring proper use of intellectual property, and increased the importance of employing security mechanisms for video and audio data. This conference will serve as a forum for the exchange of ideas in the areas of security systems and mechanisms especially in applications that handle large data volumes. Papers are solicited in all areas of security systems and algorithms including but not limited to: * security systems for imaging applications * security systems for real-time video applications * performance studies and comparisons for securing image data * watermarking and detection of fraudulent copying of intellectual property * metering schemes for intellectual property usage * audio and video encryption mechanisms * key management and security protocols for broadcast applications * payment systems for online multimedia applications * content protection mechanisms for online multimedia distribution. This conference is just one of nearly 30 conferences to be held at the EI'97 symposium. And EI'97 is one of 4 collocated symposia (Electronic Imaging, Biomedical Optics, Lasers and Applications, and Optoelectronics). Watch SPIE's web site for the entire Photonics West Call for Papers (late May-early June): http://www.spie.org/web/meetings/meetings_home.html For a printed call for papers or other information: E-mail: pw97@spie.org Fax: 360/647-1445 Phone: 360/676-3290 DEADLINES Paper Abstracts (for review) Due from Authors: 15 July 1996 Camera-Ready Abstracts (from accepted authors) Due: 18 November 1996 Manuscripts Due from all Authors: 13 January 1997 GUIDELINES FOR SUBMITTING AN ABSTRACT Send a 500 word abstract of your paper, by 15 July, in ONE of the following ways: >>electronic mail in ASCII format (NOT encoded) to abstracts@spie.org The SUBJECT line must include: EI97 (Elgamal) (Send one submission per email message.) Note: There will also be available an interactive abstract submission form on the web site. >>mail (please mail 4 hard copies) to: IS&T/SPIE Electronic Imaging '97 SPIE, P.O. Box 10, Bellingham, WA 98227-0010 Shipping Address: 1000 20th Street, Bellingham, WA 98225 Telephone: 360/676-3290 >>fax to SPIE at 360/647-1445 (Please send one submission per fax.) Be sure each abstract includes the following: 1. CONFERENCE CHAIR and CONFERENCE TITLE (submit to ONLY ONE conference) to which the abstract is submitted 2. AUTHOR LISTING (List principal author first) for each author: full name [first(given) last(family] and affiliation, mailing address, phone/fax numbers, email 3. ABSTRACT/PAPER TITLE 4. ABSTRACT TEXT: 500 words typed on white paper 5. KEYWORDS: maximum of 5 keywords 6. BRIEF BIOGRAPHY of the principal author: 50-100 words -- Taher Elgamal elgamal@netscape.com Chief Scientist, Netscape Communications (T) 415 937 2898, (F) 415 428 4054 Received: from relay.tis.com by neptune.TIS.COM id ab29341; 14 Jun 96 11:30 EDT Received: by relay.tis.com; id LAA06904; Fri, 14 Jun 1996 11:32:05 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma006900; Fri, 14 Jun 96 11:31:38 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01469; Fri, 14 Jun 96 11:31:39 EDT Received: by relay.tis.com; id LAA06893; Fri, 14 Jun 1996 11:31:36 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1) id xma006875; Fri, 14 Jun 96 11:31:12 -0400 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id IAA13692; Fri, 14 Jun 1996 08:33:42 -0700 Received: by mailsun2.us.oracle.com (8.7.1/37.8) id IAA14692; Fri, 14 Jun 1996 08:36:42 -0700 (PDT) Message-Id: <199606141536.IAA14692@mailsun2.us.oracle.com> Date: 13 Jun 96 21:05:57 -0700 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: Topics for IPsec Agenda Cc: sshannon@certicom.ca Mime-Version: 1.0 Sender: ipsec-approval@neptune.tis.com Precedence: bulk This is a final call to be on the June IPsec agenda! If you wish to be included on the agenda, please send me (palamber@us.oracle.com) e-mail that includes: 1) the words "IPsec Agenda" in the subject line ("Re:topics for IPsec Agenda" is all right), 2) the title of the topic(s), 3) name of presenter(s) (tentative is OK), 4) a topic description if the topic does not directly relate to one of the working group drafts, 5) estimate of the time you would like (no guarantees) and the 6) full name of the internet draft(s) that are covered by the presentation. Thanks for your help... it looks like we will have a very busy meeting! Paul -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com -------------------------------------------------------------- Received: from relay.tis.com by neptune.TIS.COM id aa02764; 14 Jun 96 14:48 EDT Received: by relay.tis.com; id OAA13096; Fri, 14 Jun 1996 14:50:16 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma013091; Fri, 14 Jun 96 14:49:47 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA11294; Fri, 14 Jun 96 14:49:49 EDT Received: by relay.tis.com; id OAA13086; Fri, 14 Jun 1996 14:49:46 -0400 Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay.tis.com via smap (V3.1.1) id xma013072; Fri, 14 Jun 96 14:49:16 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa18468; 14 Jun 96 9:56 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: ipsec@TIS.COM From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-ipsec-isakmp-oakley-00.txt Date: Fri, 14 Jun 96 09:56:53 -0400 Message-Id: <9606140956.aa18468@IETF.CNRI.Reston.VA.US> Sender: ipsec-approval@neptune.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The resolution of ISAKMP with Oakley Author(s) : D. Harkins, D. Carrel Filename : draft-ietf-ipsec-isakmp-oakley-00.txt Pages : 13 Date : 06/13/1996 [MSST96] (ISAKMP) provides a framework for authentication and key exchange but does not define them. ISAKMP is designed to be key exchange independant; that is, it is designed to support many different key exchanges. [Orm96] (Oakley) describes a series of key exchanges-- called "modes"-- and details the services provided by each (e.g. perfect forward secrecy for keys, identity protetion, and authentication). This document describes a proposal for using the Oakley Key Exchange Protocol in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP, and for other security associations such as AH and ESP for the ISAKMP Internet DOI. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-isakmp-oakley-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-oakley-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-oakley-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960613143749.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-oakley-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-oakley-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960613143749.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- Received: from relay.tis.com by neptune.TIS.COM id aa04573; 14 Jun 96 16:50 EDT Received: by relay.tis.com; id QAA15499; Fri, 14 Jun 1996 16:52:16 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma015495; Fri, 14 Jun 96 16:51:47 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20160; Fri, 14 Jun 96 16:51:49 EDT Received: by relay.tis.com; id QAA15489; Fri, 14 Jun 1996 16:51:46 -0400 Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay.tis.com via smap (V3.1.1) id xma015483; Fri, 14 Jun 96 16:51:19 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa19175; 14 Jun 96 10:05 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: ipsec@TIS.COM From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-ipsec-isakmp-05.txt, .ps Date: Fri, 14 Jun 96 10:05:06 -0400 Message-Id: <9606141005.aa19175@IETF.CNRI.Reston.VA.US> Sender: ipsec-approval@neptune.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Internet Security Association and Key Management Protocol (ISAKMP) Author(s) : D. Maughan, M. Schertler, M. Schneider, J. Turner Filename : draft-ietf-ipsec-isakmp-05.txt, .ps Pages : 80 Date : 06/13/1996 This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and cryptographic keys in an Internet environment. A Security Association protocol that negotiates, establishes, modifies and deletes Security Associations and their attributes is required for an evolving Internet, where there will be numerous security mechanisms and several options for each security mechanism. The key management protocol must be robust in order to handle public key generation for the Internet community at large and private key requirements for those private networks with that requirement. The Internet Security Association and Key Management Protocol (ISAKMP) defines the procedures for authenticating a communicating peer, creation and management of Security Associations, key generation techniques, and threat mitigation (e.g. denial of service and replay attacks). All of these are necessary to establish and maintain secure communications (via IP Security Service or any other security protocol) in an Internet environment. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-isakmp-05.txt". Or "get draft-ietf-ipsec-isakmp-05.ps". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-05.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-05.txt". Or "FILE /internet-drafts/draft-ietf-ipsec-isakmp-05.ps". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960613135102.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960613135102.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- Received: from relay.tis.com by neptune.TIS.COM id aa20713; 16 Jun 96 3:51 EDT Received: by relay.tis.com; id DAA25525; Sun, 16 Jun 1996 03:52:45 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma025523; Sun, 16 Jun 96 03:52:17 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16171; Sun, 16 Jun 96 03:52:17 EDT Received: by relay.tis.com; id DAA25520; Sun, 16 Jun 1996 03:52:15 -0400 Received: from unknown(192.114.26.219) by relay.tis.com via smap (V3.1.1) id xma025518; Sun, 16 Jun 96 03:51:46 -0400 Received: from radguard.com ([192.114.26.210]) by radmail.rad.co.il (post.office MTA v1.9.3 ID# 0-12126) with SMTP id AAA5807 for ; Sun, 16 Jun 1996 10:55:53 +0300 Received: by radguard.com (4.1/SMI-4.1) id AA16640; Sun, 16 Jun 96 10:54:32 IDT Received: from elgamal.radguard.co.il(192.114.33.2) by gatekeeper.radguard.com via smap (V1.3) id sma016638; Sun Jun 16 10:54:19 1996 Received: by elgamal.radguard.com (4.1/SMI-4.1) id AA23561; Sun, 16 Jun 96 10:54:56 IDT Date: Sun, 16 Jun 1996 10:54:56 +0300 (IDT) From: Dan Frommer To: ipsec@TIS.COM Subject: I-D ACTION:draft-frommer-sec-transform-00.txt (fwd) Message-Id: Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY=NextPart Content-Id: Sender: ipsec-approval@neptune.tis.com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --NextPart Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: ---------- Forwarded message ---------- Date: Fri, 14 Jun 96 09:57:28 -0400 From: Internet-Drafts@CNRI.Reston.VA.US To: IETF-Announce: ; Subject: I-D ACTION:draft-frommer-sec-transform-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The DES-CBC plus DES-MAC Security Transform Author(s) : D. Frommer Filename : draft-frommer-sec-transform-00.txt Pages : 10 Date : 06/13/1996 This document describes the use of DES-CBC for confidentiality plus DES Message Authentication Code (MAC) for integrity, in the IP Encapsulating Security Payload (ESP). The use of the DES algorithm for both purposes may serve useful in environments where hardware acceleration is available. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-frommer-sec-transform-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-frommer-sec-transform-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-frommer-sec-transform-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart-- Received: from relay.tis.com by neptune.TIS.COM id aa10413; 17 Jun 96 11:39 EDT Received: by relay.tis.com; id LAA09530; Mon, 17 Jun 1996 11:41:52 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma009524; Mon, 17 Jun 96 11:41:26 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16243; Mon, 17 Jun 96 11:41:24 EDT Received: by relay.tis.com; id LAA09519; Mon, 17 Jun 1996 11:41:22 -0400 Received: from border.com(199.71.190.98) by relay.tis.com via smap (V3.1.1) id xma009515; Mon, 17 Jun 96 11:41:08 -0400 Received: by janus.border.com id <18448-2>; Mon, 17 Jun 1996 11:42:41 -0400 Message-Id: <96Jun17.114241edt.18448-2@janus.border.com> To: ipsec@TIS.COM Subject: UUNET Network Encryption Patents From: "C. Harald Koch" Organization: Border Network Technologies Inc. Phone: +1 416 368 7157 X-Uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Mon, 17 Jun 1996 11:43:26 -0400 Sender: ipsec-approval@neptune.tis.com Precedence: bulk It has been brought to my attention that UUNET Technologies has a pair of patents covering network encryption. The patents are very broad, and basically cover anything that selectively encrypts datagrams based on source/destination information. This would automatically cover all implementations of the IPsec protocols. UUNET's legal staff have stated their intent to begin actively pursuing these patents, beginning this summer. It is my understanding that their licensing terms are quite reasonable. However, this patent has (obvious) implications for everyone here, and so I bring it to your attention. The patents are: 5,442,708 - Computer Network Encryption/Decryption Device Inventors: Richard L. Adams, Jr., Fairfax, Va.; Peter D. Hallenbeck, Elfland, N.C. Assignee: UUNET Techologies, Inc., Falls Church, Va. Appl. No: 305,509 Filed: Sep. 13, 1994 Related U.S. Application Data: Continuation of Ser. No. 28,437, Mar. 9, 1993, abandoned. 5,444,782 - Computer Network Encryption/Decryption Device Inventors: Richard L. Adams, Jr., Fairfax, Va.; Peter D. Hallenbeck, Elfland, N.C. Assignee: UUNET Techologies, Inc., Falls Church, Va. Appl. No: 184,631 Filed: Jan. 19, 1994 Related U.S. Application Data: Continuation of Ser. No. 28,437, Mar. 9, 1993, abandoned. -- C. Harald Koch | Border Network Technologies Inc. chk@border.com | Senior System Developer +1 416 368 7157 (voice) | 20 Toronto Street, Suite 400, Toronto ON M5C 2B8 +1 416 368 7789 (fax) | Madness takes its toll. Please have exact change. Received: from relay.tis.com by neptune.TIS.COM id aa12439; 17 Jun 96 13:33 EDT Received: by relay.tis.com; id NAA12484; Mon, 17 Jun 1996 13:34:57 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma012481; Mon, 17 Jun 96 13:34:32 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22971; Mon, 17 Jun 96 13:34:27 EDT Received: by relay.tis.com; id NAA12478; Mon, 17 Jun 1996 13:34:27 -0400 Received: from unknown(199.246.132.198) by relay.tis.com via smap (V3.1.1) id xma012476; Mon, 17 Jun 96 13:34:23 -0400 Received: by lacroix.wildbear.on.ca from localhost (router,SLmailNT V3.0 alpha 1); Mon, 17 Jun 96 13:35:33 Eastern Daylight Time Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLmailNT V3.0 alpha 1); Mon, 17 Jun 96 13:35:32 Eastern Daylight Time X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Jun 1996 13:35:22 -0400 To: "C. Harald Koch" , ipsec@TIS.COM From: Jack De Winter Subject: Re: UUNET Network Encryption Patents Message-Id: <19960617133533.00c6ce14.in@lacroix.wildbear.on.ca> Sender: ipsec-approval@neptune.tis.com Precedence: bulk >It has been brought to my attention that UUNET Technologies has a pair of >patents covering network encryption. The patents are very broad, and >basically cover anything that selectively encrypts datagrams based on >source/destination information. This would automatically cover all >implementations of the IPsec protocols. > >UUNET's legal staff have stated their intent to begin actively pursuing >these patents, beginning this summer. It is my understanding that their >licensing terms are quite reasonable. However, this patent has (obvious) >implications for everyone here, and so I bring it to your attention. would some kind member of the list be able to check into this and get some more detailed information as to the ramifications of this protocol in light of these patents? regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 576-3873 Lacroix: Well, I must be the devil to you. Nicolah: No, not the devil Lacroix. Lacroix: What then? Nicolah: My closest friend. In Memorium - Forever Knight, "Last Knight", Last Words. Received: from relay.tis.com by neptune.TIS.COM id aa13438; 17 Jun 96 14:18 EDT Received: by relay.tis.com; id OAA14053; Mon, 17 Jun 1996 14:20:39 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma014045; Mon, 17 Jun 96 14:20:13 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25700; Mon, 17 Jun 96 14:20:12 EDT Received: by relay.tis.com; id OAA14038; Mon, 17 Jun 1996 14:20:11 -0400 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1.1) id xma014016; Mon, 17 Jun 96 14:19:42 -0400 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.5/8.6.12) with SMTP id OAA19897; Mon, 17 Jun 1996 14:21:56 -0400 (EDT) Message-Id: <199606171821.OAA19897@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: "C. Harald Koch" Cc: ipsec@TIS.COM Subject: Re: UUNET Network Encryption Patents In-Reply-To: Your message of "Mon, 17 Jun 1996 11:43:26 EDT." <96Jun17.114241edt.18448-2@janus.border.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 17 Jun 1996 14:21:55 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk "C. Harald Koch" writes: > It has been brought to my attention that UUNET Technologies has a pair of > patents covering network encryption. The patents are very broad, and > basically cover anything that selectively encrypts datagrams based on > source/destination information. This would automatically cover all > implementations of the IPsec protocols. > > UUNET's legal staff have stated their intent to begin actively pursuing > these patents, beginning this summer. It is my understanding that their > licensing terms are quite reasonable. However, this patent has (obvious) > implications for everyone here, and so I bring it to your attention. The UUNET people did their work AFTER vast amounts of prior art was produced. Network layer encryption based on source/destination address goes back much further, and even products existed, from my memory, before then. Hell, blacker predates all of this. I also remember there having been work on this stuff ten years earlier by our own Steve Kent. I suspect this is the usual bad patent situation. If UUNET's legal staff try to pursue this, I hope that the industry very strongly stands up to them. Provided I am right on the prior art my own company will certainly do so. Perry Received: from relay.tis.com by neptune.TIS.COM id aa14399; 17 Jun 96 14:53 EDT Received: by relay.tis.com; id OAA14829; Mon, 17 Jun 1996 14:55:09 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma014807; Mon, 17 Jun 96 14:54:40 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28029; Mon, 17 Jun 96 14:54:39 EDT Received: by relay.tis.com; id OAA14804; Mon, 17 Jun 1996 14:54:39 -0400 Received: from bugs_bunny.columbia.sparta.com(157.185.80.205) by relay.tis.com via smap (V3.1.1) id xma014800; Mon, 17 Jun 96 14:54:32 -0400 Received: from [157.185.80.136] (blackbird.columbia.SPARTA.COM) by columbia.sparta.com (4.1/cfm-7-21-95) id AA25535; Mon, 17 Jun 96 14:56:50 EDT Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Jun 1996 14:56:59 -0400 To: "C. Harald Koch" From: "Carl F. Muckenhirn" Subject: Re: UUNET Network Encryption Patents Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk This should be interesting. I don't have the entire patent, but from the abstract (for 5,442,708) available from the USPTO: A computer network encryption/decryption device includes at least one microprocessor, microprocessor support hardware, at least two network ports for connecting to upstream and downstream networks, memory hardware for storing program, configuration, and keylist data, and data encryption/decryption hardware. Both network ports have the same network address, making the device transparent to the local area network in which it is spliced. The device operates by selectively encrypting or decrypting only the data portion of a data packet, leaving the routing information contained in the header and trailer portions of the data packet unchanged. 18 Claims, 10 Drawing Figures I would guess that the Private Line Interface (two KG-30s hooked to gether with a Lockheed SUE) evaluated in 1975, fielded 1976; BLACKER program (started 1978 worked through out the 80's, currently in production by Group Technologies), CANEWARE (fielded 1993); NES (basically commercial version of the CANEWARE) (fielded 1993, in production by Motorola), and many more developed and produced ***prior*** to the submission date of this patent are infringing. I guess that NSA and the fed government owe UUNET a bunch of money. (I don't think I have standing to challenge the patent, but I guess that Motorola and/or NSA would. And they probably have a stronger financial interest in seeing this dealt with.) carl. At 11:43 AM 6/17/96, C. Harald Koch wrote: >It has been brought to my attention that UUNET Technologies has a pair of >patents covering network encryption. The patents are very broad, and >basically cover anything that selectively encrypts datagrams based on >source/destination information. This would automatically cover all >implementations of the IPsec protocols. > >UUNET's legal staff have stated their intent to begin actively pursuing >these patents, beginning this summer. It is my understanding that their >licensing terms are quite reasonable. However, this patent has (obvious) >implications for everyone here, and so I bring it to your attention. > > >The patents are: > >5,442,708 - Computer Network Encryption/Decryption Device >Inventors: Richard L. Adams, Jr., Fairfax, Va.; > Peter D. Hallenbeck, Elfland, N.C. >Assignee: UUNET Techologies, Inc., Falls Church, Va. >Appl. No: 305,509 >Filed: Sep. 13, 1994 >Related U.S. Application Data: > Continuation of Ser. No. 28,437, Mar. 9, 1993, abandoned. > >5,444,782 - Computer Network Encryption/Decryption Device >Inventors: Richard L. Adams, Jr., Fairfax, Va.; > Peter D. Hallenbeck, Elfland, N.C. >Assignee: UUNET Techologies, Inc., Falls Church, Va. >Appl. No: 184,631 >Filed: Jan. 19, 1994 >Related U.S. Application Data: > Continuation of Ser. No. 28,437, Mar. 9, 1993, abandoned. > >-- >C. Harald Koch | Border Network Technologies Inc. >chk@border.com | Senior System Developer >+1 416 368 7157 (voice) | 20 Toronto Street, Suite 400, Toronto ON M5C 2B8 >+1 416 368 7789 (fax) | Madness takes its toll. Please have exact change. Received: from relay.tis.com by neptune.TIS.COM id aa15268; 17 Jun 96 15:32 EDT Received: by relay.tis.com; id PAA16609; Mon, 17 Jun 1996 15:34:44 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma016596; Mon, 17 Jun 96 15:34:19 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01424; Mon, 17 Jun 96 15:34:15 EDT Received: by relay.tis.com; id PAA16589; Mon, 17 Jun 1996 15:34:14 -0400 Received: from copilot.is.chrysler.com(204.189.94.36) by relay.tis.com via smap (V3.1.1) id xma016574; Mon, 17 Jun 96 15:33:55 -0400 Received: by pilotx.firewall.is.chrysler.com; id PAA09682; Mon, 17 Jun 1996 15:36:20 -0400 Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilotx.is.chrysler.com via smap (g3.0.1) id sma009680; Mon, 17 Jun 96 15:36:15 -0400 Received: from rgm3 by clhubgw1-nf0.is.chrysler.com (8.7.5/SMI-4.1) id PAA13343; Mon, 17 Jun 1996 15:39:31 -0400 (EDT) Message-Id: <2.2.32.19960617193358.009b339c@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Jun 1996 15:33:58 -0400 To: perry@piermont.com, "C. Harald Koch" From: Robert Moskowitz Subject: Re: UUNET Network Encryption Patents Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 02:21 PM 6/17/96 -0400, Perry E. Metzger wrote: >The UUNET people did their work AFTER vast amounts of prior art was >produced. Network layer encryption based on source/destination address >goes back much further, and even products existed, from my memory, >before then. Hell, blacker predates all of this. I also remember there >having been work on this stuff ten years earlier by our own Steve Kent. Yeah, I'd suspect that there is an earlier patent :) I'm feeling a little perverse today. Been one of those mondays. Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.tis.com by neptune.TIS.COM id aa15745; 17 Jun 96 15:50 EDT Received: by relay.tis.com; id PAA17880; Mon, 17 Jun 1996 15:52:33 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma017853; Mon, 17 Jun 96 15:52:03 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02404; Mon, 17 Jun 96 15:52:02 EDT Received: by relay.tis.com; id PAA17843; Mon, 17 Jun 1996 15:52:01 -0400 Received: from unknown(194.30.193.159) by relay.tis.com via smap (V3.1.1) id xma017829; Mon, 17 Jun 96 15:51:52 -0400 Hops: 0 Host: tis.com. Received: from del.tla.org (ppp86.hol.gr [194.30.192.198]) by prometheus.hol.gr (8.7.4/8.7.3) with ESMTP id WAA18580 for ; Mon, 17 Jun 1996 22:51:29 -0200 (GMT) Posted-Date: Mon, 17 Jun 1996 22:51:29 -0200 (GMT) Received: from del.tla.org (localhost.tla.org [127.0.0.1]) by del.tla.org (8.7.2/8.6.9) with ESMTP id WAA22601 for ; Mon, 17 Jun 1996 22:53:47 +0300 (EET DST) Message-Id: <199606171953.WAA22601@del.tla.org> X-Mailer: exmh version 1.6.2 7/18/95 To: ipsec@TIS.COM Subject: Re: UUNET Network Encryption Patents In-Reply-To: Your message of "Mon, 17 Jun 1996 11:43:26 EDT." <96Jun17.114241edt.18448-2@janus.border.com> Reply-To: ji@hol.gr Organization: La maison qui rend fou. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Jun 1996 22:53:46 +0300 From: John Ioannidis Sender: ipsec-approval@neptune.tis.com Precedence: bulk There is enough prior art on the subject that I don't see what they are going to get other than a lot of bad will from the community. Anyone from uunet care to comment? /ji Received: from relay.tis.com by neptune.TIS.COM id aa17616; 17 Jun 96 17:05 EDT Received: by relay.tis.com; id RAA22484; Mon, 17 Jun 1996 17:07:38 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma022465; Mon, 17 Jun 96 17:07:09 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06657; Mon, 17 Jun 96 17:07:09 EDT Received: by relay.tis.com; id RAA22461; Mon, 17 Jun 1996 17:07:08 -0400 Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay.tis.com via smap (V3.1.1) id xma022446; Mon, 17 Jun 96 17:06:45 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa25231; 17 Jun 96 14:24 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: ipsec@TIS.COM From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-ipsec-esp-des-md5-02.txt Date: Mon, 17 Jun 96 14:24:18 -0400 Message-Id: <9606171424.aa25231@IETF.CNRI.Reston.VA.US> Sender: ipsec-approval@neptune.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Combined DES-CBC, HMAC and Replay Prevention Security Transform Author(s) : J. Hughes Filename : draft-ietf-ipsec-esp-des-md5-02.txt Pages : 12 Date : 06/14/1996 This draft describes a combination of privacy, authentication, integrity and replay prevention into a single packet format. This document is the result of significant work by several major contributors and the IPsec working group as a whole. These contributors, cited later in this document, provided many of the key technical details summarized in this document. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-esp-des-md5-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-esp-des-md5-02.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-esp-des-md5-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960614143700.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-des-md5-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-des-md5-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960614143700.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- Received: from relay.tis.com by neptune.TIS.COM id aa18103; 17 Jun 96 17:31 EDT Received: by relay.tis.com; id RAA24066; Mon, 17 Jun 1996 17:33:53 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma024047; Mon, 17 Jun 96 17:33:25 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA07533; Mon, 17 Jun 96 17:33:24 EDT Received: by relay.tis.com; id RAA24040; Mon, 17 Jun 1996 17:33:23 -0400 Received: from hosaka.smallworks.com(192.207.126.1) by relay.tis.com via smap (V3.1.1) id xma024034; Mon, 17 Jun 96 17:33:19 -0400 Received: from butthead.SmallWorks.COM by hosaka.smallworks.com (5.x/SMI-SVR4) id AA04698; Mon, 17 Jun 1996 16:35:42 -0500 Received: by butthead.SmallWorks.COM (4.1/SPARCbook_POP1.3) id AA09764; Mon, 17 Jun 96 16:31:41 CDT From: Jim Thompson Message-Id: <9606171631.ZM9762@butthead.smallworks.com> Date: Mon, 17 Jun 1996 16:31:40 -0500 In-Reply-To: "Carl F. Muckenhirn" "Re: UUNET Network Encryption Patents" (Jun 17, 2:56pm) References: X-Mailer: Z-Mail (3.2.1 10oct95) To: "Carl F. Muckenhirn" , "C. Harald Koch" Subject: Re: UUNET Network Encryption Patents Cc: ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipsec-approval@neptune.tis.com Precedence: bulk I'm not an IP lawyer (though we have one who works here), but this > Both network ports have the same network address, making the device transparent > to the local area network in which it is spliced. The device operates by > selectively encrypting or decrypting only the data portion of a data packet, > leaving the routing information contained in the header and trailer portions > of the data packet unchanged. Would seem to leave IPsec in the free and clear (so to speak.) Jim Received: from relay.tis.com by neptune.TIS.COM id aa18745; 17 Jun 96 18:08 EDT Received: by relay.tis.com; id SAA25300; Mon, 17 Jun 1996 18:10:01 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma025291; Mon, 17 Jun 96 18:09:32 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08710; Mon, 17 Jun 96 18:09:31 EDT Received: by relay.tis.com; id SAA25288; Mon, 17 Jun 1996 18:09:31 -0400 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1.1) id xma025286; Mon, 17 Jun 96 18:09:22 -0400 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.5/8.6.12) with SMTP id SAA20222; Mon, 17 Jun 1996 18:11:33 -0400 (EDT) Message-Id: <199606172211.SAA20222@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Jim Thompson Cc: "Carl F. Muckenhirn" , "C. Harald Koch" , ipsec@TIS.COM Subject: Re: UUNET Network Encryption Patents In-Reply-To: Your message of "Mon, 17 Jun 1996 16:31:40 CDT." <9606171631.ZM9762@butthead.smallworks.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 17 Jun 1996 18:11:30 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Jim Thompson writes: > I'm not an IP lawyer (though we have one who works here), but this > > > Both network ports have the same network address, making the > > device> transparent to the local area network in which it is > > spliced. The device operates by selectively encrypting or > > decrypting only the data portion of a data packet, leaving the > > routing information contained in the header and trailer portions > > of the data packet unchanged. > > Would seem to leave IPsec in the free and clear (so to speak.) Not in Virtual Private Network applications. It doesn't matter, though. The patents are invalid on their face. None of this is new technology -- this stuff is all very old. Prior art fully invalidates a patent. .pm Received: from relay.tis.com by neptune.TIS.COM id aa18848; 17 Jun 96 18:13 EDT Received: by relay.tis.com; id SAA25401; Mon, 17 Jun 1996 18:15:31 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma025395; Mon, 17 Jun 96 18:15:02 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08816; Mon, 17 Jun 96 18:15:01 EDT Received: by relay.tis.com; id SAA25392; Mon, 17 Jun 1996 18:15:01 -0400 Received: from bugs_bunny.columbia.sparta.com(157.185.80.205) by relay.tis.com via smap (V3.1.1) id xma025387; Mon, 17 Jun 96 18:14:59 -0400 Received: from [157.185.80.136] (blackbird.columbia.SPARTA.COM) by columbia.sparta.com (4.1/cfm-7-21-95) id AA26876; Mon, 17 Jun 96 18:17:06 EDT Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Jun 1996 18:17:21 -0400 To: Jim Thompson From: "Carl F. Muckenhirn" Subject: Re: UUNET Network Encryption Patents Cc: "Carl F. Muckenhirn" , "C. Harald Koch" , ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 4:31 PM 6/17/96, Jim Thompson wrote: >I'm not an IP lawyer (though we have one who works here), but this > >> Both network ports have the same network address, making the device >transparent >> to the local area network in which it is spliced. The device operates by >> selectively encrypting or decrypting only the data portion of a data packet, >> leaving the routing information contained in the header and trailer portions >> of the data packet unchanged. > >Would seem to leave IPsec in the free and clear (so to speak.) > >Jim Pointing this out reminds me of a "non-military" application. The "Bump in the Stack Encryptor" by Steve Bellovin (et al, I just can't remember who al is). A few years back provides exactly this functionality. carl. Received: from relay.tis.com by neptune.TIS.COM id aa19600; 17 Jun 96 18:53 EDT Received: by relay.tis.com; id SAA25797; Mon, 17 Jun 1996 18:55:04 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma025795; Mon, 17 Jun 96 18:54:35 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA09918; Mon, 17 Jun 96 18:54:34 EDT Received: by relay.tis.com; id SAA25790; Mon, 17 Jun 1996 18:54:34 -0400 Received: from hosaka.smallworks.com(192.207.126.1) by relay.tis.com via smap (V3.1.1) id xma025786; Mon, 17 Jun 96 18:54:31 -0400 Received: from butthead.SmallWorks.COM by hosaka.smallworks.com (5.x/SMI-SVR4) id AA05155; Mon, 17 Jun 1996 17:57:00 -0500 Received: by butthead.SmallWorks.COM (4.1/SPARCbook_POP1.3) id AA10068; Mon, 17 Jun 96 17:52:58 CDT From: Jim Thompson Message-Id: <9606171752.ZM10066@butthead.smallworks.com> Date: Mon, 17 Jun 1996 17:52:58 -0500 In-Reply-To: "Perry E. Metzger" "Re: UUNET Network Encryption Patents" (Jun 17, 6:11pm) References: <199606172211.SAA20222@jekyll.piermont.com> X-Mailer: Z-Mail (3.2.1 10oct95) To: perry@piermont.com Subject: Re: UUNET Network Encryption Patents Cc: "C. Harald Koch" , "Carl F. Muckenhirn" , ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipsec-approval@neptune.tis.com Precedence: bulk Jim Thompson writes: > I'm not an IP lawyer (though we have one who works here), but this > > > > > Both network ports have the same network address, making the > > > device transparent to the local area network in which it is > > > spliced. The device operates by selectively encrypting or > > > decrypting only the data portion of a data packet, leaving the > > > routing information contained in the header and trailer portions > > > of the data packet unchanged. > > > > Would seem to leave IPsec in the free and clear (so to speak.) > > Not in Virtual Private Network applications. Both network ports have the same address? Local area network? > It doesn't matter, though. The patents are invalid on their face. None > of this is new technology -- this stuff is all very old. Prior art > fully invalidates a patent. Perry, it just ain't true that 'prior art fully invalidates a patent'. (I've just had a discussion with that IP lawyer we have on-staff here.) Prior art is a defense to litigation, its true, but it doesn't invalidate a patent. The only way to invalidate a patent is to ask for re-examination e.g. go back to the PTO, file an application for re-examination of the patent, pay the fee (I think its $1000.00 US), and wait. This is an one-shot process. After you've filed the re-examination form, the original holder of the patent gets to go in and point out why their patent is still valid. You (and your friends, lawyers, etc) don't get to participate. You're only told of the outcome. The most famous invalidation via this mechanism of late was the Compton Multimedia patent. Unless you make this happen, you basically have to wait until you are sued, and use prior art as a defense to the suit. Even then, until you get the case decided in your favor at the Court of Appeals level, the case can be litigated over 100 times, with different results. (I think there are 105 different district courts, and in patent cases, they don't listen to what each other decide (precidence.) This will probably cost you over $1000 in legal fees. Jim Received: from relay.tis.com by neptune.TIS.COM id aa19782; 17 Jun 96 19:00 EDT Received: by relay.tis.com; id TAA25991; Mon, 17 Jun 1996 19:02:20 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma025948; Mon, 17 Jun 96 19:01:45 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10106; Mon, 17 Jun 96 19:01:42 EDT Received: by relay.tis.com; id TAA25924; Mon, 17 Jun 1996 19:01:40 -0400 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1.1) id xma025854; Mon, 17 Jun 96 19:01:17 -0400 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.5/8.6.12) with SMTP id TAA20325; Mon, 17 Jun 1996 19:03:47 -0400 (EDT) Message-Id: <199606172303.TAA20325@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Jim Thompson Cc: ipsec@TIS.COM Subject: Re: UUNET Network Encryption Patents In-Reply-To: Your message of "Mon, 17 Jun 1996 17:52:58 CDT." <9606171752.ZM10066@butthead.smallworks.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 17 Jun 1996 19:03:47 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk "Jim Thompson" writes: > > It doesn't matter, though. The patents are invalid on their face. None > > of this is new technology -- this stuff is all very old. Prior art > > fully invalidates a patent. > > Perry, it just ain't true that 'prior art fully invalidates a patent'. (I've > just had a discussion with that IP lawyer we have on-staff here.) > > Prior art is a defense to litigation, its true, but it doesn't invalidate a > patent. > > The only way to invalidate a patent is to ask for re-examination The distinction is unimportant for purposes of this discussion. .pm Received: from relay.tis.com by neptune.TIS.COM id aa23292; 17 Jun 96 23:25 EDT Received: by relay.tis.com; id XAA28044; Mon, 17 Jun 1996 23:27:45 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma028040; Mon, 17 Jun 96 23:27:16 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA14591; Mon, 17 Jun 96 23:27:15 EDT Received: by relay.tis.com; id XAA28035; Mon, 17 Jun 1996 23:27:15 -0400 Received: from servo.qualcomm.com(129.46.128.14) by relay.tis.com via smap (V3.1.1) id xma028031; Mon, 17 Jun 96 23:27:06 -0400 Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id UAA02531; Mon, 17 Jun 1996 20:29:33 -0700 (PDT) Date: Mon, 17 Jun 1996 20:29:33 -0700 (PDT) From: Phil Karn Message-Id: <199606180329.UAA02531@servo.qualcomm.com> To: chk@border.com Cc: ipsec@TIS.COM In-Reply-To: <96Jun17.114241edt.18448-2@janus.border.com> (chk@border.com) Subject: Re: UUNET Network Encryption Patents Sender: ipsec-approval@neptune.tis.com Precedence: bulk >Filed: Sep. 13, 1994 >Filed: Jan. 19, 1994 All the basic concepts of IP Security (especially including what we now call "tunnel mode") have been widely and publicly known since at least the original "lunch BOF" that I called at the San Diego IETF meeting way back in 1992. So the validity of these patents is not only seriously in doubt, but there is also the interesting question of fraud against the PTO for not disclosing all known relevant prior art. Phil Received: from relay.tis.com by neptune.TIS.COM id aa23691; 18 Jun 96 0:01 EDT Received: by relay.tis.com; id AAA28217; Tue, 18 Jun 1996 00:03:15 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma028214; Tue, 18 Jun 96 00:02:46 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA15153; Tue, 18 Jun 96 00:02:45 EDT Received: by relay.tis.com; id AAA28208; Tue, 18 Jun 1996 00:02:45 -0400 Received: from servo.qualcomm.com(129.46.128.14) by relay.tis.com via smap (V3.1.1) id xma028201; Tue, 18 Jun 96 00:02:16 -0400 Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id VAA02652; Mon, 17 Jun 1996 21:04:39 -0700 (PDT) Date: Mon, 17 Jun 1996 21:04:39 -0700 (PDT) From: Phil Karn Message-Id: <199606180404.VAA02652@servo.qualcomm.com> To: jim@smallworks.com Cc: perry@piermont.com, chk@border.com, cfm@columbia.sparta.com, ipsec@TIS.COM In-Reply-To: <9606171752.ZM10066@butthead.smallworks.com> (message from Jim Thompson on Mon, 17 Jun 1996 17:52:58 -0500) Subject: Re: UUNET Network Encryption Patents Sender: ipsec-approval@neptune.tis.com Precedence: bulk >The most famous invalidation via this mechanism of late was the Compton >Multimedia patent. Actually, the Compton Multimedia re-examination was initiated by the Patent Commissioner as opposed to a request for re-examination. I'm told this is an extremely rare event. I also understand that some changes to the re-examination procedures are pending in some bills in Congress at the moment. Phil Received: from relay.tis.com by neptune.TIS.COM id aa24609; 18 Jun 96 1:23 EDT Received: by relay.tis.com; id BAA28661; Tue, 18 Jun 1996 01:25:15 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma028659; Tue, 18 Jun 96 01:24:47 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16266; Tue, 18 Jun 96 01:24:45 EDT Received: by relay.tis.com; id BAA28656; Tue, 18 Jun 1996 01:24:45 -0400 Received: from hosaka.smallworks.com(192.207.126.1) by relay.tis.com via smap (V3.1.1) id xma028654; Tue, 18 Jun 96 01:24:43 -0400 Received: from butthead.SmallWorks.COM by hosaka.smallworks.com (5.x/SMI-SVR4) id AA06618; Tue, 18 Jun 1996 00:27:15 -0500 Received: by butthead.SmallWorks.COM (4.1/SPARCbook_POP1.3) id AA11636; Tue, 18 Jun 96 00:23:13 CDT From: Jim Thompson Message-Id: <9606180023.ZM11634@butthead.smallworks.com> Date: Tue, 18 Jun 1996 00:23:13 -0500 In-Reply-To: Phil Karn "Re: UUNET Network Encryption Patents" (Jun 17, 8:29pm) References: <199606180329.UAA02531@servo.qualcomm.com> X-Mailer: Z-Mail (3.2.1 10oct95) To: Phil Karn , chk@border.com Subject: Re: UUNET Network Encryption Patents Cc: ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipsec-approval@neptune.tis.com Precedence: bulk On Jun 17, 8:29pm, Phil Karn wrote: > Subject: Re: UUNET Network Encryption Patents > >Filed: Sep. 13, 1994 > >Filed: Jan. 19, 1994 > > All the basic concepts of IP Security (especially including what we > now call "tunnel mode") have been widely and publicly known since at > least the original "lunch BOF" that I called at the San Diego IETF > meeting way back in 1992. So the validity of these patents is not > only seriously in doubt, but there is also the interesting question of > fraud against the PTO for not disclosing all known relevant prior art. > > Phil > > >-- End of excerpt from Phil Karn When the IETF last met in Washington D.C. (I think that was the summer of 1992), there was a lunch where you, I, ji, and someone else where as far as I know, the original discussion of using ji's IPIP with encryption (e.g. tunnel-mode) was discussed. JI had mentioned something similar when I was visiting him at Columbia several months prior to this. In addition: ftp.cs.columbia.edu:pub/ji/swipe-26ietf.ps is dated Apr 8, 1993. ftp.cs.columbia.edu:pub/ji/usenix-sec93.ps.Z is dated Aug 18, 1993. ftp.cs.columbia.edu:pub/ji/swipeusenix.ps is dated Sep 21, 1993. Jim Received: from relay.tis.com by neptune.TIS.COM id aa03256; 18 Jun 96 11:07 EDT Received: by relay.tis.com; id LAA06804; Tue, 18 Jun 1996 11:09:18 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma006792; Tue, 18 Jun 96 11:08:56 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02372; Tue, 18 Jun 96 11:08:48 EDT Received: by relay.tis.com; id LAA06763; Tue, 18 Jun 1996 11:08:45 -0400 Received: from ns.newbridge.com(192.75.23.67) by relay.tis.com via smap (V3.1.1) id xma006740; Tue, 18 Jun 96 11:08:21 -0400 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id LAA07134 for ; Tue, 18 Jun 1996 11:10:51 -0400 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma007103; Tue Jun 18 11:10:21 1996 Received: from thor.ca.newbridge.com (thor121.ca.newbridge.com [138.120.121.43]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with ESMTP id LAA10947 for ; Tue, 18 Jun 1996 11:10:17 -0400 Received: (from bretth@localhost) by thor.ca.newbridge.com (8.6.12/8.6.12) id LAA19636 for ipsec@tis.com; Tue, 18 Jun 1996 11:10:16 -0400 Date: Tue, 18 Jun 1996 11:10:16 -0400 From: Brett Howard Message-Id: <199606181510.LAA19636@thor.ca.newbridge.com> To: ipsec@TIS.COM Subject: ISAKMP null transforms Sender: ipsec-approval@neptune.tis.com Precedence: bulk In my understanding of ISAKMP, the proposal for ESP and AH are sent as a list in order of preference. Does it not make sense to define "null" transform? The rationale is this: Suppose I wish to convey to my pier that I would like to communicate with no AH; however, I am capable of communicating using an MD5 AH, or, say SHA-1 AH. As it is now, I don't see how to propose this. I can propose no AH transforms (true?), in which case my pier gets the wrong message since it will think I *cannot* speak MD5; or I can propose MD5 and SHA-1 which again conveys the wrong message, since I'd really prefer no AH (and how would this be differentiated from the case where I will not accept anything less than, say, MD5?). Note that this applies equally to ESP as it does to AH. I believe being able to propose a "null" transform in each list could solve this. Have I missed something? Thanks! Brett Received: from relay.tis.com by neptune.TIS.COM id aa04399; 18 Jun 96 12:04 EDT Received: by relay.tis.com; id LAA08037; Tue, 18 Jun 1996 11:52:42 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma008032; Tue, 18 Jun 96 11:52:17 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA04788; Tue, 18 Jun 96 11:52:12 EDT Received: by relay.tis.com; id LAA08024; Tue, 18 Jun 1996 11:52:12 -0400 Received: from unknown(199.71.190.98) by relay.tis.com via smap (V3.1.1) id xma008019; Tue, 18 Jun 96 11:52:04 -0400 Received: by janus.border.com id <18450-2>; Tue, 18 Jun 1996 11:53:33 -0400 Message-Id: <96Jun18.115333edt.18450-2@janus.border.com> To: ipsec@TIS.COM Subject: Re: UUNET Network Encryption Patents References: <199606180329.UAA02531@servo.qualcomm.com> <9606180023.ZM11634@butthead.smallworks.com> In-Reply-To: jim's message of "Tue, 18 Jun 1996 01:23:13 -0400". <9606180023.ZM11634@butthead.smallworks.com> From: "C. Harald Koch" Date: Tue, 18 Jun 1996 11:51:20 -0400 Sender: ipsec-approval@neptune.tis.com Precedence: bulk > > Subject: Re: UUNET Network Encryption Patents > > >Filed: Sep. 13, 1994 > > >Filed: Jan. 19, 1994 The patent also states "continuation-in-part of Ser. No. 28,437, Mar 3, 1993, abandoned"; this is the important "first date", according to the lawyers. The papers below are after this date, and won't count as prior art. (Anyone from that lunch BOF want to testify? ) [ ObDisclaimer: I don't represent BNTi or SCC in a legal sense; I'm just a software developer ... ] > ftp.cs.columbia.edu:pub/ji/swipe-26ietf.ps is dated Apr 8, 1993. > ftp.cs.columbia.edu:pub/ji/usenix-sec93.ps.Z is dated Aug 18, 1993. > ftp.cs.columbia.edu:pub/ji/swipeusenix.ps is dated Sep 21, 1993. -- C. Harald Koch | Border Network Technologies Inc. chk@border.com | Senior System Developer +1 416 368 7157 (voice) | 20 Toronto Street, Suite 400, Toronto ON M5C 2B8 +1 416 368 7789 (fax) | Madness takes its toll. Please have exact change. Received: from relay.tis.com by neptune.TIS.COM id aa07034; 18 Jun 96 14:16 EDT Received: by relay.tis.com; id OAA12174; Tue, 18 Jun 1996 14:18:41 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma012157; Tue, 18 Jun 96 14:18:14 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA15512; Tue, 18 Jun 96 14:18:12 EDT Received: by relay.tis.com; id OAA12150; Tue, 18 Jun 1996 14:18:12 -0400 Received: from hubbub.cisco.com(198.92.30.31) by relay.tis.com via smap (V3.1.1) id xma012139; Tue, 18 Jun 96 14:17:41 -0400 Received: from spook (dharkins-ss20.cisco.com [171.69.60.241]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with ESMTP id LAA24634; Tue, 18 Jun 1996 11:23:29 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by spook (8.6.8+c/CISCO.WS.1.1) with SMTP id LAA03123; Tue, 18 Jun 1996 11:20:15 -0700 Message-Id: <199606181820.LAA03123@spook> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Brett Howard Cc: ipsec@TIS.COM Subject: Re: ISAKMP null transforms In-Reply-To: Your message of "Tue, 18 Jun 1996 11:10:16 EDT." <199606181510.LAA19636@thor.ca.newbridge.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Jun 1996 11:20:14 -0700 From: Daniel Harkins Sender: ipsec-approval@neptune.tis.com Precedence: bulk > In my understanding of ISAKMP, the proposal for ESP and AH are sent as a > list in order of preference. Does it not make sense to define "null" > transform? The rationale is this: > > Suppose I wish to convey to my pier that I would like to communicate > with no AH; however, I am capable of communicating using an MD5 AH, > or, say SHA-1 AH. There are 2 negotiations taking place with ISAKMP. The first is to protect ISAKMP-to-ISAKMP traffic; the second is to negotiate one or more security associations like AH and ESP under the protection of the policy negotiated in the first phase. The first phase of negotiation doesn't use AH or ESP. Encryption and authentication are negotiated and subsequently used, but the AH _header_ and ESP _header_ are never sent as part of an ISAKMP payload. You would never want to negotiate a null here. All ISAKMP exchanges require authentication; you must negotiate it. (The Authentication Only exchange does not encrypt the traffic but it still authenticates the two parties). If your question relates to the second phase of negoatiation then I'm a bit confused. If you don't want to do a transform I don't understand why you need ISAKMP to announce that fact. Just don't negotiate a transform. It says nothing about your ability just your intent. > As it is now, I don't see how to propose this. I can propose no > AH transforms (true?), in which case my pier gets the wrong message > since it will think I *cannot* speak MD5; or I can propose MD5 and SHA-1 > which again conveys the wrong message, since I'd really prefer no AH (and > how would this be differentiated from the case where I will not accept > anything less than, say, MD5?). I don't see the problem here. If you don't want to do AH you shouldn't worry about your peer getting any message about your ability to do it. The only thing your peer cares about is what you intend on doing-- how you intend on communicating. The second phase of negotiation establishes security associations. There is no such thing as a "null" security association. You can't do AH with nothing, same for ESP. Dan. Received: from relay.tis.com by neptune.TIS.COM id aa08141; 18 Jun 96 15:08 EDT Received: by relay.tis.com; id PAA13544; Tue, 18 Jun 1996 15:10:10 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma013539; Tue, 18 Jun 96 15:09:48 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA17922; Tue, 18 Jun 96 15:09:41 EDT Received: by relay.tis.com; id PAA13533; Tue, 18 Jun 1996 15:09:40 -0400 Received: from mn3.swip.net(192.71.180.33) by relay.tis.com via smap (V3.1.1) id xma013526; Tue, 18 Jun 96 15:09:13 -0400 Received: by mn3.swip.net (8.7.5/2.01) id SAA09134; Tue, 18 Jun 1996 18:59:56 GMT Received: from desmond.sectra.se by jeeves.sectra.se (4.1/KTH-1.1+Sectra-1.4) id AA04968; Tue, 18 Jun 96 20:45:03 +0200 Received: by desmond.sectra.se (1.38.193.5/HP=16.2/Sectra=0.1) id AA24642; Tue, 18 Jun 1996 20:44:36 +0200 From: Per Unell Message-Id: <9606182044.ZM24640@desmond.sectra.se> Date: Tue, 18 Jun 1996 20:44:36 +0000 References: <199606180329.UAA02531@servo.qualcomm.com> <9606180023.ZM11634@butthead.smallworks.com> <96Jun18.115333edt.18450-2@janus.border.com> X-Mailer: Z-Mail (3.2.0 06sep94) To: ipsec@TIS.COM Subject: Re: UUNET Network Encryption Patents Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipsec-approval@neptune.tis.com Precedence: bulk On Jun 18, 11:51am, C. Harald Koch wrote: > Subject: Re: UUNET Network Encryption Patents > > > Subject: Re: UUNET Network Encryption Patents > > > >Filed: Sep. 13, 1994 > > > >Filed: Jan. 19, 1994 > > The patent also states "continuation-in-part of Ser. No. 28,437, Mar 3, > 1993, abandoned"; this is the important "first date", according to the > lawyers. The papers below are after this date, and won't count as prior art. > > (Anyone from that lunch BOF want to testify? ) > I Just looked up the oldest version of the requirement specification for our KryptoLan system that I could find. It is dated May. 27 1991 and includes IP and Ethernet encryption and is based on the IEEE 802.10 Draft 1 dated december 1989. Sure beats 1993 ... /PU Received: from relay.tis.com by neptune.TIS.COM id aa09552; 18 Jun 96 16:14 EDT Received: by relay.tis.com; id QAA15709; Tue, 18 Jun 1996 16:16:48 -0400 From: pau@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma015694; Tue, 18 Jun 96 16:16:16 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21053; Tue, 18 Jun 96 16:16:14 EDT Received: by relay.tis.com; id QAA15688; Tue, 18 Jun 1996 16:16:14 -0400 Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1.1) id xma015683; Tue, 18 Jun 96 16:16:11 -0400 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id QAA10598 for ; Tue, 18 Jun 1996 16:19:05 -0400 Received: from secpwr.watson.ibm.com (secpwr.watson.ibm.com [9.2.24.17]) by mailhub1.watson.ibm.com (8.7.1/03-28-96) with SMTP id QAA35165; Tue, 18 Jun 1996 16:17:17 -0400 Received: by secpwr.watson.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA22378; Tue, 18 Jun 1996 16:22:52 -0400 Date: Tue, 18 Jun 1996 16:22:52 -0400 Message-Id: <9606182022.AA22378@secpwr.watson.ibm.com> To: ipsec@TIS.COM Subject: adding port number to ISAKMP Internet DOI ID's Cc: hugo@watson.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: CnmK5Ig8iN6hW/vIGfwJWw== Sender: ipsec-approval@neptune.tis.com Precedence: bulk I would like to suggest adding port number and protocol as an option field to ISAKMP Internet DOI ID's. The field could be sent together with a IPv4 or IPv6 address. The address:port:protocol ID can be used as IDui or IDur during proxy negotiation. I think this feature is useful for per-user or per-connection keying. Say, when a user wishes to secure a particular connection. Pau-Chen Disclaimer: This message is NOT intended to re-ignite the debate on per-user keying. Personally, I like to see all communication secured with one secure tunnel whose keys are frequently refreshed. But I have encountered much more than one request for per-user/connection keying (Which means some packets can be unprotected.). In any case, I think the cost of adding the field is small. So I suggest ISAKMP provide this flexibility. A responder can always refuse such a request. Received: from relay.tis.com by neptune.TIS.COM id aa09754; 18 Jun 96 16:26 EDT Received: by relay.tis.com; id QAA16183; Tue, 18 Jun 1996 16:28:14 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma016165; Tue, 18 Jun 96 16:27:45 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21604; Tue, 18 Jun 96 16:27:44 EDT Received: by relay.tis.com; id QAA16162; Tue, 18 Jun 1996 16:27:44 -0400 Received: from ns.newbridge.com(192.75.23.67) by relay.tis.com via smap (V3.1.1) id xma016146; Tue, 18 Jun 96 16:27:14 -0400 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id QAA23289; Tue, 18 Jun 1996 16:29:41 -0400 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma023267; Tue Jun 18 16:29:30 1996 Received: from thor.ca.newbridge.com (thor121.ca.newbridge.com [138.120.121.43]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with ESMTP id QAA24142; Tue, 18 Jun 1996 16:29:29 -0400 Received: (from bretth@localhost) by thor.ca.newbridge.com (8.6.12/8.6.12) id QAA05194; Tue, 18 Jun 1996 16:29:27 -0400 Date: Tue, 18 Jun 1996 16:29:27 -0400 From: Brett Howard Message-Id: <199606182029.QAA05194@thor.ca.newbridge.com> To: bretth@ca.newbridge.com, dharkins@cisco.com Subject: Re: ISAKMP null transforms Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Dan, >I don't see the problem here. If you don't want to do AH you shouldn't worry >about your peer getting any message about your ability to do it. The only >thing your peer cares about is what you intend on doing-- how you intend >on communicating. Well, I'm not sure I agree. When I send a list of transforms in some order, I implicitly state both a list of capabilities (all members on the list) and an ordering of preferences. Not "wanting" to do AH doesn't imply that I'm not "willing" to do it should my peer deem it necessary. I would like to say "I'd prefer no AH, but here's what I'll accept in order of preference: blah blah". > The second phase of negotiation establishes security associations. There is >no such thing as a "null" security association. You can't do AH with nothing, >same for ESP. > > Dan True, but I'm suggesting that an accepted "null" AH proposal would be identical to accepting a proposal with no AH. Cheers, Brett Received: from relay.tis.com by neptune.TIS.COM id aa11319; 18 Jun 96 17:52 EDT Received: by relay.tis.com; id RAA18399; Tue, 18 Jun 1996 17:54:31 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma018394; Tue, 18 Jun 96 17:54:03 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA24622; Tue, 18 Jun 96 17:54:01 EDT Received: by relay.tis.com; id RAA18391; Tue, 18 Jun 1996 17:54:01 -0400 Received: from border.com(199.71.190.98) by relay.tis.com via smap (V3.1.1) id xma018386; Tue, 18 Jun 96 17:53:46 -0400 Received: by janus.border.com id <18433-2>; Tue, 18 Jun 1996 17:55:30 -0400 Message-Id: <96Jun18.175530edt.18433-2@janus.border.com> To: Brett Howard Cc: dharkins@cisco.com, ipsec@TIS.COM Subject: Re: ISAKMP null transforms References: <199606182029.QAA05194@thor.ca.newbridge.com> In-Reply-To: bretth's message of "Tue, 18 Jun 1996 16:29:27 -0400". <199606182029.QAA05194@thor.ca.newbridge.com> From: "C. Harald Koch" Organization: Border Network Technologies Inc. Phone: +1 416 368 7157 X-Uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Tue, 18 Jun 1996 17:56:21 -0400 Sender: ipsec-approval@neptune.tis.com Precedence: bulk In message <199606182029.QAA05194@thor.ca.newbridge.com>, Brett Howard writes: > > Well, I'm not sure I agree. When I send a list of transforms in some > order, I implicitly state both a list of capabilities (all members > on the list) and an ordering of preferences. Not "wanting" to do > AH doesn't imply that I'm not "willing" to do it should my peer deem > it necessary. I would like to say "I'd prefer no AH, but here's > what I'll accept in order of preference: blah blah". Um, this may be a silly idea, but could we steal some ideas from the PPP option negotiation mechanisms here? -- C. Harald Koch | Border Network Technologies Inc. chk@border.com | Senior System Developer +1 416 368 7157 (voice) | 20 Toronto Street, Suite 400, Toronto ON M5C 2B8 +1 416 368 7789 (fax) | Madness takes its toll. Please have exact change. Received: from relay.tis.com by neptune.TIS.COM id aa11656; 18 Jun 96 18:11 EDT Received: by relay.tis.com; id SAA18896; Tue, 18 Jun 1996 18:13:02 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma018887; Tue, 18 Jun 96 18:12:34 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25377; Tue, 18 Jun 96 18:12:32 EDT Received: by relay.tis.com; id SAA18875; Tue, 18 Jun 1996 18:12:32 -0400 Received: from toad.com(140.174.2.1) by relay.tis.com via smap (V3.1.1) id xma018868; Tue, 18 Jun 96 18:12:26 -0400 Received: from localhost (localhost [127.0.0.1]) by toad.com (8.7.5/8.7.3) with SMTP id PAA01406; Tue, 18 Jun 1996 15:14:44 -0700 (PDT) Message-Id: <199606182214.PAA01406@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: ipsec@TIS.COM, gnu@toad.com Subject: Re: UUNET Network Encryption Patents In-Reply-To: <9606182044.ZM24640@desmond.sectra.se> Date: Tue, 18 Jun 1996 15:14:36 -0700 From: John Gilmore Sender: ipsec-approval@neptune.tis.com Precedence: bulk I mentioned the subject to Rick Adams, the patent holder. He says that if anyone has actual prior art, they'll drop the claim. But it has to be real prior art in the patent context, not just rumors or speculation by people who don't know much about patents. (Such rumors aren't enough to be worth bothering Rick with, but might lead a patent-aware person to info good enough to send to him.) To invalidate the patent, the prior art needs to be prior to March 1992; what counts is the filing date of the original application, not the grant date. Uunet started work on this sometime in late 1991. Per Unell said: > I Just looked up the oldest version of the requirement specification > for our KryptoLan system that I could find. It is dated May. 27 1991 > and includes IP and Ethernet encryption and is based on the IEEE > 802.10 Draft 1 dated december 1989. You're OK on the date. Was this "reqirement spec" a public document? Then the question is how many of the patent's claims it mentions. Somebody should get the patent texts and figures and put them online. Rick said: > ... remember that a combination of publically available pieces is > patentable as a whole, even if the individual components are not. > > The key component is the decision to encrypt being made on a per > packet basis based on the contents of the header of the packet. I'm > fairly sure that Blacker did not allow unencrypted traffic to be > mixed with encrypted traffic on the same network interface. > ... > I'll be happy to look at any well thought out argument, but I'm not going to > do the digging. Comments like "I'm sure Blacker invalidates this" are too > ambiguous to chase down. We can feel free to chase such comments down and provide better info, if we want. John Received: from relay.tis.com by neptune.TIS.COM id aa12133; 18 Jun 96 18:44 EDT Received: by relay.tis.com; id SAA19600; Tue, 18 Jun 1996 18:46:22 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma019591; Tue, 18 Jun 96 18:45:54 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA26605; Tue, 18 Jun 96 18:45:53 EDT Received: by relay.tis.com; id SAA19584; Tue, 18 Jun 1996 18:45:52 -0400 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1.1) id xma019572; Tue, 18 Jun 96 18:45:21 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id PAA25376; Tue, 18 Jun 1996 15:47:54 -0700 Date: Tue, 18 Jun 1996 15:47:54 -0700 From: Ran Atkinson Message-Id: <199606182247.PAA25376@puli.cisco.com> To: ipsec@TIS.COM Subject: Re: keying styles In-Reply-To: <9606182022.AA22378@secpwr.watson.ibm.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: Sender: ipsec-approval@neptune.tis.com Precedence: bulk In article <9606182022.AA22378@secpwr.watson.ibm.com> Pau-Chen wrote: >Disclaimer: This message is NOT intended to re-ignite the debate on > per-user keying. Personally, I like to see all communication > secured with one secure tunnel whose keys are frequently refreshed. > But I have encountered much more than one request > for per-user/connection keying (Which means some packets > can be unprotected.). In any case, I think the > cost of adding the field is small. So I suggest ISAKMP provide > this flexibility. A responder can always refuse such a request. DISCLAIMER: I also do not seek to re-ignite a heated debate Unlike Pau-Chen, I don't see user-oriented and host-oriented keying as mutually exclusive. For example, the NRL implementation has always permitted a system admin to require that all outgoing traffic be encrypted (e.g. using some keying strategy, with some traffic possibly using a host-oriented key) while also having user-oriented keying in use for sessions having such keys. In other words, an implementation can (and NRL's always has) permit some sessions on a system to use user-oriented keying while other sessions on the same system share a host-oriented key. The keying strategies need not be mutually exclusive. By mandating that "everything must be encrypted" as a policy in the "system security level" variable then all packets are guaranteed to be protected even while some sessions might be using host-oriented keying and other sessions might be using user-oriented keying at the same time. See the NRL implementation for a working example. Ran rja@cisco.com Received: from relay.tis.com by neptune.TIS.COM id aa12307; 18 Jun 96 18:56 EDT Received: by relay.tis.com; id SAA19815; Tue, 18 Jun 1996 18:58:22 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma019806; Tue, 18 Jun 96 18:57:55 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27001; Tue, 18 Jun 96 18:57:53 EDT Received: by relay.tis.com; id SAA19793; Tue, 18 Jun 1996 18:57:52 -0400 Received: from hubbub.cisco.com(198.92.30.31) by relay.tis.com via smap (V3.1.1) id xma019776; Tue, 18 Jun 96 18:57:26 -0400 Received: from spook (dharkins-ss20.cisco.com [171.69.60.241]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with ESMTP id QAA23010; Tue, 18 Jun 1996 16:03:14 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by spook (8.6.8+c/CISCO.WS.1.1) with SMTP id PAA03364; Tue, 18 Jun 1996 15:32:27 -0700 Message-Id: <199606182232.PAA03364@spook> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Brett Howard Cc: ipsec@TIS.COM Subject: Re: ISAKMP null transforms In-Reply-To: Your message of "Tue, 18 Jun 1996 16:29:27 EDT." <199606182029.QAA05194@thor.ca.newbridge.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Jun 1996 15:32:27 -0700 From: Daniel Harkins Sender: ipsec-approval@neptune.tis.com Precedence: bulk Brett, >>I don't see the problem here. If you don't want to do AH you shouldn't worry >>about your peer getting any message about your ability to do it. The only >>thing your peer cares about is what you intend on doing-- how you intend >>on communicating. > >Well, I'm not sure I agree. When I send a list of transforms in some >order, I implicitly state both a list of capabilities (all members >on the list) and an ordering of preferences. Not "wanting" to do >AH doesn't imply that I'm not "willing" to do it should my peer deem >it necessary. I would like to say "I'd prefer no AH, but here's >what I'll accept in order of preference: blah blah". Ok. You don't want to do AH. I assume you want to do something though or else why go through the motions. So, let's say you want to do ESP without AH (a bad idea, but for the sake of discussion, let's say that you do). To do this you send a proposal for esp transform of "RFC-1829" followed by a proposal for esp transform of "DES-CBC-HMAC-replay". If the receiver's local policy accepts unauthenticated but encrypted packets he'll accept the 1st-- your preferred transform. If he doesn't, he'll accept the 2nd-- your "rather not but will..." transform. The implicit order of preference can be used to tell the receiver what you'd like to do, what you'll settle for, and what is a last resort, or any other graduation you can think of. >> The second phase of negotiation establishes security associations. There is >>no such thing as a "null" security association. You can't do AH with nothing, >>same for ESP. >> > >True, but I'm suggesting that an accepted "null" AH proposal would be >identical to accepting a proposal with no AH. Why obfuscate things with a "null" proposal? You don't want AH, then don't put it in the proposal. Or do you see some distinction between a proposal without AH and a proposal with a "null AH" specified? As a receiver, should I view those two differently? Dan. Received: from relay.tis.com by neptune.TIS.COM id aa14803; 18 Jun 96 21:45 EDT Received: by relay.tis.com; id VAA21947; Tue, 18 Jun 1996 21:47:38 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma021940; Tue, 18 Jun 96 21:47:09 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA00995; Tue, 18 Jun 96 21:47:08 EDT Received: by relay.tis.com; id VAA21937; Tue, 18 Jun 1996 21:47:08 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1) id xma021935; Tue, 18 Jun 96 21:46:39 -0400 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id SAA22956; Tue, 18 Jun 1996 18:49:13 -0700 Received: by mailsun2.us.oracle.com (8.7.1/37.8) id SAA01090; Tue, 18 Jun 1996 18:52:34 -0700 (PDT) Message-Id: <199606190152.SAA01090@mailsun2.us.oracle.com> Date: 18 Jun 96 18:11:26 -0700 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: Network Layer Encryption History and Prior Art Cc: JHAVERTY@us.oracle.com X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-approval@neptune.tis.com's message of 17-Jun-96 20:29 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Boundary-5452247-0-0 Sender: ipsec-approval@neptune.tis.com Precedence: bulk --Boundary-5452247-0-0 Phil, Approching for network layer encryption have been openly published before the work in the IETF. ... in reference to the UUNET patent on network encryption >All the basic concepts of IP Security (especially >including what we now call "tunnel mode") have been >widely and publicly known since at least the original >"lunch BOF" that I called at the San Diego IETF >meeting way back in 1992. The research and development of "Network Security" started in the late 70's at BBN with the development of the "IPLI". Classified research and development continued in this area on the Blacker (Unisys) and Caneware (Motorola) programs in the early 80's. The NSA sponsored Secure Data Network System (SDNS) project brought together a variety of vendors that created the early SP3, KMP and MSP specifications. SP3 provided network layer security services that included a tunneling mode. SP3 is very similar to the IPsec working group ESP specification. The Key Management Protocol (KMP) is similar to the ISAKMP specification in concept, but used ASN.1 for specifying the protocol formats. Much of the SDNS work was openly published starting in about 1988. The Motorola Network Encryption System (NES) is an SDNS device and was designed in the mid to late 80's. The SDNS specification for SP3 was submitted to the ANSI and ISO standards committees and mutated into the Network Layer Security Protocol (NLSP). NLSP included a network layer key establishment protocol that served as a starting point for some of the current IPsec key management proposals. An important early paper on network security was written by Dave Golber (Unisys at the time) on the "Dual versus Single Catenet Security Model" (about 1983). There are a variety of SP3 security papers written in 1988 and 1989. So, there is a lot of prior art for network encryption. Most of the major wrinkles in the technology were worked out in the late 80's by projects sponsored by the NSA and openly published to help create "good" security standards. Paul -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com -------------------------------------------------------------- --Boundary-5452247-0-0 Content-Type: message/rfc822 Date: 17 Jun 96 20:29:33 From:"Phil Karn " To: chk@border.com Subject: Re: UUNET Network Encryption Patents Cc: ipsec@tis.com X-Orcl-Application: In-Reply-To: <96Jun17.114241edt.18448-2@janus.border.com> (chk@border.com) X-Orcl-Application: Sender: ipsec-approval@neptune.tis.com X-Orcl-Application: Precedence: bulk >Filed: Sep. 13, 1994 >Filed: Jan. 19, 1994 All the basic concepts of IP Security (especially including what we now call "tunnel mode") have been widely and publicly known since at least the original "lunch BOF" that I called at the San Diego IETF meeting way back in 1992. So the validity of these patents is not only seriously in doubt, but there is also the interesting question of fraud against the PTO for not disclosing all known relevant prior art. Phil --Boundary-5452247-0-0-- Received: from relay.tis.com by neptune.TIS.COM id aa15280; 18 Jun 96 22:20 EDT Received: by relay.tis.com; id WAA22192; Tue, 18 Jun 1996 22:22:38 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma022187; Tue, 18 Jun 96 22:22:09 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01596; Tue, 18 Jun 96 22:22:08 EDT Received: by relay.tis.com; id WAA22184; Tue, 18 Jun 1996 22:22:08 -0400 Received: from south-station-annex.mit.edu(18.72.1.2) by relay.tis.com via smap (V3.1.1) id xma022182; Tue, 18 Jun 96 22:21:51 -0400 Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA08588; Tue, 18 Jun 96 22:22:38 EDT Received: by dcl.MIT.EDU (5.x/4.7) id AA07109; Tue, 18 Jun 1996 22:24:18 -0400 Date: Tue, 18 Jun 1996 22:24:18 -0400 Message-Id: <9606190224.AA07109@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "PALAMBER.US.ORACLE.COM" Cc: ipsec@TIS.COM, JHAVERTY@us.oracle.com, gnu@toad.com In-Reply-To: PALAMBER.US.ORACLE.COM's message of 18 Jun 96 18:11:26 -0700, <199606190152.SAA01090@mailsun2.us.oracle.com> Subject: Re: Network Layer Encryption History and Prior Art Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: ipsec-approval@neptune.tis.com Precedence: bulk Date: 18 Jun 96 18:11:26 -0700 From: "PALAMBER.US.ORACLE.COM" The research and development of "Network Security" started in the late 70's at BBN with the development of the "IPLI". Classified research and development continued in this area on the Blacker (Unisys) and Caneware (Motorola) programs in the early 80's. The NSA sponsored Secure Data Network System (SDNS) project brought together a variety of vendors that created the early SP3, KMP and MSP specifications. SP3 provided network layer security services that included a tunneling mode. SP3 is very similar to the IPsec working group ESP specification. The Key Management Protocol (KMP) is similar to the ISAKMP specification in concept, but used ASN.1 for specifying the protocol formats. Much of the SDNS work was openly published starting in about 1988. The Motorola Network Encryption System (NES) is an SDNS device and was designed in the mid to late 80's. Paul, thanks for the history lesson!! John (Gilmore), is this what you were looking for in terms of real Prior Art to take to Rick Adams, so he'll drop the patent claims? The SP3 specifications should hopefully be detailed enough to satisfy a Patent Attorney as being Real Prior Art in the Patent Context. The only question is whether or not there's enough there to take out all of the claims in UUNET's patent (or at least enough so that IPSEC won't be have to worry about infringing the UUNET patent.) - Ted Received: from relay.tis.com by neptune.TIS.COM id aa18621; 19 Jun 96 3:45 EDT Received: by relay.tis.com; id DAA24714; Wed, 19 Jun 1996 03:47:25 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma024707; Wed, 19 Jun 96 03:46:56 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA07014; Wed, 19 Jun 96 03:46:55 EDT Received: by relay.tis.com; id DAA24701; Wed, 19 Jun 1996 03:46:54 -0400 Received: from toad.com(140.174.2.1) by relay.tis.com via smap (V3.1.1) id xma024697; Wed, 19 Jun 96 03:46:39 -0400 Received: from localhost (localhost [127.0.0.1]) by toad.com (8.7.5/8.7.3) with SMTP id AAA08542; Wed, 19 Jun 1996 00:49:11 -0700 (PDT) Message-Id: <199606190749.AAA08542@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: ipsec@TIS.COM, gnu@toad.com Subject: Re: Network Layer Encryption History and Prior Art In-Reply-To: <9606190224.AA07109@dcl.MIT.EDU> Date: Wed, 19 Jun 1996 00:49:11 -0700 From: John Gilmore Sender: ipsec-approval@neptune.tis.com Precedence: bulk > John (Gilmore), is this what you were looking for in terms of real Prior > Art to take to Rick Adams, so he'll drop the patent claims? Nope, these are *pointers to* prior art. Somebody (who understand patentese) needs to read the patents, and then read the actual published materials that Paul is mentioning. If any of them cover features that are specifically claimed by the Uunet patents, then there's a chance that they count as "prior art". (I'm not up on exactly what qualifies as prior art.) We would send the source documents to Rick or his lawyer, pointing out the prior inventions. If we get documents enough to mention ALL the claims from the Uunet patents, then the patents will cease to be a problem. Recall that Rick says the important feature is encrypting some packets, based on their header information, while letting others go through unencrypted. I don't think any of the SDNS stuff that I saw mentioned such ideas; they assumed you *did* want to encrypt and explained the encrypted protocol. Perhaps some of the implementations of these NSA protocols supported mixed encrypted/unencrypted traffic, though. Their manuals might be valid prior art, if ordinary mortals could have obtained them by 1991. John Received: from relay.tis.com by neptune.TIS.COM id aa21610; 19 Jun 96 7:53 EDT Received: by relay.tis.com; id HAA26688; Wed, 19 Jun 1996 07:55:05 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma026686; Wed, 19 Jun 96 07:54:37 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA12124; Wed, 19 Jun 96 07:54:36 EDT Received: by relay.tis.com; id HAA26680; Wed, 19 Jun 1996 07:54:35 -0400 Received: from pilot.is.chrysler.com(204.189.94.35) by relay.tis.com via smap (V3.1.1) id xma026677; Wed, 19 Jun 96 07:54:18 -0400 Received: by pilot.firewall.is.chrysler.com; id HAA00099; Wed, 19 Jun 1996 07:56:47 -0400 Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilot.is.chrysler.com via smap (g3.0.1) id sma001934; Wed, 19 Jun 96 07:53:22 -0400 Received: from rgm3 by clhubgw1-nf0.is.chrysler.com (8.7.5/SMI-4.1) id HAA07563; Wed, 19 Jun 1996 07:56:39 -0400 (EDT) Message-Id: <2.2.32.19960619115039.00b5a7f0@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Jun 1996 07:50:39 -0400 To: John Gilmore , ipsec@TIS.COM, gnu@toad.com From: Robert Moskowitz Subject: Re: UUNET Network Encryption Patents Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 03:14 PM 6/18/96 -0700, John Gilmore wrote: > >Rick said: > >> ... >> I'll be happy to look at any well thought out argument, but I'm not going to >> do the digging. Comments like "I'm sure Blacker invalidates this" are too >> ambiguous to chase down. Sounds like the Rick Adams of old. Good to see that success has not spoiled him ;) Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.tis.com by neptune.TIS.COM id aa22463; 19 Jun 96 8:47 EDT Received: by relay.tis.com; id IAA27606; Wed, 19 Jun 1996 08:49:06 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma027569; Wed, 19 Jun 96 08:48:37 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA14995; Wed, 19 Jun 96 08:48:36 EDT Received: by relay.tis.com; id IAA27560; Wed, 19 Jun 1996 08:48:35 -0400 Received: from ns.newbridge.com(192.75.23.67) by relay.tis.com via smap (V3.1.1) id xma027554; Wed, 19 Jun 96 08:48:32 -0400 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id IAA20838; Wed, 19 Jun 1996 08:51:04 -0400 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma020832; Wed Jun 19 08:50:34 1996 Received: from thor.ca.newbridge.com (thor121.ca.newbridge.com [138.120.121.43]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with ESMTP id IAA17963; Wed, 19 Jun 1996 08:50:31 -0400 Received: (from bretth@localhost) by thor.ca.newbridge.com (8.6.12/8.6.12) id IAA27908; Wed, 19 Jun 1996 08:50:29 -0400 Date: Wed, 19 Jun 1996 08:50:29 -0400 From: Brett Howard Message-Id: <199606191250.IAA27908@thor.ca.newbridge.com> To: bretth@ca.newbridge.com, dharkins@cisco.com Subject: Re: ISAKMP null transforms Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Dan, >Why obfuscate things with a "null" proposal? You don't want AH, then don't >put it in the proposal. Or do you see some distinction between a proposal >without AH and a proposal with a "null AH" specified? As a receiver, should >I view those two differently? > > Dan. Yes you can treat them differently since the "null" proposal *allows* you to follow with a second and third choice for AH; the proposal without AH does not. For example, I propose, in order: "null", HMAC-MD5, HMAC-SHA The receiver knows that I'd prefer no AH, but if it *requires* an authentication header, at least it now has the option of choosing ones I support; in the "without AH" proposal it does not since I cannot tell it which I support. Maybe my example would have been better flipped around. My security policy demands that I support authentication, but not confidentiality. I will, however, gladly support ESP transforms should my peer require it. I propose: AH: HMAC-MD5 ESP: "null", rfc1829, rfc1851 ...again, my partner may choose to accept "no ESP transform", or choose confidentiality with DES-CBC or triple-DES since I offered them. Note that I am not including a "null" here for AH, since I am not willing to offer that option as dictated by my policy. Cheers! Brett Received: from relay.tis.com by neptune.TIS.COM id aa22785; 19 Jun 96 8:59 EDT Received: by relay.tis.com; id JAA28090; Wed, 19 Jun 1996 09:01:35 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma028083; Wed, 19 Jun 96 09:01:08 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA15873; Wed, 19 Jun 96 09:01:07 EDT Received: by relay.tis.com; id JAA28074; Wed, 19 Jun 1996 09:01:06 -0400 Received: from guardian.guard.ncsc.mil(144.51.52.1) by relay.tis.com via smap (V3.1.1) id xma028066; Wed, 19 Jun 96 09:00:57 -0400 Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id JAA03716 for ; Wed, 19 Jun 1996 09:03:40 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma003714; Wed Jun 19 09:03:21 1996 Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id IAA03587 for ; Wed, 19 Jun 1996 08:59:47 -0400 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id JAA00806; Wed, 19 Jun 1996 09:03:05 -0400 Date: Wed, 19 Jun 1996 09:03:05 -0400 From: "David P. Kemp" Message-Id: <199606191303.JAA00806@argon.ncsc.mil> To: ipsec@TIS.COM Subject: Re: ISAKMP null transforms X-Sun-Charset: US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk > Ok. You don't want to do AH. I assume you want to do something though or > else why go through the motions. So, let's say you want to do ESP without > AH (a bad idea, but for the sake of discussion, let's say that you do). > >True, but I'm suggesting that an accepted "null" AH proposal would be > >identical to accepting a proposal with no AH. > > Why obfuscate things with a "null" proposal? You don't want AH, then don't > put it in the proposal. Or do you see some distinction between a proposal > without AH and a proposal with a "null AH" specified? As a receiver, should > I view those two differently? I understand Brett's question, but don't understand the answer. Let's say, for the sake of discussion, that your policy is that you require integrity protection (AH), but that you would prefer not to encrypt but are capable of encryption if the peer requires it. Shouldn't it be legitimate to request: AH-alg1 (ESP-null, ESP-alg1, ESP-alg2) The difference to the receiver is that in one case (no ESP proposed) no connection will be established, and in the other case (ESP list as shown above) it will (assuming either alg1 or alg2 are acceptable to the receiver). The benefit of the null capability is that if both peers prefer no encryption (but do require AH), they can establish an AH-only connection without the overhead of encryption. Yet each of them are also able to establish encrypted connections with different peers, if those other peers require it. Forgive me for not understanding if this can be accomplished in some other way. Received: from relay.tis.com by neptune.TIS.COM id aa23100; 19 Jun 96 9:09 EDT Received: by relay.tis.com; id JAA28498; Wed, 19 Jun 1996 09:11:36 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma028489; Wed, 19 Jun 96 09:11:09 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16442; Wed, 19 Jun 96 09:11:07 EDT Received: by relay.tis.com; id JAA28479; Wed, 19 Jun 1996 09:11:06 -0400 Received: from bugs_bunny.columbia.sparta.com(157.185.80.205) by relay.tis.com via smap (V3.1.1) id xma028468; Wed, 19 Jun 96 09:11:03 -0400 Received: from katahdin.columbia.sparta.com by columbia.sparta.com (4.1/cfm-7-21-95) id AA03624; Wed, 19 Jun 96 09:13:34 EDT Received: by katahdin.columbia.sparta.com (5.61/SMI-4.1) id AA06918; Wed, 19 Jun 96 09:13:32 -0400 From: Howard Weiss Message-Id: <9606191313.AA06918@katahdin.columbia.sparta.com> Subject: Re: Network Layer Encryption History and Prior Art To: ipsec@TIS.COM Date: Wed, 19 Jun 1996 09:13:31 -0400 (EDT) In-Reply-To: <9606190224.AA07109@dcl.MIT.EDU> from "Theodore Y. Ts'o" at Jun 18, 96 10:24:18 pm Organization: SPARTA Inc. (Secure Systems Engineering Division) Usmail: 9861 Broken Land Parkway, Suite 300, Columbia MD 21046 Phone: (410) 381-9400 x201 Fax: (410) 381-5559 X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2276 Sender: ipsec-approval@neptune.tis.com Precedence: bulk > > Date: 18 Jun 96 18:11:26 -0700 > From: "PALAMBER.US.ORACLE.COM" > > The research and development of "Network Security" started in the > late 70's at BBN with the development of the "IPLI". Classified > research and development continued in this area on the Blacker > (Unisys) and Caneware (Motorola) programs in the early 80's. The NSA > sponsored Secure Data Network System (SDNS) project brought together > a variety of vendors that created the early SP3, KMP and MSP > specifications. SP3 provided network layer security services that > included a tunneling mode. SP3 is very similar to the IPsec working > group ESP specification. The Key Management Protocol (KMP) is > similar to the ISAKMP specification in concept, but used ASN.1 for > specifying the protocol formats. Much of the SDNS work was openly > published starting in about 1988. The Motorola Network Encryption > System (NES) is an SDNS device and was designed in the mid to late > 80's. > Actually, the PLI (Private Line Interface) was developed by BBN in the early '70s. The IPLI was to be its "modern" successor. It consisted of a classified-side (red) processor, a KG-30 encryption box, and an unclassified-side (black) processor. It was evaluated and certified by NSA around late-1975 or early-1976. Its function was to allow classified traffic to flow, encrypted, over the ARPAnet. This meant, at the time, that ARPAnet NCP headers remained in the clear while the data payload was encrypted. COINS (Consolidated On-line Intelligence Network) used the PLI to connect a distant node via the ARPAnet in order to save the line charges for the then, very expensive 50KB lines. Howie Weiss ________________________________________________________________________ | | | Howard Weiss phone (410) 381-9400 x201 | | SPARTA, Inc. (301) 621-8145 x201 (DC)| | 9861 Broken Land Parkway, suite 300 fax: (410) 381-5559 | | Columbia, MD 21046 email: hsw@columbia.sparta.com| |________________________________________________________________________| Received: from relay.tis.com by neptune.TIS.COM id aa23707; 19 Jun 96 9:26 EDT Received: by relay.tis.com; id JAA29088; Wed, 19 Jun 1996 09:28:15 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma029081; Wed, 19 Jun 96 09:27:51 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA17502; Wed, 19 Jun 96 09:27:48 EDT Received: by relay.tis.com; id JAA29074; Wed, 19 Jun 1996 09:27:45 -0400 Received: from unknown(205.158.3.34) by relay.tis.com via smap (V3.1.1) id xma029070; Wed, 19 Jun 96 09:27:30 -0400 Received: from jhaverty ([205.158.209.33]) by SanMateo01.POP.InterNex.Net (post.office MTA v1.9.1 ID# 0-11029) with SMTP id AAA26274; Wed, 19 Jun 1996 06:29:54 -0700 Message-Id: <2.2.32.19960619132701.006b2ff8@SanMateo01.pop.internex.net> X-Sender: oracle1-11@SanMateo01.pop.internex.net X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Jun 1996 06:27:01 -0700 To: palamber@us.oracle.com From: Jack Haverty Subject: Re: Auto-forward: Re: Network Layer Encryption History and Prior Art Cc: tytso@mit.edu, ipsec@TIS.COM, gnu@toad.com Sender: ipsec-approval@neptune.tis.com Precedence: bulk Actually, it started even before that. The PLI (Private Line Interface), documented as an appendix in BBN Report 1822 (How to Connect a Host to an IMP), was the predecessor to the IPLI (which was the version that had to work on the Internet with TCP/IP as it evolved from the Arpanet with the original NCP protocol). /Jack >Date: 18 Jun 96 19:24:34 >From:"Theodore Y. Ts'o" >To: PALAMBER@us.oracle.com >Subject: Re: Network Layer Encryption History and Prior Art >Cc: ipsec@TIS.COM,JHAVERTY@us.oracle.com,gnu@toad.com >X-Orcl-Application: In-Reply-To: PALAMBER.US.ORACLE.COM's message of 18 Jun 96 18:11:26 -0700, >X-Orcl-Application: In-Reply-To: <199606190152.SAA01090@mailsun2.us.oracle.com> >X-Orcl-Application: Address: 1 Amherst St., Cambridge, MA 02139 >X-Orcl-Application: Phone: (617) 253-8091 > > > Date: 18 Jun 96 18:11:26 -0700 > From: "PALAMBER.US.ORACLE.COM" > > The research and development of "Network Security" started in the > late 70's at BBN with the development of the "IPLI". Classified > research and development continued in this area on the Blacker > (Unisys) and Caneware (Motorola) programs in the early 80's. The NSA > sponsored Secure Data Network System (SDNS) project brought together > a variety of vendors that created the early SP3, KMP and MSP > specifications. SP3 provided network layer security services that > included a tunneling mode. SP3 is very similar to the IPsec working > group ESP specification. The Key Management Protocol (KMP) is > similar to the ISAKMP specification in concept, but used ASN.1 for > specifying the protocol formats. Much of the SDNS work was openly > published starting in about 1988. The Motorola Network Encryption > System (NES) is an SDNS device and was designed in the mid to late > 80's. > >Paul, thanks for the history lesson!! > >John (Gilmore), is this what you were looking for in terms of real Prior >Art to take to Rick Adams, so he'll drop the patent claims? The SP3 >specifications should hopefully be detailed enough to satisfy a Patent >Attorney as being Real Prior Art in the Patent Context. The only >question is whether or not there's enough there to take out all of the >claims in UUNET's patent (or at least enough so that IPSEC won't be have >to worry about infringing the UUNET patent.) > > - Ted > > Jack Haverty Internet Products Group Oracle Corporation jhaverty@oracle1.xo.com 415-506-2942 Received: from relay.tis.com by neptune.TIS.COM id aa24105; 19 Jun 96 9:40 EDT Received: by relay.tis.com; id JAA29330; Wed, 19 Jun 1996 09:42:16 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma029325; Wed, 19 Jun 96 09:41:46 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18078; Wed, 19 Jun 96 09:41:46 EDT Received: by relay.tis.com; id JAA29322; Wed, 19 Jun 1996 09:41:45 -0400 Received: from ns.research.att.com(192.20.225.4) by relay.tis.com via smap (V3.1.1) id xma029310; Wed, 19 Jun 96 09:41:31 -0400 Received: from research.research.att.com by ns; Wed Jun 19 09:42:15 EDT 1996 Received: from raptor.research.att.com by research; Wed Jun 19 09:37:51 EDT 1996 Received: from research.att.com (localhost.research.att.com [127.0.0.1]) by raptor.research.att.com (8.7.5/8.7) with ESMTP id JAA28224; Wed, 19 Jun 1996 09:37:50 -0400 (EDT) Message-Id: <199606191337.JAA28224@raptor.research.att.com> To: John Gilmore Cc: ipsec@TIS.COM Subject: Re: UUNET Network Encryption Patents Date: Wed, 19 Jun 1996 09:37:50 -0400 From: Steven Bellovin Sender: ipsec-approval@neptune.tis.com Precedence: bulk A paper of mine might be relevant: %A S.M. Bellovin %T Pseudo-Network Drivers and Virtual Networks %P 229-244 %I USENIX %B USENIX Conference Proceedings %D January 22-26, 1990 %C Washington, D.C. %W AT&T Bell Laboratories It's available as ftp://ftp.research.att.com/dist/smb/pnet.ext.ps.Z. The part of interest is the discussion of the ``Greyer'' encryption system (which I never actually built, though at the time I'd intended to). The paper speaks of using the routing table (i.e., the destination address) to send packets for particular destinations to what we'd now call a tunnel driver; the packets would then be encrypted and reinjected. My design was very consciously modeled on both BLACKER and SP3, and both designs are cited in the bibliography. I'll say more after I've read the claims in the UUNET patents. Received: from relay.tis.com by neptune.TIS.COM id aa25070; 19 Jun 96 10:32 EDT Received: by relay.tis.com; id KAA00899; Wed, 19 Jun 1996 10:33:34 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma000892; Wed, 19 Jun 96 10:33:05 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21057; Wed, 19 Jun 96 10:33:04 EDT Received: by relay.tis.com; id KAA00883; Wed, 19 Jun 1996 10:33:04 -0400 Received: from dave.bbn.com(128.89.4.237) by relay.tis.com via smap (V3.1.1) id xma000860; Wed, 19 Jun 96 10:32:36 -0400 Received: from maggie.bbn.com (MAGGIE.BBN.COM [128.33.225.199]) by dave.bbn.com (8.6.9/150.200.504) with SMTP id KAA08607; Wed, 19 Jun 1996 10:34:53 -0400 Message-Id: <2.2.32.19960619142927.006bb9a4@dave.bbn.com> X-Sender: jlowry@dave.bbn.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Jun 1996 10:29:27 -0400 To: Jack Haverty From: John Lowry Subject: Re: Auto-forward: Re: Network Layer Encryption History and Prior Art Cc: palamber@us.oracle.com, tytso@mit.edu, ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk I was the last project leader for IPLI and I still have one in my office. (Kind of booring without a mate - or a pair of KG-84s !) Many of the IPLI reports were unclassified FOUO and delivered to (D)ARPA. Would any of these constitute "public" documents for the purposes of establishing prior art ? If so, then perhaps DARPA would consent to release some or all ? John Lowry At 06:27 AM 6/19/96 -0700, Jack Haverty wrote: >Actually, it started even before that. The PLI (Private Line Interface), >documented as an appendix in BBN Report 1822 (How to Connect a Host to an >IMP), was the predecessor to the IPLI (which was the version that had to >work on the Internet with TCP/IP as it evolved from the Arpanet with the >original NCP protocol). > >/Jack > ... John Lowry jlowry@bbn.com (617)873-2435 Received: from relay.tis.com by neptune.TIS.COM id aa25548; 19 Jun 96 10:55 EDT Received: by relay.tis.com; id KAA02132; Wed, 19 Jun 1996 10:57:25 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma002119; Wed, 19 Jun 96 10:57:11 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22302; Wed, 19 Jun 96 10:57:09 EDT Received: by relay.tis.com; id KAA02087; Wed, 19 Jun 1996 10:57:02 -0400 Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1.1) id xma002067; Wed, 19 Jun 96 10:56:36 -0400 Received: from [128.89.0.110] (COMSEC.BBN.COM [128.89.0.110]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id LAA21139; Wed, 19 Jun 1996 11:02:00 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Jun 1996 10:59:39 +0100 To: John Gilmore From: Stephen Kent Subject: Re: Network Layer Encryption History and Prior Art Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Folks, As one who participated somewhat more directly in the history of this, let me refine some of Paul's comments. The first packet encryptor was the PLI (not IPLI) developed in the early 70s by BBN under DARPA funding. It was approved by NSA for limited deployment on the ARPANET, to protect classified data being sent by DoD folks, starting in 1975 (a somewhat more sophisticated version was approved for use in 1976). Due to the restrictions imposed by use of government COMSEC equipment (KG-34), this was a manually keyed system. In the 1975-1980 timeframe, BBN and the Collins Radio division or Rockwell developed and did limited deployment of the BCR, also under DARPA funding, as an experimental network encryption device. The BCR worked in the TCP/IP protocol environment, used the first NBS-certified DES chips, and had automated, KDC-based key management and access control (the same model later adopted by Kerberos and Blacker). The BCR underwent substabtial performance testing in 1980-81, before being retired. Later, DES-based network security devices were design and some were built as prototypes for DARPA in the early 80s, experimentin with higher speed network connections (Ethernet) and newer versions of protocols (IPv4 vs. IPv3). The first Blacker program also began in the late 70's, funded by NSA with work done by SDC (software) and Burroughs (hardware). It too made use of centralized key management and access control. The followon program, designed to produce a product (vs. a proof-of-concept demo) was awarded to Unisys (merged SDC and Burroughs) in the early 80s, but it did not produce fielded devices until the late 80s. The fielded Blacker was revolutionary in its use of a single processor design with the (custom) crypto as a peripheral on the internal bus. It was designed to be a very high assurance (A1) system. In the early-80s, BBN developed the IPLI, a successor to the PLI, updated to use TCP/IP, newer COMSEC technology (KG-84), but still manually keyed. The IPLI was a backup program, funded by DARPA and DCA, in case the more ambitious (multi-level secure) Blacker program was delayed (which it was) and caused programmatic problems for the newly inaugrated Defense Data Network (DDN). IPLIs also were deisgned for a tactical environment, for use with DARPA low caost packet radios. A small number of IPLIs were delivered in the mid-80s, but never saw real deployment. All of the devices described above embody the essential network security designs that later were elaborated and improved upon in the SDNS program. However, none of them supported selective encryption on a per-packet basis, i.e., they all assumed that every packet emitted by a host or router on the "red" side of the device was to be encrypted. The CANEWARE program evolved from the initial, pre-production Blacker work in the late 70s, when one of the projects was a multiplexed link encryptor. Motorola was the contrtactor and the Air Force was the primary client. The client decided that muxed link crypto was not the wave of the future and the program gradually evolved into a network encryption project, called ENSNARE, by the early 80s. ENSNARE was a traditional approach to network crypto, completely analogous to the BCR, but using high grade COMSEC chips designed explicitly for this purpose. ENSNARE begat CANEWARE in the mid-80s, and for a while CANEWARE became the preferred backup for the long-awaited BLACKER product. CANEWARE diverged from the other programs by adopting the FIREFLY key management technology that became a centerpiece of the SDNS program and later network security efforts. As CANEWARE continued, it adopted the SDNS protocols for IP layer security and key management. During the late-80s, the CANEWARE interface spec began to include a capability for selective encryption, i.e., traffic to selected host addresses need not be encrypted. To the best of my knowledge, this was the first high grade network crypto device to include such a capability. However, the first widely published paper on CANEWARE (which appears in the proceedings of the 10th National Computer Security Conference, 9/87), does not mention this facility. The SDNS program (1986-91) developed protocols for layers 3 & 4 and for e-mail secruity and realtime key management. It included the notion that selective encryption could be employed (e.g., on an address-pair basis). I would check the SP3 specs sent to NIST in the late 80s for reference to this particular facility, since that seems to be the critical point. In the late-80s, IEEE started the SILS program, to develop security protocols for LANs. It was oriented toward commercial (not just government) clients and thus had a model that allowed for selective encryption (and/or integrity protection) of packets. In the proceedings of the 12th National Computer Security Conference, 10/89, there is an overview paper on SILS and that may make mention of what seems to be the relevent feature. Russ Housley was the co-chair of this committe for some time, so he may have access to better/more citations that would point to this facility. However, I did find what appears to be a relevent citation in looking through the 13th National Computer Security Conference proceedings (10/89). In a paper entitled "Low Cost Outboard Cryptographic Support for SILS and SP4" (B.J. Herbison, pages 286-295), there is explicit mention of a selective encryption facility in the device designed by DEC (and later built by them!). On page 288 the paper notes "The device recognizes several frame formats (both SILS and SP4) in frames passing through the device and encrypts or decrypts parts of the frames. if a frame doesn't contain a recognized format, then the frame is passed through unmodfied." In this design, software in the workstation or router or bridge decides what will or will not be encrypted and encapsulates it as appropriate. Then the simple crypto module does the necessary operations as directed by the encapsulation protocol. Thus, the combination of the software executing on the attached device plus this simple, inline crypto module, performs selective encryption/decryption of packets (viewed as MAC layer frames by this device). Steve Received: from relay.tis.com by neptune.TIS.COM id aa25816; 19 Jun 96 11:10 EDT Received: by relay.tis.com; id LAA03135; Wed, 19 Jun 1996 11:12:08 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma003111; Wed, 19 Jun 96 11:11:44 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA23190; Wed, 19 Jun 96 11:11:42 EDT Received: by relay.tis.com; id LAA03101; Wed, 19 Jun 1996 11:11:38 -0400 Received: from ns.research.att.com(192.20.225.4) by relay.tis.com via smap (V3.1.1) id xma003087; Wed, 19 Jun 96 11:11:33 -0400 Received: from research.research.att.com by ns; Wed Jun 19 11:12:35 EDT 1996 Received: from raptor.research.att.com by research; Wed Jun 19 11:12:06 EDT 1996 Received: from research.att.com (localhost.research.att.com [127.0.0.1]) by raptor.research.att.com (8.7.5/8.7) with ESMTP id LAA09832; Wed, 19 Jun 1996 11:11:59 -0400 (EDT) Message-Id: <199606191511.LAA09832@raptor.research.att.com> To: John Gilmore , ipsec@TIS.COM Subject: Re: UUNET Network Encryption Patents Date: Wed, 19 Jun 1996 11:11:59 -0400 From: Steven Bellovin Sender: ipsec-approval@neptune.tis.com Precedence: bulk Something else worth checking -- in the late '80s, DEC was selling a bump-in-the-cord Ethernet encryptor --- called the DESNC, if I recall correctly. It was completely transparent to the hosts involved, and did its encryption based on the addresses in the Ethernet header. Received: from relay.tis.com by neptune.TIS.COM id aa28112; 19 Jun 96 12:51 EDT Received: by relay.tis.com; id MAA06917; Wed, 19 Jun 1996 12:53:17 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma006882; Wed, 19 Jun 96 12:52:49 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27905; Wed, 19 Jun 96 12:52:48 EDT Received: by relay.tis.com; id MAA06872; Wed, 19 Jun 1996 12:52:47 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1) id xma006846; Wed, 19 Jun 96 12:52:28 -0400 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id JAA10775; Wed, 19 Jun 1996 09:53:31 -0700 Received: by mailsun2.us.oracle.com (8.7.1/37.8) id JAA26381; Wed, 19 Jun 1996 09:56:47 -0700 (PDT) Message-Id: <199606191656.JAA26381@mailsun2.us.oracle.com> Date: 19 Jun 96 09:49:29 -0700 From: "PALAMBER.US.ORACLE.COM" To: gnu@toad.com, ipsec@TIS.COM Subject: Re: Network Layer Encryption History and Prior Art Cc: scott@phx.sectel.mot.com X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-approval@neptune.tis.com's message of 19-Jun-96 00:49 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Boundary-5459231-0-0 Sender: ipsec-approval@neptune.tis.com Precedence: bulk --Boundary-5459231-0-0 >Recall that Rick says the important feature is encrypting some >packets, based on their header information, while letting others go >through unencrypted. I don't think any of the SDNS stuff that I saw >mentioned such ideas; they assumed you *did* want to encrypt and >explained the encrypted protocol. No, the "bypass" mode of operation that would allow selective encryption of packets was extensively discussed and documented. Most of the documents were internal design memos and reports. Selective encryption is critical to protect large existing systems ... you do not want to be forced to install all the encryption devices at the same time. Paul PS - I left all my patent files at Motorola when I changed jobs. If someone wants to push on the UUNET patent I may be able to find someone at Motorola to help. There is alot of documented prior art in their files... -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com -------------------------------------------------------------- --Boundary-5459231-0-0 Content-Type: message/rfc822 Date: 19 Jun 96 00:49:11 From:"John Gilmore " To: ipsec@tis.com,gnu@toad.com Subject: Re: Network Layer Encryption History and Prior Art X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol X-Orcl-Application: In-Reply-To: <9606190224.AA07109@dcl.MIT.EDU> X-Orcl-Application: Sender: ipsec-approval@neptune.tis.com X-Orcl-Application: Precedence: bulk > John (Gilmore), is this what you were looking for in terms of real Prior > Art to take to Rick Adams, so he'll drop the patent claims? Nope, these are *pointers to* prior art. Somebody (who understand patentese) needs to read the patents, and then read the actual published materials that Paul is mentioning. If any of them cover features that are specifically claimed by the Uunet patents, then there's a chance that they count as "prior art". (I'm not up on exactly what qualifies as prior art.) We would send the source documents to Rick or his lawyer, pointing out the prior inventions. If we get documents enough to mention ALL the claims from the Uunet patents, then the patents will cease to be a problem. Recall that Rick says the important feature is encrypting some packets, based on their header information, while letting others go through unencrypted. I don't think any of the SDNS stuff that I saw mentioned such ideas; they assumed you *did* want to encrypt and explained the encrypted protocol. Perhaps some of the implementations of these NSA protocols supported mixed encrypted/unencrypted traffic, though. Their manuals might be valid prior art, if ordinary mortals could have obtained them by 1991. John --Boundary-5459231-0-0-- Received: from relay.tis.com by neptune.TIS.COM id aa28480; 19 Jun 96 13:09 EDT Received: by relay.tis.com; id NAA07875; Wed, 19 Jun 1996 13:11:20 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma007863; Wed, 19 Jun 96 13:10:53 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28930; Wed, 19 Jun 96 13:10:49 EDT Received: by relay.tis.com; id NAA07846; Wed, 19 Jun 1996 13:10:47 -0400 Received: from pilot.is.chrysler.com(204.189.94.35) by relay.tis.com via smap (V3.1.1) id xma007823; Wed, 19 Jun 96 13:10:18 -0400 Received: by pilot.firewall.is.chrysler.com; id NAA05399; Wed, 19 Jun 1996 13:12:49 -0400 Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilot.is.chrysler.com via smap (g3.0.1) id sma005387; Wed, 19 Jun 96 13:12:38 -0400 Received: from rgm3 by clhubgw1-nf0.is.chrysler.com (8.7.5/SMI-4.1) id NAA13455; Wed, 19 Jun 1996 13:15:55 -0400 (EDT) Message-Id: <2.2.32.19960619170953.0099cc20@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Jun 1996 13:09:53 -0400 To: Stephen Kent , John Gilmore From: Robert Moskowitz Subject: Re: Network Layer Encryption History and Prior Art Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 10:59 AM 6/19/96 +0100, Stephen Kent wrote: >Folks, > > As one who participated somewhat more directly in the history of >this, let me refine some of Paul's comments. For people like me, this is a facinating thread. It also lends a lot of crediblity to the work down here. It is not cut from clean cloth. Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.tis.com by neptune.TIS.COM id aa28575; 19 Jun 96 13:12 EDT Received: by relay.tis.com; id NAA08042; Wed, 19 Jun 1996 13:14:50 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma008018; Wed, 19 Jun 96 13:14:25 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA29205; Wed, 19 Jun 96 13:14:24 EDT Received: by relay.tis.com; id NAA08002; Wed, 19 Jun 1996 13:14:20 -0400 Received: from raptor.com(204.7.243.11) by relay.tis.com via smap (V3.1.1) id xma007995; Wed, 19 Jun 96 13:14:17 -0400 Received: from raptor1.raptor.com ([204.7.242.10]) by eagle.raptor.com via smtpd (for ns.tis.com [192.94.214.100]) with SMTP; 19 Jun 1996 17:15:38 UT Received: from Joe_Tardo.raptor.com (pool021.Max4.San-Francisco.CA.DYNIP.ALTER.NET [153.37.101.21]) by raptor1.raptor.com (8.7.3/8.7.3) with SMTP id NAA21251; Wed, 19 Jun 1996 13:16:26 -0400 (EDT) Message-Id: <2.2.32.19960619171645.006f0e80@204.7.242.10> X-Sender: jtardo@204.7.242.10 X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Jun 1996 10:16:45 -0700 To: Steven Bellovin From: Joe Tardo Subject: Re: UUNET Network Encryption Patents Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk The DESNC was ethernet only. The 'wart in the line' encryptor used a chip that did both ISO TLSP and IPv4 transport mode encryption. Both were intended to be 'transparent', but the chip mainly did streaming crypto operations, and worked in conjunction with host drivers. Oh, by the way, DEC obtained a bunch of patents too. I don't remember all the numbers or claims or if any apply here, hopefully not, but, then, I'm no patent lawyer. At 11:11 AM 6/19/96 -0400, Steven Bellovin wrote: >Something else worth checking -- in the late '80s, DEC was selling a >bump-in-the-cord Ethernet encryptor --- called the DESNC, if I recall >correctly. It was completely transparent to the hosts involved, and >did its encryption based on the addresses in the Ethernet header. > > = ========================================================= = Joe Tardo Voice: 408-524-2990 Raptor Systems, Inc. 1250 Oakmead Parkway, Suite 210 Fax: 408-524-2988 Sunnyvale,Ca. 94088-3599 = ========================================================= = Received: from relay.tis.com by neptune.TIS.COM id aa29147; 19 Jun 96 13:40 EDT Received: by relay.tis.com; id NAA09347; Wed, 19 Jun 1996 13:42:14 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma009343; Wed, 19 Jun 96 13:41:46 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01539; Wed, 19 Jun 96 13:41:45 EDT Received: by relay.tis.com; id NAA09335; Wed, 19 Jun 1996 13:41:44 -0400 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1.1) id xma009324; Wed, 19 Jun 96 13:41:20 -0400 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.5/8.6.12) with SMTP id NAA25887; Wed, 19 Jun 1996 13:43:13 -0400 (EDT) Message-Id: <199606191743.NAA25887@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: John Lowry Cc: Jack Haverty , palamber@us.oracle.com, tytso@mit.edu, ipsec@TIS.COM Subject: Re: Auto-forward: Re: Network Layer Encryption History and Prior Art In-Reply-To: Your message of "Wed, 19 Jun 1996 10:29:27 EDT." <2.2.32.19960619142927.006bb9a4@dave.bbn.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 19 Jun 1996 13:43:11 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk John Lowry writes: > I was the last project leader for IPLI and I still have one in my office. > (Kind of booring without a mate - or a pair of KG-84s !) > Many of the IPLI reports were unclassified FOUO and delivered to (D)ARPA. > Would any of these constitute "public" documents for the purposes of > establishing prior art ? I am not a lawyer, but my understanding is that following the enactment of the Freedom of Information Act, all unclassified government documents that do not contain personal information covered by the privacy act and are not germane to a current legal investigation are public documents. My understanding is that the fact that any member of the general public can get access to them is in all likelyhood sufficient for patent prior art purposes. Perry Received: from relay.tis.com by neptune.TIS.COM id aa29559; 19 Jun 96 13:52 EDT Received: by relay.tis.com; id NAA09855; Wed, 19 Jun 1996 13:54:49 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma009811; Wed, 19 Jun 96 13:54:15 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02297; Wed, 19 Jun 96 13:54:14 EDT Received: by relay.tis.com; id NAA09807; Wed, 19 Jun 1996 13:54:13 -0400 Received: from central.cis.upenn.edu(158.130.12.2) by relay.tis.com via smap (V3.1.1) id xma009793; Wed, 19 Jun 96 13:54:00 -0400 Received: (jms@localhost) by central.cis.upenn.edu (8.6.12/UPenn 1.4) id NAA05235; Wed, 19 Jun 1996 13:56:25 -0400 Date: Wed, 19 Jun 1996 13:56:25 -0400 From: "Jonathan M. Smith" Posted-Date: Wed, 19 Jun 1996 13:56:25 -0400 Message-Id: <199606191756.NAA05235@central.cis.upenn.edu> To: touch@isi.edu Subject: Re: UUNET Network Encryption Patents Cc: faber@isi.edu, ipsec@TIS.COM Content-Length: 591 Sender: ipsec-approval@neptune.tis.com Precedence: bulk I think UUNET will have a bit of trouble with that patent given the filing dates. This is based on: Jonathan M. Smith, C. Brendan S. Traw, and David J. Farber, "Apparatus for Providing Cryptographic Support in a Net- work," U.S. Patent No. 5,329,623 (July 12th, 1994). and Jonathan M. Smith, C. Brendan S. Traw, and David J. Farber, "Cryptographic Support for a Gigabit Network," in Proceed- ings, INET '92, Kobe, JAPAN (June 15-18, 1992), pp. 229-237. (Inaugural Conference of the Internet Society) on which the patent filing was based. -J. Received: from relay.tis.com by neptune.TIS.COM id aa00384; 19 Jun 96 14:14 EDT Received: by relay.tis.com; id OAA11113; Wed, 19 Jun 1996 14:16:35 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma011080; Wed, 19 Jun 96 14:16:04 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03800; Wed, 19 Jun 96 14:16:03 EDT Received: by relay.tis.com; id OAA11077; Wed, 19 Jun 1996 14:16:02 -0400 Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1.1) id xma011068; Wed, 19 Jun 96 14:15:46 -0400 Received: from [128.89.0.110] (COMSEC.BBN.COM [128.89.0.110]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id OAA09284; Wed, 19 Jun 1996 14:20:09 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Jun 1996 14:17:40 +0100 To: Steven Bellovin From: Stephen Kent Subject: Re: UUNET Network Encryption Patents Cc: John Gilmore , ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Steve, Yes, I thought of the DESNC after I wrote my message. There is a paper on it in the 12th NCSC proceedings, but I am missing that year. I agree that it almost certainly provided for selective bypass on a host address (in this case a MAC layer address) basis. It relied on a KDC, which probably incorporated the access control database as well. Steve Received: from relay.tis.com by neptune.TIS.COM id aa03500; 19 Jun 96 16:33 EDT Received: by relay.tis.com; id QAA17599; Wed, 19 Jun 1996 16:35:12 -0400 From: MarkVon@aol.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma017591; Wed, 19 Jun 96 16:34:45 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13346; Wed, 19 Jun 96 16:34:44 EDT Received: by relay.tis.com; id QAA17586; Wed, 19 Jun 1996 16:34:42 -0400 Received: from unknown(198.81.11.39) by relay.tis.com via smap (V3.1.1) id xma017577; Wed, 19 Jun 96 16:34:24 -0400 Received: by emout13.mail.aol.com (8.6.12/8.6.12) id QAA22319 for ipsec@tis.com; Wed, 19 Jun 1996 16:36:50 -0400 Date: Wed, 19 Jun 1996 16:36:50 -0400 Message-Id: <960619163649_138475669@emout13.mail.aol.com> To: ipsec@TIS.COM Subject: Re: UUNET Network Encryption Patents Sender: ipsec-approval@neptune.tis.com Precedence: bulk Folks, Some more prior art to 1993. Xerox started selling the Xerox Encryption Unit around 1990. The XEU was a layer 2 (Ethernet/802.3) network encryption device. Wang started selling the Trusted Interface Unit around 1990. The TIU was a layer 2 (Ethernet/802.3) and layer 3 (IP) network encryption device. These products were based on technology developed by Ultron Labs which started around 1985 by Ultron Labs. Semaphore Communications Corp. started selling the Network Security System for Ethernet Workgroups in 1992. The NSS for WGs is a layer 2 (Ethernet/802.3) and layer 3 (IP, XNS, IPX, DECnet IV, Appletalk) network encryption system. The development of S4's system started in 1989. Regards, Mark Vondemkamp Received: from relay.tis.com by neptune.TIS.COM id aa03674; 19 Jun 96 16:41 EDT Received: by relay.tis.com; id QAA18053; Wed, 19 Jun 1996 16:42:58 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma018030; Wed, 19 Jun 96 16:42:30 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13956; Wed, 19 Jun 96 16:42:28 EDT Received: by relay.tis.com; id QAA18026; Wed, 19 Jun 1996 16:42:28 -0400 Received: from copernicus.hpc.org(192.187.8.4) by relay.tis.com via smap (V3.1.1) id xma018022; Wed, 19 Jun 96 16:42:18 -0400 Received: from earth.hpc.org (earth.hpc.org [192.187.8.34]) by hpc.org (8.7.1/8.7.1) with SMTP id QAA04747 for ; Wed, 19 Jun 1996 16:47:01 -0400 (EDT) Received: by earth.hpc.org (SMI-8.6/SMI-SVR4) id QAA25940; Tue, 18 Jun 1996 16:46:47 -0400 Date: Tue, 18 Jun 1996 16:46:47 -0400 From: Hilarie Orman Message-Id: <199606182046.QAA25940@earth.hpc.org> To: ipsec@TIS.COM Subject: Oakley primes and EC groups Sender: ipsec-approval@neptune.tis.com Precedence: bulk The following is a augmentation of Appendix F of the Oakely-01 draft, giving the recommended parameters for 4 of the Well-Known Groups. This includes a heavy-duty elliptic curve group. A 1536-bit prime is still in progress; that will complete the 5 WKG's (this prime will have 90-bits of "strength"). ----- APPENDIX F The Well-Known Groups The group identifiers: 0 No group (used as a placeholder and for non-DH exchanges) 1 A modular exponentiation group with a 768 bit modulus 2 A modular exponentiation group with a 1024 bit modulus 3 A modular exponentiation group with a 1536 bit modulus (TBD) 4 An elliptic curve group over GF[2^155] 5 An elliptic curve group over GF[2^185] values 2^31 and higher are used for private group identifiers Richard Schroeppel performed all the mathematical and computational work for this appendix. Classical Diffie-Hellman Modular Exponentiation Groups The primes for groups 1 and 2 were selected to have certain properties. The high order 64 bits are forced to 1. This helps the classical remainder algorithm, because the trial quotient digit can always be taken as the high order word of the dividend, possibly +1. The low order 64 bits are forced to 1. This helps the Montgomery- style remainder algorithms, because the multiplier digit can always be taken to be the low order word of the dividend. The middle bits are taken from the binary expansion of pi. This guarantees that they are effectively random, while avoiding any suspicion that the primes have secretly been selected to be weak. Because both primes are based on pi, there is a large section of overlap in the hex representations of the two primes. The primes are chosen to be Sophie-Germain primes (i.e., (P-1)/2 is also prime), to have the maximum strength against the square-root attack. The starting trial numbers were repeatedly incremented by 2^64 until suitable primes were located. Because these two primes are congruent to 7 (mod 8), 2 is a quadratic residue of each prime. All powers of 2 will also be quadratic residues. This prevents an opponent from learning the low order bit of the Diffie-Hellman exponent. Using 2 as a generator is efficient for some modular exponentiation algorithms. [Note that 2 is technically not a generator in the number theory sense, because it omits half of the possible residues mod P. From a cryptographic viewpoint, this is a virtue.] F.1. Well-Known Group 1: A 768 bit prime The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. Its decimal value is 155251809230070893513091813125848175563133404943451431320235 119490296623994910210725866945387659164244291000768028886422 915080371891804634263272761303128298374438082089019628850917 0691316593175367469551763119843371637221007210577919 This has been rigorously verified as a prime. The representation of the group in OAKLEY is Type of group: "MODP" Size of field element (bits): 768 Prime modulus: 21 (decimal) Length (32 bit words): 24 Data (hex): FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF Generator: 22 (decimal) Length (32 bit words): 1 Data (hex): 2 Optional Parameters: Group order largest prime factor: 24 (decimal) Length (32 bit words): 24 Data (hex): 7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68 94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122 F242DABB 312F3F63 7A262174 D31D1B10 7FFFFFFF FFFFFFFF Strength of group: 26 (decimal) Length (32 bit words) 1 Data (hex): 00000042 F.2. Well-Known Group 2: A 1024 bit prime The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. Its decimal value is 179769313486231590770839156793787453197860296048756011706444 423684197180216158519368947833795864925541502180565485980503 646440548199239100050792877003355816639229553136239076508735 759914822574862575007425302077447712589550957937778424442426 617334727629299387668709205606050270810842907692932019128194 467627007 The primality of the number has been rigorously proven. The representation of the group in OAKLEY is Type of group: "MODP" Size of field element (bits): 1024 Prime modulus: 21 (decimal) Length (32 bit words): 32 Data (hex): FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 FFFFFFFF FFFFFFFF Generator: 22 (decimal) Length (32 bit words): 1 Data (hex): 2 Optional Parameters: Group order largest prime factor: 24 (decimal) Length (32 bit words): 32 Data (hex): 7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68 94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122 F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6 F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F67329C0 FFFFFFFF FFFFFFFF Strength of group: 26 (decimal) Length (32 bit words) 1 Data (hex): 0000004D F.3. Well-Known Group 3: An Elliptic Curve Group Definition The curve is based on the Galois field GF[2^155] with 2^155 field elements. The irreducible polynomial for the field is u^155 + u^62 + 1. The equation for the elliptic curve is Y^2 + X Y = X^3 + A X + B X, Y, A, B are elements of the field. For the curve specified, A = 0 and B = u^18 + u^17 + u^16 + u^13 + u^12 + u^9 + u^8 + u^7 + u^3 + u^2 + u + 1. B is represented in binary as the bit string 1110011001110001111; in decimal this is 471951, and in hex 7338F. The generator is a point (X,Y) on the curve (satisfying the curve equation, mod 2 and modulo the field polynomial). X = u^6 + u^5 + u^4 + u^3 + u + 1 and Y = u^8 + u^7 + u^6 + u^3. The binary bit strings for X and Y are 1111011 and 111001000; in decimal they are 123 and 456. The group order (the number of curve points) is 45671926166590716193865565914344635196769237316 which is 12 times the prime 3805993847215893016155463826195386266397436443. (This prime has been rigorously proven.) The generating point (X,Y) has order 4 times the prime; the generator is the triple of some curve point. OAKLEY representation of this group: Type of group: "EC2N" Size of field element (bits): 155 Irreducible field polynomial: 21 (decimal) Length (32 bit words): 5 Data (hex): 08000000 00000000 00000000 40000000 00000001 Generator: X coordinate: 22 (decimal) Length (32 bit words): 1 Data (hex): 7B Y coordinate: 22 (decimal) Length (32 bit words): 1 Data (hex): 1C8 Elliptic curve parameters: A parameter: 23 (decimal) Length (32 bit words): 1 Data (hex): 0 B parameter: 23 (decimal) Length (32 bit words): 1 Data (hex): 7338F Optional Parameters: Group order largest prime factor: 24 (decimal) Length (32 bit words): 5 Data (hex): 00AAAAAA AAAAAAAA AAAAB1FC F1E206F4 21A3EA1B Group order: 25 (decimal) Length (32 bit words): 5 Data (hex): 08000000 00000000 000057DB 56985371 93AEF944 Strength of group: 26 (decimal) Length (32 bit words) 1 Data (hex): 0000004C F.4. Well-Known Group 4: A Large Elliptic Curve Group Definition This curve is based on the Galois field GF[2^185] with 2^185 field elements. The irreducible polynomial for the field is u^185 + u^69 + 1. The equation for the elliptic curve is Y^2 + X Y = X^3 + A X + B. X, Y, A, B are elements of the field. For the curve specified, A = 0 and B = u^12 + u^11 + u^10 + u^9 + u^7 + u^6 + u^5 + u^3 + 1. B is represented in binary as the bit string 1111011101001; in decimal this is 7913, and in hex 1EE9. The generator is a point (X,Y) on the curve (satisfying the curve equation, mod 2 and modulo the field polynomial); X = u^4 + u^3 and Y = u^3 + u^2 + 1. The binary bit strings for X and Y are 11000 and 1101; in decimal they are 24 and 13. The group order (the number of curve points) is 49039857307708443467467104857652682248052385001045053116, which is 4 times the prime 12259964326927110866866776214413170562013096250261263279. (This prime has been rigorously proven.) The generating point (X,Y) has order 2 times the prime; the generator is the double of some curve point. OAKLEY representation of this group: Type of group: "EC2N" Size of field element (bits): 185 Irreducible field polynomial: 21 (decimal) Length (32 bit words): 6 Data (hex): 02000000 00000000 00000000 00000020 00000000 00000001 Generator: X coordinate: 22 (decimal) Length (32 bit words): 1 Data (hex): 18 Y coordinate: 22 (decimal) Length (32 bit words): 1 Data (hex): D Elliptic curve parameters: A parameter: 23 (decimal) Length (32 bit words): 1 Data (hex): 0 B parameter: 23 (decimal) Length (32 bit words): 1 Data (hex): 1EE9 Optional parameters: Group order largest prime factor: 24 (decimal) Length (32 bit words): 6 Data (hex): 007FFFFF FFFFFFFF FFFFFFFF F6FCBE22 6DCF9210 5D7E53AF Group order: 25 (decimal) Length (32 bit words): 6 Data (hex): 01FFFFFF FFFFFFFF FFFFFFFF DBF2F889 B73E4841 75F94EBC Strength of group: 26 (decimal) Length (32 bit words) 1 Data (hex): 0000005B Received: from relay.tis.com by neptune.TIS.COM id aa04234; 19 Jun 96 17:08 EDT Received: by relay.tis.com; id RAA18977; Wed, 19 Jun 1996 17:09:59 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma018960; Wed, 19 Jun 96 17:09:31 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA15791; Wed, 19 Jun 96 17:09:30 EDT Received: by relay.tis.com; id RAA18951; Wed, 19 Jun 1996 17:09:28 -0400 Received: from toad.com(140.174.2.1) by relay.tis.com via smap (V3.1.1) id xma018945; Wed, 19 Jun 96 17:09:22 -0400 Received: from localhost (localhost [127.0.0.1]) by toad.com (8.7.5/8.7.3) with SMTP id OAA25347; Wed, 19 Jun 1996 14:11:48 -0700 (PDT) Message-Id: <199606192111.OAA25347@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: ipsec@TIS.COM, gnu@toad.com Subject: UUNET Network Encryption Patents available online In-Reply-To: <2.2.32.19960619171645.006f0e80@204.7.242.10> Date: Wed, 19 Jun 1996 14:11:46 -0700 From: John Gilmore Sender: ipsec-approval@neptune.tis.com Precedence: bulk I pulled down the patents (minus their figures) and have made them available at http://www.cygnus.com/~gnu/netcrypt.html There's also an edited-down version of the fascinating history lesson we've been exchanging. John Received: from relay.tis.com by neptune.TIS.COM id aa05181; 19 Jun 96 17:58 EDT Received: by relay.tis.com; id HAA26657; Wed, 19 Jun 1996 07:51:35 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma026655; Wed, 19 Jun 96 07:51:07 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA11979; Wed, 19 Jun 96 07:51:06 EDT Received: by relay.tis.com; id HAA26650; Wed, 19 Jun 1996 07:51:05 -0400 Received: from unknown(204.189.94.36) by relay.tis.com via smap (V3.1.1) id xma026624; Wed, 19 Jun 96 07:51:04 -0400 Received: by pilotx.firewall.is.chrysler.com; id HAA01117; Wed, 19 Jun 1996 07:53:34 -0400 Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilotx.is.chrysler.com via smap (g3.0.1) id sma001109; Wed, 19 Jun 96 07:53:23 -0400 Received: from rgm3 by clhubgw1-nf0.is.chrysler.com (8.7.5/SMI-4.1) id HAA07565; Wed, 19 Jun 1996 07:56:40 -0400 (EDT) Message-Id: <2.2.32.19960619115040.00b95ae0@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Jun 1996 07:50:40 -0400 To: John Gilmore , ipsec@TIS.COM, gnu@toad.com From: Robert Moskowitz Subject: Re: Network Layer Encryption History and Prior Art Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 12:49 AM 6/19/96 -0700, John Gilmore wrote: >> John (Gilmore), is this what you were looking for in terms of real Prior >> Art to take to Rick Adams, so he'll drop the patent claims? > >Nope, these are *pointers to* prior art. Somebody (who understand >patentese) needs to read the patents, and then read the actual >published materials that Paul is mentioning. sounds like some work for one of the vendor's patent lawyers. If this were an auto patent problem, I would know whoto take it to. But I do not think that Chrysler can lend a hand in this one... BTW, we do these things all of the time. Many we win, some we cross license, and some we loose in court (like intermitent wiper systems :). Your industry is only beginning to learn this technique. Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.tis.com by neptune.TIS.COM id aa05957; 19 Jun 96 18:35 EDT Received: by relay.tis.com; id SAA21762; Wed, 19 Jun 1996 18:37:44 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma021753; Wed, 19 Jun 96 18:37:19 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19333; Wed, 19 Jun 96 18:37:14 EDT Received: by relay.tis.com; id SAA21749; Wed, 19 Jun 1996 18:37:14 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1) id xma021747; Wed, 19 Jun 96 18:37:08 -0400 Received: from maildig1.us.oracle.com by inet-smtp-gw-1.us.oracle.com with SMTP (8.6.12/37.7) id PAA30730; Wed, 19 Jun 1996 15:39:40 -0700 Received: by maildig1.us.oracle.com (5.65v3.2/37.8) id AA31562; Wed, 19 Jun 1996 15:39:38 -0700 Message-Id: <9606192239.AA31562@maildig1.us.oracle.com> Date: Wed, 19 Jun 1996 15:39:38 -0700 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: Re: UUNET Network Encryption Patents X-Orcl-Application: In-Reply-To:UNX02.US.ORACLE.COM:ipsec-approval@neptune.tis.com's message of 19-Jun-96 10:16 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Boundary-21339856-0-0 Sender: ipsec-approval@neptune.tis.com Precedence: bulk --Boundary-21339856-0-0 >Oh, by the way, DEC obtained a bunch of patents too. One of these patents covered sending an encrypted session key in the header that was encrypted by a key know only to the recipient. This provides some interesting optimizations for hardware implementations. This function was forced into the IEEE 802.10 Standard for Interoperable Lan Standard (SILS) as an optional user or "management defined field". It was inserted ostensibly for labeling to support filtering at bridges, but in reality no other vendor supported this feature. There is now no documentation of the DEC usage of this field in the SILS standard, but the field still is documented in the standard (last I checked..). This is an interesting example of embedding patented technologies as options into a standard. Paul -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com -------------------------------------------------------------- --Boundary-21339856-0-0 Content-Type: message/rfc822 Date: 19 Jun 96 10:16:45 From:"Joe Tardo " To: Steven,Bellovin,smb@research.att.com Subject: Re: UUNET Network Encryption Patents Cc: ipsec@tis.com X-Sender: jtardo@204.7.242.10 X-Mailer: Windows Eudora Pro Version 2.2 (32) X-Orcl-Application: Mime-Version: 1.0 X-Orcl-Application: Content-Type: text/plain; charset="us-ascii" X-Orcl-Application: Sender: ipsec-approval@neptune.tis.com X-Orcl-Application: Precedence: bulk The DESNC was ethernet only. The 'wart in the line' encryptor used a chip that did both ISO TLSP and IPv4 transport mode encryption. Both were intended to be 'transparent', but the chip mainly did streaming crypto operations, and worked in conjunction with host drivers. Oh, by the way, DEC obtained a bunch of patents too. I don't remember all the numbers or claims or if any apply here, hopefully not, but, then, I'm no patent lawyer. At 11:11 AM 6/19/96 -0400, Steven Bellovin wrote: >Something else worth checking -- in the late '80s, DEC was selling a >bump-in-the-cord Ethernet encryptor --- called the DESNC, if I recall >correctly. It was completely transparent to the hosts involved, and >did its encryption based on the addresses in the Ethernet header. > > = ========================================================= = Joe Tardo Voice: 408-524-2990 Raptor Systems, Inc. 1250 Oakmead Parkway, Suite 210 Fax: 408-524-2988 Sunnyvale,Ca. 94088-3599 = ========================================================= = --Boundary-21339856-0-0-- Received: from relay.tis.com by neptune.TIS.COM id aa06114; 19 Jun 96 18:42 EDT Received: by relay.tis.com; id SAA21868; Wed, 19 Jun 1996 18:44:44 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma021861; Wed, 19 Jun 96 18:44:15 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19556; Wed, 19 Jun 96 18:44:15 EDT Received: by relay.tis.com; id SAA21855; Wed, 19 Jun 1996 18:44:14 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1) id xma021849; Wed, 19 Jun 96 18:43:45 -0400 Received: from maildig1.us.oracle.com by inet-smtp-gw-1.us.oracle.com with SMTP (8.6.12/37.7) id PAA07941; Wed, 19 Jun 1996 15:46:17 -0700 Received: by maildig1.us.oracle.com (5.65v3.2/37.8) id AA00282; Wed, 19 Jun 1996 15:46:15 -0700 Message-Id: <9606192246.AA00282@maildig1.us.oracle.com> Date: Wed, 19 Jun 1996 15:46:15 -0700 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: Re: UUNET Network Encryption Patents Cc: faber@isi.edu X-Orcl-Application: In-Reply-To:UNX02.US.ORACLE.COM:ipsec-approval@neptune.tis.com's message of 19-Jun-96 13:56 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Boundary-21340246-0-0 Sender: ipsec-approval@neptune.tis.com Precedence: bulk --Boundary-21340246-0-0 Jonathan, Thanks for your input ... does this mean that you are claiming your patent may apply to IPsec standards? > Jonathan M. Smith, C. Brendan S. Traw, and David J. Farber, > "Apparatus for Providing Cryptographic Support in a > Network," U.S. Patent No. 5,329,623 (July 12th, 1994). Would it be possible for you to send a copy of your patent to me (address below) ... Thanks in advance, Paul -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com *** Hiring, send resumes to: rwessman@us.oracle.com *** -------------------------------------------------------------- --Boundary-21340246-0-0 Content-Type: message/rfc822 Date: 19 Jun 96 13:56:25 From:"Jonathan M. Smith" To: touch@isi.edu Subject: Re: UUNET Network Encryption Patents Cc: faber@isi.edu,ipsec@tis.com X-Orcl-Application: Posted-Date: Wed, 19 Jun 1996 13:56:25 -0400 X-Orcl-Application: Content-Length: 591 X-Orcl-Application: Sender: ipsec-approval@neptune.tis.com X-Orcl-Application: Precedence: bulk I think UUNET will have a bit of trouble with that patent given the filing dates. This is based on: Jonathan M. Smith, C. Brendan S. Traw, and David J. Farber, "Apparatus for Providing Cryptographic Support in a Net- work," U.S. Patent No. 5,329,623 (July 12th, 1994). and Jonathan M. Smith, C. Brendan S. Traw, and David J. Farber, "Cryptographic Support for a Gigabit Network," in Proceed- ings, INET '92, Kobe, JAPAN (June 15-18, 1992), pp. 229-237. (Inaugural Conference of the Internet Society) on which the patent filing was based. -J. --Boundary-21340246-0-0-- Received: from relay.tis.com by neptune.TIS.COM id aa06369; 19 Jun 96 18:54 EDT Received: by relay.tis.com; id SAA22040; Wed, 19 Jun 1996 18:56:14 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma022038; Wed, 19 Jun 96 18:55:45 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19996; Wed, 19 Jun 96 18:55:44 EDT Received: by relay.tis.com; id SAA22035; Wed, 19 Jun 1996 18:55:44 -0400 Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1.1) id xma022033; Wed, 19 Jun 96 18:55:21 -0400 Received: from [128.89.0.110] (COMSEC.BBN.COM [128.89.0.110]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id SAA29064; Wed, 19 Jun 1996 18:59:02 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Jun 1996 18:56:35 +0100 To: MarkVon@aol.com From: Stephen Kent Subject: Re: UUNET Network Encryption Patents Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Mark, The XEU and TIU are good examples of inline network crypto from the latter 80s, but they also did not provide the selective bypass feature mentioned as a critical feature in the patent. However, the Semaphore device certainly did (and still does) and that's an excellent example of existing technology that was widely demonstrated and its product literature certainly mentioned the selective bypass capability. (Semaphore was a sort of spinoff from Xerox, the folks who developed the XEU, as your mentioned.) One also could mention the Motorola NES, an IP (or MAC) layer, high grade crypto product which was sold starting in the early 90s, but it too lacked selective bypass. The Motorola folks often viewed the Sempahore devices as commercial versions of the NES, and in many respects that is an accurate characterization. Steve Received: from relay.tis.com by neptune.TIS.COM id aa12975; 20 Jun 96 2:47 EDT Received: by relay.tis.com; id CAA00448; Thu, 20 Jun 1996 02:48:55 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma000308; Thu, 20 Jun 96 02:47:21 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27168; Thu, 20 Jun 96 02:47:09 EDT Received: by relay.tis.com; id CAA00276; Thu, 20 Jun 1996 02:47:04 -0400 Received: from lobster.corpeast.baynetworks.com(192.32.253.3) by relay.tis.com via smap (V3.1.1) id xma029660; Thu, 20 Jun 96 02:40:54 -0400 Received: from pobox.BayNetworks.com by lobster.wellfleet.com (SMI-8.6/SMI-4.1) id WAA29888; Wed, 19 Jun 1996 22:16:55 -0400 Received: from gopher.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA16578; Wed, 19 Jun 96 22:14:28 EDT Date: Wed, 19 Jun 96 22:14:28 EDT From: Cheryl Madson Message-Id: <9606200214.AA16578@pobox.BayNetworks.com> To: jkrawczy@baynetworks.com Subject: I need a file... Cc: It@baynetworks.com, a@baynetworks.com, cmadson@baynetworks.com, folder.@baynetworks.com, has@baynetworks.com, ipsec@TIS.COM, is@baynetworks.com, mail@baynetworks.com, much@baynetworks.com, my@baynetworks.com, of@baynetworks.com, rfax@baynetworks.com, zip@baynetworks.com Sender: ipsec-approval@neptune.tis.com Precedence: bulk Yes, at the moment I can still log in, but I haven't been able to download all day. more than the ipsec archives, some of it private discussions. Ruth was able to copy files onto diskettes for me. She and I both have intel-based systems, so no conversion was needed. If you or her can copy this file for me, and if you could bring it to Montreal, I'd appreciate it. Thx - C BTW: I assume that they aren't planning on keeping my login going forever; it would be a good idea for someone to check on it... Received: from relay.tis.com by neptune.TIS.COM id aa15954; 20 Jun 96 6:24 EDT Received: by relay.tis.com; id GAA03966; Thu, 20 Jun 1996 06:26:27 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma003963; Thu, 20 Jun 96 06:25:59 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01597; Thu, 20 Jun 96 06:25:57 EDT Received: by relay.tis.com; id GAA03960; Thu, 20 Jun 1996 06:25:57 -0400 Received: from copilot.is.chrysler.com(204.189.94.36) by relay.tis.com via smap (V3.1.1) id xma003958; Thu, 20 Jun 96 06:25:47 -0400 Received: by pilotx.firewall.is.chrysler.com; id GAA14676; Thu, 20 Jun 1996 06:28:21 -0400 Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilotx.is.chrysler.com via smap (g3.0.1) id sma014673; Thu, 20 Jun 96 06:28:07 -0400 Received: from rgm3 by clhubgw1-nf0.is.chrysler.com (8.7.5/SMI-4.1) id GAA23498; Thu, 20 Jun 1996 06:31:24 -0400 (EDT) Message-Id: <2.2.32.19960620102510.009512b8@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Jun 1996 06:25:10 -0400 To: perry@piermont.com, John Lowry From: Robert Moskowitz Subject: Re: Auto-forward: Re: Network Layer Encryption History and Prior Art Cc: Jack Haverty , palamber@us.oracle.com, tytso@mit.edu, ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 01:43 PM 6/19/96 -0400, Perry E. Metzger wrote: > >I am not a lawyer, but my understanding is that following the >enactment of the Freedom of Information Act, all unclassified >government documents that do not contain personal information covered >by the privacy act and are not germane to a current legal >investigation are public documents. My understanding is that the fact >that any member of the general public can get access to them is in all >likelyhood sufficient for patent prior art purposes. Gee it is so fun to play lawyer! When was FIA passed? If it post dates the filing, then these docs probably do not constitute prior art. Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.tis.com by neptune.TIS.COM id aa16521; 20 Jun 96 7:01 EDT Received: by relay.tis.com; id HAA04222; Thu, 20 Jun 1996 07:03:27 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma004211; Thu, 20 Jun 96 07:02:59 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02085; Thu, 20 Jun 96 07:02:58 EDT Received: by relay.tis.com; id HAA04206; Thu, 20 Jun 1996 07:02:58 -0400 Message-Id: <199606201102.HAA04206@relay.tis.com> Received: from hydra.dra.hmg.gb(192.5.29.32) by relay.tis.com via smap (V3.1.1) id xmaa04192; Thu, 20 Jun 96 07:02:32 -0400 Date: 20 Jun 96 12:03:00 GMT From: "SPARKS::WEAVER" Subject: NULL or NOT To: ipsec Sender: ipsec-approval@neptune.tis.com Precedence: bulk All, Just picked-up the conversation on the "NULL_SA" - been out of the office. I can see that some people may wish to use a NULL_SA instead of creating multiple proposal lists to achieve the same thing. However, my interpretation of the latest 1825, 1826 and 1827 drafts are that you either use AH or ESP between hosts but not both, at least not with the same SPI, in this case the NULL_SA idea is NULLIFIED ;-) Elfed weaver@hydra.dra.hmg.gb Received: from relay.tis.com by neptune.TIS.COM id aa16490; 20 Jun 96 7:00 EDT Received: by relay.tis.com; id HAA04205; Thu, 20 Jun 1996 07:02:57 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma004197; Thu, 20 Jun 96 07:02:29 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02077; Thu, 20 Jun 96 07:02:27 EDT Received: by relay.tis.com; id HAA04194; Thu, 20 Jun 1996 07:02:27 -0400 Message-Id: <199606201102.HAA04194@relay.tis.com> Received: from hydra.dra.hmg.gb(192.5.29.32) by relay.tis.com via smap (V3.1.1) id xma004192; Thu, 20 Jun 96 07:02:14 -0400 Date: 20 Jun 96 12:03:00 GMT From: "SPARKS::WEAVER" To: ipsec Sender: ipsec-approval@neptune.tis.com Precedence: bulk All, Just picked-up the conversation on the "NULL_SA" - been out of the office. I can see that some people may wish to use a NULL_SA instead of creating multiple proposal lists to achieve the same thing. However, my interpretation of the latest 1825, 1826 and 1827 drafts are that you either use AH or ESP between hosts but not both, at least not with the same SPI, in this case the NULL_SA idea is NULLIFIED ;-) Elfed weaver@hydra.dra.hmg.gb Received: from relay.tis.com by neptune.TIS.COM id aa17553; 20 Jun 96 7:51 EDT Received: by relay.tis.com; id HAA04874; Thu, 20 Jun 1996 07:52:58 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma004872; Thu, 20 Jun 96 07:52:33 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03477; Thu, 20 Jun 96 07:52:28 EDT Received: by relay.tis.com; id HAA04867; Thu, 20 Jun 1996 07:52:28 -0400 Received: from pad-thai.cam.ov.com(192.231.148.11) by relay.tis.com via smap (V3.1.1) id xma004861; Thu, 20 Jun 96 07:52:16 -0400 Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Thu, 20 Jun 1996 11:54:49 GMT Received: from localhost by winkl.cam.ov.com (8.6.10/4.7) id HAA07213; Thu, 20 Jun 1996 07:54:49 -0400 Message-Id: <199606201154.HAA07213@winkl.cam.ov.com> To: Stephen Kent Cc: John Gilmore , ipsec@TIS.COM, linn@cam.ov.com Subject: Re: Network Layer Encryption History and Prior Art In-Reply-To: Your message of "Wed, 19 Jun 1996 10:59:39 BST." Date: Thu, 20 Jun 1996 07:54:48 -0400 From: John Linn Sender: ipsec-approval@neptune.tis.com Precedence: bulk As part of his comprehensively informative history message, Steve wrote, excerpting: > The SDNS program (1986-91) developed protocols for layers 3 & 4 and >for e-mail secruity and realtime key management. It included the notion >that selective encryption could be employed (e.g., on an address-pair >basis). I would check the SP3 specs sent to NIST in the late 80s for >reference to this particular facility, since that seems to be the critical >point. The proceedings of the 10th National Computer Security Conference (September 1987) included a set of papers about the SDNS program. I wrote one of them, "SDNS Products in the Type II Environment" (the phrase "Type II" referring in this parlance to anticipated usage for protection of commercial and Government unclassified sensitive information). On page 163 of the proceedings, this paper stated, "... As a specific example, it will be common for SDNS-secured Type II hosts to communicate not only with other SDNS-secured hosts, but also with unsecured hosts. This implies that Type II SDNS components must accomodate selective application of encryption, either on an address-driven basis or on request from an associated host." Although this paper's level was discussion of issues and requirements, not detailed design or implementation, I believe this validates the concept's visibility in at least one piece of published literature as of 1987. --jl Received: from relay.tis.com by neptune.TIS.COM id aa20474; 20 Jun 96 10:12 EDT Received: by relay.tis.com; id CAA00421; Thu, 20 Jun 1996 02:48:40 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma000257; Thu, 20 Jun 96 02:46:55 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27111; Thu, 20 Jun 96 02:46:48 EDT Received: by relay.tis.com; id CAA00219; Thu, 20 Jun 1996 02:46:45 -0400 Received: from lobster.corpeast.baynetworks.com(192.32.253.3) by relay.tis.com via smap (V3.1.1) id xma029643; Thu, 20 Jun 96 02:40:47 -0400 Received: from pobox.BayNetworks.com by lobster.wellfleet.com (SMI-8.6/SMI-4.1) id WAA29978; Wed, 19 Jun 1996 22:20:18 -0400 Received: from gopher.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA16672; Wed, 19 Jun 96 22:17:53 EDT Date: Wed, 19 Jun 96 22:17:53 EDT From: Cheryl Madson Message-Id: <9606200217.AA16672@pobox.BayNetworks.com> To: ipsec@TIS.COM Subject: Sigh. The mailer just went nuts... Sender: ipsec-approval@neptune.tis.com Precedence: bulk Sorry for the trash. - C Received: from relay.tis.com by neptune.TIS.COM id aa21658; 20 Jun 96 10:54 EDT Received: by relay.tis.com; id KAA09488; Thu, 20 Jun 1996 10:56:18 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma009476; Thu, 20 Jun 96 10:55:51 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13205; Thu, 20 Jun 96 10:55:49 EDT Received: by relay.tis.com; id KAA09469; Thu, 20 Jun 1996 10:55:49 -0400 Received: from unknown(204.189.94.35) by relay.tis.com via smap (V3.1.1) id xma009432; Thu, 20 Jun 96 10:55:18 -0400 Received: by pilot.firewall.is.chrysler.com; id KAA18369; Thu, 20 Jun 1996 10:57:42 -0400 Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilot.is.chrysler.com via smap (g3.0.1) id sma018365; Thu, 20 Jun 96 10:57:17 -0400 Received: from rgm3 by clhubgw1-nf0.is.chrysler.com (8.7.5/SMI-4.1) id LAA28132; Thu, 20 Jun 1996 11:00:34 -0400 (EDT) Message-Id: <2.2.32.19960620145419.00b74e04@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Jun 1996 10:54:19 -0400 To: ipsec@TIS.COM From: Robert Moskowitz Subject: l2f and Cisco??? Sender: ipsec-approval@neptune.tis.com Precedence: bulk Pointcast had a press release from last night from Cisco, Nortell, and Shiva announcing 'layer two forwarding' that they had submitted to the IETF for a standard. Can the Cisco and other members here comment on what l2f gives over ipsec? Why should l2f become more than an informational RFC and why even is it needed? Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.tis.com by neptune.TIS.COM id aa22083; 20 Jun 96 11:07 EDT Received: by relay.tis.com; id LAA10147; Thu, 20 Jun 1996 11:09:31 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma010141; Thu, 20 Jun 96 11:09:15 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA14372; Thu, 20 Jun 96 11:09:12 EDT Received: by relay.tis.com; id LAA10131; Thu, 20 Jun 1996 11:09:07 -0400 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1.1) id xma010123; Thu, 20 Jun 96 11:08:56 -0400 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.5/8.6.12) with SMTP id KAA28926; Thu, 20 Jun 1996 10:11:08 -0400 (EDT) Message-Id: <199606201411.KAA28926@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Robert Moskowitz Cc: ipsec@TIS.COM Subject: Re: Auto-forward: Re: Network Layer Encryption History and Prior Art In-Reply-To: Your message of "Thu, 20 Jun 1996 06:25:10 EDT." <2.2.32.19960620102510.009512b8@pop3hub.is.chrysler.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Thu, 20 Jun 1996 10:11:04 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Robert Moskowitz writes: > Gee it is so fun to play lawyer! > > When was FIA passed? Just after Watergate. It predates all this work. > If it post dates the filing, then these docs probably do not > constitute prior art. Received: from relay.tis.com by neptune.TIS.COM id aa24079; 20 Jun 96 12:47 EDT Received: by relay.tis.com; id MAA12913; Thu, 20 Jun 1996 12:49:32 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma012893; Thu, 20 Jun 96 12:49:04 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19593; Thu, 20 Jun 96 12:49:02 EDT Received: by relay.tis.com; id MAA12887; Thu, 20 Jun 1996 12:49:02 -0400 Received: from unknown(171.68.223.44) by relay.tis.com via smap (V3.1.1) id xma012881; Thu, 20 Jun 96 12:48:55 -0400 Received: from pferguso-pc.cisco.com (c1robo13.cisco.com [171.68.13.13]) by lint.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id JAA06051; Thu, 20 Jun 1996 09:52:16 -0700 Message-Id: <199606201652.JAA06051@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Jun 1996 12:51:21 -0400 To: Robert Moskowitz From: Paul Ferguson Subject: Re: l2f and Cisco??? Cc: ipsec@TIS.COM, Andy Valencia Sender: ipsec-approval@neptune.tis.com Precedence: bulk Bob, L2F is a method to build a 'dynamic' tunnel, for instance, in instances where you would like to have per-customer dial-up profiles to connect to different services & different privilege levels. See: http://ds.internic.net/internet-drafts/draft-ietf-pppext-l2f-02.txt - paul At 10:54 AM 6/20/96 -0400, Robert Moskowitz wrote: >Pointcast had a press release from last night from Cisco, Nortell, and Shiva >announcing 'layer two forwarding' that they had submitted to the IETF for a >standard. > >Can the Cisco and other members here comment on what l2f gives over ipsec? >Why should l2f become more than an informational RFC and why even is it needed? > >Robert Moskowitz >Chrysler Corporation >(810) 758-8212 > Received: from relay.tis.com by neptune.TIS.COM id aa24894; 20 Jun 96 13:38 EDT Received: by relay.tis.com; id NAA14895; Thu, 20 Jun 1996 13:39:58 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma014889; Thu, 20 Jun 96 13:39:31 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA24097; Thu, 20 Jun 96 13:39:29 EDT Received: by relay.tis.com; id NAA14880; Thu, 20 Jun 1996 13:39:28 -0400 Received: from stilton.cisco.com(171.69.1.161) by relay.tis.com via smap (V3.1.1) id xma014873; Thu, 20 Jun 96 13:39:05 -0400 Received: from cisco.com (localhost.cisco.com [127.0.0.1]) by stilton.cisco.com (8.6.8+c/8.6.5) with ESMTP id KAA03189; Thu, 20 Jun 1996 10:41:32 -0700 Message-Id: <199606201741.KAA03189@stilton.cisco.com> To: Robert Moskowitz Cc: ipsec@TIS.COM Subject: Re: l2f and Cisco??? In-Reply-To: Your message of "Thu, 20 Jun 1996 10:54:19 EDT." <2.2.32.19960620145419.00b74e04@pop3hub.is.chrysler.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <3185.835292491.1@cisco.com> Date: Thu, 20 Jun 1996 10:41:32 -0700 From: David Carrel Sender: ipsec-approval@neptune.tis.com Precedence: bulk > Pointcast had a press release from last night from Cisco, Nortell, and Shiva > announcing 'layer two forwarding' that they had submitted to the IETF for a > standard. > > Can the Cisco and other members here comment on what l2f gives over ipsec? > Why should l2f become more than an informational RFC and why even is it neede > d? Bob, L2F and IPSEC play very different roles. In fact the two can be used together to play a quite useful role. l2f provides for tunneling of remote access users to a central location so their connectivity appears similar no matter what access point they use. (ie. if I dialed into ANY of my service providers dialup pools, in any city, I would still get the same network connectivity as if I dialed into cisco directly.) Another benefit is the MUXing of multiple users over a single (presumably lower cost) long haul link (internet, frame relay, ...). This protocol (and another called PPTP) are being discussed on the ppp list Dave Received: from relay.tis.com by neptune.TIS.COM id aa29940; 20 Jun 96 18:40 EDT Received: by relay.tis.com; id SAA24355; Thu, 20 Jun 1996 18:41:59 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma024349; Thu, 20 Jun 96 18:41:40 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA09113; Thu, 20 Jun 96 18:41:36 EDT Received: by relay.tis.com; id SAA24330; Thu, 20 Jun 1996 18:41:34 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1) id xma024316; Thu, 20 Jun 96 18:41:20 -0400 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id PAA24572; Thu, 20 Jun 1996 15:43:53 -0700 Received: by mailsun2.us.oracle.com (8.7.1/37.8) id PAA03008; Thu, 20 Jun 1996 15:47:15 -0700 (PDT) Message-Id: <199606202247.PAA03008@mailsun2.us.oracle.com> Date: 20 Jun 96 13:36:30 -0700 From: "PALAMBER.US.ORACLE.COM" To: gnu@toad.com Subject: UUNET Blocks Internet Security with Bogus Patent Cc: rick@uunet.uu.net, ipsec@TIS.COM X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:tytso@MIT.EDU's message of 18-Jun-96 22:24 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Boundary-5485862-0-0 Sender: ipsec-approval@neptune.tis.com Precedence: bulk --Boundary-5485862-0-0 John, Has anyone at UUNET given an opinion on the validity or licensing of this patent relative to the IPsec committee? Paul -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com -------------------------------------------------------------- --Boundary-5485862-0-0 Content-Type: message/rfc822 Date: 18 Jun 96 22:24:18 From:"Theodore Y. Ts'o" To: PALAMBER@us.oracle.com Subject: Re: Network Layer Encryption History and Prior Art Cc: ipsec@tis.com,JHAVERTY@us.oracle.com,gnu@toad.com X-Orcl-Application: In-Reply-To: PALAMBER.US.ORACLE.COM's message of 18 Jun 96 18:11:26 -0700, X-Orcl-Application: In-Reply-To: <199606190152.SAA01090@mailsun2.us.oracle.com> X-Orcl-Application: Address: 1 Amherst St., Cambridge, MA 02139 X-Orcl-Application: Phone: (617) 253-8091 Date: 18 Jun 96 18:11:26 -0700 From: "PALAMBER.US.ORACLE.COM" The research and development of "Network Security" started in the late 70's at BBN with the development of the "IPLI". Classified research and development continued in this area on the Blacker (Unisys) and Caneware (Motorola) programs in the early 80's. The NSA sponsored Secure Data Network System (SDNS) project brought together a variety of vendors that created the early SP3, KMP and MSP specifications. SP3 provided network layer security services that included a tunneling mode. SP3 is very similar to the IPsec working group ESP specification. The Key Management Protocol (KMP) is similar to the ISAKMP specification in concept, but used ASN.1 for specifying the protocol formats. Much of the SDNS work was openly published starting in about 1988. The Motorola Network Encryption System (NES) is an SDNS device and was designed in the mid to late 80's. Paul, thanks for the history lesson!! John (Gilmore), is this what you were looking for in terms of real Prior Art to take to Rick Adams, so he'll drop the patent claims? The SP3 specifications should hopefully be detailed enough to satisfy a Patent Attorney as being Real Prior Art in the Patent Context. The only question is whether or not there's enough there to take out all of the claims in UUNET's patent (or at least enough so that IPSEC won't be have to worry about infringing the UUNET patent.) - Ted --Boundary-5485862-0-0-- Received: from relay.tis.com by neptune.TIS.COM id aa06354; 21 Jun 96 4:04 EDT Received: by relay.tis.com; id EAA29279; Fri, 21 Jun 1996 04:06:39 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma029277; Fri, 21 Jun 96 04:06:10 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20814; Fri, 21 Jun 96 04:06:12 EDT Received: by relay.tis.com; id EAA29274; Fri, 21 Jun 1996 04:06:09 -0400 Received: from toad.com(140.174.2.1) by relay.tis.com via smap (V3.1.1) id xma029272; Fri, 21 Jun 96 04:05:40 -0400 Received: from localhost (localhost [127.0.0.1]) by toad.com (8.7.5/8.7.3) with SMTP id BAA00745; Fri, 21 Jun 1996 01:08:15 -0700 (PDT) Message-Id: <199606210808.BAA00745@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: "PALAMBER.US.ORACLE.COM" Cc: ipsec@TIS.COM, farber@cis.upenn.edu Cc: "Jonathan M. Smith" , gnu@toad.com Subject: Re: UPenn Network Encryption Patent In-Reply-To: <9606192246.AA00282@maildig1.us.oracle.com> Date: Fri, 21 Jun 1996 01:08:14 -0700 From: John Gilmore Sender: ipsec-approval@neptune.tis.com Precedence: bulk I shelled out the $3.75 to casweb.cas.org to download this patent too. (Gee, this list is full of cheapskates ;-} or people who don't know that you can get online patent text easily via the Web now.) I've added it to the Network Encryption page at http://www.cygnus.com/~gnu/netcrypt.html. I did a quick scan of the Jonathan Smith's (UPenn) patent, and it doesn't seem to apply to IPSEC. All of the claims relate to ATM networks which segment packets into cells with virtual channel ID's. Amazingly, UPenn's patent lawyer never bothered to include the claims generalizing their invention to any physical medium! John Received: from relay.tis.com by neptune.TIS.COM id aa09366; 21 Jun 96 8:11 EDT Received: by relay.tis.com; id IAA02089; Fri, 21 Jun 1996 08:12:54 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma002075; Fri, 21 Jun 96 08:12:30 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25810; Fri, 21 Jun 96 08:12:31 EDT Received: by relay.tis.com; id IAA02067; Fri, 21 Jun 1996 08:12:26 -0400 Received: from central.cis.upenn.edu(158.130.12.2) by relay.tis.com via smap (V3.1.1) id xma002060; Fri, 21 Jun 96 08:12:19 -0400 Received: (jms@localhost) by central.cis.upenn.edu (8.6.12/UPenn 1.4) id IAA18114; Fri, 21 Jun 1996 08:11:03 -0400 Date: Fri, 21 Jun 1996 08:11:03 -0400 From: "Jonathan M. Smith" Posted-Date: Fri, 21 Jun 1996 08:11:03 -0400 Message-Id: <199606211211.IAA18114@central.cis.upenn.edu> To: PALAMBER@us.oracle.com, gnu@toad.com Subject: Re: UPenn Network Encryption Patent Cc: farber@central.cis.upenn.edu, ipsec@TIS.COM Content-Length: 275 Sender: ipsec-approval@neptune.tis.com Precedence: bulk Hi John - yes but since it uses a discriminator associated with the source and destination (VCI) it should really make it hard for the UUNET patent to cause IPSEC problems. At least if Joe Touch's note summarized the main concern. And our lawyers, well.....yes. -JMS Received: from relay.tis.com by neptune.TIS.COM id aa03374; 23 Jun 96 0:47 EDT Received: by relay.tis.com; id AAA01593; Sun, 23 Jun 1996 00:49:39 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma001589; Sun, 23 Jun 96 00:49:11 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20941; Sun, 23 Jun 96 00:49:15 EDT Received: by relay.tis.com; id AAA01584; Sun, 23 Jun 1996 00:49:09 -0400 Received: from ns.incog.com(199.190.177.251) by relay.tis.com via smap (V3.1.1) id xma001580; Sun, 23 Jun 96 00:49:07 -0400 Received: from osmosys.incog.com by incog.com (SMI-8.6/94082501) id VAA12652; Sat, 22 Jun 1996 21:50:50 -0700 Received: from monster.incog.com by osmosys.incog.com (SMI-8.6/SMI-SVR4) id VAA02399; Sat, 22 Jun 1996 21:52:25 -0700 Received: by monster.incog.com (SMI-8.6/SMI-SVR4) id VAA07506; Sat, 22 Jun 1996 21:51:54 -0700 Date: Sat, 22 Jun 1996 21:51:54 -0700 From: Tom Markson Message-Id: <199606230451.VAA07506@monster.incog.com> To: ipsec@TIS.COM Subject: SKIP Beta2.3 is Released Sender: ipsec-approval@neptune.tis.com Precedence: bulk We are pleased to announce the latest release of the SKIP domestic source reference implementation into the public domain. This represents a major release and includes many new features. It interoperates with several other independent SKIP implementations. Both FreeBSD 2.1.0 and SunOS 4.1.3 are supported in this release. DES, triple-DES and SAFER are supported for encryption and keyed-MD5 is supported for authentication. This source produces a package which contains a loadable module which works with existing TCP/IP stacks. You do not need to replace (or even recompile) your IP stack to use this package. Source and pre-built binaries (for FreeBSD 2.1.0) may be obtained by US and Canadian citizens from http://skip.incog.com/ This software may be used without restriction, for commercial and/or non-commercial purposes. Features of this release ------------------------ o Support for FreeBSD2.1.0 o SKIP V2 compliant implementation using ESP and AH encapsulation. o Support for Authentication using keyed-MD5. o Support for DES, 3DES, and SAFER 128SK for traffic and key encryption. o Support for nomadic users o Support for multiple local identities with different sets of parameters. o Support for multiple CA (Certificate Authority) certificates. o Transport mode is supported. o New Certificate Discovery protocol. o Highly configurable key manager. o Support for RAW AH and ESP protocols. o Diffie-Hellman Public Key Agreement based system. o Support for multiple NSIDs and multiple local certificates. o GUI tool for user friendly manipulation of access control lists and key statistics. o Command line tools for manipulating access control lists, etc. o Implementation of the Certificate Discovery protocol fully integrated into SKIP. o Implementation of X.509 public key certificates. o Implementation of DSA signature algorithm for certificate signatures. o Implementation for MD2, MD5 and SHA message digest algorithms. o Implementation of ASN.1 DER encoding/decoding. o SunScreen(tm) SKIP compatibility mode. o Implementation of hashed public keys as defined in the SKIP draft. Implementation of programs to generate hashed public keys, to convert X.509 Certificates to hashed keys and print both X.509 and Hashed certificates. o High performance Big Number library for Diffie-Hellman calculations. o Implementation is effectively "public domain" and may be used both commercially and non-commercially. o Patent Agreement with Cylink allows royalty-free use of the Diffie-Hellman and other Stanford patents with this package for commercial and non-commercial use. Read README.PATENT for some restrictions. o Inclusion of prime generation program used to generate the primes in SKIP draft. Received: from relay.tis.com by neptune.TIS.COM id aa06430; 25 Jun 96 3:03 EDT Received: by relay.tis.com; id DAA06365; Tue, 25 Jun 1996 03:05:28 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma006362; Tue, 25 Jun 96 03:04:59 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA24178; Tue, 25 Jun 96 03:05:03 EDT Received: by relay.tis.com; id DAA06359; Tue, 25 Jun 1996 03:04:58 -0400 Received: from inet-user-gw-1.us.oracle.com(192.86.155.82) by relay.tis.com via smap (V3.1.1) id xma006357; Tue, 25 Jun 96 03:04:51 -0400 Received: from mailsun2.us.oracle.com by inet-user-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id AAA15185; Tue, 25 Jun 1996 00:07:25 -0700 Received: by mailsun2.us.oracle.com (SMI-8.6/37.8) id AAA25404; Tue, 25 Jun 1996 00:07:18 -0700 Message-Id: <199606250707.AAA25404@mailsun2.us.oracle.com> Date: 24 Jun 96 20:44:08 -0700 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: IPsec Agenda X-Orcl-Priority: High Cc: PALAMBER@us.oracle.com Mime-Version: 1.0 X-Mailer: Oracle InterOffice (version 2.1.16.1.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Agenda of the IPSEC Working Group Thirty-Sixth IETF - Montreal (June 25 -26, 1996) TUESDAY, June 25, 1996 1530-1730 IP Security Protocol WG 15:30 Introductions - brief background - work items and drafts - liaisons ------ ESP/AH ------ 15:45 "Combined DES-CBC, HMAC and Replay Prevention Security Transform", J. Hughes draft-ietf-ipsec-esp-des-md5-02.txt 16:05 "DES-CBC + DES-MAC security transform", Dan Frommer draft-frommer-sec-transform-00.txt 16:20 S/WAN Status, Brett Howard 16:30 Near Term Deployment, John Gilmore 16:40 IPsec and Firewalls, Michael Richardson 17:00 IPsec Architecture Documents, Ran Atkinson 17:15 Open Work Items (discussion), Paul Lambert 17:25 Summary and Action Items 17:30 Adjourn WEDNESDAY, June 26, 1996 1530-1730 IP Security Protocol WG 15:00 Introduction (second meeting) 15:35 DNS interoperability challenge, Bob Moskowitz Automotive interoperability challenge, Bob Moskowitz 15:45 SKIP Update, RSVP & CDP, Tom Markson "Certificate Discovery Protocol" draft-ietf-ipsec-cdp-01.txt 16:05 Comments on oakley-isakmp draft, Hugo Krawczyk also draft-ietf-ipsec-hmac-md5-00.txt 16:15 "Internet Security Association and Key Management Protocol (ISAKMP)", D. Maughan, M. Schertler, M. Schneider, J. Turner draft-ietf-ipsec-isakmp-05.txt, .ps 16:45 "The resolution of ISAKMP with Oakley",D. Harkins, D. Carrel draft-ietf-ipsec-isakmp-oakley-00.txt 17:05 Elliptic Curves, Scott Vanstone (Certicom) 17:25 Summary and Action Items 17:30 Adjourn Received: from relay.tis.com by neptune.TIS.COM id aa06729; 26 Jun 96 15:13 EDT Received: by relay.tis.com; id PAA20172; Wed, 26 Jun 1996 15:15:14 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma020159; Wed, 26 Jun 96 15:14:46 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA09871; Wed, 26 Jun 96 15:14:48 EDT Received: by relay.tis.com; id PAA20156; Wed, 26 Jun 1996 15:14:44 -0400 Received: from unknown(160.239.177.30) by relay.tis.com via smap (V3.1.1) id xma020149; Wed, 26 Jun 96 15:14:22 -0400 Received: from orient.soliton.co.jp (takahashi1.rdd.soliton.co.jp [160.239.194.53]) by soliton.co.jp (8.6.9+2.4Wb/3.3Wb95101700) with SMTP id EAA10688 for ; Thu, 27 Jun 1996 04:11:54 +0900 Message-Id: <9606261918.AA00168@orient.soliton.co.jp> Date: Thu, 27 Jun 1996 04:18:17 +0900 From: Kiyotaka Takahashi To: ipsec@TIS.COM Subject: [Q] AH and ESP X-Mailer: AL-Mail 1.12 Sender: ipsec-approval@neptune.tis.com Precedence: bulk Hello all, My name is Kiyotaka Takahashi. I'm now working for PC based IPSec system in the Security Group. I have read the draft-ietf-ipsec-arch-sec-00.txt(4 June 1996). I have a few questions. 1) Why is a single IPsec Security Association never for both ESP and AH? 2) Is there two modes within AH, like ESP has tunnel-mode and transport-mode? Would anyone tell me an answer to my question. Best regards, T.Kiyotaka -- Soliton Systems K.K.,R&D Takahashi Kiyotaka E-Mail: takahasi@soliton.co.jp Tel:03(5360)3830;Fax:03(3356)6890 Received: from relay.tis.com by neptune.TIS.COM id aa13991; 30 Jun 96 21:50 EDT Received: by relay.tis.com; id VAA27923; Sun, 30 Jun 1996 21:52:07 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma027921; Sun, 30 Jun 96 21:51:38 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01089; Sun, 30 Jun 96 21:51:40 EDT Received: by relay.tis.com; id VAA27918; Sun, 30 Jun 1996 21:51:37 -0400 Received: from ns.research.att.com(192.20.225.4) by relay.tis.com via smap (V3.1.1) id xma027916; Sun, 30 Jun 96 21:51:22 -0400 Received: from research.research.att.com by ns; Sun Jun 30 21:52:07 EDT 1996 Received: from smb.research.att.com by research; Sun Jun 30 21:48:14 EDT 1996 Received: from smb.research.att.com (smb@localhost) by smb.research.att.com (8.6.12/8.6.10) with ESMTP id TAA00201 for ; Sun, 30 Jun 1996 19:20:07 -0400 Message-Id: <199606302320.TAA00201@smb.research.att.com> X-Authentication-Warning: smb.research.att.com: smb owned process doing -bs From: Steve Bellovin MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM To: ipsec@TIS.COM Subject: deriving keying material from the shared secret Date: Sun, 30 Jun 1996 19:18:51 -0400 Sender: ipsec-approval@neptune.tis.com Precedence: bulk The particular secrecy and authentication transforms we are considering need varying amounts of keying material. For example, the current ESP draft (draft-ietf-ipsec-esp-des-md5-02.txt) uses two 56-bit DES keys (though it extracts 64-bit chunks), a single 64-bit IV (why one instead of two?), and a 128-bit HMAC key. A mechanism for deriving these keys from the shared secret is given in the text; it involves a 512-bit pad field whose contents varies, and MD5. By contrast, the current MD5-HMAC draft (draft-ietf-ipsec-ah-hmac-md5-00.txt) uses a variable-length key apparently taken directly from the shared secret, crunching it through MD5 if needed to reduce it to 64 bytes if needed. I suggest that we have one standard method of extracting keys from the shared secret, probably spelled out in a separate RFC. It is important, in my opinion, to make it extremely difficult to derive one key given one of the others derived from the same shared secret. For example, suppose one can determine the IV used for the ESP transform as defined; we don't want to make it easy to determine the session keys from the IV. The derivation mechanism used in the ESP draft is probably wrong, since it uses MD5 run on the concatenation of a constant string (which differs for each key) and the shared secret. Since the constant string is 64 bytes long, the natural input block length of MD5, when the secret is crunched in it is equivalent to running MD5' on just the secret, where MD5 differs from MD5 only in the starting values of the state registers A, B, C, D. If the shared secret is, say, 155 bits (and I think that that will be common, if elliptic curves are used and if I'm reading the Oakley spec correctly), then the attacker need only go after one of the simpler cases for attacking MD5. (A forthcoming draft paper will show why it may be relatively easier to get the key for one direction than for the other. And given the key, the IV is trivial to recover.) Possibly, we should run HMAC on the padding string, using the shared secret as the key. At the least, I suggest that MD5(key,constantstring) would be more secure. Comments?