A team from U. of Pennsylvania also obtained patent '623 on network encryption. However, their patent's claims are restricted to use in ATM networks, in which packets are broken up into cells. The patent filing was based on this paper: Jonathan M. Smith, C. Brendan S. Traw, and David J. Farber, "Cryptographic Support for a Gigabit Network," in Proceedings, INET '92, Kobe, JAPAN (June 15-18, 1992), pp. 229-237. (Inaugural Conference of the Internet Society),
The Sun SKIP team has also obtained patent '646 on network encryption. Here are the drawing pages from the patent as well: 2, 3, 4, 5, 6, 7, 8. If someone would write a brief summary of this patent, I would insert it here; send it to gnu@toad.com. Sun's legal department has stated that if any prior art turns up which is "more relevant than the art that was before the Patent Office" they will bring it before the Patent Office to reconsider the patent's claims. (Both the patents their statement refers to are accessible on this page, in the following paragraphs.)
The Sun SKIP team has dedicated two previous patent applications (one of which resulted in issued patent '842) to the public:
Sun Microsystems, Inc., in the interest of promoting an open-systems, standardized approach to key management for use on the Internet, is taking the step of dedicating important intellectual property rights in this area to the public. Sun has submitted a proposed specification to the IETF entitled "Simple Key Management Scheme for Internet Protocols (SKIP)". On June 10 1994, Sun filed two patent applications with the United States Patent Office relating to SKIP, entitled "Method and Apparatus for a Key Management Scheme for Internet Protocols", Serial No. 08/258,272; and "Method and Apparatus for Key Management Scheme for Use with Internet Protocols at Site Firewalls", Serial No. 08/258,344. Sun wishes to dedicate its rights under these two applications to the public, and to that end hereby licenses all persons and companies to practice the SKIP procedures claimed in these patent applications (and in the patents resulting from the applications, when and if they issue). This license is immediately effective, and requires no fee.IBM has a patent that cover some techniques for key refreshment (more precisely for two-party authentication protocols). IBM has granted a free license for use of this patent (US Patent 5,148,479) in connection to IKMP. For the exact "grant of rights" text see RFC 1822. Therefore, there is no reason to avoid these techniques; in particular, Oakley incorporates them already.
BTW [says Hugo Krawczyk, hugo@watson.ibm.com], this [IBM] patent (filed 3/91 issued 9/92) pre-dates any work in the IPSEC WG. None of the new work that we did in relation to this WG activity (e.g., MKMP, SKEME, HMAC) and which is now incorporated into current WG drafts (Oakley, AH, etc) has been patented by us.
DEC has a '961 patent on a network encryption system. It is focused on multilevel-secure systems, but some of its claims might apply to ordinary systems.
Netscape has a '390 patent on its Secure Sockets Layer encryption, which is very similar to IP Security except that it's done on a socket-by-socket rather than a packet-by-packet basis. Many people believe it's invalid due to prior art. The patent includes a full source-code listing of their SSL implementation, though the patent-search service I use didn't provide it as text. You can get crummy fax images of the source code from the IBM patent server.
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.
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 cost 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).
[VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level
Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983.
%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 LaboratoriesIt'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.
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.
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.
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.
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.
Ioannidis & Blaze, "Architecture and Implementation of Network-Layer Security under Unix." USENIX Security Conference, October 1993.
Ioannidis & Blaze, "The swIPe IP security protocol." Internet Draft. December 1993.
http://town.hall.org/trendy/sipp/sipp-doc/sipp-whitepaper.TXT
It might be prudent for you to download the source for that file to your own web site lest it get accidentally deleted from town.hall.org in future.
I'm still searching for the original draft-ietf-sipp-sa-00.txt, draft-ietf-sip-esp-00.txt, and draft-ietf-sip-ap-00.txt which were put online as formal Internet-Drafts on 31 Jan 1994 and had been circulating on the SIP list well prior to that. Email announcements of those drafts to the main IETF list are still archived among the IETF main list archives for 1993 at http://www.ima.com.
The ESP spec is directly derived from the US Government's SP-3 specification published by NIST as a Special Publication in the late 1980s (1988 perhaps). AH is derived from SP-3 and from SNMP Security. The ISO Network Layer Security Protocol (NLSP) is another SP-3 derivative that was published in draft form by July 1991. Initially, the IPsec working group had looked at NLSP as a possible basis for an IETF standard.
...
See also Steve Deering's paper "SIP: Simple Internet Protocol"
in the May 1993 issue of IEEE Networks magazine. I believe it
includes mention of ESP and AH (then called AP) in the article.
...
Additional relevant prior art is in the following article, located
online at
http://csrc.ncsl.nist.gov/nistgen/sp4rpt.txt.
The date is particularly interesting to me.
Charles Dinkel, et. al., "Prototyping SP4: A Secure Data Network System (SDNS) Transport Protocol Interoperability Demonstration Project", NIST Information Report 90-4228, NIST, Gaithersburg, MD, 1990.
The one element that does not appear in Tsudik's work is truncation. However, truncating the output of MAC functions is an old and very well known practice in cryptography. For example,
[MM] Meyer, S. and Matyas, S.M., Cryptography, New York Wiley, 1982.
[ANSI] ANSI X9.9, ``American National Standard for Financial Institution Message Authentication (Wholesale),'' American Bankers Association, 1981. Revised 1986.
and therefore a hard to defend claim (I'm not a lawyer!!).
After consulting with Jeff Schiller and the WG chairs, it became clear to me that the existence of Novell's patent shouldn't be an obstacle to include a section on truncation in the HMAC rfc, and more significantly, to propose it for adoption for AH-HMAC-SHA.
Circa 1987-8, Casey and McDermott (and Steve Kent?) of BBN developed several SURAN security architecture approaches and developed detailed algorithms and designs that included various encryption techniques. Although the architecture was not implemented, the architecture design included techniques similar to those now in standard network encryption designs and products. I believe that some of their reports are available from DTIC.
It seems that Netscape was just granted a US patent on the idea of the SSL protocol. From reading the abstract (at patents.uspto.gov), there might be a chance the patent applies to SSH. If SSH was publicly released before the filing date, then it should be clear of the patent. Otherwise it might be wise to check with a patent lawyer...
From drummond@aristarchus.rutgers.edu Thu Jul 21 17:00:10 1994
Flags: 000000000001
Received: from ns1.rutgers.edu by hardees.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA19226; Thu, 21 Jul 94 17:00:10 EDT
Received: from aristarchus.rutgers.edu by ns1.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA07899; Thu, 21 Jul 94 17:00:07 EDT
Received: by aristarchus.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA16801; Thu, 21 Jul 94 16:59:54 EDT
Date: Thu, 21 Jul 94 16:59:51 EDT
From: Walt Drummond
To: www-talk@www0.cern.ch
Cc: www-security@ns1.rutgers.edu
Subject: WWW Security mailing list
Message-Id:
Hi all:
Internally, Rutgers has been discussing different methods of
providing secure WWW service. We've decided to open this discussion
up to the rest of the WWW community, and have created yet another
mailing list. This list will focus on how to secure HTTP and/or
HTTP-like protocols to provide:
o Privacy
o User Authentication
o Service Certification
o Document Checking (Digital Signatures)
and anything that I've forgotten!
To subscribe, send mail with a body of:
subscribe www-security
to www-security-request@nsmx.rutgers.edu
Messages should be sent to www-security@nsmx.rutgers.edu
(big surprise, I know.. :)
Walt
_________________________________________________________
Walt Drummond (drummond@noc.rutgers.edu)
Network Services
Rutgers University Computing Services
- Lost: One mind. Owner sad. Reward.
From scooper@hardees.rutgers.edu Thu Jul 21 17:04:18 1994
Flags: 000000000001
Received: from ns1.rutgers.edu by hardees.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA19419; Thu, 21 Jul 94 17:04:18 EDT
Received: from hacksaw.rutgers.edu by ns1.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA08038; Thu, 21 Jul 94 17:04:17 EDT
Received: (from scooper@localhost) by hacksaw.rutgers.edu (8.6.8.1+bestmx/8.6.6) id RAA03769; Thu, 21 Jul 1994 17:01:17 -0400
Date: Thu, 21 Jul 1994 17:01:17 -0400
From: Simon Cooper
Message-Id: <199407212101.RAA03769@hacksaw.rutgers.edu>
To: www-security@ns1.rutgers.edu
Subject: Outline RUSSL document.
The "really sketchy" version of the RUSSL document is now available via
WWW, the URL is
http://www-ns.rutgers.edu/~scooper/rucs/russl_doc.html
You can find the ITU (CCITT) series of documents in
~scooper/Info.new/docs/ccitt
The IETF documents referenced are in,
~scooper/Info.new/docs/ietf
The exact locations of where these documents came from are stored in
.desc.{pag,dir} dir files if you need to refetch them. (I have tools in my
$BIN directory :- "dl" and "describe" that update and access these dbm
files).
Simon.
Also, I have witnessed documents, and prototypes of a device that I developed probably well before the UUNET device, and have continued to develop and try to commercialize since then. From the information appearing in the working group, it very much seems that their box is a lot like my box.