From ipsec-request@ans.net Thu Sep 1 02:12:40 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16257 (5.65c/IDA-1.4.4 for ); Wed, 31 Aug 1994 22:44:58 -0400 Received: by interlock.ans.net id AA12036 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 31 Aug 1994 22:31:29 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 31 Aug 1994 22:31:29 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 31 Aug 1994 22:31:29 -0400 Date: Thu, 1 Sep 94 02:12:40 GMT From: "William Allen Simpson" Message-Id: <3108.bill.simpson@um.cc.umich.edu> To: ipsec Reply-To: bsimpson@morningstar.com Subject: Re: IPSEC requirements > From: Mark H Linehan/Watson/IBM Research > - We need authentication of message sources (i.e. of the IP source address & > related information) so that firewall routers can filter packets based on > source addresses. I think this is the only requirement that really MUST be > addressed at the IP level. > Whoops! I certainly don't agree with this one! The end-end communicators want to authenticate the message source (or the router-router participating in a tunnel), but certainly routers snooping on end-end authentication is not a goal. Too many keys floating about. If we could only get authentication widely deployed, we won't need firewalls anymore. > - We need message confidentiality (encryption) for those situations where the > communicating parties want to keep their messages private. Examples are many > corporate environments. > > This function can be provided at the application level (e.g. by PEM, etc.) > with the advantage that applications can selectively apply encryption where > it's really needed. The reason for providing confidentiality at the IP level > is that many apps don't implement any kind of encryption. Performing > encryption at the IP level gives a blanket guarantee that all packets are > private. > Here I agree. And of course, tunnel encryption is at the IP level. > - We need message integrity (i.e. a guarantee that no bits in a packet have > been changed) for the same reasons that we need message confidentiality. > I think that this is _not_ orthogonal to authentication. The integrity function should simultaneously provide authentication. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Wed Aug 31 19:07:41 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18534 (5.65c/IDA-1.4.4 for ); Wed, 31 Aug 1994 23:23:00 -0400 Received: by interlock.ans.net id AA11330 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 31 Aug 1994 23:09:17 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 31 Aug 1994 23:09:17 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 31 Aug 1994 23:09:17 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 31 Aug 1994 23:09:17 -0400 Date: Wed, 31 Aug 94 23:07:41 EDT From: Marcus J Ranum Message-Id: <9409010307.AA05880@tis.com> To: bsimpson@morningstar.com, ipsec@ans.net Subject: Re: IPSEC requirements >If we could only get authentication widely deployed, we won't need >firewalls anymore. Unfortunately, this is dead wrong. If folks start relying merely on IP-level authentication and encryption, then you'll very quickly see hackers posting exploit scripts that let you slam kernel variables around to cross-wire file descriptors and steal those nice, established, end-to-end authenticated connections. They could do it now, but they don't because other attacks are just so much easier. The issues of maintaining a common security perimeter are real toughies. I'm afraid the net will be stuck with firewalls forever. That's because there's got to be something to enforce a trust boundary, and it has to be under local control. That means I'm not going to trust a component of your system to enforce my trust boundary. No way, ever. All this stuff is going to give us better and different and more interesting firewalls, but I'll be really surprised if I see them vanishing. They'll look different, but they'll still be there. [This is why I'm really interested in link-level encryption *only* with a degree of tamper-proofing. All this other authentication nonsense is not going to solve any of the problems I think folks think it will solve. It's going to push them a little deeper, but they'll still be there. Distributing trust is a tricky problem that's not solvable by mere network-level encryption, tamper-proofing, or authentication.] mjr. From ipsec-request@ans.net Thu Sep 1 09:58:54 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15106 (5.65c/IDA-1.4.4 for ); Thu, 1 Sep 1994 09:58:54 -0400 Received: by interlock.ans.net id AA27602 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 1 Sep 1994 09:39:26 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 1 Sep 1994 09:39:26 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 1 Sep 1994 09:39:26 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 1 Sep 1994 09:39:26 -0400 Date: Thu, 01 Sep 94 06:01:23 From: "Housley, Russ" Encoding: 1998 Text Message-Id: <9408017784.AA778424483@uu0892.spyrus.com> To: Phil Karn Cc: ipsec@ans.net Subject: Re[2]: IVs, summary of discussion Phil: >>I would prefer one protocol data unit format that is appropriate for the >>use with IPv4 and IPv6. I understand Phil's overhead concerns, but I think >>that the mandatory option set must work in both IPv4 and IPv6. > >Once again, I don't know of any IPv4 transport protocol, existing or >proposed, that won't require *some* changes to operate over IPv6. IPSEC >won't be any worse. A totally interchangeable IPSEC is a chimera. Phil, you advocated the use of the ID field as an IV. You further advocated that this technique be part of the mandatory set of options. In fact, you said, that it must be implemented, but that it did not have to be used on a particular security association. I say that such a technique should be dropped if it cannot be supported in both IPv4 and IPv6. Steve has already posted a message saying that the ID filed is not present in IPv6. >>That said, I would prefer that the mandatory option set include the best >>possible security principles. After all, we are designing a security >>protocol. In some environments, less security may be traded off for >>improved performance, but in my opinion, less security should not be the >>default. > >"Best possible?" *Everything* in security is a tradeoff between >security and performance, because security is never "perfect", nor is >it ever "free". Example: all other things being equal, the longer an >authentication sequence, the stronger the security provided. Keyed >MD5 provides a 16 byte MAC. SHA provides 20. Why stop there? Why not >100-byte MACs? 200 bytes? Okay, I should have chosen my words more carefully. I do not think that the one scheme that must be included in all IPSP implementations should have 3/4ths of its bits constant and known. I object to this on principle. I would rather carry a 64 bit IV. As Steve Kent suggests, we can couple compression with encryption in environments where bandwidth is a concern. Russ From ipsec-request@ans.net Thu Sep 1 10:45:38 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16986 (5.65c/IDA-1.4.4 for ); Thu, 1 Sep 1994 10:45:38 -0400 Received: by interlock.ans.net id AA13504 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 1 Sep 1994 10:27:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 1 Sep 1994 10:27:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 1 Sep 1994 10:27:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 1 Sep 1994 10:27:08 -0400 Date: Thu, 01 Sep 94 07:15:02 From: "Housley, Russ" Encoding: 1437 Text Message-Id: <9408017784.AA778428902@uu0892.spyrus.com> To: hughes@hughes.network.com Cc: IPsec@ans.net Subject: Re[2]: (Fwd) Authentication and encryption. James P. Hughes said: > If the encryption is strong and the probability of garbage passing the > integrity check is low enough (2^-64 or less), then the knowledge of the > shared secret should be authentication of the source. If one can prove > that to create a valid integrity check one must calculate it against the > data in the clear and prove that the attacker must know the key. If you > know only the sender (and you) know the key, then authentication is proven. > Why would this not be acceptable for general traffic authentication > when the traffic is already being encrypted? Of course, this is correct. The tricky part is, as you say, "if the encryption is strong and the probability of garbage passing the integrity check is low enough." Xerox did some work in this area that resuted in a little known DES mode - Cipher Block Chaining with Checksum (CBCC). At the expense of one additional XOR per 64-bit data block, a sum of the ciphertext data blocks is kept. Then, this sum is used in the encryption (and decryption) of the final data block. CBCC ensures that changes made to any ciphertext block impact the decrypted output of the last block. If the last block contains an integrity check (like a CRC) or a constant, then integrity can be checked with very little additional overhead. Certainly much less overhead than MD5, epsecially if a constant is used. Russ From ipsec-request@ans.net Thu Sep 1 10:45:55 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15199 (5.65c/IDA-1.4.4 for ); Thu, 1 Sep 1994 10:45:55 -0400 Received: by interlock.ans.net id AA17612 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 1 Sep 1994 10:27:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 1 Sep 1994 10:27:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 1 Sep 1994 10:27:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 1 Sep 1994 10:27:37 -0400 Date: Thu, 01 Sep 94 07:15:05 From: "Housley, Russ" Encoding: 2285 Text Message-Id: <9408017784.AA778428905@uu0892.spyrus.com> To: uri@watson.ibm.com Cc: ipsec@ans.net Subject: Re: (Fwd) Authentication and encryption. My summary of this discussion is that IPSP should support confidentiality, integrity, and both confidentiality and integrity. The security association will determine which security services are provided. When both onfidentiality and integrity are provided the integrity check function can take advantage of the error extension provided by the cipher. The properties of the encryption mode and algorithm used are of the utmost importance in selecting a compatible integrity check function. A simple integrity function can be used in conjunction with an appropriate encryption scheme. In this way, the integrity and confidentiality can be provided at less computational expense that providing the two independently. Did I miss a major conclusion? Russ ______________________________ Reply Separator _________________________________ Subject: Re: (Fwd) Authentication and encryption. Author: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL20] at internet Date: 8/31/94 10:46 AM James P. Hughes says: > The CRC under the encryption is not a "normal" integrity check. "Normal" > integrity checks are over the entire encrypted packet and protect the > data from random noise. i.e. CRC32 on Ethernet. Again, I don't want to spend too much time/efforts on exploring this. My "feeling" is - that without ASSumptions about method and mode of encryption one can't reliably ASSume anything about integrity checks done even on cleartext prior to encryption, because there can be ways to modify the data without it being detected by that integrity check (and without disturbing the encryption, of course :-). > Is it your assertion that "that the attacker must know the key" to reliabily > change the data can not be proven? I'm not sure I understand what you mean - but I'll answer anyway (:-). Not only it can't be proven, but I think it's outright wrong in general. There are integrity checks that are expensive and secure, and there are ones that are cheap and "breakable". Some encryption modes/methods can vouch for data integrity (to some extent - I don't want to dive into this now) and some can NOT... -- Regards, Uri uri@watson.ibm.com acheron!angmar!uri N2RIU ----------- From ipsec-request@ans.net Thu Sep 1 09:06:11 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17593 (5.65c/IDA-1.4.4 for ); Thu, 1 Sep 1994 13:48:25 -0400 Received: by interlock.ans.net id AA26819 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 1 Sep 1994 13:25:07 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 1 Sep 1994 13:25:07 -0400 Return-Path: shirey@mitre.org Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 1 Sep 1994 13:25:07 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 1 Sep 1994 13:25:07 -0400 Date: Thu, 1 Sep 94 13:06:11 EDT Message-Id: <9409011706.AA06313@smiley.mitre.org.sit> X-Sender: shirey@smiley.mitre.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: secdir@tis.com, saag@tis.com, pem-dev@tis.com, ipsec@ans.net From: abr@tycho.ncsc.mil (Amy B. Reiss) (by way of shirey@mitre.org (Robert W. Shirey)) Subject: OSE Implementors Workshop Sec-Sig: Draft Minutes SEC-SIG 94-08 DRAFT #34 OSE Implementors Workshop Security SIG Minutes June 14 -16, 1994 1.0 General Information 1.1 Meeting Date and Location June 14 -16, 1994 NIST, Gaithersburg, Maryland 1.2 SIG Officers Chair: Richard Ankney Fischer International (703)818-0713 Richard.Ankney@emc2-tao.fisc.com Vice-Chair: John Hooder ITAC/DASN, Washington D.C. (202)433-4745 Secretary: Position Open Editors: Mohammad Mirhakkak Ph.D. MITRE Corp (703)883-7820 mmirhakk@mitre.com 1.3 Security SIG Voting Rules 1. There is one vote for each company or each independent division. 2. Only companies that regularly attend (SEC-SIG's interpretation: Attend two of the last three meetings, including the current one) should vote. 3. Only companies that plan to sell or buy a protocol should vote on its implementation decisions. 4. Only companies knowledgeable of the issues should vote. 5. No proxy votes are admissible. 1.4 Tentative Dates of Future Meetings #35--September 12-16, 1994 #36--December 12-16, 1994 #37--March 13-17,1995 #38--June 12-16, 1995 1.5 Electronic Mailing List There is an electronic mailing list for minutes distribution (secsig@monkfish.nosc.mil). Everyone is asked to provide his/her electronic mailing address on the attendee list. Attendees are added to the mailing list. If you want to be a member of the NIST OSI Security SIG electronic mailing list, please send a message to "secsig-request@monkfish.nosc.mil". Contributions to this list should be addressed to "secsig@monkfish.nosc.mil". 1.6 Document Register Every document handed out must have an assigned number "SEC-SIG 94-XX" (where XX is a number starting from 1). Please get a number from the chair if you want to distribute a document. 2.0 Opening Plenary 2.1 Welcome and Announcements Opening plenary was led by Richard Ankney. Members from various standards committees gave liaisons reports. 2.2 Minutes The minutes of the March workshop are to be reviewed for approval at the closing Plenary. Amy Reiss took the minutes for this workshop. 2.3 Agenda The agenda was developed for the remaining workshop sessions. Tuesday AM Opening Plenary New Business Tuesday PM Joint Session with NM-SIG Wednesday AM/PM Joint Session with MMS SIG Joint Session with RDA SIG Joint Session with OSE-TC (Rich) Thursday AM Closing Plenary 2.4 New Business Amy Reiss proposed that section 9.2 be created in the working agreements that would deal Security Associations (SA) and Security Association Management Protocols (SAMP). She presented a text contribution regarding this new topic and the group went through and edited the text. Next, Rich determined how section 9.2 should be presented and tasks were assigned accordingly: Section 9.2.1 Overview (current contribution), Section 9.2.2 Layer Specific Security Association Protocols (Action: Dale Walters) Section 9.2.3 IEEE KMP (Action: Amy Reiss), Section 9.2.4 X9.41 Security Services Management for the Financial Services Industry (Action: Rich Ankney), Section 9.2.5 ISP.421 Security Association Management Protocol (Action: Amy Reiss). In addition, SEC-SIG members were tasked to gather a core set of attributes that need to be negotiated by a SAMP. Dale Walters will generate the interoperability set of attributes. Rich Ankney will generate the private sector set of attributes. Amy Reiss will generate the gove 3.0 Presentations and Tutorials There were no presentations or tutorials for the SEC-SIG during the June workshop. 4.0 OIW SIGs Activities 4.1 OSE-TC During this workshop, Rich Ankney worked with the OSE-TC regarding security issues with Electronic Commerce. Rich contributed a paper on security for electronic commerce, focusing on the use of crypto for Email security. There was concern about the use of certificates with the lack of a certificate infrastructure. In addition, there was also an interest for signed receipt capabilities. The group still needs to put together a list of algorithm suites (i.e., NIST suite, PEM suite, and X9 suite). 4.2 Manufacturing Messages Specification At prior workshops the SEC-SIG recommended GULS for the full configuration and NLSP for the limited configuration to the MMS-SIG in order to secure both MMS communities (i.e., the utility-to-utility communications (UU) and the utility-to-customer (UC) communications). At the June workshop the SEC-SIG also recommended the use of the Secure Data Exchange (SDE) protocol from the IEEE 802.10 standard. This would provide confidentiality, integrity, authentication, and access control at the LLC layer 2. Since both communities will have LLC in their network configuration, this solution could be used for both communities instead of two separate solutions. By using the IEEE SDE, the MMS-SIG could also use the IEEE Key Management Protocol (KMP) when it is completed. The MMS-SIG asked for copies of the SDE standard; however, it is a completed IEEE standard and is copyrighted. This issue will have to be resolved. The MMS-SIG would also like an official statement/recommendation from the SEC-SIG regarding PGP. Thi 4.3 Remote Data Access The RDA-SIG is currently working issues regarding the handling of authentication with respect to RDA. The NIST document, "Recommendation of a Protected Authentication Mechanism for the Remote Database Access (RDA) Project", was distributed. Basically, this document proposed a short-term and long-term solution for RDA authentication. The short-term recommendation is the use of a hashing algorithm to prevent the transmission of unencrypted passwords. Rich Ankney stated that in addition to this, measures should be taken to ensure that passwords are not stored in plaintext. The X.511 Directory Bind was recommended to accomplish this. For the long term recommendation there were two alternatives: Secret Key Encryption and Public Key Encryption. Rich recommended the Public Key Encryption using DSS for strong authentication. Rich also pointed out that in the stable agreements the use of authentication in ACSE is included for the NM-SIG and could also be used by the RDA-SIG. 4.3 Network Management There was a concern by the NM-SIG that more work needs to be done in regards to the management of GULS. After a brief discussion it was determined that there was no more work left in this area. The NM-SIG will ask Lee LeBarre to make sure if there were anymore open issues regarding the management of GULS. The SEC-SIG distributed the X/OPEN Security Document provided by Joe Sonsini. The NM-SIG wanted to know how the SAMP work was progressing. It was stated that Security Association text was being added to the agreements and SAMP text would be added at the next workshop. The SEC-SIG would like the NM-SIG to review this text. The NM-SIG asked the SEC-SIG to review the comments for the other workshops on pDISP 10164-7 "Security Alarm Reporting," and pDISP 10164-8 "Security Audit Trail." The NM-SIG asked for a volunteer to be the editor of pDISP 10164-9 "Objects and Attributes for Access Control." However, the SEC-SIG was not able to provide one. After assessing the impact of the technical correction of the Secure Hash Algorithm (SHA), the decision to correct the agreements was made to add a new object identifier for the fix. The new OID will be called SHA1 and will be fixed in the Security agreements (Part 12). In addition, the GNMP will be affected by the changed. It was recommended that the NM-SIG makes sure that the GNMP aligns to the SHA1 fix. 5.0 Closing Plenary Rich Ankney led the Thursday morning closing plenary. The following are the approved motions and votes: The minutes for the March 1994 workshop were approved. Y=4, N=0, A=0 Section 7.5 and Annex D: Move from WIA to SIA signature and OIDs for the following: RSA signature with MD5 RSA signature with MD2. Y=3, N=0, A=1 Section 7 and Annex D: Add to WIA Algorithms and OIDs for the following: SHA1 DSA with SHA1 DSA with SHA1 with common parameters, RSA signature with SHA1 Y=4, N=0, A=0 Section 9.2: Add to WIA new text regarding Security Associations and SAMP Y=4, N=0, A=0 ANNEX I: Document List SEC-SIG 94-01: US Ballot Response on ISO/IEC DIS 11586-1 GULS Part 1. SEC-SIG 94-02: OIW Security SIG Minutes, March 1994 Workshop. SEC-SIG 94-03: Security Association Text Contribution for WIA 9.2. SEC-SIG 94-04: EWOS EGSEC Work Programme Slides, Roy Cadwallader. SEC-SIG 94-05: ISO JTC1/SC27/WG1 N443, Output from Trondheim Meeting -- Security Information Objects. SEC-SIG 94-06: X/Open Guide - Distributed Security Frameworks Draft 3. SEC-SIG 94-07: Recommendation of a Protected Authentication Mechanism for the RDA Project, Dray & Foti. SEC-SIG 94-08: OIW Security SIG Minutes, June 1994 Workshop. From ipsec-request@ans.net Thu Sep 1 18:57:52 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13216 (5.65c/IDA-1.4.4 for ); Thu, 1 Sep 1994 16:33:22 -0400 Received: by interlock.ans.net id AA10097 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 1 Sep 1994 16:14:32 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 1 Sep 1994 16:14:32 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 1 Sep 1994 16:14:32 -0400 Date: Thu, 1 Sep 94 18:57:52 GMT From: "William Allen Simpson" Message-Id: <3112.bill.simpson@um.cc.umich.edu> To: IPsec@ans.net Reply-To: bsimpson@morningstar.com Subject: CBCC > From: "Housley, Russ" > Of course, this is correct. The tricky part is, as you say, "if > the encryption is strong and the probability of garbage passing the > integrity check is low enough." Xerox did some work in this area that > resuted in a little known DES mode - Cipher Block Chaining with Checksum > (CBCC). At the expense of one additional XOR per 64-bit data block, a sum > of the ciphertext data blocks is kept. Then, this sum is used in the > encryption (and decryption) of the final data block. CBCC ensures that > changes made to any ciphertext block impact the decrypted output of the > last block. If the last block contains an integrity check (like a CRC) or > a constant, then integrity can be checked with very little additional > overhead. Certainly much less overhead than MD5, epsecially if a constant > is used. > Sounds like this is the way to go for our default encryption technique. Why the XOR? Why not CRC over the whole payload, appended to the end of the final block before encryption? CRC-32 isn't _that_ expensive, especially compared to CBC. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Thu Sep 1 18:45:53 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13473 (5.65c/IDA-1.4.4 for ); Thu, 1 Sep 1994 16:33:23 -0400 Received: by interlock.ans.net id AA12393 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 1 Sep 1994 16:14:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 1 Sep 1994 16:14:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 1 Sep 1994 16:14:30 -0400 Date: Thu, 1 Sep 94 18:45:53 GMT From: "William Allen Simpson" Message-Id: <3111.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Re: IPSEC requirements > From: Marcus J Ranum > >If we could only get authentication widely deployed, we won't need > >firewalls anymore. > > Unfortunately, this is dead wrong. > No, _your_ argument is dead wrong. "Hackers posting" means they can get into your secure machine. If you are using IP Security, you might as well be running a secure machine. If it's not secure, a firewall won't save you. The trust boundary is the trusted machine. I don't care about unsecure machines. Let them die. Since "trusting" IP Addresses requires "trusting" somebody else's routing fabric, firewalls don't protect against anything but maliciousness. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Thu Sep 1 20:15:51 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18408 (5.65c/IDA-1.4.4 for ); Thu, 1 Sep 1994 16:48:43 -0400 Received: by interlock.ans.net id AA15048 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 1 Sep 1994 16:35:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 1 Sep 1994 16:35:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 1 Sep 1994 16:35:08 -0400 Date: Thu, 1 Sep 94 20:15:51 GMT From: "William Allen Simpson" Message-Id: <3117.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Motorola patent 5,245,614 on compression This one covers VJ compression. Do we have art prior to April 29, 1991? > From: Paul Mackerras > Here are the claims from the second Motorola patent. I have copied > these from Australian patent 19787/92, which corresponds to international > patent publication number WO 92/20176, which is the same (I expect) > as US patent number 5,245,614. > > Briefly, the patent seems to cover the situation where you store > several compression dictionaries, and use information from the frame, > such as a source/destination address pair, to choose which dictionary > to use. > > CLAIMS. > 1. A method for allocating memory for storage of vocabularies used in > an adaptive data compression of a frame-multiplexed data stream of a > data communications network, said method comprising the steps of: > partitioning a memory of a data compression encoder into a > plurality of sections for the temporary storage of a corresponding > plurality of data compression vocabularies; and > assigning a memory section of said plurality based on > information of a current frame of said frame-multiplexed data stream > for storage of a vocabulary created adaptively from said current > frame. > > 2. The method in accordance with claim 1 wherein at least one of (2A) > and (2B): > 2A) the memory section for storage of a vocabulary is assigned > dynamically, and > 2B) further including the following steps: > 2B1) including in each frame of the frame-multiplexed data > stream address information, and > 2B2) assigning a memory section of said plurality to the > current frame based on address information in the current frame, > wherein in 2B1 and 2B2, where selected, one of: > 2Ba) the memory section is assigned based on frame address > information including a source/destination pair of addresses, and > 2Bb) the steps of assigning includes the steps of: > 2Bb1) assigning an unassigned memory section of said > plurality to each current frame having frame address information > different from that corresponding to the assigned memory sections > until all of the memory sections are assigned, and > 2Bb2) thereafter, reassigning a designated assigned > memory section of said plurality for storage of a vocabulary for a > current frame having frame address information different from that > corresponding to the assigned memory sections, such that, where > selected, one of: > 2Bb2a) the reassignment step includes the step of > designating an assigned memory section for reassignment based on the > least recently active of the frames having frame address information > corresponding to the assigned memory sections, > 2Bb2b) the reassignment step includes the step of > designating an assigned memory section for reassignment based on a > sequential selection of the assigned memory sections, > 2Bb2c) the reassignment step includes the step of > cancelling the present frame address assignment of the memory section > designated for reassignment, and > 2Bb2d) the reassignment step includes the step of > resetting the contents of the memory section designated for > reassignment prior to storage of the vocabulary of the current frame, > and where selected, 2B further includes the steps of: > 2B3) assigning an index code to the frame information of each > of a selected plurality of frames, and > 2B4) mapping the frame address information of said current > frame into its assigned index code, wherein step 2B4 further includes, > where selected, the steps of: > 2B4a) assigning a memory slot of a routing table portion > of said memory to each index code of said plurality, and > 2B4b) storing in each memory slot an indication of memory > section assignment corresponding to said index code, and the step 2B4b > further includes, where selected, the steps of: > 2B4b1) positioning another table portion of said > memory into areas for storing printer information in connection with > vocabulary memory section assignment and reassignment, and > 2B4b2) accessing said memory areas by the memory > section indications stored in the memory slots of the routing table > portion of memory. > > 3. A method for allocating memory for storage of vocabularies used in > an adaptive data compression of a frame-multiplexed data stream of a > data communication network in which at least one interconnecting node > thereof is coupled to a plurality of communication links of said > network, said method comprising the steps of: > partitioning a memory of a data compression encoder of said > interconnecting node into a portion for each communication link which > may be coupled to said interconnecting node; > partitioning each partitioned portion of said memory into a > plurality of sections for the temporary storage of a corresponding > plurality of data compression vocabularies; > assigning a partitioned portion of said memory to a current > frame of said frame-multiplexed data stream based on information of > said current frame used by said encoder in connection with designating > a communication link of said plurality over which said current frame > is destined; and > assigning a memory section of said assigned portion of said > current frame based on said information of said current frame for > storage of a vocabulary created adaptively from said current frame. > > 4. The method in accordance with claim 3 wherein one of 4A and 4B: > 4A) the steps of assigning for storage of vocabularies are both > performed dynamically, and > 4B) further including the steps of: > 4B1) including in each frame of the frame-multiplexed data > stream address information, > 4B2) assigning a partitioned portion of said memory to said > current frame based on said address information in said current frame > of said frame-multiplexed data stream, and > 4B3) assigning a memory section of said assigned memory > portion of said current frame based on said source/destination address > information thereof, > and, where selected, in addition to one of 4A and 4B, further > including the steps of: > 4C) assigning an index code to the frame information of each of a > selected plurality of frames, and > 4D) mapping the frame address information of said current frame > into its assigned index code, where step 4D includes, where selected, > the steps of: > 4D1) assigning a memory slot of a routing table portion of > said memory to each index code of said plurality, and > 4D2) storing in each memory slot an indication of memory > portion and section assignment corresponding to said index code. > > 5. The method in accordance with claim 4 wherein one of 5A and 5B: > 5A) both assignments are based on frame information including a > source/destination pair of addresses, and > 5B) further including the steps of: > 5B1) assigning an unassigned memory section of the assigned > memory portion to each current frame of the assigned memory portion > having a frame address information different from that corresponding > to the assigned memory sections thereof until all of the memory > sections of the assigned memory portion are assigned, and > 5B2) thereafter reassigning a designated assigned memory > section of the assigned memory portion for storage of a vocabulary for > a current frame of the assigned memory portion having a source/ > destination address pair different from those corresponding to the > assigned memory sections thereof. > > 6. The method in accordance with claim 5 wherein one of 6A - 6D: > 6A) the reassignment step includes the step of designating an > assigned memory section for reassignment based on the least recently > active of the frames having frame address information corresponding to > the assigned memory sections, > 6B) the reassignment step includes the step of designating an > assigned memory section for reassignment based on a sequential > selection of the assigned memory section, > 6C) the reassignment step includes the step of cancelling the > present frame address information of the memory section designated > for reassignment, and > 6D) the reassignment step includes the step of resetting the > contents of the memory section designated for reassignment prior to > storage of the vocabulary of the current frame. > > 7. Apparatus for dynamically allocating memory of an encoder of a data > communications network for storage of vocabulary used in an adaptive > data compression of a frame-multiplexed data stream by said encoder, > said apparatus comprising: > memory means partitioned into a plurality of sections for the > temporary storage of a corresponding plurality of data compression > vocabularies; and > means for assigning a memory section of said memory means > based on information of a current frame of said frame-multiplexed data > stream to store a vocabulary created adaptively from said current > frame by said encoder. > > 8. The apparatus in accordance with claim 7 wherein one of 8A and 8B: > 8A) the assigning means includes means for assigning a memory > section dynamically, and > 8B) each frame of the frame-multiplexed data stream includes > address information and including means for assigning a memory section > of the memory means to the current frame based on the address > information in the current frame, > and, where selected, in addition to one of 8A and 8B, further > including: > 8C) the network includes at least one interconnecting node ported > to a plurality of communications links, said interconnecting node > including the data compression encoder; and means for designating a > communications link of said plurality for the current frame based on > the frame address information thereof; wherein the memory means is > partitioned into a portion for each communications link which may be > coupled to said interconnecting node and each memory portion is > partitioned into the plurality of sections for the temporary storage > of a corresponding plurality of data compression vocabularies; and > wherein the assigning means included: > 8C1) means for assigning a partitioned portion of the memory > means to a current frame based on the frame address information > thereof, and > 8C2) means for assigning a memory section of said assigned > memory portion of said current frame based on said frame address > information thereof, > and, where selected, in addition to 8C, further including 8D-8F: > 8D) means for mapping the frame address information of the current > frame into an index code uniquely assigned thereto, > 8E) a routing table portion of the memory means including a memory > slot corresponding to each index code, and > 8F) means for storing in each memory slot on indication of memory > portion and section assignment corresponding to said index code. > > 9. The apparatus in accordance with claim 8 wherein at least one of 9A > and 9B: > 9A) the frame address information includes a source/destination > pair of addresses, and > 9B) the assigning means includes: > 9B1) means for assigning an unassigned memory section of the > memory means to current frame having frame address information > different from that corresponding to the assigned memory sections > until all of the memory sections are assigned, and > 9B2) means for reassigning a designated assigned memory > section of the memory means for storage of a vocabulary for a current > frame having frame address information different from that > corresponding the the assigned memory sections. > > 10. Apparatus in accordance with claim 9 wherein at least one of > 10A-10D: > 10A) the reassigning means includes means for designating an > assigned memory section for reassignment based on the least recently > active of the frames having frame address information corresponding to > the assigned memory sections, > 10B) the reassigning means includes means for designating an > assigned memory section for reassignment based on a sequential > selection of assigned memory sections, > 10C) the reassigning means includes means for cancelling the > present frame address assignment of the memory section designated for > reassignment, and > 10D) the reassigning means includes means for resetting the > contents of the memory section designated for reassignment prior to > storage of the vocabulary of the current frame. > > Paul Mackerras paulus@cs.anu.edu.au > Dept. of Computer Science > Australian National University. > From ipsec-request@ans.net Thu Sep 1 20:08:26 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17901 (5.65c/IDA-1.4.4 for ); Thu, 1 Sep 1994 16:49:37 -0400 Received: by interlock.ans.net id AA10178 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 1 Sep 1994 16:35:02 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 1 Sep 1994 16:35:02 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 1 Sep 1994 16:35:02 -0400 Date: Thu, 1 Sep 94 20:08:26 GMT From: "William Allen Simpson" Message-Id: <3116.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Motorola patent 5,130,993 on checksum of encoded data We have been having a problem which arose in the PPP WG, where a draft for the compression over PPP has been held up due to Motorola sending a letter to the Secretariat last winter. A member of the PPP WG recently typed in the text of the patent claims. This one covers the DES CBCC concept. Do we have art prior to December 1989? > From: Paul Mackerras > I have obtained a copy of the Motorola patent which covers the CCP > reset req/ack mechanism. (Specifically, I have a copy of Australian > patent 73296/91, which corresponds to US patent 5,130,993.) > I have reproduced the claims section below (including their spelling > mistakes :-). > > A few notes: > > - The patent acknowledges as prior art the configuration where the > compressor/decompressor are connected using a link which uses error > detection and retransmission to provide a reliable link. Using CCP > over V.42 modems would seem to me to fall into this category. > > - The 1st paragraph of the "Summary of the Invention" section reads: > "In general, the invention features transmitting encoded (e.g., compressed > or encrypted) data over an unreliable network, by checking for > transmission errors after decoding, and resetting the encoder if > an error is detected. Synchronization of encoding and decoding can > thereby be maintained." > > I know that this isn't legally a claim, but I think it gives some idea > of the range of implementations which Motorola would like to think > the patent covers. > > CLAIMS: > > 1. A method for transmitting encoded data across unreliable > networks, said encoding being of the type in which encoding and > decoding are synchronized, said method comprising the steps of: > encoding said data; > transmitting said encoded data across said unreliable network; > receiving and decoding said data; > subsequently detecting any errors introduced by said > unreliable network; and > resetting said encoding method upon said detection of errors. > > 2. The method of claim 1 wherein error detection information > is added to said data prior to encoding said data, and said error > detection information is used, following decoding, to detect any > errors introduced by said unreliable network. > > 3. The method of claim 2 wherein said error correction > information is a code sequence inserted into said data prior to > encoding. > > 4. The method of claim 3 wherein said code sequence is a > cyclic redundancy check (CRC). > > 5. The method of claim 1 wherein said unreliable network > includes a plurality of nodes so arranged that a plurality of paths > exist between at least some nodes between which said method is > practiced. > > 6. The method of claim 5 wherein at least one node may > communicate with more than one node at a time. > > 7. The method of claim 1 wherein said data encoding comprises > data compression. > > 8. The method of claim 1 wherein said data encoding comprises > encryption. > > 9. The method of claim 1 wherein said step of resetting said > encoding method further includes > transmitting a reset request code sequence over a reverse > channel upon said detection of errors; and > transmitting a request acknowledgement code sequence over said > unreliable network to acknowledge reception of said reset request code > sequence. > > 10. The method of claim 9 wherein > the reset request code sequence initiates the resetting of the > encoder; and > the reset acknowledgement code sequence initiates the > resetting of the decoder. > > 11. The moethod of claim 10 wherein said step of resetting > said encoder further includes > starting a timer upon said detection of errors; > transmitting a second reset request code sequence over said > reverse channel upon failure to receive said request acknowledgement > code sequence upon the expiration of said timer. > > 12. The method of claim 11 wherein > said unreliable network further includes a plurality of nodes > so arranged that a plurality of paths exist between at least some > nodes between which said method is practiced; and wherein > at least one node may communicate with more than one node at a > time using different encoding methods to communicate with at least two > different nodes; and wherein said timer is shared by said different > encoding methods. > > 13. The method of claim 1 wherein > said data encoding comprises data compression; and wherein > said step of resetting said data encoding includes > resynchronizating the encoder and decoder of said data compression. > > 14. The method of claim 13 wherein said error detection > information is added to said data prior to encoding said data, and > said error detection infofmation is used, following decoding of said > data, to detect any errors introduced by said unreliable network. > > 15. The method of claim 13 wherein said unreliable network > includes a plurality of nodes so arranged that a plurality of paths > exist between at least some nodes between which said method is > practiced. > > ----------------------------------------------------------------------------- > Paul Mackerras paulus@cs.anu.edu.au > Dept. of Computer Science > Australian National University > From ipsec-request@ans.net Thu Sep 1 22:10:03 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13127 (5.65c/IDA-1.4.4 for ); Thu, 1 Sep 1994 18:21:04 -0400 Received: by interlock.ans.net id AA26774 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 1 Sep 1994 18:09:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 1 Sep 1994 18:09:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 1 Sep 1994 18:09:31 -0400 Date: Thu, 1 Sep 1994 15:10:03 -0700 From: Phil Karn Message-Id: <199409012210.PAA29297@servo.qualcomm.com> To: bsimpson@morningstar.com Cc: ipsec@ans.net In-Reply-To: <3116.bill.simpson@um.cc.umich.edu> Subject: Re: Motorola patent 5,130,993 on checksum of encoded data Seems to me that Van Jacobson IP/TCP header compression works very much along these lines. When the receiver detects an error after decompression, the sender times out and retransmits. This retransmission is sent uncompressed, which automatically resynchronizes the decompressor. VJ header compression has been around for quite a few years now, so it would likely qualify as prior art. Phil From ipsec-request@ans.net Thu Sep 1 22:12:43 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15958 (5.65c/IDA-1.4.4 for ); Thu, 1 Sep 1994 18:23:47 -0400 Received: by interlock.ans.net id AA15795 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 1 Sep 1994 18:12:02 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 1 Sep 1994 18:12:02 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 1 Sep 1994 18:12:02 -0400 Date: Thu, 1 Sep 1994 15:12:43 -0700 From: Phil Karn Message-Id: <199409012212.PAA29306@servo.qualcomm.com> To: bsimpson@morningstar.com Cc: ipsec@ans.net In-Reply-To: <3117.bill.simpson@um.cc.umich.edu> Subject: Re: Motorola patent 5,245,614 on compression >This one covers VJ compression. Do we have art prior to April 29, 1991? RFC-1144 on VJ header compression is dated February 1990. I think he may have written conference papers on it well before then. Phil From ipsec-request@ans.net Thu Sep 1 22:19:14 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13422 (5.65c/IDA-1.4.4 for ); Thu, 1 Sep 1994 18:32:31 -0400 Received: by interlock.ans.net id AA10023 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 1 Sep 1994 18:18:59 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 1 Sep 1994 18:18:59 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 1 Sep 1994 18:18:59 -0400 Date: Thu, 1 Sep 1994 15:19:14 -0700 Posted-Date: Thu, 1 Sep 1994 15:19:14 -0700 Message-Id: <199409012219.AA14006@cym.isi.edu> Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 1 Sep 1994 18:18:59 -0400 From: Clifford Neuman To: housley@spyrus.com Cc: hughes@hughes.network.com, IPsec@ans.net In-Reply-To: "Housley, Russ"'s message of Thu, 01 Sep 94 07:15:02 <9408017784.AA778428902@uu0892.spyrus.com> Subject: Re[2]: (Fwd) Authentication and encryption. Date: Thu, 01 Sep 94 07:15:02 From: "Housley, Russ" Of course, this is correct. The tricky part is, as you say, "if the encryption is strong and the probability of garbage passing the integrity check is low enough." Xerox did some work in this area that resuted in a little known DES mode - Cipher Block Chaining with Checksum (CBCC). At the expense of one additional XOR per 64-bit data block, a sum of the ciphertext data blocks is kept. Then, this sum is used in the encryption (and decryption) of the final data block. CBCC ensures that changes made to any ciphertext block impact the decrypted output of the last block. If the last block contains an integrity check (like a CRC) or a constant, then integrity can be checked with very little additional overhead. Certainly much less overhead than MD5, epsecially if a constant is used. This sounds very similar to the PCBC mode that we used in version 4 of Kerberos. Of course, our PCBC mode had the unfortunate property that swapping two ciphertext blocks resulted in no change to subsequent plaintext blocks. ~ Cliff From ipsec-request@ans.net Fri Sep 2 03:26:31 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13452 (5.65c/IDA-1.4.4 for ); Thu, 1 Sep 1994 23:40:47 -0400 Received: by interlock.ans.net id AA15807 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 1 Sep 1994 23:25:50 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 1 Sep 1994 23:25:50 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 1 Sep 1994 23:25:50 -0400 Date: Thu, 1 Sep 1994 20:26:31 -0700 From: Phil Karn Message-Id: <199409020326.UAA29553@servo.qualcomm.com> To: linehan@watson.ibm.com Cc: ipsec@ans.net In-Reply-To: <9408311858.AA0908@watlny03.watson.ibm.com> (linehan@watson.ibm.com) Subject: Re: IPSEC requirements > This function can be provided at the application level (e.g. by PEM, etc.) >with the advantage that applications can selectively apply encryption where >it's really needed. The reason for providing confidentiality at the IP level >is that many apps don't implement any kind of encryption. Performing ^^^^^^^^^ >encryption at the IP level gives a blanket guarantee that all packets are >private. This isn't a strong enough statement. Many *hosts* don't implement any kind of encryption. One of the nice things about doing it just above IP is that you have the option of building an "encryption gateway" that can encrypt and/or authenticate packets from "crypto-unaware" hosts. A particularly important special case is two LANs belonging to the same company but physically at different locations and interconnected by an insecure network (e.g., the Internet). None of the hosts on the LANs support encryption, or are likely to in the near future. How can the two LANs be joined so that the hosts can communicate across the net in a reasonably secure fashion against outside (*not* inside) attacks? IPSEC is a perfect solution to this problem. And you can keep it even after you eventually implement it inside all the hosts. Very flexible and elegant, much more so than encryption at any other protocol level. Phil From ipsec-request@ans.net Fri Sep 2 05:47:01 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13260 (5.65c/IDA-1.4.4 for ); Fri, 2 Sep 1994 10:22:24 -0400 Received: by interlock.ans.net id AA05485 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 2 Sep 1994 10:00:05 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 2 Sep 1994 10:00:05 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 2 Sep 1994 10:00:05 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 2 Sep 1994 10:00:05 -0400 Date: Fri, 2 Sep 94 09:47:01 EDT From: Marcus J Ranum Message-Id: <9409021347.AA20376@tis.com> To: bsimpson@morningstar.com, ipsec@ans.net Subject: Re: IPSEC requirements >The trust boundary is the trusted machine. >I don't care about unsecure machines. Let them die. That's exactly what I mean. If the trust boundary is your trusted machine, you can't assume that data from an untrusted machine is authentic. Even if it's authenticated and has the IP security stamp of approval. After all, if it's an unsecure machine, it should be trivial for an attacker to pretend to be an authorized user on your machine. So your machine can't trust it, and you've gone and built a firewall *EXACTLY* like the ones that are out there today, where the only machines that trust eachother are the ones you own. When I said that the distributed trust problem is hard to solve, I wasn't just trying to be obnoxious. It *IS* hard to solve! And every time I see IP security come up, someone says "and after this we won't need firewalls." --- I really really wish this were true, but until all *hosts* are adequately secured, and all *networks* are adequately secured, you're going to have trust boundaries. The very fact that systems will always be administered differently means that for some value of "adequate" all hosts will *NEVER* be adequately secured. To put this another way: would you let traffic through your firewall if it was protected by IP security options and was coming from an authenticated user logging in from, say, gnu.ai.mit.edu, or a public access machine? I wouldn't. Kerberos is a similar situation. If you use it all over your network, on machines that you trust because you run them, then you're fine. If you start letting other systems you don't have control over authenticate users to your machines, you're running the risk that those machines could be compromised in a way that "steals" someone's kerberos password. Suppose I modify the "klogin" program on my workstation and you use it to log into your home machine. The kerberos part of the system is still perfectly strong, but I now know your kerberos password and can be you. This is what I mean about how IP level encryption solves a limited set of problems, and must be accompanied by similar host-based security and common management. Your trust boundary is going to encompass all the systems you control, or the systems people you are willing to trust control, and nobody else. That's the *CURRENT* situation with firewalls -- IPSEC will give newer technologies but the basic trust situation isn't likely to change. mjr. From ipsec-request@ans.net Fri Sep 2 17:27:44 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA01667 (5.65c/IDA-1.4.4 for ); Fri, 2 Sep 1994 13:47:44 -0400 Received: by interlock.ans.net id AA28587 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 2 Sep 1994 13:30:34 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 2 Sep 1994 13:30:34 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 2 Sep 1994 13:30:34 -0400 Return-Path: Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 2 Sep 1994 13:30:34 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 2 Sep 1994 13:30:34 -0400 From: Charlie Watt Sender: Charlie Watt Message-Id: <9409021727.AA01844@mordred.sware.com> Subject: Re: IPSEC requirements To: mjr@tis.com (Marcus J Ranum) Date: Fri, 2 Sep 1994 13:27:44 -0400 (EDT) Cc: bsimpson@morningstar.com, ipsec@ans.net In-Reply-To: <9409021347.AA20376@tis.com> from "Marcus J Ranum" at Sep 2, 94 09:47:01 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1510 X-Sensitivity-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-Certificate: MIIBwDCCAWoCEQC43J7oZ50NWTRSVBShvvaXMA0GCSqGSIb3DQEBAgUAMFkxCzAJ BgNVBAYTAlVTMRgwFgYDVQQKEw9TZWN1cmVXYXJlIEluYy4xFzAVBgNVBAsTDlNl Y3VyZVdhcmUgUENBMRcwFQYDVQQLEw5FbmdpbmVlcmluZyBDQTAeFw05NDA0MDUx NzA2NDJaFw05NTA0MDUxNzA2NDJaMHAxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9T ZWN1cmVXYXJlIEluYy4xFzAVBgNVBAsTDlNlY3VyZVdhcmUgUENBMRcwFQYDVQQL Ew5FbmdpbmVlcmluZyBDQTEVMBMGA1UEAxMMQ2hhcmxlcyBXYXR0MFkwCgYEVQgB AQICAgQDSwAwSAJBDNmUqe2+nqg6iuUWzxaXegxki426RzmVNO6VHHYCV4nbo/WL X9a7Jn/2nWqZUK/l+RXqCHU/21Ur9jFIt4GNHhcCAwEAATANBgkqhkiG9w0BAQIF AANBAEY6kP5jHqK9B9PhZCCJ9mckYuKMufWr7l61LulXGwUTqFzjFC0MOYwXo5s+ 8lqrLQ7YpTzyE74pKR1cl5TAUU4= MIC-Info: RSA-MD5,RSA, CEYgppx/IOBfjD8vBOYcL/yh1ezAJ2BZSzMum7/6Ym/b2yVc8k7qwAmXGkxvf1Pm Em7FKGfNdKxhoWcqKeY7lVc= X-Sensitivity-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED X-Information-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED > > >The trust boundary is the trusted machine. > >I don't care about unsecure machines. Let them die. > > That's exactly what I mean. > > If the trust boundary is your trusted machine, you can't > assume that data from an untrusted machine is authentic. Even if > it's authenticated and has the IP security stamp of approval. > After all, if it's an unsecure machine, it should be trivial > for an attacker to pretend to be an authorized user on your > machine. So your machine can't trust it, and you've gone and > built a firewall *EXACTLY* like the ones that are out there > today, where the only machines that trust eachother are the > ones you own. Marcus, your basic point that you must trust the remote systems with which you are authenticating is correct. But network level security buys us far more than we get with today's firewalls. With today's firewalls you can only build a defense perimeter around those hosts that have direct physical connections over those LANs/WANs that YOU directly control, and over which you can guarantee absolute physical security. With cryptographic protection at the network level providing peer-host authentication, data integrity and data confidentiality, you can extend your defense perimeter out over the unprotected networks to encompass all of those machines that you control or trust, where ever they may be. This is a big win for any organization, or for any distributed service, that spans more than a single LAN. Charles Watt SecureWare, Inc. -----END PRIVACY-ENHANCED MESSAGE----- From ipsec-request@ans.net Fri Sep 2 09:38:23 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06374 (5.65c/IDA-1.4.4 for ); Fri, 2 Sep 1994 13:53:14 -0400 Received: by interlock.ans.net id AA21521 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 2 Sep 1994 13:40:11 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 2 Sep 1994 13:40:11 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 2 Sep 1994 13:40:11 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 2 Sep 1994 13:40:11 -0400 Date: Fri, 2 Sep 94 13:38:23 EDT From: Marcus J Ranum Message-Id: <9409021738.AA10155@tis.com> To: watt@sware.com Subject: Re: IPSEC requirements Cc: bsimpson@morningstar.com, ipsec@ans.net Charles Watt writes: >With cryptographic protection at the network level providing peer-host >authentication, data integrity and data confidentiality, you can extend >your defense perimeter out over the unprotected networks to encompass >all of those machines that you control or trust, where ever they may >be. This is a big win for any organization, or for any distributed service, >that spans more than a single LAN. No arguments here! This would be a great step forward and I don't think it'd surprise anyone to find out that TIS is working quite actively on such technologies. :) We describe this as building a "virtual network perimeter" -- you're extending your network perimeter over untrusted networks; what's important is that you're still not bringing those untrusted networks *into* your network. In other words, you're still firewalled off from the world. Once there are good link-level integrity and encryption tools available, we can start looking at the more complex problem of how do you distribute trust to machines you don't necessarily control (a real hard problem). I worry that some of the folks reading this list are trying to solve the latter problem, and that we may delay having something useful in our quest for the very hard. Or worse, that we may focus on one technology and fail to realize that it's only a small slice of a very tough problem that needs to be solved across the board. That's what Doug Gwyn was saying, basically. Just give me IP encryption and some integrity checking and that's enough. All the authentication stuff is useless and belongs at the application layer. No way in hell am I gonna trust your kernel on a remote machine to authenticate a user. Not until we have high quality host-based security. If I'm that gullible, I may as well just use rlogin and "privileged ports." mjr. From ipsec-request@ans.net Fri Sep 2 16:08:43 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07563 (5.65c/IDA-1.4.4 for ); Fri, 2 Sep 1994 16:08:43 -0400 Received: by interlock.ans.net id AA15852 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 2 Sep 1994 15:48:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 2 Sep 1994 15:48:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 2 Sep 1994 15:48:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 2 Sep 1994 15:48:23 -0400 Date: Fri, 02 Sep 94 12:27:46 From: "Housley, Russ" Encoding: 214 Text Message-Id: <9408027785.AA778534066@uu0892.spyrus.com> To: ipsec@ans.net, bsimpson@morningstar.com Subject: Re: Motorola patent 5,245,614 on compression Bill: As I said in the other message, the Authentication Protocol specification was published inApril 1984. Someone else will have to decide if this work can be used to challenge Motorola's claim. Russ From ipsec-request@ans.net Fri Sep 2 16:15:39 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA01702 (5.65c/IDA-1.4.4 for ); Fri, 2 Sep 1994 16:15:39 -0400 Received: by interlock.ans.net id AA25179 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 2 Sep 1994 15:54:41 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 2 Sep 1994 15:54:41 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 2 Sep 1994 15:54:41 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 2 Sep 1994 15:54:41 -0400 Date: Fri, 02 Sep 94 12:27:52 From: "Housley, Russ" Encoding: 1748 Text Message-Id: <9408027785.AA778534072@uu0892.spyrus.com> To: IPsec@ans.net Subject: Re: CBCC Bill: Some people will object to CBCC because it is not available in today's hardware implementations. Other than that concern, I know of no reason to avoid CBCC. You could calculate a CRC on the whole payload, then place the resulting CRC value in the final block of the payload. The CBCC XORing will ensure that the CRC does not decrypt correctly if the ciphertext is twiddled. Russ ______________________________ Reply Separator _________________________________ Subject: CBCC Author: bsimpson@morningstar.com at internet Date: 9/1/94 6:57 PM > From: "Housley, Russ" > Of course, this is correct. The tricky part is, as you say, "if > the encryption is strong and the probability of garbage passing the > integrity check is low enough." Xerox did some work in this area that > resuted in a little known DES mode - Cipher Block Chaining with Checksum > (CBCC). At the expense of one additional XOR per 64-bit data block, a sum > of the ciphertext data blocks is kept. Then, this sum is used in the > encryption (and decryption) of the final data block. CBCC ensures that > changes made to any ciphertext block impact the decrypted output of the > last block. If the last block contains an integrity check (like a CRC) or > a constant, then integrity can be checked with very little additional > overhead. Certainly much less overhead than MD5, epsecially if a constant > is used. > Sounds like this is the way to go for our default encryption technique. Why the XOR? Why not CRC over the whole payload, appended to the end of the final block before encryption? CRC-32 isn't _that_ expensive, especially compared to CBC. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Fri Sep 2 16:27:57 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA01664 (5.65c/IDA-1.4.4 for ); Fri, 2 Sep 1994 16:27:57 -0400 Received: by interlock.ans.net id AA28645 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 2 Sep 1994 16:03:22 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 2 Sep 1994 16:03:22 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 2 Sep 1994 16:03:22 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 2 Sep 1994 16:03:22 -0400 Date: Fri, 02 Sep 94 12:27:49 From: "Housley, Russ" Encoding: 1955 Text Message-Id: <9408027785.AA778534069@uu0892.spyrus.com> To: ipsec@ans.net, bsimpson@morningstar.com Subject: Re: Motorola patent 5,130,993 on checksum of encoded data Bill: The earliest description of CBCC that I have was published in April 1984. The algorithm description is in section 5.2 of the Xerox Network System (XNS) Authentication Protocol specification. The text says: The Authentication Protocol uses a variant of the standard cipher block chaining mode in which the XOR sum of plain text blocks 1 through n-1 is XORed with the plain text block n before encryption. This makes it possible to detect tampering with the cipher text. This mode of DES, called cipher block chaining with checksum (CBCC), is shown in Figure 5.2. I should have dug out the document before I made my original posting about CBCC. I did not remember the details correctly. As you can see from the above text, the plaintext is summed, not the ciphertext. There is a notice in the front of the book that says: This standard includes subject matter relating to patent(s) of Xerox Corporation. No licensee under such patent(s) is granted by implication, estoppel, or otherwise, as a result of the publication of this specification. I do not know if CBCC is patented or not. Perhaps someone employed by Xerox can tell us. Someone else will have to decide if this work can be used to challenge Motorola's claim. I do not know if the document is still available from Xerox, but here is the information from the front about ordering: Xerox Corporation Office Systems Division Network Systems Administration Office 3450 Hillview Avenue Palo Alto, CA 94304 Authentication Protocol XSIS 098404 April 1984 I know that Xerox still has a facility on Hillview in Palo Alto, but the Xerox Corporation has be reorganized many times since 1984, and the Office Systems Division does not exist anymore. Bill, if you want me to fax you Section 5.2, send me a fax phone number. Russ From ipsec-request@ans.net Fri Sep 2 21:26:28 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18361 (5.65c/IDA-1.4.4 for ); Fri, 2 Sep 1994 17:46:29 -0400 Received: by interlock.ans.net id AA34496 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 2 Sep 1994 17:31:07 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 2 Sep 1994 17:31:07 -0400 Message-Id: <199409022131.AA23740@interlock.ans.net> To: Marcus J Ranum Cc: ipsec@ans.net Subject: Re: IPSEC requirements In-Reply-To: Your message of Fri, 02 Sep 94 13:38:23 -0400. <9409021738.AA10155@tis.com> Date: Fri, 02 Sep 94 17:26:28 -0400 From: Steve Kent Marcus, I disagree with some of your comments about what one needs, and where it fits into protocol layers, to make life better in the Internet. First, you need a network, not a link layer, protocol for integrity and confidentiality, and that is what IPSP will provide. It will provide this service not only on an end-to-end basis, but also on an enclave-to-enclave or an end-to-enclave basis. All of these configurations are important to address slightly different Internet security requirements. As for authentication, I disagree with your assertion that it is best performed only at the application layer. For single user end systems, such as desktop workstations and laptop/notebnook computers, authentication provided at the network layer is essentially equivalent, in terms of its granularity, to user authentication provided at the application layer. This is not true for all applications, e.g., email and directory services are exceptions, but it is generally true. I agree that the form of the identification may be different at the network layer vs. the application layer, but that does not imply that suitable mappings cannot be established between the two in many instaances. Also, when we are providing enclave-to-enclave or end-to-enclave protection, which many folks believe is quite valuable, end user identification is generally not applicable. I agree that, in the best of all worlds, one would like to have a high degree of confidence in the security of the other end systems with which one interacts. However, such confidence will depend on a number of security disciplines being effectively pursued, incluidng computer security, procedural security, and network security. In gerenal, in the Internet, we don't have much control over or knowledge of the security measures in place at other sites, much less other individual workstations. User granularity authentication, provided at the application layer, does not necessarily make an end system more secure than the same system with network layer authentication. Even if the end system were more trusted than I have any reason to expect in this environment, the incremental security afforded by application vs. network layer security is not very great, in most instances. I would expect that a remote computer that has been compromised, e.g., by dint of failures in local computer or procedural security, will be able to do much the same damage via a secure network path whether application or network layer authentication is employed. Perahps, in a system with very strong separation of processes and an ability to isolate and contain software received from suspect locations, we might be able to mitigate the effects of some poor security practices by other sites. But I'm not convinced that application layer authentication will really make a big difference in that regard. If you can share some more concrete examples where use of application layer authentication does make a substantive difference (other than in the email and directory service examples alluded to above), then it would probably help support that contention. Note that I'm not talking about such things as signing software being retrieved acrosss the net or the like, but rather reletuive merits of access control measures enforced at the network vs. application layer, based on authentication provided at the respective layers. Steve From ipsec-request@ans.net Fri Sep 2 22:46:53 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05385 (5.65c/IDA-1.4.4 for ); Fri, 2 Sep 1994 18:53:49 -0400 Received: by interlock.ans.net id AA09318 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 2 Sep 1994 18:39:59 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 2 Sep 1994 18:39:59 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 2 Sep 1994 18:39:59 -0400 Date: Fri, 2 Sep 1994 15:46:53 -0700 From: Phil Karn Message-Id: <199409022246.PAA22853@unix.ka9q.ampr.org> To: ipsec@ans.net Cc: karn@unix.ka9q.ampr.org Subject: Some crypto timings I thought it might be useful to report on the execution speeds of some of the 386/486 assembler implementations of DES, IDEA and MD5 I've been working on lately. The IDEA code is by Colin Plumb, who write it for PGP. In keeping with the IDEA algorithm, it uses all 16-bit operations. The DES code is by myself, based on Richard Outerbridge's C code in "Applied Cryptography". It uses lots of 32-bit operations. The MD5 code is from RSAREF 2.0, but with my assembler replacement for the core MD5Transform() function. It uses 32-bit operations almost exclusively. I also rewrote the MD5Update() C function to avoid a memory copy in the common case of hashing a well-sized and well-aligned buffer. I've tested these routines on several machines, but for a consistent basis of comparison I'll give the times for my 50 Mhz 486 running DOS in real mode. The C compiler is Borland C++ 3.1. Special care was taken to ensure proper alignment of all long memory objects, since this version of the compiler does not do this. On this machine, single-key DES encrypts or decrypts at 2.78 megabits/sec, IDEA does 2.344 megabits/sec, and MD5 hashes at 19.32 megabits/sec. Observations and comments: The MD5 and DES code run even faster in 32-bit protected mode, because of their heavy use of 32-bit operations. In 16-bit real mode, every 32-bit operation takes an "override" prefix and an extra clock to execute. (The DES code does 4.44 megabits/sec on a 486-DX2-66 running BSDI). IDEA's somewhat disappointing performance is due to its heavy use of integer multiplies. 16x16 integer multiplies on the 486 take 13-26 clocks, considerably better than some earlier Intel CPUs (the 8088/86 took 113-118 clocks) but nowhere near that of a DSP that can do it in one clock. But the IDEA code does only 16-bit operations and will run on an 8086, while the DES and MD5 code takes considerable advantages of the 32-bit registers on the 386 and 486. So I wouldn't be too surprised if IDEA were to outperform DES on the older CPUs. And of course, comparing IDEA to single-key DES is a little unfair. Triple DES should run a little better than 1/3 the speed of single DES since the initial and final permutations only have to be done once. IDEA would still have the advantage here. MD5 hashing is something like 7 times the speed of DES, the fastest cipher. So it still looks like a good idea to encrypt before adding the authenticator rather than the reverse to minimize the vulnerability of your system to being swamped by bogus packets in a denial-of-service attack. I haven't timed it yet, but it does seem that a MD5-based cipher would likely outperform single key DES. Using the MD5Transform() function as the core of a cipher involves a 4:1 speed penalty over using it as a hash function (each call to MD5Transform() takes 64 bytes but produces only 16 bytes), but that still leaves a 1.75:1 advantage over DES. And the effective key would be much larger. Phil From ipsec-request@ans.net Sat Sep 3 08:00:07 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15599 (5.65c/IDA-1.4.4 for ); Sat, 3 Sep 1994 08:00:07 -0400 Received: by interlock.ans.net id AA30480 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 3 Sep 1994 07:48:19 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 3 Sep 1994 07:48:19 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 3 Sep 1994 07:48:19 -0400 From: Masataka Ohta Return-Path: Message-Id: <9409031141.AA05408@necom830.cc.titech.ac.jp> Subject: Re: IPSEC requirements To: kent@BBN.COM (Steve Kent) Date: Sat, 3 Sep 94 20:40:52 JST Cc: mjr@tis.com, ipsec@ans.net In-Reply-To: <199409022131.AA23740@interlock.ans.net>; from "Steve Kent" at Sep 2, 94 5:26 pm X-Mailer: ELM [version 2.3 PL11] > Marcus, > > I disagree with some of your comments about what one needs, > and where it fits into protocol layers, to make life better in the > Internet. First, you need a network, not a link layer, protocol for > integrity and confidentiality, and that is what IPSP will provide. It > will provide this service not only on an end-to-end basis, but also on > an enclave-to-enclave or an end-to-enclave basis. It seems to me that there is a misconception on layering. All firewalls today are operating at the transport layer. Firewalls looks into transport header for port #s. Sockd explicitely is a transport layer relay. Of course, there is no reason that some transport layer data can not be mixed with network layer data. So, it's OK to have an implementation which put transport layer security data into IP header. Layering is NOT for implementation. But viewing the data is at the network layer is, IMHO, a layering confusion. > As for authentication, I disagree with your assertion that it > is best performed only at the application layer. Application layer protection is application dependent. It is impossible to do it on firewalls without specific knowledge on applications and they are not so efficient. Application layer protection should be best performed end-end over protected transport layer. But, > Also, when we are providing > enclave-to-enclave or end-to-enclave protection, which many folks > believe is quite valuable, end user identification is generally not > applicable. that's not a valid objection. For example, an application, nntpd, actually allows enclave-wise protection specification. Application layer filter specification, in general, will be (user spec, application spec, host spec) and you can specify: (any user, any application, hosts in a certain subnet) which is what you need for enclave-to-enclave or end-to-enclave protection. "Enclave" issue is merely a wildcarding issue. Of course, doing application layer protection on firewalls means firewalls have knowledges on foreign users which is inefficient, unrealistic and shoule be avoided. Masataka Ohta From ipsec-request@ans.net Sat Sep 3 14:55:26 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06988 (5.65c/IDA-1.4.4 for ); Sat, 3 Sep 1994 14:02:27 -0400 Received: by interlock.ans.net id AA20910 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 3 Sep 1994 13:51:16 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 3 Sep 1994 13:51:16 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 3 Sep 1994 13:51:16 -0400 Date: Sat, 3 Sep 94 14:55:26 GMT From: "William Allen Simpson" Message-Id: <3119.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Re: IPSEC requirements Several of the things which you said make no sense to me: > From: Marcus J Ranum > If the trust boundary is your trusted machine, you can't > assume that data from an untrusted machine is authentic. Even if > it's authenticated and has the IP security stamp of approval. If it's authenticated, then it _must_ be a trusted machine. You have already shared a secret or otherwise added that machine to your web of trust. I don't understand how it could be authenticated otherwise. You seem to be confusing application authentication with IP authentication. > To put this another way: would you let traffic through > your firewall if it was protected by IP security options and > was coming from an authenticated user logging in from, say, > gnu.ai.mit.edu, or a public access machine? I wouldn't. Again, why would you have added such a machine to your IP security associations, except that you trust that machine's administration? All that IP authentication guarantees is that the traffic is arriving from the machine which claims to have originated the traffic. So, yes, I would certainly let a public machine access my machine, given that I had a security association with the machine. (FYI, I exclusively use public access addresses here in Michigan, and the firewall which filters traffic allows such addresses through. Note the first "received" in this very message. Anyone could spoof being me, except that the public access addresses authenticate the users with PPP, so the spoofer could ultimately be traced.) > Kerberos is a similar situation. ... Suppose > I modify the "klogin" program on my workstation and you use > it to log into your home machine. The kerberos part of the > system is still perfectly strong, but I now know your kerberos > password and can be you. Why would I have added your workstation to _MY_ IP security associations? And why wouldn't I be using my own trusted laptop? Again, login is an application authentication. IP authentication has nothing to do with Kerberos. > Your trust boundary is going to encompass all the systems > you control, or the systems people you are willing to trust > control, and nobody else. That's right. > That's the *CURRENT* situation with > firewalls HUH? Firewalls merely allow certain IP addresses/protocols through. They say nothing about trust, and nothing about control! For example, every time I go to IETF, I have to get the firewall where my POP3 server is located to allow a range of IP addresses through. That doesn't mean we either trust or control those addresses. It just means that we have limited the expectations of where such POP requests might originate. The authentication of the POP3 request is what establishes the trust of the session. And that is easily compromised, which is why we want something better. Moreover, we know that practically everybody who goes to IETF is capable of sniffing the application authentication as it goes through. Do I trust _everybody_ at IETF? Hey, you're fine folks, but hell NO! Sorry, as I said before, firewalls don't buy you _anything_ except a buffer against malicious "denial of service" attacks. Otherwise, they are worthless, a pain to administer, and nothing but trouble for the users, whether stationary or mobile. The IP authentication will completely obsolete firewalls, because it _does_ add trust and control. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Sat Sep 3 17:53:17 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13354 (5.65c/IDA-1.4.4 for ); Sat, 3 Sep 1994 15:04:03 -0400 Received: by interlock.ans.net id AA08227 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 3 Sep 1994 14:57:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 3 Sep 1994 14:57:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 3 Sep 1994 14:57:39 -0400 Date: Sat, 3 Sep 94 17:53:17 GMT From: "William Allen Simpson" Message-Id: <3124.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Re: Some crypto timings > From: Phil Karn > On this machine, single-key DES encrypts or decrypts at 2.78 > megabits/sec, IDEA does 2.344 megabits/sec, and MD5 hashes at 19.32 > megabits/sec. > Wonderful. Thanks for the excellent work, Phil. Looks to me like MD5 is good enough for authentication at Ethernet speeds, which is where these processors are likely to be attached. That's what I was worried about. You mention an MD5 based cipher. That would be great, since we could minimize code and maximize speed in low-end boxes. Please keep us posted. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Sat Sep 3 14:22:10 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17077 (5.65c/IDA-1.4.4 for ); Sat, 3 Sep 1994 18:30:13 -0400 Received: by interlock.ans.net id AA32746 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 3 Sep 1994 18:24:22 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Sat, 3 Sep 1994 18:24:22 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 3 Sep 1994 18:24:22 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 3 Sep 1994 18:24:22 -0400 Date: Sat, 3 Sep 94 18:22:10 EDT From: Marcus J Ranum Message-Id: <9409032222.AA14848@tis.com> To: bsimpson@morningstar.com, ipsec@ans.net Subject: Re: IPSEC requirements I'm willing to drop this discussion, btw, if there's a feeling that it's going too far off-track for IPSEC. Let me know. The reason I'm pursuing this is because I do think it's very important that whatever IPSEC options evolve are going to need to work properly with firewalls. What those firewalls look and act like is a subject of debate. :) I'd like to define two terms I'm using, FYI: Firewall -- a system or combination of systems that enforces a trust boundary at the perimeter of an isolated network. This may be application level *or* IP level. Masataka Ohta asserted that all firewalls are IP level systems -- I guess he's not familiar with the work Cheswick and Bellovin and I have been doing, which is mostly application level. Virtual network perimeter -- a network consisting entirely of trusted links, some of which may be running over untrusted links via encapsulation/encryption. Link state *typically* relies on some form of authentication, e.g., an authenticated PPP link, or an authenticated encrypted IP point-to-point route. I think of a virtual network perimeter of consisting of *HOSTS* *AND* their users. Conceptually, I think of a virtual network perimeter as "tunneling through" or "going around" or "gatewaying through" the firewall. In other words, if you're a member of the virtual network perimeter, the firewall is transparent. If you're not, the firewall may stop you, force you to prove who you are, or whatever, before letting you through. The reason I draw these distinctions is because, in my mind at least, the firewall is "gone" if you're a member of the virtual perimeter. By extension, all members of the virtual perimeter are "trusted" to some degree [to whatever degree you'd trust any other machine on your LAN/WAN that was behind your firewall]. What I suspect most folks are looking for (myself included) is tools for building virtual network perimeters. Where things get interesting is if the tools are going to be extended to permit *USER* membership in the virtual network perimeter. I think that's where I have been confusing people, and I aplogise if the discussion I've started is unproductive. Host-level membership in the VNP is not a big deal, since you're implicitly trusting the host and its users, since you trust the administration of that host. The problem that I think is going to require some really careful thinking about is if we try to design a mechanism so that an individual remote *user* can gain access to the VNP without being on a host that is a member the VNP. In firewalling terms, the way this normally works is you somehow authenticate yourself to the firewall (as an individual) and it thereafter waves you through. Present technologies for doing this are cumbersome and could use improvement [any of you who have seen those of us at conferences who telnet/rlogin through our firewalls using application level relays with handheld calculators should be familiar with the level of transparency of these approaches] Perhaps this clarifies my original remarks. Now I'd like to discuss some extracts from the mail from Steve Kent and Bill Simpson in that light. Steve Kent writes: >First, you need a network, not a link layer, protocol for >integrity and confidentiality, and that is what IPSP will provide. It >will provide this service not only on an end-to-end basis, but also on >an enclave-to-enclave or an end-to-enclave basis. > As for authentication, I disagree with your assertion that it >is best performed only at the application layer. For single user end >systems, such as desktop workstations and laptop/notebnook computers, >authentication provided at the network layer is essentially >equivalent, in terms of its granularity, to user authentication Steve is, of course, 100% right. I believe my original remarks which prompted this response were a result of my confusing the objectives of the authentication system. What Steve is referring to here appears to be what I'd call members of the VNP -- they're all trusted hosts. Where I get confused is whether one of the objectives of IPSEC is to permit individual user membership in the VNP. That was what prompted my remarks about authentication being best at the application layer. If I'm at a remote site, on a trusted host that's part of my VNP, then of course, I won't have any need to do anything especially fancy. If, however, I am at a remote site, on an untrusted host, is it the case that IPSEC doesn't help me at all? That's OK, if so, I'm just trying to delimit the problem space. This is what prompted my remarks a few weeks ago that, in effect, we're never going to be rid of firewalls. Not until we have a robust means of bringing an individual *user* on an untrusted host into our VNP. Until we can do that, then we'll have firewalls. [Even if we do, it's likely that the thing enforcing the access will be called a "firewall"] [And I'll be building them.] Steve Kent writes: > Note that I'm not talking about such things as signing >software being retrieved acrosss the net or the like, but rather >reletuive merits of access control measures enforced at the network >vs. application layer, based on authentication provided at the >respective layers. I think we're in agreement, but that I simply didn't explain my question adequately before. :( Succinctly put, I don't think that network layer access control measures work as well as application layer access control measures if the remote member is an untrusted host. I'm not sure that application layer approaches work *either*. Bill Simpson writes: (in response to me) >All that IP authentication guarantees is that the traffic is arriving >from the machine which claims to have originated the traffic. Precisely. And what I'm saying is that this doesn't buy you much. It means the machine can (possibly) become a member of your VNP. That's a far, far, far step from "getting rid of firewalls" which some members on this list seem to think this is going to do. Bill Simpson continues: >So, yes, I would certainly let a public machine access my machine, given >that I had a security association with the machine. In other words, if you trust it. This concerns me. After a while, there will be some really interesting opportunities for island-hopping attacks along the strands of the web of trust. [excuse me for being poetic] This is not really solving a security problem; it's just developing a tool for building secure virtual perimeters. Bigger, better firewalls. That's fine with me, but let's be clear that what's happening is further balkanization, not an increase in the trustability of the 'net. Bill Simpson continues: >(FYI, I exclusively use public access addresses here in Michigan, and >the firewall which filters traffic allows such addresses through. Note >the first "received" in this very message. Anyone could spoof being me, >except that the public access addresses authenticate the users with PPP, >so the spoofer could ultimately be traced.) Your PPP node is then part of your VNP, even though you're not encrypting/authenticating your traffic. So your firewall is trusting your PPP node. What do you do if you are logged onto an *untrusted* outside node?? Presumably when you are, then you have to do something more elaborate to get through your firewall, no? Bill Simpson writes: (in response to me) >> Kerberos is a similar situation. ... Suppose >> I modify the "klogin" program on my workstation and you use >> it to log into your home machine. The kerberos part of the >> system is still perfectly strong, but I now know your kerberos >> password and can be you. > >Why would I have added your workstation to _MY_ IP security >associations? Clearly, I see no reason why you would! That's my point. This system isn't really improving security or trust, it's just letting folks build bigger, better trusted virtual network perimeters. We're not making firewalls go away, and we're not improving the security of the 'net at all. >And why wouldn't I be using my own trusted laptop? If all you're trying to do is build bigger, better firewalls, then definitely, there's no reason not to use your own trusted laptop. :) You're not making the firewall go away -- you're just inventing a magical way of moving your laptop (virtually) behind the firewall. mjr. From ipsec-request@ans.net Sun Sep 4 15:55:39 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05462 (5.65c/IDA-1.4.4 for ); Sun, 4 Sep 1994 13:28:07 -0400 Received: by interlock.ans.net id AA13980 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 4 Sep 1994 13:15:02 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 4 Sep 1994 13:15:02 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 4 Sep 1994 13:15:02 -0400 Date: Sun, 4 Sep 94 15:55:39 GMT From: "William Allen Simpson" Message-Id: <3129.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Re: IPSEC requirements Well, it seems obvious to me that Marcus has expanded the definition of "firewalls" far beyond the usual term. > From: Marcus J Ranum > Firewall -- a system or combination of systems that > enforces a trust boundary at the perimeter of an isolated > network. This may be application level *or* IP level. > ... > I think of a virtual network > perimeter of consisting of *HOSTS* *AND* their users. > In other words, a machine which has a login or FTP prompt (authenticates the user at the application level) is a "firewall". Please call it something else. Most of us don't mean this when we say "firewall". A firewall is an IP level concept. Even peeking into the IP Protocol field is still an IP level concept. You use PPP as an example. We in that segment of the industry don't call these devices "firewalls" either. We call them Network Access Servers. Authenticating to a NAS does not grant you other trusted accesses, such as automatic access to other machines in the net (although there is a fellow from Cisco who proposed that recently). All it does is determine whether you are allowed access through that NAS. Simple, clean. > Host-level membership in the VNP is not a big deal, > since you're implicitly trusting the host and its users, > since you trust the administration of that host. Agreed. > The problem > that I think is going to require some really careful thinking > about is if we try to design a mechanism so that an individual > remote *user* can gain access to the VNP without being on a > host that is a member the VNP. That is _way_ outside what we are trying to do. > Where I get confused is whether one of the objectives > of IPSEC is to permit individual user membership in the VNP. It is not. > That was what prompted my remarks about authentication being > best at the application layer. If I'm at a remote site, on > a trusted host that's part of my VNP, then of course, I won't > have any need to do anything especially fancy. If, however, > I am at a remote site, on an untrusted host, is it the case > that IPSEC doesn't help me at all? > It does not. > Succinctly put, I > don't think that network layer access control measures work > as well as application layer access control measures if the > remote member is an untrusted host. I'm not sure that application > layer approaches work *either*. > Of course, it doesn't work. If you don't trust the host, then all the authentication has to be done _outside_ the host. If you are doing it offline on a calculator, then _you're_ the trusted host. Why waste the time? Just connect your trusted host directly. This goes with someone along the way commenting that clock based chellenges are bad, because the attacker could change the clock and get the answers to later challenges. This is (IMnsHO) pretty silly, since if they control your clock, they probably control everything else, too. > Your PPP node is then part of your VNP, even though > you're not encrypting/authenticating your traffic. So your > firewall is trusting your PPP node. What do you do if you > are logged onto an *untrusted* outside node?? Presumably when > you are, then you have to do something more elaborate to get > through your firewall, no? > HUH? How could I be "logged onto an *untrusted* outside node"? This is self-contradictory. If I am logged in, I must have authenticated. If I can authenticate, the node must be trusted. Otherwise, it wouldn't have my authentication information. > >And why wouldn't I be using my own trusted laptop? > > If all you're trying to do is build bigger, > better firewalls, then definitely, there's no reason > not to use your own trusted laptop. :) You're not making > the firewall go away -- you're just inventing a magical > way of moving your laptop (virtually) behind the firewall. > Again, this makes no sense to me. Using Mobile-IP or some such mechanism to authenticate myself has no relation to "firewalls". The Home Agent is not a "firewall". It is a "router". The authentication used is the same needed for _any_ router to exchange routing updates with another router. We hope to use IP-SEC for that, since it is an IP level node-node activity. Just as we don't call routing forwarders "gateways" anymore, because the term was taken by application level, please don't use the term "firewall" for authentication at any level. Firewalls do not do authentication. I don't grok that speak. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Sun Sep 4 15:33:40 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15609 (5.65c/IDA-1.4.4 for ); Sun, 4 Sep 1994 19:44:27 -0400 Received: by interlock.ans.net id AA16443 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 4 Sep 1994 19:35:52 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Sun, 4 Sep 1994 19:35:52 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 4 Sep 1994 19:35:52 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 4 Sep 1994 19:35:52 -0400 Date: Sun, 4 Sep 94 19:33:40 EDT From: Marcus J Ranum Message-Id: <9409042333.AA25221@tis.com> To: bsimpson@morningstar.com, ipsec@ans.net Subject: Re: IPSEC requirements >Well, it seems obvious to me that Marcus has expanded the definition of >"firewalls" far beyond the usual term. OOps, sorry. I suggest you read something about what's being done in "firewalls" these days -- most of the concepts I present are not new, nor are they unique to me, though I did have something to do with their formation. Check our Cheswick and Bellovin's book for a good intro. >Please call it something else. Most of us don't mean this when we say >"firewall". A firewall is an IP level concept. Generally, when you're talking to folks who are doing firewalls, you may find that "Firewall" != "router + screening" 100% of the time. Perhaps you may wish to call them something else, or perhaps you may wish me to call them something else, but the term "firewall" has a fairly wide interpretation these days. It's best to understand that, to prevent confusion, which was the purpose of my previous missive. Perhaps one should distinguish between application level firewalls and IP level firewalls. In future discussion here, I will do that to reduce confusion. Let's avoid a battle of definitions if possible. It's too late to change the use of the word "firewall" in the firewall community to meet your understanding. (Many of us call an IP level "firewall" a "screening router") >authentication has to be done _outside_ the host. If you are doing it >offline on a calculator, then _you're_ the trusted host. Why waste the >time? Just connect your trusted host directly. No, if you're using offline authentication, then you are a trusted party, possibly using an untrusted host. There's a big difference. I could be using, say, a version of telnet that logs all my keystrokes and my session encryption key, but if my offline authentication is tamper-proof, then an attacker will have a lot of trouble pretending to be me when creating a different session. [The current session could be completely compromised, of course. If I were a "trusted host" personally, then I'd be using only my own software that I could trust, etc, etc] >> Your PPP node is then part of your VNP, even though >> you're not encrypting/authenticating your traffic. So your >> firewall is trusting your PPP node. What do you do if you >> are logged onto an *untrusted* outside node?? Presumably when >> you are, then you have to do something more elaborate to get >> through your firewall, no? >> >HUH? How could I be "logged onto an *untrusted* outside node"? This is >self-contradictory. > >If I am logged in, I must have authenticated. If I can authenticate, >the node must be trusted. Otherwise, it wouldn't have my authentication >information. Terminology confusion again. "Logged on" in the above statement means "on the machine" -- could be a guest account, a guest terminal server at a conference, whatever. The host in question may not have your authentication information and may, in fact, have no idea who you are -- you could be "conference guest login #1" In such a case, I can't see any reason (unless you were trying to bring individual users into the VNP) why you would wish to have authentication information on an untrusted host, unless the authentication protocol was robust enough that it couldn't be harmed if that host were already compromised. >> If all you're trying to do is build bigger, >> better firewalls, then definitely, there's no reason >> not to use your own trusted laptop. :) You're not making >> the firewall go away -- you're just inventing a magical >> way of moving your laptop (virtually) behind the firewall. >> >Again, this makes no sense to me. Using Mobile-IP or some such >mechanism to authenticate myself has no relation to "firewalls". >The Home Agent is not a "firewall". It is a "router". It's useless to quibble about terminology, I'm sorry. Whatever you want to call it, it's part of your security perimeter and it's part of the mechanism that enforces the integrity of your perimeter. It may be a "router" but that's an implementation detail. Whatever terms you care to substitute in place of mine, the effect of my statement remains: you're not solving any access problems; you're just hiding them by logically moving everything into your security perimeter. That's fine. In the language of firewalls you're not making the firewall go away, you're just moving everything you own behind it. >Just as we don't call routing forwarders "gateways" anymore, because the >term was taken by application level, please don't use the term >"firewall" for authentication at any level. Firewalls do not do >authentication. Sorry, but my "firewalls" do authentication. Let's accept that there's not a standard language and just work with the concepts, OK? I won't try to tell you what you can and can't call a router if you don't try to tell me what a "firewall" is. :) From your reaction to my earlier mail, you understood what I was saying; that is sufficient. mjr. From ipsec-request@ans.net Mon Sep 5 00:04:39 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05604 (5.65c/IDA-1.4.4 for ); Sun, 4 Sep 1994 20:13:49 -0400 Received: by interlock.ans.net id AA17652 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 4 Sep 1994 20:07:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Sun, 4 Sep 1994 20:07:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 4 Sep 1994 20:07:31 -0400 From: Gerald J Creager Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 4 Sep 1994 20:07:31 -0400 Message-Id: <199409050004.TAA10021@sparc38.cs.tamu.edu> Subject: Re: IPSEC requirements To: mjr@tis.com (Marcus J Ranum) Date: Sun, 4 Sep 1994 19:04:39 -0500 (CDT) Cc: ipsec@ans.net In-Reply-To: <9409042333.AA25221@tis.com> from "Marcus J Ranum" at Sep 4, 94 07:33:40 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1946 Marcus J Ranum sez: > Generally, when you're talking to folks who are doing > firewalls, you may find that "Firewall" != "router + screening" > 100% of the time. Perhaps you may wish to call them something > else, or perhaps you may wish me to call them something else, > but the term "firewall" has a fairly wide interpretation these > days. It's best to understand that, to prevent confusion, which > was the purpose of my previous missive. Guess I have to side with Bill's interpretation here. The IP-level firewall is in widespread use, at least from the places I play. > Perhaps one should distinguish between application > level firewalls and IP level firewalls. In future discussion > here, I will do that to reduce confusion. That ought to be an acceptable alternative for the time being... > Let's avoid a battle of definitions if possible. It's > too late to change the use of the word "firewall" in the > firewall community to meet your understanding. (Many of us > call an IP level "firewall" a "screening router") And, while I might devine your definition of a "screening router," I'd STILL have to think about it each time it's used for a bit. It's not the term I'd expect. > It's useless to quibble about terminology, I'm sorry. > Whatever you want to call it, it's part of your security perimeter > and it's part of the mechanism that enforces the integrity of > your perimeter. It may be a "router" but that's an implementation > detail. Actually, if we don't get the terminology "right," whatever we determine "right" to be, we shall continue to argue. Semanitcs is in fact very important in a technical discussion. If we are all discussing different topics but using like-sounding terminology, we shall become seriously confused. Further, if we're discussing convergent themes with each using his/her pet phraseology, on this path, too, lies danger. Gerry gerry@cs.tamu.edu gcreager@gothamcity.jsc.nasa.gov From ipsec-request@ans.net Mon Sep 5 03:47:52 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05570 (5.65c/IDA-1.4.4 for ); Sun, 4 Sep 1994 23:56:49 -0400 Received: by interlock.ans.net id AA32582 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 4 Sep 1994 23:48:00 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 4 Sep 1994 23:48:00 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 4 Sep 1994 23:48:00 -0400 Message-Id: X-Sender: brian@harry.lloyd.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 4 Sep 1994 20:47:52 -0700 To: Gerald J Creager , mjr@tis.com (Marcus J Ranum) From: brian@lloyd.com (Brian Lloyd) Subject: Re: IPSEC requirements Cc: ipsec@ans.net At 19:04 9/4/94 -0500, Gerald J Creager wrote: >Marcus J Ranum sez: >> Generally, when you're talking to folks who are doing >> firewalls, you may find that "Firewall" != "router + screening" >> 100% of the time. Perhaps you may wish to call them something >> else, or perhaps you may wish me to call them something else, >> but the term "firewall" has a fairly wide interpretation these >> days. It's best to understand that, to prevent confusion, which >> was the purpose of my previous missive. > >Guess I have to side with Bill's interpretation here. The IP-level firewall >is in widespread use, at least from the places I play. Well, I have to side with Marcus. There are lots of types of firewalls, the IP "packet screening router" is but one type of firewall. It is the most common and many seem to feel that firewall == packet-screening-router, but I always find it makes life simpler to make a point of identifying which type of firewall I am talking about. I am 100% for anything that removes ambiguity. Let's just be unambiguous here for the sake of clarity. Brian Lloyd, President Lloyd Internetworking brian@lloyd.com 3031 Alhambra Drive (916) 676-1147 - voice Suite 102 (916) 676-3442 - fax Cameron Park, CA 95682 From ipsec-request@ans.net Mon Sep 5 06:24:26 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA01738 (5.65c/IDA-1.4.4 for ); Mon, 5 Sep 1994 06:24:26 -0400 Received: by interlock.ans.net id AA14369 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 5 Sep 1994 06:14:56 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 5 Sep 1994 06:14:56 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 5 Sep 1994 06:14:56 -0400 From: Masataka Ohta Return-Path: Message-Id: <9409050642.AA11521@necom830.cc.titech.ac.jp> Subject: Re: IPSEC requirements To: mjr@tis.com (Marcus J Ranum) Date: Mon, 5 Sep 94 15:42:30 JST Cc: bsimpson@morningstar.com, ipsec@ans.net In-Reply-To: <9409032222.AA14848@tis.com>; from "Marcus J Ranum" at Sep 3, 94 6:22 pm X-Mailer: ELM [version 2.3 PL11] > Masataka > Ohta asserted that all firewalls are IP level systems No, I never did. > -- I guess > he's not familiar with the work Cheswick and Bellovin and I > have been doing, which is mostly application level. I guess you don't understand what transport layer means. You can construct secure application layer over secure transport layer. Masataka Ohta From ipsec-request@ans.net Mon Sep 5 06:26:52 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA01743 (5.65c/IDA-1.4.4 for ); Mon, 5 Sep 1994 06:26:52 -0400 Received: by interlock.ans.net id AA26417 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 5 Sep 1994 06:17:34 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 5 Sep 1994 06:17:34 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 5 Sep 1994 06:17:34 -0400 From: Masataka Ohta Return-Path: Message-Id: <9409050633.AA11474@necom830.cc.titech.ac.jp> Subject: Re: IPSEC requirements To: bsimpson@morningstar.com Date: Mon, 5 Sep 94 15:33:21 JST Cc: ipsec@ans.net In-Reply-To: <3129.bill.simpson@um.cc.umich.edu>; from "William Allen Simpson" at Sep 4, 94 3:55 pm X-Mailer: ELM [version 2.3 PL11] > Please call it something else. Most of us don't mean this when we say > "firewall". A firewall is an IP level concept. Even peeking into the > IP Protocol field is still an IP level concept. Firewalls are quite appropriately implemented to look at port numbers in TCP/UDP headers, not IP headers. So, please don't try to misspecify them. It's still OK to have a transport layer IP-SEC field in IP header for implementation efficiency. Masataka Ohta From ipsec-request@ans.net Tue Sep 6 12:32:53 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA01763 (5.65c/IDA-1.4.4 for ); Tue, 6 Sep 1994 08:54:19 -0400 Received: by interlock.ans.net id AA21357 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 6 Sep 1994 08:33:28 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 6 Sep 1994 08:33:28 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 6 Sep 1994 08:33:28 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 6 Sep 1994 08:33:28 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 6 Sep 1994 08:33:28 -0400 Message-Id: <9409061232.AA21058@snark.imsi.com> To: Gerald J Creager Cc: mjr@tis.com (Marcus J Ranum), ipsec@ans.net Subject: Re: IPSEC requirements In-Reply-To: Your message of "Sun, 04 Sep 1994 19:04:39 CDT." <199409050004.TAA10021@sparc38.cs.tamu.edu> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 06 Sep 1994 08:32:53 -0400 From: "Perry E. Metzger" Gerald J Creager says: > Marcus J Ranum sez: > > Generally, when you're talking to folks who are doing > > firewalls, you may find that "Firewall" != "router + screening" > > 100% of the time. Perhaps you may wish to call them something > > else, or perhaps you may wish me to call them something else, > > but the term "firewall" has a fairly wide interpretation these > > days. It's best to understand that, to prevent confusion, which > > was the purpose of my previous missive. > > Guess I have to side with Bill's interpretation here. The IP-level firewall > is in widespread use, at least from the places I play. I've rarely seen IP layer filtering in use. My clients tend to be too paranoid. I've participated in the construction of a number of these beasts, and we've always built application level gateways with the standard two router-D.M.Z. machine approach. Yes, firewall construction has become semi-standarized in some quarters. Yes, its is application layer much of the time. Firewalls can be either at the IP layer or at application layers. See Ches and Steve Bellovin's book on the topic. Marcus is absolutely right on this point. Perry From ipsec-request@ans.net Tue Sep 6 14:34:35 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07138 (5.65c/IDA-1.4.4 for ); Tue, 6 Sep 1994 10:53:17 -0400 Received: by interlock.ans.net id AA19295 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 6 Sep 1994 10:39:02 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 6 Sep 1994 10:39:02 -0400 Message-Id: <199409061439.AA36443@interlock.ans.net> To: Masataka Ohta Subject: Re: IPSEC requirements Cc: ipsec@ans.net Date: Tue, 06 Sep 94 10:34:35 -0400 From: Steve Kent Masataka, I agree with Marcus that the the term "firewall" has come to mean two very different types of perimeter security, operating at the IP layer or at the application layer. I think relatively few firewalls operate at the transport layer, per se, perhaps because of the difficulty of concatenating TCP connections. The IP layer firewalls examine TCP and UDP port fields in making filtering or screening decisions, but that is not the same as implementing full-fledged transport layer processing. (It's a minor form of cheating.) Application layer firewalls are generally a pain for users to deal with. Double logins are annoying and proxy application processing is complex and may not preserve the application semantics. It also creates the potential for processing bottlenecks. One can replace the client software on user machines within an enclave to ameliorate the problems, but that is a difficult task in some environments, e.g., with a heterogeneous set of user platforms and with application software that is not available in source code form. Despite our differences of opinion on several details, we do agree that application layer firewalls are not a desirable endpoint for Internet security. Steve From ipsec-request@ans.net Tue Sep 6 11:34:42 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14858 (5.65c/IDA-1.4.4 for ); Tue, 6 Sep 1994 11:34:42 -0400 Received: by interlock.ans.net id AA31224 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 6 Sep 1994 11:20:26 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 6 Sep 1994 11:20:26 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 6 Sep 1994 11:20:26 -0400 From: Masataka Ohta Return-Path: Message-Id: <9409061512.AA18004@necom830.cc.titech.ac.jp> Subject: Re: IPSEC requirements To: kent@BBN.COM (Steve Kent) Date: Wed, 7 Sep 94 0:12:02 JST Cc: ipsec@ans.net In-Reply-To: <9409061432.AA17842@necom830.cc.titech.ac.jp>; from "Steve Kent" at Sep 6, 94 10:34 am X-Mailer: ELM [version 2.3 PL11] > I agree with Marcus that the the term "firewall" has come to > mean two very different types of perimeter security, operating at the > IP layer or at the application layer. I think relatively few > firewalls operate at the transport layer, per se, perhaps because of > the difficulty of concatenating TCP connections. I'm afraid concatenating TCP connections is for firewalls at the application layer (or the above). For TCP, payload is just a stream of bytes. The transport layer does not try to interpret the data in the payload. It's application which gives the semantics for the payload. BTW, it is real bad layering violation for routers peek TCP and does not work when there are mutiple alternative routes, which is the other proof that looking at pay load is for the application layer firewall. > The IP layer > firewalls examine TCP and UDP port fields in making filtering or > screening decisions, but that is not the same as implementing > full-fledged transport layer processing. (It's a minor form of cheating.) Urrrr, see RFC 768: 0 7 8 15 16 23 24 31 +--------+--------+--------+--------+ | Source | Destination | | Port | Port | +--------+--------+--------+--------+ | | | | Length | Checksum | +--------+--------+--------+--------+ | | data octets ... +---------------- ... User Datagram Header Format Port # is the only essential data of the transport layer UDP header! So, if you call it minor cheating, the entire concept of the transport layer is the minor cheating. > Application layer firewalls are generally a pain for users to > deal with. Not necessarily. > Double logins are annoying Applications behind an application firewall does not need login and can simply believe the firewall for the identification of the user. > and proxy application > processing is complex and may not preserve the application semantics. > It also creates the potential for processing bottlenecks. Those are the problems. It is my understanding that applications are so different each other that it is impractical to construct application independent application layer firewalls. And if firewalls are application dependent, they are rather a part of secured application than a general purpose firewalls. > Despite our differences of opinion on several details, we do > agree that application layer firewalls are not a desirable endpoint > for Internet security. Sure, but I'll be a lot more comfortable if we stop cheating and can agree that "IP level" means "network or transport layer". Masataka Ohta From ipsec-request@ans.net Tue Sep 6 18:48:31 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16267 (5.65c/IDA-1.4.4 for ); Tue, 6 Sep 1994 15:11:08 -0400 Received: by interlock.ans.net id AA27133 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 6 Sep 1994 14:53:24 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 6 Sep 1994 14:53:24 -0400 Message-Id: <199409061853.AA27129@interlock.ans.net> To: Masataka Ohta Subject: Re: IPSEC requirements Cc: ipsec@ans.net Date: Tue, 06 Sep 94 14:48:31 -0400 From: Steve Kent Masataka, I understand the difference between transport and application layers, and I meant what I said about pure transport relaying vs. application relaying (or proxy applications). Looking at TCP/UDP port values is a layer violation for an IP layer intermediate system, and one which I do not endorse. I don't think it causes problems for the reason you cite. If one makes filtering (screening) decisions based on port fields, then these decisions should be consistent irrespective of whether the packets take a consistent route or if alternative routes into the enclave are taken. In contrast, application layer firewalls do limit ones opportunity to take advantage of alternative routes. However, Marcus and others have pointed out that one can home multiple routers with different attachment points to external nets to a single fireall machine, so as to retain much of the alternate routing flexability. Also, the reliability of machines used as application layer firewalls has usually been excellent, so the single piont of failure posed by a firewall of this sort also may not be as bad as one might think. What would be a terrible problem for an intermediate system is trying to eumlate or track the TCP state information for each connection through that system. That is where alternate routes can kill you. So, in that light, looking at the port fields is cheating a little, but looking at the sequence numbers and flags would be really severe cheeting! Applications behind a firewall do not automatically get login info from a firewall, e.g., the target machine and the firewall may require different user ID technology and thus be incompatible in terms of relaying user I&A. Also, application layer firewalls often are set up to control outgoing connections, where the user is behind the firewall and the target application is outside. Here the target may not be willing to trust user I&A info provided by some firewall elsewhere, and that results in multiple logins. Finally, yes, we do agree that application-dependent firewalls are a long term problem because they require tracking evolving applications and the intermediate implementation of these applications may loose functionality for the users. Steve From ipsec-request@ans.net Tue Sep 6 14:00:33 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17851 (5.65c/IDA-1.4.4 for ); Tue, 6 Sep 1994 18:17:17 -0400 Received: by interlock.ans.net id AA33241 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 6 Sep 1994 18:03:19 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 6 Sep 1994 18:03:19 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 6 Sep 1994 18:03:19 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 6 Sep 1994 18:03:19 -0400 Date: Tue, 6 Sep 94 18:00:33 EDT From: Marcus J Ranum Message-Id: <9409062200.AA04946@tis.com> To: kent@BBN.COM, mohta@necom830.cc.titech.ac.jp Subject: Re: IPSEC requirements Cc: ipsec@ans.net > Finally, yes, we do agree that application-dependent firewalls >are a long term problem because they require tracking evolving >applications and the intermediate implementation of these applications >may loose functionality for the users. I know I seem like I'm throwing a lot of wrenches into the works, but I'd like to point out that there are lots of good reasons for using restrictive application-dependent firewalls. That, in fact, is why I was careful to open the discussion on trust boundaries in IPSEC versus firewalls. A network security system is more than just a bunch of components; it has to be looked at in its completeness. Having an IP-layer firewall that permits arbitrary traffic between members of the VNP is going to address a lot of problems, but it doesn't help out with the problems of safely (or as safely as possible) communicating with hosts that are *outside* the VNP. In that case, an application-dependent firewall may be a very good thing, since it presumably will "understand" what kinds of operations should or should not be permitted across it. An IP-level firewall will simply deal with "this connection is OK" or "this connection is not" --- which is insufficient if you're dealing with normal UNIX host security. After all, the best network security in the world isn't worth a plugged nickle if an outsider can talk to sendmail running in daemon mode as root on your system. :) So, while the application-dependent firewall is a pain in the neck, it's a more conservative approach, and there may well be good reasons for doing things that way. "tracking evolving applications and the intermediate implementation of these applications" also means leaving oneself open to being reamed by the often gaping holes in said applications. Some of us *can't* afford to do that. That's one of the problems with peer-to-peer networking utilities -- they're often terribly badly designed from a security perspective. That's why a number of folks in the firewalls biz (myself included) build our firewalls to block *ALL* network level traffic. IP applications can't be trusted to be reliable. Trusted host-to-host networking means your security is only as good as your host software -- i.e.; generally terribe, and nothing anyone would want to rely on to protect their network. Interjecting an irritating piece of carefully designed application gateway permits a degree of control and audit over an otherwise messy situation. Clearly what is needed are strong mechanisms for building host-to-host trust and VNPs. Side by side with them we need strong mechanisms for isolating and mediating access between the network perimeter and unstrusted networks. mjr. From ipsec-request@ans.net Tue Sep 6 22:50:01 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17734 (5.65c/IDA-1.4.4 for ); Tue, 6 Sep 1994 19:37:18 -0400 Received: by interlock.ans.net id AA17465 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 6 Sep 1994 19:25:05 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 6 Sep 1994 19:25:05 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 6 Sep 1994 19:25:05 -0400 Date: Tue, 6 Sep 94 22:50:01 GMT From: "William Allen Simpson" Message-Id: <3145.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Re: IPSEC requirements > From: Marcus J Ranum > I know I seem like I'm throwing a lot of wrenches into the > works, but I'd like to point out that there are lots of good reasons > for using restrictive application-dependent firewalls. That, in fact, > is why I was careful to open the discussion on trust boundaries in > IPSEC versus firewalls. > Look, this is clearly outside the scope of this group. Please stop bothering me with it. We are dealing with IP Security, not some other kind. We don't give a damn about "restrictive application-dependent firewalls", whatever the term du jour. (I'd call them Moats, or Keeps, or something else.) Please, can we discuss Ran's Authentication draft, and (if he would ever get it done), Perry's Encryption draft! Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Wed Sep 7 00:42:09 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16863 (5.65c/IDA-1.4.4 for ); Wed, 7 Sep 1994 00:42:09 -0400 Received: by interlock.ans.net id AA11385 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 7 Sep 1994 00:26:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 7 Sep 1994 00:26:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 7 Sep 1994 00:26:37 -0400 From: Masataka Ohta Return-Path: Message-Id: <9409070419.AA21044@necom830.cc.titech.ac.jp> Subject: Re: IPSEC requirements To: kent@BBN.COM (Steve Kent) Date: Wed, 7 Sep 94 13:19:03 JST Cc: ipsec@ans.net In-Reply-To: <9409061846.AA18857@necom830.cc.titech.ac.jp>; from "Steve Kent" at Sep 6, 94 2:48 pm X-Mailer: ELM [version 2.3 PL11] Steve; > I understand the difference between transport and application > layers, and I meant what I said about pure transport relaying > vs. application relaying (or proxy applications). Are you still cheating? I have no idea on what "inpure transport relaying" means. :-) > Looking at TCP/UDP port values is a layer violation for an IP > layer intermediate system, I think "IP layer" means "Internetwork layer". OK? > and one which I do not endorse. I endorse what people are using without difficulty and working quite efficiently. To do so, just say firewalls are operating at the transport layer. > I don't > think it causes problems for the reason you cite. I don't think transport layer firewalls causes problems. > If one makes > filtering (screening) decisions based on port fields, It is important to distinguish transport layer filtering and transport layer relaying. Transport layer filtering, only which is required for transport firewalls, is easy and does not need state tracking. Transport layer filtering does allow the selection of multiple routes and multiple firewalls, though thier filtering policy should be consistent each other which requires some protocol (I don't want to develop it) to propagate dynamic policy changes. > Also, the reliability of machines used as application layer firewalls > has usually been excellent, so the single piont of failure posed by a > firewall of this sort also may not be as bad as one might think. That's perfectly endorsable. If there are no alternative routes, it is possible to view the situation that incoming and outgoing transport layer connections, having the same port #, are terminated and relayed on the application layer firewall (src/dst address cheating used here is no layering cheating). Note that such a view is impossible if there are multile parallel firewalls. > What would be a terrible problem for an intermediate system is > trying to eumlate or track the TCP state information for each > connection through that system. That is where alternate routes can > kill you. So, in that light, looking at the port fields is cheating a > little, but looking at the sequence numbers and flags would be really > severe cheeting! When speaking on specification, cheating is cheating. I'm not interested in the degree of cheating. Looking at the port fields is no cheating at all, but looking at the sequence numbers and flags is cheating. > Applications behind a firewall do not automatically get login > info from a firewall, e.g., the target machine and the firewall may > require different user ID technology and thus be incompatible in terms > of relaying user I&A. That's a user interface issue on how can we design a firewall friendly applications. > Also, application layer firewalls often are set > up to control outgoing connections, where the user is behind the > firewall and the target application is outside. Here the target may > not be willing to trust user I&A info provided by some firewall > elsewhere, and that results in multiple logins. That's an issue of multipel firewalls and inessential. UNIX 'su' command is a firewall to the super user previledges and requires its own password. So, call it double login. But does that matter? > Finally, yes, we do agree that application-dependent firewalls > are a long term problem because they require tracking evolving > applications and the intermediate implementation of these applications > may loose functionality for the users. And, anyway, we need transport layer security to make all the TCP and most of UDP applications we are using today work securely without modification. Application firewalls may be developped. They may or may not make use of transport layer security/firewalls. But there are no reason not to have transport layer security/firewalls. Masataka Ohta From ipsec-request@ans.net Wed Sep 7 10:46:57 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA01580 (5.65c/IDA-1.4.4 for ); Wed, 7 Sep 1994 07:01:43 -0400 Received: by interlock.ans.net id AA10067 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 7 Sep 1994 06:47:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 7 Sep 1994 06:47:30 -0400 Message-Id: <199409071047.AA11087@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 7 Sep 1994 06:47:30 -0400 Organisation: University College London, CS Dept. Phone: +44 71 380 7777 ext 3706 or +44 71 387 7050 ext 3462 Fax: ++44 71 387 1397 To: ipsec@ans.net Subject: Multicast key distribution Date: Wed, 07 Sep 94 11:46:57 +0100 From: Tony Ballardie Can anyone give me pointers to papers on "multicast key distribution" and the problems associated with achieving multicast key distribution? From what I've gathered, there isn't much literature on the subject. Alternatively, can anyone provide a summary of the problems for me? Much appreciated. Tony From ipsec-request@ans.net Wed Sep 7 12:00:25 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17965 (5.65c/IDA-1.4.4 for ); Wed, 7 Sep 1994 08:20:24 -0400 Received: by interlock.ans.net id AA07627 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 7 Sep 1994 08:00:34 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 7 Sep 1994 08:00:34 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 7 Sep 1994 08:00:34 -0400 Date: Wed, 7 Sep 1994 08:00:25 -0400 From: jfjr@mbunix.mitre.org (Freedman) Message-Id: <199409071200.IAA14441@mbunix.mitre.org> Posted-From: The MITRE Corporation, Bedford, MA To: mjr@tis.com Cc: kent@BBN.COM, mohta@necom830.cc.titech.ac.jp, ipsec@ans.net In-Reply-To: Marcus J Ranum's message of Tue, 6 Sep 94 18:00:33 EDT <9409062200.AA04946@tis.com> Subject: IPSEC requirements > Clearly what is needed are strong mechanisms for building >host-to-host trust and VNPs. Side by side with them we need strong >mechanisms for isolating and mediating access between the network >perimeter and unstrusted networks. >mjr. At Toronto I believe Dave Moskowitz of Chrysler had a BOF wherein he attempted to address this in the context of IPv6. I think you are absolutely correct and these issues need to be dealt with but I am not sure that they should be dealt with in ipsec. Jerry Freedman,Jr From ipsec-request@ans.net Wed Sep 7 14:20:39 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17713 (5.65c/IDA-1.4.4 for ); Wed, 7 Sep 1994 10:41:14 -0400 Received: by interlock.ans.net id AA16767 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 7 Sep 1994 10:26:42 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 7 Sep 1994 10:26:42 -0400 Message-Id: <199409071426.AA32379@interlock.ans.net> To: Tony Ballardie Cc: ipsec@ans.net Subject: Re: Multicast key distribution In-Reply-To: Your message of Wed, 07 Sep 94 11:46:57 +0100. <199409071047.AA11087@interlock.ans.net> Date: Wed, 07 Sep 94 10:20:39 -0400 From: Steve Kent Tony, For an early look at the topic you might read "Security Requirements and Protocols for a Broadcast Scenario," S.T. Kent, IEEE Transactions on Communications 29(6), June 1981, pp 778-786. Despite the title, it does address multicast key distribution for symmetric and asymmetric cryptography. Steve From ipsec-request@ans.net Sat Sep 10 01:29:20 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA01706 (5.65c/IDA-1.4.4 for ); Fri, 9 Sep 1994 21:41:12 -0400 Received: by interlock.ans.net id AA16374 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 9 Sep 1994 21:28:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 9 Sep 1994 21:28:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 9 Sep 1994 21:28:37 -0400 Date: Fri, 9 Sep 1994 18:29:20 -0700 From: Phil Karn Message-Id: <199409100129.SAA25603@servo.qualcomm.com> To: mjr@tis.com Cc: watt@sware.com, bsimpson@morningstar.com, ipsec@ans.net In-Reply-To: <9409021738.AA10155@tis.com> (message from Marcus J Ranum on Fri, 2 Sep 94 13:38:23 EDT) Subject: Re: IPSEC requirements > Just give me IP encryption and some integrity checking >and that's enough. All the authentication stuff is useless and >belongs at the application layer. No way in hell am I gonna >trust your kernel on a remote machine to authenticate a user. >Not until we have high quality host-based security. If I'm that >gullible, I may as well just use rlogin and "privileged ports." If you don't trust a particular kernel, how can you trust an application that runs above it? The kernel is god in just about every OS I know. An evil kernel could easily poke into any application and suck out its secrets, such as crypto keys. Phil