From owner-freebsd-security Fri Nov 24 06:42:17 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA22253 for security-outgoing; Fri, 24 Nov 1995 06:42:17 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA22237 for ; Fri, 24 Nov 1995 06:42:13 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id GAA01869 for ; Fri, 24 Nov 1995 06:40:18 -0800 To: security@freebsd.org Subject: I wonder how much trouble something like this would be to do? :) Date: Fri, 24 Nov 1995 06:40:17 -0800 Message-ID: <1867.817224017@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-security@freebsd.org Precedence: bulk Someone sent me this. It sounds like "one of those really simple engineering ideas that marketing got ahold of and hyped the heck outta" but still - I can think of more than a few MIS managers who'd just eat this up. Jordan ---- UG565-07 DEC's SECURE INTERNET ROUTE Tunneling - transporting data from one point to another encapsulated in wrapper packets - is a networking technique that's been around for some years. Claiming to have its neck ahead of the pack, Digital Equipment Corp says its Internet Tunnel has extended this capability to provide encryption and authentication technologies for the Internet enabling corporate data to be transmitted securely over the net (UX No 562). Digital Internet Tunnel uses a regular Internet Protocol (IP) jacket, encrypted and encapsulated inside a TCP/IP packet. The source and destination IP applications work as normal, but data on the network between the two tunnel servers appears scrambled. When a client wants to initiate a connection with an Internet Group Tunnel server, a connection request is sent over the network. The connection request message contains an identification message that is encrypted by the client with the server's public key, and then decrypted by the server with its own private key. The server's database contains a list of clients that are authorised to establish tunnels. If and when the request has been granted, the tunnel server sends a response encrypted using the client's public key, which is then decrypted by the client using its private key. After the authentication session, the two parties exchange portions of a session key, which is then combined to form a secret session key. DEC uses the encryption technology, devised by Rivest, Shamir and Adeleman, known as RSA. Versions for the US and Canada use a 128-bit RC4 key, international versions (because of US government restrictions) a 40-bit version only. The session key is changed periodically to enhance security. The tunnel comes in two flavours, the Group tunnel and the Personal tunnel. The Group tunnel software runs on Digital Unix, with a SLIP (Serial Line Internet Protocol), PPP (Point to Point protocol), Ethernet or FDDI (Fibre distributed data interface) connection. It manages the construction and operation of tunnels from other tunnel servers. Performance is based on system configuration and end-to-end network throughput; DEC claims to support up to 512 tunnel connections. The authentication key generation and management software is included with the Tunnel product. Personal Tunnel software installed on a PC must have Windows 95 TCP/IP software active, connected to a network with connectivity and using a valid IP address for the local subnet. Personal Tunnel includes a Win32 Windows-based application to enable the request, operation and management of an encrypted tunnel. The Internet Tunnel is meant to complement firewall products, and unlike other tunnel products is said to be firewall-independent. DEC reckons its tunneling technology differs from router and firewall vendors because it offers connections from home or mobiles to the corporate network, whereas routers only provide a single private data circuit and do not support end to end or trans-Internet privacy. Firewall tunneling products require the use of their tunnels at both ends, since interoperability standards don't exist, says the company. DEC says its approach also wins out over Netscape's SSL (Secure Socket layer) protocol, which also uses RSA encryption, because its used at a different level of the IP stack. SSL encrypts information for applications, while tunnels establish a link for all connections between two networks. With Netscape applications the need to encrypt a specific session, such as Web browsers, Telnet or FTP must be modified to enable the request for an encrypted link. In contrast, Digital Internet tunnel applications are not modified, it says, and all the traffic between the tunnels is encrypted. The international version is due next month. Prices start at $10,000 on Digital Unix and comes with DEC's own Firewall Unix, $3,600 on PCs. From owner-freebsd-security Fri Nov 24 08:45:26 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA02734 for security-outgoing; Fri, 24 Nov 1995 08:45:26 -0800 Received: from kilgour.nething.com (kilgour.nething.com [204.253.210.65]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA02718 for ; Fri, 24 Nov 1995 08:45:21 -0800 Received: from randy.nething.com (randy.nething.com [204.253.210.83]) by kilgour.nething.com (8.6.11/8.6.9) with SMTP id KAA26846; Fri, 24 Nov 1995 10:44:06 -0600 Date: Fri, 24 Nov 1995 10:44:06 -0600 Message-Id: <199511241644.KAA26846@kilgour.nething.com> X-Sender: rberndt@nething.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Jordan K. Hubbard" , security@FreeBSD.ORG From: Randy Berndt Subject: Re: I wonder how much trouble something like this would be to do? :) Sender: owner-security@FreeBSD.ORG Precedence: bulk Wow, only $3,600 for the PC version. I wonder if Dec has looked on the ftp site: ftp.cs.hut.fi:/pub/ssh for the ssh program, that does much the same thing for telnet, rlogin type stuff for FREE. At 06:40 AM 11/24/95 -0800, Jordan K. Hubbard wrote: >Someone sent me this. It sounds like "one of those really simple >engineering ideas that marketing got ahold of and hyped the heck >outta" but still - I can think of more than a few MIS managers who'd >just eat this up. > > Jordan >---- >UG565-07 DEC's SECURE INTERNET ROUTE > >Tunneling - transporting data from one point to another >encapsulated in wrapper packets - is a networking technique >that's been around for some years. Claiming to have its neck >ahead of the pack, Digital Equipment Corp says its Internet >Tunnel has extended this capability to provide encryption and >authentication technologies for the Internet enabling corporate >data to be transmitted securely over the net (UX No 562). Digital >Internet Tunnel uses a regular Internet Protocol (IP) jacket, >encrypted and encapsulated inside a TCP/IP packet. The source and >destination IP applications work as normal, but data on the >network between the two tunnel servers appears scrambled. When a >client wants to initiate a connection with an Internet Group >Tunnel server, a connection request is sent over the network. The >connection request message contains an identification message >that is encrypted by the client with the server's public key, and >then decrypted by the server with its own private key. The >server's database contains a list of clients that are authorised >to establish tunnels. If and when the request has been granted, >the tunnel server sends a response encrypted using the client's >public key, which is then decrypted by the client using its >private key. After the authentication session, the two parties >exchange portions of a session key, which is then combined to >form a secret session key. DEC uses the encryption technology, >devised by Rivest, Shamir and Adeleman, known as RSA. Versions >for the US and Canada use a 128-bit RC4 key, international >versions (because of US government restrictions) a 40-bit version >only. The session key is changed periodically to enhance >security. The tunnel comes in two flavours, the Group tunnel and >the Personal tunnel. The Group tunnel software runs on Digital >Unix, with a SLIP (Serial Line Internet Protocol), PPP (Point to >Point protocol), Ethernet or FDDI (Fibre distributed data >interface) connection. It manages the construction and operation >of tunnels from other tunnel servers. Performance is based on >system configuration and end-to-end network throughput; DEC >claims to support up to 512 tunnel connections. The >authentication key generation and management software is included >with the Tunnel product. Personal Tunnel software installed on a >PC must have Windows 95 TCP/IP software active, connected to a >network with connectivity and using a valid IP address for the >local subnet. Personal Tunnel includes a Win32 Windows-based >application to enable the request, operation and management of an >encrypted tunnel. The Internet Tunnel is meant to complement >firewall products, and unlike other tunnel products is said to be >firewall-independent. DEC reckons its tunneling technology >differs from router and firewall vendors because it offers >connections from home or mobiles to the corporate network, >whereas routers only provide a single private data circuit and do >not support end to end or trans-Internet privacy. Firewall >tunneling products require the use of their tunnels at both ends, >since interoperability standards don't exist, says the company. >DEC says its approach also wins out over Netscape's SSL (Secure >Socket layer) protocol, which also uses RSA encryption, because >its used at a different level of the IP stack. SSL encrypts >information for applications, while tunnels establish a link for >all connections between two networks. With Netscape applications >the need to encrypt a specific session, such as Web browsers, >Telnet or FTP must be modified to enable the request for an >encrypted link. In contrast, Digital Internet tunnel applications >are not modified, it says, and all the traffic between the >tunnels is encrypted. The international version is due next >month. Prices start at $10,000 on Digital Unix and comes with >DEC's own Firewall Unix, $3,600 on PCs. > > > > > Randy Berndt ---------------------------------- AOS/VS, FreeBSD, DOS: I'm caught in a maze of twisty little command interpreters, all different. From owner-freebsd-security Fri Nov 24 08:54:31 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA04241 for security-outgoing; Fri, 24 Nov 1995 08:54:31 -0800 Received: from sivka.carrier.kiev.ua (root@sivka.carrier.kiev.ua [193.125.68.130]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA04195 for ; Fri, 24 Nov 1995 08:54:13 -0800 Received: from elvisti.kiev.ua (uucp@localhost) by sivka.carrier.kiev.ua (Sendmail 8.who.cares/5) with UUCP id SAA02576 for security@freebsd.org; Fri, 24 Nov 1995 18:56:57 +0200 Received: from office.elvisti.kiev.ua (office.elvisti.kiev.ua [193.125.28.33]) by spider2.elvisti.kiev.ua (8.6.12/8.ElVisti) with ESMTP id SAA26296 for ; Fri, 24 Nov 1995 18:04:57 +0200 Received: (from stesin@localhost) by office.elvisti.kiev.ua (8.6.12/8.ElVisti) id SAA13149; Fri, 24 Nov 1995 18:04:55 +0200 From: "Andrew V. Stesin" Message-Id: <199511241604.SAA13149@office.elvisti.kiev.ua> Subject: Re: I wonder how much trouble something like this would be to do? :) To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Fri, 24 Nov 1995 18:04:55 +0200 (EET) Cc: security@freebsd.org In-Reply-To: <1867.817224017@time.cdrom.com> from "Jordan K. Hubbard" at Nov 24, 95 06:40:17 am X-Mailer: ELM [version 2.4 PL24alpha5] Content-Type: text Content-Length: 1119 Sender: owner-security@freebsd.org Precedence: bulk # # Someone sent me this. It sounds like "one of those really simple # engineering ideas that marketing got ahold of and hyped the heck # outta" but still - I can think of more than a few MIS managers who'd # just eat this up. # # Jordan # ---- # UG565-07 DEC's SECURE INTERNET ROUTE # # Tunneling - transporting data from one point to another # encapsulated in wrapper packets - is a networking technique # that's been around for some years. Claiming to have its neck [...] So, we have two firewalled networks; each has a "tunelling proxy", which accepts connections from inside, and another -- from the outside (or may this be a single proxy program?) and -- voila, wer'e Ok, we have a secure channel over an insecure network? And we can have a single RFC#1597 network (or better to say a piece of address space), closed to the world, splitted into a few parts but transparently connected via a tunneled secure channels? Simple and cool. -- With best regards -- Andrew Stesin. +380 (44) 2760188 +380 (44) 2713457 +380 (44) 2713560 An undocumented feature is a coding error. From owner-freebsd-security Fri Nov 24 09:22:11 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA08060 for security-outgoing; Fri, 24 Nov 1995 09:22:11 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA08055 for ; Fri, 24 Nov 1995 09:22:03 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id JAA02513; Fri, 24 Nov 1995 09:19:16 -0800 To: Randy Berndt cc: security@FreeBSD.ORG Subject: Re: I wonder how much trouble something like this would be to do? :) In-reply-to: Your message of "Fri, 24 Nov 1995 10:44:06 CST." <199511241644.KAA26846@kilgour.nething.com> Date: Fri, 24 Nov 1995 09:19:16 -0800 Message-ID: <2511.817233556@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-security@FreeBSD.ORG Precedence: bulk > Wow, only $3,600 for the PC version. I wonder if Dec has looked on > the ftp site: ftp.cs.hut.fi:/pub/ssh for the ssh program, that does > much the same thing for telnet, rlogin type stuff for FREE. Yeah, but ssh is different. The DEC folks are encrypting *all* traffic between the networks, not just those clients that support end to end crypto. Yes, you and I may know that doing it one layer up is architecturally superior, but to the MIS manager who reads DEC's solution as "one big hammer" he won't have to worry too much about, well, the solution he'll pick will be obvious. Jordan From owner-freebsd-security Fri Nov 24 10:45:33 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA12723 for security-outgoing; Fri, 24 Nov 1995 10:45:33 -0800 Received: from multivac.orthanc.com (root@multivac.orthanc.com [204.244.20.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA12718 for ; Fri, 24 Nov 1995 10:45:29 -0800 Received: from localhost (lyndon@localhost) by multivac.orthanc.com (8.7/8.7) with SMTP id KAA27588; Fri, 24 Nov 1995 10:45:07 -0800 (PST) Message-Id: <199511241845.KAA27588@multivac.orthanc.com> X-Authentication-Warning: multivac.orthanc.com: Host lyndon@localhost didn't use HELO protocol From: Lyndon Nerenberg (VE7TCP) To: "Jordan K. Hubbard" cc: security@freebsd.org Subject: Re: I wonder how much trouble something like this would be to do? :) In-reply-to: Your message of "Fri, 24 Nov 1995 06:40:17 PST." <1867.817224017@time.cdrom.com> Date: Fri, 24 Nov 1995 10:45:04 -0800 Sender: owner-security@freebsd.org Precedence: bulk >>>>> "Jordan" == Jordan K Hubbard writes: Jordan> Someone sent me this. It sounds like "one of those really Jordan> simple engineering ideas that marketing got ahold of and Jordan> hyped the heck outta" but still - I can think of more than Jordan> a few MIS managers who'd just eat this up. No doubt. I first read about this several (at least three) years ago in one of the Usenix Security Conference proceedings. The paper described an implementation that had been done for 4.4BSD. I can try to dig out a reference if anyone's interested. Jordan> The international version is due Jordan> next month. Prices start at $10,000 on Digital Unix and Jordan> comes with DEC's own Firewall Unix, $3,600 on PCs. Har dee har har har. --lyndon From owner-freebsd-security Fri Nov 24 14:21:30 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA26735 for security-outgoing; Fri, 24 Nov 1995 14:21:30 -0800 Received: from multivac.orthanc.com (root@multivac.orthanc.com [204.244.20.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA26724 for ; Fri, 24 Nov 1995 14:21:20 -0800 Received: from localhost (lyndon@localhost) by multivac.orthanc.com (8.7/8.7) with SMTP id OAA28830; Fri, 24 Nov 1995 14:20:49 -0800 (PST) Message-Id: <199511242220.OAA28830@multivac.orthanc.com> X-Authentication-Warning: multivac.orthanc.com: Host lyndon@localhost didn't use HELO protocol From: Lyndon Nerenberg (VE7TCP) To: Bill Trost cc: security@freebsd.org Subject: Re: I wonder how much trouble something like this would be to do? :) In-reply-to: Your message of "Fri, 24 Nov 1995 13:12:35 PST." Date: Fri, 24 Nov 1995 14:20:47 -0800 Sender: owner-security@freebsd.org Precedence: bulk >>>>> "Bill" == Bill Trost writes: Bill> Lyndon Nerenberg writes: No doubt. I first read about this Bill> several (at least three) years ago in one of the Usenix Bill> Security Conference proceedings. The paper described an Bill> implementation that had been done for 4.4BSD. I can try to Bill> dig out a reference if anyone's interested. Bill> That's me. I took a look through my collection of Usenix proceedings. The paper did not jump out at me. Considering the number of volumes that have gone missing from my collection over the years, this is not surprising. I did a search through the index at usenix.org but nothing obvious turned up, although the following reference looks promising: Author: John Ioannidis Author: Matt Blaze Title: The Architecture and Implementation of Network Layer Security in UNIX Pages: 29-39 Publisher: USENIX Proceedings: UNIX Security IV Symposium Date: October 4-6, 1993 Location: Santa Clara, CA Institution: Columbia University Institution: AT&T Bell Laboritories It's close to the timeframe I remember reading the paper (fall 1991 to fall 1993). While searching the Usenix index I noticed a couple of papers from the Usenix Security V conference that looked promising. In particular: Author: Pau-Chen Cheng Author: Juan A. Garay Author: Amir Herzberg Author: Hugo Krawczyk Title: Design and Implementation of Modular Key Management Protocol and IP Secure Tunnel on AIX Pages: 41-54 Publisher: USENIX Proceedings: 5th USENIX UNIX Security Symposium Date: June 5-7, 1995 Location: Salt Lake City, UT Institution: IBM, Thomas J. Watson Research Center Anyway, I'll keep digging and let you know what turns up. If you decide to search your own collection, I vaguely remember a paper about forwarding FIDOnet articles over the Internet being in the same proceedings. (Don't ask me why ...) --lyndon From owner-freebsd-security Fri Nov 24 14:39:31 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA28014 for security-outgoing; Fri, 24 Nov 1995 14:39:31 -0800 Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA28002 for ; Fri, 24 Nov 1995 14:39:25 -0800 Received: from localhost (localhost [127.0.0.1]) by precipice.shockwave.com (8.6.12/8.6.12) with SMTP id OAA01327; Fri, 24 Nov 1995 14:20:05 -0800 Message-Id: <199511242220.OAA01327@precipice.shockwave.com> To: "Jordan K. Hubbard" cc: Randy Berndt , security@freebsd.org Subject: Re: I wonder how much trouble something like this would be to do? :) In-reply-to: Your message of "Fri, 24 Nov 1995 09:19:16 PST." <2511.817233556@time.cdrom.com> Date: Fri, 24 Nov 1995 22:20:05 +0000 From: Paul Traina Sender: owner-security@freebsd.org Precedence: bulk Pathetic given that IP security does exactly the same thing as DEC is proposing. Call your local router vendor to see when they're releasing it (I could tell you when cisco is, but then I'd have to kill myself). There should be several near-PD implementations of IPsec for Free/NetBSD coming out shortly. From owner-freebsd-security Fri Nov 24 18:42:19 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA16169 for security-outgoing; Fri, 24 Nov 1995 18:42:19 -0800 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA16160 for ; Fri, 24 Nov 1995 18:42:15 -0800 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id CAA02783; Sat, 25 Nov 1995 02:41:08 GMT From: Michael Smith Message-Id: <199511250241.CAA02783@genesis.atrad.adelaide.edu.au> Subject: Re: I wonder how much trouble something like this would be to do? :) To: stesin@elvisti.kiev.ua (Andrew V. Stesin) Date: Sat, 25 Nov 1995 02:41:08 +0000 () Cc: jkh@time.cdrom.com, security@freebsd.org In-Reply-To: <199511241604.SAA13149@office.elvisti.kiev.ua> from "Andrew V. Stesin" at Nov 24, 95 06:04:55 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1325 Sender: owner-security@freebsd.org Precedence: bulk Andrew V. Stesin stands accused of saying: > So, we have two firewalled networks; each has > a "tunelling proxy", which accepts connections from > inside, and another -- from the outside (or may this be > a single proxy program?) and -- voila, wer'e Ok, we have > a secure channel over an insecure network? As I've mentioned a number of times in various FreeBSD groups, a local provider has already implemented the base of this using FreeBSD. The code for either end (symmetrical, no encryption) runs to about 50 lines, including comments 8) It uses the tun device, and raw IP sockets for its transport. (What's the point of wrapping IP in TCP? IP is unreliable anyway 8)) They use it mostly for providing "exclusive routes", rather than security. So if any of our securty gurus want to "get dirty" with a straightforward end-to-end encryption setup, FreeBSD has all of the hooks ready for this 8) (at a lot less than $3600 a pop 8) -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 041-122-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] "Who does BSD?" "We do Chucky, we do." [[ From owner-freebsd-security Sat Nov 25 00:45:39 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA13251 for security-outgoing; Sat, 25 Nov 1995 00:45:39 -0800 Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA13246 for ; Sat, 25 Nov 1995 00:45:36 -0800 Received: from localhost (localhost [127.0.0.1]) by precipice.shockwave.com (8.6.12/8.6.12) with SMTP id AAA28898; Sat, 25 Nov 1995 00:18:55 -0800 Message-Id: <199511250818.AAA28898@precipice.shockwave.com> To: Michael Smith cc: stesin@elvisti.kiev.ua (Andrew V. Stesin), jkh@time.cdrom.com, security@freebsd.org Subject: Re: I wonder how much trouble something like this would be to do? :) In-reply-to: Your message of "Sat, 25 Nov 1995 02:41:08 GMT." <199511250241.CAA02783@genesis.atrad.adelaide.edu.au> Date: Sat, 25 Nov 1995 00:18:49 -0800 From: Paul Traina Sender: owner-security@freebsd.org Precedence: bulk It uses the tun device, and raw IP sockets for its transport. (What's the point of wrapping IP in TCP? IP is unreliable anyway 8)) There are advantages if you're running a stream cypher protocol like RC4. From owner-freebsd-security Sat Nov 25 08:48:33 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA06763 for security-outgoing; Sat, 25 Nov 1995 08:48:33 -0800 Received: from sivka.carrier.kiev.ua (root@sivka.carrier.kiev.ua [193.125.68.130]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA06701 for ; Sat, 25 Nov 1995 08:48:16 -0800 Received: from elvisti.kiev.ua (uucp@localhost) by sivka.carrier.kiev.ua (Sendmail 8.who.cares/5) with UUCP id SAA28181 for security@freebsd.org; Sat, 25 Nov 1995 18:51:32 +0200 Received: from office.elvisti.kiev.ua (office.elvisti.kiev.ua [193.125.28.33]) by spider2.elvisti.kiev.ua (8.6.12/8.ElVisti) with ESMTP id RAA27234 for ; Sat, 25 Nov 1995 17:53:28 +0200 Received: (from stesin@localhost) by office.elvisti.kiev.ua (8.6.12/8.ElVisti) id RAA19561; Sat, 25 Nov 1995 17:53:27 +0200 From: "Andrew V. Stesin" Message-Id: <199511251553.RAA19561@office.elvisti.kiev.ua> Subject: Re: I wonder how much trouble something like this would be to do? :) To: lyndon@orthanc.com (Lyndon Nerenberg) Date: Sat, 25 Nov 1995 17:53:27 +0200 (EET) Cc: security@freebsd.org In-Reply-To: <199511241845.KAA27588@multivac.orthanc.com> from "Lyndon Nerenberg" at Nov 24, 95 10:45:04 am X-Mailer: ELM [version 2.4 PL24alpha5] Content-Type: text Content-Length: 867 Sender: owner-security@freebsd.org Precedence: bulk Hello Lyndon, # No doubt. I first read about this several (at least three) years # ago in one of the Usenix Security Conference proceedings. The paper # described an implementation that had been done for 4.4BSD. I can # try to dig out a reference if anyone's interested. As for me, I'm _very_ interested. This smells like FreeBSD will be able to prove it's technical superiority to the people (both users and ISPs and possibly to the corporate guys too) due to presence of such a feature. # Jordan> The international version is due # Jordan> next month. Prices start at $10,000 on Digital Unix and # Jordan> comes with DEC's own Firewall Unix, $3,600 on PCs. # # Har dee har har har. # # --lyndon # -- With best regards -- Andrew Stesin. +380 (44) 2760188 +380 (44) 2713457 +380 (44) 2713560 An undocumented feature is a coding error. From owner-freebsd-security Sat Nov 25 22:39:51 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA17785 for security-outgoing; Sat, 25 Nov 1995 22:39:51 -0800 Received: from statler.csc.calpoly.edu (statler-srv.csc.calpoly.edu [129.65.241.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA17777 for ; Sat, 25 Nov 1995 22:39:45 -0800 Received: (from nlawson@localhost) by statler.csc.calpoly.edu (8.6.12/N8) id WAA24634; Sat, 25 Nov 1995 22:39:26 -0800 From: Nathan Lawson Message-Id: <199511260639.WAA24634@statler.csc.calpoly.edu> Subject: Re: I wonder how much trouble something like this would be to do? :) To: lyndon@orthanc.com (Lyndon Nerenberg) Date: Sat, 25 Nov 1995 22:39:25 -0800 (PST) Cc: security@freebsd.org In-Reply-To: <199511241845.KAA27588@multivac.orthanc.com> from "Lyndon Nerenberg" at Nov 24, 95 10:45:04 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1301 Sender: owner-security@freebsd.org Precedence: bulk > >>>>> "Jordan" == Jordan K Hubbard writes: > > Jordan> Someone sent me this. It sounds like "one of those really > Jordan> simple engineering ideas that marketing got ahold of and > Jordan> hyped the heck outta" but still - I can think of more than > Jordan> a few MIS managers who'd just eat this up. > > No doubt. I first read about this several (at least three) years > ago in one of the Usenix Security Conference proceedings. The paper > described an implementation that had been done for 4.4BSD. I can > try to dig out a reference if anyone's interested. I believe you are referring to swIPe, an implementation of something like this done by Matt Blaze. Check ftp.csua.berkeley.edu:/pub/cypherpunks/swIPe for details. It is designed for NetBSD and SunOS, but I am sure it's an easy port to FreeBSD. The only bad thing about it is that key management is left up to manual means, but I am sure a quick RSA exchange can be added (along with public key host authentication). > Jordan> The international version is due > Jordan> next month. Prices start at $10,000 on Digital Unix and > Jordan> comes with DEC's own Firewall Unix, $3,600 on PCs. > > Har dee har har har. Yes, who ever said that numbers weren't worth good money? -Nate