From dan@isv.dec.com Wed Jun 16 06:56:47 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13969 (5.65c/IDA-1.4.4 for ); Wed, 16 Jun 1993 12:12:32 -0400 Received: from inet-gw-2.pa.dec.com by interlock.ans.net with SMTP id AA19739 (InterLock SMTP Gateway 1.1 for ); Wed, 16 Jun 1993 12:06:12 -0400 Received: by inet-gw-2.pa.dec.com; id AA21647; Tue, 15 Jun 93 23:57:02 -0700 Received: by vbormc.vbo.dec.com; id AA06450; Wed, 16 Jun 93 08:55:37 +0200 Received: by jerusalem (5.57/fma-100391); id AA15444; Wed, 16 Jun 93 09:56:48 +0300 Message-Id: <9306160656.AA15444@jerusalem> To: ipsec@ans.net Cc: dan@isv.dec.com Subject: Amsterdam IETF Date: Wed, 16 Jun 93 09:56:47 +0300 From: dan@isv.dec.com X-Mts: smtp The most recent agenda for the Amsterdam IETF does not include a session for this group. Is this group meeting in Amsterdam? Dan From gvaudre@CNRI.Reston.VA.US Thu Jun 17 21:23:52 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15932 (5.65c/IDA-1.4.4 for ); Thu, 17 Jun 1993 17:28:52 -0400 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by interlock.ans.net with SMTP id AA11396 (InterLock SMTP Gateway 1.1 for ); Thu, 17 Jun 1993 17:26:53 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa15855; 17 Jun 93 17:23 EDT To: IETF-Announce: ; Cc: ipsec@ans.net Subject: Internet Protocol Security Protocol (ipsec) Date: Thu, 17 Jun 93 17:23:52 -0400 From: Greg Vaudreuil Message-Id: <9306171723.aa15855@IETF.CNRI.Reston.VA.US> A new working group has been formed in the Security Area of the IETF. Please contact the working group chair or the Security area director for more information. Greg Vaudreuil IESG Secretary Internet Protocol Security Protocol (ipsec) ------------------------------------------- Charter Chair(s): Al Hoover Paul Lambert Security Area Director(s) Stephen Crocker Mailing lists: General Discussion:ipsec@ans.net To Subscribe: ipsec-request@ans.net Archive: ftp.ans.net:~/pub/archive/ipsec Description of Working Group: Rapid advances in communication technology have accentuated the need for security in the Internet. The IP Security Protocol Working Group (IPSEC) will develop mechanisms to protect client protocols of IP. A security protocol in the network layer will be developed to provide cryptographic security services that will flexibly support combinations of authentication, integrity, access control, and confidentiality. The protocol formats for the IP Security Protocol (IPSP) will be independent of the cryptographic algorithm. The preliminary goals will specifically pursue host-to-host security followed by subnet-to-subnet and host-to-subnet topologies. Protocol and cryptographic techniques will also be developed to support the key management requirements of the network layer security. The key management will be specified as an application layer protocol that is independent of the lower layer security protocol. The protocol will initially support public key based techniques. Flexibility in the protocol will allow eventual support of Key Distribution Center (KDC - such as Kerberos) and manual distribution approaches. Goals and Milestones: June 93 Post as an Internet-Draft the IP Security Protocol. Jul 93 Post as an Interenet-Draft the specification for Internet Key Management. Nov 93 Report on Pilot Implementation of the IP Security Protocol. Update Protocol as needed. Mar 94 Report on Pilot implementation of the Internet Key Management Protocol. Update Internet-Draft as needed. Jul 94 Submit the IP Security Protocol to the IESG for consideration as a Proposed Standard. Jul 94 Submit the Key Management Protocol to the IESG for consideration as a Proposed Standard. From ldl@ans.net Fri Jun 18 05:19:53 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14266 (5.65c/IDA-1.4.4 for ); Fri, 18 Jun 1993 09:21:36 -0400 Received: by interlock.ans.net id AA18873 (InterLock SMTP Gateway 1.1 for ipsec@ans.net); Fri, 18 Jun 1993 09:19:22 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 18 Jun 1993 09:19:22 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 18 Jun 1993 09:19:22 -0400 Date: Fri, 18 Jun 93 9:19:53 EDT From: Linda Leibengood To: ipsec@ans.net Subject: ipsec mailing list Cc: ipsec-request@ans.net Message-Id: Yesterday's announcement of the formation of the ipsec working group has created a bit of confusion about the mailing list. The existing ipsec list will continue to be used. If you've been receiving ipsec mail, you will continue to do so. The list originally grew out of a BOF session at the Boston IETF. ipsec was recently chartered and made an official working group. Yesterday's announcement was just an official notification of this. Linda Leibengood ANS Postmaster From smart@mel.dit.csiro.au Sun Jun 27 23:55:57 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA02512 (5.65c/IDA-1.4.4 for ); Sun, 27 Jun 1993 20:06:05 -0400 Received: from shark.mel.dit.CSIRO.AU by interlock.ans.net with SMTP id AA16587 (InterLock SMTP Gateway 1.1 for ); Sun, 27 Jun 1993 19:54:08 -0400 Received: from squid.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA21691 (5.65c/IDA-1.4.4/DIT-1.3 for ); Mon, 28 Jun 1993 09:56:17 +1000 Received: by squid.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA29395; Mon, 28 Jun 93 09:55:58 EST Message-Id: <9306272355.AA29395@squid.mel.dit.CSIRO.AU> To: ipsec@ans.net Subject: Re: Internet Protocol Security Protocol (ipsec) In-Reply-To: Your message of "Thu, 17 Jun 93 17:23:52 -0400." <9306171723.aa15855@IETF.CNRI.Reston.VA.US> Date: Mon, 28 Jun 93 09:55:57 +1000 From: Bob Smart >The key management will be specified as an application layer protocol >that is independent of the lower layer security protocol. I can't help reading this to mean a new protocol. It is hard to believe we wouldn't want to use existing directory services such as the DNS. Actually a pet project of mine is to define X.509 using the DNS instead of X.500, but in such a way that you get exactly the same information whether you go through the DNS or X.500. This is not hard. > June 93 Post as an Internet-Draft the IP Security Protocol. Is this the Karn-JI proposal? Are we going to see outlines of these documents before they come out as IDs? That's the way it was done in the MIME WG and it seemed to be a useful step. Well I have a comment which may or may not be relevant since I don't have a clue what is planned, but here it is: I recently added X.509-based encryption to Telnet. It used DES in CBC mode to encrypt the session. On data across a high speed link (e.g. from localhost) there was a noticable added jerkiness to output. The problem is that the feedback mechanism in CBC mode means that you are forced to do the DES calculations at the last moment. This problem can be overcome if we use a mechanism with no feedback. Both sides generate the same pseudo-random number sequence and each 8-byte block of that sequence is DES encrypted (so the pseudo-random number sequence itself doesn't have to be cryptographically strong). This gives a sequence of bytes that each side XORs against the input or output. The nice property of this is that both sides can generate a circular buffer of future values that will be required using as much buffer space as they can afford. The DES encryption can be done during the end-system's idle time and not at the crucial moment in time when the incoming or outgoing data has to be processed. This seems likely to be even more important for a network layer encryption scheme than for telnet. Bob Smart Robert.Smart@mel.dit.csiro.au Open Systems Program CSIRO Division of Information Technology phone: +61 3 282 2625 723 Swanston St, Carlton VIC 3053, Australia fax: +61 3 282 2600 From Russ_Housley.McLean_CSD@xerox.com Sun Jun 27 22:33:31 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA02475 (5.65c/IDA-1.4.4 for ); Mon, 28 Jun 1993 09:26:59 -0400 Received: from alpha.Xerox.COM by interlock.ans.net with SMTP id AA13267 (InterLock SMTP Gateway 1.1 for ); Mon, 28 Jun 1993 09:17:04 -0400 Received: from Mail3_McLean.McLean_CSD.Xerox.xns by alpha.xerox.com via XNS id <11573>; Mon, 28 Jun 1993 05:34:06 PDT X-Ns-Transport-Id: 0000AA00CAB3AC422FEE Date: Mon, 28 Jun 1993 05:33:31 PDT Sender: Russ_Housley.McLean_CSD@xerox.com From: Housley.McLean_CSD@xerox.com Subject: Re: Internet Protocol Security Protocol (ipsec) In-Reply-To: <9306272355.AA29395@squid.mel.dit.CSIRO.AU> To: smart@mel.dit.csiro.au Cc: ipsec@ans.net Reply-To: ipsec@ans.net Message-Id: <"28-Jun-93 8:33:22".*.Russ_Housley.McLean_CSD@Xerox.com> Bob: >>The key management will be specified as an application layer protocol >>that is independent of the lower layer security protocol. > >I can't help reading this to mean a new protocol. It is hard to believe >we wouldn't want to use existing directory services such as the DNS. >Actually a pet project of mine is to define X.509 using the DNS >instead of X.500, but in such a way that you get exactly the same >information whether you go through the DNS or X.500. This is not hard. Yes, a new protocol is needed. Even if X.509 certificates are available in the DNS dor Directory, a new protocol is needed. The IEEE 802.10 Working Group is currently spending alot of time on this topic. When certificate-based key management is used, there are four stages in key management for a lower layer security protocol such as IPSP. First, exchange certificates. This could be eliminated (or made optional) if every entity in the network has a certificate posted in a globally available DNS or Directory. Some algorithms for the generation of keying material require some parameters that go along with the certificate. Different parameters are used each time a key is generated, therefore the parameters cannot be signed by the CA and made part of the certificate. Thus, depending on the key generation algorithm, even if certificates are universally available, then some information must be exchanged in this step. In the work being done in IEEE 802.10, the two peers also exchange names for the key that is generated at this stage. Second, negotiate attributes. These attributes determine how the lower layer security protocol (IPSP in our case) will use the key or keys. Will the key(s) provide confidentiality, integrity, or both? Is a particular security label associated with the key(s)? Perhaps the host implements more than one lower layer security protocol. If so, the attribute negotiation will determine which security protocol will be used with this key. In the work being done in IEEE 802.10, the attribute negotiation is protected using the key(s) generated in the first stage. Third, use the key. The lower layer security protocol (IPSP in our case) uses the key to protect traffic (IP datagrams in our case). Fourth, delete the key. One side tells the other that it is finished with the key and it is deleting it. One side cannot be sure that the other will also delete the key, butt can be assured that no more traffic will be exchanged by the two hosts using that key. In conclusion, posting X.509 certificates in the DNS and/or Directory does not address all of the key management issues. Russ From kent@BBN.COM Mon Jun 28 14:31:06 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04883 (5.65c/IDA-1.4.4 for ); Mon, 28 Jun 1993 17:23:32 -0400 Received: from CCV1.BBN.COM by interlock.ans.net with SMTP id AA19681 (InterLock SMTP Gateway 1.1 for ); Mon, 28 Jun 1993 17:20:07 -0400 Message-Id: <199306282120.AA19681@interlock.ans.net> To: Bob Smart Cc: ipsec@ans.net, kent@BBN.COM Subject: Re: Internet Protocol Security Protocol (ipsec) In-Reply-To: Your message of Mon, 28 Jun 93 09:55:57 +1000. <9306272355.AA29395@squid.mel.dit.CSIRO.AU> Date: Mon, 28 Jun 93 10:31:06 -0400 From: Steve Kent Bob, There is a DES mode defined (OFB) for providing the precomputation capability you describe. It uses the DES in a feedback arrangement to generate a pseudo-random sequence from a random or pesdue-random seed value, but it fails to provide unpredictable error propogation, an important feature in support of detecting modification (as does your scheme). I'd suggest you adopt that scheme if you want a precomputation capability, but it would be less desirable for general use in the IPSEC context because of this defficiency. Steve From smart@mel.dit.csiro.au Mon Jun 28 23:44:45 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16657 (5.65c/IDA-1.4.4 for ); Mon, 28 Jun 1993 19:46:54 -0400 Received: from shark.mel.dit.CSIRO.AU by interlock.ans.net with SMTP id AA14485 (InterLock SMTP Gateway 1.1 for ); Mon, 28 Jun 1993 19:42:57 -0400 Received: from squid.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA08599 (5.65c/IDA-1.4.4/DIT-1.3 for ); Tue, 29 Jun 1993 09:45:06 +1000 Received: by squid.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA04590; Tue, 29 Jun 93 09:44:46 EST Message-Id: <9306282344.AA04590@squid.mel.dit.CSIRO.AU> To: ipsec@ans.net Subject: Re: Internet Protocol Security Protocol (ipsec) In-Reply-To: Your message of "Mon, 28 Jun 93 10:31:06 -0400." <199306282120.AA19681@interlock.ans.net> Date: Tue, 29 Jun 93 09:44:45 +1000 From: Bob Smart >pesdue-random seed value, but it fails to provide unpredictable error >propogation, an important feature in support of detecting modification If everyone else on this list is familiar with the phrase "unpredictable error propogation" then obviously I'm a bit behind. However the only way to learn on an IETF list is to make a fool of yourself. It's worked for me in the past! Let me guess. Unpredictable error propogation means that if someone changes a bit in a packet then the decrypted stream will not just be temporarily wrong but will stay completely wrong from then on. This increases the chance that the underlying process will die rather than do something subtly wrong. As a data integrity check this seems incredibly crude. Wouldn't it be better to add separate integrity checking as well? Also doesn't it put you at risk of having your network layer drop out after a hardware glitch? The upper layer protocols might have recovered happily from the glitch but you don't give them a chance. Alternatively I'm sure we can devise a system that allows substantial precomputation but still has feedback at the last minute that doesn't require a lot of overhead. I still think precomputation is essential for high speed encryption/decryption, which is in turn essential for network layer encryption. Bob Smart From smb@research.att.com Mon Jun 28 16:21:45 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12808 (5.65c/IDA-1.4.4 for ); Mon, 28 Jun 1993 20:27:27 -0400 Received: from research.att.com by interlock.ans.net with SMTP id AA12559 (InterLock SMTP Gateway 1.1 for ); Mon, 28 Jun 1993 20:22:14 -0400 Message-Id: <199306290022.AA12559@interlock.ans.net> From: smb@research.att.com Received: by gryphon; Mon Jun 28 20:21:46 EDT 1993 To: Bob Smart Cc: ipsec@ans.net Subject: Re: Internet Protocol Security Protocol (ipsec) Date: Mon, 28 Jun 93 20:21:45 EDT >pesdue-random seed value, but it fails to provide unpredictable error >propogation, an important feature in support of detecting modificatio n If everyone else on this list is familiar with the phrase "unpredictab le error propogation" then obviously I'm a bit behind. However the only way to learn on an IETF list is to make a fool of yourself. It's worke d for me in the past! Let me guess. Unpredictable error propogation means that if someone changes a bit in a packet then the decrypted stream will not just be temporarily wrong but will stay completely wrong from then on. This increases the chance that the underlying process will die rather than do something subtly wrong. No, that's not what it means. The problem with OFB mode is that the attacker can control what the changes are in the decrypted plaintext. With CBC, the enemy can scramble certain fields, but without any ability to dictate the final contents. Let me be more precise. OFB works as follows: DES[n] = E(K,DES[n-1]) C[n] = P[n] XOR DES[n] That is, DES is run in a feedback loop, always in encrypt mode. A block of ciphertext is formed by XORing a block of this DES output with a block of plaintext. Decryption is done by generating the same DES output stream -- still running DES in encrypt mode -- and XORing it with the ciphertext. Clearly, if I invert bit 17 of the ciphertext, I've inverted bit 17 of the decrypted plaintext. Similarly, if the enemy knows that a particular packets is from host 12.34.56.78, he or should could construct the appropriate XOR pattern to make it appear as if the packet were from 87.65.43.21. Yes, in theory it's possible to add a checksum. But OFB mode is generally employed when encrypting asynchronous streams, which makes checksumming a bit difficult. CBC mode is different. Encryption is done by C[n] = E(K, P[n] XOR C[n-1]) and decryption is P[n] = D(K, C[n]) XOR C[n-1] An enemy who garbled block C[n-1] could, in fact, introduce a predictable error into the decryption of P[n], but only at the expense of totally garbling P[n-1]. Let me recommend the discussion of encryption modes in @book{daviesprice, author = {Donald W. Davies and Wyn L. Price}, edition = {second}, publisher = {John Wiley \& Sons}, title = {Security for Computer Networks}, year = {1989} } It discusses all of this, and more. I'll oversimplify by saying that for general use, CBC is best for block encryption, and OFB is best for stream encryption. --Steve Bellovin From shirey@mitre.org Tue Jun 29 15:43:02 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04165 (5.65c/IDA-1.4.4 for ); Tue, 29 Jun 1993 10:43:16 -0400 Received: from mwunix.mitre.org by interlock.ans.net with SMTP id AA07497 (InterLock SMTP Gateway 1.1 for ); Tue, 29 Jun 1993 10:39:24 -0400 Return-Path: Received: from smiley.mitre.org.sit (smiley.mitre.org) by mwunix.mitre.org (5.65c/SMI-2.2) id AA17864; Tue, 29 Jun 1993 10:41:19 -0400 Received: from [128.29.140.100] (shirey-mac.mitre.org) by smiley.mitre.org.sit (4.1/SMI-4.1) id AA22593; Tue, 29 Jun 93 10:40:05 EDT Message-Id: <9306291440.AA22593@smiley.mitre.org.sit> Date: Tue, 29 Jun 1993 10:43:02 -0500 To: Bob Smart , smb@research.att.com From: shirey@mitre.org (Robert W. Shirey) X-Sender: shirey@128.29.140.20 Subject: Re: Internet Protocol Security Protocol (ipsec) Cc: ipsec@ans.net At 9:44 AM 6/29/93 +1000, Bob Smart wrote: ... >If everyone else on this list is familiar with the phrase "unpredictable >error propogation" then obviously I'm a bit behind ... >Let me guess. Unpredictable error propogation means that if someone >changes a bit in a packet then the decrypted stream will not just >be temporarily wrong but will stay completely wrong from then on. >This increases the chance that the underlying process will die >rather than do something subtly wrong. >Bob Smart Bob, Steve Bellovin has already replied to you about this, but I thought a little more background might be useful to you or other people on the list: DES specifies the Data Encryption Algorithm (DEA). DEA uses a 64-bit key, of which 56 bits are independently chosen and 8 are parity bits, to encipher or decipher a 64-bit block, mapping it into another 64-bit block. There are four standard methods, or *modes*, for incorporating DES in a cryptographic system; two are block methods and two are stream methods [FIPS81]. In *block encipherment* methods, the input to the algorithm is the cleartext block to be enciphered, and the output is a ciphertext block. *Stream encipherment* methods use the algorithm to generate a stream of pseudo-random bits, and then use the exclusive-OR operation to combine that stream with the cleartext input stream, yielding the ciphertext output stream. The DES block modes are Electronic Codebook (ECB) mode, which separately enciphers each cleartext block as specified in DEA, and Cipher Block Chaining (CBC) mode, which exclusive-ORs each ciphertext output block with the next cleartext block to form the next input block. ECB mode is not recommended for use in enciphering user data because, for example, data patterns aligned on 8-byte boundaries are easily discerned in this mode. Instead, ECB mode should be used only for encipherment of keys or IVs. The chaining in CBC mode avoids block alignment problem, so that CBC is suitable for direct encipherment of user data. Both modes provide unpredictable error extension within an 8-byte block. CBC provides some further (but predictable) error propogation, because the chaining of blocks causes a ciphertext bit change to be extended over additional cleartext bits when the chained block is deciphered. This feature can help protect against active wiretapping. The DES stream modes are Cipher Feedback (CFB) mode, which also uses chaining and causes unpredictable error extension, and Output Feedback (OFB) mode, which does not. [FIPS46] U.S. Department of Commerce, *Data Encipherment Standard*, FIPS [Federal Information Processing Standards Publication] 46, 15 January 1977. [FIPS81] -----, *DES Modes of Operation*, FIPS 81, 2 December 1980. From Paul_Lambert@poncho.phx.sectel.mot.com Tue Jun 29 02:59:49 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20717 (5.65c/IDA-1.4.4 for ); Tue, 29 Jun 1993 13:05:28 -0400 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA09818 (InterLock SMTP Gateway 1.1 for ); Tue, 29 Jun 1993 12:59:00 -0400 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.14 for ) id AA04470; Tue, 29 Jun 1993 12:00:54 -0500 Received: from phx.sectel.mot.com (rambo.phx.sectel.mot.com) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.14 for ) id AA20673; Tue, 29 Jun 1993 12:00:53 -0500 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA17713; Tue, 29 Jun 93 10:00:22 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA39359; Tue, 29 Jun 1993 10:03:27 MST Message-Id: <00112.2824193007.39359@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Tue, 29 Jun 1993 9:59:49 MST Subject: IPSEC in Amsterdam IPSEC in Amsterdam The IP Security IPSEC working group will be meeting in Amsterdam on Tuesday 9:00 to 12:00. I will post a preliminary agenda tommorrow. We will be working on both the IPSP and key management at the meeting. Please send me a note if you would like to give a presentation at the meeting or have comments on the agenda. Paul From Paul_Lambert@poncho.phx.sectel.mot.com Tue Jun 29 03:25:32 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20609 (5.65c/IDA-1.4.4 for ); Tue, 29 Jun 1993 13:38:41 -0400 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA05393 (InterLock SMTP Gateway 1.1 for ); Tue, 29 Jun 1993 13:23:46 -0400 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.14 for ) id AA05920; Tue, 29 Jun 1993 12:25:41 -0500 Received: from phx.sectel.mot.com (rambo.phx.sectel.mot.com) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.14 for ) id AA22613; Tue, 29 Jun 1993 12:25:39 -0500 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA17904; Tue, 29 Jun 93 10:25:08 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA39366; Tue, 29 Jun 1993 10:26:45 MST Message-Id: <00112.2824194405.39366@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Tue, 29 Jun 1993 10:25:32 MST Subject: Reorganized NLSP Reorganized NLSP I have obtained a copy of: Title: Reorganized NLSP Author: Betty Mackman Date: March 1993 It looks better than the current ISO DIS 11577 specification, but still has the connection-oriented baggage that we do not need in IPSP. For now, all I have is a paper version of the document. IUll send paper copies to anyone that wants one, all you need to do is send your request to: Paul_Lambert@email.mot.com Be sure to include your postal (aka snail-mail) address. Also, does anyone out there know how I can reach Betty Machman? Paul From kent@BBN.COM Wed Jun 30 14:29:28 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18506 (5.65c/IDA-1.4.4 for ); Wed, 30 Jun 1993 10:31:37 -0400 Received: from CCV1.BBN.COM by interlock.ans.net with SMTP id AA13857 (InterLock SMTP Gateway 1.1 for ); Wed, 30 Jun 1993 10:27:44 -0400 Message-Id: <199306301427.AA13857@interlock.ans.net> To: Bob Smart Cc: ipsec@ans.net Subject: Re: Internet Protocol Security Protocol (ipsec) In-Reply-To: Your message of Tue, 29 Jun 93 09:44:45 +1000. <9306282344.AA04590@squid.mel.dit.CSIRO.AU> Date: Wed, 30 Jun 93 10:29:28 -0400 From: Steve Kent Bob, Sorry I used a term not everyone is familiar with. Unpredictable error propogation implies that a change to the ciphertext manifests itself as a change to some number of plaintext bits, where the precise number and location of the modified plaintext bits is not predictable by the attacker. It does not imply that all subsequenc bits in a message, data stream , etc. are trashed (to use a technical term). For example, using the DES in CBC mode provide unpredictable error propogation that is bounded by the 64-bit block size of the underlying cipher codebook. A change to a bit of ciphertext results in an average of 32 bits being changed in the underlying plaintext. The region in which these 32 bits will be changed is precictable, but the exact bits that are changes is not. This makes it very hard for an attacker to modify ciphertext in a fashion that is not detectable by a the reciver of the plaintext, assuming good choices of error detection codes. Hope this helps, Steve