Received: from relay.hq.tis.com by neptune.TIS.COM id aa21754; 2 Oct 96 14:35 EDT Received: by relay.hq.tis.com; id OAA03120; Wed, 2 Oct 1996 14:38:16 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma003106; Wed, 2 Oct 96 14:37:53 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA25390; Wed, 2 Oct 96 14:39:54 EDT Received: by relay.hq.tis.com; id OAA03095; Wed, 2 Oct 1996 14:37:45 -0400 Received: from hq.cisco.com(161.44.72.2) by relay.tis.com via smap (V3.1.1) id xma003087; Wed, 2 Oct 96 14:37:37 -0400 Received: from 161.44.128.127 ([161.44.128.127]) by HQ.CISCO.COM via INTERNET ; Wed, 2 Oct 1996 11:39:51 PDT Date: Wed, 2 Oct 1996 11:38:35 From: Rob Adams Message-Id: <19961002113835adams@161.44.128.127> To: ipsec@TIS.COM Subject: Proposed changes to the DES-CBC, HMAC and Replay Prevetion Security Transform. X-Mailer: Pronto Mail [tgv Ver 2.03] Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk The following are changes I'd like to make to the above document. I've posted comments about the changes to the list and didn't get a lot of comments. I've made the following changes: 1) added a new transform specified by a different IANA number for packets including an IV. 2) made the replay window size NON-negotiated. It is left to the implementation. I did not change the padding to the start of the packet because of the hardware assist thoughts. Comments please.. -Rob The text follows: |2. Packet Format | | DES-CBC/HMAC/Replay has two supported transforms, each with its own | packet format. The first packet format for IPSEC_ESP_DESCBCHR is as | follows: | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- | | Security Parameters Index (SPI) | ^ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Replay Prevention Field (count) | | ^ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | ~ Payload Data ~ | | | | |HMAC | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DES | | | Padding (0-255 bytes) | | CBC | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Pad Length | Payload Type | v | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- | | | | | | ~ HMAC digest ~ | | | | v | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- | | The initialization vector for this transform is discussed in section | 2.2. | | The other transform, IPSEC_ESP_DESCBCHR_IV, includes the initialization | vector in the packet. This transform is useful for implementations | using hardware assisted encryption which generates its own IV. | Hughes September 14, 1996 [Page 3] INTERNET DRAFT September 1996 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- | | Security Parameters Index (SPI) | ^ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | + Initialization Vector + | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | --- | | Replay Prevention Field (count) | | ^ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | ~ Payload Data ~ | | | | |HMAC | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DES | | | Padding (0-255 bytes) | | CBC | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Pad Length | Payload Type | v | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- | | | | | | ~ HMAC digest ~ | | | | v | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- | 2.2. Initialization Vector The use of an explicit Initialization Vector MAY be negotiated. The | purpose of this transform is to support devices that automatically gen- | erate IVs and can not operate using a constant IV_key_. | used in place of the constant IV_key_ described later in this docu- ment. 2.3. Replay Prevention | Replay window size is an implementation detail. Appendix A has actual code that implement a 32 packet replay window and a test routine. The purpose of this routine is to show how it could be implemented. Received: from relay.hq.tis.com by neptune.TIS.COM id aa24366; 2 Oct 96 16:39 EDT Received: by relay.hq.tis.com; id QAA07022; Wed, 2 Oct 1996 16:43:27 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma007002; Wed, 2 Oct 96 16:43:05 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA05727; Wed, 2 Oct 96 16:45:06 EDT Received: by relay.hq.tis.com; id QAA06992; Wed, 2 Oct 1996 16:42:57 -0400 Received: from hq.cisco.com(161.44.72.2) by relay.tis.com via smap (V3.1.1) id xma006987; Wed, 2 Oct 96 16:42:53 -0400 Received: from 161.44.128.127 ([161.44.128.127]) by HQ.CISCO.COM via INTERNET ; Wed, 2 Oct 1996 13:45:06 PDT Date: Wed, 2 Oct 1996 13:43:49 From: Rob Adams Message-Id: <19961002134349adams@161.44.128.127> To: perry@piermont.com Subject: Re: Proposed changes to the DES-CBC, HMAC and Replay Prevetion Security Transform. Cc: ipsec@TIS.COM X-Mailer: Pronto Mail [tgv Ver 2.03] Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk I think you might have missed the point if I understand your earlier postings. If I'm correct, you thought that I was suggesting that no IV be used for one and an IV be used only if it was included in the packet. I'm not suggesting that at all. The current transform says you use an IV derived from negotiated keying material if one isn't present. That would be the same. I only would like to see two separate transforms, one where the derived IV is used, and one where the included IV is used. Your point about the replay window was lost on me. I never suggested an infinite replay window, only that I saw no advantage in supporting the negotiation of replay windows. If my implementation has a 32 bit replay window and the peer I'm communicating with has no window and requires packets in order, what do I care? Why should that be negotiated? I had one person say that there was added vulnerability in using a window versus requiring packets in order and that negotiating would allow sites to not allow this vulnerability. I don't see the vulnerability. If my implementation is guaranteed to drop packets it has seen before, I can't fathom the vulnerability. If I'm missing something, I'm perfectly willing to drop my request. I'm simply saying that replay window size is an implementation detail, the size you choose is up to you. -Rob > >Rob Adams writes: >> The following are changes I'd like to make to the above document. I've >> posted comments about the changes to the list and didn't get a lot of >> comments. >> >> I've made the following changes: >> 1) added a new transform specified by a different IANA number for >> packets including an IV. >> 2) made the replay window size NON-negotiated. It is left to the >> implementation. > >I do not particularly like either of these proposals, for reasons I >have already stated in previous messages. > >Perry > Received: from relay.hq.tis.com by neptune.TIS.COM id aa25518; 2 Oct 96 17:44 EDT Received: by relay.hq.tis.com; id RAA08744; Wed, 2 Oct 1996 17:48:27 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma008740; Wed, 2 Oct 96 17:47:59 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA11599; Wed, 2 Oct 96 17:50:05 EDT Received: by relay.hq.tis.com; id RAA08734; Wed, 2 Oct 1996 17:47:57 -0400 Received: from hq.cisco.com(161.44.72.2) by relay.tis.com via smap (V3.1.1) id xma008729; Wed, 2 Oct 96 17:47:39 -0400 Received: from 161.44.128.127 ([161.44.128.127]) by HQ.CISCO.COM via INTERNET ; Wed, 2 Oct 1996 14:49:53 PDT Date: Wed, 2 Oct 1996 14:48:37 From: Rob Adams Message-Id: <19961002144837adams@161.44.128.127> To: perry@piermont.com Subject: Re: Proposed changes to the DES-CBC, HMAC and Replay Prevetion Security Transform. Cc: ipsec@TIS.COM X-Mailer: Pronto Mail [tgv Ver 2.03] Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk > >So that both sides will know what is in use? > I don't care what the other side is using.. So why negotiate? > >Denial of service attacks. > Explain this. What denial of service attacks exist which depend on the size of the replay window..? > >You have to save information on every packet you've already seen for >which the bottom of the window hasn't been passed. This leaves you >open to having attackers force you to consume memory and CPU if you >have a large window. > You store a bit in a mask versus a longword value. The replay counter is above your window, slide the window. Replay counter is below, drop the packet. If it is in your window, set bit if not set, else drop if set. If you have a window of 1, test to see if the counter is saved++, if so, increment saved, else drop. In BOTH cases, you must decrypt the packet and sign it before you can really validate the replay window. Both require the same CPU and memory to decrypt/sign the packet. A window requires an extra longword to save the count of the bottom of the window and 30 more lines of code. The only possible attack I can see is if your keys are had and an attacker can impersonate you in everyway, the attacker has 1 chance in 2^32 to get through your replay test for a window size of 1, versus 32 chances in 2^32 for a 32 bit window. In any case, if an attacker has your keys, they can rip your packets open and see what sequence your at anyway. Received: from relay.hq.tis.com by neptune.TIS.COM id aa23781; 2 Oct 96 16:12 EDT Received: by relay.hq.tis.com; id QAA06184; Wed, 2 Oct 1996 16:16:24 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma006177; Wed, 2 Oct 96 16:15:55 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA01359; Wed, 2 Oct 96 16:18:02 EDT Received: by relay.hq.tis.com; id QAA06174; Wed, 2 Oct 1996 16:15:54 -0400 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap id xma006159; Wed, 2 Oct 96 16:15:28 -0400 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.5/8.6.12) with SMTP id QAA07396; Wed, 2 Oct 1996 16:17:25 -0400 Message-ID: <9610030742.aa02996@neptune.TIS.COM> (EDT) Message-Id: <199610022017.QAA07396@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Rob Adams Cc: ipsec@TIS.COM Subject: Re: Proposed changes to the DES-CBC, HMAC and Replay Prevetion Security Transform. In-Reply-To: Your message of "Wed, 02 Oct 1996 11:38:35." <19961002113835adams@161.44.128.127> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 02 Oct 1996 16:17:24 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Rob Adams writes: > The following are changes I'd like to make to the above document. I've > posted comments about the changes to the list and didn't get a lot of > comments. > > I've made the following changes: > 1) added a new transform specified by a different IANA number for > packets including an IV. > 2) made the replay window size NON-negotiated. It is left to the > implementation. I do not particularly like either of these proposals, for reasons I have already stated in previous messages. Perry Received: from relay.hq.tis.com by neptune.TIS.COM id aa24096; 2 Oct 96 16:29 EDT Received: by relay.hq.tis.com; id QAA06643; Wed, 2 Oct 1996 16:32:55 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma006622; Wed, 2 Oct 96 16:32:26 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA02980; Wed, 2 Oct 96 16:34:33 EDT Received: by relay.hq.tis.com; id QAA06612; Wed, 2 Oct 1996 16:32:25 -0400 Received: from cornpuffs.cisco.com(171.69.1.219) by relay.tis.com via smap id xma006604; Wed, 2 Oct 96 16:32:13 -0400 Received: (rja@localhost) by cornpuffs.cisco.com (8.6.12/8.6.5) id NAA03679; Wed, 2 Oct 1996 13:34:27 -0700 Date: Wed, 2 Oct 1996 13:34:27 -0700 From: Ran Atkinson Message-Id: <199610022034.NAA03679@cornpuffs.cisco.com> To: adams@cisco.com Subject: Re: Proposed changes to the DES-CBC, HMAC and Replay Prevetion Security Transform. In-Reply-To: <19961002113835adams@161.44.128.127> Organization: cisco Systems Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk [co-chair hat off; just personal opinions, based in part on experience with the NRL codebase] In article <19961002113835adams@161.44.128.127> Rob Adams wrote: >The following are changes I'd like to make to the above document. I've >posted comments about the changes to the list and didn't get a lot of >comments. > >I've made the following changes: > 1) added a new transform specified by a different IANA number for > packets including an IV. I do not see any real advantage to this. IPsec Security Associations already have a fair number of attributes defined (see RFC-1825). The presence or absence of a separate IV field is just an IPsec SA attribute, nothing more. There is NOT significant extra code here, just an if/else branch based on the value of a particular element of the IPsec SA. > 2) made the replay window size NON-negotiated. It is left to the > implementation. I find implementation-defined replay window sizes strongly undesirable. Different IP sessions have different security requirements. The size of the replay window relates directly to the quality of the provided security. The ability to implement different security properties for different sessions is an important feature of IPsec. The replay window size should be negotiated. For example, a major auto manufacturer might want to have a small replay protection window for traffic transiting certain countries for increased security at the cost of higher chance of losing some out-of-order packets while having a larger replay protection window for less security but less chance of lost out-of-order packets for traffic that never leaves the domestic US auto industry community. Ran rja@cisco.com Received: from relay.hq.tis.com by neptune.TIS.COM id aa24551; 2 Oct 96 16:45 EDT Received: by relay.hq.tis.com; id QAA07325; Wed, 2 Oct 1996 16:49:27 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma007287; Wed, 2 Oct 96 16:48:58 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA07394; Wed, 2 Oct 96 16:51:04 EDT Received: by relay.hq.tis.com; id QAA07284; Wed, 2 Oct 1996 16:48:57 -0400 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap id xma007273; Wed, 2 Oct 96 16:48:47 -0400 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.5/8.6.12) with SMTP id QAA07632; Wed, 2 Oct 1996 16:51:02 -0400 Message-ID: <9610030743.aa03075@neptune.TIS.COM> (EDT) Message-Id: <199610022051.QAA07632@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Rob Adams Cc: ipsec@TIS.COM Subject: Re: Proposed changes to the DES-CBC, HMAC and Replay Prevetion Security Transform. In-Reply-To: Your message of "Wed, 02 Oct 1996 13:43:49." <19961002134349adams@161.44.128.127> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 02 Oct 1996 16:50:58 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Rob Adams writes: > Your point about the replay window was lost on me. I never suggested an > infinite replay window, only that I saw no advantage in supporting the > negotiation of replay windows. If my implementation has a 32 bit replay > window and the peer I'm communicating with has no window and requires > packets in order, what do I care? Why should that be negotiated? So that both sides will know what is in use? > I had one person say that there was added vulnerability in using a > window versus requiring packets in order and that negotiating would > allow sites to not allow this vulnerability. I don't see the > vulnerability. Denial of service attacks. > If my implementation is guaranteed to drop packets it has seen > before, I can't fathom the vulnerability. You have to save information on every packet you've already seen for which the bottom of the window hasn't been passed. This leaves you open to having attackers force you to consume memory and CPU if you have a large window. Perry Date: Wed, 02 Oct 96 17:05:26 EST From: "Whelan, Bill" Message-Id: <9609038443.AA844353349@netx.nei.com> Cc: ipsec@TIS.COM Subject: CBC vs. ECB Sender: ipsec-approval@neptune.tis.com Precedence: bulk Without an IV, what you are running is the ECB mode of these algorithms which is highly insecure. I do not think that should be encouraged. So CBC is more secure than ECB! I've been accepting statements such as this as gospel for a while, but now I'm not so sure. Please excuse my ignorance, but... If I've got a sequence of ciphertext (C0, C1, C2,...) and an IV, then P0 = IV ^ ECBDec(C0) (IV xor ECB Decryption of C0) P1 = C0 ^ ECBDec(C1) P2 = C1 ^ ECBDec(C2) ... So, if you've got the IV and the ciphertext and you can figure out how to do ECB decryption, it's a small step to do CBC decryption. So why is CBC more secure than ECB? Am I missing something? Bill Message-Id: <199609271404.KAA08489@jekyll.piermont.com> To: Rob Adams Cc: ipsec@TIS.COM Subject: Re: Comments on ESP and AH IPSEC drafts. In-Reply-To: Your message of "Thu, 26 Sep 1996 14:44:01." <19960926144401adams@161.44.128.127> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 27 Sep 1996 10:04:59 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Rob Adams writes: > I think including an IV in the packet should constitute a separate > transform with a unique IANA designation. Optional fields slow > performance and in this case, the keying material and caching information > are different even though most of the actual operation is substantially > the same. Without an IV, what you are running is the ECB mode of these algorithms which is highly insecure. I do not think that should be encouraged. > I don't see the purpose of negotiated window sizes unless there is some > vulnerability in accepting out of order packets. Serious denial of service attacks result if you are forced to keep an infinite window. Perry To: "Whelan, Bill" Cc: ipsec@TIS.COM Subject: Re: CBC vs. ECB Date: Thu, 03 Oct 1996 09:59:21 -0400 From: Steven Bellovin Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9610031149.aa09859@neptune.TIS.COM> Without an IV, what you are running is the ECB mode of these algorithms which is highly insecure. I do not think that should be encouraged. So CBC is more secure than ECB! I've been accepting statements such as this as gospel for a while, but now I'm not so sure. Please excuse my ignorance, but... If I've got a sequence of ciphertext (C0, C1, C2,...) and an IV, then P0 = IV ^ ECBDec(C0) (IV xor ECB Decryption of C0) P1 = C0 ^ ECBDec(C1) P2 = C1 ^ ECBDec(C2) ... So, if you've got the IV and the ciphertext and you can figure out how to do ECB decryption, it's a small step to do CBC decryption. So why is CBC more secure than ECB? Am I missing something? CBC is more secure than ECB for a lot of reasons, most of which are explained in any decent cryptography text. To name a few: 1) Common plaintext blocks will (in general) be mapped to different ciphertext blocks. 2) If the IV is different, even the first block will be encrypted differently. This in turn will cause all subsequent blocks to be encrypted differently, even if the packets are identical. Note that a constant IV may suffice (for this property) if the first block of the plaintext is always different (i.e., if it contains a sequence number). 3) Splicing messages is more difficult, as a CBC splice results in a corrupted plaintext block. But you're certainly right that an enemy who can already solve the ECB encryption won't be hindered at all by use of CBC mode. To: perry@piermont.com Cc: Rob Adams , ipsec@TIS.COM Subject: Re: Comments on ESP and AH IPSEC drafts. Date: Thu, 03 Oct 1996 10:27:30 -0400 From: Steven Bellovin Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9610031153.aa10042@neptune.TIS.COM> Rob Adams writes: > I think including an IV in the packet should constitute a separate > transform with a unique IANA designation. Optional fields slow > performance and in this case, the keying material and caching inform ation > are different even though most of the actual operation is substantia lly > the same. Without an IV, what you are running is the ECB mode of these algorithms which is highly insecure. I do not think that should be encouraged. If the first block is guaranteed to be different -- and it is here, since there's a sequence number -- you don't need an IV to protect the first block. (Well, there are probable plaintext attacks, but that's a far cry from ECB mode.) > I don't see the purpose of negotiated window sizes unless there is s ome > vulnerability in accepting out of order packets. Serious denial of service attacks result if you are forced to keep an infinite window. I don't see the point to negotiating the window size. It seems to me to be a local implementation issue. Senders cannot, in general, control the delivery patterns; that's more an artifact of the current state of the network. Given that, what can the sender do with knowledge of the receiver's window size? An attacker can replay old packets which will be dropped. He or she can also send random packets, but those will have a bad authentication check, and so will not (or at least should not) affect the last packet counter. I do not see any denial of service attacks here. (An attacker who can intercept and reorder all packets to a destination has accomplished nothing; the most that can be done by delaying a packet is to cause it to be dropped.) Received: from relay.hq.tis.com by neptune.TIS.COM id aa10444; 3 Oct 96 12:10 EDT Received: by relay.hq.tis.com; id MAA23438; Thu, 3 Oct 1996 12:13:46 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma023436; Thu, 3 Oct 96 12:13:25 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA16007; Thu, 3 Oct 96 12:15:28 EDT Received: by relay.hq.tis.com; id MAA23424; Thu, 3 Oct 1996 12:13:16 -0400 Received: from fluffy.cisco.com(161.44.128.253) by relay.tis.com via smap (V3.1.1) id xma023416; Thu, 3 Oct 96 12:12:46 -0400 Received: from localhost (localhost [127.0.0.1]) by fluffy.cisco.com (8.7.5/8.7.3) with SMTP id JAA00995 for ; Thu, 3 Oct 1996 09:15:05 -0700 (PDT) Message-Id: <199610031615.JAA00995@fluffy.cisco.com> To: ipsec@TIS.COM Subject: IV or no IV; that is not the question... Date: Thu, 03 Oct 1996 09:15:05 -0700 From: Derrell Piper Sender: ipsec-approval@neptune.tis.com Precedence: bulk > Without an IV, what you are running is the ECB mode of these > algorithms which is highly insecure. I do not think that should be > encouraged. > > Am I missing something? > > Bill Yes, you and Perry are both missing something. If you read the "Combined DES-CBC, HMAC and Replay Prevention Security Transform" Internet Draft, it says that the IVs for the initiator and responder are derived from the secret key using keyed MD5: IV_Key_I = Truncate(MD5( I_Pad_I | K ),64) IV_Key_R = Truncate(MD5( I_Pad_R | K ),64) ...where "I_Pad_I" and "I_Pad_R" are constants and "K" is the secret key. In other words, the IVs do not need to be explicitly communicated, though we are, of course, doing CBC. That's why the draft lists this field as Optional. Derrell Received: from relay.hq.tis.com by neptune.TIS.COM id aa10640; 3 Oct 96 12:19 EDT Received: by relay.hq.tis.com; id MAA23626; Thu, 3 Oct 1996 12:23:16 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma023596; Thu, 3 Oct 96 12:22:48 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA16495; Thu, 3 Oct 96 12:24:53 EDT Received: by relay.hq.tis.com; id MAA23593; Thu, 3 Oct 1996 12:22:46 -0400 Received: from fluffy.cisco.com(161.44.128.253) by relay.tis.com via smap (V3.1.1) id xma023590; Thu, 3 Oct 96 12:22:29 -0400 Received: from localhost (localhost [127.0.0.1]) by fluffy.cisco.com (8.7.5/8.7.3) with SMTP id JAA01037 for ; Thu, 3 Oct 1996 09:24:49 -0700 (PDT) Message-Id: <199610031624.JAA01037@fluffy.cisco.com> To: ipsec@TIS.COM Subject: replay window Date: Thu, 03 Oct 1996 09:24:43 -0700 From: Derrell Piper Sender: ipsec-approval@neptune.tis.com Precedence: bulk > Serious denial of service attacks result if you are forced to keep an > infinite window. > > Perry No one's suggesting keeping an infinite replay window. Let's get back to the point, which is about negotiated replay window size. I don't see the point of negotiating the window size. I do see the point of negotiating whether or not your side cares about replay, but the size of the window should be left up to the implementation on either side. You simply have to trust that the other side is going to honor its intention to not accept out-of-order packets. Given that, there's no reason not to let it choose a window size that makes sense for it. Several people have made claims that there is a denial-of-service issue if you allow for any sized window. Given that the replay counter is both digitally signed and encrypted, I just don't get it. Can anyone justify this claim? If not, let's stop confusing this issue. Derrell Received: from relay.hq.tis.com by neptune.TIS.COM id aa12859; 3 Oct 96 13:40 EDT Received: by relay.hq.tis.com; id NAA26423; Thu, 3 Oct 1996 13:44:16 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma026400; Thu, 3 Oct 96 13:43:50 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA20897; Thu, 3 Oct 96 13:45:54 EDT Received: by relay.hq.tis.com; id NAA26394; Thu, 3 Oct 1996 13:43:46 -0400 Received: from fluffy.cisco.com(161.44.128.253) by relay.tis.com via smap (V3.1.1) id xma026390; Thu, 3 Oct 96 13:43:34 -0400 Received: from localhost (localhost [127.0.0.1]) by fluffy.cisco.com (8.7.5/8.7.3) with SMTP id KAA01148 for ; Thu, 3 Oct 1996 10:45:54 -0700 (PDT) Message-Id: <199610031745.KAA01148@fluffy.cisco.com> To: ipsec@TIS.COM Subject: replay counter size Date: Thu, 03 Oct 1996 10:45:45 -0700 From: Derrell Piper Sender: ipsec-approval@neptune.tis.com Precedence: bulk The latest HMAC AH draft (the one following Montreal) specifies a 64-bit replay field. The latest Combined ESP draft uses only a 32-bit field. Jim, was it your intention for these specs to diverge like this? I would like to understand why these fields need to be different for AH and ESP. I would rather see them be the same. I personally believe that 2^32 packets is too much data to encrypt under one key anyway, so I think 32-bits is the right number. But I'm more concerned that AH and ESP be equally protected. I recall some discussion in Montreal about the performance of replay window checks being dependent on the underlying hardware register size, which supports our desire to make this implementation dependent. I do not recall discussing changing the replay counter from 32 to 64 bits, though I confess to being a bit late for the first working group meeting, due to not being able to get into the room due to overcrowding. Derrell To: "Whelan, Bill" Cc: ipsec@TIS.COM Subject: Re: CBC vs. ECB In-Reply-To: Your message of "Wed, 02 Oct 1996 17:05:26 EST." <9609038443.AA844353349@netx.nei.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Thu, 03 Oct 1996 13:38:07 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9610031354.aa13351@neptune.TIS.COM> "Whelan, Bill" writes: > So CBC is more secure than ECB! I've been accepting statements such > as this as gospel for a while, but now I'm not so sure. Please excuse > my ignorance, but... ECB modes have a very bad property: repeated instances of the same message encrypted under the same key form the same ciphertext. CBC does not have this property. I would suggest reading a good book like Schneier's Applied Cryptography (2nd Ed.) if you want to get a better idea of the issues. Perry Received: from relay.hq.tis.com by neptune.TIS.COM id aa16345; 3 Oct 96 21:22 EDT Received: by relay.hq.tis.com; id VAA00525; Thu, 3 Oct 1996 21:26:45 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma000521; Thu, 3 Oct 96 21:26:27 -0400 Received: from la.tis.com (scintillate.la.tis.com) by tis.com (4.1/SUN-5.64) id AA07676; Thu, 3 Oct 96 21:28:31 EDT Received: from relay.la.tis.com by la.tis.com (4.1/SUN-5.64) id AA10800; Thu, 3 Oct 96 15:29:02 PDT Received: by relay.la.tis.com; id PAA19116; Thu, 3 Oct 1996 15:24:02 -0700 Received: from fluffy.cisco.com(161.44.128.253) by relay.la.tis.com via smap (V3.1.1) id xma019114; Thu, 3 Oct 96 15:23:51 -0700 Received: from localhost (localhost [127.0.0.1]) by fluffy.cisco.com (8.7.5/8.7.3) with SMTP id PAA01439; Thu, 3 Oct 1996 15:29:21 -0700 (PDT) Message-Id: <199610032229.PAA01439@fluffy.cisco.com> To: Stephen Kent Cc: ipsec@TIS.COM Subject: Re: replay window In-Reply-To: Your message of "Thu, 03 Oct 1996 16:05:06 EDT." Date: Thu, 03 Oct 1996 15:28:00 -0700 From: Derrell Piper Sender: ipsec-approval@neptune.tis.com Precedence: bulk Steve, Thanks for your note. > Window negotiation allows for two forms of flexibility. The >receiver can declare what window size it is willing to deal with, and the >transmitter can declare what size it thinks might be appropriate, based on >some knowledge of the type of traffic (e.g., on a per-association basis). By, "type of traffic," are you referring to non-security concerns (e.g. allowing for larger windows over associations with known or assumed high latency)? If so, can you suggest a reasonable algorithm for determining what replay window size a system might request/require? Or do you think that this should just be hard-wired to, say, 32 for now, leaving room for real negotiation in the future should it turn out to be needed? > Finally, just a nit about your closing comments. The sequence >number is not always encrypted, and it is not signed. Since ESP now offers >options for connectionless integrity, anti-replay features, data origin >authentication, and confidentiality options, one might not encrypt the >sequence numbers. The defined algorithms for connectionless integrity do >not currently include signature algorithms, only keyed hash algorithms. I'm sorry. I meant to say that it was included in an HMAC MD5 digest, not that it was digitally signed. I assume you're talking about "big E" ESP here and not the actual combined transform, which does position the replay field within the encrypted payload. Do you agree though that supporting a replay window within the AH or ESP framework does not necessarily introduce vulnerabilities? A replay counter that was neither included in a message digest, nor signed, nor encrypted, would, of course, be vulnerable to denial-of-service attacks and useless from a security viewpoint. I think we all agree on that... I'm not necessarily against negotiated replay window size, if it can be justified or has some added value. The problem I have is with arbitrary claims that things "increase security" by their mere presence. I do not think that negotiating a replay window size has any realistic effect on the security of the specific AH and ESP transforms described in the current Internet Drafts. Derrell Received: from relay.hq.tis.com by neptune.TIS.COM id aa16595; 3 Oct 96 21:29 EDT Received: by relay.hq.tis.com; id VAA00659; Thu, 3 Oct 1996 21:33:15 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma000655; Thu, 3 Oct 96 21:33:12 -0400 Received: from la.tis.com (scintillate.la.tis.com) by tis.com (4.1/SUN-5.64) id AA08934; Thu, 3 Oct 96 21:35:17 EDT Received: from relay.la.tis.com by la.tis.com (4.1/SUN-5.64) id AA07580; Thu, 3 Oct 96 13:03:02 PDT Received: by relay.la.tis.com; id MAA17109; Thu, 3 Oct 1996 12:58:02 -0700 Received: from zafu.bbn.com(128.89.0.25) by relay.la.tis.com via smap (V3.1.1) id xma017099; Thu, 3 Oct 96 12:57:36 -0700 Received: from [128.89.0.110] (COMSEC.BBN.COM [128.89.0.110]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id QAA08885; Thu, 3 Oct 1996 16:02:08 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 3 Oct 1996 16:05:06 -0400 To: Derrell Piper From: Stephen Kent Subject: Re: replay window Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Darrell. As the initial proponet of including a window size negotiation, let me explain the rationale behind the anti-replay technique in more detail. First, it is not a requirement that an anti-replay implementation accept packets only in order. In fact, I'd consider such an implementation to be inapopropriate since it violates the normal IP layer assumptions about ordering. The goal of anti-replay facilities in IPSEC is to detect and reject duplicate packets and a windowing mechanism is included to facilitate this task. Without a window at the receiver, and given the goal of allowing out of order packet arrival, it is not generally feasible to detect and reject replayed packets. So, the window is used to allow the receiver to delcare some range of packets to be old enough to be rejected, without needing to keep track of the packets actually received after some point in time. Window negotiation allows for two forms of flexibility. The receiver can declare what window size it is willing to deal with, and the transmitter can declare what size it thinks might be appropriate, based on some knowledge of the type of traffic (e.g., on a per-association basis). I don't know if this will really turn out to be needed in practice, but it seems like an appropriate facility to include. I don't think leaving the window size purely to the receiving implementation is a good idea. For one thing, it makes it harder to test and determine if the system is working properly. Finally, just a nit about your closing comments. The sequence number is not always encrypted, and it is not signed. Since ESP now offers options for connectionless integrity, anti-replay features, data origin authentication, and confidentiality options, one might not encrypt the sequence numbers. The defined algorithms for connectionless integrity do not currently include signature algorithms, only keyed hash algorithms. Steve Received: from relay.hq.tis.com by neptune.TIS.COM id aa02613; 4 Oct 96 10:08 EDT Received: by relay.hq.tis.com; id KAA09515; Fri, 4 Oct 1996 10:12:31 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma009512; Fri, 4 Oct 96 10:12:16 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA27433; Fri, 4 Oct 96 10:14:20 EDT Received: by relay.hq.tis.com; id KAA09494; Fri, 4 Oct 1996 10:12:03 -0400 Received: from fnal.fnal.gov(131.225.110.17) by relay.tis.com via smap (V3.1.1) id xma009476; Fri, 4 Oct 96 10:11:37 -0400 Received: from gungnir.fnal.gov ("port 34341"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IA8N6M4544002W6E@FNAL.FNAL.GOV>; Fri, 04 Oct 1996 09:13:41 -0600 (CST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id JAA16341; Fri, 04 Oct 1996 09:13:34 -0500 Date: Fri, 04 Oct 1996 09:13:34 -0500 From: Matt Crawford Subject: Re: CBC vs. ECB In-Reply-To: "03 Oct 1996 13:38:07 EDT." <"9610031354.aa13351"@neptune.TIS.COM> To: perry@piermont.com Cc: "Whelan, Bill" , ipsec@TIS.COM Message-Id: <199610041413.JAA16341@gungnir.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ > So CBC is more secure than ECB! I've been accepting statements such > > as this as gospel for a while, but now I'm not so sure. Please excuse > > my ignorance, but... > > ECB modes have a very bad property: repeated instances of the same > message encrypted under the same key form the same ciphertext. CBC > does not have this property. But this is true whether or not you have an IV, and that's where this thread started. Yes, with no IV, a constant first block will always come out the same if you begin again with the same key. But if an SA includes an IV, it would seem to me to be as easy to change the key as to change the IV. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A Received: from relay.hq.tis.com by neptune.TIS.COM id aa03716; 4 Oct 96 10:43 EDT Received: by relay.hq.tis.com; id KAA10398; Fri, 4 Oct 1996 10:47:05 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma010389; Fri, 4 Oct 96 10:46:41 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA29349; Fri, 4 Oct 96 10:48:42 EDT Received: by relay.hq.tis.com; id KAA10386; Fri, 4 Oct 1996 10:46:35 -0400 Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1.1) id xma010384; Fri, 4 Oct 96 10:46:22 -0400 Received: from [128.89.0.110] (COMSEC.BBN.COM [128.89.0.110]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id KAA01010; Fri, 4 Oct 1996 10:48:29 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 4 Oct 1996 10:51:21 -0400 To: Derrell Piper From: Stephen Kent Subject: Re: replay window Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Derrell, I don't have a proposed algorithm for calculating a replay window size; I'm just concerned that we not pick a single, universal value at this time. However, I do feel that the size of the window ultitamely should be controlled by the receiver, since that's where the work is done. So, "negotiation" may be a misnomer here. One could begin by having a receiving implementation always insist on a fixed window size, irrespective of the request from the sender, and that would be compliant. At least this allows for changinf your implementation in the future but advertising the change, rather than having it be a locally defined mystery. I don't think adding a replay window represents an inc rease in vulnerability, modulo the usual concerns about added functionality representing more opportunities to intorduce errors, and the added overhead of doing the checking. With regard to the question of what's encrypted and what is not, I was talking in terms of ESP overall, not any particular, already defined transforms. The intent is to re-write the ESP spec to pre-define the range of transforms as individual options, to allow independent documentation of each option and avoid the combinatorial explosion of transform documents. Steve Received: from relay.hq.tis.com by neptune.TIS.COM id aa07827; 4 Oct 96 14:30 EDT Received: by relay.hq.tis.com; id OAA18528; Fri, 4 Oct 1996 14:33:58 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma018522; Fri, 4 Oct 96 14:33:35 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA14262; Fri, 4 Oct 96 14:35:38 EDT Received: by relay.hq.tis.com; id OAA18513; Fri, 4 Oct 1996 14:33:29 -0400 Received: from hq.cisco.com(161.44.72.2) by relay.tis.com via smap (V3.1.1) id xma018498; Fri, 4 Oct 96 14:33:18 -0400 Received: from 161.44.128.127 ([161.44.128.127]) by HQ.CISCO.COM via INTERNET ; Fri, 4 Oct 1996 11:34:37 PDT Date: Fri, 4 Oct 1996 11:33:04 From: Rob Adams Message-Id: <19961004113304adams@161.44.128.127> To: glenn@snad.ncsl.nist.gov Subject: Re: Comments on ESP and AH IPSEC drafts. Cc: ipsec@TIS.COM X-Mailer: Pronto Mail [tgv Ver 2.03] Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk >Since you know apriori whether a packet contains the replay field (i.e. > information >provided in the security association) is this really that big of a problem? > It's kind of a pain because it is variable in the fixed part of the header. None of this is tremendously difficult. It would just be cleaner and easier if the variable part of the header was at the end, after information that is fixed. Okay, Okay, okay.. maybe I'm nit picking. But I still prefer: +12345678123456781234567812345678+ |--------------------------------+ | nexhdr|length | reserved | +--------------------------------+ | | | signature | ~ ~ +--------------------------------+ | replay (optional?) | +--------------------------------+ | ++ pad for md5 ++ | +--------------------------------+ This gives a real representation of the size of the replay field. No padding necessary for SHA1. You know the location of the signature, you know where the replay field is if you care, pad because length++. Otherwise we have, if we have to do replay then replay is here and signature is here and pad is here for sha otherwise blah blah blah blah.. Sue me, I'm a purist.. %) ----------------------------------------------------------- Rob Adams adams@cisco.com Cisco Systems 408 457 5200 101 Cooper Street, Santa Cruz, CA 95060 Received: from relay.hq.tis.com by neptune.TIS.COM id aa07971; 4 Oct 96 14:34 EDT Received: by relay.hq.tis.com; id OAA18714; Fri, 4 Oct 1996 14:37:59 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma018699; Fri, 4 Oct 96 14:37:31 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA14550; Fri, 4 Oct 96 14:39:35 EDT Received: by relay.hq.tis.com; id OAA18690; Fri, 4 Oct 1996 14:37:29 -0400 Received: from ns.newbridge.com(192.75.23.67) by relay.tis.com via smap (V3.1.1) id xma018680; Fri, 4 Oct 96 14:37:13 -0400 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id OAA17367 for ; Fri, 4 Oct 1996 14:39:31 -0400 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma017228; Fri Oct 4 14:38:52 1996 Received: from tsntsrv2.timestep.com ([192.168.219.191]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id OAA16372 for ; Fri, 4 Oct 1996 14:38:51 -0400 Received: by tsntsrv2.timestep.com with Microsoft Exchange (IMC 4.0.838.14) id <01BBB201.FBC984E0@tsntsrv2.timestep.com>; Fri, 4 Oct 1996 14:40:27 -0400 Message-Id: X-Ms-Tnef-Correlator: From: Roy Pereira To: 'IPSEC' Subject: Security Association Payload length Date: Fri, 4 Oct 1996 14:40:25 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.838.14 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BBB201.FBCB0B80" Sender: ipsec-approval@neptune.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BBB201.FBCB0B80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Should the SA payload length be specified in 4-octet units, or should it not be specified as all of the other payload types are, in 1-octet units? It doesn't make much sense to have one payload type use a different length unit than the rest. Will this inconsistency be changed in the new draft coming out shortly? ------ =_NextPart_000_01BBB201.FBCB0B80 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IhwSAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAAzAcKAAQADgAoABkABQA1AQEggAMADgAAAMwHCgAE AA4AKAAaAAUANgEBCYABACEAAAA5OUNCRTZERjVEMUREMDExOTI1RTAwODA1RkZDNzIwMQA7BwEN gAQAAgAAAAIAAgABBIABACQAAABTZWN1cml0eSBBc3NvY2lhdGlvbiBQYXlsb2FkIGxlbmd0aACB DQEDkAYArAQAABkAAAADACYAAAAAAAMANgAAAAAAAwAGENVI9EQDAAcQ/wAAAB4ACBABAAAAZQAA AFNIT1VMRFRIRVNBUEFZTE9BRExFTkdUSEJFU1BFQ0lGSUVESU40LU9DVEVUVU5JVFMsT1JTSE9V TERJVE5PVEJFU1BFQ0lGSUVEQVNBTExPRlRIRU9USEVSUEFZTE9BRFRZUEUAAAAAAwAQEAAAAAAD ABEQAAAAAAIBCRABAAAAiwEAAIcBAABRAgAATFpGdRTRgHv/AAoBDwIVAqQD5AXrAoMAUBMDVAIA Y2gKwHNldG4yBgAGwwKDMgPFAgBwhHJxEiJzdGVtAoMuMwPGBxMCgzQPemhlomwDIERsZwKDNRSt /n0KgAjPCdkCgAqBDbELYOBuZzEwMxSQCwoXYocB0BZxCGBsZCB0FpCpBgBBIAqweRjQYRzgSmwJ 8GcdACBiHSBzPnAFkAaQCJAc4AuAIDRYLW9jFBAFQHUDAHRocywgBbFzHKQgACDsbm8FQB5rYQQg B0ADIHxvZhzzITAWkAXAHXZ0vnkeoCJBGUAgMB8xMR96Sj8KhUkFQGRvB5BulicFQADAax0gbXUR sE8egAnwEfAc8G8gEcB2vSLxbh0gI3of0CehYSZA/QaQZgSQCfAFQB31H+Ic8W8DkR0CGUAUAC4K hQqFV/8DEAMgHQAEAB8hBaAAgRQB/S2QeR5SEbEa8B8EHQIoYPEH4GRyYQGALoADcAuAOmcgQHUF QCCBACBseQslphhhADIAAB4AcAABAAAAJAAAAFNlY3VyaXR5IEFzc29jaWF0aW9uIFBheWxvYWQg bGVuZ3RoAAIBcQABAAAAFgAAAAG7siL+uArINsccWRHQmoAAAMCNYdoAAEAAOQDgSh+CI7K7AQMA 8T8JBAAAAgFHAAEAAAA5AAAAYz1VUzthPSA7cD1UaW1lU3RlcCBDb3Jwb3JhO2w9VFNOVFNSVjIt OTYxMDA0MTg0MDI1Wi0yMDIAAAAAAgH5PwEAAABaAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAA AAAAAC9PPVRJTUVTVEVQIENPUlBPUkFUSU9OL09VPVRJTUVTVEVQL0NOPVJFQ0lQSUVOVFMvQ049 UlBFUkVJUkEAAAAeAPg/AQAAAAwAAABSb3kgUGVyZWlyYQACAfs/AQAAAFoAAAAAAAAA3KdAyMBC EBq0uQgAKy/hggEAAAAAAAAAL089VElNRVNURVAgQ09SUE9SQVRJT04vT1U9VElNRVNURVAvQ049 UkVDSVBJRU5UUy9DTj1SUEVSRUlSQQAAAB4A+j8BAAAADAAAAFJveSBQZXJlaXJhAEAABzDgSh+C I7K7AUAACDBwOW2CI7K7AQMADTT9PwAAAgEUNAEAAAAQAAAAVJShwCl/EBulhwgAKyolFx4APQAB AAAAAQAAAAAAAAALACkAAAAAAAsAIwAAAAAAAgF/AAEAAABRAAAAPGM9VVMlYT1fJXA9VGltZVN0 ZXBfQ29ycG9yYSVsPVRTTlRTUlYyLTk2MTAwNDE4NDAyNVotMjAyQHRzbnRzcnYyLnRpbWVzdGVw LmNvbT4AAAAAsC8= ------ =_NextPart_000_01BBB201.FBCB0B80-- Date: Sun, 6 Oct 1996 12:01:27 -0400 From: Hilarie Orman Message-Id: <199610061601.MAA08934@earth.hpc.org> To: ipsec@TIS.COM Subject: Deafening Silence Sender: ipsec-approval@neptune.tis.com Precedence: bulk What is the follow-up to Schiller's announcement re keying of a few weeks ago? I've not heard any plans in public or in private, so I'm wondering what plans there are and what will we see come December. My interest is especially keen if I am expected to be a participant in the outcome. Hilarie Date: Mon, 7 Oct 1996 09:48:40 -0400 In-Reply-To: Hilarie Orman "Deafening Silence" (Oct 6, 12:01pm) References: <199610061601.MAA08934@earth.hpc.org> X-Mailer: Z-Mail (3.2.1 10oct95) To: Hilarie Orman Subject: Re: Deafening Silence Cc: ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipsec-approval@neptune.tis.com Precedence: bulk From: ipsec-approval@neptune.tis.com Message-ID: <9610071001.aa10645@neptune.TIS.COM> Hi, I thought Schiller has made a decision about key management for this working group: ISAKMP/OAKLEY will be the mandatory one. Under this situation, I think that it is clear that in December meeting we should focus (in a higher priority at least) on the ISAKMP/OAKLEY proposal. -Felix wu@csc.ncsu.edu On Oct 6, 12:01pm, Hilarie Orman wrote: > Subject: Deafening Silence > What is the follow-up to Schiller's announcement re keying of a few > weeks ago? I've not heard any plans in public or in private, so I'm > wondering what plans there are and what will we see come December. My > interest is especially keen if I am expected to be a participant in > the outcome. > > Hilarie > > >-- End of excerpt from Hilarie Orman Date: Mon, 07 Oct 1996 13:10:15 -0400 To: Hilarie Orman , ipsec@TIS.COM From: Robert Moskowitz Subject: Re: Deafening Silence Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9610071316.aa13124@neptune.TIS.COM> At 12:01 PM 10/6/96 -0400, Hilarie Orman wrote: >What is the follow-up to Schiller's announcement re keying of a few >weeks ago? I've not heard any plans in public or in private, so I'm >wondering what plans there are and what will we see come December. My >interest is especially keen if I am expected to be a participant in >the outcome. I expect to see considerable headway in Oakley/ISAKMP, both tuning up the specs and seeing product in San Jose. I feel we need to move some of our energy to key (or rather cert) formats and retrieval methods. Such as how to get X.509 certs safely. When might DNSSEC be used and when not. Also firewall/RFC1918 issues need to start coming forward. More on this after Oct 17th (date of my next AIAG security wg meeting). Robert Moskowitz Chrysler Corporation (810) 758-8212 To: ipsec@TIS.COM cc: Hilarie Orman , wu@csc.ncsu.edu Subject: Re: Deafening Silence In-reply-to: Your message of "Mon, 07 Oct 1996 09:48:40 EDT." <9610071001.aa10645@neptune.TIS.COM> X-Url: http://www.incog.com/~stoltz Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 07 Oct 1996 12:26:23 -0700 From: Ben Stoltz Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9610071527.aa14984@neptune.TIS.COM> ipsec-approval@neptune.tis.com said: > I thought Schiller has made a decision about key management for this > working group: ISAKMP/OAKLEY will be the mandatory one. Under this > situation, I think that it is clear that in December meeting we > should focus (in a higher priority at least) on the ISAKMP/OAKLEY > proposal. > > -Felix wu@csc.ncsu.edu Please take a closer look at Schiller's note. ISAKMP/OAKLEY is only mandatory for IPv6. ISAKMP/Oakley and SKIP are on an equal footing for IPv4. Ben To: ipsec@TIS.COM, gnu@toad.com Subject: Short keys * Options, combinations, and negotiations => simplicity Date: Tue, 08 Oct 1996 00:04:31 -0700 From: John Gilmore Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9610080731.aa28031@neptune.TIS.COM> There's also been a deafening silence with respect to last week's announcement that the US is taking further measures to force key-escrow on us, by offering us the wimpy option to gladly pay the piper Tuesday (2-years-day?) for a 56-bit hamburger today. RFC 1984 makes it clear that IAB/IESG, who have to pass on our work, will frown on short or limited key lengths and/or key-escrow facilities. Yet somehow the WG has standardized on "exportable" 56-bit DES, which we know to be breakable by feasible brute force guessed-plaintext attacks. The only known cure is long keys, which we already know how to do, but haven't spec'd. Meanwhile NSA is refusing *all* export licenses for 3DES, even resonable ones for US company branches and financial institutions, in an attempt to pressure groups like us into avoiding it. Let's build protocols that are actually likely to pass technical muster and become standards, and honor our parent groups' advice by deliberately ignoring the local-country issues in our worldwide standard. I have not seen a combined 3DES-HMAC-replay transform draft. Unless I hear a public reply saying "I am writing it and will post it by date X", I will write one and post it by the end of October. Beyond this I have a further philosophical observation. I think that what we are trying to do is not as hard as we are making it. Hilarie correctly identified the proliferation of options as one of the factors making it very hard to procedurally come to consensus. The realization that AH and ESP could not be securely separated also points us in the direction of fewer options for improved security. Yet we continue to see, and honor with debate, suggestions for further options, combinations, and/or negotiations. For example, Steve Kent's recent messages conflate the WG's desire to simplify the writing of spec documents with a desire to offer optional combinations of transforms. I believe the intent of the WG is to offer fixed standard combinations of transforms, which happen to be written for clarity in several documents. E.g. because DES would be documented separately from replay protection does not mean an implementation can validly do one without the other (by negotiation or by default). I believe that to make reasonable progress we'll have to steadfastly ignore such proposals, and proceed with building protocols that have few or no options, combinations, and negotiations in the initial implementations. In the same way that we've ruthlessly been narrowing the key agreement protocol options we're willing to talk about, we must do the same for transforms, and must cull insecure algorithms like 56-bit DES, to achieve our goal of a uniform worldwide high-security standard. John PS: We'll need to do the same to ISAKMP as well, cutting its generality back (in the first, worldwide standard implementations) to a small well understood set, that returns "unknown negotiation" whenever a "generic" parameter has a value other than the obvious. Message-Id: <199610081650.MAA02511@jekyll.piermont.com> To: John Gilmore cc: ipsec@TIS.COM Subject: Re: Short keys * Options, combinations, and negotiations => simplicity In-reply-to: Your message of "Tue, 08 Oct 1996 00:04:31 PDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 08 Oct 1996 12:50:59 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk John Gilmore writes: > RFC 1984 makes it clear that IAB/IESG, who have to pass on our work, > will frown on short or limited key lengths and/or key-escrow > facilities. Yet somehow the WG has standardized on "exportable" > 56-bit DES, which we know to be breakable by feasible brute force > guessed-plaintext attacks. John; We didn't standardize on 56-bit DES for exportability reasons. We all know that its breakable and that it can't be exported anyway. We standardized on it far more because it was a lowest common denominator that was generally understood. > I have not seen a combined 3DES-HMAC-replay transform draft. Unless I > hear a public reply saying "I am writing it and will post it by date > X", I will write one and post it by the end of October. I strongly encourage you to do so. To my knowledge, no one is writing one, and we are all overworked. Any help you could provide in writing such a thing would be greatly appreciated. > PS: We'll need to do the same to ISAKMP as well, cutting its > generality back (in the first, worldwide standard implementations) to > a small well understood set, that returns "unknown negotiation" > whenever a "generic" parameter has a value other than the obvious. I tend to agree that we may have added too many knobs to twiddle... Perry Message-Id: <199610081917.PAA17438@raptor.research.att.com> To: perry@piermont.com cc: John Gilmore , ipsec@TIS.COM Subject: Re: Short keys * Options, combinations, and negotiations => simplicity Date: Tue, 08 Oct 1996 15:17:10 -0400 From: Steven Bellovin Sender: ipsec-approval@neptune.tis.com Precedence: bulk > I have not seen a combined 3DES-HMAC-replay transform draft. Unless I > hear a public reply saying "I am writing it and will post it by date > X", I will write one and post it by the end of October. I strongly encourage you to do so. To my knowledge, no one is writing one, and we are all overworked. Any help you could provide in writing such a thing would be greatly appreciated. Steve Kent had made the point that we had too many protocols that differed only in the name of the encryption algorithm. He was going to write a new RFC for any block cipher, into which one can plug the names `3DES', `DES', etc., though for something like 3DES a short RFC specifying inner vs. outer CBC would be useful. I haven't seen any drafts in this new format, though. Steve? Received: from relay.hq.tis.com by neptune.TIS.COM id aa06172; 8 Oct 96 15:45 EDT Received: by relay.hq.tis.com; id PAA02497; Tue, 8 Oct 1996 15:49:50 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma002490; Tue, 8 Oct 96 15:49:22 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id PAA24791 for ; Tue, 8 Oct 1996 15:47:41 -0400 (EDT) Received: by relay.hq.tis.com; id PAA02482; Tue, 8 Oct 1996 15:49:20 -0400 Received: from bozo.mit.edu(18.72.0.198) by relay.tis.com via smap (V3.1.1) id xma002478; Tue, 8 Oct 96 15:49:19 -0400 Received: from bozo by bozo.MIT.EDU with SMTP id PAA21412; Tue, 8 Oct 1996 15:44:27 -0400 Message-ID: <325AAD65.2781@mit.edu> Date: Tue, 08 Oct 1996 15:37:09 -0400 From: "Jeffrey I. Schiller" Organization: Massachusetts Institute of Technology X-Mailer: Mozilla 3.0 (X11; U; IRIX 5.2 IP22) MIME-Version: 1.0 To: Ben Stoltz CC: ipsec@TIS.COM, Hilarie Orman , wu@csc.ncsu.edu Subject: Re: Deafening Silence References: <9610071527.aa14984@neptune.TIS.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk Ben Stoltz wrote: > Please take a closer look at Schiller's note. > ISAKMP/OAKLEY is only mandatory for IPv6. ISAKMP/Oakley and SKIP are > on an equal footing for IPv4. ISAKMP/Oakley is mandatory for IPv6 because only in IPv6 is IPSEC mandatory. It isn't completely clear what mandatory would mean in the IPv4 context (though I can think of some interpretations). However I think you go to far to say that ISAKMP/Oakley and SKIP are on equal footing. They are not. It is important that the working group complete the work on ISAKMP/Oakley so we have a deployable solution for IPv6 and for IPv4. -Jeff Message-Id: <199610082100.OAA10269@denwa.incog.com> X-Mailer: exmh version 1.6.4 10/10/95 To: "Jeffrey I. Schiller" cc: ipsec@TIS.COM, Hilarie Orman , wu@csc.ncsu.edu Subject: Re: Deafening Silence X-Url: http://www.incog.com/~stoltz Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 08 Oct 1996 14:00:17 -0700 From: Ben Stoltz Sender: ipsec-approval@neptune.tis.com Precedence: bulk (speaking as an individual) As far as the working group activities go, I understand the need to complete the work on ISAKMP/Oakley. I did not mean to imply that SKIP requires as much of the working group's time. There are trade-offs with both key management schemes and the cost of the more complex implementation is, of course, a correspondingly large amount of work. However, you did state that you would like to see a set of SKIP RFCs that fully define the SKIP approach. It is my impression that adequate SKIP drafts exist and that it should be appropriate to advance them to last call. Please explain if I am in error. Respectfully, Ben Stoltz On Fri, 20 Sep 1996, jis@mit.edu said: >I would like to see the IPSEC working group create three sets of RFCs. ... > o A Set of RFCs which fully define the SKIP approach. These RFCs will > follow the normal IETF standards tack ultimately resulting in a > protocol that is ELECTIVE for IPv4 and is ELECTIVE for IPv6. > Ben Stoltz wrote: > > Please take a closer look at Schiller's note. > > ISAKMP/OAKLEY is only mandatory for IPv6. ISAKMP/Oakley and SKIP are > > on an equal footing for IPv4. > > ISAKMP/Oakley is mandatory for IPv6 because only in IPv6 is IPSEC > mandatory. It isn't completely clear what mandatory would mean in the > IPv4 context (though I can think of some interpretations). However I > think you go to far to say that ISAKMP/Oakley and SKIP are on equal > footing. They are not. It is important that the working group complete > the work on ISAKMP/Oakley so we have a deployable solution for IPv6 and > for IPv4. > > -Jeff Received: from relay.hq.tis.com by neptune.TIS.COM id aa08305; 8 Oct 96 18:45 EDT Received: by relay.hq.tis.com; id SAA05863; Tue, 8 Oct 1996 18:48:51 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma005841; Tue, 8 Oct 96 18:48:21 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id SAA02470 for ; Tue, 8 Oct 1996 18:46:40 -0400 (EDT) Received: by relay.hq.tis.com; id SAA05837; Tue, 8 Oct 1996 18:48:21 -0400 Received: from unknown(129.34.139.18) by relay.tis.com via smap (V3.1.1) id xma005835; Tue, 8 Oct 96 18:48:15 -0400 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id SAA07920; Tue, 8 Oct 1996 18:50:34 -0400 Received: from hawpub.watson.ibm.com (hawpub.watson.ibm.com [9.2.90.19]) by mailhub1.watson.ibm.com (8.7.1/10-03-96) with SMTP id SAA631696; Tue, 8 Oct 1996 18:50:30 -0400 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA18537; Tue, 8 Oct 1996 18:50:19 -0400 From: Uri Blumenthal Message-Id: <9610082250.AA18537@hawpub.watson.ibm.com> Subject: Re: Short keys * Options, combinations, and negotiations => simplicity To: Steven Bellovin Date: Tue, 8 Oct 1996 18:50:13 -0400 (EDT) Cc: ipsec@TIS.COM In-Reply-To: <199610081917.PAA17438@raptor.research.att.com> from "Steven Bellovin" at Oct 8, 96 03:17:10 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk Steven Bellovin says: > Steve Kent had made the point that we had too many protocols that > differed only in the name of the encryption algorithm. He was going > to write a new RFC for any block cipher, into which one can plug the > names `3DES', `DES', etc., though for something like 3DES a short RFC > specifying inner vs. outer CBC would be useful. I think Eli Biham finally broke _all_ of the tripple modes, with the only exception of ECB-ECB-ECB (i.e. using 3DES as an encryption engine). I don't remember exactly, but if memory serves me, there is one more mode, that Eli thinks secure...Checking his home page would be useful. The paper: "Cryptanalysis of multiple modes" or such. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- Received: from relay.hq.tis.com by neptune.TIS.COM id aa08295; 8 Oct 96 18:44 EDT Received: by relay.hq.tis.com; id SAA05667; Tue, 8 Oct 1996 18:39:21 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma005646; Tue, 8 Oct 96 18:38:51 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id SAA02295 for ; Tue, 8 Oct 1996 18:37:10 -0400 (EDT) Received: by relay.hq.tis.com; id SAA05642; Tue, 8 Oct 1996 18:38:51 -0400 Received: from amaterasu.sandelman.ottawa.on.ca(205.233.54.134) by relay.tis.com via smap (V3.1.1) id xma005630; Tue, 8 Oct 96 18:38:29 -0400 Received: from amaterasu.sandelman.ocunix.on.ca (LOCALHOST [127.0.0.1]) by amaterasu.sandelman.ottawa.on.ca (8.7.5/8.6.12) with ESMTP id SAA29651 for ; Tue, 8 Oct 1996 18:41:00 -0400 (EDT) Message-Id: <199610082241.SAA29651@amaterasu.sandelman.ottawa.on.ca> To: ipsec@TIS.COM Subject: Re: Short keys * Options, combinations, and negotiations => simplicity In-reply-to: Your message of "Tue, 08 Oct 1996 15:17:10 EDT." <199610081917.PAA17438@raptor.research.att.com> Date: Tue, 08 Oct 1996 18:40:53 -0400 From: Michael Richardson Sender: ipsec-approval@neptune.tis.com Precedence: bulk >>>>> "Steven" == Steven Bellovin writes: Steven> cipher, into which one can plug the names `3DES', `DES', Steven> etc., though for something like 3DES a short RFC Steven> specifying inner vs. outer CBC would be useful. Would it be reasonable that these rfc's on the algorithms would also specify how they key is derived from the keying material, and whatever properties are required of this key? (e.g. weak keys for DES) :!mcr!: | Network security consulting and Michael Richardson | contract programming WWW: mcr@sandelman.ottawa.on.ca. PGP key available. Received: from relay.hq.tis.com by neptune.TIS.COM id aa09419; 8 Oct 96 19:49 EDT Received: by relay.hq.tis.com; id TAA07227; Tue, 8 Oct 1996 19:53:21 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma007222; Tue, 8 Oct 96 19:52:53 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id TAA03885 for ; Tue, 8 Oct 1996 19:51:13 -0400 (EDT) Received: by relay.hq.tis.com; id TAA07214; Tue, 8 Oct 1996 19:52:51 -0400 Received: from unknown(129.34.139.18) by relay.tis.com via smap (V3.1.1) id xma007210; Tue, 8 Oct 96 19:52:21 -0400 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id TAA05846; Tue, 8 Oct 1996 19:54:33 -0400 Received: from hawpub.watson.ibm.com (hawpub.watson.ibm.com [9.2.90.19]) by mailhub1.watson.ibm.com (8.7.1/10-03-96) with SMTP id TAA183263; Tue, 8 Oct 1996 19:54:29 -0400 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA31029; Tue, 8 Oct 1996 19:54:28 -0400 From: Uri Blumenthal Message-Id: <9610082354.AA31029@hawpub.watson.ibm.com> Subject: Re: Short keys * Options, combinations, and negotiations => simplicity To: "Theodore Y. Ts'o" Date: Tue, 8 Oct 1996 19:54:28 -0400 (EDT) Cc: ipsec@TIS.COM In-Reply-To: <9610082347.AA23159@dcl.MIT.EDU> from "Theodore Y. Ts'o" at Oct 8, 96 07:47:42 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk Theodore Y. Ts'o says: > I don't remember exactly, but if memory serves me, there is one more > mode, that Eli thinks secure...Checking his home page would be useful. > The paper: "Cryptanalysis of multiple modes" or such. > Eli's home page is: http://www.cs.technion.ac.il/~biham/ Yes, thanks! > The paper in question ("On Modes of Operations", published in the > proceedings of Fast Software Encryption 1) can be found as: > http://www.cs.technion.ac.il/~biham/Reports/onmodes.ps.gz I doubt it, as his latest results were published less than a week ago (PragoCrypt'96). -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- Received: from relay.hq.tis.com by neptune.TIS.COM id aa09564; 8 Oct 96 19:58 EDT Received: by relay.hq.tis.com; id UAA07412; Tue, 8 Oct 1996 20:02:51 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma007406; Tue, 8 Oct 96 20:02:22 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id UAA04094 for ; Tue, 8 Oct 1996 20:00:42 -0400 (EDT) Received: by relay.hq.tis.com; id UAA07402; Tue, 8 Oct 1996 20:02:21 -0400 Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1.1) id xma007400; Tue, 8 Oct 96 20:01:59 -0400 Received: from [128.89.30.9] (ARA9.BBN.COM [128.89.30.9]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id UAA18681; Tue, 8 Oct 1996 20:03:57 -0400 (EDT) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 8 Oct 1996 20:05:33 -0500 To: John Gilmore From: Stephen Kent Subject: Re: Short keys * Options, combinations, and negotiations => simplicity Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk John, I agree with some, but not all, of your comments. My goal in working with Ran on all three of the IPsec top level documents (the architecture, AH and ESP specs) is to unify and simplify the set of documentation. This should improve readibility and make it easier to document and to add new algorithms, which I believe is a generally good thing. I also want to ensure that compliant implementations incorporate a set of capabilities that make them generally useful (not unduly constrained) and manageable. I agree, though, that even if it is easy to document new algorithms or modes or security features, that does not mean that one should proliferate such combinations of options needlessly. The usual approach in these sorts of situations is to define a mandatory, minimum set of features that all implementations must include (even if they are not always invoked), to facilitate interoperability. Then additional features may be defined and implemented by some, but not all, vendors. There is clearly an element of value judgement in selecting the required feature list, and we have had that discussion in part before, but it's not really done yet. Finally, given the move to unify the various transform definitions in ESP and AH, we don't need a 3DES-HMAC-AR transform. We need a 3DES description and an HMAC description (with you choice of hash functions). The AR feature will be defined in ESP and AH as an option. I do not agree with what I interpret as your suggestion that 3DES (vs. DES) become the default encryption algorithm. The IAB memo on crypto policy does not strike me as mandating such. Moreover, in selecting any safeguard, one must balance percieved threats against costs. While you clearly precieve NSA as a threat, I don't find that most of my commercial clients share that view. They are more concerned about hackers, criminals, and other adversaries for whom DES is a reasonable countermeasure. Moreover, a balanced security design does not incorporate very strong measures in some areas while leaving gaping holes in other areas. If we were to mandate 3DES for IPsec, this would generally be inconsistent with the environments in which the technlogy will be used (e.g., software crypto, pseudo-RNGs, COTS OSs like most Unix and Windows platforms, etc.). Providing a 3DES option for those users who do percieve a threat for which this algorithm and key size are appropriate, and for which the complementary security safeguards are consistent, is an appropriate means of accommodating a range of user requirements in a standard protocol. Steve Received: from relay.hq.tis.com by neptune.TIS.COM id aa09805; 8 Oct 96 20:15 EDT Received: by relay.hq.tis.com; id UAA07630; Tue, 8 Oct 1996 20:19:51 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma007628; Tue, 8 Oct 96 20:19:24 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id UAA04360 for ; Tue, 8 Oct 1996 20:17:43 -0400 (EDT) Received: by relay.hq.tis.com; id UAA07618; Tue, 8 Oct 1996 20:19:22 -0400 Received: from dns1.noc.best.net(206.86.8.69) by relay.tis.com via smap (V3.1.1) id xma007612; Tue, 8 Oct 96 20:19:20 -0400 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns1.noc.best.net (8.6.12/8.6.5) with ESMTP id QAA22902; Tue, 8 Oct 1996 16:35:15 -0700 Received: from bill.scli.com ([206.79.9.161]) by shellx.best.com (8.6.12/8.6.5) with SMTP id QAA20362; Tue, 8 Oct 1996 16:34:58 -0700 Received: by bill.scli.com with Microsoft Mail id <01BBB536.8DD49000@bill.scli.com>; Tue, 8 Oct 1996 16:34:19 -0700 Message-ID: <01BBB536.8DD49000@bill.scli.com> From: Bill Hunt To: Ben Stoltz , "'Jeffrey I. Schiller'" Cc: "ipsec@TIS.COM" , Hilarie Orman , "wu@csc.ncsu.edu" Subject: RE: Deafening Silence Date: Tue, 8 Oct 1996 16:34:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk Jeff, Your statement leaves me confused, as I read your original decision exactly as Ben did. I would appreciate a clarification: If SKIP and ISAKMP/Oakley are optional and appropriate for use with IPv4, and both are to be pursued as IETF standards, what do you mean that they are not on equal footing? Bill ipsec-approval@neptune.tis.com said: > I thought Schiller has made a decision about key management for this > working group: ISAKMP/OAKLEY will be the mandatory one. Under this > situation, I think that it is clear that in December meeting we > should focus (in a higher priority at least) on the ISAKMP/OAKLEY > proposal. > > -Felix wu@csc.ncsu.edu ---------- From: Jeffrey I. Schiller[SMTP:jis@mit.edu] Sent: Tuesday, October 08, 1996 12:37 PM To: Ben Stoltz Cc: ipsec@TIS.COM; Hilarie Orman; wu@csc.ncsu.edu Subject: Re: Deafening Silence Ben Stoltz wrote: > Please take a closer look at Schiller's note. > ISAKMP/OAKLEY is only mandatory for IPv6. ISAKMP/Oakley and SKIP are > on an equal footing for IPv4. ISAKMP/Oakley is mandatory for IPv6 because only in IPv6 is IPSEC mandatory. It isn't completely clear what mandatory would mean in the IPv4 context (though I can think of some interpretations). However I think you go to far to say that ISAKMP/Oakley and SKIP are on equal footing. They are not. It is important that the working group complete the work on ISAKMP/Oakley so we have a deployable solution for IPv6 and for IPv4. Received: from relay.hq.tis.com by neptune.TIS.COM id aa10340; 8 Oct 96 20:52 EDT Received: by relay.hq.tis.com; id UAA08058; Tue, 8 Oct 1996 20:56:51 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma008056; Tue, 8 Oct 96 20:56:32 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id UAA04914 for ; Tue, 8 Oct 1996 20:54:42 -0400 (EDT) Received: by relay.hq.tis.com; id UAA08048; Tue, 8 Oct 1996 20:56:21 -0400 Received: from custmail.internex.net(199.2.14.213) by relay.tis.com via smap (V3.1.1) id xma008044; Tue, 8 Oct 96 20:55:59 -0400 Received: from cixgate ([192.156.136.10]) by custmail.InterNex.Net (8.7.1/8.7.1) with SMTP id RAA01486 for ; Tue, 8 Oct 1996 17:58:10 -0700 (PDT) Received: from gw.3Com.COM by cixgate (4.1/SMI-4.1/3com-cixgate-GCA-931027-01) id AA11078; Tue, 8 Oct 96 18:10:48 PDT Received: from hqsmtp2.OPS.3Com.COM by gw.3Com.COM with SMTP id AA16558 (5.65c/IDA-1.4.4 for ); Tue, 8 Oct 1996 17:58:06 -0700 Received: by hqsmtp2.ops.3com.com (IBM OS/2 SENDMAIL VERSION 1.3.17/1.0) id AA3602; Tue, 08 Oct 96 18:03:42 -0700 Message-Id: <9610090103.AA3602@hqsmtp2.ops.3com.com> Received: by 3Com (Lotus Notes Mail Gateway for SMTP V1.1) id F1D42FB516520FD8882563BE000407B4; Tue, 8 Oct 96 18:03:35 EDT To: Uri Blumenthal Cc: "Theodore Y. Ts'o" , ipsec From: Dan Nessett/HQ/3Com Date: 8 Oct 96 17:56:18 EDT Subject: Re: Short keys * Options, combinations, and negotiations => simplicity Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipsec-approval@neptune.tis.com Precedence: bulk The URL to the paper "Cryptanalysis of Triple-Modes of Operation," by Eli Biham, which discusses why other triple-mode uses of blockciphers are less secure than ECB-ECB-ECB is : http://www.cs.technion.ac.il/~biham/Reports/cs885.ps.gz Dan Received: from relay.hq.tis.com by neptune.TIS.COM id aa11162; 8 Oct 96 21:54 EDT Received: by relay.hq.tis.com; id VAA08593; Tue, 8 Oct 1996 21:57:51 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xmaa08588; Tue, 8 Oct 96 21:57:27 -0400 Received: from sol.hq.tis.com. (sol [10.33.1.100]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id VAA05632 for ; Tue, 8 Oct 1996 21:55:46 -0400 (EDT) Received: from la.tis.com (scintillate.la.tis.com) by sol.hq.tis.com. sol.hq.tis.com (4.1/SMI-4.1) id AA16337; Tue, 8 Oct 96 21:59:25 EDT Received: from relay.la.tis.com by la.tis.com (4.1/SUN-5.64) id AA08210; Tue, 8 Oct 96 18:57:36 PDT Received: by relay.la.tis.com; id SAA13827; Tue, 8 Oct 1996 18:52:33 -0700 Received: from unknown(192.43.161.5) by relay.la.tis.com via smap (V3.1.1) id xma013825; Tue, 8 Oct 96 18:52:20 -0700 Received: from cylink by defender.cylink.com with smtp (Smail3.1.29.1 #4) id m0vAnkC-0007DEC; Tue, 8 Oct 96 18:47 PDT Received: from kennedy ([205.226.80.185]) by cylink (4.1/SMI-4.1) id AA14881; Tue, 8 Oct 96 18:56:08 PDT Date: Tue, 8 Oct 96 18:56:08 PDT Message-Id: <9610090156.AA14881@cylink> From: John Kennedy To: kent@bbn.com, gnu@toad.com, lattin@cylink.com Subject: Triple DES, Diffie-Hellman, and ECDSA Cc: ipsec@TIS.COM X-Mailer: Pronto E-Mail [version 2.01] Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk Just wanted to jump in and mention that ANSI X9.F1 voted last week to send X9.42 (Diffie-Hellman), X9.52 (Triple DES Modes), and X9.62 (Elliptic Curve Digital Signature Algorithm - ECDSA) to ballot after some relatively minor editorial changes are made. All three documents have come a long way since their inception and are quite mature at this point. Since the IPSEC group seems to be searching for definitive documents on Diffie-Hellman and Triple-DES in particular, I strongly encourage interested parties to take a look at these documents before trying to re-invent the wheel. X9.62 - ECDSA is an elliptic curve version of the NIST Digital Signature Standard. Both X9.42 and X9.62 are closely aligned to parallel work going on in IEEE P1363. Contact information: X9.42 (Diffie-Hellman): John Kennedy, jkennedy@cylink.com X9.52 (Triple DES): Bill Lattin, lattin@cylink.com X9.62 (ECDSA): Don Johnson, djohnson@certicom.ca Regards, -John Kennedy, jkennedy@cylink.com Date: Tue, 8 Oct 1996 19:47:42 -0400 Message-Id: <9610082347.AA23159@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: uri@watson.ibm.com Cc: Steven Bellovin , ipsec@TIS.COM In-Reply-To: Uri Blumenthal's message of Tue, 8 Oct 1996 18:50:13 -0400 (EDT), <9610082250.AA18537@hawpub.watson.ibm.com> Subject: Re: Short keys * Options, combinations, and negotiations => simplicity Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: ipsec-approval@neptune.tis.com Precedence: bulk From: Uri Blumenthal Date: Tue, 8 Oct 1996 18:50:13 -0400 (EDT) I don't remember exactly, but if memory serves me, there is one more mode, that Eli thinks secure...Checking his home page would be useful. The paper: "Cryptanalysis of multiple modes" or such. Eli's home page is: http://www.cs.technion.ac.il/~biham/ The paper in question ("On Modes of Operations", published in the proceedings of Fast Software Encryption 1) can be found as: http://www.cs.technion.ac.il/~biham/Reports/onmodes.ps.gz - Ted Message-Id: <199610090225.WAA13952@raptor.research.att.com> To: Stephen Kent cc: John Gilmore , ipsec@TIS.COM Subject: Re: Short keys * Options, combinations, and negotiations => simplicity Date: Tue, 08 Oct 1996 22:25:53 -0400 From: Steven Bellovin Sender: ipsec-approval@neptune.tis.com Precedence: bulk I do not agree with what I interpret as your suggestion that 3DES (vs. DES) become the default encryption algorithm. The IAB memo on crypto policy does not strike me as mandating such. Moreover, in selecting any safeguard, one must balance percieved threats against costs. This is a crucial point. I agree that 3DES is too expensive to be the default transform. I also agree that the IAB had no intention of mandating such a move, and I was one of the authors of the statement. On the other hand, I didn't read John's note as suggesting it, either; rather (and this may be based on prior conversations with him), he was suggesting a mandatory-to-implement 3DES transform, so that people who want it will have it. John -- what did you mean? Received: from relay.hq.tis.com by neptune.TIS.COM id aa28212; 9 Oct 96 16:05 EDT Received: by relay.hq.tis.com; id QAA00733; Wed, 9 Oct 1996 16:09:01 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma000712; Wed, 9 Oct 96 16:08:33 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id QAA26245 for ; Wed, 9 Oct 1996 16:06:50 -0400 (EDT) Received: by relay.hq.tis.com; id QAA00699; Wed, 9 Oct 1996 16:08:31 -0400 Received: from chirality.rsa.com(192.80.211.33) by relay.tis.com via smap (V3.1.1) id xma000671; Wed, 9 Oct 96 16:08:13 -0400 Received: from lobester.rsa.com by RSA.COM with SMTP id AA29252; Wed, 9 Oct 96 13:11:25 PDT Received: by LOBESTER.rsa.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BBB5E3.4DC12D90@LOBESTER.rsa.com>; Wed, 9 Oct 1996 13:10:54 -0700 Message-Id: From: Bob Baldwin To: 'IPSec' Subject: ESP with long keys Date: Wed, 9 Oct 1996 13:10:53 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk Here is some information for people who want to make ESP transforms with long keys. In the Spring of '96 Brett Howard and I wrote an ESP based on RC5 that includes both a 128 bit and a 40 bit key version. This was submitted as an Internet draft and is also available at the URL below. It was based on the Spring ESP format. ftp://ftp.rsa.com/pub/rc5/draft-rsadsi-esp-rc5-00.txt The companion RFC, which defines RC5 in sufficient detail to guarantee interoperability, was also submitted as an Internet draft and is currently being upgraded to an Informational RFC. It can be found on the IETF sites or: ftp://ftp.rsa.com/pub/rc5/draft-rsadsi-rc5-00.txt Any feedback on these would be quite welcome. --Bob Received: from relay.hq.tis.com by neptune.TIS.COM id aa01594; 9 Oct 96 18:52 EDT Received: by relay.hq.tis.com; id SAA06529; Wed, 9 Oct 1996 18:56:09 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma006518; Wed, 9 Oct 96 18:55:40 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id SAA03139 for ; Wed, 9 Oct 1996 18:53:58 -0400 (EDT) Received: by relay.hq.tis.com; id SAA06508; Wed, 9 Oct 1996 18:55:39 -0400 Received: from ftp.com(128.127.2.122) by relay.tis.com via smap (V3.1.1) id xma006501; Wed, 9 Oct 96 18:55:09 -0400 Received: from ftp.com by ftp.com ; Wed, 9 Oct 1996 18:57:25 -0400 Received: from mailserv-2high.ftp.com by ftp.com ; Wed, 9 Oct 1996 18:57:25 -0400 Received: from cascade.ftp.com by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id SAA08921; Wed, 9 Oct 1996 18:57:17 -0400 Message-Id: <199610092257.SAA08921@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM Priority: Normal To: ipsec@TIS.COM X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: John T O'Hara Subject: RE: Deafening Silence Date: Wed, 09 Oct 1996 19:03:09 -0400 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: quoted-printable Sender: ipsec-approval@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- There is a effort to get underway a ISAKMP-OAKLEY interoperability event se= t up for early January 1997. Details are being worked out now and will be = posted to the list. The current thought is to have a engineering focused e= vent centered on ISAKMP-OAKLEY interoperation where developers could work o= ut the kinks. Perhaps other areas in IPSEC could also be covered time and i= nterest permiting. It would seem to be a good time to start working on a update of the ISAKMP-= OAKLEY implementation draft. How do people feel about the current state of = the draft ?. What are the open issues ?. What else needs to get nailed dow= n in time for a Jan/97 testathon ?. Comments, suggestions ? John O'Hara FTP Software, Inc. 508 684 6247 -----BEGIN PGP SIGNATURE----- Version: 2.9 iQCVAgUBMlwuCi/CgyjmiURDAQFkiAP/b8mIH8guYCfspRjc3Bw/upe9R/Cf3WCG FlqK0C/XPLfyHtZDB33k6gFFPN7PqT5ql2UYsBpHdnLlcYLtpBiDaiqcLLH0h/Ys 0LjX4jxR8+nCeWzSCW+s+d/dE7e5AAfXxad9I37orbaWwfa3QozIuMYXZy3XEjlZ opv42bwPrHM=3D =3DovXV -----END PGP SIGNATURE----- Received: from relay.hq.tis.com by neptune.TIS.COM id aa06262; 9 Oct 96 23:55 EDT Received: by relay.hq.tis.com; id XAA10631; Wed, 9 Oct 1996 23:59:44 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma010627; Wed, 9 Oct 96 23:59:15 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id XAA08416 for ; Wed, 9 Oct 1996 23:57:30 -0400 (EDT) Received: by relay.hq.tis.com; id XAA10623; Wed, 9 Oct 1996 23:59:14 -0400 Received: from p-spatsch.cs.arizona.edu(150.135.1.98) by relay.tis.com via smap (V3.1.1) id xma010616; Wed, 9 Oct 96 23:58:46 -0400 Received: from localhost (spatsch@localhost) by P-spatsch.cs.arizona.edu (8.6.12/8.6.9) with SMTP id UAA13437; Wed, 9 Oct 1996 20:59:22 -0700 X-Authentication-Warning: P-spatsch.cs.arizona.edu: spatsch owned process doing -bs Date: Wed, 9 Oct 1996 20:59:19 -0700 (MST) From: Oliver Spatscheck To: John T O'Hara cc: ipsec@TIS.COM Subject: RE: Deafening Silence In-Reply-To: <199610092257.SAA08921@MAILSERV-2HIGH.FTP.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- > > There is a effort to get underway a ISAKMP-OAKLEY interoperability > event set > up for early January 1997. Details are being worked out now and > will > be posted to the list. The current thought is to have a engineering > focused event centered on ISAKMP-OAKLEY interoperation where > developers could work out the kinks. Perhaps other areas in IPSEC > could also be covered time and interest permiting. > I would be curious to know who is implementing ISAKMP/Oakley at this point (who could interoperate in Jan/97)? I know about CISCO which implemented an EXTREMELY cut down ISAKMP/Oakley version which does not support the general framework very well. Using the name draft-ietf-ipsec-isakmp-oakley is kind of misleading, I think. I agree with an earlier posting, that the required ISAKMP/Oakley part has to be smaller than the whole framework. But I think there are ways to restrict ISAKMP/Oakley without unnecessarily complicating the not required case. The DOD implemented ISAKMP (Did they also do Oakley?). I implemented a key exchange framework which should handle the complete ISAKMP/Oakley framework. At this point, however, my implementation is still too unstable to be released to the general public and incomplete in a sense that not all features are implemented at this point. I also think that the drafts are not concrete enough so that 2 implementer would come up with interoperable implementations. (I mean the ISAKMP and Oakley drafts not the draft-ietf-ipsec-isakmp-oakley.) I am working on a more detailed list of comments. I already mentioned some of the bugs on this or the isakmp oakley mailing list and a fix was promised for the next draft. Which drafts are considered as standards? I hope the ISAKMP and the Oakley draft NOT the draft-ietf-ipsec-isakmp-oakley. Oliver -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBMlx0mTnVPgUZ7uZJAQGBHwP+NOT3qcG4TUUDYY+x8x5TT34gSYvXetdQ leDwGZzfKFBGwCdB4O9mEbTOAOND1dphTIcJcxWk/ObjGKkeaDKMC8hJckfQRFIM 3f3FkKYV3gKagWMF2GCYcdo+KqLhgdz9DnoluMI0fBIo3ipA5Advo3BWlcgBvIox I26Hc3h18Kw= =VhQ4 -----END PGP SIGNATURE----- Received: from relay.hq.tis.com by neptune.TIS.COM id aa18579; 10 Oct 96 13:34 EDT Received: by relay.hq.tis.com; id NAA07699; Thu, 10 Oct 1996 13:38:28 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma007677; Thu, 10 Oct 96 13:38:05 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id NAA08774 for ; Thu, 10 Oct 1996 13:36:16 -0400 (EDT) Received: by relay.hq.tis.com; id NAA07666; Thu, 10 Oct 1996 13:37:58 -0400 Received: from ftp.com(128.127.2.122) by relay.tis.com via smap (V3.1.1) id xma007639; Thu, 10 Oct 96 13:37:35 -0400 Received: from ftp.com by ftp.com ; Thu, 10 Oct 1996 13:39:51 -0400 Received: from mailserv-2high.ftp.com by ftp.com ; Thu, 10 Oct 1996 13:39:51 -0400 Received: from cascade.ftp.com by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id NAA09842; Thu, 10 Oct 1996 13:39:43 -0400 Message-Id: <199610101739.NAA09842@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM Priority: Normal To: ipsec@TIS.COM X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: John T O'Hara Subject: RE: Deafening Silence Date: Thu, 10 Oct 1996 13:45:36 -0400 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: quoted-printable Sender: ipsec-approval@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Oliver, >I would be curious to know who is implementing ISAKMP/Oakley >at this point (who could interoperate in Jan/97)? We, FTP Software, will certainly be aiming for it. Comments from others wel= come here. I think that the ISAKMP/OAKLEY draft was a first cut and that it's not enou= gh for developers to implement from. The reason I suggested that we start d= iscussing the draft was to elicit comments from the community, and pehaps t= o have either the original authors of the draft or a interested third party= voluteer to edit the draft for ISAKMP/OAKLEY testathon use. Without a more complete implementation draft I would venture to say that a = testathon would not be as productive. I would recommend that discussions of= the draft stay on this list for a while due to the wider audience. John O'Hara >I know about CISCO which implemented an EXTREMELY cut down >ISAKMP/Oakley version which does not support the general framework >very well. Using the name draft-ietf-ipsec-isakmp-oakley is kind of >misleading, I think. I agree with an earlier posting, that the >required ISAKMP/Oakley part has to be smaller than the whole >framework. But I think there are ways to restrict ISAKMP/Oakley >without unnecessarily complicating the not required case. >The DOD implemented ISAKMP (Did they also do Oakley?). >I implemented a key exchange framework which should handle the >complete ISAKMP/Oakley framework. At this point, however, my >implementation is still too unstable to be released to the general >public and incomplete in a sense that not all features are implemented >at this point. >I also think that the drafts are not concrete enough so that 2 >implementer would come up with interoperable implementations. >(I mean the ISAKMP and Oakley drafts not the >draft-ietf-ipsec-isakmp-oakley.) >I am working on a more detailed list of comments. I already mentioned >some of the bugs on this or the isakmp oakley mailing list and a fix >was promised for the next draft. >Which drafts are considered as standards? I hope the ISAKMP and the >Oakley draft NOT the draft-ietf-ipsec-isakmp-oakley. >Oliver -----BEGIN PGP SIGNATURE----- Version: 2.9 iQCVAgUBMl02Mi/CgyjmiURDAQFGqgP+M9oK1psQGflMeLPM0eVIbv/F/iUeEQRP AVcE7qW22y01G+5DdWRhp1WB0ImI4kfndN1nJomSq23lm8VL+Bc8cmGNZ9qusVWM yCVNB9YGqovc/rVOLt5NRUyfvnYAKVqj6ShcPIzmMehph2NgtHwf6bMjyEmNCZk0 6/8rXYG5TsY=3D =3DnNFS -----END PGP SIGNATURE----- Received: from relay.hq.tis.com by neptune.TIS.COM id aa19237; 10 Oct 96 14:14 EDT Received: by relay.hq.tis.com; id OAA09883; Thu, 10 Oct 1996 14:18:28 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma009821; Thu, 10 Oct 96 14:18:05 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id OAA11966 for ; Thu, 10 Oct 1996 14:16:15 -0400 (EDT) Received: by relay.hq.tis.com; id OAA09795; Thu, 10 Oct 1996 14:17:58 -0400 Received: from p-spatsch.cs.arizona.edu(150.135.1.98) by relay.tis.com via smap (V3.1.1) id xma009780; Thu, 10 Oct 96 14:17:40 -0400 Received: from localhost (spatsch@localhost) by P-spatsch.cs.arizona.edu (8.6.12/8.6.9) with SMTP id LAA00228; Thu, 10 Oct 1996 11:17:42 -0700 X-Authentication-Warning: P-spatsch.cs.arizona.edu: spatsch owned process doing -bs Date: Thu, 10 Oct 1996 11:17:40 -0700 (MST) From: Oliver Spatscheck To: Ran Atkinson cc: spatsch@optima.cs.arizona.edu, ipsec@TIS.COM Subject: Re: Deafening Silence In-Reply-To: <199610101717.KAA06479@cornpuffs.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Ran wrote: > >>I also think that the drafts are not concrete enough so that 2 >>implementer would come up with interoperable implementations. > > You make a strong bold claim. However, there is an existence proof to >the contrary since interoperability of independently-written implementations >has ALREADY been shown. For example, the DRA/Malvern implementation written >against isakmp-04 talked fine with the cisco UNIX implementation written >against isakmp-04. There can be no doubt that the ISAKMP and ISAKMP-Oakley >specifications are sufficiently concrete to implement. All the details are >there, including all of the magic numbers, in a clean easily-read format. > Correct me if I am wrong but the CISCO implementation only covers the draft-ietf-ipsec-oakley written by CISCO . An EXTREME subset of the complete ISAKMP and OAKLEY drafts. Is that the required subset ?? Why? Don't misunderstand me again. I don't claim you can't write interoperable implementations of the subset defined in draft-ietf-ipsec-oakley or in ISAKMP-05. I claim you have problems if you try to combine the ISAKMP-05 and the complete OAKLEY draft. Who is implementing that? Why I think the drafts are not concrete enough? Only two examples: - - The latest Oakley draft doesn't match the ISAKMP payload formats. - - The ISAKMP draft 5 doesn't define the IP DOI completely. All this are not major problems, but they need fixing. Again if the consent of the working group is to use the EXTREMELY cut down draft-ietf-ipsec-oakley please somebody let me know.... . Oliver -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBMl09xTnVPgUZ7uZJAQEMEwQApJjvNWmGlhbuIkVyW1VdbmuaTKY2LB0x etOQAiNWxAFg7Mkb9N2HKljsRwtaV69ut7riIOqMZd/U5IUhy7TwL1/aMpOsnuUW xCLgssEmFSC/13MQzPgEU4pOfLxK2rIP3l2l5ecOplH3tc15GeHHTSQL5l3NhIzO foF2aLsj0wo= =V06S -----END PGP SIGNATURE----- Date: Thu, 10 Oct 1996 10:17:21 -0700 From: Ran Atkinson Message-Id: <199610101717.KAA06479@cornpuffs.cisco.com> To: spatsch@cs.arizona.edu Subject: Re: Deafening Silence In-Reply-To: References: <199610092257.SAA08921@MAILSERV-2HIGH.FTP.COM> Organization: cisco Systems Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk In article , Oliver wrote: >I would be curious to know who is implementing ISAKMP/Oakley >at this point (who could interoperate in Jan/97)? As I understand it, cisco has 4 distinct implementations (PIX, TGV, IOS, and the freely distributable UNIX implementation). The PIX (in Palo Alto) and TGV (in Santa Cruz) and IOS (in San Jose) parts of cisco are logically/administratively and geographically separate, with separate staff. It is not clear to me that the 4 implementations are related or able to share code. In particular, IOS is very significantly different from UNIX and so it is not generally feasible to port any UNIX code into IOS. There are several other vendors (e.g. ftp Software, Timestep) working on ISAKMP/Oakley code. The auto industry has sent a very clear signal to vendors about what key management products they plan to purchase (i.e. ISAKMP/Oakley) and the auto industry purchases a lot of product, so firms that are trying to make money rather than have technical religion will probably be shipping ISAKMP/Oakley products in the near-term. I would guess that most UNIX vendors will be using code derived from the freely-distributable cisco ikmpd(8) implementation on their boxes. My understanding has been that DRA/Malvern (UK) is working on updating their implementation to match the most recent I-Ds. Elfed Weaver has indicated on this list in the past that DRA/Malvern's implementation is intended to become freely distributable in future (note that it is also a non-US implementation). I hear word of an implementation in progress built against PF_KEY underway within the Asia/Pacific region as well. The US DoD has their own implementation and should be ready by January (NB: their publically release code might be a subset of their total in-house code, but it is still an independent implementation). There is active discussion of testing ISAKMP/Oakley and IPsec as part of this December's IPv6 testing at UNH. In particular, Digital has been vocally advocating this. I anticipate that other UNIX vendors will also have IPsec for IPv6 and ISAKMP/Oakley ready by the next UNH session. So let's count up the math. 4 + 2 + 1 + 1 + 1 = 9. So I'd say that roughly 9 distinct implementations will probably be testable in the January 1996 timeframe. Several are being tested in the very near term within the RSADSI S/WAN activity. Others will probably be tested in December at UNH as part of IPv6 testing. >I also think that the drafts are not concrete enough so that 2 >implementer would come up with interoperable implementations. You make a strong bold claim. However, there is an existence proof to the contrary since interoperability of independently-written implementations has ALREADY been shown. For example, the DRA/Malvern implementation written against isakmp-04 talked fine with the cisco UNIX implementation written against isakmp-04. There can be no doubt that the ISAKMP and ISAKMP-Oakley specifications are sufficiently concrete to implement. All the details are there, including all of the magic numbers, in a clean easily-read format. Best regards, Ran rja@cisco.com Received: from relay.hq.tis.com by neptune.TIS.COM id aa20911; 10 Oct 96 16:09 EDT Received: by relay.hq.tis.com; id QAA15743; Thu, 10 Oct 1996 16:12:59 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma015723; Thu, 10 Oct 96 16:12:37 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id QAA19353 for ; Thu, 10 Oct 1996 16:10:49 -0400 (EDT) Received: by relay.hq.tis.com; id QAA15713; Thu, 10 Oct 1996 16:12:29 -0400 Received: from p-spatsch.cs.arizona.edu(150.135.1.98) by relay.tis.com via smap (V3.1.1) id xma015680; Thu, 10 Oct 96 16:12:01 -0400 Received: from localhost (spatsch@localhost) by P-spatsch.cs.arizona.edu (8.6.12/8.6.9) with SMTP id NAA00444; Thu, 10 Oct 1996 13:12:23 -0700 X-Authentication-Warning: P-spatsch.cs.arizona.edu: spatsch owned process doing -bs Date: Thu, 10 Oct 1996 13:12:20 -0700 (MST) From: Oliver Spatscheck To: Ran Atkinson cc: Oliver Spatscheck , ipsec@TIS.COM Subject: Re: Deafening Silence In-Reply-To: <199610101949.MAA08333@cornpuffs.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Thu, 10 Oct 1996, Ran Atkinson wrote: >On Oct 10, 11:17am, Oliver Spatscheck wrote: > >% Correct me if I am wrong but the CISCO implementation only covers >% the draft-ietf-ipsec-oakley written by CISCO. > >Wrong on two counts. > >Firstly, more than one cisco implementation exists, as I explained >in my previous note. Sorry for using the singular. > >Secondly, it is my understanding that the UNIX implementation that you refer >to implements more than is in the isakmp-oakley resolution draft (and, no, >I haven't looked at the source code myself because I'm too busy with IPv6 >coding). > Could somebody speak up how they defined the payloads for Oakley in the implementation which covers more than the isakmp-oakley resolution draft? As mentioned earlier the definitions in the Oakley draft are obsolete. I guess that would help fixing the Oakley draft. Oliver -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBMl1YpznVPgUZ7uZJAQFXXQP6AurRP1aVhrg2hlL1unDtzER6mRlXRmFE PNKjEXmTzZ3Ab31QZBL7ITYxNwQ2CbT8RywOXg/WRx7qpWQXRVzHUG8VS/0zNe4+ IviZgXtMUvDBIXGXh+4N6jImhEN0zGKfZbLhApmy3FYetG+nDldpY9PWFbyy6AsK k+Urj8kInkQ= =2X/a -----END PGP SIGNATURE----- Received: from relay.hq.tis.com by neptune.TIS.COM id aa22034; 10 Oct 96 17:28 EDT Received: by relay.hq.tis.com; id QAA17495; Thu, 10 Oct 1996 16:53:29 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma017493; Thu, 10 Oct 96 16:53:21 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id QAA21441 for ; Thu, 10 Oct 1996 16:50:48 -0400 (EDT) Received: by relay.hq.tis.com; id QAA17483; Thu, 10 Oct 1996 16:52:29 -0400 Received: from ns.newbridge.com(192.75.23.67) by relay.tis.com via smap (V3.1.1) id xma017481; Thu, 10 Oct 96 16:52:26 -0400 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id QAA01924 for ; Thu, 10 Oct 1996 16:54:41 -0400 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma001583; Thu Oct 10 16:53:30 1996 Received: from tsntsrv2.timestep.com ([192.168.219.191]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id QAA22888 for ; Thu, 10 Oct 1996 16:51:16 -0400 Received: by tsntsrv2.timestep.com with Microsoft Exchange (IMC 4.0.838.14) id <01BBB6CB.2CF74700@tsntsrv2.timestep.com>; Thu, 10 Oct 1996 16:50:43 -0400 Message-ID: From: Roy Pereira To: "'ipsec@TIS.COM'" , 'John T O'Hara' Subject: RE: Deafening Silence Date: Thu, 10 Oct 1996 16:50:36 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.838.14 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk TimeStep Corp. is currently developing the S/WAN toolkit and also an implementation of ISAKMP/Oakley that will utilize that toolkit. The current draft of both ISAKMP and Oakley do need to be edited and resubmitted, plugging up some holes that exist with identifiers and so forth... but they can be currently used to develop an implementation. For interoperability however, we, the mailing-list recipients, need to go over these drafts and bring up any concerns, comments or questions that we have so that the authors' next drafts will be good enough for interoperability. Roy >---------- >From: John T O'Hara[SMTP:johara@ftp.com] >Sent: Thursday, October 10, 1996 1:45 PM >To: ipsec@TIS.COM >Subject: RE: Deafening Silence > >-----BEGIN PGP SIGNED MESSAGE----- > > >Oliver, > >>I would be curious to know who is implementing ISAKMP/Oakley >>at this point (who could interoperate in Jan/97)? > >We, FTP Software, will certainly be aiming for it. Comments from others >welcome here. > >I think that the ISAKMP/OAKLEY draft was a first cut and that it's not >enough for developers to implement from. The reason I suggested that we >start discussing the draft was to elicit comments from the community, >and pehaps to have either the original authors of the draft or a >interested third party voluteer to edit the draft for ISAKMP/OAKLEY >testathon use. > >Without a more complete implementation draft I would venture to say >that a testathon would not be as productive. I would recommend that >discussions of the draft stay on this list for a while due to the wider >audience. > >John O'Hara > >>I know about CISCO which implemented an EXTREMELY cut down >>ISAKMP/Oakley version which does not support the general framework >>very well. Using the name draft-ietf-ipsec-isakmp-oakley is kind of >>misleading, I think. I agree with an earlier posting, that the >>required ISAKMP/Oakley part has to be smaller than the whole >>framework. But I think there are ways to restrict ISAKMP/Oakley >>without unnecessarily complicating the not required case. > >>The DOD implemented ISAKMP (Did they also do Oakley?). > >>I implemented a key exchange framework which should handle the >>complete ISAKMP/Oakley framework. At this point, however, my >>implementation is still too unstable to be released to the general >>public and incomplete in a sense that not all features are implemented >>at this point. > >>I also think that the drafts are not concrete enough so that 2 >>implementer would come up with interoperable implementations. >>(I mean the ISAKMP and Oakley drafts not the >>draft-ietf-ipsec-isakmp-oakley.) >>I am working on a more detailed list of comments. I already mentioned >>some of the bugs on this or the isakmp oakley mailing list and a fix >>was promised for the next draft. > >>Which drafts are considered as standards? I hope the ISAKMP and the >>Oakley draft NOT the draft-ietf-ipsec-isakmp-oakley. > > >>Oliver > > > Received: from relay.hq.tis.com by neptune.TIS.COM id aa22651; 10 Oct 96 18:01 EDT Received: by relay.hq.tis.com; id SAA19697; Thu, 10 Oct 1996 18:05:29 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma019694; Thu, 10 Oct 96 18:05:05 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id SAA24775 for ; Thu, 10 Oct 1996 18:03:16 -0400 (EDT) Received: by relay.hq.tis.com; id SAA19686; Thu, 10 Oct 1996 18:04:59 -0400 Received: from capone.ch.apollo.hp.com(15.254.24.3) by relay.tis.com via smap (V3.1.1) id xma019678; Thu, 10 Oct 96 18:04:49 -0400 Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id ; Thu, 10 Oct 1996 18:07:01 -0400 Received: from thunk (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.6.12/8.6.12) with ESMTP id PAA02146 for ; Thu, 3 Oct 1996 15:31:50 -0400 Message-Id: <199610031931.PAA02146@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: ipsec@TIS.COM Subject: Proposed changes to transform naming.. In-Reply-To: ipsec-request's message of Thu, 03 Oct 1996 08:02:56 -0400. Date: Thu, 03 Oct 1996 15:30:34 -0400 From: Bill Sommerfeld Sender: ipsec-approval@neptune.tis.com Precedence: bulk Note that there doesn't have to be a 1-1 mapping between the dispatch method used in an implementation and the "names" for the transforms. One reasonable way to implement may well be to have a vector of function pointers in the security association structure; since the "attributes" in question are static for the life of the SPI, you might as well instantiate a separate function for each different combination of sub-transform attributes you care about, plus a "generic" version which handles all the options. - Bill Received: from relay.hq.tis.com by neptune.TIS.COM id aa23242; 10 Oct 96 18:42 EDT Received: by relay.hq.tis.com; id SAA20531; Thu, 10 Oct 1996 18:46:29 -0400 From: pau@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma020528; Thu, 10 Oct 96 18:46:01 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id SAA25984 for ; Thu, 10 Oct 1996 18:44:15 -0400 (EDT) Received: by relay.hq.tis.com; id SAA20524; Thu, 10 Oct 1996 18:45:59 -0400 Received: from unknown(129.34.139.18) by relay.tis.com via smap (V3.1.1) id xma020521; Thu, 10 Oct 96 18:45:40 -0400 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id SAA17758; Thu, 10 Oct 1996 18:47:46 -0400 Received: from secpwr.watson.ibm.com (secpwr.watson.ibm.com [9.2.24.17]) by mailhub1.watson.ibm.com (8.7.1/10-03-96) with SMTP id SAA559067; Thu, 10 Oct 1996 18:47:42 -0400 Received: by secpwr.watson.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA23210; Thu, 10 Oct 1996 18:49:32 -0400 Date: Thu, 10 Oct 1996 18:49:32 -0400 Message-Id: <9610102249.AA23210@secpwr.watson.ibm.com> To: ipsec@TIS.COM, johara@ftp.com, spatsch@cs.arizona.edu Subject: RE: Deafening Silence Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Md5: gSI3rxrFR+zDBjkjdxuikQ== Sender: ipsec-approval@neptune.tis.com Precedence: bulk We are implementing ISAKMP/OAKLEY as well. But I do have some problems = in finding some "magic numbers". For example, when negotiating an ISAKMP = SA, you need to specify EHA; where are the numbers for E, H and A defined ? For E, how should we pad the data ? Also, when computing signature or hash for authentication, what kind of data encoding is used ? I mean, if nonce is an input to hash, do you = include only the nonce value or the entire ISAKMP nonce payload or ... ? Are such details specified any where ? Thank you. Regards, Pau-Chen > From: "John T O'Hara" > Subject: RE: Deafening Silence > Date: Thu, 10 Oct 1996 13:45:36 -0400 > Content-Type: text/plain; charset=3DUS-ASCII; X-MAPIextension=3D".TXT" > Content-Transfer-Encoding: quoted-printable > Sender: ipsec-approval@neptune.hq.tis.com > Precedence: bulk > Content-Length: 2453 > Status: RO >=20 > -----BEGIN PGP SIGNED MESSAGE----- >=20 >=20 > Oliver, >=20 > >I would be curious to know who is implementing ISAKMP/Oakley > >at this point (who could interoperate in Jan/97)? >=20 > We, FTP Software, will certainly be aiming for it. Comments from = others welcome here. >=20 > I think that the ISAKMP/OAKLEY draft was a first cut and that it's not = enough for developers to implement from. The reason I suggested that we = start discussing the draft was to elicit comments from the community, = and pehaps to have either the original authors of the draft or a = interested third party voluteer to edit the draft for ISAKMP/OAKLEY = testathon use. >=20 > Without a more complete implementation draft I would venture to say = that a testathon would not be as productive. I would recommend that = discussions of the draft stay on this list for a while due to the wider = audience. >=20 > John O'Hara >=20 > >I know about CISCO which implemented an EXTREMELY cut down > >ISAKMP/Oakley version which does not support the general framework > >very well. Using the name draft-ietf-ipsec-isakmp-oakley is kind of > >misleading, I think. I agree with an earlier posting, that the > >required ISAKMP/Oakley part has to be smaller than the whole > >framework. But I think there are ways to restrict ISAKMP/Oakley > >without unnecessarily complicating the not required case. >=20 > >The DOD implemented ISAKMP (Did they also do Oakley?). >=20 > >I implemented a key exchange framework which should handle the > >complete ISAKMP/Oakley framework. At this point, however, my > >implementation is still too unstable to be released to the general > >public and incomplete in a sense that not all features are = implemented > >at this point. >=20 > >I also think that the drafts are not concrete enough so that 2 > >implementer would come up with interoperable implementations. > >(I mean the ISAKMP and Oakley drafts not the > >draft-ietf-ipsec-isakmp-oakley.) > >I am working on a more detailed list of comments. I already mentioned > >some of the bugs on this or the isakmp oakley mailing list and a fix > >was promised for the next draft. >=20 > >Which drafts are considered as standards? I hope the ISAKMP and the > >Oakley draft NOT the draft-ietf-ipsec-isakmp-oakley. >=20 >=20 > >Oliver >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: 2.9 >=20 > iQCVAgUBMl02Mi/CgyjmiURDAQFGqgP+M9oK1psQGflMeLPM0eVIbv/F/iUeEQRP > AVcE7qW22y01G+5DdWRhp1WB0ImI4kfndN1nJomSq23lm8VL+Bc8cmGNZ9qusVWM > yCVNB9YGqovc/rVOLt5NRUyfvnYAKVqj6ShcPIzmMehph2NgtHwf6bMjyEmNCZk0 > 6/8rXYG5TsY=3D > =3DnNFS > -----END PGP SIGNATURE----- >=20 >=20 > Received: from relay.hq.tis.com by neptune.TIS.COM id aa23955; 10 Oct 96 19:21 EDT Received: by relay.hq.tis.com; id TAA21110; Thu, 10 Oct 1996 19:25:00 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma021097; Thu, 10 Oct 96 19:24:31 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id TAA26722 for ; Thu, 10 Oct 1996 19:22:45 -0400 (EDT) Received: by relay.hq.tis.com; id TAA21093; Thu, 10 Oct 1996 19:24:29 -0400 Received: from p-spatsch.cs.arizona.edu(150.135.1.98) by relay.tis.com via smap (V3.1.1) id xma021091; Thu, 10 Oct 96 19:24:22 -0400 Received: from localhost (spatsch@localhost) by P-spatsch.cs.arizona.edu (8.6.12/8.6.9) with SMTP id QAA00817; Thu, 10 Oct 1996 16:24:56 -0700 X-Authentication-Warning: P-spatsch.cs.arizona.edu: spatsch owned process doing -bs Date: Thu, 10 Oct 1996 16:24:53 -0700 (MST) From: Oliver Spatscheck To: Shawn Mamros cc: ipsec@TIS.COM, spatsch@optima.cs.arizona.edu Subject: Re: Deafening Silence In-Reply-To: <199610102136.RAA03403@MAILSERV-2HIGH.FTP.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In the following I included some comments to the current ISAKMP & Oakley draft. I encountered the problems while I was struggling to implement a full blown ISAKMP and Oakley key exchange engine. I might have mentioned some of the comments to the authors before. So forgive me if I am repeating them here. We schould also think about which part of ISAKMP and Oakley is required and which is optional. ISAKMP draft 5 ============== 2.2 - - The XCHG field is to small. If each Oakley exchange gets it's own XCHG number 8 Bit are not sufficient. 16 Bit seem OK to me. - - What is the correspondence between the XCHG filed in the ISAKMP header and the key exchange identifier in the ISAKMP proposal? Is the XCHG field only used for ISAKMP negotiation and the key exchange identifier (KEI) for any other negotiation? I think the XCHG field should determine processing. The key exchange identifier should determine the key exchange algorithm only like RSA, DH... . However then the Oakley Mode is not negotiable. 2.3 - - I think the table in this section is extremely confusing. Why don't we always use receiver SPI than sender SPI ? 2.3.1 - - I would strongly recommend that an ENVELOPE payload has to be used always. Except for DELETE, NOTIFY and CERTIFICATE payloads. This allows easier parsing and multiple exchanges in one message. (Combine ISAKMP with IPSEC SA negotiation to reduce the number of roundtrips for example) 2.4.1 - - I would allow that if only one proposal is made in a SA payload the message can be accompanied by other payloads . This allows for example to put a SA, ID, nonce and a key exchange payload in the same message as long as the payloads match the proposal. Reducing the number of roundtrips. (Something similar is proposed in the Oakley draft.) 2.4.2 - - Again I think Oakley is not a KEI it is a XCHG. 2.4.7 - - The phrase : " .......... If nonces are used by a particular key exchange, it is expected the nonces will be defined as part of the key exchange data and not transmitted as a separate payload. " is misleading. I would suggest that Oakley is using the nonce payload. 3.4 - - Why ISAKMP exchanges? I think they are all unnecessary. The Oakley exchanges can be use instead. - - The authentication only exchange is buggy. It does not protect against replay. IP DOI: - ---------- - - Define how the IPSEC SPI fits into the 8 Byte SPI field. - - Complete the missing chapter. Other: - - The TLV field has to be defined. Oakley draft 1 ============== Hashing and Signing: - -------------------- The current draft describes multiple examples of exchanges (aggressive, hidden identity, ...) However I have problems generalizing from this examples to what has to be hashed or signed. It would be extremely helpful if we could come up with a general simple rule what should be signed and state it. It would be also extremely helpful if we could come up with a rule from which state on a signature or hash payload has to be included. For example you have to sign data structure x after the following data is received .... . KEYID - ----- The KEYID generation has to be rethought. If a main mode ISAKMP exchange is performed within an ISAKMP SA the cookies for the ISAKMP SA are already used as KEYID for the ISAKMP SA key. Payloads - -------- The payload formats should be updated to ISAKMP draft 5 or whatever comes next. Oliver - ----- Grad student and research associate in computer science at the University of Arizona, Tucson, USA For my PGP public key please check my homepage URL: http://www.cs.arizona.edu/people/spatsch -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBMl2FxznVPgUZ7uZJAQGy1QQAoUjFiagMCarip2NBpJUbUYcbOjvA4UHo RbOLtxyhTgSoL+oL7xQgAj+os6+ASJmO1HC9toDzOx52mLt9WDP1twGCmvwHkYNN /IjYSEzoIqI5fex7ecl65jnYFqL/PCUe633ecHuUtcOkkNk8hSx1F7w7owwEraA9 NkuJeMFojmU= =DbbC -----END PGP SIGNATURE----- Date: Thu, 10 Oct 1996 17:36:04 -0400 Message-Id: <199610102136.RAA03403@MAILSERV-2HIGH.FTP.COM> To: ipsec@TIS.COM Subject: Re: Deafening Silence From: Shawn Mamros Reply-To: mamros@ftp.com Cc: rja@cisco.com, spatsch@cs.arizona.edu Repository: mailserv-2high.ftp.com, [message accepted at Thu Oct 10 17:35:59 1996] Originating-Client: cavedog.ftp.com Sender: ipsec-approval@neptune.tis.com Precedence: bulk First, a disclaimer of sorts: I am a relative newcomer to the IPSEC world (others here at FTP have been working in this area for quite a while), so I may not have a complete understanding of some of the issues here. But, as an implementor working for a company which would very much like to see ISAKMP/Oakley interoperability ASAP (and one which Ran cited in his message), I do have some serious concerns about the current state of the drafts and at least one reference implementation out there w.r.t. interoperability. If anyone could help clarify these for me, I'd be grateful. >>I also think that the drafts are not concrete enough so that 2 >>implementer would come up with interoperable implementations. > > You make a strong bold claim. However, there is an existence proof to >the contrary since interoperability of independently-written implementations >has ALREADY been shown. For example, the DRA/Malvern implementation written >against isakmp-04 talked fine with the cisco UNIX implementation written >against isakmp-04. There can be no doubt that the ISAKMP and ISAKMP-Oakley >specifications are sufficiently concrete to implement. All the details are >there, including all of the magic numbers, in a clean easily-read format. I don't doubt that this is true. However, I can't find a copy of the isakmp-04 draft anywhere. The current draft is isakmp-05. And, if I look at that draft, and then look at the isakmp-oakley-00 draft and the freely-distributable cisco UNIX implementation, I see a number of very crucial differences which are causing a lot of confusion for me as an implementor. Just one example (but perhaps the most crucial one): The isakmp-05 draft defines three exchange types which MUST be implemented, and the respective values which are used for them in the XCHG field of the ISAKMP header: Base (1), Identity Protection (2), and Authentication Only (3). The isakmp-oakley-00 draft makes no mention of the above three mandatory exchange types. Instead, it defines three of its own: Oakley Main Mode, Oakley Aggressive Mode, and Oakley Quick Mode. No values for the XCHG field are defined for these exchange types in this draft. The cisco UNIX implementation, which looks to be based largely on isakmp-oakley-00, only implements Oakley Main Mode and Oakley Quick Mode. Since Oakley Aggressive Mode is cited in the draft as a SHOULD but not a MUST, it looks like it complies with the requirements of isakmp-oakley-00. But, since it does not implement Base, Identity Protection, or Authentication Only exchanges, it cannot be considered compliant with the isakmp-05 draft, since those exchange types are MUSTs. Furthermore, the XCHG field values used in the implementation *directly conflict* with those in isakmp-05! (Oakley Main Mode is 1, Oakley Aggressive Mode is 2, and the unused-except-for-debugging-output Oakley New Group Mode is 3 - see the ikmpd/isakmp.h source file.) Clearly, this conflict MUST be resolved one way or another before we can ensure that implementations based on the current drafts are interoperable. From my (perhaps naive) analysis, Identity Protection and Oakley Main Mode look enough like one another that a merger of the two should be possible. The Base exchange and Oakley Aggressive Mode seem to be relatively close, in terms of the desired functionality, but I can't say for certain. Oakley Quick Mode, if it is needed (and currently no other exchange type in either draft provides for the exchange of IDui and IDur, so I believe it is) will almost certainly need a separate exchange type. Personally, I have neither the time nor the desire to get into wars over "technical (or any other type of) religion" - I want to make working code! But, if other vendors are going to be working from the cisco code as a base, I need to know that so that we can successfully interoperate with them come January. If, on the other hand, the isakmp-05 draft should be taken as "the truth", then the cisco implementation (and, for that matter, the isakmp-oakley-00 draft) needs to be brought in line, and other vendors need to be aware that that code is out of date BEFORE somebody decides to ship product based on it. (That sort of thing has happened before, countless times...) Let's not do battle over this - let's just make things work. I am more than willing to participate in discussion on these and other related issues, right out here in the open on the list, so that these conflicts can be resolved. And, if I am mistaken in anything I have said above, please enlighten me. -Shawn Mamros E-mail to: mamros@ftp.com From: Ran Atkinson Date: Thu, 10 Oct 1996 14:48:30 PDT In-Reply-To: mamros@ftp.com (Shawn Mamros) "Re: Deafening Silence" (Oct 10, 5:36pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: mamros@ftp.com, ipsec@TIS.COM Subject: Re: Deafening Silence Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9610110724.aa04588@neptune.TIS.COM> Shawn, The cisco ikmpd(8) software currently online predates the ISAKMP-05 draft. As with many protocols in the IETF (specifically including the several protocols within this working group), reference implementations tend to appear online somewhat after the drafts appear online. I would guess that most ISAKMP/Oakley discussions are probably occuring on the isakmp-oakley mailing list mentioned previously since the IPsec list has historically had a poor signal/noise ratio. Regards, Ran rja@cisco.com -- Message-Id: <3.0b34.32.19961011102018.00a36ea8@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0b34 (32) Date: Fri, 11 Oct 1996 11:00:35 -0400 To: John T O'Hara , ipsec@TIS.COM From: Robert Moskowitz Subject: RE: Deafening Silence Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 01:45 PM 10/10/96 -0400, John T O'Hara wrote: > >Without a more complete implementation draft I would venture to say that a testathon would not be as productive. I would recommend that discussions of the draft stay on this list for a while due to the wider audience. Please yes. Get going on this. We need this done in short order. Robert Moskowitz Chrysler Corporation (810) 758-8212 Message-Id: <3.0b34.32.19961011100736.00a36190@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0b34 (32) Date: Fri, 11 Oct 1996 11:00:33 -0400 To: Stephen Kent , John Gilmore From: Robert Moskowitz Subject: Re: Short keys * Options, combinations, and negotiations => simplicity Cc: ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 08:05 PM 10/8/96 -0500, Stephen Kent wrote: > >Moreover, in selecting any safeguard, one >must balance percieved threats against costs. While you clearly precieve >NSA as a threat, I don't find that most of my commercial clients share that >view. They are more concerned about hackers, criminals, and other >adversaries for whom DES is a reasonable countermeasure. Our industry has already faced government backed industrial espionage. Not NSA backed, but their competitors.... Robert Moskowitz Chrysler Corporation (810) 758-8212 Message-Id: <3.0b34.32.19961011095534.00a197d8@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0b34 (32) Date: Fri, 11 Oct 1996 11:00:29 -0400 To: "Jeffrey I. Schiller" , Ben Stoltz From: Robert Moskowitz Subject: Re: Deafening Silence Cc: ipsec@TIS.COM, Hilarie Orman , wu@csc.ncsu.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 03:37 PM 10/8/96 -0400, Jeffrey I. Schiller wrote: >Ben Stoltz wrote: >> Please take a closer look at Schiller's note. >> ISAKMP/OAKLEY is only mandatory for IPv6. ISAKMP/Oakley and SKIP are >> on an equal footing for IPv4. I got a real chuckle with this wordspinning... >ISAKMP/Oakley is mandatory for IPv6 because only in IPv6 is IPSEC >mandatory. It isn't completely clear what mandatory would mean in the >IPv4 context (though I can think of some interpretations). However I >think you go to far to say that ISAKMP/Oakley and SKIP are on equal >footing. They are not. It is important that the working group complete >the work on ISAKMP/Oakley so we have a deployable solution for IPv6 and >for IPv4. I want to see that new Oakley/ISAKMP draft this month! We need that so that we have Nov to go through it to finalize it for San Jose. Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.hq.tis.com by neptune.TIS.COM id aa08707; 11 Oct 96 11:31 EDT Received: by relay.hq.tis.com; id LAA09378; Fri, 11 Oct 1996 11:35:12 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma009356; Fri, 11 Oct 96 11:34:44 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id LAA23220 for ; Fri, 11 Oct 1996 11:32:55 -0400 (EDT) Received: by relay.hq.tis.com; id LAA09346; Fri, 11 Oct 1996 11:34:41 -0400 Received: from hubbub.cisco.com(198.92.30.31) by relay.tis.com via smap (V3.1.1) id xma009325; Fri, 11 Oct 96 11:34:17 -0400 Received: from spook (dharkins-ss20.cisco.com [171.69.60.241]) by hubbub.cisco.com (8.7.6/CISCO.GATE.1.1) with ESMTP id IAA24879; Fri, 11 Oct 1996 08:36:27 -0700 (PDT) Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by spook (8.6.8+c/CISCO.WS.1.1) with SMTP id IAA04163; Fri, 11 Oct 1996 08:36:58 -0700 Message-Id: <199610111536.IAA04163@spook> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: mamros@ftp.com Cc: ipsec@TIS.COM Subject: Re: Deafening Silence In-Reply-To: Your message of "Thu, 10 Oct 1996 17:36:04 EDT." <199610102136.RAA03403@MAILSERV-2HIGH.FTP.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 11 Oct 1996 08:36:58 -0700 From: Daniel Harkins Sender: ipsec-approval@neptune.tis.com Precedence: bulk Shawn, Your note is very timely. We've been working for the past few days to clean up the isakmp-oakley draft and bring it more in line with the main ISAKMP doc. Of course, code modifications will follow. > >>I also think that the drafts are not concrete enough so that 2 > >>implementer would come up with interoperable implementations. > > > > You make a strong bold claim. However, there is an existence proof to > >the contrary since interoperability of independently-written implementations > >has ALREADY been shown. For example, the DRA/Malvern implementation written > >against isakmp-04 talked fine with the cisco UNIX implementation written > >against isakmp-04. There can be no doubt that the ISAKMP and ISAKMP-Oakley > >specifications are sufficiently concrete to implement. All the details are > >there, including all of the magic numbers, in a clean easily-read format. > > I don't doubt that this is true. However, I can't find a copy of the > isakmp-04 draft anywhere. The current draft is isakmp-05. And, if I > look at that draft, and then look at the isakmp-oakley-00 draft and > the freely-distributable cisco UNIX implementation, I see a number of > very crucial differences which are causing a lot of confusion for me > as an implementor. Just one example (but perhaps the most crucial one): The interop tests we had with DRA/Malvern were at a time when 04 was the latest-and-greatest. When 05 came out we developed the reference implelentation. The code that interoperated with DRA was not the free code. > The cisco UNIX implementation, which looks to be based largely on > isakmp-oakley-00, only implements Oakley Main Mode and Oakley Quick Mode. > Since Oakley Aggressive Mode is cited in the draft as a SHOULD but not > a MUST, it looks like it complies with the requirements of isakmp-oakley-00. > But, since it does not implement Base, Identity Protection, or > Authentication Only exchanges, it cannot be considered compliant with > the isakmp-05 draft, since those exchange types are MUSTs. Furthermore, > the XCHG field values used in the implementation *directly conflict* > with those in isakmp-05! (Oakley Main Mode is 1, Oakley Aggressive Mode > is 2, and the unused-except-for-debugging-output Oakley New Group Mode > is 3 - see the ikmpd/isakmp.h source file.) Correct on both. The free code can not yet be declared as being truely ISAKMP compliant; and, the XCHG values were not defined in our draft. You'll also note in ikmpd/isakmp.h that the exchanges as well as other defines like protocol numbers are accompanied by a remark like "NOT YET ASSIGNED IN ISAKMP DRAFT". We've known this was a problem; it and several other inconsistencies are being dealt with presently. > Clearly, this conflict MUST be resolved one way or another before we > can ensure that implementations based on the current drafts are > interoperable. From my (perhaps naive) analysis, Identity Protection > and Oakley Main Mode look enough like one another that a merger of > the two should be possible. The Base exchange and Oakley Aggressive > Mode seem to be relatively close, in terms of the desired functionality, > but I can't say for certain. Oakley Quick Mode, if it is needed (and > currently no other exchange type in either draft provides for the > exchange of IDui and IDur, so I believe it is) will almost certainly > need a separate exchange type. A far from naive analysis: this is exactly what has been discussed. I propose this thread be moved to the isakmp-oakley mailing list (isakmp-oakley@cisco.com, majordomo@cisco.com for administrivia). If you-- or anyone else-- find any more problems, or inconsistencies that need to be resolved, please let us know while the ink is not yet dry. Dan. Message-Id: <199610111726.NAA18539@jekyll.piermont.com> To: rgm3@chrysler.com cc: Stephen Kent , John Gilmore , ipsec@TIS.COM Subject: Re: Short keys * Options, combinations, and negotiations => simplicity Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 11 Oct 1996 13:26:21 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Robert Moskowitz writes: > At 08:05 PM 10/8/96 -0500, Stephen Kent wrote: > >Moreover, in selecting any safeguard, one > >must balance percieved threats against costs. While you clearly precieve > >NSA as a threat, I don't find that most of my commercial clients share that > >view. They are more concerned about hackers, criminals, and other > >adversaries for whom DES is a reasonable countermeasure. > > Our industry has already faced government backed industrial espionage. Not > NSA backed, but their competitors.... I must also state that corporate threats are not out of the question, either. Dr. Kent's statement that his commercial clients may not be worried could very well be correct (my clients are worried but his may not be). That is, however, unimportant. Most corporate executives do not understand cryptography and thus do not know what is necessary. Luckily, we don't have to rely on opinion, we can rely on solid engineering and math for this judgement. All cryptography is economics. The point at which you have enough security in a commercial environment is easy to define -- breaking your codes must cost more than the information protected is worth. According to the paper "Minimal Key Lengths for Symmetric Ciphers to Provide Adequate Commercial Security"*, by Blaze, Diffie, Rivest, Schneier, Shimomura, Thompson, and Wiener, for an initial investment of $10Million, a device may be made which will successfully break DES keys in six minutes each, at an amortized price of $38. For an investment of $300k, one can break the keys in three hours for the same amortized price. It is clear that for any corporate secret worth more than $38, DES is inadequate. If you think an investment of $10 Million, or even $300k, is improbable, think again. In my particular industry group (the financial industry), an expenditure of a few million dollars to break someone's traffic might be a a very lucrative (if highly illegal) investment, and if the amortized cost of a single break was only $38, the expense would be considered inconsequential by many unscrupulous people. Indeed, with that low an amortized cost, one could afford strategies that would prevent being caught. If the amortized cost was high, you would need to make a big killing which might lead to your discovery, but with an amortized cost of $38, you could afford to make just a few hundred here and a few thousand there, indefinitely. You could, for example, front run trades for MONTHS, and have your pattern of activity look nearly innocent. Even outside my industry, it is not unreasonable to expect such investments to be made. These investments are not, in the greater scheme of things, large, and as I have noted, the amortized cost of any individual crack is smaller than a businessman's lunch. In other words, any thought that DES is adequate is simply wrong (no disrespect intended to Dr. Kent, who I admire). If your information is worth more than $38, its worth more than DES. (By the way, the same paper places the cost per crack of a 40 bit key at around eight CENTS, with an investment of $400 -- "exportable" crypto isn't worthwhile if you expect *any* serious attempt at all). I think the conclusion statement from the paper is worth quoting. "Bearing in mind that the additional computational costs of stronger encryption are modest, we strongly recommend a minimum key-length of 90 bits for symmetric cryptosystems." *The paper by Blaze et all is available from ftp://ftp.research.att.com/dist/mab/keylength.ps ftp://ftp.research.att.com/dist/mab/keylength.txt Perry PS It has been contended by the NSA in a document circulated in Washington that the paper by Blaze et al is wrong. I will quote their response to this contention here in order to cut off any argument in advance. This document is also available as ftp://ftp.research.att.com/dist/mab/keylength.nsa ---------------------------------------------------------------------- July 18, 1996 There is currently being circulated, to members of Congress and possibly elsewhere, a four page document entitled ``Brute-Force Cryptanalytic Attacks'' that calls into question some of the conclusions of the ``Minimum Key Lengths for Symmetric Ciphers'' white paper [1]. The document bears no author or organization attribution, but we are told that it originated from NSA. The NSA document argues that ``physical realities'' make parallel key search much more expensive and time consuming than our white paper estimated. However, the NSA document appears to have been written from the perspective of general parallel processing or cryptanalysis rather than exhaustive key search per se. It ignores several elementary principles of parallel processing that apply specifically to exhaustive key search machines of the type that our white paper considered. In particular, NSA argues that interconnections, heat dissipation, input/output bandwidth, and interprocessor communication make it difficult to ``scale up'' a key search machine by dividing the task among a large number of small components. While these factors do limit the scalability of more general purpose multiprocessor computers (such as those made by Cray), they do not apply at all to specialized exhaustive key search machines. The NSA argument ignores the most fundamental feature of brute-force key search: the processors performing the search have no need to communicate with other components of the system while they perform their share of the search, and therefore the system has no need for any of the global interconnections that limit scaling. Indeed, there is no reason that all the components of a parallel search machine must be located even within the same city, let alone the same computer housing. We note that one of our co-authors (Eric Thompson, of Access Data, Inc.) designs and builds medium-scale FPGA-based key search machines with exactly this loosely-coupled structure, and regularly uses them to recover keys for clients that include the FBI. The NSA document also calls into question our cost estimates for ASIC components, suggesting that ASIC chips of this type cost NSA approximately $1000.00 each. However, our $10.00 per chip estimate is based on an actual price quote from a commercial chip fabrication vendor for a moderate-size order for an exhaustive search ASIC designed in 1993 by Michael Wiener [2]. Perhaps NSA could reduce its own costs by changing vendors. Finally, the NSA report offers estimates of the time required to perform exhaustive search using a Cray model T3D supercomputer. This is a curious choice, for as our report notes, general-purpose supercomputers of this type make poor (and uneconomical) key search engines. However, even the artificially low performance results for this machine should give little comfort to the users of 56 bit keys. According to NSA, 56 bit keys can be searched on such a machine in less than 453 days. ``Moore's law'' predicts that it will not be long before relatively inexpensive general-purpose computers offer similar computational capability. /s/ Matt Blaze Whitfield Diffie References: [1] Blaze, M., Diffie, W., Rivest, R., Schneier, B., Shimomura, T., Thompson, E., and Wiener, M. ``Minimum Key Lengths for Symmetric Key Ciphers for Commercial Security.'' January 1996. Available from ftp://ftp.research.att.com/dist/mab/keylength.txt [2] Wiener, M. ``Exhaustive DES Key Search.'' Presented at Crypto-93, Santa Barbara, CA. August 1993. ========================================================================= [Transcription of document circulated to various members of congress and others in June, 1996, apparently by NSA] BRUTE-FORCE CRYPTANALYTIC ATTACKS Two published theoretical estimates of cost versus time to perform brute-force hardware attacks on selected cryptography key lengths differ between themselves and differ significantly from what we find when we buy or build computers to carry out such attacks. The differences lie in assumptions made in the theoretical estimates, which are not fully spelled out by the authors, and in scaling up hypothesized small machines to ever larger ones without accounting for physical realities. The factors not accounted for are: o R&D costs for the first machine, typically on the order of $10 million. o As more and more chips are added to a machine, two effects occur: o Interconnections increase and increase running time; o Heat from the chips eventually limit [sic] the size of a machine. o Memory costs are not included. o When get [sic] to the very fast processing speed estimates, machines can become Input/Output bound; so [sic] it cannot achieve the estimated speed. o Assuming every algorithm can be tested in same amount of time and key length is the only difference. Table 1 are [sic] the average time estimates made for a given cost done by Michael Wiener of Bell Norther Research in 1995. These are published in Bruce Schneier's Applied Cryptography book. Note that these are average times, one-half of the total exhaust time. Table 2 are [sic] the estimates for total exhaust times using Field Programmmable Gate Arrays (FPGA) and Application Specific ICs (ASICs) done for the Business Software Alliance by Blaze, Diffie, Rivest, Schneier, Shimomura, Thompson, and Wiener in 1996. In addition to the above factors not accounted for they have assumed ASICs cost as low as $10. We find ASICs more typically cost $1000 and their capabilities can vary considerably depending upon the specific task. Table 3 are out estimates based on our experience with a Cray T3D supercomputer with 1024 nodes. This machine costs $30 million. [Tables 1, 2, and 3 not transcribed here.] ---------------------------------------------------------------------- Received: from relay.hq.tis.com by neptune.TIS.COM id aa12583; 11 Oct 96 14:55 EDT Received: by relay.hq.tis.com; id OAA18026; Fri, 11 Oct 1996 14:59:25 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma018024; Fri, 11 Oct 96 14:59:13 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id OAA06269 for ; Fri, 11 Oct 1996 14:57:13 -0400 (EDT) Received: by relay.hq.tis.com; id OAA17999; Fri, 11 Oct 1996 14:58:55 -0400 Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1.1) id xma017983; Fri, 11 Oct 96 14:58:29 -0400 Received: from [128.89.0.110] (COMSEC.BBN.COM [128.89.0.110]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id PAA29675; Fri, 11 Oct 1996 15:00:21 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 11 Oct 1996 15:03:17 -0400 To: perry@piermont.com From: Stephen Kent Subject: Re: Short keys * Options, combinations, and negotiations => simplicity Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Perry, The analysis you cite on the cost of key breaking focuses on just one aspect of an overall intercept operation. Because it fails to take into account many other factors that arise in real world intercept situations, the results are potentially misleading. It is worth noting that single DES is widely used to provide confidentiality for a number of very substantial financial services apoplications. If the cost of breaking DES is sufficiently low, then organized criminals are missing a great opportunity to steal billions of dollars. If these folks (who do constitute a threat for many commercial clients) are not exploiting this vulnerability, either the cost is not so low, or they have better means of generating income. This is not a counter to the issue raised by Bob Moskowitz, since foreign intelligence agencies have different priorities, motivations and capabilities. Because there are many ways to acquire sensitive information, not just via passive intercepts, a fair amount of thought has to go into analysis of what constitutes appropriate security technology, relative to various threats. In developing a standard like IPSEC, we can allow for various algorithms and key lengths to accommodate different threat environments. However, because more secure algorithms and longer key lengths often entail performance penalties, one should make an informed decision when selecting among multiple options. Steve Received: from shiva.ee.siue.edu by neptune.TIS.COM id aa13682; 11 Oct 96 16:23 EDT Received: (from akjoele@localhost) by ee.siue.edu (8.7.5/8.7.3) id PAA16245; Fri, 11 Oct 1996 15:31:03 -0500 (CDT) Date: Fri, 11 Oct 1996 15:31:03 -0500 (CDT) From: Arve Kjoelen Message-Id: <199610112031.PAA16245@ee.siue.edu> To: ipsec@neptune.tis.com Subject: Re: Short keys * Options, combinations, and negotiations => simplicity Cc: akjoele@ee.siue.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: XV+ZQHmGC9W4Ql0gC+R27w== Sender: ipsec-approval@neptune.tis.com Precedence: bulk Steven Kent writes, in two different postings: > Providing a 3DES > option for those users who do percieve a threat for which this algorithm > and key size are appropriate, and for which the complementary security > safeguards are consistent, is an appropriate means of accommodating a range > of user requirements in a standard protocol. and > However, because more secure algorithms and longer key > lengths often entail performance penalties, one should make an informed > decision when selecting among multiple options. The differential increase in computing power required to support greater key lengths is far smaller than the increase in computing power required to decrypt traffic using these longer key lengths (assuming brute force). Given: - That there are numerous potential interceptors, with a wide range of financial means. - The continuous increase in computing power, facilitating the use of longer key lengths. - That it is impossible for the IPSEC working group to envision who will need (or want) what level of encryption, now or in the future. I think it would be prudent for us to make mandatory-to-implement strong algorithms such as 3DES. The existence of these algorithms in all IPSEC implementations will ensure that those who have or feel a need for strong cryptography will have the means available to them within IPSEC. Those who don't feel the need can still use single DES, which will also be available in all implementations. I encourage the group to make 3DES mandatory-to-implement. I personally believe that 56-bit DES will become less used with time, and agree with John that we must cull this and other short-keylength algorithms, or at least make stronger algorithms available just as widely as 56-bit DES. -Arve. Received: from relay.hq.tis.com by neptune.TIS.COM id aa14913; 11 Oct 96 18:06 EDT Received: by relay.hq.tis.com; id SAA22745; Fri, 11 Oct 1996 18:10:25 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma022743; Fri, 11 Oct 96 18:09:57 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id SAA16805 for ; Fri, 11 Oct 1996 18:08:09 -0400 (EDT) Received: by relay.hq.tis.com; id SAA22739; Fri, 11 Oct 1996 18:09:55 -0400 Received: from songbird.com(206.14.4.2) by relay.tis.com via smap (V3.1.1) id xma022737; Fri, 11 Oct 96 18:09:37 -0400 Received: (from kent@localhost) by bywater.songbird.com (8.6.9/8.6.9) id PAA17650; Fri, 11 Oct 1996 15:08:49 -0700 From: Kent Crispin Message-Id: <199610112208.PAA17650@bywater.songbird.com> Subject: Re: Short keys * Options, combinations, and negotiations => simplicity To: perry@piermont.com Date: Fri, 11 Oct 1996 15:08:49 -0700 (PDT) Cc: ipsec@TIS.COM In-Reply-To: <199610111726.NAA18539@jekyll.piermont.com> from "Perry E. Metzger" at Oct 11, 96 01:26:21 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk Perry E. Metzger allegedly said: > Robert Moskowitz writes: > > At 08:05 PM 10/8/96 -0500, Stephen Kent wrote: [...] > > All cryptography is economics. The point at which you have enough > security in a commercial environment is easy to define -- breaking > your codes must cost more than the information protected is worth. > > According to the paper "Minimal Key Lengths for Symmetric Ciphers to > Provide Adequate Commercial Security"*, by Blaze, Diffie, Rivest, > Schneier, Shimomura, Thompson, and Wiener, for an initial investment > of $10Million, a device may be made which will successfully break DES > keys in six minutes each, at an amortized price of $38. For an > investment of $300k, one can break the keys in three hours for the > same amortized price. > > It is clear that for any corporate secret worth more than $38, DES is > inadequate. > > If you think an investment of $10 Million, or even $300k, is > improbable, think again. [...] > In other words, any thought that DES is adequate is simply wrong (no > disrespect intended to Dr. Kent, who I admire). If your information is > worth more than $38, its worth more than DES. (By the way, the same > paper places the cost per crack of a 40 bit key at around eight CENTS, > with an investment of $400 -- "exportable" crypto isn't worthwhile if > you expect *any* serious attempt at all). While I find this analysis fairly persuasive, it does leave out an important extra cost -- the cost of isolating a converstion worth decrypting. If "valuable" secrets occur in a small fraction of intercepted messages, then the cost of finding the secret goes up proportionately. So, if keys are changed frequently, and *all* traffic is encrypted, the situation is dramatically different. It would have to be the case, for example, that the *average* value of a message was greater than $38, for a 56-bit key to be ineffective. If 99% of the messages had a value of 0, then the cost per *useful* key would be closer to $3800... Of course, one expects a higher percentage of value for messages flowing from a bank. But for incidental, opportunistic encryption (as John Gilmore put it), 56 bits may be adequate for a year or two. -- Kent Crispin "No reason to get excited", kent@songbird.com,kc@llnl.gov the thief he kindly spoke... PGP fingerprint: B6 04 CC 30 9E DE CD FE 6A 04 90 BB 26 77 4A 5E Received: from relay.hq.tis.com by neptune.TIS.COM id aa17653; 11 Oct 96 22:14 EDT Received: by relay.hq.tis.com; id WAA25264; Fri, 11 Oct 1996 22:18:56 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma025262; Fri, 11 Oct 96 22:18:29 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id WAA19713 for ; Fri, 11 Oct 1996 22:16:41 -0400 (EDT) Received: by relay.hq.tis.com; id WAA25255; Fri, 11 Oct 1996 22:18:26 -0400 Received: from dns2.noc.best.net(206.86.0.21) by relay.tis.com via smap (V3.1.1) id xma025251; Fri, 11 Oct 96 22:18:15 -0400 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with ESMTP id TAA01191; Fri, 11 Oct 1996 19:19:50 -0700 Received: from bill.scli.com ([206.79.9.161]) by shellx.best.com (8.6.12/8.6.5) with SMTP id TAA19834; Fri, 11 Oct 1996 19:19:13 -0700 Received: by bill.scli.com with Microsoft Mail id <01BBB7A8.FA19BC80@bill.scli.com>; Fri, 11 Oct 1996 19:18:26 -0700 Message-ID: <01BBB7A8.FA19BC80@bill.scli.com> From: Bill Hunt To: "perry@piermont.com" , 'Kent Crispin' Cc: "ipsec@TIS.COM" Subject: RE: Short keys * Options, combinations, and negotiations => simplicity Date: Fri, 11 Oct 1996 19:18:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk As you point out, there are multipliers to the raw cost, but there are also divisors. One example: the key does not typically change for each packet. Even if the key changes every five seconds, cracking one packet could give you (let's see 1500 byte packets at T1 speed) tens of thousands of cracked packets for free. Bill ---------- From: Kent Crispin[SMTP:kent@bywater.songbird.com] Perry E. Metzger allegedly said: > Robert Moskowitz writes: > > At 08:05 PM 10/8/96 -0500, Stephen Kent wrote: [...] > According to the paper "Minimal Key Lengths for Symmetric Ciphers to > Provide Adequate Commercial Security"*, by Blaze, Diffie, Rivest, > Schneier, Shimomura, Thompson, and Wiener, for an initial investment > of $10Million, a device may be made which will successfully break DES > keys in six minutes each, at an amortized price of $38. For an > investment of $300k, one can break the keys in three hours for the > same amortized price. > It is clear that for any corporate secret worth more than $38, DES is > inadequate. While I find this analysis fairly persuasive, it does leave out an important extra cost -- the cost of isolating a converstion worth decrypting. If "valuable" secrets occur in a small fraction of intercepted messages, then the cost of finding the secret goes up proportionately. So, if keys are changed frequently, and *all* traffic is encrypted, the situation is dramatically different. It would have to be the case, for example, that the *average* value of a message was greater than $38, for a 56-bit key to be ineffective. If 99% of the messages had a value of 0, then the cost per *useful* key would be closer to $3800... Of course, one expects a higher percentage of value for messages flowing from a bank. But for incidental, opportunistic encryption (as John Gilmore put it), 56 bits may be adequate for a year or two. To: Steven Bellovin cc: Stephen Kent , John Gilmore , ipsec@TIS.COM, gnu@toad.com Subject: Re: Short keys (3DES transform) Date: Fri, 11 Oct 1996 23:51:25 -0700 From: John Gilmore Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9610140720.aa16058@neptune.TIS.COM> I'm not 100% caught up on mailing list traffic (I'm not at home), but thought this deserved a quicker answer than if I waited. Steve Bellovin said: > This is a crucial point. I agree that 3DES is too expensive to be the > default transform. I also agree that the IAB had no intention of mandating > such a move, and I was one of the authors of the statement. On the > other hand, I didn't read John's note as suggesting it, either; rather > (and this may be based on prior conversations with him), he was suggesting > a mandatory-to-implement 3DES transform, so that people who want it will > have it. > > John -- what did you mean? I think that as a minimum we should have a mandatory-to-implement 3DES transform, so that hosts or sites which desire high-security connections to arbitrary hosts have a prayer of being able to get them. I also think that something stronger than 1DES should be the default. Steve Bellovin, you wrote the paper on breaking it; do you agree? If so, what would you pick as a default (if we need to pick one)? I think that DES's susceptibility to brute force is a real problem for commercial-grade traffic within the early lifetime of IPSEC. Just like people rely upon the Internet itself because it is there, they will tend to rely on IPSEC because it is there. Real high-dollar-value business, life-critical medical information, control of potentially deadly industrial processes, control of widely used infrastructures like water and power, and other valuable things will be secured and authenticated with it. Multi-billion-dollar companies will rise who depend on IPSEC for their daily commerce with millions of people. If their reliance is misplaced after two or three or five years, we will have done them a disservice. What the market wants is a "magic bullet" that solves the network confidentiality and network authentication problems. Non-cryptographers' least favorite thing about crypto is that you can't solve the problem once and for all; you have to keep redesigning it as attacks improve. This argues for building for long lifetimes when we know how to. Steve Kent argues that DES isn't the weakest link so we shouldn't strengthen it. As an engineer I'll put in the extra 10% effort to make sure it isn't MY link that fails. And in doing so I'll teach the designers of the weak links how to improve by avoiding marginal fixes. I have been running all of my telnet/rlogin traffic with 1DES (using Kerberos) for years, even within my local Ethernet, and find the performance completely acceptable and unnoticeable. I don't think I would notice 3DES either, though a large server with many connections might. I hope to have some performance numbers and "feel" for you (from running real IPSEC with 3DES) next month. Twenty-five years in this industry have shown me that today's marginal performance is invisible and irrelevant tomorrow, while today's marginal interface design decisions cost and cost and cost us forever. We have big leverage for speeding things up without changing them, but it takes massive human effort to change interfaces. 32-bit IP addresses. 640K DOS. 16-bit Windows. Segmented Mac memory. Unsafe pointers in C. Concentration of privileges in "root" user ID's. Lack of preemptive multitasking. Let's not add "1DES IPSEC". 1DES IPSEC, even with frequent key changes, will not provide privacy from inquisitive university students five years from now, just as 40-bit RC2 doesn't today. We're seeing exponential growth in circuit speed and density, independent exponential growth in the number of networked machines, and a further factor from our increasing abilities in software to coordinate parallel processors both in the same box and worldwide. Not to mention the wild card of increasingly wide access to circuit design and circuit implementation facilities (soon to include graphical "plug together blocks" PC tools which redefine field-programmable circuitry within the PC itself). DES was designed to be slow in software and fast in hardware, but the line between the two is blurring, and 56 bits just don't give a 5-year margin of safety even against poorly funded opponents. Steve Kent says that commercial customers think DES is strong enough today. He's right; they mostly do. This is why the Clinton DES-export-for-GAK gambit could work: the executives who are making these decisions may be willing to sacrifice the long term security of their customers to alleviate a short-term frustration. But we who specialize in this field owe them as customers a design that isn't obsolete tomorrow. And we owe our children a society that protects their privacy and their physical infrastructure, rather than leaving them increasingly vulnerable to thieves, blackmailers, terrorists, and J. Edgar Nixons. I considered building a DES-cracker this year to prove to skeptics that it's really a problem. I can do that because I'm a millionaire, but there are 140,000 millionaires in the US alone, and the cracker gets cheaper every year. I know two other groups that are building them today, and there undoubtedly more who haven't told me. I decided to do IPSEC instead, and I still think it's a good decision, but I am relying on *your* professional expertise to understand the threat without having a physical hardware box shoved under your nose. So, while I don't have the definitive expertise to say "I have run 3DES for years for all my packet traffic and it works great", all my expertise says that even if it doesn't, next year or in 18 months it will. And I have the same feeling about the DES search engines which make 1DES a poor default. John To: Stephen Kent cc: ipsec@TIS.COM Subject: Re: Short keys * Options, combinations, and negotiations => simplicity In-reply-to: Your message of "Fri, 11 Oct 1996 15:03:17 EDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 11 Oct 1996 23:19:06 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9610140719.aa16041@neptune.TIS.COM> Stephen Kent writes: > It is worth noting that single DES is widely used to provide > confidentiality for a number of very substantial financial services > apoplications. If the cost of breaking DES is sufficiently low, then > organized criminals are missing a great opportunity to steal billions of > dollars. Its only because the mafia doesn't have the expertise in house -- yet. I feel that I could personally manage to earn a substantial amount of ill gotten loot given the knowledge I have in my head right now. As an exercise, I've gone so far as to try to figure out what would be the way to do it. I'm not about to say how in detail, but I suspect that it would not only be possible to make a considerable sum, but one could also do it without being caught except by extreme chance. You are probably too used to thinking small, Steve. *Trillions* (not a misprint) flow through the capital markets on a daily basis. Tiny information advantages can be parlayed into large amounts of money. Done quietly, carefully, and non-greedily over a long period, and it would be possible to make a fortune. Not a small fortune -- a real one. I suspect that about half the people on this mailing list figure out how to do this if they bothered to take about six months to study the financial industry in detail and they had the courage. >From what I can tell, all that stands between us and this sort of thing happening regularly is a lack of smarts in our organized criminal gangs. I do not think this is a good situation. We should not be depending on the good will of the smart people of the world to protect us. > Because there are many ways to acquire sensitive information, not > just via passive intercepts, a fair amount of thought has to go into > analysis of what constitutes appropriate security technology, > relative to various threats. I've done consulting for a trader with a fairly famous hedge fund (I won't name him, but he's the sort to have had his name on the front page of the Journal) who I one day saw, without batting an eyelash, accumulate an 18 Billion dollar Eurobond position. (That is not a misprint). It took a team of about twenty people to work his trades in the market quietly enough to prevent him from being noticed. Do you know how much money could have been made if that information had leaked out? Do you know how much money he could have *lost* if that had leaked out? Tell me, with a straight face, that someone in that position doesn't need security every bit as good as the government. I mean, there is a serious limit to what lengths someone will go to for their country. Money, on the other hand, has a very powerful influence on human behavior. People will do astounding things for money. Honestly, I do not see any valid argument for why any financial instutution should use single DES under any circumstances. It is inadequate -- period. The data rates that the average institution deals with are low, and the machines they have usually have plenty of spare capacity. In software, the price difference between DES and 3DES is nearly zero provided you weren't using the cycles anyway. In hardware, the price is literally zero. > In developing a standard like IPSEC, we can allow for various > algorithms and key lengths to accommodate different threat > environments. However, because more secure algorithms and longer > key lengths often entail performance penalties, one should make an > informed decision when selecting among multiple options. A while back, I decided to see what it would be like to have to live with a "fully encrypted" environment. All communications between my company's machines -- ALL of it -- is encrypted. Backups, remote logins, mail reading, everything. (I wish I could be using IPSEC -- instead I am using Tatu Ylonen's SSH package. I do not 100% trust its security -- the package is too large to analyse -- but the exercise has none the less been good.) All that data is encrypted with 3DES at all times. What has the result been? Well, frankly, I've barely noticed. I was worried that my machines and communications would crawl, but they don't. The only time I really notice cryptography delays is when I do my mail downloads from my sacrificial machine (which accepts mail) to my workstation -- the script that I wrote to do this unfortunately invokes SSH three times, which means three RSA operations. The extra delay of a few seconds is noticeable, as I've said, but just barely. As I've noted, the delay is in doing the RSAs, not in 3DES. When doing collaborative work with the NetBSD project, I do all my remote CVS using RC4 with 128 bit keys. I would use 3DES, but the machine used for the CVS repository until recently was very old and had a very, very overloaded processor, so I decided to be kind to it. Going from personal experience to theory, I will note: 1) 40 bit RC4 and 128 bit RC4 run at the same speed even in software. 2) In hardware, 3DES and DES run at about the same speed and both cost about the same. (You need hardware anyway for serious bandwidths.) 3) In software, 3DES is often nearly as cheap as DES in practice, as I've found. Unless you are pounding bits really hard, your bottleneck is frequently not your data transmission speed. Allow me to summarize. 1) Investment banks, trading houses, commercial banks and hedge funds have *real* risk in using DES. The mere fact that many are foolish enough to do it doesn't change that. Hell, I know of important deals concluded IN THE CLEAR BY EMAIL. The fact that people are often stupid doesn't mean they don't need real security. 2) The price of real security is very low -- frequently near zero. Perry Date: Mon, 14 Oct 1996 08:37:19 -0400 To: "ipsec@TIS.COM" From: Robert Moskowitz Subject: European IPSec implementations Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9610140843.aa17259@neptune.TIS.COM> I will be in Cologne, Germany Oct 28th & 29th for a meeting of ODETTE wg 4 (automotive). It would be very valuable for this meeting to have at least a partial list of non-US IPsec implementations (planned are accessaptable at this point) that are targeting Oakley/ISAKMP and X.509 certs. Thanks for your help. Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.hq.tis.com by neptune.TIS.COM id aa18788; 14 Oct 96 10:18 EDT Received: by relay.hq.tis.com; id KAA18955; Mon, 14 Oct 1996 10:22:15 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma018941; Mon, 14 Oct 96 10:21:49 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id KAA23220 for ; Mon, 14 Oct 1996 10:19:55 -0400 (EDT) Received: by relay.hq.tis.com; id KAA18923; Mon, 14 Oct 1996 10:21:45 -0400 Received: from bastion.sware.com(139.131.15.2) by relay.tis.com via smap (V3.1.1) id xma018912; Mon, 14 Oct 96 10:21:25 -0400 Received: from UNKNOWN [139.131.1.166] by bastion-gw.sware.com for id KAA21758; Mon Oct 14 10:23:37 1996 Received: by zeus.sware.com (1.39.111.2/2.0) from mordred.sware.com id AA298293016; Mon, 14 Oct 1996 10:23:36 -0400 Received: by mordred.sware.com (5.65/2.1) id AA06799; Mon, 14 Oct 96 10:25:08 -0400 Message-Id: <9610141425.AA06799@mordred.sware.com> Subject: Re: Short keys * Options, combinations, and negotiations => simplicity Date: Mon, 14 Oct 1996 10:25:07 -0400 (EDT) In-Reply-To: <9610140719.aa16041@neptune.TIS.COM> from "Perry E. Metzger" at Oct 11, 96 11:19:06 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text To: perry@piermont.com From: Charles Watt Cc: kent@bbn.com, ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-Certificate: MIIBvzCCAWkCEFmOln6ip0w49CuyWr9vDVUwDQYJKoZIhvcNAQECBQAwWTELMAkG A1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2Vj dXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMB4XDTk1MDUwODIw MjMzNVoXDTk3MDUwNzIwMjMzNVowcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1Nl Y3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsT DkVuZ2luZWVyaW5nIENBMRUwEwYDVQQDEwxDaGFybGVzIFdhdHQwWTAKBgRVCAEB AgICBANLADBIAkEM2ZSp7b6eqDqK5RbPFpd6DGSLjbpHOZU07pUcdgJXiduj9Ytf 1rsmf/adaplQr+X5FeoIdT/bVSv2MUi3gY0eFwIDAQABMA0GCSqGSIb3DQEBAgUA A0EApEjzeBjiSnGImJXgeY1K8HWSufpJ2DpLBF7DYqqIVAX9H7gmfOJhfeGEYVjK aTxjgASxqHhzkx7PkOnL4JrN+Q== MIC-Info: RSA-MD5,RSA, BGCRKqAKblFdFAdiOHGkQjpVFQk1sz8fNSsPm283blaYvo2LgISc6e9jpnV7TnD9 RWGb+X9eW7ssl8hVb1qVFwM= Perry Metzger writes: > Stephen Kent writes: > > It is worth noting that single DES is widely used to provide > > confidentiality for a number of very substantial financial services > > apoplications. If the cost of breaking DES is sufficiently low, then > > organized criminals are missing a great opportunity to steal billions of > > dollars. > > Its only because the mafia doesn't have the expertise in house -- > yet. ... In all this flap I haven't heard any mention of Rivest's DESX (see www.rsa.com/rsalabs/cryptobytes/, Volume 2, Number 2 - Summer '96 issue). The only weakness that I have seen in the literature concerning DES comes from exhaustive key search. Rogaway and Kilian provide a convincing argument that DESX solves this problem, perhaps better than 3DES, with essentially the same computational costs as DES. Have I missed something in the literature? Charles Watt SecureWare/Security First Network Bank -----END PRIVACY-ENHANCED MESSAGE----- Received: from relay.hq.tis.com by neptune.TIS.COM id aa19379; 14 Oct 96 10:57 EDT Received: by relay.hq.tis.com; id LAA20237; Mon, 14 Oct 1996 11:01:15 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma020227; Mon, 14 Oct 96 11:00:47 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id KAA26674 for ; Mon, 14 Oct 1996 10:58:53 -0400 (EDT) Received: by relay.hq.tis.com; id LAA20223; Mon, 14 Oct 1996 11:00:44 -0400 Received: from tik1.ethz.ch(129.132.119.131) by relay.tis.com via smap (V3.1.1) id xma020208; Mon, 14 Oct 96 11:00:15 -0400 Received: from kom30.ethz.ch (kom30 [129.132.66.8]) by tik1.ethz.ch (8.7.5/8.7.3) with ESMTP id RAA17104; Mon, 14 Oct 1996 17:02:04 +0200 (MET DST) From: Germano Caronni Received: (from caronni@localhost) by kom30.ethz.ch (8.7.5/8.7.3) id RAA21335; Mon, 14 Oct 1996 17:02:00 +0200 (MET DST) Message-Id: <199610141502.RAA21335@kom30.ethz.ch> Subject: Re: replay window To: Stephen Kent Date: Mon, 14 Oct 1996 17:01:59 +0200 (MET DST) Cc: piper@tgv.com, ipsec@TIS.COM In-Reply-To: from "Stephen Kent" at Oct 4, 96 10:51:21 am X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk Stephen Kent wrote: > I don't have a proposed algorithm for calculating a replay window > size; I'm just concerned that we not pick a single, universal value at > this time. However, I do feel that the size of the window ultitamely > should be controlled by the receiver, since that's where the work is done. > So, "negotiation" may be a misnomer here. One could begin by having a > receiving implementation always insist on a fixed window size, irrespective > of the request from the sender, and that would be compliant. At least this > allows for changinf your implementation in the future but advertising the > change, rather than having it be a locally defined mystery. I am a little bit late in joining this discussion, so perhaps I missed some arguments that were already used. If you happen to have a look at the internet draft '*-esp-stream-01.txt', (which has a very ugly weakness (inherent in using stream ciphers) that was first reported by Angelos, and on which I will write something RSN :-( ), you will find some practical limits in section 6.1 esp-stream does *not* do any negotiation of the replay window size. The reason for this is that the decision how big the window actually needs to be is mostly receiver-dependant in environments where lower layer QoS can not be determined. A receiver can monitor the behaviour of its associations, and 'fix' the window size to achieve best performance / resource consumption. On the other hand, if the sender fears about the time data may be 'unobserved', it just needs to change the packet key. No big issue, and no need for any form of negotiation there. Comments? Germano Received: from relay.hq.tis.com by neptune.TIS.COM id aa20118; 14 Oct 96 11:34 EDT Received: by relay.hq.tis.com; id LAA21557; Mon, 14 Oct 1996 11:38:25 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma021552; Mon, 14 Oct 96 11:38:04 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id LAA28488 for ; Mon, 14 Oct 1996 11:36:04 -0400 (EDT) Received: by relay.hq.tis.com; id LAA21546; Mon, 14 Oct 1996 11:37:55 -0400 Received: from zelkova.qualcomm.com(129.46.148.32) by relay.tis.com via smap (V3.1.1) id xma021544; Mon, 14 Oct 96 11:37:51 -0400 Received: from localhost (localhost [127.0.0.1]) by zelkova.qualcomm.com (8.7.6/8.7.3) with ESMTP id IAA04917; Mon, 14 Oct 1996 08:39:09 -0700 (PDT) To: John Gilmore cc: Steven Bellovin , Stephen Kent , ipsec@TIS.COM Subject: Re: Short keys (3DES transform) From: Paul Pomes Organization: Qualcomm, Inc. X-url: In-reply-to: Your message of Fri, 11 Oct 1996 23:51:25 PDT. <9610140720.aa16058@neptune.TIS.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4909.845307548.1@zelkova.qualcomm.com> Date: Mon, 14 Oct 1996 08:39:09 -0700 Message-ID: <4915.845307549@zelkova.qualcomm.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk Another argument against using 1DES now is the prospect of "data mining" in the future once fast DES crackers are under $5K. There's a lot of sensitive traffic *now* that will still be dynamite in 5 years to the sufficiently motivated (IRS, business partners, spouses, etc). The latter are usually well-positioned with low costs of intercept. /pbp Received: from relay.hq.tis.com by neptune.TIS.COM id aa20194; 14 Oct 96 11:40 EDT Received: by relay.hq.tis.com; id LAA21684; Mon, 14 Oct 1996 11:44:55 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma021676; Mon, 14 Oct 96 11:44:29 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id LAA28829 for ; Mon, 14 Oct 1996 11:42:33 -0400 (EDT) Received: by relay.hq.tis.com; id LAA21666; Mon, 14 Oct 1996 11:44:25 -0400 Received: from netcom8.netcom.com(192.100.81.117) by relay.tis.com via smap (V3.1.1) id xmaa21660; Mon, 14 Oct 96 11:44:23 -0400 Received: from winp133 (ple-ca16-15.ix.netcom.com [204.31.114.207]) by netcom8.netcom.com (8.6.13/Netcom) id IAA24189; Mon, 14 Oct 1996 08:46:31 -0700 Message-Id: <2.2.32.19961014154517.006e6b58@netcom8.netcom.com> X-Sender: dpalma@netcom8.netcom.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 14 Oct 1996 08:45:17 -0700 To: ipsec@TIS.COM From: Derek Palma Subject: ISAKMP/Oakley vs SKIP: The real status Cc: dpalma@netcom.com Sender: ipsec-approval@neptune.tis.com Precedence: bulk Is there an official statement from the workgroup about the status of ISAKMP/Oakley vs SKIP? I see bits and peices but no official statement. --------------------------------------------------------------------- Derek Palma Email: dpalma@netcom.com Net Research, Inc. Direct:(510) 487-6439 32536 Monterey Way Main: (510) 487-6300 Union City, CA 94587 FAX: (510) 487-6072 Received: from relay.hq.tis.com by neptune.TIS.COM id aa23147; 14 Oct 96 15:24 EDT Received: by relay.hq.tis.com; id PAA27953; Mon, 14 Oct 1996 15:28:56 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma027945; Mon, 14 Oct 96 15:28:35 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id PAA12047 for ; Mon, 14 Oct 1996 15:26:39 -0400 (EDT) Received: by relay.hq.tis.com; id PAA27933; Mon, 14 Oct 1996 15:28:29 -0400 Received: from bastion.sware.com(139.131.15.2) by relay.tis.com via smap (V3.1.1) id xma027927; Mon, 14 Oct 96 15:28:13 -0400 Received: from UNKNOWN [139.131.1.166] by bastion-gw.sware.com for id PAA25587; Mon Oct 14 15:30:26 1996 Received: by zeus.sware.com (1.39.111.2/2.0) from mordred.sware.com id AA286581416; Mon, 14 Oct 1996 15:30:17 -0400 Received: by mordred.sware.com (5.65/2.1) id AA07647; Mon, 14 Oct 96 15:31:48 -0400 Message-Id: <9610141931.AA07647@mordred.sware.com> Subject: Re: Short keys * Options, combinations, and negotiations => Date: Mon, 14 Oct 1996 15:31:48 -0400 (EDT) In-Reply-To: <3.0b34.32.19961014122515.00c37168@pop3hub.is.chrysler.com> from "Robert Moskowitz" at Oct 14, 96 12:33:09 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text To: rgm3@chrysler.com From: Charles Watt Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-Certificate: MIIBvzCCAWkCEFmOln6ip0w49CuyWr9vDVUwDQYJKoZIhvcNAQECBQAwWTELMAkG A1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2Vj dXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMB4XDTk1MDUwODIw MjMzNVoXDTk3MDUwNzIwMjMzNVowcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1Nl Y3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsT DkVuZ2luZWVyaW5nIENBMRUwEwYDVQQDEwxDaGFybGVzIFdhdHQwWTAKBgRVCAEB AgICBANLADBIAkEM2ZSp7b6eqDqK5RbPFpd6DGSLjbpHOZU07pUcdgJXiduj9Ytf 1rsmf/adaplQr+X5FeoIdT/bVSv2MUi3gY0eFwIDAQABMA0GCSqGSIb3DQEBAgUA A0EApEjzeBjiSnGImJXgeY1K8HWSufpJ2DpLBF7DYqqIVAX9H7gmfOJhfeGEYVjK aTxjgASxqHhzkx7PkOnL4JrN+Q== MIC-Info: RSA-MD5,RSA, ASERSHDnJzzboIfvTk+rj0b/F0WdSzybWdhtLl4DGXuZ/mAYZbYmXTskteVYEcbY YD1YCRQ0aAfehKHn9rJkomQ= > > At 10:25 AM 10/14/96 -0400, Charles Watt wrote: > > > >In all this flap I haven't heard any mention of Rivest's DESX > >(see www.rsa.com/rsalabs/cryptobytes/, Volume 2, Number 2 - Summer '96 > issue). > > The only URL I found was: > > http://www.rsa.com/rsalabs/pubs/cryptobytes.html > > And it did not have vol2#2 yet :( > > >The only weakness that I have seen in the literature concerning DES comes > >from exhaustive key search. Rogaway and Kilian provide a convincing > >argument that DESX solves this problem, perhaps better than 3DES, with > >essentially the same computational costs as DES. > > > >Have I missed something in the literature? > > Well, I've missed the lit! Sorry. I get the paper copy of Cryptobytes from RSA. I trusted the URL published in the paper. Try "How to protect DES against exhaustive key search" as listed at http://wwwcsif.cs.ucdavis.edu/~rogaway/papers/ (I verified this one!). CW -----END PRIVACY-ENHANCED MESSAGE----- Received: from relay.hq.tis.com by neptune.TIS.COM id aa28905; 14 Oct 96 22:04 EDT Received: by relay.hq.tis.com; id WAA03491; Mon, 14 Oct 1996 22:08:37 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma003486; Mon, 14 Oct 96 22:08:09 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id WAA20663 for ; Mon, 14 Oct 1996 22:06:15 -0400 (EDT) Received: by relay.hq.tis.com; id WAA03482; Mon, 14 Oct 1996 22:08:07 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1) id xma003480; Mon, 14 Oct 96 22:07:47 -0400 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id TAA27249; Mon, 14 Oct 1996 19:10:00 -0700 Received: by mailsun2.us.oracle.com (SMI-8.6/37.8) id TAA12987; Mon, 14 Oct 1996 19:14:26 -0700 Message-Id: <199610150214.TAA12987@mailsun2.us.oracle.com> Date: 14 Oct 96 16:27:27 -0700 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: Re: ISAKMP/Oakley vs SKIP: The real status X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-request@neptune.hq.tis.com's message of 14-Oct-96 08:45 MIME-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.0.2.1.40) Content-Type: multipart/mixed; boundary="=_ORCL_8445309_0_11919610142015260" Sender: ipsec-approval@neptune.tis.com Precedence: bulk --=_ORCL_8445309_0_11919610142015260 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" >Is there an official statement from the workgroup >about the status of ISAKMP/Oakley vs SKIP? I see bits >and peices but no official statement. The "official" statement came from Jeff Schiller (the IETF Security Area Directory) a month ago. Please check the e-mail archive if you have not read this announcement. The IPsec working group is now focusing on the ISAKMP/Oakley specifications as the mandatory to implement standard for key management. The working group is strongly encouraged to send all comments on ISAKMP/Oakley to the list. If something is not clear, please propose text. I would also strongly encourage the group to pursue interoperability testing as soon as possible. If someone would like to help coordinate testing at the next IETF, please let me know. After the working group has finished all editorial clarification of ISAKMP/Oakley, work within the committee could start on incorporating optional facilities for in-line keying. I assume that this work will be loosely based on SKIP with slight modifications based on working group suggestions for a consolidated architecture. Note that this will not be SKIP as currently documented. I also assume that the SKIP team will continue to contribute to this working group to help create a consolidated approach for in-line keying. Regards, Paul A. Lambert (IPsec Co-Chair) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 633-2963 Redwood Shores, CA 94065 E-Mail: palamber@us.oracle.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Secure Jobs" -> send resumes to: palamber@us.oracle.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --=_ORCL_8445309_0_11919610142015260 Content-Type:message/rfc822 Date: 14 Oct 96 08:45:17 From:"Derek Palma " To:ipsec@tis.com Subject:ISAKMP/Oakley vs SKIP: The real status Cc:dpalma@netcom.com X-Sender:dpalma@netcom8.netcom.com X-Mailer:Windows Eudora Pro Version 2.2 (32) Sender:ipsec-approval@neptune.hq.tis.com Precedence: bulk MIME-Version: 1.0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="us-ascii" Is there an official statement from the workgroup about the status of ISAKMP/Oakley vs SKIP? I see bits and peices but no official statement. --------------------------------------------------------------------- Derek Palma Email: dpalma@netcom.com Net Research, Inc. Direct:(510) 487-6439 32536 Monterey Way Main: (510) 487-6300 Union City, CA 94587 FAX: (510) 487-6072 --=_ORCL_8445309_0_11919610142015260-- Date: Mon, 14 Oct 1996 17:55:17 -0400 (EDT) Message-Id: <199610142155.RAA08785@carp.morningstar.com> From: Karl Fox To: Charles Watt Cc: rgm3@chrysler.com, ipsec@TIS.COM Subject: Re: Short keys * Options, combinations, and negotiations => In-Reply-To: <9610141931.AA07647@mordred.sware.com> References: <3.0b34.32.19961014122515.00c37168@pop3hub.is.chrysler.com> <9610141931.AA07647@mordred.sware.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: ipsec-approval@neptune.tis.com Precedence: bulk > > >In all this flap I haven't heard any mention of Rivest's DESX > > >(see www.rsa.com/rsalabs/cryptobytes/, Volume 2, Number 2 - Summer '96 > > issue). > > > > The only URL I found was: > > > > http://www.rsa.com/rsalabs/pubs/cryptobytes.html > > > > And it did not have vol2#2 yet :( ... Try http://www.rsa.com/PUBS/crypto2n.pdf -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 Date: Tue, 15 Oct 1996 11:46:50 -0400 From: Hilarie Orman Message-Id: <199610151546.LAA04859@earth.hpc.org> To: PALAMBER@us.oracle.com Cc: ipsec@TIS.COM In-reply-to: Yourmessage <199610150229.TAA26925@baskerville.CS.Arizona.EDU> Subject: Re: ISAKMP/Oakley vs SKIP: The real status Sender: ipsec-approval@neptune.tis.com Precedence: bulk > After the working group has finished all editorial clarification of > ISAKMP/Oakley, work within the committee could start on incorporating optional > facilities for in-line keying. What committee? The in-line key committee? Won't the ESP and AH headers need to be changed for this optional facility? Hilarie Orman X-Money-Talking: text following is due to an SMTP-Humor error If you are a millionaire and want to build a DES cracking machine, please send $10 to the three people whose names appear at the top of the following list. Delete their names and then send EXACT copies of the message to them. Remember, you can't break DES if you break the chain! (If you are a billionaire please send $10,000) (list of 140000 millionaires removed by nefarious influence) Received: from relay.hq.tis.com by neptune.TIS.COM id aa11806; 15 Oct 96 14:24 EDT Received: by relay.hq.tis.com; id OAA20241; Tue, 15 Oct 1996 14:28:31 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma020230; Tue, 15 Oct 96 14:28:05 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id OAA26517 for ; Tue, 15 Oct 1996 14:26:07 -0400 (EDT) Received: by relay.hq.tis.com; id OAA20222; Tue, 15 Oct 1996 14:28:01 -0400 Received: from dns1.noc.best.net(206.86.8.69) by relay.tis.com via smap (V3.1.1) id xma020217; Tue, 15 Oct 96 14:27:51 -0400 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns1.noc.best.net (8.6.12/8.6.5) with ESMTP id LAA20171; Tue, 15 Oct 1996 11:27:26 -0700 Received: from bill.scli.com ([206.79.9.161]) by shellx.best.com (8.6.12/8.6.5) with SMTP id LAA25178; Tue, 15 Oct 1996 11:24:48 -0700 Received: by bill.scli.com with Microsoft Mail id <01BBBA8B.55E7DDA0@bill.scli.com>; Tue, 15 Oct 1996 11:23:48 -0700 Message-ID: <01BBBA8B.55E7DDA0@bill.scli.com> From: Bill Hunt To: "ipsec@TIS.COM" , "'PALAMBER.US.ORACLE.COM'" Subject: RE: ISAKMP/Oakley vs SKIP: The real status Date: Tue, 15 Oct 1996 11:23:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk You are, of course, referring to IPv6, since that is the only place the word "mandatory" appeared in Jeff's decision? I too am unclear about the status of SKIP vs. ISAKMP/Oakley. Clarification would be nice. Bill Hunt ---------- From: PALAMBER.US.ORACLE.COM[SMTP:PALAMBER@us.oracle.com] Sent: Monday, October 14, 1996 4:27 PM To: ipsec@TIS.COM Subject: Re: ISAKMP/Oakley vs SKIP: The real status <> >Is there an official statement from the workgroup >about the status of ISAKMP/Oakley vs SKIP? I see bits >and peices but no official statement. The "official" statement came from Jeff Schiller (the IETF Security Area Directory) a month ago. Please check the e-mail archive if you have not read this announcement. The IPsec working group is now focusing on the ISAKMP/Oakley specifications as the mandatory to implement standard for key management. The working group is strongly encouraged to send all comments on ISAKMP/Oakley to the list. If something is not clear, please propose text. I would also strongly encourage the group to pursue interoperability testing as soon as possible. If someone would like to help coordinate testing at the next IETF, please let me know. After the working group has finished all editorial clarification of ISAKMP/Oakley, work within the committee could start on incorporating optional facilities for in-line keying. I assume that this work will be loosely based on SKIP with slight modifications based on working group suggestions for a consolidated architecture. Note that this will not be SKIP as currently documented. I also assume that the SKIP team will continue to contribute to this working group to help create a consolidated approach for in-line keying. Received: from relay.hq.tis.com by neptune.TIS.COM id aa13150; 15 Oct 96 15:38 EDT Received: by relay.hq.tis.com; id PAA23399; Tue, 15 Oct 1996 15:43:02 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma023390; Tue, 15 Oct 96 15:42:37 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id PAA02337 for ; Tue, 15 Oct 1996 15:40:39 -0400 (EDT) Received: by relay.hq.tis.com; id PAA23375; Tue, 15 Oct 1996 15:42:32 -0400 Received: from fnal.fnal.gov(131.225.110.17) by relay.tis.com via smap (V3.1.1) id xma023365; Tue, 15 Oct 96 15:42:27 -0400 Received: from gungnir.fnal.gov ("port 35101"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IAOBXJIDDA0036JE@FNAL.FNAL.GOV>; Tue, 15 Oct 1996 14:44:29 -0600 (CST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id OAA17822; Tue, 15 Oct 1996 14:44:20 -0500 Date: Tue, 15 Oct 1996 14:44:19 -0500 From: Matt Crawford Subject: Re: ISAKMP/Oakley vs SKIP: The real status In-reply-to: "15 Oct 1996 11:23:47 PDT." <"01BBBA8B.55E7DDA0"@bill.scli.com> To: Bill Hunt Cc: "ipsec@TIS.COM" Message-id: <199610151944.OAA17822@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ You are, of course, referring to IPv6, since that is the only place > the word "mandatory" appeared in Jeff's decision? > > I too am unclear about the status of SKIP vs. ISAKMP/Oakley. > Clarification would be nice. Clarification may be found in the original announcement, by continuing to read beyond the bullet list under "I would like to see ..." to find "Proposed New Charter (with change bars)." _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A Date: Tue, 15 Oct 1996 16:57:37 -0400 (EDT) Message-Id: <199610152057.QAA05737@carp.morningstar.com> From: Karl Fox To: Charles Watt Cc: perry@piermont.com, kent@bbn.com, ipsec@TIS.COM Subject: Re: Short keys * Options, combinations, and negotiations => simplicity In-Reply-To: <9610141425.AA06799@mordred.sware.com> References: <9610140719.aa16041@neptune.TIS.COM> <9610141425.AA06799@mordred.sware.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: ipsec-approval@neptune.tis.com Precedence: bulk Charles Watt writes: > In all this flap I haven't heard any mention of Rivest's DESX > (see www.rsa.com/rsalabs/cryptobytes/, Volume 2, Number 2 - Summer '96 issue). > The only weakness that I have seen in the literature concerning DES comes > from exhaustive key search. Rogaway and Kilian provide a convincing > argument that DESX solves this problem, perhaps better than 3DES, with > essentially the same computational costs as DES. I, too, am intrigued by this. If someone wrote a draft for some form of ESP-DESX, I'd implement it. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 Received: from relay.hq.tis.com by neptune.TIS.COM id aa18815; 16 Oct 96 1:19 EDT Received: by relay.hq.tis.com; id BAA02571; Wed, 16 Oct 1996 01:23:33 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma002569; Wed, 16 Oct 96 01:23:04 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id BAA15308 for ; Wed, 16 Oct 1996 01:21:07 -0400 (EDT) Received: by relay.hq.tis.com; id BAA02561; Wed, 16 Oct 1996 01:23:03 -0400 Received: from servo.qualcomm.com(129.46.101.170) by relay.tis.com via smap (V3.1.1) id xmaa02557; Wed, 16 Oct 96 01:22:58 -0400 Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id WAA13288; Tue, 15 Oct 1996 22:25:06 -0700 (PDT) Date: Tue, 15 Oct 1996 22:25:06 -0700 (PDT) From: Phil Karn Message-Id: <199610160525.WAA13288@servo.qualcomm.com> To: perry@piermont.com CC: kent@bbn.com, ipsec@TIS.COM In-reply-to: <9610140719.aa16041@neptune.TIS.COM> (perry@piermont.com) Subject: Re: Short keys * Options, combinations, and negotiations => simplicity Sender: ipsec-approval@neptune.tis.com Precedence: bulk >3) In software, 3DES is often nearly as cheap as DES in practice, as > I've found. Unless you are pounding bits really hard, your > bottleneck is frequently not your data transmission speed. Some data points. My own DES and 3DES code runs at 15.9 and 6.2 megabits/sec, respectively, on a 133 MHz Pentium under BSDI. As Perry says, this is not even noticeable over most communication paths. Certainly not the ones I'm most concerned about, such as my ISDN connection and the external Internet. The 3DES code runs somewhat faster than 1/3 the speed of the single DES code because I've removed the inner initial and final permutation pairs that cancel each other out. The core of the code is in hand-optimized assembler. Both GNU and Borland C versions are included, though the GNU version is faster because it assumes 32-bit mode. I consider my code public domain and will email it to anyone who states they're a US citizen or permanent resident. I too routinely encrypt as much as I can with SSH, including all interactive and file transfer sessions between work and home, and even the HTTP connections between Netscape on my local machines and the web cache over at SDSC. SSH's TCP connection- forwarding feature makes this pretty easy to do. And with compression also enabled in SSH, response over my ISDN link is faster than with no SSH in the path. Phil Date: Wed, 16 Oct 1996 09:05:25 -0700 From: Ran Atkinson Message-Id: <199610161605.JAA03441@cornpuffs.cisco.com> To: ipsec@TIS.COM Subject: ISAKMP support for inline keying In-Reply-To: <199610150214.TAA12987@mailsun2.us.oracle.com> Organization: Internet Engineering Task Force Sender: ipsec-approval@neptune.tis.com Precedence: bulk In article <199610150214.TAA12987@mailsun2.us.oracle.com> Paul Lambert wrote: >After the working group has finished all editorial clarification of >ISAKMP/Oakley, work within the committee could start on incorporating >optional facilities for in-line keying. I assume that this work will >be loosely based on SKIP with slight modifications based on working group >suggestions for a consolidated architecture. To follow up on Paul's note and clarify perhaps a bit: - There was significant discussion on the IPsec list about how desirable it would be to put inline-keying support derived in large part from SKIP within the ISAKMP framework. The Security AD has indicated that it is desirable for the WG to explore this approach in detail. Many people, including folks at Sun, have indicated that this is technically feasible. Other specific suggestions (e.g. Bill Sommerfeld's idea which reduces per-packet overhead) have also been made that should be considered as part of the inline keying approach. - Therefore, Paul and I would like to ask for a volunteer or two to act as document editors for a document on placing in-line keying based on SKIP but incorporating other suggestions/ideas from the working group into the ISAKMP framework. Volunteers should send an email to both Paul and me. A key criterion is having time to work on the document. Another important criterion is willingness to edit in accordance with WG inputs. Should we have multiple volunteers that are in other respects the same, we'll probably prefer someone not at a vendor. To followup on Hilarie's question about ESP/AH: - I don't see any need to change ESP/AH in a backwards-incompatible way. I'm strongly disinclined to change ESP/AH in a backwards- incompatible way because implements of the Proposed Standard RFCs already exist. My understanding from Steve Kent has been that his editorial changes will not affect where the bits go (e.g. in ESP with the Combined ESP transform or AH with the HMAC MD5 transform). Ran rja@cisco.com From: PC-Waterhouse Richard To: 'IPSEC Working Group' Subject: isakmp-05.txt Date: Fri, 18 Oct 96 16:00:00 cdt Message-ID: <3267F332@smtp-gw.dos.chnt.gtegsc> Encoding: 7 TEXT X-Mailer: Microsoft Mail V3.0 Sender: ipsec-approval@neptune.tis.com Precedence: bulk 1. Why MUST all implementations of ISAKMP support the Internet DOI ? We have a potential application that has nothing to do with thre Internet. 2. A general impression - if you are serious about "MUST", you don't have enough of them to nail it down to the point that interoperability is guaranteed. Received: from relay.hq.tis.com by neptune.TIS.COM id aa26358; 18 Oct 96 17:52 EDT Received: by relay.hq.tis.com; id RAA00961; Fri, 18 Oct 1996 17:55:57 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma000952; Fri, 18 Oct 96 17:55:28 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id RAA16144 for ; Fri, 18 Oct 1996 17:53:26 -0400 (EDT) Received: by relay.hq.tis.com; id RAA00948; Fri, 18 Oct 1996 17:55:27 -0400 Received: from stilton.cisco.com(171.69.1.161) by relay.tis.com via smap (V3.1.1) id xma000943; Fri, 18 Oct 96 17:55:08 -0400 Received: from cisco.com (localhost.cisco.com [127.0.0.1]) by stilton.cisco.com (8.6.12/8.6.5) with ESMTP id OAA29356; Fri, 18 Oct 1996 14:55:30 -0700 Message-Id: <199610182155.OAA29356@stilton.cisco.com> To: PC-Waterhouse Richard cc: 'IPSEC Working Group' Subject: Re: isakmp-05.txt In-reply-to: Your message of "Fri, 18 Oct 1996 16:00:00 CDT." <3267F332@smtp-gw.dos.chnt.gtegsc> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29353.845675730.1@cisco.com> Date: Fri, 18 Oct 1996 14:55:30 -0700 From: David Carrel Sender: ipsec-approval@neptune.tis.com Precedence: bulk > 1. Why MUST all implementations of ISAKMP support the Internet DOI ? We > have a potential application that has nothing to do with thre Internet. To be an ISAKMP implementation that is conformant with the upcoming IETF standard for ISAKMP, you must implement the internet DOI. But if you want an implementation that does not do the Internet DOI, then you do not have to implement it. You just won't be compliant with the IETF spec. You also won't be able to interoperate with implementations doing only the Internet DOI. Interoperability is the reason for the "MUST". Dave Received: from relay.hq.tis.com by neptune.TIS.COM id aa27984; 18 Oct 96 20:10 EDT Received: by relay.hq.tis.com; id UAA03592; Fri, 18 Oct 1996 20:14:16 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma003588; Fri, 18 Oct 96 20:14:05 -0400 Received: from sol.hq.tis.com (sol [10.33.1.100]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id UAA18447 for ; Fri, 18 Oct 1996 20:12:02 -0400 (EDT) Received: from la.tis.com (scintillate.la.tis.com) by sol.hq.tis.com (4.1/SMI-4.1) id AA16921; Fri, 18 Oct 96 20:15:53 EDT Received: from relay.la.tis.com by la.tis.com (4.1/SUN-5.64) id AA04471; Fri, 18 Oct 96 17:17:13 PDT Received: by relay.la.tis.com; id RAA05933; Fri, 18 Oct 1996 17:08:50 -0700 Received: from hubbub.cisco.com(198.92.30.31) by relay.la.tis.com via smap (V3.1.1) id xma005931; Fri, 18 Oct 96 17:08:42 -0700 Received: from spook (dharkins-ss20.cisco.com [171.69.60.241]) by hubbub.cisco.com (8.7.6/CISCO.GATE.1.1) with ESMTP id RAA04315; Fri, 18 Oct 1996 17:14:47 -0700 (PDT) Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by spook (8.6.8+c/CISCO.WS.1.1) with SMTP id OAA07772; Fri, 18 Oct 1996 14:50:35 -0700 Message-Id: <199610182150.OAA07772@spook> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: PC-Waterhouse Richard Cc: 'IPSEC Working Group' Subject: Re: isakmp-05.txt In-Reply-To: Your message of "Fri, 18 Oct 1996 16:00:00 CDT." <3267F332@smtp-gw.dos.chnt.gtegsc> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Oct 1996 14:50:35 -0700 From: Daniel Harkins Sender: ipsec-approval@neptune.tis.com Precedence: bulk PC-Waterhouse Richard wrote: > 1. Why MUST all implementations of ISAKMP support the Internet DOI ? We > have a potential application that has nothing to do with thre Internet. Well, this is the _Internet_ Engineering Task Force afterall. Nothing is stopping you from creating your own DOI. In fact, if you do please share it with the rest of us. At the least it would be edifying for other developers. > 2. A general impression - if you are serious about "MUST", you don't have > enough of them to nail it down to the point that interoperability is > guaranteed. If you have any specific ideas that will guarantee interoperability now is the time to speak up-- the drafts are being edited presently. regards, Dan. To: PC-Waterhouse Richard cc: 'IPSEC Working Group' Subject: Re: isakmp-05.txt In-reply-to: Your message of "Fri, 18 Oct 1996 16:00:00 CDT." <3267F332@smtp-gw.dos.chnt.gtegsc> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 18 Oct 1996 18:03:08 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9610210738.aa23470@neptune.TIS.COM> PC-Waterhouse Richard writes: > 1. Why MUST all implementations of ISAKMP support the Internet DOI ? We > have a potential application that has nothing to do with thre Internet. This is the INTERNET Engineering Task Force. The ISOC police will not handcuff you for implementing something else, but our goal here is to provide protocols for Internet users. You can feel free to use variations on any spec we build for any private application you may have -- just don't call it ISAKMP. Perry Date: Sun, 20 Oct 1996 15:20:40 -0700 From: Ran Atkinson Message-Id: <199610202220.PAA05515@cornpuffs.cisco.com> To: ipsec@TIS.COM Subject: Re: isakmp-05.txt In-Reply-To: <199610182150.OAA07772@spook> References: <3267F332@smtp-gw.dos.chnt.gtegsc> Organization: cisco Systems Sender: ipsec-approval@neptune.tis.com Precedence: bulk Someone wrote: >> 1. Why MUST all implementations of ISAKMP support the Internet DOI ? We >> have a potential application that has nothing to do with thre Internet. Not all implementations of the ISAKMP Base Specification should be required to implement the "Internet DOI" (or "IPsec DOI"), IMHO. In the view of many, it is desirable to decouple the IPsec-specific parts from the base ISAKMP specification for precisely the reason you outline. I am aware of work by others creating other DOIs for ISAKMP that will permit ISAKMP to be used at all layers of a protocol stack. >From an implementer perspective, this is highly desirable because it would facilitate significant amounts of code reuse. Vendors using PF_KEY could use PF_KEY and an ISAKMP daemon to negotiate SAs for any protocol available in a UNIX kernel, for example. IMHO, the draft authors should consider renaming the "Internet DOI" to be "IP Security DOI" because it is very much IPsec-centric in its current form. Further, I would suggest making it a requirement that implementations of the "IP Security DOI" also implement the ISAKMP Base Specification, but NOT requiring all implementations of the ISAKMP Base Specification to implement the "IP Security DOI". Then Dan Harkins responded: >Nothing is stopping you from creating your own DOI. In fact, if you do >please share it with the rest of us. At the least it would be edifying >for other developers. I would encourage this as well. I'll also note that one can publish an Informational RFC on any topic. So if one were (hypothetically) creating an "FastEthernet-layer DOI", then it could be published as an Informational RFC, even though it mightn't be an appropriate topic for standardisation within the IETF. Regards, Ran rja@cisco.com Date: Tue, 22 Oct 1996 14:18:23 -0400 (EDT) Message-Id: <199610221818.OAA20612@carp.morningstar.com> From: Karl Fox To: ipsec@TIS.COM Subject: 40-bit DES Reply-To: Karl Fox Organization: Ascend Communications Sender: ipsec-approval@neptune.tis.com Precedence: bulk Does anybody out there support ESP-DES-CBC using 40-bit keys? If so, how do you restrict the key space? -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 Message-Id: <199610221823.LAA23039@cornpuffs.cisco.com> From: Ran Atkinson Date: Tue, 22 Oct 1996 11:23:41 PDT X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipsec@TIS.COM Subject: [Admin] ESP 3DES MD5 Editor Cc: naganand@ftp.com Sender: ipsec-approval@neptune.tis.com Precedence: bulk All, Paul Lambert and I have appointed Naganand Doraswamy as the document editor to write up an ESP Transform combining Triple-DES, MD5, and Replay Protection. This new transform is to be derived from and as similar as practical to Jim Hughes' ESP DES-CBC MD5 transform. This new transform is intended to become standards-track. It will appear online as draft-ietf-ipsec-esp-3des-md5-*.txt once Naganand has written it up. Paul Lambert Randall Atkinson -- Message-Id: <199610222041.QAA16767@jekyll.piermont.com> To: Karl Fox cc: ipsec@TIS.COM Subject: Re: 40-bit DES In-reply-to: Your message of "Tue, 22 Oct 1996 14:18:23 EDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 22 Oct 1996 16:41:00 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Karl Fox writes: > Does anybody out there support ESP-DES-CBC using 40-bit keys? If so, > how do you restrict the key space? I'm sure you could do it using the lovely IBM CDMF algorithm. On the other hand, given how cheap it is to break a 40 bit key ($0.08, according to Blaze et al), why would you want to? If you are having export problems, move your development, don't cut back on your strength -- unless you are seeking embarassment. Perry Message-Id: <199610230212.WAA02005@smb.research.att.com> X-Authentication-Warning: smb.research.att.com: smb owned process doing -bs To: Karl Fox cc: ipsec@TIS.COM Subject: Re: 40-bit DES Date: Tue, 22 Oct 1996 22:10:07 -0400 From: Steve Bellovin Sender: ipsec-approval@neptune.tis.com Precedence: bulk Does anybody out there support ESP-DES-CBC using 40-bit keys? If so, how do you restrict the key space? The best way I know of is IBM's Commercial Data Masking Facility. However, it's patented. In any event, see @inproceedings{cdmf1, author = {D.B.Johnson and S.M. Matyas and A.V. Le and J.D. Wilkins}, title = "Design of the Commercial Data Masking Facility Data Privacy Algorithm", year = {1993}, booktitle = {Proceedings of the First ACM Conference on Computer and Communications Security}, month = {November}, pages = {93--96} } @article{cdmf2, author = {D.B.Johnson and S.M. Matyas and A.V. Le and J.D. Wilkins}, title = "The Commercial Data Masking Facility ({CDMF}) Data Privacy algorithm", journal = {IBM Jour. of Research and Development}, volume = 38, number = 2, pages = {217--226}, month = {March}, year = 1994, annotate = {CDMF is covered by U.S. patent number 5,323,464.} } Date: Tue, 22 Oct 1996 17:08:03 -0400 (EDT) Message-Id: <199610222108.RAA09089@carp.morningstar.com> From: Karl Fox To: perry@piermont.com Cc: ipsec@TIS.COM Subject: Re: 40-bit DES In-Reply-To: <199610222041.QAA16767@jekyll.piermont.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: ipsec-approval@neptune.tis.com Precedence: bulk Perry E. Metzger writes: > Karl Fox writes: > > Does anybody out there support ESP-DES-CBC using 40-bit keys? If so, > > how do you restrict the key space? > > I'm sure you could do it using the lovely IBM CDMF algorithm. The last time this question was brought up on this list, CDMF was mentioned but it was said IBM had patented it. I was trying to find out what others did, if anybody does it at all. > On the other hand, given how cheap it is to break a 40 bit key > ($0.08, according to Blaze et al), why would you want to? If you are > having export problems, move your development, don't cut back on > your strength -- unless you are seeking embarassment. It wouldn't embarass me at all. If somebody wants to buy it, I'll be happy to create a product that we can sell them. As to exporting development, the NSA told us that not only couldn't we export source with any kind of hook for encryption, we couldn't even hire someone outside of the country to add encryption to an existing product without running afoul of the U.S. laws. Of course, I'm not a lawyer, and am not suggesting that their claims were necessarily valid. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 Received: from relay.hq.tis.com by neptune.TIS.COM id aa19525; 23 Oct 96 13:08 EDT Received: by relay.hq.tis.com; id NAA03941; Wed, 23 Oct 1996 13:12:32 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma003939; Wed, 23 Oct 96 13:12:04 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id NAA00013 for ; Wed, 23 Oct 1996 13:14:09 -0400 (EDT) Received: by relay.hq.tis.com; id NAA03935; Wed, 23 Oct 1996 13:12:02 -0400 Received: from chirality.rsa.com(192.80.211.33) by relay.tis.com via smap (V3.1.1) id xma003929; Wed, 23 Oct 96 13:11:52 -0400 Received: from lobester.rsa.com by RSA.COM with SMTP id AA09911; Wed, 23 Oct 96 10:14:32 PDT Received: by LOBESTER.rsa.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BBC0CB.01E21B30@LOBESTER.rsa.com>; Wed, 23 Oct 1996 10:14:42 -0700 Message-Id: From: Bob Baldwin To: "'ipsec@TIS.COM'" Cc: "'naganand@ftp.com'" Subject: Suggestion for ESP 3DES MD5 document Date: Wed, 23 Oct 1996 10:14:41 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk Naganand, I would like to suggest that when you write-up the triple DES transform that you modularize the document so it is easy to substitute other ciphers and hash functions. My goal is to be able to briefly specify other ESPs by referencing your document. For example, I would love to be able to write a two page Internet draft that fully specifies an ESP with RC5 (16 round, 128 bit keys) and SHA1 hashing by referencing your document and providing an alternative wording for one or two sections of the document. The implications are that your description should be parameterized by the size of the keys for the privacy and integrity transforms, and by the size of the integrity value (hash output). It is probably OK to assume that all ciphers will use 8 byte CBC with an 8 byte IV. The name of the cipher (e.g. DES-EDE) should not be spread throughout the text. --Bob Baldwin RSA Data Security Inc. >---------- >From: Ran Atkinson[SMTP:rja@cisco.com] >Sent: Tuesday, October 22, 1996 11:23 AM >To: ipsec@TIS.COM >Cc: naganand@ftp.com >Subject: [Admin] ESP 3DES MD5 Editor > > >All, > > Paul Lambert and I have appointed Naganand Doraswamy as >the document editor to write up an ESP Transform combining Triple-DES, MD5, >and Replay Protection. This new transform is to be derived from and as >similar as practical to Jim Hughes' ESP DES-CBC MD5 transform. This new >transform is intended to become standards-track. It will appear online >as draft-ietf-ipsec-esp-3des-md5-*.txt once Naganand has written it up. > >Paul Lambert >Randall Atkinson > > > >-- > > > Date: Wed, 23 Oct 1996 14:03:46 -0700 From: Ran Atkinson Message-Id: <199610232103.OAA09819@cornpuffs.cisco.com> To: baldwin@rsa.com Subject: Re: Suggestion for ESP 3DES MD5 document Organization: cisco Systems Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk In article , Bob Baldwin wrote: > I would like to suggest that when you write-up the triple DES >transform that you modularize the document so it is easy to >substitute other ciphers and hash functions. My goal is to be able >to briefly specify other ESPs by referencing your document. Modularity is the primary goal of the editorial changes proposed in Montreal by and being made by Steve Kent. More documents specifying more transforms is (IMHO) not part of the solution here, as Steve Kent so clearly pointed out in Montreal. With a modest amount of luck, we'll eliminate the "transform" concept -- all together -- and replace it with some magic number/algorithm pairs in the IAB Assigned Numbers document (of which only one set each for AH/ESP would be mandatory to implement). At some level, it would be more logical to wait on all new transform specifications until after the modularised base specifications are published. However, the group seems to prefer to proceed forward for now and retrofit those specs back into the new document model later. By basing the 3DES transform draft on the Jim Hughes' Combined ESP draft, these later editorial changes can be done without adversely impacting code. All IMHO. Ran rja@cisco.com Received: from relay.hq.tis.com by neptune.TIS.COM id aa22946; 23 Oct 96 19:18 EDT Received: by relay.hq.tis.com; id TAA11170; Wed, 23 Oct 1996 19:23:13 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma011168; Wed, 23 Oct 96 19:22:51 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id TAA00724 for ; Wed, 23 Oct 1996 19:24:49 -0400 (EDT) Received: by relay.hq.tis.com; id TAA11161; Wed, 23 Oct 1996 19:22:43 -0400 Received: from capone.ch.apollo.hp.com(15.254.24.3) by relay.tis.com via smap (V3.1.1) id xma011157; Wed, 23 Oct 96 19:22:33 -0400 Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id ; Wed, 23 Oct 1996 19:24:33 -0400 Received: from thunk (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.7.5/8.6.12) with ESMTP id TAA01563; Wed, 23 Oct 1996 19:24:13 -0400 (EDT) Message-Id: <199610232324.TAA01563@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: Karl Fox Cc: perry@piermont.com, ipsec@TIS.COM Subject: Re: 40-bit DES In-Reply-To: karl's message of Tue, 22 Oct 1996 17:08:03 -0400. <199610222108.RAA09089@carp.morningstar.com> Date: Wed, 23 Oct 1996 19:24:06 -0400 From: Bill Sommerfeld Sender: ipsec-approval@neptune.tis.com Precedence: bulk I don't think there's value in creating an Internet standard for 40-bit DES ... or 40-bit anything, for that matter. 1) whenever anyone has attempted to measure it, the consensus of the IETF and the IAB has been that IETF security standards should not be watered down to fit export control requirements. 2) given (1), and that full-strength DES is mandatory-to-implement anyway, there's no point in pursuing the standardization of an algorithm which is simultaneously less secure and slower (the key setup phase of an expurgated DES will necessarily be slightly slower than the key setup of real DES). 3) There's also the "deal with the devil" approach: if you endorse the government's "key recovery" initiative and are making progress towards implementing it, the government will allow you to export unescrowed 56-bit crypto for up to two years. I am not endorsing this approach. - Bill Received: from relay.hq.tis.com by neptune.TIS.COM id aa23042; 23 Oct 96 19:22 EDT Received: by relay.hq.tis.com; id TAA11244; Wed, 23 Oct 1996 19:27:13 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma011235; Wed, 23 Oct 96 19:26:46 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id TAA00962 for ; Wed, 23 Oct 1996 19:28:48 -0400 (EDT) Received: by relay.hq.tis.com; id TAA10969; Wed, 23 Oct 1996 19:07:20 -0400 Received: from unknown(129.132.119.131) by relay.tis.com via smap (V3.1.1) id xma010918; Wed, 23 Oct 96 19:03:02 -0400 Received: from kom30.ethz.ch (kom30 [129.132.66.8]) by tik1.ethz.ch (8.7.5/8.7.3) with ESMTP id BAA02319 for ; Thu, 24 Oct 1996 01:04:01 +0200 (MET DST) From: Germano Caronni Received: (from caronni@localhost) by kom30.ethz.ch (8.7.5/8.7.3) id BAA07552 for ipsec@tis.com; Thu, 24 Oct 1996 01:03:59 +0200 (MET DST) Message-Id: <199610232303.BAA07552@kom30.ethz.ch> Subject: A hole in esp-stream-01 To: ipsec@TIS.COM Date: Thu, 24 Oct 1996 01:03:59 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk Hello everybody, in the beginning of September, Angelos Keromytis pointed out a fundamental weakness of esp-stream-01 to me. This weakness is similar to one described in Steve Bellovin draft for the DES-CBC cipher, bute even more dangerous. In the current form, esp-stream can only be used if certain risks are taken into account, or are actively countered. The attacks of Angelos all rely on the fact that there is no strong integrity check in esp-stream. Due to the fact that current MACs are too slow to be used in applications that need stream ciphers for performance purposes, we either need a (about 10 times) faster MAC, or esp-stream has to be enhanced to provide inherent integrity protection... I would like to present the problem here, and then go into possible solutions, being interested what the group thinks of them. Please note that substantial parts of this originate from Angelos. > Host1 communicates with Host2. They use IP tunneling, ESP stream and > no authentication. The format of the packets would be: > > [External IP header] [SPI] [Offset] [Internal IP header] [Payload] > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Encrypted > > Assume: attacker in the middle who also has login access to > Host1/Host2 OR (if Host1/Host2 are firewalls) has access to some > machine(s) behind those firewalls, OR Host1/Host2 don't do any sort of > filtering and have their IP forwarding turned on. > > In any case, attacker does: > Internal_IP_header.destination_address = Destination_Address XOR Attacker_Address > and recomputes the checksum. Now, this might seem hard, but it > actually isn't; the attacker knows in fact all the information on the > Internal IP header except the ip_id field and the checksum. The ip_id > field however is predictable (and in fact, in most IPsec > implementations would just be External_IP_header.ip_id - 1). So the > attacker actually knows all the fields in the header (since he knows > all the other fields, he can compute the checksum). Knowing the > checksum, he can compute the new checksum (with the new destination > address) and then do: > Internal_IP_header.checksum = Old_Checksum XOR New_Checksum > > and then just let the packet go. If attacker has access to the > machine, he can use an alternate local address that the one the > particular application is listening to. > > If UDP is used as the transport protocol (very probable, considering > multicast), the destination port can be changed instead, simplifying > things, if UDP checksums are disabled. If UDP checksums are enabled, > then the value of the (decrypted) checksum should not be reported when > the kernel reports the failed checksum verification, otherwise the > packet can be corrected and resent. Another attack: > [...] i think you can also do it even > if attacker has no access to hosts, unless the destination host is > very very careful: change BOTH source and destination addresses in the > internal IP header to make the packet look like it originated from > some internal host (or the firewall) and destined to some other host > on the Internet (the attacker). So the attacker doesn't *need* to have > access to the machines/networks actually. If he does, there's another > attack which i came up with: just toggle the lowest order bit in the > destination port and in the UDP/TCP checksum; this will allow the > packet to still be valid, but go to another port which the attacker > could be monitoring. Conclusion: > Under the assumptions you gave, all pure encryption algorithms which XOR > the data stream to a key stream are implicitly broken. Possible reactions: > 1) Security Concerns need to be updated that this type of attack is > easy and bound to succeed for any attacker that has access to these > hosts. Attacks are possible if the attacker can actively access the wire. So this is not a good way to go anymore. The algorithm has to be changed! > 2) IPSEC definitively **needs** a fast symmetric MAC. This might be a MAC > with limited strength, as long as it holds longer that reception of data > is perceived as valid. I am working on this, but until now no reasonably > strong and fast MAC has turned up. This would be the best and most > generic counter measure. Still nothing in sight. It is a very strange phenomenon. As soon as you create a fast-enough MAC, breaking it can be done even faster... sigh... > 3) The operation to apply a key stream to the data may be changed. Use > something different from XOR. (e.g. ?) Comments on this one? I was thinking of e.g. a permutation table, where the key stream and the plaintext denote an index, to an entry. > 4) Chain the data such that modification of one byte affects all data (or at > least everything afterwards. This would be the easiest counter-measure > for now. So I said. But how to do it? The best approach IMNSHO is 2). But I see the following alternatives: a) do a CRC over everything but the last 4 bytes, then XOR this CRC to the last 4 bytes before encryption. This just hopes that something different will do the error detection, including the last four bytes... b) Add preceeding plaintext byte and cypertext byte to current byte before encryption. C(n)=C(C(n-1)+P(n-1)+P(n)). This should deny changing plain- text unless you know the plaintext anyway. Comments on this one? Friendly greetings, Germano Caronni -- <...cookie space for rent...> Germano Caronni caronni@tik.ee.ethz.ch http://www.tik.ee.ethz.ch/~caronni PGP-Key-ID:7B7AE5E1 gec@acm.org 997C6DC4AF930A5D2D5D6AEAA196C33B Received: from relay.hq.tis.com by neptune.TIS.COM id aa24442; 23 Oct 96 21:36 EDT Received: by relay.hq.tis.com; id VAA12725; Wed, 23 Oct 1996 21:40:13 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma012716; Wed, 23 Oct 96 21:39:45 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id VAA02692 for ; Wed, 23 Oct 1996 21:41:47 -0400 (EDT) Received: by relay.hq.tis.com; id VAA12711; Wed, 23 Oct 1996 21:39:43 -0400 Received: from tik1.ethz.ch(129.132.119.131) by relay.tis.com via smap (V3.1.1) id xma012709; Wed, 23 Oct 96 21:39:32 -0400 Received: from kom30.ethz.ch (kom30 [129.132.66.8]) by tik1.ethz.ch (8.7.5/8.7.3) with ESMTP id DAA03054; Thu, 24 Oct 1996 03:41:36 +0200 (MET DST) From: Germano Caronni Received: (from caronni@localhost) by kom30.ethz.ch (8.7.5/8.7.3) id DAA09828; Thu, 24 Oct 1996 03:41:33 +0200 (MET DST) Message-Id: <199610240141.DAA09828@kom30.ethz.ch> Subject: Re: A hole in esp-stream-01 To: "Angelos D. Keromytis" Date: Thu, 24 Oct 1996 03:41:33 +0200 (MET DST) Cc: ipsec@TIS.COM In-Reply-To: <199610240134.VAA05857@coredump.cis.upenn.edu> from "Angelos D. Keromytis" at Oct 23, 96 09:34:28 pm X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk Angelos D. Keromytis wrote: > >a) do a CRC over everything but the last 4 bytes, then XOR this CRC to the > > last 4 bytes before encryption. This just hopes that something different > > will do the error detection, including the last four bytes... > At least one of the attacks will still hold (toggling the lower order > bit of the TCP/UDP port in the header and the checksum). Right. But only if nobody checks the checksum over the whole packet, which I just introduced. And yes, I hate myself for doing it, I would much more prefer to have a formal MAC which ist fast enough to calculate such that esp-stream would fit into the cum MAC philosophy of IPSEC. > > >b) Add preceeding plaintext byte and cypertext byte to current byte before > > encryption. C(n)=C(C(n-1)+P(n-1)+P(n)). This should deny changing plain- > > text unless you know the plaintext anyway. > > But the problem is that the attacker already knows the plaintext of > the header...unless i'm missing something ? Yes, I believe he now needs to know the *whole* plaintext. Otherwise all the rest after the header he changed will be garbled. Or do I have a gross mistake in my thinking here? Germano To: Germano Caronni cc: ipsec@TIS.COM Subject: Re: A hole in esp-stream-01 In-reply-to: Your message of "Thu, 24 Oct 1996 01:03:59 +0200." <199610232303.BAA07552@kom30.ethz.ch> Date: Wed, 23 Oct 1996 21:34:28 -0400 From: "Angelos D. Keromytis" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9610240721.aa28311@neptune.TIS.COM> In message <199610232303.BAA07552@kom30.ethz.ch>, Germano Caronni writes: > >a) do a CRC over everything but the last 4 bytes, then XOR this CRC to the > last 4 bytes before encryption. This just hopes that something different > will do the error detection, including the last four bytes... At least one of the attacks will still hold (toggling the lower order bit of the TCP/UDP port in the header and the checksum). >b) Add preceeding plaintext byte and cypertext byte to current byte before > encryption. C(n)=C(C(n-1)+P(n-1)+P(n)). This should deny changing plain- > text unless you know the plaintext anyway. But the problem is that the attacker already knows the plaintext of the header...unless i'm missing something ? -Angelos To: Germano Caronni cc: ipsec@TIS.COM Subject: Re: A hole in esp-stream-01 In-reply-to: Your message of "Thu, 24 Oct 1996 03:41:33 +0200." <199610240141.DAA09828@kom30.ethz.ch> Date: Wed, 23 Oct 1996 21:49:20 -0400 From: "Angelos D. Keromytis" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9610240722.aa28351@neptune.TIS.COM> -----BEGIN PGP SIGNED MESSAGE----- In message <199610240141.DAA09828@kom30.ethz.ch>, Germano Caronni writes: >Right. But only if nobody checks the checksum over the whole packet, which I >just introduced. And yes, I hate myself for doing it, I would much more >prefer to have a formal MAC which ist fast enough to calculate such that >esp-stream would fit into the cum MAC philosophy of IPSEC. Assuming you're using the standard CRC algorithm, i don't see why this would make any difference. That particular change is still possible. >Yes, I believe he now needs to know the *whole* plaintext. Otherwise all >the rest after the header he changed will be garbled. Or do I have a >gross mistake in my thinking here? So, he'll get P(i) + K(i-1)...he can recursively break this, starting from the first ciphertext unit (bit or byte, depending on the algorithm) and working towards the end of the packet. - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMm7LH70pBjh2h1kFAQFbnAP+Pfg/G8ot4Ufs/wQsyVMAE/limc4aW1wy XE+Jy+GJrVuDRLRzkq1cd3fBW90v4t1N59D/JJ1vjMLTsaA7d1ombRQnNKQmwjvF DXif0TLJRRZfFi1SCwrJOgnyqJyVgaEb3wHxX3C/uB4UHem3zDTtjVLDNpakY2Kt C1pfs0FKj80= =vkoW -----END PGP SIGNATURE----- Message-Id: <199610232314.QAA07259@toad.com> To: Karl Fox cc: perry@piermont.com, ipsec@TIS.COM, gnu@toad.com Subject: Re: NSA's opinion on what it's legal to do In-reply-to: <199610222108.RAA09089@carp.morningstar.com> Date: Wed, 23 Oct 1996 16:14:38 -0700 From: John Gilmore Sender: ipsec-approval@neptune.tis.com Precedence: bulk > As to exporting development, the NSA told us that not only couldn't we > export source with any kind of hook for encryption, we couldn't even > hire someone outside of the country to add encryption to an existing > product without running afoul of the U.S. laws. Of course, I'm not a > lawyer, and am not suggesting that their claims were necessarily valid. I am stating, not suggesting, that their claims are deliberately invalid. The NSA regularly lies to people who ask it for advice on export control. They have no reason not to; accomplishing their goal by any legal means is fine by them. Lying by government employees is legal. NSA recently "distanced itself" from statements made by an NSA employee to Dan Bernstein, plaintiff in our lawsuit to overturn the export controls. In an official submission to the court, they cited court cases supporting the position that the advice that government employees give to citizens is not binding on the government and does not define the government's policy. One thing this employee had said to Dan, when he called up asking for advice about his crypto export, was that it wasn't legal to publish export-controlled technical data "with the intent" that it leave the country, even though published materials are exempt from the export controls on technical data. NSA now finds that position hard to defend in court, so they are claiming it never was their "official" position; their employee must simply have been mistaken. We tape-recorded their employee making the statement (with permission), so they couldn't simply deny that he'd said it. Karl, see what happens when you ask for NSA to restate their opinion, in writing. Jerry Rainville of NSA did a tremendous job in this regard a few years back. He convinced the standards committee for digital cellphones that if they even discussed encryption in open meetings, they would violate the ITAR. It was all complete bullshit, of course, but the committee believed it. The result is that digital cellphones ended up with no privacy. Just what NSA wanted -- with almost no effort on their part! In short, if you rely on NSA for legal advice, you have a malicious and untrustworthy lawyer. Get your own export lawyer! Since you're in Ohio, I suggest talking to Peter Junger's lawyers. Peter is a law prof at Case Western who is also challenging the ITAR in court. Try: Gino Scarselli, , +1 216 291 8601; or Raymond Vasvari, , +1 216 522 1925. John PS: Whether you can "export source with any kind of hook for encryption" is at the heart of our court case (see http://www.eff.org/pub/Legal/Cases/Bernstein_v_DoS/). Our judge has already ruled that publication of source code is protected by the First Amendment. The NSA "hook" doctrine (that they can control the distribution of source code that doesn't even include crypto, just hooks where it might be inserted or called) doesn't stand a chance. They are unlikely to prosecute any such case because of the serious risk that the law would be invalidated as a result. Fear, uncertainty and doubt serves their purposes much better than a narrow and enforceable law would. Fortunately for us, vague and overbroad laws are unconstitutional. PPS: Whether you can hire someone outside the country to add encryption to an existing product is legal in many circumstances (in my own opinion, though lawyers have provided signed opinions of counsel concurring with it). I believe that if the work is done by an outside contractor which is less than 50% owned by your company, it's definitely legal. There are probably other circumstances in which it's legal as well. Get a good lawyer to help you figure it out. Received: from relay.hq.tis.com by neptune.TIS.COM id aa00298; 24 Oct 96 9:38 EDT Received: by relay.hq.tis.com; id JAA20137; Thu, 24 Oct 1996 09:42:25 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma020131; Thu, 24 Oct 96 09:42:02 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id JAA17506 for ; Thu, 24 Oct 1996 09:43:58 -0400 (EDT) Received: by relay.hq.tis.com; id JAA20121; Thu, 24 Oct 1996 09:41:56 -0400 Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1.1) id xma020106; Thu, 24 Oct 96 09:41:28 -0400 Received: from [128.89.30.9] (ARA9.BBN.COM [128.89.30.9]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id JAA17207; Thu, 24 Oct 1996 09:43:27 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 24 Oct 1996 09:44:57 -0500 To: Ran Atkinson From: Stephen Kent Subject: Re: Suggestion for ESP 3DES MD5 document Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Ran, Thanks for the reminder message. Work is underway to revise ESP as per the Montreal discussion and resolution, so we ougt not create any new transforms per se. Instead, authors of transforms should go back and develop I-Ds that specify the algorithms used, independent of the combinations of the algorithms. So, we need brief descriptions of DES-CBC, 3DES-CBC, HMAC-MD5, HMAC-SHA1, etc. Steve Received: from relay.hq.tis.com by neptune.TIS.COM id aa01173; 24 Oct 96 10:46 EDT Received: by relay.hq.tis.com; id KAA21667; Thu, 24 Oct 1996 10:50:25 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma021662; Thu, 24 Oct 96 10:50:04 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id KAA21306 for ; Thu, 24 Oct 1996 10:52:01 -0400 (EDT) Received: by relay.hq.tis.com; id KAA21643; Thu, 24 Oct 1996 10:49:56 -0400 Received: from tik1.ethz.ch(129.132.119.131) by relay.tis.com via smap (V3.1.1) id xma021635; Thu, 24 Oct 96 10:49:51 -0400 Received: from kom30.ethz.ch (kom30 [129.132.66.8]) by tik1.ethz.ch (8.7.5/8.7.3) with ESMTP id QAA11074; Thu, 24 Oct 1996 16:51:56 +0200 (MET DST) From: Germano Caronni Received: (from caronni@localhost) by kom30.ethz.ch (8.7.5/8.7.3) id QAA10704; Thu, 24 Oct 1996 16:51:51 +0200 (MET DST) Message-Id: <199610241451.QAA10704@kom30.ethz.ch> Subject: Re: A hole in esp-stream-01 To: "Angelos D. Keromytis" Date: Thu, 24 Oct 1996 16:51:51 +0200 (MET DST) Cc: ipsec@TIS.COM In-Reply-To: <199610240149.VAA06155@coredump.cis.upenn.edu> from "Angelos D. Keromytis" at Oct 23, 96 09:49:20 pm X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk Angelos D. Keromytis wrote: > > So, he'll get P(i) + K(i-1)...he can recursively break this, starting > from the first ciphertext unit (bit or byte, depending on the > algorithm) and working towards the end of the packet. This works only if he knows the contents of the whole packet. And in that case, he can create a bgous one all by himself... He can not 'break' it, he can just try to fix the chaining for the part of the packet he knows. And if he does not know the whole packet, he can not fix the whole packet? Germano Posted-Date: Thu, 24 Oct 1996 13:21:44 -0400 Message-Id: <9610241722.AA77338@aurora.cis.upenn.edu> To: Germano Caronni Cc: ipsec@TIS.COM Subject: Re: A hole in esp-stream-01 In-Reply-To: Your message of "Thu, 24 Oct 1996 16:51:51 +0200." <199610241451.QAA10704@kom30.ethz.ch> Date: Thu, 24 Oct 1996 13:21:44 -0400 From: "Angelos D. Keromytis" Sender: ipsec-approval@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In message <199610241451.QAA10704@kom30.ethz.ch>, Germano Caronni writes: >This works only if he knows the contents of the whole packet. And >in that case, he can create a bgous one all by himself... He can not 'break' >it, he can just try to fix the chaining for the part of the packet he knows. >And if he does not know the whole packet, he can not fix the whole packet? He doesn't need to fix the chaining for the rest of the packet; he'll get the target to remove the encryption, and then he can fix the chaining himself, since he knows both the original plaintext/ciphertext and the changed plaintext/ciphertext for the begining of the packet and then he can fix the remainder of it one bit/byte at a time. The problem is that the chaining and the encryption algorithm commute (sp ?). - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMm+lp70pBjh2h1kFAQGz4QP9GB/a/Nhon/QZmTPJriac7WpQifT5nMwU dakifDbjUVMHhypJXMUKfQI6Z/pQ+h+WocNsg7peBBWQWr4067M4yEXexaZNBPhh Tw+2trdqznTsyPx1XzMfLQwU7zqltNtY/8S6U6sJwKXFnOD+jDg4cRg3mpbEy5oz tzPuI+iKUS4= =Uwt8 -----END PGP SIGNATURE----- Received: from relay.hq.tis.com by neptune.TIS.COM id aa03692; 24 Oct 96 13:26 EDT Received: by relay.hq.tis.com; id NAA26444; Thu, 24 Oct 1996 13:30:26 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma026442; Thu, 24 Oct 96 13:30:13 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id NAA29991 for ; Thu, 24 Oct 1996 13:32:04 -0400 (EDT) Received: by relay.hq.tis.com; id NAA26420; Thu, 24 Oct 1996 13:29:57 -0400 Received: from tik1.ethz.ch(129.132.119.131) by relay.tis.com via smap (V3.1.1) id xma026406; Thu, 24 Oct 96 13:29:27 -0400 Received: from kom30.ethz.ch (kom30 [129.132.66.8]) by tik1.ethz.ch (8.7.5/8.7.3) with ESMTP id TAA12259; Thu, 24 Oct 1996 19:31:29 +0200 (MET DST) From: Germano Caronni Received: (from caronni@localhost) by kom30.ethz.ch (8.7.5/8.7.3) id TAA00763; Thu, 24 Oct 1996 19:31:21 +0200 (MET DST) Message-Id: <199610241731.TAA00763@kom30.ethz.ch> Subject: Re: A hole in esp-stream-01 To: "Angelos D. Keromytis" Date: Thu, 24 Oct 1996 19:31:21 +0200 (MET DST) Cc: ipsec@TIS.COM In-Reply-To: <9610241722.AA77338@aurora.cis.upenn.edu> from "Angelos D. Keromytis" at Oct 24, 96 01:21:44 pm X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk Angelos D. Keromytis wrote: > He doesn't need to fix the chaining for the rest of the packet; he'll > get the target to remove the encryption, and then he can fix the > chaining himself, since he knows both the original [...] > The problem is that the chaining and the encryption algorithm commute (sp ?). I agree. This problem is valid if the decrypting entity does not check for integrity. (I assumed this check would take place.) We are back to square one: Add a *fast* MAC to stream ciphers. Germano Received: from relay.hq.tis.com by neptune.TIS.COM id aa03803; 24 Oct 96 13:33 EDT Received: by relay.hq.tis.com; id NAA26586; Thu, 24 Oct 1996 13:37:26 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma026582; Thu, 24 Oct 96 13:37:03 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id NAA00319 for ; Thu, 24 Oct 1996 13:39:02 -0400 (EDT) Received: by relay.hq.tis.com; id NAA26565; Thu, 24 Oct 1996 13:36:59 -0400 Received: from chirality.rsa.com(192.80.211.33) by relay.tis.com via smap (V3.1.1) id xma026555; Thu, 24 Oct 96 13:36:50 -0400 Received: from lobester.rsa.com by RSA.COM with SMTP id AA15782; Thu, 24 Oct 96 10:39:27 PDT Received: by LOBESTER.rsa.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BBC197.A6C2FE40@LOBESTER.rsa.com>; Thu, 24 Oct 1996 10:39:36 -0700 Message-Id: From: Bob Baldwin To: 'naganand' Cc: "'ipsec@TIS.COM'" Subject: Revised suggestion for ESP 3DES MD5 document Date: Thu, 24 Oct 1996 10:39:35 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk Naganand, Given that Steve Kent is modularizing the IPSec documents, let me retract my suggestion since it is likely to cause delays. It is more important to me to have a strong ESP quickly, than a modular specification. --Bob >---------- >From: Ran Atkinson[SMTP:rja@cisco.com] >Sent: Wednesday, October 23, 1996 2:03 PM >To: Bob Baldwin >Cc: ipsec@TIS.COM >Subject: Re: Suggestion for ESP 3DES MD5 document > >Bob Baldwin wrote: > >> I would like to suggest that when you write-up the triple DES >>transform that you modularize the document so it is easy to >>substitute other ciphers and hash functions. My goal is to be able >>to briefly specify other ESPs by referencing your document. > > Modularity is the primary goal of the editorial changes proposed in >Montreal >by and being made by Steve Kent. More documents specifying more transforms >is >(IMHO) not part of the solution here, as Steve Kent so clearly pointed out in >Montreal. > > With a modest amount of luck, we'll eliminate the "transform" concept >-- all together -- and replace it with some magic number/algorithm pairs >in the IAB Assigned Numbers document (of which only one set each for AH/ESP >would be mandatory to implement). > > At some level, it would be more logical to wait on all new transform >specifications until after the modularised base specifications are >published. However, the group seems to prefer to proceed forward for >now and retrofit those specs back into the new document model later. >By basing the 3DES transform draft on the Jim Hughes' Combined ESP >draft, these later editorial changes can be done without adversely >impacting code. > >All IMHO. > >Ran >rja@cisco.com > > > > > > > Received: from relay.hq.tis.com by neptune.TIS.COM id aa07001; 24 Oct 96 17:21 EDT Received: by relay.hq.tis.com; id RAA03355; Thu, 24 Oct 1996 17:25:19 -0400 From: HUGO@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma003343; Thu, 24 Oct 96 17:24:50 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id RAA14700 for ; Thu, 24 Oct 1996 17:26:51 -0400 (EDT) Received: by relay.hq.tis.com; id RAA03338; Thu, 24 Oct 1996 17:24:49 -0400 Received: from unknown(129.34.139.18) by relay.tis.com via smap (V3.1.1) id xma003335; Thu, 24 Oct 96 17:24:33 -0400 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id RAA17994; Thu, 24 Oct 1996 17:26:30 -0400 Received: from yktvmv.watson.ibm.com (yktvmv.watson.ibm.com [9.117.33.29]) by mailhub1.watson.ibm.com (8.8.0/10-23-96) with SMTP id RAA702108; Thu, 24 Oct 1996 17:26:20 -0400 Message-Id: <199610242126.RAA702108@mailhub1.watson.ibm.com> Received: from YKTVMV by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 5100; Thu, 24 Oct 96 17:26:17 EDT Date: Thu, 24 Oct 96 15:35:22 EDT To: kent@bbn.com, rja@cisco.com cc: ipsec@TIS.COM Subject: Suggestion for ESP 3DES MD5 document Sender: ipsec-approval@neptune.tis.com Precedence: bulk Ref: Your note of Thu, 24 Oct 1996 09:44:57 -0500 (attached) > Ran, > > Thanks for the reminder message. Work is underway to revise ESP as > per the Montreal discussion and resolution, so we ougt not create any new > transforms per se. Instead, authors of transforms should go back and > develop I-Ds that specify the algorithms used, independent of the > combinations of the algorithms. So, we need brief descriptions of DES-CBC, > 3DES-CBC, HMAC-MD5, HMAC-SHA1, etc. > > Steve > I have submitted a while ago an informational RFC on HMAC. The description is independent of any combination of algorithms or any particular application (and not tied to MD5 or SHA), so you (and others) may find it useful. SInce the process of RFC publication is taking very long these days, I will send in the next message the draft RFC as I submitted to the IESG. Hugo > Received: from relay.hq.tis.com by neptune.TIS.COM id aa07018; 24 Oct 96 17:21 EDT Received: by relay.hq.tis.com; id RAA03369; Thu, 24 Oct 1996 17:25:49 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma003365; Thu, 24 Oct 96 17:25:26 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id RAA14707 for ; Thu, 24 Oct 1996 17:27:23 -0400 (EDT) Received: by relay.hq.tis.com; id RAA03354; Thu, 24 Oct 1996 17:25:19 -0400 Received: from unknown(129.34.139.18) by relay.tis.com via smap (V3.1.1) id xma003349; Thu, 24 Oct 96 17:25:16 -0400 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id RAA04968 for ; Thu, 24 Oct 1996 17:27:33 -0400 Received: from copacabana.watson.ibm.com (copacabana.watson.ibm.com [9.2.19.74]) by mailhub1.watson.ibm.com (8.8.0/10-23-96) with SMTP id RAA47723 for ; Thu, 24 Oct 1996 17:27:23 -0400 Received: by copacabana.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA16911; Thu, 24 Oct 1996 17:27:21 -0400 Date: Thu, 24 Oct 1996 17:27:21 -0400 From: "H.Krawczyk" Message-Id: <9610242127.AA16911@copacabana.watson.ibm.com> To: ipsec@TIS.COM Subject: HMAC rfc draft (long) Sender: ipsec-approval@neptune.tis.com Precedence: bulk Network Working Group H. Krawczyk Request for Comments: xxxx M. Bellare Category: Informational R. Canetti August 1996 HMAC: Keyed-Hashing for Message Authentication Status of This Memo This memo provides information for the Internet community. This memo does not specify an Internet. Distribution of this memo is unlimited. Abstract This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. Krawczyk, Bellare & Canetti [Page i] RFC XXXX HMAC June 1996 1. Introduction Providing a way to check the integrity of information transmitted over or stored in an unreliable medium is a prime necessity in the world of open computing and communications. Mechanisms that provide such integrity check based on a secret key are usually called "message authentication codes" (MAC). Typically, message authentication codes are used between two parties that share a secret key in order to validate information transmitted between these parties. In this document we present such a MAC mechanism based on cryptographic hash functions. This mechanism, called HMAC, is based on work by the authors [BCK1] where the construction is presented and cryptographically analyzed. We refer to that work for the details on the rationale and security analysis of HMAC, and its comparison to other keyed-hash methods. HMAC can be used in combination with any iterated cryptographic hash function. MD5 and SHA-1 are examples of such hash functions. HMAC also uses a secret key for calculation and verification of the message authentication values. The main goals behind this construction are * To use, without modifications, available hash functions. In particular, hash functions that perform well in software, and for which code is freely and widely available. * To preserve the original performance of the hash function without incurring in a significant degradation. * To use and handle keys in a simple way. * To have a well understood cryptographic analysis of the strength of the authentication mechanism based on reasonable assumptions on the underlying hash function. * To allow for easy replaceability of the underlying hash function in case that faster or more secure hash functions are found or required. This document specifies HMAC using a generic cryptographic hash function (denoted by H). Specific instantiations of HMAC need to define a particular hash function. Current candidates for such hash functions include SHA-1 [SHA], MD5 [MD5], RIPEMD-128/160 [RIPEMD]. These different realizations of HMAC will be denoted by HMAC-SHA1, HMAC-MD5, HMAC-RIPEMD, etc. Note: To the date of writing of this document MD5 and SHA-1 are the most widely used cryptographic hash functions. MD5 has been recently shown to be vulnerable to collision search attacks [Dobb1, Dobb2]. This attack and other currently known weaknesses of MD5 do not compromise the use of MD5 within HMAC as specified in this document (see [Dobb2]); however, SHA-1 appears to be a cryptographically stronger function. To this date, MD5 can be considered for use in HMAC for applications where the superior performance of MD5 is Krawczyk, Bellare & Canetti [Page 1] RFC XXXX HMAC June 1996 critical. In any case, implementers and users need to be aware of possible cryptanalytic developments regarding any of these cryptographic hash functions, and the eventual need to replace the underlying hash function. (See section 6 for more information on the security of HMAC.) 2. Definition of HMAC The definition of HMAC requires a cryptographic hash function, which we denote by H, and a secret key K. We assume H to be a cryptographic hash function where data is hashed by iterating a basic compression function on blocks of data. We denote by B the byte-length of such blocks (B=64 for all the above mentioned examples of hash functions), and by L the byte-length of hash outputs (L=128 for MD5, L=160 for SHA-1). The authentication key K can be of any length up to B, the block length of the hash function. Applications that use keys longer than B bytes will first hash the key using H and then use the resultant L byte string as the actual key to HMAC. In any case the minimal recommended length for K is L bytes (as the hash output length). See section 3 for more information on keys. We define two fixed and different strings ipad and opad as follows (the 'i' and 'o' are mnemonics for inner and outer): ipad = the byte 0x36 repeated B times opad = the byte 0x5C repeated B times. To compute HMAC over the data `text' we perform H(K XOR opad, H(K XOR ipad, text)) Namely, (1) append zeros to the end of K to create a B byte string (e.g., if K is of length 20 bytes and B=64, then K will be appended with 44 zero bytes 0x00) (2) XOR (bitwise exclusive-OR) the B byte string computed in step (1) with ipad (3) append the data stream 'text' to the B byte string resulting from step (2) (4) apply H to the stream generated in step (3) (5) XOR (bitwise exclusive-OR) the B byte string computed in step (1) with opad (6) append the H result from step (4) to the B byte string resulting from step (5) (7) apply H to the stream generated in step (6) and output the result For illustration purposes, sample code based on MD5 is provided as an appendix. Krawczyk, Bellare & Canetti [Page 2] RFC XXXX HMAC June 1996 3. Keys The key for HMAC can be of any length (keys longer than B bytes are first hashed using H). However, less than L bytes is strongly discouraged as it would decrease the security strength of the function. Keys longer than L bytes are acceptable but the extra length would not significantly increase the function strength. (A longer key may be advisable if the randomness of the key is considered weak.) Keys need to be chosen at random (or using a cryptographically strong pseudo-random generator seeded with a random seed), and periodically refreshed. (Current attacks do not indicate a specific recommended frequency for key changes as these attacks are practically infeasible. However, periodic key refreshment is a fundamental security practice that helps against potential weaknesses of the function and keys, and limits the damage of an exposed key.) 4. Implementation Note HMAC is defined in such a way that the underlying hash function H can be used with no modification to its code. In particular, it uses the function H with the pre-defined initial value IV (a fixed value specified by each iterative hash function to initialize its compression function). However, if desired, a performance improvement can be achieved at the cost of (possibly) modifying the code of H to support variable IVs. The idea is that the intermediate results of the compression function on the B-byte blocks (K XOR ipad) and (K XOR opad) can be precomputed only once at the time of generation of the key K, or before its first use. These intermediate results are stored and then used to initialize the IV of H each time that a message needs to be authenticated. This method saves, for each authenticated message, the application of the compression function of H on two B-byte blocks (i.e., on (K XOR ipad) and (K XOR opad)). Such a savings may be significant when authenticating short streams of data. We stress that the stored intermediate values need to be treated and protected the same as secret keys. (Choosing to implement HMAC in the above way is a decision of the local implementation and has no effect on inter-operability.) 5. Truncated output A well-known practice with message authentication codes is to truncate the output of the MAC and output only part of the bits (e.g., [MM, ANSI]). Preneel and van Oorschot [PV] show some analytical advantages of truncating the output of hash-based MAC functions. The results in this area are not absolute as for the overall security advantages of truncation. It has advantages (less information on the hash result available to an attacker) and disadvantages (less bits to predict for the attacker). Applications of HMAC can choose to truncate the output of HMAC by outputting the t leftmost bits of the Krawczyk, Bellare & Canetti [Page 3] RFC XXXX HMAC June 1996 HMAC computation for some parameter t (namely, the computation is carried in the normal way as defined in section 2 above but the end result is truncated to t bits). We recommend that the output length t be not less than half the length of the hash output (to match the birthday attack bound) and not less than 80 bits (a suitable lower bound on the number of bits that need to be predicted by an attacker). We propose denoting a realization of HMAC that uses a hash function H with t bits of output as HMAC-H-t. For example, HMAC-SHA1-80 denotes HMAC computed using the SHA-1 function and with the output truncated to 80 bits. (If the parameter t is not specified, e.g. HMAC-MD5, then it is assumed that all the bits of the hash are output.) 6. Security The security of the message authentication mechanism presented here depends on cryptographic properties of the hash function H: the resistance to collision finding (limited to the case where the initial value is secret and random, and where the output of the function is not explicitly available to the attacker), and the message authentication property of the compression function of H when applied to single blocks (in HMAC these blocks are partially unknown to an attacker as they contain the result of the inner H computation and, in particular, cannot be fully chosen by the attacker). These properties, and actually stronger ones, are commonly assumed for hash functions of the kind used with HMAC. In particular, a hash function for which the above properties do not hold would become unsuitable for most (probably, all) cryptographic applications, including alternative message authentication schemes based on such functions. (For a complete analysis and rationale of the HMAC function the reader is referred to [BCK1].) Given the limited confidence gained so far as for the cryptographic strength of candidate hash functions, it is important to observe the following two properties of the HMAC construction and its secure use for message authentication: 1. The construction is independent of the details of the particular hash function H in use and then the latter can be replaced by any other secure (iterative) cryptographic hash function. 2. Message authentication, as opposed to encryption, has a "transient" effect. A published breaking of a message authentication scheme would lead to the replacement of that scheme, but would have no adversarial effect on information authenticated in the past. This is in sharp contrast with encryption, where information encrypted today may suffer from exposure in the future if, and when, the encryption algorithm is broken. The strongest attack known against HMAC is based on the frequency of collisions for the hash function H ("birthday attack") [PV,BCK2], and is totally impractical for minimally reasonable hash functions. Krawczyk, Bellare & Canetti [Page 4] RFC XXXX HMAC June 1996 As an example, if we consider a hash function like MD5 where the output length equals L=16 the attacker needs to acquire the correct message authentication tags computed (with the _same_ secret key K!) on about 2**64 known plaintexts. This would require the processing of at least 2**64 blocks under H, an impossible task in any realistic scenario (for a block length of 64 bytes this would take 250,000 years in a continuous 1Gbps link, and without changing the secret key K during all this time). This attack could become realistic only if serious flaws in the collision behavior of the function H are discovered (e.g. collisions found after 2**30 messages). Such a discovery would determine the immediate replacement of the function H (the effects of such failure would be far more severe for the traditional uses of H in the context of digital signatures, public key certificates, etc.). Note: this attack needs to be strongly contrasted with regular collision attacks on cryptographic hash functions where no secret key is involved and where 2**64 off-line parallelizable (!) operations suffice to find collisions. The latter attack is approaching feasibility [VW] while the birthday attack on HMAC is totally impractical. (In the above examples, if one uses a hash function with, say, 160 bit of output then 2**64 should be replaced by 2**80.) A correct implementation of the above construction, the choice of random (or cryptographically pseudorandom) keys, a secure key exchange mechanism, frequent key refreshments, and good secrecy protection of keys are all essential ingredients for the security of the integrity verification mechanism provided by HMAC. Appendix -- Sample Code The following sample code for the implementation of HMAC-MD5 and corresponding test vectors are provided for the sake of illustration only (it is based on MD5 code as described in [MD5]). /* ** Function: hmac_md5 */ void hmac_md5(text, text_len, key, key_len, digest) unsigned char* text; /* pointer to data stream */ int text_len; /* length of data stream */ unsigned char* key; /* pointer to authentication key */ int key_len; /* length of authentication key */ caddr_t digest; /* caller digest to be filled in */ { MD5_CTX context; unsigned char k_ipad[65]; /* inner padding - key XORd with ipad */ unsigned char k_opad[65]; /* outer padding - key XORd with opad */ unsigned char tk[16]; int i; Krawczyk, Bellare & Canetti [Page 5] RFC XXXX HMAC June 1996 /* sanity check parameters */ if ((text == NULL) || (key == NULL) || (digest == NULL)) /* most heinous, probably should log something */ return; /* if key is longer than 64 bytes reset it to key=MD5(key) */ if (key_len > 64) { MD5_CTX tctx; MD5Init(&tctx); MD5Update(&tctx, key, key_len); MD5Final(tk, &tctx); key = tk; key_len = 16; } /* * the HMAC_MD5 transform looks like: * * MD5(K XOR opad, MD5(K XOR ipad, text)) * * where K is an n byte key * ipad is the byte 0x36 repeated 64 times * opad is the byte 0x5c repeated 64 times * and text is the data being protected */ /* start out by storing key in pads */ bzero( k_ipad, sizeof k_ipad); bzero( k_opad, sizeof k_opad); bcopy( key, k_ipad, key_len); bcopy( key, k_opad, key_len); /* XOR key with ipad and opad values */ for (i=0; i<64; i++) { k_ipad[i] ^= 0x36; k_opad[i] ^= 0x5c; } /* * perform inner MD5 */ MD5Init(&context); /* init context for 1st pass */ MD5Update(&context, k_ipad, 64) /* start with inner pad */ MD5Update(&context, text, text_len); /* then text of datagram */ MD5Final(digest, &context); /* finish up 1st pass */ /* * perform outer MD5 */ MD5Init(&context); /* init context for 2nd pass */ MD5Update(&context, k_opad, 64); /* start with outer pad */ MD5Update(&context, digest, 16); /* then results of 1st hash */ MD5Final(digest, &context); /* finish up 2nd pass */ } Krawczyk, Bellare & Canetti [Page 6] RFC XXXX HMAC June 1996 Test Vectors: key = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b key_len = 16 data = "Hi There" digest = 0x9294727a3638bb1c13f48ef8158bfc9d key = "Jefe" data = "what do ya want for nothing?" digest = 0x750c783e6ab0b503eaa86e310a5db738 key = 0xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA key_len 16 data = 0xDDDDDDDDDDDDDDDDDDDD... ..DDDDDDDDDDDDDDDDDDDD... ..DDDDDDDDDDDDDDDDDDDD... ..DDDDDDDDDDDDDDDDDDDD... ..DDDDDDDDDDDDDDDDDDDD data_len = 50 digest = 0x56be34521d144c88dbb8c733f0e8b3f6 Acknowledgments Pau-Chen Cheng, Jeff Kraemer, and Michael Oehler, have provided useful comments on early drafts, and ran the first interoperability tests of this specification. Jeff and Pau-Chen kindly provided the sample code and test vectors that appear in the appendix. Burt Kaliski, Bart Preneel, Matt Robshaw, Adi Shamir, and Paul van Oorschot have provided useful comments and suggestions during the investigation of the HMAC construction. References [ANSI] ANSI X9.9, ``American National Standard for Financial Institution Message Authentication (Wholesale),'' American Bankers Association, 1981. Revised 1986. [Atk] R. Atkinson, "IP Authentication Header", RFC-1826, August 1995. [BCK1] M. Bellare, R. Canetti, and H. Krawczyk, "Keyed Hash Functions and Message Authentication", Proceedings of Crypto'96, LNCS 1109, pp. 1-15. (http://www.research.ibm.com/security/keyed-md5.html) [BCK2] M. Bellare, R. Canetti, and H. Krawczyk, "Pseudorandom Functions Revisited: The Cascade Construction", Proceedings of FOCS'96. [Dobb1] H. Dobbertin, "MD5 is not collision-free", Manuscript, 1996. [Dobb2] H. Dobbertin, "The Status of MD5 After a Recent Attack", RSA Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996. http://www.rsa.com/rsalabs/pubs/cryptobytes.html Krawczyk, Bellare & Canetti [Page 7] RFC XXXX HMAC June 1996 [PV] B. Preneel and P. van Oorschot, "Building fast MACs from hash functions", Advances in Cryptology -- CRYPTO'95 Proceedings, Lecture Notes in Computer Science, Springer-Verlag Vol.963, 1995, pp. 1-14. [MD5] Ronald Rivest, "The MD5 Message-Digest Algorithm", RFC-1321, DDN Network Information Center, April 1992. [MM] Meyer, S. and Matyas, S.M., Cryptography, New York Wiley, 1982. [RIPEMD] H. Dobbertin, A. Bosselaers, and B. Preneel, "RIPEMD-160: A strengthened version of RIPEMD", Fast Software Encryption, LNCS Vol 1039, pp. 71-82. ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/bosselae/ripemd/. [SHA] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995. [Tsu] G. Tsudik, "Message authentication with one-way hash functions", In Proceedings of Infocom'92, May 1992. (Also in "Access Control and Policy Enforcement in Internetworks", Ph.D. Dissertation, Computer Science Department, University of Southern California, April 1991.) [VW] P. van Oorschot and M. Wiener, "Parallel Collision Search with Applications to Hash Functions and Discrete Logarithms", Proceedings of the 2nd ACM Conf. Computer and Communications Security, Fairfax, VA, November 1994. Authors Address Hugo Krawczyk IBM T.J. Watson Research Center P.O.Box 704 Yorktown Heights, NY 10598 hugo@watson.ibm.com Mihir Bellare Dept of Computer Science and Engineering Mail Code 0114 University of California at San Diego 9500 Gilman Drive La Jolla, CA 92093 mihir@cs.ucsd.edu Ran Canetti IBM T.J. Watson Research Center P.O.Box 704 Yorktown Heights, NY 10598 canetti@watson.ibm.com Krawczyk, Bellare & Canetti [Page 8] . > To: Karl Fox > Cc: perry@piermont.com, ipsec@TIS.COM > Subject: Re: 40-bit DES > Date: Wed, 23 Oct 1996 19:24:06 -0400 > From: Bill Sommerfeld > Sender: ipsec-approval@neptune.hq.tis.com Sender: ipsec-approval@neptune.tis.com Precedence: bulk Date: Thu, 24 Oct 96 17:35:34 EDT From: ipsec-approval@neptune.tis.com Message-ID: <9610241735.aa07187@neptune.TIS.COM> > I don't think there's value in creating an Internet standard for > 40-bit DES ... or 40-bit anything, for that matter. Certainly of rather limited value. > 1) whenever anyone has attempted to measure it, the consensus of the > IETF and the IAB has been that IETF security standards should not be > watered down to fit export control requirements. I fully agree with this stand. > 2) given (1), and that full-strength DES is mandatory-to-implement > anyway, there's no point in pursuing the standardization of an > algorithm which is simultaneously less secure and slower (the key > setup phase of an expurgated DES will necessarily be slightly slower > than the key setup of real DES). Not enough to be an issue. > 3) There's also the "deal with the devil" approach: if you endorse > the government's "key recovery" initiative and are making progress > towards implementing it, the government will allow you to export > unescrowed 56-bit crypto for up to two years. I am not endorsing this > approach. I agree with this too. However, since the standard is internationaly public and countries outside the US have DES, they can develop their own IPsec implementations. Because of the standard, we can interoperate with these other products and have the full strength encryption. This will effectively circumvent the ITAR and make it rather moot. The big problem is that us US vendors won't be able to sell our products overseas, but the overseas vendors will be selling their products here. Time to lobby some more against stupid export restrictions. -- Regards, -------------------------------------------------------------------------- Sunny Azah - sazah@ibu.sj.nec.com Internet Business Unit, Home of the PrivateNet NEC Technologies, Inc. 110 Rio Robles San Jose, CA 95134 Tel:(408) 433-2161 FAX:(408) 433-1230 http://www.privatenet.nec.com -------------------------------------------------------------------------- Received: from relay.hq.tis.com by neptune.TIS.COM id aa07589; 24 Oct 96 18:12 EDT Received: by relay.hq.tis.com; id SAA04225; Thu, 24 Oct 1996 18:16:49 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma004221; Thu, 24 Oct 96 18:16:20 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id SAA16077 for ; Thu, 24 Oct 1996 18:18:21 -0400 (EDT) Received: by relay.hq.tis.com; id SAA04217; Thu, 24 Oct 1996 18:16:19 -0400 Received: from ns.newbridge.com(192.75.23.67) by relay.tis.com via smap (V3.1.1) id xma004215; Thu, 24 Oct 96 18:16:05 -0400 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id SAA27590 for ; Thu, 24 Oct 1996 18:18:12 -0400 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma027529; Thu Oct 24 18:17:37 1996 Received: from tsntsrv2.timestep.com ([192.168.219.191]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id SAA19684 for ; Thu, 24 Oct 1996 18:17:31 -0400 Received: by tsntsrv2.timestep.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BBC1D7.BA3167B0@tsntsrv2.timestep.com>; Thu, 24 Oct 1996 18:18:16 -0400 Message-ID: From: Andrew Robison To: 'Germano Caronni' Cc: "'ipsec@TIS.COM'" Subject: RE: A hole in esp-stream-01 Date: Thu, 24 Oct 1996 18:18:15 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk >From: Germano Caronni[SMTP:caronni@tik.ee.ethz.ch] >Sent: October 24, 1996 1:31 PM >Subject: Re: A hole in esp-stream-01 > >I agree. This problem is valid if the decrypting entity does not check for >integrity. (I assumed this check would take place.) >We are back to square one: Add a *fast* MAC to stream ciphers. > How about the following: start with the values of: C1(0)=0x674502301 C2(0)=0xefcdab89 which are the first two start values for MD5. They could of course be random number if you wanted this to be keyed. C1(N+1)=C(N)+B(N) which is easily predictable as if you know the plaintext bit you want to change, all you need to do is flip all of the appropriate bits based upon what it does to the count. Not good enough, so: C2(N+1)=ROTL(C2(N)+C1(N+1),C2(N)>>5) which is much harder to predict unless you know all of the plaintext. Finally, the checksum H is produced: H=ROTL(C2(N),C2(N)>>5)^ROTL(C2(N),C2(N)>>23) Cost is about 6 operations/byte which means that a P90 should be able to churn through over 15MB/sec. Rather than XOR the checksum with the last four bytes of the packet as was suggested, which allows for changing these four bytes' values, add four more bytes to the packet as is done with ESP DES-MD5. Which raises the question: When using ESP with DES or 3DES, why do I need a cryptographically strong hash function since the hash is encrypted? In order to be able to successfully modify the packet and still create a valid hash would require breaking the encryption. We are not actually talking about a non-repudiation issue with a digital signature; a cryptographically secure hash appears to be overkill and using a keyed hash even more so. Received: from relay.hq.tis.com by neptune.TIS.COM id aa07907; 24 Oct 96 18:44 EDT Received: by relay.hq.tis.com; id SAA04811; Thu, 24 Oct 1996 18:48:49 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma004809; Thu, 24 Oct 96 18:48:20 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id SAA16691 for ; Thu, 24 Oct 1996 18:50:21 -0400 (EDT) Received: by relay.hq.tis.com; id SAA04805; Thu, 24 Oct 1996 18:48:19 -0400 Received: from ftp.com(128.127.2.122) by relay.tis.com via smap (V3.1.1) id xma004802; Thu, 24 Oct 96 18:48:11 -0400 Received: from ftp.com by ftp.com ; Thu, 24 Oct 1996 18:50:08 -0400 Received: from mailserv-2high.ftp.com by ftp.com ; Thu, 24 Oct 1996 18:50:08 -0400 Received: from athena by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id SAA11009; Thu, 24 Oct 1996 18:50:03 -0400 Message-Id: <2.2.32.19961024225548.00bf114c@mailserv-H.ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 24 Oct 1996 18:55:48 -0400 To: ipsec@TIS.COM From: Naganand Doraswamy Subject: Clarification on 3DES transforms Sender: ipsec-approval@neptune.tis.com Precedence: bulk I have questions on key generation for 3DES transform, which mode of 3DES we should be standardizing on and number of keys we should be using. I would appreciate the group's input on this. 1. I am assuming that we will support 3 key version and not 2 key version. Is there any need for us to support 2 key version? 2. Do we need to give an option whether to use inner-CBC or outer-CBC or can we assume that we will support only outer-CBC. According to Schneier, inner-CBC is less secure against differential attacks but is faster to implement as you can parallelize encryption. 3. We can generate the keys in multiple ways. I would like to get opinions on the cryptographic strengths of the keys generated using these options: Option 1: -------- DES_Key_I = Truncate(MD5( D_Pad_I | K ),192) DES_KEY_I1 = first 64 bits of DES_KEY_I DES_KEY_I2 = second 64 bits of DES_KEY_I DES_KEY_I3 = third 64 bits of DES_KEY_I D_Pad_I = 0x5c repeated 64 times DES_KEY_R = Truncate( MD5(D_Pad_R | K ), 192) DES_KEY_R1 = first 64 bits of DES_KEY_R DES_KEY_R2 = second 64 bits of DES_KEY_R DES_KEY_R3 = third 64 bits of DES_KEY_R D_Pad_R = 0x3a repeated 64 times Option 2: --------- DES_Key_I1 = Truncate(MD5( D_Pad_I1 | K ),64) DES_Key_I2 = Truncate(MD5( D_Pad_I2 | K ),64) DES_Key_I3 = Truncate(MD5( D_Pad_I3 | K ),64) DES_Key_R1 = Truncate(MD5( D_Pad_R1 | K ),64) DES_Key_R2 = Truncate(MD5( D_Pad_R2 | K ),64) DES_Key_R3 = Truncate(MD5( D_Pad_R3 | K ),64) where D_Pad_I1 = 0x5C repeated 64 times D_Pad_I2 = 0xA3 repeated 64 times D_Pad_I3 = 0xCA repeated 64 times D_Pad_R1 = 0x3A repeated 64 times D_Pad_R2 = 0xA5 repeated 64 times D_Pad_R3 = 0xC3 repeated 64 times Thanks, --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) Received: from relay.hq.tis.com by neptune.TIS.COM id aa09445; 24 Oct 96 20:45 EDT Received: by relay.hq.tis.com; id UAA06956; Thu, 24 Oct 1996 20:49:34 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma006952; Thu, 24 Oct 96 20:49:07 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id UAA18820 for ; Thu, 24 Oct 1996 20:51:07 -0400 (EDT) Received: by relay.hq.tis.com; id UAA06945; Thu, 24 Oct 1996 20:49:04 -0400 Received: from capone.ch.apollo.hp.com(15.254.24.3) by relay.tis.com via smap (V3.1.1) id xma006938; Thu, 24 Oct 96 20:48:50 -0400 Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id ; Thu, 24 Oct 1996 20:50:56 -0400 Received: from thunk (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.7.5/8.6.12) with ESMTP id UAA02112; Thu, 24 Oct 1996 20:50:54 -0400 (EDT) Message-Id: <199610250050.UAA02112@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: Naganand Doraswamy Cc: ipsec@TIS.COM Subject: Re: Clarification on 3DES transforms In-Reply-To: naganand's message of Thu, 24 Oct 1996 18:55:48 -0400. <2.2.32.19961024225548.00bf114c@mailserv-H.ftp.com> Date: Thu, 24 Oct 1996 20:50:52 -0400 From: Bill Sommerfeld Sender: ipsec-approval@neptune.tis.com Precedence: bulk > DES_Key_I = Truncate(MD5( D_Pad_I | K ),192) > DES_KEY_I1 = first 64 bits of DES_KEY_I > DES_KEY_I2 = second 64 bits of DES_KEY_I > DES_KEY_I3 = third 64 bits of DES_KEY_I MD5 only produces 128 bits of output, so this is not going to work very well ... you can't produce I3 because DES_KEY_I only has 128 bits, and you've also wasted 16 bits of entropy because of the @!#^%^& DES key parity. Note that if you use SHA instead, you get 160 bits out. If you use the bits efficiently, you only need 168 (not 192). Where do you find the remaining 8 bits? I'm not endorsing the second one, mind you; I want to hear what the Real Cryptographers(tm) have to say about it.. - Bill Received: from relay.hq.tis.com by neptune.TIS.COM id aa10245; 24 Oct 96 22:15 EDT Received: by relay.hq.tis.com; id WAA07943; Thu, 24 Oct 1996 22:19:34 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma007941; Thu, 24 Oct 96 22:19:07 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id WAA20553 for ; Thu, 24 Oct 1996 22:21:06 -0400 (EDT) Received: by relay.hq.tis.com; id WAA07933; Thu, 24 Oct 1996 22:19:04 -0400 Received: from janus.border.com(199.71.190.98) by relay.tis.com via smap (V3.1.1) id xma007929; Thu, 24 Oct 96 22:18:37 -0400 Received: by janus.border.com id <18461-2>; Thu, 24 Oct 1996 22:18:43 -0400 Message-Id: <96Oct24.221843edt.18461-2@janus.border.com> To: ipsec@TIS.COM Subject: Re: Clarification on 3DES transforms References: <199610250050.UAA02112@thunk.orchard.medford.ma.us> In-reply-to: sommerfeld's message of "Thu, 24 Oct 1996 20:50:52 -0400". <199610250050.UAA02112@thunk.orchard.medford.ma.us> From: "C. Harald Koch" Organization: Secure Computing Canada Ltd. Phone: +1 416 368 7157 X-uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Thu, 24 Oct 1996 22:20:38 -0400 Sender: ipsec-approval@neptune.tis.com Precedence: bulk In message <199610250050.UAA02112@thunk.orchard.medford.ma.us>, Bill Sommerfeld writes: > > DES_Key_I = Truncate(MD5( D_Pad_I | K ),192) > > DES_KEY_I1 = first 64 bits of DES_KEY_I > > DES_KEY_I2 = second 64 bits of DES_KEY_I > > DES_KEY_I3 = third 64 bits of DES_KEY_I > > MD5 only produces 128 bits of output, so this is not going to work > very well ... I've seen specs that say: DES_Key_I = MD5(D_Pad_I | K) DES_KEY_1 = first 64 bits of DES_KEY_I DES_KEY_2 = second (and last) 64 bits of DES_KEY_I DES_Key_II = MD5(D_Pad_I | K | K); DES_KEY_3 = first 64 bits of DES_Key_II Same question; how do the Real Cryptographers feel about this one? -- C. Harald Koch | Senior System Developer, Secure Computing Canada Ltd. chk@border.com | 20 Toronto Street, Suite 400, Toronto ON M5C 2B8 +1 416 368 7157 (voice) | "Madness takes its toll. Please have exact change." +1 416 368 7789 (fax) | -Karen Murphy Received: from relay.hq.tis.com by neptune.TIS.COM id aa11345; 25 Oct 96 0:13 EDT Received: by relay.hq.tis.com; id AAA09041; Fri, 25 Oct 1996 00:18:05 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma009039; Fri, 25 Oct 96 00:17:38 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id AAA21948 for ; Fri, 25 Oct 1996 00:19:36 -0400 (EDT) Received: by relay.hq.tis.com; id AAA09032; Fri, 25 Oct 1996 00:17:35 -0400 Received: from btw.plaintalk.bellevue.wa.us(204.157.220.237) by relay.tis.com via smap (V3.1.1) id xma009028; Fri, 25 Oct 96 00:17:24 -0400 Received: from imo.plaintalk.bellevue.wa.us (imo.plaintalk.bellevue.wa.us [192.168.1.7]) by btw.plaintalk.bellevue.wa.us (8.7.6/8.7.3/dpg hack 01aug96) with ESMTP id VAA23541; Thu, 24 Oct 1996 21:19:29 -0700 (PDT) Received: (from dennisg@localhost) by imo.plaintalk.bellevue.wa.us (8.7.5/8.7.3/dpg hack 5may96) id VAA22821; Thu, 24 Oct 1996 21:19:28 -0700 (PDT) Message-Id: <199610250419.VAA22821@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Dennis Glatting Date: Thu, 24 Oct 96 21:19:26 -0700 To: Naganand Doraswamy Subject: Re: Clarification on 3DES transforms cc: ipsec@TIS.COM Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: <2.2.32.19961024225548.00bf114c@mailserv-H.ftp.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk Date: Thu, 24 Oct 1996 18:55:48 -0400 From: Naganand Doraswamy > 2. Do we need to give an option whether to use inner-CBC or > outer-CBC or can we assume that we will support only > outer-CBC. According to Schneier, inner-CBC is less > secure against differential attacks but is faster to > implement as you can parallelize encryption. > Biham, in his paper "Cryptanalysis of Triple-Modes of Operation", shows inner-CBC (CBC|CBC|CBC) is weak requiring 2^34 plaintexts, 2^60 steps, and 2^33 memory whereas outer-CBC (ECB|ECB|ECB) requires 3 plaintexts, 2^113 steps, and 2^56 memory. -dpg To: Bill Sommerfeld cc: Naganand Doraswamy , ipsec@TIS.COM Subject: Re: Clarification on 3DES transforms Date: Thu, 24 Oct 1996 23:17:05 -0400 From: Steven Bellovin Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9610250719.aa14757@neptune.TIS.COM> > DES_Key_I = Truncate(MD5( D_Pad_I | K ),192) > DES_KEY_I1 = first 64 bits of DES_KEY_I > DES_KEY_I2 = second 64 bits of DES_KEY_I > DES_KEY_I3 = third 64 bits of DES_KEY_I MD5 only produces 128 bits of output, so this is not going to work very well ... you can't produce I3 because DES_KEY_I only has 128 bits, and you've also wasted 16 bits of entropy because of the @!#^%^& DES key parity. Note that if you use SHA instead, you get 160 bits out. If you use the bits efficiently, you only need 168 (not 192). Where do you find the remaining 8 bits? I'm not endorsing the second one, mind you; I want to hear what the Real Cryptographers(tm) have to say about it.. I don't know if I qualify as a Real Cryptographer, but there is another alternative worth mentioning. Given that K is long enough, we have enough input entropy to generate all the DES keys we need. I suggest using DES_Key_i = Truncate(MD5( D_Pad_I | i | K), 64) for i=1, 2, 3. In other words, toss a counter into the mix. Comments? Received: from relay.hq.tis.com by neptune.TIS.COM id aa16418; 25 Oct 96 9:37 EDT Received: by relay.hq.tis.com; id JAA15474; Fri, 25 Oct 1996 09:41:42 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma015471; Fri, 25 Oct 96 09:41:17 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id JAA02003 for ; Fri, 25 Oct 1996 09:43:15 -0400 (EDT) Received: by relay.hq.tis.com; id JAA15460; Fri, 25 Oct 1996 09:41:12 -0400 Received: from fe3.rust.net(204.157.12.254) by relay.tis.com via smap (V3.1.1) id xma015454; Fri, 25 Oct 96 09:41:07 -0400 Received: from netx.nei.com (netx.nei.com [204.157.42.17]) by Fe3.rust.net (8.8.2/8.8.0) with SMTP id JAA15564 for ; Fri, 25 Oct 1996 09:42:25 -0400 (EDT) Received: from cc:Mail by netx.nei.com id AA846261751; Fri, 25 Oct 96 09:25:36 EST Date: Fri, 25 Oct 96 09:25:36 EST From: "Pluth, Rick" Message-Id: <9609258462.AA846261751@netx.nei.com> To: ipsec@TIS.COM Subject: ESP and AH on a secure gateway Sender: ipsec-approval@neptune.tis.com Precedence: bulk I am developing a secure gateway, i.e. providing encryption on behalf of my trusted subnet. This gateway will be using ESP tunnel-mode and AH. secure (untrusted) secure host gateway----------------------------gateway host | | | | ---------- ----------- (untrusted subnet) (trusted subnet) After reading and discussing the appropriate RFC's (1825, 1826, etc), I'm a little confused on how to use a combination of ESP and AH. To clarify, if I receive a packet from a trusted host, should I authenticate this IP packet, add in the AH, and then encrypt and add the ESP header? Such as: (IP hdr H = IP hdr produced by trusted host IP hdr G = IP hdr produced by gateway) From trusted host: |IP hdr H|data| | v On Gateway: |IP hdr H|AH|data| | v On Gateway: |IP hdr G|ESP hdr|encrypted(IP hdr H|AH|data)| OR, Should I encrypt the received IP packet and add the ESP header, and THEN authenticate this data. Such as From trusted host: |IP hdr H|data| | v On Gateway: |IP hdr G|ESP hdr|encrypted(IP hdr H|data)| | v On Gateway: |IP hdr G|AH hdr|ESP hdr|encrypted(IP hdr H|data)| In the first method, I'm authenticating the trusted host's clear-text packet, while in the second method, I am authenticating the ESP packet my gateway has produced. I am inclined to say the latter method is more appropriate for a gateway, since I shouldn't be authenticating "someone else's" data. Opinions? -- Rick Pluth (rpluth@nei.com) Date: Fri, 25 Oct 1996 09:57:20 -0400 From: Hilarie Orman Message-Id: <199610251357.JAA12001@earth.hpc.org> To: naganand@ftp.com Cc: ipsec@TIS.COM In-reply-to: Yourmessage <199610242352.QAA10534@baskerville.CS.Arizona.EDU> Subject: Re: Clarification on 3DES transforms Sender: ipsec-approval@neptune.tis.com Precedence: bulk The OAKLEY draft discusses how to turn raw keying material into keys, and I'd suggest that you follow that method, which adds an extra byte to the keying material before generating a hash. It is important, I think, to have a uniform method for taking raw keying material (a varible length integer) and turning it into keys for a transform. I'd suggest that each transform come equipped with an interface for generating its key from a VPI input. Hilarie Received: from relay.hq.tis.com by neptune.TIS.COM id aa06695; 25 Oct 96 18:14 EDT Received: by relay.hq.tis.com; id SAA02796; Fri, 25 Oct 1996 18:18:44 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma002789; Fri, 25 Oct 96 18:18:16 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id SAA05221 for ; Fri, 25 Oct 1996 18:20:14 -0400 (EDT) Received: by relay.hq.tis.com; id SAA02785; Fri, 25 Oct 1996 18:18:14 -0400 Received: from germany-c.it.earthlink.net(204.250.46.123) by relay.tis.com via smap (V3.1.1) id xma002783; Fri, 25 Oct 96 18:18:06 -0400 Received: from rmonsour (max5-wc-ca-02.earthlink.net [206.149.209.52]) by germany.it.earthlink.net (8.7.5/8.7.3) with SMTP id PAA18985; Fri, 25 Oct 1996 15:20:03 -0700 (PDT) Message-Id: <3.0b36.32.19961025152056.00706a64@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0b36 (32) Date: Fri, 25 Oct 1996 15:20:59 -0700 To: Stephen Kent From: Bob Monsour Subject: Re: Suggestion for ESP 3DES MD5 document Cc: ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Steve, At 09:44 AM 10/24/96 -0500, you wrote: > Thanks for the reminder message. Work is underway to revise ESP as >per the Montreal discussion and resolution, so we ougt not create any new >transforms per se. Instead, authors of transforms should go back and >develop I-Ds that specify the algorithms used, independent of the >combinations of the algorithms. So, we need brief descriptions of DES-CBC, >3DES-CBC, HMAC-MD5, HMAC-SHA1, etc. Having just created a "new transform", I thought it best to alert the list of a new internet draft for 3DES-CBC (see below). Note that it also adds compression, HMAC and replay prevention. It is based on Hughes DES-CBC draft. Given the move to define the algorithms separately and provide the algorithm selection information in the ESP document, I would like to propose that optional use of compression be added as an integral part of ESP. The only discussion of compression to date has in brief mention within some of the key management protocol drafts. Additionally, another draft (draft-thayer-seccomp-00.txt) has been proposed to provide compression within an ESP payload. With the increasingly pervasive use of compression within PPP, all of the encryption that will be done to implement VPNs (or any other network layer encryption applications) will end up costing businesses additional line charges due to the inability to compress encrypted data. When you're talking about T1 rates and greater, this is not small change. As a result, I think it is critical for the ipsec framework to support the optional use of compression. I would also suggest that the additional fields be included in a revised ESP. I propose that the newly submitted draft (see below) along with the Thayer draft be examined as starting points for such discussion. On the specifics of the 3DES included in the draft below, as someone else on the list had mentioned earlier (don't recall who), ANSI is currently nearing completion on a 3DES draft (X9.52). The 3DES in our draft is based (in part) on that work. Comments are appreciated. Bob Monsour rmonsour@earthlink.net > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Combined 3DES-CBC, LZS Compression, HMAC, and > Replay Prevention ESP Transform > Author(s) : M. Sabin, R. Monsour > Filename : draft-sabin-esp-des3-lzs-md5-00.txt > Pages : 18 > Date : 10/23/1996 > >This document proposes the "3DES-CBC-LZS-HMAC-Replay" security transform >for the IP Encapsulating Security Payload (ESP). The proposed transform >combines triple-DES encryption, LZS compression, HMAC authentication, and >replay prevention into a single packet format. The transform is compatible >with implementations that do not support compression and with >implementations that support only single-DES encryption. Compression is >performed prior to encryption, which has the side benefit of reducing the >amount of data that must be encrypted. > >This document is based on the IPsec Working Group's proposed "Combined >DES-CBC, HMAC, and Replay Prevention Security Transform," cited later in >this document. > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-sabin-esp-des3-lzs-md5-00.txt". >A URL for the Internet-Draft is: >ftp://ds.internic.net/internet-drafts/draft-sabin-esp-des3-lzs-md5-00.txt > >Internet-Drafts directories are located at: > > o Africa: ftp.is.co.za > > o Europe: nic.nordu.net > ftp.nis.garr.it > > o Pacific Rim: munnari.oz.a > > o US East Coast: ds.internic.net > > o US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ds.internic.net. In the body type: > "FILE /internet-drafts/draft-sabin-esp-des3-lzs-md5-00.txt". > >NOTE: The mail server at ds.internic.net can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e., documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version >of the Internet-Draft. > > > Received: from relay.hq.tis.com by neptune.TIS.COM id aa23584; 25 Oct 96 23:39 EDT Received: by relay.hq.tis.com; id XAA05646; Fri, 25 Oct 1996 23:43:44 -0400 From: HUGO@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma005643; Fri, 25 Oct 96 23:43:16 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id XAA08678 for ; Fri, 25 Oct 1996 23:45:14 -0400 (EDT) Received: by relay.hq.tis.com; id XAA05639; Fri, 25 Oct 1996 23:43:14 -0400 Received: from igw3.watson.ibm.com(129.34.139.18) by relay.tis.com via smap (V3.1.1) id xma005637; Fri, 25 Oct 96 23:42:52 -0400 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id XAA12474; Fri, 25 Oct 1996 23:45:00 -0400 Received: from yktvmv.watson.ibm.com (yktvmv.watson.ibm.com [9.117.33.29]) by mailhub1.watson.ibm.com (8.7.1/10-23-96) with SMTP id XAA649569; Fri, 25 Oct 1996 23:44:49 -0400 Message-Id: <199610260344.XAA649569@mailhub1.watson.ibm.com> Received: from YKTVMV by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 6026; Fri, 25 Oct 96 23:44:46 EDT Date: Fri, 25 Oct 96 23:24:18 EDT To: ipsec@TIS.COM cc: ho@earth.hpc.org, naganand@ftp.com Subject: Key derivation Sender: ipsec-approval@neptune.tis.com Precedence: bulk > The OAKLEY draft discusses how to turn raw keying material into keys, > and I'd suggest that you follow that method, which adds an extra byte > to the keying material before generating a hash. It is important, I think, > to have a uniform method for taking raw keying material (a varible length > integer) and turning it into keys for a transform. > > I'd suggest that each transform come equipped with an interface for > generating its key from a VPI input. > > Hilarie I strongly support the approach suggested by Hilarie. (I hope I understand it correctly). In particular, I'd like to emphasize the rationale to this approach, and some of the important issues, as I see them. One can think of the key exchange protocol as providing a single key to the communicating parties (we refer to that key as the "raw keying material" or RKM). The individual keys required by specific transforms (DES, HMAC, etc) are then derived from that RKM. An important issue is whether it is up to the documents describing the individual transforms to define how a key for that particular transform is derived from RKM or whether it is the key exchange mechanism itself responsible for that key derivation. I argue that the latter is the right approach. Indeed the only way to achieve "computational independence" between keys for different transforms is to have a unified mechanism defined by the key exchange protocol (By "computational independence" of the keys I mean that the compromise of the key used by transform A will have no effect on the security of the key used by transform B even if both keys were derived from the same RKM. This property is needed not only in the case of explicit compromise but to prevent cryptanalytical attacks based on dependencies between keys). The main ingredient to achieve this computational independence is to derive the per-algorithm keys by cryptographically combining the key RKM with a *unique* identifier for the specific algorithm. Such unique identifiers could be the IANA assigned numbers for the transforms (which are required in any case for security parameter negotiation), or any other related encoding (e.g., the IANA number repeated 17 times, etc.) If this cryptographic copmbination is done, for example, through a strong keyed hash, say, H(alg-id, RKM) then keys derived using different values of alg-id should be computationally independent even if the same RKM is used. (If, in contrast, one lets each transform define its own key material from RKM then one could easily end with different transforms that derive the same or related key bits. I can easily imagine seeing DES and HMAC-MD5 sharing key bits, or 3DES-CBC and 3DES-CBC-MAC using the exact same key). It is ok if a particular transform "requests" from the key exchange a certain number of bits and then defines a way to expand this key (or apply any other manipulation to it). As long as the basic key provided to this transform is independent from the keys provided to other algorithms then the internal work of one transform is irrelevant to the security of the others. Therefore, we see that the required "interface" between a transform and the key exchange engine is a mechanism by which the transform specifies the number of (pseudorandom) bits that it needs as key material. (Another parameter in this interface is the cryptographic strength of these bits, but this is a complex issue that I prefer not to discuss here.) Since different transforms will request different numbers of key bits we need the key exchange to support a well-defined mechanism to derive such a variable number of key bits. Two main approaches are: -- Concatenate ouputs of the hash function computed using an increasing counter: H(algorithm-id, 0, RKM), H(algorithm-id, 1, RKM), H(algorithm-id, 2, RKM),. .. for as many times as needed to get all the necessary bits (e.g., if H is MD5 and the algorithm is 3DES you'll use counter with 0 and 1 to get 256 bits of output and then choose the first 192 bits). -- Iterate on the derived keys. For example, the first block of bits is derived by K1 = H(algorithm-id, RKM), the second block by K2 = H(K1, RKM) etc. Many variants exist, e.g. to use only part of the bits of K1, K2,... for the derived key. Two final remarks: 1) I used the example of keyed hash because it is very popular these days. In general when deriving keys (or pseudorandom strings) one should be talking about pseudorandom functions (not just keyed hashing). Not only is this term a more accurate one but, more importantly, it includes many functions which are NOT keyed hash functions. For example, it is perfectly correct (and probably *more secure*) to use 3DES as the derivation algorithm instead of a keyed hash. Similarly, any other block cipher (like IDEA) can be used for key derivation, even if these ciphers are NOT keyed hash functions. One more advantage of the notion of pseudorandom functions is that it makes very clear the distinction between keys and arguments to the function. This distinction is less clear in keyed hash functions and a good source for design mistakes. (Fortunately, Oakley already incorporate the pseudorandom function -- prf -- terminolgy.) 2) Using alg-id to get key independence may not always be sufficient. For example, one may have the need to derive keys for a version of RC5 with 12 rounds and another for RC5 with 20 rounds. In that case, again, the keys need to be independent, and the number of rounds reflected, or added, to the alg-id identifier. Similarly, one may need to derive two independent keys for the *same* algorithm (e.g., DES used to conceal identities and DES used to encrypt data). In such a case a differentiation via different alg-id values or additional information is necessary. Hugo Received: from relay.hq.tis.com by neptune.TIS.COM id aa29168; 26 Oct 96 3:31 EDT Received: by relay.hq.tis.com; id DAA07119; Sat, 26 Oct 1996 03:36:17 -0400 From: JMKELSEY@delphi.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma007094; Sat, 26 Oct 96 03:35:49 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id DAA10209 for ; Sat, 26 Oct 1996 03:37:45 -0400 (EDT) Received: by relay.hq.tis.com; id DAA07090; Sat, 26 Oct 1996 03:35:46 -0400 Received: from bos1e.delphi.com(192.80.63.5) by relay.tis.com via smap (V3.1.1) id xma007088; Sat, 26 Oct 96 03:35:31 -0400 Received: from delphi.com by delphi.com (PMDF V5.0-7 #10880) id <01IB31UAFNGC8ZINVB@delphi.com> for ipsec@tis.com; Sat, 26 Oct 1996 03:37:35 -0500 (EST) Date: Sat, 26 Oct 1996 03:37:35 -0500 (EST) Subject: Re: A hole in esp-stream-01 To: ipsec@TIS.COM Message-id: <01IB31UAFX3I8ZINVB@delphi.com> X-VMS-To: INTERNET"ipsec@tis.com" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Sender: ipsec-approval@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- [ To: IPSec mailing list ## Date: 10/25/96 08:21 pm ## Subject: RE: A hole in esp-stream-01 ] >Date: Thu, 24 Oct 1996 18:18:15 -0400 >From: Andrew Robison >Subject: RE: A hole in esp-stream-01 >How about the following: > >start with the values of: > C1(0)=0x674502301 > C2(0)=0xefcdab89 > >which are the first two start values for MD5. They could of course be >random number if you wanted this to be keyed. > > C1(N+1)=C(N)+B(N) > >which is easily predictable as if you know the plaintext bit you want to >change, all you need to do is flip all of the appropriate bits based >upon what it does to the count. Not good enough, so: > > C2(N+1)=ROTL(C2(N)+C1(N+1),C2(N)>>5) > >which is much harder to predict unless you know all of the plaintext. >Finally, the checksum H is produced: > > H=ROTL(C2(N),C2(N)>>5)^ROTL(C2(N),C2(N)>>23) > >Cost is about 6 operations/byte which means that a P90 should be able to >churn through over 15MB/sec. > >Rather than XOR the checksum with the last four bytes of the packet as >was suggested, which allows for changing these four bytes' values, add >four more bytes to the packet as is done with ESP DES-MD5. One way to attack this kind of system is to find generic ways to change the plaintext that lead to the same MAC with some fairly high probability. Let's think about ways to do this: This is a restatement of the MAC: All variables here are 32-bit words: for(i=0;i>5)&31); } mac_output = rol(c2,(c2>>5)&31)^rol(c2,(c2>>23)&31); Now, it's immediately clear how to alter c1--it's actually under our complete control if we control the plaintext. If we can only flip desired bits (rather than, say, adding 32-bit values in), then we lose a little control over this, but not too much. Let's suppose we want to make c1 differ modulo 2^{32} by values a, then b, then go back to not differing. How do we have to change the plaintext? (Here x* means the altered form of x.) D[4]* = D[4] ..... c1[4]* = c1[4] D[5]* = D[5] + a ..... c1[5]* = c1[5] + a D[6]* = D[6] + b - a ..... c1[6]* = c1[6] + b D[7]* = D[7] - b ..... c1[7]* = c1[7] These values for D4..7 will cause c1 to differ by 0,a,b,0, and will allow no propogation in c1. This still leaves us with c2 to worry about. Okay, so now we need to also undo the change in c2. The trick here is to either know or guess the rotation amount for c2 going into each step. Let's choose (a,b) so that b = -a mod 2^{32}. In that case, we now cause c1 to change by 0,a,-a,0 by causing the above changes in the plaintext. Now, let's think about this: c2[4]* = c2[4] c2[5]* = rol(c2[5] + a,j) c2[6]* = rol(c2[6] - a,k) c2[7]* = c2[7] This works iff j = 0, which happens with probability 2^{-5}. Thus, we get: 1. If the plaintext before the change is made is known, and the starting state is known, then we can make changes in the plaintext without affecting the MAC with certainty of success. (We have to vary the attack slightly to deal with different rotation counts, but it's fundamentally not much of a problem.) 2. If the plaintext before the change, or the starting state, are unknown, then we can make changes in the plaintext with a 2^{-5} probability of success. Note that the added munging at the end has nothing to do with this attack, since by the time that happens, we've already returned the state back to normal. The only loose thread with this analysis is that we're talking about not having complete control of the plaintext--instead, we're hitting it through an XOR encryption. What we actually need to be able to do is to add and subtract 32-bit numbers into the plaintext. This is straightforward if we know the original values we want to change (XOR in the original one, then XOR in the new value desired). However, if we don't know them, we can still flip bits. In this case, we flip bits instead of adding and subtracting numbers. Now, here's the trick: if we flip bit i in a word, we either add or subtract 2^i. So, for the attack above, we might try to flip bit i in three consecutive words. With probability 2^{-3}, this part would work properly, and if it did, then we'd have a 2^{-5} probability of not altering the final checksum. Unless I'm missing something, the final probability of successfully making the change is 2^{-8}. In short: I don't think this MAC is strong enough to be useful. The big problem with a lot of this kind of scheme is that we don't get good diffusion in our intermediate ``chaining'' variables. Anytime we fail to get good diffusion there, it seems like an attacker can find ways to manipulate those internal values. (This is why, say, one-round MD4 isn't useful as a MAC, at least not directly.) A couple of ideas that might be interesting: 1. Use two instances of the keystream generator, one for encryption, and one for authentication. The authentication one simply encrypts the plaintext into an intermediate value which is MACed. An attacker never sees this intermediate value, and it should change (along with the encrypting keystream) for each packet. 2. Find some internal function for the MAC which doesn't have any good XOR-based differentials. (That is, make its differentials something that are hard to get to with XOR differences in the plaintext, which are the only ones the attacker can cleanly get into the MAC.) Some ideas here include using S-boxes that are optimized to have no high-probability XOR differentials, using multiplication mod 2^{16}+1, as in IDEA, or using some kind of nonlinear binary functions as in MD4 or Haval. Addition-with-rotation alone doesn't seem like it will be enough, unless it's iterated a huge number of times, as in TEA. Also, I think it makes sense to do a big one-time precomputation (as in Blowfish or Khufu) ahead of time. >Which raises the question: > >When using ESP with DES or 3DES, why do I need a cryptographically >strong hash function since the hash is encrypted? In order to be able to >successfully modify the packet and still create a valid hash would >require breaking the encryption. We are not actually talking about a >non-repudiation issue with a digital signature; a cryptographically >secure hash appears to be overkill and using a keyed hash even more so. Actually, I think this general idea (hash the data, then encrypt the hash) has been discussed a few times as a valid MAC design. I can see a couple possible problems with it, off the top of my head: 1. If you can cause collisions in the hash function (i.e., MD5), then you can cause collisions in the MAC, as well. (I don't think this is all that upsetting--once your hash function has stopped resisting collisions, it's time to retire it.) More to the point, collision values can be found offline--they don't require interaction with the user. Admittedly, getting the pair of collision values into encrypted form is still going to be pretty complicated. 2. I think doing this in CBC-mode may add some complications to the analysis. Among other things, we have to make sure the IV gets hashed along with the data. Does anyone else know of cryptanalysis of this kind of scheme? Of course, we often want to be able to give the ability to authenticate data without the ability to decrypt it. In that case, this scheme isn't acceptable, but simply encrypting the hash (probably in ECB-mode) is. We also would probably want to do a *little* something to make precomputation-type attacks harder, so we might do MAC_K(X) = e_K(md5(e_K(512 bit pad),packet_data)). Note that the intermediate result from that first 512-bit hash is only computed once, and is then stored. Comments? --John Kelsey, jmkelsey@delphi.com / kelsey@counterpane.com PGP 2.6 fingerprint = 4FE2 F421 100F BB0A 03D1 FE06 A435 7E36 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMnG7l0Hx57Ag8goBAQEK9AQAgJvu5MlTBaYDE0fs00h9Sh05b6rIgu8C lzCuzwsbSlPmc/19H04iI6aFzSe4dkDJeK0zdkpG7zC/9wyfSdpuiKPua1meepcp /ihqjuPJrXhfWiu7d/Iwyh73m145g0yVzQdfCFlJmWG5tjJ3dhDxPOfZ/s1J0UGp +ohnNj4YjYI= =RrAD -----END PGP SIGNATURE----- Received: from relay.hq.tis.com by neptune.TIS.COM id aa29027; 26 Oct 96 3:30 EDT Received: by relay.hq.tis.com; id DAA07085; Sat, 26 Oct 1996 03:35:16 -0400 From: JMKELSEY@delphi.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma007079; Sat, 26 Oct 96 03:34:49 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id DAA10204 for ; Sat, 26 Oct 1996 03:36:45 -0400 (EDT) Received: by relay.hq.tis.com; id DAA07075; Sat, 26 Oct 1996 03:34:46 -0400 Received: from bos1d.delphi.com(192.80.63.4) by relay.tis.com via smap (V3.1.1) id xma007072; Sat, 26 Oct 96 03:34:34 -0400 Received: from delphi.com by delphi.com (PMDF V5.0-7 #10880) id <01IB31SYG3YO8ZINVB@delphi.com> for ipsec@tis.com; Sat, 26 Oct 1996 03:36:33 -0500 (EST) Date: Sat, 26 Oct 1996 03:36:33 -0500 (EST) Subject: Re: A hole in esp-stream-01 To: ipsec@TIS.COM Message-id: <01IB31SYGDLU8ZINVB@delphi.com> X-VMS-To: INTERNET"ipsec@tis.com" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Sender: ipsec-approval@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- [ To: IPSec mailing list ## Date: 10/24/96 01:06 pm ## Subject: Re: A hole in esp-stream-01 ] >Date: Thu, 24 Oct 1996 03:41:33 +0200 (MET DST) >From: Germano Caronni >Subject: Re: A hole in esp-stream-01 >Angelos D. Keromytis wrote: >> >a) do a CRC over everything but the last 4 bytes, then XOR this CRC to the >> > last 4 bytes before encryption. This just hopes that something different >> > will do the error detection, including the last four bytes... >> At least one of the attacks will still hold (toggling the lower order >> bit of the TCP/UDP port in the header and the checksum). > >Right. But only if nobody checks the checksum over the whole packet, which I >just introduced. And yes, I hate myself for doing it, I would much more >prefer to have a formal MAC which ist fast enough to calculate such that >esp-stream would fit into the cum MAC philosophy of IPSEC. >> >b) Add preceeding plaintext byte and cypertext byte to current byte before >> > encryption. C(n)=C(C(n-1)+P(n-1)+P(n)). This should deny changing plain- >> > text unless you know the plaintext anyway. >> >> But the problem is that the attacker already knows the plaintext of >> the header...unless i'm missing something ? > >Yes, I believe he now needs to know the *whole* plaintext. Otherwise all >the rest after the header he changed will be garbled. Or do I have a >gross mistake in my thinking here? If I'm understanding your description, above, then we have something like: Encrypting: C[i] = K[i] XOR (P[i] + C[i-1] + P[i-1]) Decrypting: P[i] = (C[i] XOR K[i]) - (C[i-1]+P[i-1]). This means that anything you do that leaves C[i-1]+P[i-1] unchanged won't propogate. For example, suppose that I know the high bit of P[4] is zero, but that bit of C[4] is a one. To change this so that the receiver will get the high bit of P[4] as a one, all I do is flip that bit in the ciphertext. Now, when we're decrypting, we get the following: (Let T be the vector with only the high bit on.) P[4]* = (C[4] XOR K[4] XOR T) - (C[3] + P[3]) = P[4] XOR T P[5]* = (C[5] XOR K[5]) - (C[4]* + P[4]*) Now, remember, we turned the high bit off in the ciphertext byte, and on in the plaintext byte. What this means is that we subtracted 128 from the ciphertext byte, and added it back in the plaintext byte. Thus, (C[4]* + P[4]*) = (C[4] + P[4]). If we have to also deal with the CRC of this, so long as the CRC polynomial is known, we can just flip the bits that would have changed in the CRC, right? >Germano --John Kelsey, jmkelsey@delphi.com / kelsey@counterpane.com PGP 2.6 fingerprint = 4FE2 F421 100F BB0A 03D1 FE06 A435 7E36 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMnG7f0Hx57Ag8goBAQG1tAP/QyCnMx33jqdL3ILuVYUozWDL/5+TN8Qe /ytjaIZwttHySprW05gYP/OlwLJyn6qKJbE78thaBTHCDF7rZ3odvOFOVZ9JuwPN FEdFtct0YM2KtOC0K92Se6orbqmgIHSRfA5zYXwdkuMpaBqZJ5J8P1OAYmrIsTeL MoftDRfXYlU= =6qPt -----END PGP SIGNATURE----- Received: from relay.hq.tis.com by neptune.TIS.COM id aa29236; 26 Oct 96 3:32 EDT Received: by relay.hq.tis.com; id DAA07134; Sat, 26 Oct 1996 03:36:47 -0400 From: JMKELSEY@delphi.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma007130; Sat, 26 Oct 96 03:36:21 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id DAA10214 for ; Sat, 26 Oct 1996 03:38:17 -0400 (EDT) Received: by relay.hq.tis.com; id DAA07121; Sat, 26 Oct 1996 03:36:17 -0400 Received: from bos1d.delphi.com(192.80.63.4) by relay.tis.com via smap (V3.1.1) id xma007115; Sat, 26 Oct 96 03:35:58 -0400 Received: from delphi.com by delphi.com (PMDF V5.0-7 #10880) id <01IB31UUBSOY8ZINVB@delphi.com> for ipsec@tis.com; Sat, 26 Oct 1996 03:38:03 -0500 (EST) Date: Sat, 26 Oct 1996 03:38:03 -0500 (EST) Subject: A question/comment on how the SPI is used To: ipsec@TIS.COM Message-id: <01IB31UUBSP08ZINVB@delphi.com> X-VMS-To: INTERNET"ipsec@tis.com" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Sender: ipsec-approval@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- [ To: IPSec discussion list ## Date: 10/25/96 09:14 am ## Subject: A question/comment on how the SPI is used ] As I understand it, the SPI is used in ESP to make sure that both the sender and receiver are using the same set of security parameters. I was curious why, when we do authentication, we don't include the hash of those security parameters (this isn't included in the packet, just in the MAC computation). This seems like it would make it much harder for some flaw in an individual implementation (or in parameter negotiation) to allow the sender and reciever to get out of synch in these parameters. If they don't have identical parameters, then the MAC no longer verifies properly. This seems to transform a lot of potentially very hard-to-spot flaws into very visible ones. Is there a reason this sort of thing is a bad idea? It shouldn't add much processing overhead--hash the parameters once, and then add 20 bytes (for SHA) to the data to be MACed. Most of the time, this doesn't lead to even one more compression function call for the hash function. --John Kelsey, jmkelsey@delphi.com / kelsey@counterpane.com PGP 2.6 fingerprint = 4FE2 F421 100F BB0A 03D1 FE06 A435 7E36 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMnG7pEHx57Ag8goBAQGdpAQAlDmhxv40CH3QYEq0csizOQ8+bBpsn6I1 EibzkR/ZEigOF0tIeauC+nU3rz9HcvG/IcOSAz2nc9oE6c+HaZ0u5iYF5ly7E6uK zKpN8nKnheTXPJE3CiDOZSKesIkk3SeucpG4OiEO9Ok/y1cGadejTlwfImCaWgm4 9Qiaa70kV/4= =vJnw -----END PGP SIGNATURE----- Received: from relay.hq.tis.com by neptune.TIS.COM id aa18130; 26 Oct 96 15:12 EDT Received: by relay.hq.tis.com; id PAA11606; Sat, 26 Oct 1996 15:17:16 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma011602; Sat, 26 Oct 96 15:16:52 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id PAA14199 for ; Sat, 26 Oct 1996 15:18:44 -0400 (EDT) Received: by relay.hq.tis.com; id PAA11597; Sat, 26 Oct 1996 15:16:46 -0400 Received: from poblano.near.net(198.114.157.116) by relay.tis.com via smap (V3.1.1) id xma011594; Sat, 26 Oct 96 15:16:40 -0400 Received: from AURELIUS.BBN.COM by poblano.bbnplanet.com id aa26995; 26 Oct 96 15:18 EDT X-Sender: smarcus@198.114.157.116 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Organization: BBN Corporation USMail: 150 CambridgePark Drive, Cambridge, MA 02140, U.S.A. Phone: +1 617.873.3075 Date: Sat, 26 Oct 1996 15:18:10 -0400 To: Bob Monsour From: Scott Marcus Subject: Re: Suggestion for ESP 3DES MD5 document Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 6:20 PM 10/25/96, Bob Monsour wrote: >... With the increasingly pervasive use of compression within PPP, all of the >encryption that will be done to implement VPNs (or any other network layer >encryption applications) will end up costing businesses additional line >charges due to the inability to compress encrypted data. When you're >talking about T1 rates and greater, this is not small change. As a result, >I think it is critical for the ipsec framework to support the optional use >of compression ... This is an interesting thought. The IPSEC framework is also potentially of great interest for dial-up access at relatively low speeds. In this case, compression contributes strongly to delay, and thus to performance as perceived by the user. It would be very unfortunate if IPSEC were to preclude effective compression. This argues, I think, for incorporating optional compression into the framework itself, as Bob suggests. Cheers, -- Scott Received: from relay.hq.tis.com by neptune.TIS.COM id aa29311; 26 Oct 96 16:25 EDT Received: by relay.hq.tis.com; id QAA12066; Sat, 26 Oct 1996 16:29:46 -0400 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma012063; Sat, 26 Oct 96 16:29:17 -0400 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id QAA14618 for ; Sat, 26 Oct 1996 16:31:14 -0400 (EDT) Received: by relay.hq.tis.com; id QAA12059; Sat, 26 Oct 1996 16:29:16 -0400 Received: from freya.cs.umass.edu(128.119.40.195) by relay.tis.com via smap (V3.1.1) id xma012057; Sat, 26 Oct 96 16:28:54 -0400 Received: from opine.cs.umass.edu (opine.cs.umass.edu [128.119.41.246]) by freya.cs.umass.edu (8.7.6/8.6.9) with SMTP id QAA03733; Sat, 26 Oct 1996 16:30:51 -0400 Message-ID: <327274FB.446B@cs.umass.edu> Date: Sat, 26 Oct 1996 16:30:51 -0400 From: Lewis McCarthy Organization: Theoretical Computer Science Group, UMass-Amherst X-Mailer: Mozilla 3.0 (X11; I; OSF1 V3.0 alpha) MIME-Version: 1.0 To: ipsec@TIS.COM CC: rpluth@nei.com, rogaway@cs.ucdavis.edu Subject: Re: ESP and AH on a secure gateway References: <9609258462.AA846261751@netx.nei.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk Rick Pluth writes: > I am developing a secure gateway, i.e. providing encryption on > behalf of my trusted subnet. This gateway will be using ESP > tunnel-mode and AH. [...] > After reading and discussing the appropriate RFC's (1825, 1826, etc), > I'm a little confused on how to use a combination of ESP and AH. To > clarify, if I receive a packet from a trusted host, should I > authenticate this IP packet, add in the AH, and then encrypt and add > the ESP header? OR, [...] > Should I encrypt the received IP packet and add the ESP header, and > THEN authenticate this data. The latest DES-CBC + HMAC + replay protection draft, draft-ietf-esp-des-md5-03.txt, specifies encryption over message authentication (cf. section 3). On the other hand, Phil Rogaway discouraged encrypting message authentication codes in an article last year in reference to some earlier IPsec transform drafts (cf. section 4). His conclusion then was: "RECOMMENDATION 4: Mandate that, when an ESP and an AH are both used, the scope of the authentication includes the encrypted packet (and not vice versa)." Doubtless this disagreement was discussed here before, but I don't know how it was (apparently) resolved in favor of ESP over AH. References, anyone ? [Incidentally, it's not obvious to me why "it is much more transparently correct to MAC an enciphered string than to encipher a MACed one" as Phil R. wrote in April `95. I'd be interested in reading an explanation of this.] [...] > In the first method, I'm authenticating the trusted host's clear-text > packet, while in the second method, I am authenticating the ESP packet > my gateway has produced. I am inclined to say the latter method is > more appropriate for a gateway, since I shouldn't be authenticating > "someone else's" data. I think it's useful to consider this in terms of integrity rather than authentication. By computing a MAC for an outgoing packet, a gateway is just preserving the integrity of the contents as received. It's not claiming authorship or vouching for anything else. I'd say this issue is orthogonal to the ordering of confidentiality and integrity preserving transforms. Lewis http://www.cs.umass.edu/~lmccarth/lmkey.asc "The intensity of the scenes we've been shooting and the amount of emotional work and concentration that is needed to get through the day are so mentally and physically exhausting that I'm sure I will need to be institutionalized when it's over. I understand now why most actors are alcoholics, drug addicts, or Scientologists" -Madonna L. Ciccone Received: from relay.hq.tis.com by neptune.TIS.COM id aa26988; 27 Oct 96 22:56 EST Received: by relay.hq.tis.com; id XAA22783; Sun, 27 Oct 1996 23:00:51 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma022778; Sun, 27 Oct 96 23:00:25 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id XAA25414 for ; Sun, 27 Oct 1996 23:02:17 -0500 (EST) Received: by relay.hq.tis.com; id XAA22766; Sun, 27 Oct 1996 23:00:22 -0500 Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1.1) id xma022761; Sun, 27 Oct 96 23:00:17 -0500 Received: from [128.89.30.6] (ARA6.BBN.COM [128.89.30.6]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id XAA02550; Sun, 27 Oct 1996 23:02:12 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 27 Oct 1996 23:03:59 -0600 To: Bob Monsour From: Stephen Kent Subject: Re: Suggestion for ESP 3DES MD5 document Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Bob, Your point is well taken and I will make sure that compression is identified as an option within ESP. Steve Received: from relay.hq.tis.com by neptune.TIS.COM id aa27058; 27 Oct 96 22:57 EST Received: by relay.hq.tis.com; id XAA22794; Sun, 27 Oct 1996 23:01:21 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma022790; Sun, 27 Oct 96 23:00:53 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id XAA25423 for ; Sun, 27 Oct 1996 23:02:46 -0500 (EST) Received: by relay.hq.tis.com; id XAA22784; Sun, 27 Oct 1996 23:00:51 -0500 Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1.1) id xma022780; Sun, 27 Oct 96 23:00:40 -0500 Received: from [128.89.30.6] (ARA6.BBN.COM [128.89.30.6]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id XAA02565; Sun, 27 Oct 1996 23:02:33 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 27 Oct 1996 23:04:15 -0600 To: "Pluth, Rick" From: Stephen Kent Subject: Re: ESP and AH on a secure gateway Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Rick, Now that ESP offers authentication and integrity options, as well as confidentiality, I would not suggest the first example you provided, i.e., encapsulating an AH-protected packet with ESP. It should be faster and engender somewhat less overhead to use an ESP integrity check for ESP, vs. embedded AH, e.g., due of the contigious nature of the data being hashed in ESP. This is not to say that AH can't be used to some advantage as an external integrity check with ESP, as in your second example, but it may no longer be the obvious choice. Another reason not to adopt your first example is that it would interfere with the client host's ability to use AH in his traffic, on a true end-to-end basis. Steve To: ipsec@TIS.COM Path: not-for-mail From: David Wagner Newsgroups: isaac.lists.ipsec Subject: Re: A hole in esp-stream-01 Date: 26 Oct 1996 15:09:56 -0700 Organization: ISAAC Group, UC Berkeley Lines: 55 Message-ID: <54u27k$qc@joseph.cs.berkeley.edu> References: <01IB31UAFX3I8ZINVB@delphi.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk In article <01IB31UAFX3I8ZINVB@delphi.com>, wrote: > >When using ESP with DES or 3DES, why do I need a cryptographically > >strong hash function since the hash is encrypted? In order to be able to > >successfully modify the packet and still create a valid hash would > >require breaking the encryption. We are not actually talking about a > >non-repudiation issue with a digital signature; a cryptographically > >secure hash appears to be overkill and using a keyed hash even more so. > > Actually, I think this general idea (hash the data, then encrypt the > hash) has been discussed a few times as a valid MAC design. I can > see a couple possible problems with it, off the top of my head: > > 1. If you can cause collisions in the hash function (i.e., MD5), > then you can cause collisions in the MAC, as well. (I don't think > this is all that upsetting--once your hash function has stopped > resisting collisions, it's time to retire it.) More to the point, > collision values can be found offline--they don't require interaction > with the user. Admittedly, getting the pair of collision values > into encrypted form is still going to be pretty complicated. > > 2. I think doing this in CBC-mode may add some complications to > the analysis. Among other things, we have to make sure the IV gets > hashed along with the data. > > Does anyone else know of cryptanalysis of this kind of scheme? I remember discussing this approach a while ago (though it may well have been in private email?). It seemed promising at the time, but it never really got anywhere, as I recall. (Someone correct me if I'm wrong here.) The idea of appending a MD5 hash of the data, then encrypting, can fall to chosen-plaintext attacks: I request the encryption of the message M' = M || MD5(M) || foo. from you. You send C = CBC-Encrypt(M || MD5(M) || foo || MD5(M')). Recall that CBC encryption has the property that decrypting a prefix of the ciphertext yields a prefix of the plaintext. So I now (in an active attack) truncate C at the boundary between the CBC-encryption of MD5(M) and foo, thus obtaining the ciphertext CBC-Encrypt(M || MD5(M)), which the receiver will interpret as a valid, authentic encryption of the message M. Therefore simply appending an unkeyed hash prior to encryption does not always protect message integrity. (I'm probably forgetting who initially discovered this attack; apologies for the lack of attribution.) It was also suggested to append a CRC of the data before encrypting; I remember finding a known-plaintext attack on that. (The problem is that the CRC is too linear.) I will look up my old correspondence and forward you the technical details of the attack, but the exact nitty-gritty details probably aren't so interesting, so I won't bother the list with it. I think using a well-studied MAC, like HMAC, is the most robust way to go. Designing roll-your-own message integrity schemes seems fairly subtle & easy to get wrong. (But a ultra-fast secure MAC would be good to have.) Message-Id: <199610281921.LAA27635@cornpuffs.cisco.com> From: Ran Atkinson Date: Mon, 28 Oct 1996 11:21:23 PST X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipsec@TIS.COM Subject: allocation of key material into keys Sender: ipsec-approval@neptune.tis.com Precedence: bulk I'm not sure what other folks think, but I've been persuaded by various people that we need some standard and clearly stated way of transforming a "blob" of key material generated by key management (e.g. the D-H exponentiation) into one or more actual session keys. I'd like to propose that the key management protocol specifications only be responsible for generating a "blob" of key material with sufficient bits of entropy. Each transform would need to specify how many bits of entropy are needed from key management for an SA and precisely how to transform a single "blob" of key material into one or more session keys. Does this seem OK to people ? Ran rja@cisco.com -- Received: from relay.hq.tis.com by neptune.TIS.COM id aa20262; 28 Oct 96 15:24 EST Received: by relay.hq.tis.com; id PAA11709; Mon, 28 Oct 1996 15:29:08 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xmaa11692; Mon, 28 Oct 96 15:28:39 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id PAA03432 for ; Mon, 28 Oct 1996 15:30:31 -0500 (EST) Received: by relay.hq.tis.com; id PAA11685; Mon, 28 Oct 1996 15:28:36 -0500 Received: from capone.ch.apollo.hp.com(15.254.24.3) by relay.tis.com via smap (V3.1.1) id xma011672; Mon, 28 Oct 96 15:28:29 -0500 Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id ; Mon, 28 Oct 1996 15:30:14 -0500 Received: from thunk (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.7.5/8.6.12) with ESMTP id PAA03172; Mon, 28 Oct 1996 15:29:55 -0500 (EST) Message-Id: <199610282029.PAA03172@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: Ran Atkinson Cc: ipsec@TIS.COM Subject: Re: allocation of key material into keys In-Reply-To: rja's message of Mon, 28 Oct 1996 11:21:23 -0800. <199610281921.LAA27635@cornpuffs.cisco.com> Date: Mon, 28 Oct 1996 15:29:06 -0500 From: Bill Sommerfeld Sender: ipsec-approval@neptune.tis.com Precedence: bulk Here's a rephrase which I think is more precise. Let me know if this is not what you intended.. I'd like to propose that the key management protocol specifications only be responsible for generating a "blob" of key material at least N bits long containing at least K bits of entropy. For obvious reasons, K <= N. Each transform would need to specify minimum values for K and N, and precisely how to transform a variable-length "blob" of key material of at least N bits into the session keys, initial sequence numbers, and other shared state it needs. --- I think this is also more-or-less what Hilary suggested last week some time. She used "VPI" instead of "blob", but I don't think that's an important difference here.. :-) - Bill Received: from relay.hq.tis.com by neptune.TIS.COM id aa28651; 28 Oct 96 16:30 EST Received: by relay.hq.tis.com; id QAA14008; Mon, 28 Oct 1996 16:34:54 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma014006; Mon, 28 Oct 96 16:34:27 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id QAA08541 for ; Mon, 28 Oct 1996 16:36:19 -0500 (EST) Received: by relay.hq.tis.com; id QAA14002; Mon, 28 Oct 1996 16:34:24 -0500 Received: from mail.border.com(199.71.190.98) by relay.tis.com via smap (V3.1.1) id xma014000; Mon, 28 Oct 96 16:34:15 -0500 Received: by janus.border.com id <18437-1>; Mon, 28 Oct 1996 16:34:21 -0500 Message-Id: <96Oct28.163421est.18437-1@janus.border.com> To: Bill Sommerfeld cc: Ran Atkinson , ipsec@TIS.COM Subject: Re: allocation of key material into keys References: <199610282029.PAA03172@thunk.orchard.medford.ma.us> In-reply-to: sommerfeld's message of "Mon, 28 Oct 1996 15:29:06 -0500". <199610282029.PAA03172@thunk.orchard.medford.ma.us> From: "C. Harald Koch" Organization: Secure Computing Canada Ltd. Phone: +1 416 368 7157 X-uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Mon, 28 Oct 1996 16:36:06 -0500 Sender: ipsec-approval@neptune.tis.com Precedence: bulk In message <199610282029.PAA03172@thunk.orchard.medford.ma.us>, Bill Sommerfeld writes: > Here's a rephrase which I think is more precise. Let me know if this > is not what you intended.. > > I'd like to propose that the key management protocol > specifications only be responsible for generating a "blob" of > key material at least N bits long containing at least K bits of > entropy. For obvious reasons, K <= N. > > Each transform would need to specify minimum values for K and > N, and precisely how to transform a variable-length "blob" > of key material of at least N bits into the session keys, initial > sequence numbers, and other shared state it needs. The problem with this is that it doesn't cover the problem of creating *independent* keys for multiple transforms, which is the concern Hugo raised. I suspect that everyone will define simple keying material functions such that one could (for example) derive the HMAC-MD5 key from a cracked DES key. As has been discussed, this is a key management layer issue. I'd modify your statement to include that somehow, the "blobs" handed to different transforms or algorithms must be 'independent' (i.e. it's cryptographically hard to derive one key from another). They can still be generated from the same key exchange, as long as the key manager runs an intermediate step to obscure the source keying material. -- C. Harald Koch | Senior System Developer, Secure Computing Canada Ltd. chk@border.com | 20 Toronto Street, Suite 400, Toronto ON M5C 2B8 +1 416 368 7157 (voice) | "Madness takes its toll. Please have exact change." +1 416 368 7789 (fax) | -Karen Murphy Received: from relay.hq.tis.com by neptune.TIS.COM id aa02054; 28 Oct 96 16:58 EST Received: by relay.hq.tis.com; id RAA15186; Mon, 28 Oct 1996 17:02:25 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma015172; Mon, 28 Oct 96 17:01:57 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id RAA10416 for ; Mon, 28 Oct 1996 17:03:49 -0500 (EST) Received: by relay.hq.tis.com; id RAA15166; Mon, 28 Oct 1996 17:01:55 -0500 Received: from capone.ch.apollo.hp.com(15.254.24.3) by relay.tis.com via smap (V3.1.1) id xma015162; Mon, 28 Oct 96 17:01:49 -0500 Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id ; Mon, 28 Oct 1996 17:03:51 -0500 Received: from thunk (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.7.5/8.6.12) with ESMTP id RAA03227; Mon, 28 Oct 1996 17:03:49 -0500 (EST) Message-Id: <199610282203.RAA03227@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: "C. Harald Koch" Cc: Ran Atkinson , ipsec@TIS.COM Subject: Re: allocation of key material into keys In-Reply-To: chk's message of Mon, 28 Oct 1996 16:36:06 -0500. <96Oct28.163421est.18437-1@janus.border.com> Date: Mon, 28 Oct 1996 17:03:45 -0500 From: Bill Sommerfeld Sender: ipsec-approval@neptune.tis.com Precedence: bulk > As has been discussed, this is a key management layer issue. I'd modify your > statement to include that somehow, the "blobs" handed to different > transforms or algorithms must be 'independent' (i.e. it's cryptographically > hard to derive one key from another). They can still be generated from the > same key exchange, as long as the key manager runs an intermediate step to > obscure the source keying material. Agreed. Each SA/SPI instantiated by the key mgmt protocol needs to get a different, independant, blob of entropy. - Bill Received: from relay.hq.tis.com by neptune.TIS.COM id aa06688; 28 Oct 96 17:38 EST Received: by relay.hq.tis.com; id RAA16334; Mon, 28 Oct 1996 17:42:25 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma016330; Mon, 28 Oct 96 17:41:57 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id RAA12532 for ; Mon, 28 Oct 1996 17:43:49 -0500 (EST) Received: by relay.hq.tis.com; id RAA16326; Mon, 28 Oct 1996 17:41:55 -0500 Received: from freya.cs.umass.edu(128.119.40.195) by relay.tis.com via smap (V3.1.1) id xma016321; Mon, 28 Oct 96 17:41:46 -0500 Received: from thor.cs.umass.edu (thor.cs.umass.edu [128.119.41.73]) by freya.cs.umass.edu (8.7.6/8.6.9) with SMTP id RAA08608 for ; Mon, 28 Oct 1996 17:43:48 -0500 Message-ID: <32753724.3F54@cs.umass.edu> Date: Mon, 28 Oct 1996 17:43:48 -0500 From: Lewis McCarthy Organization: Theoretical Computer Science Group, UMass-Amherst X-Mailer: Mozilla 3.0 (X11; I; OSF1 V3.0 alpha) MIME-Version: 1.0 To: ipsec@TIS.COM Subject: Re: allocation of key material into keys References: <199610282029.PAA03172@thunk.orchard.medford.ma.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk [Mail from the ipsec list seems to arrive here substantially reordered, so please ignore this if it's already been covered.] Bill Sommerfeld writes: > Here's a rephrase which I think is more precise. Let me know if this > is not what you intended.. > > I'd like to propose that the key management protocol > specifications only be responsible for generating a "blob" of > key material at least N bits long containing at least K bits of > entropy. For obvious reasons, K <= N. [...] At the risk of stating the obvious, the K bits of entropy should presumably be ~ evenly distributed among the N bits of VPIblob, i.e. padding K bits from a physical random source with 0s to reach N bits would be unacceptable. Otherwise a transform might grab a hunk of padding and use it as key material.... -Lewis Received: from relay.hq.tis.com by neptune.TIS.COM id aa02498; 28 Oct 96 20:51 EST Received: by relay.hq.tis.com; id UAA19278; Mon, 28 Oct 1996 20:55:32 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma019273; Mon, 28 Oct 96 20:55:04 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id UAA17443 for ; Mon, 28 Oct 1996 20:56:55 -0500 (EST) Received: by relay.hq.tis.com; id UAA19266; Mon, 28 Oct 1996 20:55:02 -0500 Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1.1) id xma019261; Mon, 28 Oct 96 20:54:38 -0500 Received: from [128.89.30.7] (ARA7.BBN.COM [128.89.30.7]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id UAA22032 for ; Mon, 28 Oct 1996 20:56:36 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Oct 1996 20:58:21 -0600 To: ipsec@TIS.COM From: Stephen Kent Subject: proposed IPSEC changes/extensions Sender: ipsec-approval@neptune.tis.com Precedence: bulk Folks, In working with Ran on revisions to the ESP and AH documents, I also looked at the IPSEC architecture document. I'm suggesting several changes or extensions to that document, to better specify what it means to be a compliant IPSEC implementation. The following items are indicative of the sorts of material I would like to include in a revised IPSEC architecture document. I am soliciting comments from the WG on each of these points. Required Protocol (header) Support The document explains the need to support AH and both transport and tunnel modes of ESP, based on the context (host vs. security gateway). However, what about nested combinations of these protocols? It probably is not reasonable to require an implementation to support all possible combinations of these headers, nested to any depth. I put forth the following list as a starting point for this discussion: AH, ESP (tunnel), ESP(transport), AH-ESP(transport), AH-ESP(tunnel), ESP(tunnel)-AH, AH-ESP(tunnel)-ESP(transport), and ESP(tunnel)-ESP(transport). Note the nested ESP and AH/ESP configurations allow for termination of one SA at a security gateway, with an embedded SA going to a host. Because ESP can offer integrity & authentication as an independent option (i.e., without confidentiality), use of AH must be carefully examined as it is no longer the only way to provide these services. Perhaps this list is too long, and we can pare some of the combined AH/ESP support requirements. Required Management Parameters I have expanded upon the list of required management support parameters. Rather than note only the new ones, I've included the whole (revised) list. Pay attention to the notes on what system class must support what management parameters. One set of management parameters I propose adding extends the granularity of SAs, in both directions, to allow for both fine-grained SAs (at gateways and hosts) and coarse-grained SAs (primarliy for inter-gateway use). - Authentication algorithm and mode being used for AH or ESP. [REQUIRED for all implementations]. - Key(s) used with the above authentication algorithm [REQUIRED for all implementations]. - Encryption algorithm and mode used with ESP. [REQUIRED for ESP implementations] - Key(s) used with the above encryption algorithm. [REQUIRED for ESP implementations] - Presence/absence and size of a cryptographic synchronisation or initialisation vector field for the encryption algorithm. [REQUIRED for ESP implementations] - Authentication key crypto period (fixed future time or duration). [REQUIRED for all implementations]. - Encryption key crypto period (fixed future tie or duration) [REQUIRED for ESP implementations] - Lifetime of this Security Association [REQUIRED for all implementations] - Destination IP Address of the Security Association; this may be a wildcard address if more than one desitnation system shares the same Security Association (behind a security gateway) [REQUIRED for all implementations] - Source IP Address(es) of the Security Association; this might be a wildcard address if more than one sending system shares the same Security Association with the destination [REQUIRED for all implementations] - Replay Protection information, including whether it is in use, information on the window size for the sequence numbers, etc. [REQUIRED for all implementations] - Sensitivity level of the protected data (e.g., in IPSO terms) [REQUIRED for all systems claiming to provide multi-level security, RECOMMENDED for all other systems] - Next Protocol (from IP header) as an optional SA selector input for outbound traffic [OPTIONAL for contexts that require fine-grained SA management] - Source and/or Destination TCP/UDP Ports as an optional SA selector for outbound traffic [OPTIONAL for contexts that require fine-grained SA management] Also, the current text calls for userID as a required input to SA selection in a host. However, this precludes some implementation options, e.g., bump-in-the-stack and external hardware implementations. I'd suggest we relax or reword this requirement to permit a wider range of compliant implementations. AH & ESP Document Changes The goal of the AH and ESP document changes is NOT to modify the syntax of the protocols. Instead, the revised documents will consolidate the formats that have arisen in various extensions, to avoid proliferation of transform specification document. The changes for AH are very minor, i.e., it will be described as a base protocol with an optional anti-replay field and associated processing semantics. Support for anti-replay would be mandatory. For ESP, the changes are much more significant. The protocol (header) will consist of a set of optional, mostly variable-length fields, each of which is selected at SA establishment to describe the specific security services desired for the SA. The optional fields include an IV, sequence number for anti-replay, and an integrity check value (in addition to the static SPI and next protocol fields, and the padding). Thus there are no new fields (not already described in some existing tranform) nor substantive changes in processing description. (We've been talking about compression for a while, more so recently, but I don't know if there a need for any new fields for this, rather than just an SA characteristicto be negotiated?) Support for all of these fields would be mandatory. The set of algorithms supported is separate from this document and support for specific algorithms (really sets of algorithms) is separated from this document. As above, I solicit comments/suggestions on this proposed approach to revising these doucuments (already in progress). Steve Received: from relay.hq.tis.com by neptune.TIS.COM id aa14193; 29 Oct 96 8:16 EST Received: by relay.hq.tis.com; id IAA25484; Tue, 29 Oct 1996 08:20:34 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma025478; Tue, 29 Oct 96 08:20:15 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id IAA27652 for ; Tue, 29 Oct 1996 08:22:01 -0500 (EST) Received: by relay.hq.tis.com; id IAA25465; Tue, 29 Oct 1996 08:20:04 -0500 Received: from ftp.com(128.127.2.122) by relay.tis.com via smap (V3.1.1) id xma025456; Tue, 29 Oct 96 08:19:38 -0500 Received: from ftp.com by ftp.com ; Tue, 29 Oct 1996 08:21:43 -0500 Received: from mailserv-2high.ftp.com by ftp.com ; Tue, 29 Oct 1996 08:21:43 -0500 Received: from athena by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id IAA26801; Tue, 29 Oct 1996 08:21:38 -0500 Message-Id: <2.2.32.19961029132725.00c13120@mailserv-H.ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Oct 1996 08:27:25 -0500 To: Bill Sommerfeld From: Naganand Doraswamy Subject: Re: allocation of key material into keys Cc: "C. Harald Koch" , Ran Atkinson , ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk >Agreed. Each SA/SPI instantiated by the key mgmt protocol needs to >get a different, independant, blob of entropy. > Correct me if I am wrong. Jim Hughes draft on esp-des currently specifies deriving the the keys for the Initiator and the Responder from the same keying materail K. Are we suggesting here that we should be using different keying materail or can we still use the same keying materail but change the input to the hash algorithm by padding something. --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) To: ipsec@TIS.COM Path: not-for-mail From: David Wagner Newsgroups: isaac.lists.ipsec Subject: Re: proposed IPSEC changes/extensions Date: 28 Oct 1996 18:47:04 -0800 Organization: ISAAC Group, UC Berkeley Lines: 20 Message-ID: <553r78$2vp@joseph.cs.berkeley.edu> References: Sender: ipsec-approval@neptune.tis.com Precedence: bulk In article , Stephen Kent wrote: > The document explains the need to support AH and both transport and > tunnel modes of ESP, based on the context (host vs. security gateway). > However, what about nested combinations of these protocols? It probably is > not reasonable to require an implementation to support all possible > combinations of these headers, nested to any depth. While I don't know what the requirements ought to be, I thought I'd throw in a brief word of implementation experience. When I was implementing ipsec, I found that handling arbitrarily-nested combinations was easy. On inbound processing, just strip off an ipsec header, and recurse: throw the packet back in the inbound queue. (You only have to maintain a bit of state for authentication.) Certainly support for *sending* packets with arbitrarily-nested headers is harder to implement. But that's fine; either way, we ought to Be conservative in what you send and liberal in what you'll accept. Message-Id: <199610291214.HAA01347@smb.research.att.com> To: Stephen Kent cc: ipsec@TIS.COM Subject: Re: proposed IPSEC changes/extensions Date: Tue, 29 Oct 1996 07:14:21 -0500 From: Steve Bellovin Sender: ipsec-approval@neptune.tis.com Precedence: bulk I have a number of other comments I'll try to send out tonight. For now, though, I'm very curious why you want management parameters to retrieve keys. Why would a management station -- and remember that we don't have SNMP security yet -- ever need to retrieve a key? (For that matter, I thought I'd heard from you that keeping keys inside the secure box was a primary goal of cryptographic system design.) Date: Tue, 29 Oct 1996 10:09:37 -0500 Message-Id: <199610291509.KAA13917@csmes.ncsl.nist.gov> From: Joe Konczal To: rja@cisco.com CC: ipsec@TIS.COM In-reply-to: (message from Ran Atkinson on Mon, 28 Oct 1996 11:21:23 PST) Subject: Re: allocation of key material into keys Sender: ipsec-approval@neptune.tis.com Precedence: bulk Sounds like a good idea to me. Received: from relay.hq.tis.com by neptune.TIS.COM id aa15078; 29 Oct 96 12:37 EST Received: by relay.hq.tis.com; id MAA04339; Tue, 29 Oct 1996 12:42:22 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma004327; Tue, 29 Oct 96 12:41:55 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id MAA19054 for ; Tue, 29 Oct 1996 12:43:45 -0500 (EST) Received: by relay.hq.tis.com; id MAA04322; Tue, 29 Oct 1996 12:41:52 -0500 Received: from aardvark.bbn.com(128.89.1.203) by relay.tis.com via smap (V3.1.1) id xma004317; Tue, 29 Oct 96 12:41:27 -0500 Received: (gdt@localhost) by aardvark.bbn.com (8.6.10/8.6.5) id MAA12547; Tue, 29 Oct 1996 12:43:17 -0500 Date: Tue, 29 Oct 1996 12:43:17 -0500 Message-Id: <199610291743.MAA12547@aardvark.bbn.com> From: Greg Troxel To: ipsec@TIS.COM Subject: independence of keying material for multiple transforms Sender: ipsec-approval@neptune.tis.com Precedence: bulk I've only been dimly following IPSEC for a while, and am trying to pay attention more. Thus this comment is from someone less familiar with the documents; I hope this perspective is useful in that it might cause an unwritten shared assumption to be written down clearly. I'd like to concur with the notion expressed in a recent message that documents explicitly make the point that when raw keying material is used to generate blobs that whatever entropy was 'used' to generate this not be reused when generating another blob. Or perhaps, that it should be computationally infeasible to determine information about any bit in blob A given the entire contents of blobs B,C,D. This may seem obvious, and I get the impression that most/all people are thinking this, but it wasn't said explicitly in Ran's phrasing. I'm not comfortably sure that all readers would get this nuance, particularly if they aren't aspiring Real Cryptographers. Greg Troxel +1 617 873 2494 Received: from relay.hq.tis.com by neptune.TIS.COM id aa28801; 29 Oct 96 14:40 EST Received: by relay.hq.tis.com; id OAA08200; Tue, 29 Oct 1996 14:44:29 -0500 From: HUGO@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma008191; Tue, 29 Oct 96 14:44:08 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id OAA29708 for ; Tue, 29 Oct 1996 14:45:52 -0500 (EST) Received: by relay.hq.tis.com; id OAA08182; Tue, 29 Oct 1996 14:43:59 -0500 Received: from igw3.watson.ibm.com(129.34.139.18) by relay.tis.com via smap (V3.1.1) id xma008156; Tue, 29 Oct 96 14:43:30 -0500 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id OAA05044; Tue, 29 Oct 1996 14:45:18 -0500 Received: from yktvmv.watson.ibm.com (yktvmv.watson.ibm.com [9.117.33.29]) by mailhub1.watson.ibm.com (8.7.1/10-26-96) with SMTP id OAA192971; Tue, 29 Oct 1996 14:45:06 -0500 Message-Id: <199610291945.OAA192971@mailhub1.watson.ibm.com> Received: from YKTVMV by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9289; Tue, 29 Oct 96 14:45:04 EST Date: Tue, 29 Oct 96 14:28:06 EST To: rja@cisco.com, IPSEC@TIS.COM cc: dharkins@cisco.com Subject: allocation of key material into keys Sender: ipsec-approval@neptune.tis.com Precedence: bulk Ref: Your note of Mon, 28 Oct 1996 11:21:23 PST (attached) > I'm not sure what other folks think, but I've been persuaded by various people > that we need some standard and clearly stated way of transforming a "blob" of > key material generated by key management (e.g. the D-H exponentiation) into > one or more actual session keys. up to here we are in full agreement > > I'd like to propose that the key management protocol specifications only > be responsible for generating a "blob" of key material with sufficient > bits of entropy. > > Each transform would need to specify how many bits of entropy are needed from > key management for an SA and precisely how to transform a single "blob" of key > material into one or more session keys. This depends on what exactly you mean by "transform". Does the transform defines *all* the algorithms (and their needs for keys) that will be used with that particular blob. Or there is more than one transform that will use the same blob?. In the later case, I would disagre with you. This is what I was trying to explain in my previous message on key derivation. Giving *different* transforms (algorithms) the freedom to derive their keys from the *same* blob (I call it RKM for raw key material) is wrong. It does not guarantee key independence. As I said, form that single blob/RKM the key management needs to derive keys for each algorithm (the algorithm itself can then expand/manipulate that key as much as it wants). I do not care whether one sees the derivation of a transform key from RKM as part of the key exchange definition or a layer between key exchange and transform definitions, as long as key independence is enforced. > > Does this seem OK to people ? What do the editors of ISAKMP and Oakley related documents think (or more importantly, what do they plan to do)? (This is in my view a simple but fundamental issue). Hugo > > Ran > rja@cisco.com > > > -- > > Received: from relay.hq.tis.com by neptune.TIS.COM id aa00479; 29 Oct 96 14:54 EST Received: by relay.hq.tis.com; id OAA08641; Tue, 29 Oct 1996 14:58:29 -0500 From: pau@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma008636; Tue, 29 Oct 96 14:58:03 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id OAA00573 for ; Tue, 29 Oct 1996 14:59:52 -0500 (EST) Received: by relay.hq.tis.com; id OAA08626; Tue, 29 Oct 1996 14:57:59 -0500 Received: from igw3.watson.ibm.com(129.34.139.18) by relay.tis.com via smap (V3.1.1) id xma008619; Tue, 29 Oct 96 14:57:41 -0500 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id OAA03938; Tue, 29 Oct 1996 14:59:48 -0500 Received: from secpwr.watson.ibm.com (secpwr.watson.ibm.com [9.2.24.17]) by mailhub1.watson.ibm.com (8.7.1/10-26-96) with SMTP id OAA14520; Tue, 29 Oct 1996 14:59:24 -0500 Received: by secpwr.watson.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA22994; Tue, 29 Oct 1996 15:01:34 -0500 Date: Tue, 29 Oct 1996 15:01:34 -0500 Message-Id: <9610292001.AA22994@secpwr.watson.ibm.com> To: kent@bbn.com Subject: Re: proposed IPSEC changes/extensions Cc: ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Md5: E2+UdKJ7rxj350CbaqbWXQ== Sender: ipsec-approval@neptune.tis.com Precedence: bulk Steve, thank you for the effort. A few comments and questions below. Pau-Chen on Mon, 28 Oct 1996, Stephen Kent wrote >=20 > Folks, >=20 > In working with Ran on revisions to the ESP and AH documents, = I > also looked at the IPSEC architecture document. I'm suggesting = several > changes or extensions to that document, to better specify what it = means to > be a compliant IPSEC implementation. The following items are = indicative of > the sorts of material I would like to include in a revised IPSEC > architecture document. I am soliciting comments from the WG on each = of > these points. >=20 > Required Protocol (header) Support >=20 > The document explains the need to support AH and both transport = and > tunnel modes of ESP, based on the context (host vs. security gateway). > However, what about nested combinations of these protocols? It = probably is > not reasonable to require an implementation to support all possible > combinations of these headers, nested to any depth. I put forth the > following list as a starting point for this discussion: AH, ESP = (tunnel), > ESP(transport), > AH-ESP(transport), AH-ESP(tunnel), ESP(tunnel)-AH, > AH-ESP(tunnel)-ESP(transport), and ESP(tunnel)-ESP(transport).=20 Q: By AH-ESP (tunnel), do you mean the final output of encapsulation = will be IP-AH-ESP-IP-... (AH is done after ESP) or IP-ESP-AH-IP-... (AH is done before ESP) ? >=20 > Note the nested ESP and AH/ESP configurations allow for = termination > of one SA at a security gateway, with an embedded SA going to a host. > Because ESP can offer integrity & authentication as an independent = option > (i.e., without confidentiality), use of AH must be carefully examined = as it > is no longer the only way to provide these services. Perhaps this = list is > too long, and we can pare some of the combined AH/ESP support = requirements. >=20 > Required Management Parameters >=20 > I have expanded upon the list of required management support > parameters. Rather than note only the new ones, I've included the = whole > (revised) list. Pay attention to the notes on what system class must > support what management parameters. One set of management parameters = I > propose adding extends the granularity of SAs, in both directions, to = allow > for both fine-grained SAs (at gateways and hosts) and coarse-grained = SAs > (primarliy for inter-gateway use). >=20 > - Authentication algorithm and mode being used for AH or ESP. > [REQUIRED for all implementations]. > - Key(s) used with the above authentication algorithm > [REQUIRED for all implementations]. > - Encryption algorithm and mode used with ESP. > [REQUIRED for ESP implementations] > - Key(s) used with the above encryption algorithm. > [REQUIRED for ESP implementations] > - Presence/absence and size of a cryptographic synchronisation = or > initialisation vector field for the encryption algorithm. > [REQUIRED for ESP implementations] > - Authentication key crypto period (fixed future time or = duration). > [REQUIRED for all implementations]. > - Encryption key crypto period (fixed future tie or duration) > [REQUIRED for ESP implementations] > - Lifetime of this Security Association > [REQUIRED for all implementations] Q: What is the difference between "crypto period" and "SA life time" ? What do you mean by "crypto period" ? C: Related to the above question, if you mean "key life time" by "crypto period" and allows the keys(s) in an SA to be refreshed after the "crypto period" expires. Then I have some comments : =20 Key refreshment is definitely needed. However, my experience tells me there will be trouble if, in concept, we refresh only the key and not the SA; unless the SPI of the SA is changed together with the = key. The reason is that, in practice, you need a short period of overlap between the old and new keys. Otherwise, there may be disruption of communication whenever a key expires. If the old and new keys are = assigned the same SPI, then the receiver will have trouble knowing which key = to use during the overlap. This could either cause false security alarm (because the wrong key is used) or double the processing cost (trying both keys). =20 C: If "crypto period" or "SA life time" is an SA parameter, should they = be negotiated by key management protocol ? Perhaps as an attribute of a transform in ISAKMP ? > - Destination IP Address of the Security Association; this may = be > a wildcard address if more than one desitnation system = shares the > same Security Association (behind a security gateway) > [REQUIRED for all implementations] > - Source IP Address(es) of the Security Association; this = might be > a wildcard address if more than one sending system shares = the > same Security Association with the destination > [REQUIRED for all implementations] C: If the wildcard is only for the security gateway case and the SA's terminate on the gateway, then it may better to just record the exact end points in SA's and let the gateway's policy determines which = system(s) an SA should be applied to. =20 > - Replay Protection information, including whether it is in = use, > information on the window size for the sequence numbers, = etc. > [REQUIRED for all implementations] > - Sensitivity level of the protected data (e.g., in IPSO = terms) > [REQUIRED for all systems claiming to provide multi-level > security, RECOMMENDED for all other systems] > - Next Protocol (from IP header) as an optional SA selector > input for outbound traffic > [OPTIONAL for contexts that require fine-grained SA = management] > - Source and/or Destination TCP/UDP Ports as an optional SA > selector for outbound traffic > [OPTIONAL for contexts that require fine-grained SA = management] C: The "protocol" and "port" attributes seem to intervene with a = system's secuirty policy. In practice, a policy can say multiple=20
tuples will use an SA. My experience tells me that it is much easier to implement such policy as rules in a table than as attributes in SA's. I would = suggest to mention fine-grained policy can be implemented using some = "binding" between SA, protocols, ports and addresses but leave the exact = binding mechanism to the local implementation. =20 >=20 > Also, the current text calls for userID as a required input to = SA > selection in a host. However, this precludes some implementation = options, > e.g., bump-in-the-stack and external hardware implementations. I'd = suggest > we relax or reword this requirement to permit a wider range of = compliant > implementations. >=20 > AH & ESP Document Changes >=20 > The goal of the AH and ESP document changes is NOT to modify = the > syntax of the protocols. Instead, the revised documents will = consolidate > the formats that have arisen in various extensions, to avoid = proliferation > of transform specification document. The changes for AH are very = minor, > i.e., it will be described as a base protocol with an optional = anti-replay > field and associated processing semantics. Support for anti-replay = would > be mandatory. >=20 > For ESP, the changes are much more significant. The protocol > (header) will consist of a set of optional, mostly variable-length = fields, > each of which is selected at SA establishment to describe the specific > security services desired for the SA. The optional fields include an = IV, > sequence number for anti-replay, and an integrity check value (in = addition > to the static SPI and next protocol fields, and the padding). Thus = there > are no new fields (not already described in some existing tranform) = nor > substantive changes in processing description. (We've been talking = about > compression for a while, more so recently, but I don't know if there a = need > for any new fields for this, rather than just an SA characteristicto = be > negotiated?) Support for all of these fields would be mandatory. The = set > of algorithms supported is separate from this document and support for > specific algorithms (really sets of algorithms) is separated from this > document. >=20 > As above, I solicit comments/suggestions on this proposed = approach > to revising these doucuments (already in progress). >=20 > Steve >=20 >=20 Received: from relay.hq.tis.com by neptune.TIS.COM id aa01830; 29 Oct 96 15:07 EST Received: by relay.hq.tis.com; id PAA09102; Tue, 29 Oct 1996 15:11:32 -0500 From: HUGO@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma009083; Tue, 29 Oct 96 15:11:05 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id PAA01739 for ; Tue, 29 Oct 1996 15:12:55 -0500 (EST) Received: by relay.hq.tis.com; id PAA09067; Tue, 29 Oct 1996 15:11:02 -0500 Received: from igw3.watson.ibm.com(129.34.139.18) by relay.tis.com via smap (V3.1.1) id xma009061; Tue, 29 Oct 96 15:10:56 -0500 Received: from mailhub2.watson.ibm.com (mailhub2.watson.ibm.com [9.2.250.15]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id PAA15468; Tue, 29 Oct 1996 15:13:04 -0500 Received: from yktvmv.watson.ibm.com (yktvmv.watson.ibm.com [9.117.33.29]) by mailhub2.watson.ibm.com (8.7.1/10-26-96) with SMTP id PAA35192; Tue, 29 Oct 1996 15:12:52 -0500 Message-Id: <199610292012.PAA35192@mailhub2.watson.ibm.com> Received: from YKTVMV by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9906; Tue, 29 Oct 96 15:12:50 EST Date: Tue, 29 Oct 96 14:48:31 EST To: sommerfeld@apollo.hp.com, rja@cisco.com cc: ipsec@TIS.COM Subject: allocation of key material into keys Sender: ipsec-approval@neptune.tis.com Precedence: bulk Ref: Your note of Mon, 28 Oct 1996 15:29:06 -0500 (attached) sommerfeld at apollo.hp.com writes: > I'd like to propose that the key management protocol > specifications only be responsible for generating a "blob" of > key material at least N bits long containing at least K bits of > entropy. For obvious reasons, K <= N. > The word "entropy" may be confusing. The important factor is the cryptographic strength of the keys. Even if a key may have a lot of random bits used for its creation (like a DH key) its strength depends on the actual algorithms that we know for attacking that key (and its uses). For example, in the case of DH keys based on primes of 1024 bit length the strength is between 90-100 bits (in the sense that current attacks on DH or discrete log take in the order of 2^90-2^100 operations). Hugo PS: just as a remark, the entropy of a DH key g^xy is 0 given that the components g^x and g^y are public and uniquely determine g^xy. Received: from relay.hq.tis.com by neptune.TIS.COM id aa08665; 29 Oct 96 16:19 EST Received: by relay.hq.tis.com; id QAA12146; Tue, 29 Oct 1996 16:23:24 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma012132; Tue, 29 Oct 96 16:22:59 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id QAA07511 for ; Tue, 29 Oct 1996 16:24:47 -0500 (EST) Received: by relay.hq.tis.com; id QAA12124; Tue, 29 Oct 1996 16:22:54 -0500 Received: from igw3.watson.ibm.com(129.34.139.18) by relay.tis.com via smap (V3.1.1) id xma012076; Tue, 29 Oct 96 16:22:35 -0500 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id QAA17836; Tue, 29 Oct 1996 16:22:17 -0500 Received: from hawpub.watson.ibm.com (hawpub.watson.ibm.com [9.2.90.19]) by mailhub1.watson.ibm.com (8.7.1/10-26-96) with SMTP id QAA04233; Tue, 29 Oct 1996 16:22:05 -0500 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA16817; Tue, 29 Oct 1996 16:22:04 -0500 From: Uri Blumenthal Message-Id: <9610292122.AA16817@hawpub.watson.ibm.com> Subject: Re: independence of keying material for multiple transforms To: Greg Troxel Date: Tue, 29 Oct 1996 16:22:04 -0500 (EST) Cc: ipsec@TIS.COM In-Reply-To: <199610291743.MAA12547@aardvark.bbn.com> from "Greg Troxel" at Oct 29, 96 12:43:17 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk Greg Troxel says: > I'd like to concur with the notion expressed in a recent message that > documents explicitly make the point that when raw keying material is > used to generate blobs that whatever entropy was 'used' to generate > this not be reused when generating another blob. I don't think it's really necessary - but it depends on the exposure of that "blob" in question. > Or perhaps, that it > should be computationally infeasible to determine information about > any bit in blob A given the entire contents of blobs B,C,D. Yes, this looks like the requirement needed and sufficient. But again, it depends on "who knows that blob". -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From: Dan McDonald Message-Id: <199610292134.NAA21839@jurassic.eng.sun.com> Subject: Re: proposed IPSEC changes/extensions To: daw@cs.berkeley.edu Date: Tue, 29 Oct 1996 13:34:03 -0800 (PST) Cc: ipsec@TIS.COM X-Mailer: ELM [version 2.4 PL21] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk > While I don't know what the requirements ought to be, I thought I'd throw > in a brief word of implementation experience. > > When I was implementing ipsec, I found that handling arbitrarily-nested > combinations was easy. On inbound processing, just strip off an ipsec > header, and recurse: throw the packet back in the inbound queue. (You > only have to maintain a bit of state for authentication.) You also might have to maintain state for encryption (i.e. was the packet decrypted or not). Just make sure that when you get "spaghetti transforms" (to steal from both structured and object-oriented folks) you don't accidentally accept a packet that your policy says you shouldn't accept. Careful implementation will insure that this doesn't happen. > Certainly support for *sending* packets with arbitrarily-nested headers > is harder to implement. Yep! I'm not sure you need to support all that many nesting types on outbound packets. The NRL IPv6/IPsec code has a relatively simple model, which I plan on using in my current project. Dan Received: from relay.hq.tis.com by neptune.TIS.COM id aa14981; 29 Oct 96 17:19 EST Received: by relay.hq.tis.com; id RAA14182; Tue, 29 Oct 1996 17:23:55 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma014174; Tue, 29 Oct 96 17:23:28 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id RAA11080 for ; Tue, 29 Oct 1996 17:25:16 -0500 (EST) Received: by relay.hq.tis.com; id RAA14166; Tue, 29 Oct 1996 17:23:25 -0500 Received: from tik1.ethz.ch(129.132.119.131) by relay.tis.com via smap (V3.1.1) id xma014152; Tue, 29 Oct 96 17:23:09 -0500 Received: from kom30.ethz.ch (kom30 [129.132.66.8]) by tik1.ethz.ch (8.7.5/8.7.3) with ESMTP id XAA11585; Tue, 29 Oct 1996 23:24:50 +0100 (MET) From: Germano Caronni Received: (from caronni@localhost) by kom30.ethz.ch (8.7.5/8.7.3) id XAA08726; Tue, 29 Oct 1996 23:24:47 +0100 (MET) Message-Id: <199610292224.XAA08726@kom30.ethz.ch> Subject: Re: A hole in esp-stream-01 To: JMKELSEY@delphi.com Date: Tue, 29 Oct 1996 23:24:46 +0100 (MET) Cc: ipsec@TIS.COM In-Reply-To: <01IB31SYGDLU8ZINVB@delphi.com> from "JMKELSEY@delphi.com" at Oct 26, 96 03:36:33 am X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk JMKELSEY@delphi.com wrote: > Now, remember, we turned the high bit off in the ciphertext byte, > and on in the plaintext byte. What this means is that we subtracted > 128 from the ciphertext byte, and added it back in the plaintext > byte. Thus, (C[4]* + P[4]*) = (C[4] + P[4]). > > If we have to also deal with the CRC of this, so long as the CRC > polynomial is known, we can just flip the bits that would have > changed in the CRC, right? Right. Consider my proposals to 'fix' esp-stream as retracted. It either has to be a real (fast) MAC, or a note in the 'Security Considerations'. What do you people prefer? Germano Received: from relay.hq.tis.com by neptune.TIS.COM id aa02470; 29 Oct 96 19:46 EST Received: by relay.hq.tis.com; id TAA17225; Tue, 29 Oct 1996 19:50:57 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma017221; Tue, 29 Oct 96 19:50:30 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id TAA15203 for ; Tue, 29 Oct 1996 19:52:19 -0500 (EST) Received: by relay.hq.tis.com; id TAA17214; Tue, 29 Oct 1996 19:50:27 -0500 Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1.1) id xma017209; Tue, 29 Oct 96 19:50:21 -0500 Received: from [128.89.30.10] (ARA10.BBN.COM [128.89.30.10]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id TAA19720 for ; Tue, 29 Oct 1996 19:52:20 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Oct 1996 19:54:09 -0600 To: ipsec@TIS.COM From: Stephen Kent Subject: more on IPSEC architecture Sender: ipsec-approval@neptune.tis.com Precedence: bulk Folks, In speaking with Steve Bellovin this morning, he pointed out that my note from yesterday failed to call out several important details. First, in expanding on the MIB that Ran initially defined, it is important to note than not all of the variables should be readable, or readable by remote workstations. The obvious examples here are the authentication and encryption keys cited in the MIB. Second, I did not include the explanatoy text for the various combinations of modes that I proposed as required for compliant implementations. These modes are somewhat different for hosts vs. secuirty gateways and a full discussion takes some space. For example, it strikes me as useful to be able to have two nested ESP SAs, one tunnel mode and one transport mode, where the tunnel SA terminates at the security gateway and the transport SA goes all the way to the target host. If a host is going to be able to take advantage of this potential, then there must be an administrative interface of some sort to permit selection of this combination of modes and SA nesting, as well as allowing for the more obvious, non-nested SA configurations. (As Steve and I discussed this morning, the security gateway need not be aware of the nested, transport mode ESP SA for the above-cited example, so in this case the gateway has an easier task!) Finally, although I listed the AH-ESP(tunnel)-ESP(transport) configuration, I'm not wedded to it. The utility of AH has declined somewhat since ESP has become more flexible and functional. However, AH still has advantages with regard to exportability and for circumstances where the contents of the IP header must be protected, e.g., when security labels are being carried. On that basis, one might argue for ESP(tunnel)-AH-ESP(transport) as a more useful configuration, e.g., to protect such labels within a trusted, MLS network environment. I hope these clarifications help place my earlier note in context. Steve Received: from relay.hq.tis.com by neptune.TIS.COM id aa03270; 29 Oct 96 19:52 EST Received: by relay.hq.tis.com; id TAA17318; Tue, 29 Oct 1996 19:56:57 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma017313; Tue, 29 Oct 96 19:56:29 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id TAA15273 for ; Tue, 29 Oct 1996 19:58:20 -0500 (EST) Received: by relay.hq.tis.com; id TAA17309; Tue, 29 Oct 1996 19:56:27 -0500 Date: Tue, 29 Oct 1996 19:56:27 -0500 Message-Id: <199610300056.TAA17309@relay.hq.tis.com> Received: from ns.worldnet.att.net(204.127.129.1) by relay.tis.com via smap (V3.1.1) id xma017307; Tue, 29 Oct 96 19:55:59 -0500 Received: from LOCALNAME ([165.238.77.157]) by mtigwc01.worldnet.att.net (post.office MTA v2.0 0613 ) with SMTP id AAA26979; Wed, 30 Oct 1996 00:58:01 +0000 X-Sender: mike.sabin@postoffice.worldnet.att.net X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Stephen Kent From: Michael Sabin Subject: Re: proposed IPSEC changes/extensions Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 02:58 AM 10/29/96 +0000, Stephen Kent wrote: > For ESP, the changes are much more significant. The protocol >(header) will consist of a set of optional, mostly variable-length fields, >each of which is selected at SA establishment to describe the specific >security services desired for the SA. The optional fields include an IV, >sequence number for anti-replay, and an integrity check value (in addition >to the static SPI and next protocol fields, and the padding). Thus there >are no new fields (not already described in some existing tranform) nor >substantive changes in processing description. (We've been talking about >compression for a while, more so recently, but I don't know if there a need >for any new fields for this, rather than just an SA characteristicto be >negotiated?) Compression is greatly helped by including a field that controls two functions: (1) whether or not the contents of the packet are compressed; and (2) whether or not the compression state was reset prior to this packet. Here is why: 1) Compressing a packet sometimes actually expands its contents. This is most common with short packets. When expansion occurs, it is better to send the uncompressed version of the packet. This requires each packet to have a bit that identifies the packet as compressed or not. 2) Compression is stateful, which means that the transmitter and receiver can get out of sync if packets are missed. To deal with this, the transmitter frequently resets its compression state to a known starting value, allowing an out-of-sync receiver to resync. A convenient way to accommodate this is to include a bit in each packet that indicates whether or not the compression state was reset prior to compressing this packet. We recently developed an ESP transform based on the Hughes draft that includes compression (see below). We included a "Compression Control" field (one byte) that has a bit for each of these two functions. I vote that such a field be included as an optional field in the ESP. Regards, mike sabin > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Combined 3DES-CBC, LZS Compression, HMAC, and > Replay Prevention ESP Transform > Author(s) : M. Sabin, R. Monsour > Filename : draft-sabin-esp-des3-lzs-md5-00.txt > Pages : 18 > Date : 10/23/1996 > >This document proposes the "3DES-CBC-LZS-HMAC-Replay" security transform >for the IP Encapsulating Security Payload (ESP). The proposed transform >combines triple-DES encryption, LZS compression, HMAC authentication, and >replay prevention into a single packet format. The transform is compatible >with implementations that do not support compression and with >implementations that support only single-DES encryption. Compression is >performed prior to encryption, which has the side benefit of reducing the >amount of data that must be encrypted. > >This document is based on the IPsec Working Group's proposed "Combined >DES-CBC, HMAC, and Replay Prevention Security Transform," cited later in >this document. > Received: from relay.hq.tis.com by neptune.TIS.COM id aa11729; 30 Oct 96 6:45 EST Received: by relay.hq.tis.com; id GAA21986; Wed, 30 Oct 1996 06:49:33 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma021982; Wed, 30 Oct 96 06:49:05 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id GAA21586 for ; Wed, 30 Oct 1996 06:50:53 -0500 (EST) Received: by relay.hq.tis.com; id GAA21978; Wed, 30 Oct 1996 06:49:03 -0500 Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1.1) id xma021976; Wed, 30 Oct 96 06:48:33 -0500 Received: from [128.89.30.7] (ARA7.BBN.COM [128.89.30.7]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id GAA06782; Wed, 30 Oct 1996 06:50:31 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Oct 1996 06:52:21 -0600 To: pau@watson.ibm.com From: Stephen Kent Subject: Re: proposed IPSEC changes/extensions Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Pau-Chen, I thought some more about the question of where the info shoukld live that defines the set of IP datagrams that map into a single SA. My initial response to your message was that I may have put this data in the wrong place, by listing it in the per-SA MIB. However, the right answer may be that it lives in two places: the MIB entry I described and a separate database that defines policy. My thinking is that when we receive an outbound packet we have to do a table lookup to determine if any existing SA is appropriate for carrying this packet, or if a new SA must be established. The first check is made against a database of existing SAs, while the second refers to a separate database that expresses the static policy of what sort of SAs should be created. Thus it would seem reasonable to make the first check against a databse that showed what set of selectors were already in use for outbound traffic. In that context, your suggestion about explicitly listing the set of IP addresses (ports, etc.) bound to a single SA makes sense and may be better than the wildcard address approach I described (depending on the search details). If an explicit address list were used, then a new packet that could be carried on an existing bulk SA would not be immediately recognizzed, but when it was referred to the SA policy the wildcard match would indicate that the packet could be muxed with other traffic. Then one would have to make a different check to see if such an SA already exists and add this outboud address to the explicit list bound to that SA. These processing details are below the level one would want in the spec, but having this sort of model to discuss may help resolve the questions you raised. Steve Message-ID: <32776224.1FCA@ascend.com> Date: Wed, 30 Oct 1996 09:11:48 -0500 From: Karl Fox Reply-To: karl@ascend.com Organization: Ascend Communications X-Mailer: Mozilla 3.0 (Win95; I) MIME-Version: 1.0 To: Michael Sabin CC: ipsec@TIS.COM Subject: Re: proposed IPSEC changes/extensions References: <199610300056.TAA17309@relay.hq.tis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk Michael Sabin wrote: > Compression is greatly helped by including a field that controls two > functions: (1) whether or not the contents of the packet are compressed; > and (2) whether or not the compression state was reset prior to this packet. It seems to me that such a field could easily be prepended to the (possibly) compressed data before encryption takes place, being merely a part of the compression transform and therefore not requiring any ESP header space. Besides, wouldn't this be more secure? -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 Received: from relay.hq.tis.com by neptune.TIS.COM id aa09032; 30 Oct 96 9:42 EST Received: by relay.hq.tis.com; id JAA25488; Wed, 30 Oct 1996 09:46:33 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma025485; Wed, 30 Oct 96 09:46:05 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id JAA01211 for ; Wed, 30 Oct 1996 09:47:53 -0500 (EST) Received: by relay.hq.tis.com; id JAA25480; Wed, 30 Oct 1996 09:46:03 -0500 Received: from ns.newbridge.com(192.75.23.67) by relay.tis.com via smap (V3.1.1) id xma025470; Wed, 30 Oct 96 09:45:39 -0500 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id JAA00984 for ; Wed, 30 Oct 1996 09:47:43 -0500 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma000835; Wed Oct 30 09:47:16 1996 Received: from tsntsrv2.timestep.com ([192.168.219.191]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id JAA00385 for ; Wed, 30 Oct 1996 09:47:08 -0500 Received: by tsntsrv2.timestep.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BBC647.A85E7180@tsntsrv2.timestep.com>; Wed, 30 Oct 1996 09:49:35 -0500 Message-ID: From: Andrew Robison To: "'ipsec@TIS.COM'" Subject: RE: A hole in esp-stream-01 Date: Wed, 30 Oct 1996 09:49:33 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk >From: Germano Caronni[SMTP:caronni@tik.ee.ethz.ch] >Sent: October 29, 1996 5:24 PM > >JMKELSEY@delphi.com wrote: >> Now, remember, we turned the high bit off in the ciphertext byte, >> and on in the plaintext byte. What this means is that we subtracted >> 128 from the ciphertext byte, and added it back in the plaintext >> byte. Thus, (C[4]* + P[4]*) = (C[4] + P[4]). >> >> If we have to also deal with the CRC of this, so long as the CRC >> polynomial is known, we can just flip the bits that would have >> changed in the CRC, right? > >Right. Consider my proposals to 'fix' esp-stream as retracted. It either has to be a real (fast) MAC, or a note in the 'Security Considerations'. >What do you people prefer? What about putting a random sized pad at the start and end of the packet as follows such that a known plaintext attack would find it difficult to actually correctly find the plaintext to change: pad_length|pad1|original_packet|pad2|original_packet_length If you assume that original_packet and original_packet_length are completely or partially known, would it be possible to guess pad_length and therefore bypass pad1 and pad2? If pad_length is a four bits (padded out randomly to a byte) and pad1 and pad2 are randomly set between 0 and 15 bytes, would this make it harder to make a successful modification? With a basic 32 bit checksum of bytes it would be as follows: pad_length|pad1|original_packet|checksum|pad2|original_packet_length Received: from relay.hq.tis.com by neptune.TIS.COM id aa14704; 30 Oct 96 10:22 EST Received: by relay.hq.tis.com; id KAA26883; Wed, 30 Oct 1996 10:27:04 -0500 From: pau@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma026872; Wed, 30 Oct 96 10:26:35 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id KAA03461 for ; Wed, 30 Oct 1996 10:28:23 -0500 (EST) Received: by relay.hq.tis.com; id KAA26868; Wed, 30 Oct 1996 10:26:34 -0500 Received: from igw3.watson.ibm.com(129.34.139.18) by relay.tis.com via smap (V3.1.1) id xma026866; Wed, 30 Oct 96 10:26:26 -0500 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id KAA15256; Wed, 30 Oct 1996 10:28:36 -0500 Received: from secpwr.watson.ibm.com (secpwr.watson.ibm.com [9.2.24.17]) by mailhub1.watson.ibm.com (8.7.1/10-26-96) with SMTP id KAA671400; Wed, 30 Oct 1996 10:28:24 -0500 Received: by secpwr.watson.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA22586; Wed, 30 Oct 1996 10:30:33 -0500 Date: Wed, 30 Oct 1996 10:30:33 -0500 Message-Id: <9610301530.AA22586@secpwr.watson.ibm.com> To: kent@bbn.com Subject: Re: proposed IPSEC changes/extensions Cc: ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Md5: APHYSVBYtQin7nH6Cfy2SA== Sender: ipsec-approval@neptune.tis.com Precedence: bulk Steve, thank you for the quick response. I put my comments after your = text. Regards, Pau-Chen In message Stephen Kent wrote : >=20 > Pau-Chen, >=20 > I thought some more about the question of where the info = shoukld > live that defines the set of IP datagrams that map into a single SA. = My > initial response to your message was that I may have put this data in = the > wrong place, by listing it in the per-SA MIB. However, the right = answer > may be that it lives in two places: the MIB entry I described and a > separate database that defines policy. My thinking is that when we = receive > an outbound packet we have to do a table lookup to determine if any > existing SA is appropriate for carrying this packet, or if a new SA = must be > established. The first check is made against a database of existing = SAs, > while the second refers to a separate database that expresses the = static > policy of what sort of SAs should be created. Thus it would seem > reasonable to make the first check against a databse that showed what = set > of selectors were already in use for outbound traffic. In that = context, > your suggestion about explicitly listing the set of IP addresses = (ports, > etc.) bound to a single SA makes sense and may be better than the = wildcard > address approach I described (depending on the search details). If an > explicit address list were used, then a new packet that could be = carried on > an existing bulk SA would not be immediately recognizzed, but when it = was > referred to the SA policy the wildcard match would indicate that the = packet > could be muxed with other traffic. Then one would have to make a = different > check to see if such an SA already exists and add this outboud address = to > the explicit list bound to that SA. These processing details are = below the > level one would want in the spec, but having this sort of model to = discuss > may help resolve the questions you raised. >=20 > Steve >=20 > My model is the policy will tell which (kind of) SA to use. So the 1st = search is done through the policy to determine which (knid of) SA, if any, = should be used. Then we go through the existing SA's to see if an SA meeting the = policy requirements exists. If one exists, then we can just uses it. If not, = one can be created. The policy will carry the notions of wildcard, address = range, protocols, port ranges, etc.(God knows what.). (Of course, a simple = mechanism is invented to define a "kind of" SA.) The intention here is to decouple the policy from the SA. I consider = policy is very subjective and can, at least in theory, appears in many different = forms; so it is not standarized (and IMHO, it should not be.). But SA should be = simple, precise and standarized (at least in conceptual level), so SA can be = negotiated by standard KMP.=20 At present, the above concept has been implemented in IBM IPSEC code = (including a key refreshment protocol (not ISAKMP)) and placed in IBM firewall. It seems to work pretty well. I do think, however, it is useful for an end of an SA to advise the = other end how it wishes the SA to be used. This may be done by communicating protocol, port (ranges) in the KMP in addition to address (ranges).=20 Pau-Chen Received: from relay.hq.tis.com by neptune.TIS.COM id aa19589; 30 Oct 96 14:45 EST Received: by relay.hq.tis.com; id OAA07690; Wed, 30 Oct 1996 14:50:14 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma007685; Wed, 30 Oct 96 14:49:49 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id OAA25485 for ; Wed, 30 Oct 1996 14:51:35 -0500 (EST) Received: by relay.hq.tis.com; id OAA07674; Wed, 30 Oct 1996 14:49:44 -0500 Received: from ns.newbridge.com(192.75.23.67) by relay.tis.com via smap (V3.1.1) id xma007667; Wed, 30 Oct 96 14:49:34 -0500 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id OAA02477 for ; Wed, 30 Oct 1996 14:51:37 -0500 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma002334; Wed Oct 30 14:50:58 1996 Received: from tsntsrv2.timestep.com ([192.168.219.191]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id OAA17186 for ; Wed, 30 Oct 1996 14:50:53 -0500 Received: by tsntsrv2.timestep.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BBC672.379FC6D0@tsntsrv2.timestep.com>; Wed, 30 Oct 1996 14:54:14 -0500 Message-ID: From: Roy Pereira To: 'Bob Monsour' , 'Stephen Kent' Cc: "'ipsec@TIS.COM'" Subject: RE: Suggestion for ESP 3DES MD5 document Date: Wed, 30 Oct 1996 14:54:10 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk >>Your point is well taken and I will make sure that compression is >>identified as an option within ESP. Should we include compression within ESP or should we include it within its own header? While the Encapsulating Security Payload "is a mechanism for providing integrity and confidentiality to IP datagrams", it might not be the right header to place compression information into. A separate header, like the one in [draft-thayer-seccomp-00.txt], might work out better. ISAKMP or any other KEP could negotiate the available compression routines (ZLIB, etc..), but the actual decision to compress the packet would be left for the sender. A sample packet might look like this: original: IP { TCP { HTTP { DATA }}} >new: IP' { COMP { AH, ESP { IP { TCP { HTTP { DATA }}}}}} > > X-Sender: rah@pop.tiac.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Oct 1996 15:40:02 -0500 To: FC97 Announcement List From: Robert Hettinga Subject: Financial Cryptography 1997 (FC97): General Announcement Sender: ipsec-approval@neptune.tis.com Precedence: bulk =46inancial Cryptography 1997 (FC97): The world's first financial cryptography conference, workshop, and exhibitio= n! General Announcement Conference, and Exhibition, =46ebruary 24-28, 1997 Workshop for Senior Managers and IS Professionals =46ebruary 17-21, 1997 The Inter-Island Hotel Anguilla, BWI The world's first peer-reviewed conference on financial cryptography, =46C97, will be held Monday through Friday, February 24-28, 1997, from 8:30a= m until 12:30pm, at the Inter-Island Hotel on the Carribbean island of Anguilla. In conjunction with the conference, the Inter-Island Hotel will also be the site of an intensive 40-hour workshop for senior managers and IS professionals, during the week preceeding the conference (February 17-21), and an exhibition for financial cryptography vendors, from 10am-6pm during the week of conference itself. The goals of the combined conference, workshop, and exhibition are to provide a peer-reviewed forum for important research in financial cryptography and the effects it will have on society, to give senior managers and IS professionals a solid understanding of the fundamentals of strong cryptgraphy as applied to financial operations on public networks, and to showcase the newest products in the field. In addition, plenty of time has been left open in the afternoon and evening for sponsored corporate functions and activities, for business networking, and, of course, for recreational activities on Anguilla itself. As one of the principals of the conference joked, "We hope that people will treat the conference and the other activities more as a working vacation, rather than, er, vacating work." Conference participants are encouraged to bring their families. The Conference Ray Hirschfeld, the conference chair, has picked an outstanding group of professionals and researchers, in financial cryptography, and in related fields, to review the papers for this conference. They are: Chairman: Rafael Hirschfeld, CWI, Amsterdam, The Netherlands Matthew Franklin, AT&T Laboratories--Research, Murray Hill, NJ, USA Michael Froomkin, U. Miami School of Law, Coral Gables, FL, USA Arjen Lenstra, Citibank, New York, NY, USA Mark Manasse, Digital Equipment Corporation, Palo Alto, CA, USA Kevin McCurley, Sandia Laboratories, Albuquerque, NM, USA Charles Merrill, McCarter & English, Newark, NJ, USA Clifford Neuman, Information Sciences Institute, Marina del Rey, CA, USA Sholom Rosen, Citibank, New York, NY, USA Israel Sendrovic, Federal Reserve Bank of New York, New York, NY, USA Some of the names may be recognizable to you. But, if they're not, included in that list are the inventor of Millicent, the head of EU's CAFE digital cash project, the holders of Citicorp's digital cash patent, two famous scholars in cryptography and digital commerce law, the Chair of Eurocrypt '96, and the Chairman of the Taskforce on the Security of Electronic Money for the Bank for International Settlements. If we'd gotten any more talent, we couldn't have had a conference, because the committee can't review the work of it's own members! The actual agenda of the conference will be determined by the papers the program committee selects, so we won't have a final schedule for the conference until the middle of January. However, the conference committee is selecting papers in what it considers the union, and not the intersection, of the fields of finance and cryptography. Examples of topics it will consider are: Anonymous Payments Fungibility Authentication Home Banking Communication Security Identification Conditional Access Implementations Copyright Protection Loss Tolerance Credit/Debit Cards Loyalty Mechanisms Currency Exchange Legal Aspects Digital Cash Micropayments Digital Receipts Network Payments Digital Signatures Privacy Issues Economic Implications Regulatory Issues Electronic Funds Transfer Smart Cards Electronic Purses Standards Electronic Voting Tamper Resistance Electronic Wallets Transferability =46inancial Cryptography '97 is held in cooperation with the International Association for Cryptologic Research. The conference proceedings will be published on the web by the Journal for Internet Banking and Commerce. . =46or further information on submitting a paper to the FC97, and other details about the program of the conference, please see program committee's web-page at . On the lighter side, the conference will be covered by Wired Magazine, and will be the featured conference in it's January 1997, (ahem...) "Deductible Junkets" section. So, you might want to register, and make your plane and hotel reservations, before the rush begins... The price of a pass to the conference sessions and exhibits is $1,000 U.S. (Since we're on Anguilla, and there are no taxes of any kind, we thought we'd keep prices in nice round numbers, just to make things interesting. :-).) The price includes breakfast at the conference, some stipends for presenters who need them, and the logistics of having a professional conference with high-bandwidth internet connectivity in a location like Anguilla. In looking around, however, the conference organizers *did* notice that FC97 price is in keeping with other business and professional technology conferences of similar total session length, so everything seems to work out. The market *is* efficient, after all. You can register, and pay for, your conference ticket at: The Exhibition Concurrent with the conference will be the the FC97 Exhibition, a small trade show for financial cryptography products and services. Each booth will have high bandwidth access to the internet (yes, there *are* T1s in Anguilla), and will get 2 conference passes. Booth prices start at $5,000 US. Please contact Julie Rackliffe at for further information . As space is limited, please register as soon as possible if you plan to be there. The Workshop We are especially honored to have Ian Goldberg as the leader of the FC97 Workshop, which will run one week prior to the conference, February 17-21, 1997. Ian, the cryptographer at Berkeley who was made famous last year (in articles in both the Wall Street Journal and the New York Times) for breaking Netscape's transaction security protocols, will be running an intensive, 5-day workshop for senior managers and technology professionals. While the workshop is still being developed, and will depend on the skills of the planned participants, workshop topics will include, but not be limited to: The Internet (depending on the background of the participants) Overview and background of cryptography Survey of existing and proposed Internet payment systems Details on some specific payment systems Issues involved in setting up a secure Internet site And, depending on whether Ian finishes coding it (it looks likely), a step-by-step walkthrough of setting up an ecash-enabled Web server. Ian has recruited strong roster of instructors with credentials similar to his own, and, as he plans to maintain a 5-1 student/teacher ratio, the size of the workshop will be restricted and 2 months advance registration well be required. =46urther information about the workshop can be found at: The planned price for the workshop is $5,000. This covers lab space, hardware, network access, software, and, of course, 40 hours of instruction and structured lab activity. The lab itself will be open 24 hours a day, if demand warrants it. Sponsorship Opportunities =46C97 offers many exciting sponsorship opportunities at all levels. Corporations are encouraged to to be an exclusive sponsor for lunch or dinner, each of which will be followed by a recreational activity of some kind. Sponsors will have the opportunity to permanently attach their name to these important networking functions, which the organizers hope will be a large part of the conference experience. There are 10 such events being planned, and 10 corporations will be accepted for sponsorship. Corporate sponsors of these events will also get a substantial initial discount on exhibit space, and complementary conference tickets. In-kind sponsorship is available at all levels of support, with opportunities for companies to provide networking, bandwidth, hardware, radio pocket modems and equipment, as well as design and print services, transportation, entertainment, catering, sunscreen and, well, if you've got it and you think we'll need it, let us know about it -- we probably do. Please contact Julie Rackliffe at for further sponsorship information. Air Transportation and Hotels Air travel to Anguilla is typically done through either St. Thomas for US flights, or St. Maarten/Martin for flights from Europe. Several non-stop flights a day from various US and European locations can be made to either destination. Connection through to Anguilla can be made through American Eagle, or through LIAT. See your travel agent for details. American Eagle Airlines has agreed to increase their flights as needed to accomodate any extra traffic the conference brings to the island. Anguilla's runway is 3600 feet, with a displaced threshold of 600 feet, and can accomodate business jets. Obviously, you should talk to your own FBO for details about your own aircraft's capabilities in this regard. Anguilla import duties are not imposed on hardware or software which will leave the island again, so, as long as you take it with you when you leave you won't pay taxes for leaving it there. Hotels range from spartan to luxurious, and more information about hotels on Anquilla can be obtained from your travel agent, or at . Why Anguilla? We picked Anguilla for two reasons, both of them mildly political. The first is, of course, the US ITARs, which classify cryptography as a "munition" and restrict it's export. Thus, every effort will be made to highlight the absurdity of these regulations through the use of foriegn software, "leaked" software, and, of course, where necessary, US-exportable "crippleware", in the networking and server software of the conference and workshop. Of course, the conference content itself is not a violation of the ITARs, as the "munitions" being exported are in the heads of the attendees, or on paper, and thus not (typically!) subject to the US ITARs. Consider it a mild tweak on the nose of the Clinton Administration, in an era of 56-bit exportable keysize maxima. The other mildly political reason is that Anguilla is a tax haven. There are no taxes except import duties. None. No income, capital gains, sales, excise, or property taxes -- none. Anguilla's banking secrecy laws are about the finest there are anywhere. This is important to the organizers of the conference because most of the other proposed regulations of financial cryptography, particularly those of "token", or "note" based systems, are because they enable cash settlement, even perfectly anonymous cash settlement, of transactions of practically any size. Economic reality is not optional; if, in fact, the significantly reduced cost of these technologies make auditable "book-entry" transaction settlement obsolete, then there isn't much that the taxation or law-enforcement authorities of the world's nation-states can do about it. We consider countries like Anguilla an existance proof of the concept. Any attempt to restrict these technologies will only backfire on nations attempting to do so. Nation-states will simply have to develop taxation and law enforcement methods other than auditing book-entries. In fact, most central bankers and financial crime enforcement professionals who understand the technology also realize this, so, of course, our point is only *mildly* political, at this stage of the argument, anyway. Of course, the fact that Anguilla's average daytime temperature in February is in the low 80's farenheit, and that of, say, Boston, is in the low 20's, and the fact that cyclonic storms are in the *other* hemisphere that time of year, has *nothing*, we say, *nothing* to do with our decision to hold a conference there. We're simply shocked you would suggest such a thing. Neither, for that matter, does the fact that the average water visibility on Anguilla's coral reefs can be measured in hundreds of feet (if you can see that far for the blinding riot of color, that is...). Registration for FC97 Again, if you're interested in coming to FC97 see: =46or information on presenting papers at FC97 see: If you're interested in Exhibit space, please contact Julie Rackliffe: If you're interested in sponsoring FC97, also contact Julie Rackliffe: If you're interested in the FC97 Workshop for Senior Managers and IS Professionals, see: See you in Anguilla! The FC97 Organizing Committee Vince Cate and Bob Hettinga, General Chairs Ray Hirschfeld, Conference Chair Ian Goldberg, Workshop Chair Julie Rackliffe, Conference, Exhibit, and Sponsorship Manager ----------------- Robert Hettinga (rah@shipwright.com) e$, 44 Farquhar Street, Boston, MA 02131 USA "The cost of anything is the foregone alternative" -- Walter Johnson The e$ Home Page: http://www.vmeng.com/rah/ ----------------- Robert Hettinga (rah@shipwright.com) e$, 44 Farquhar Street, Boston, MA 02131 USA "The cost of anything is the foregone alternative" -- Walter Johnson The e$ Home Page: http://www.vmeng.com/rah/ Received: from relay.hq.tis.com by neptune.TIS.COM id aa07343; 30 Oct 96 17:17 EST Received: by relay.hq.tis.com; id RAA13440; Wed, 30 Oct 1996 17:21:29 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma013431; Wed, 30 Oct 96 17:21:02 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id RAA08710 for ; Wed, 30 Oct 1996 17:22:49 -0500 (EST) Received: by relay.hq.tis.com; id RAA13420; Wed, 30 Oct 1996 17:21:00 -0500 Received: from ns.newbridge.com(192.75.23.67) by relay.tis.com via smap (V3.1.1) id xma013412; Wed, 30 Oct 96 17:20:55 -0500 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id RAA11998 for ; Wed, 30 Oct 1996 17:22:58 -0500 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma011807; Wed Oct 30 17:22:30 1996 Received: from tsntsrv2.timestep.com ([192.168.219.191]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id RAA24942 for ; Wed, 30 Oct 1996 17:22:24 -0500 Received: by tsntsrv2.timestep.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BBC687.3F46A6A0@tsntsrv2.timestep.com>; Wed, 30 Oct 1996 17:24:46 -0500 Message-ID: From: Roy Pereira To: 'Bob Monsour' , 'Stephen Kent' Cc: "'ipsec@TIS.COM'" Subject: RE: Suggestion for ESP 3DES MD5 document Date: Wed, 30 Oct 1996 17:24:44 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk >>>Your point is well taken and I will make sure that compression is >>>identified as an option within ESP. >> >>Should we include compression within ESP or should we include it within >>its own header? >> >>While the Encapsulating Security Payload "is a mechanism for providing >>integrity and confidentiality to IP datagrams", it might not be the >>right header to place compression information into. A separate header, >>like the one in [draft-thayer-seccomp-00.txt], might work out better. >>ISAKMP or any other KEP could negotiate the available compression >>routines (ZLIB, etc..), but the actual decision to compress the packet >>would be left for the sender. >> >>A sample packet might look like this: >> >>original: IP { TCP { HTTP { DATA }}} >>new: IP' { COMP { AH, ESP { IP { TCP { HTTP { DATA }}}}}} > My mistake, the new packet would obvisously look like: new: IP' { AH, ESP { COMP { IP { TCP { HTTP { DATA }}}}}} > Date: Wed, 30 Oct 1996 14:21:27 -0800 From: Ran Atkinson Message-Id: <199610302221.OAA03485@cornpuffs.cisco.com> To: ipsec@TIS.COM Subject: Re: proposed IPSEC changes/extensions In-Reply-To: <9610301530.AA22586@secpwr.watson.ibm.com> Organization: cisco Systems Sender: ipsec-approval@neptune.tis.com Precedence: bulk In article <9610301530.AA22586@secpwr.watson.ibm.com> Pau-Chen wrote: [ASIDE: Pau-Chen, it would be most helpful in improving readability of your email if you would not have lines longer than ~70 characters when you send it out. :-] % My model is the policy will tell which (kind of) SA to use. So the 1st % search is done through the policy to determine which (knid of) SA, if any, % should be used. Then we go through the existing SA's to see if an SA meeting % the policy requirements exists. If one exists, then we can just uses it. If % not, one can be created. The policy will carry the notions of wildcard, % address range, protocols, port ranges, etc.(God knows what.). (Of course, a % simple mechanism is invented to define a "kind of" SA.) This is not unlike the NRL implementation, which was described in a USENIX paper last January and is freely available to all. For background, recall that the NRL code is based on 4.4 BSD and hence uses mbufs. OUTBOUND PROCESSING: ip_output() calls ipsec_output_policy() for the outbound datagram. ipsec_output_policy() decides whether IPsec is required or not and what kind of IPsec is needed (if needed). Then ipsec_output_policy() calls the Key Engine to obtain either an existing SA that conforms to policy or to have the Key Engine obtain an appropriate SA. ipsec_output_policy() has 3 possible return values to ip_output() when IPsec is needed: -- IPsec is needed and the SA data is provided in the return. -- IPsec is needed, but the SAs are not yet available. -- IPsec is needed, but the SA is not obtainable at all. In case 1, the packet goes through IPsec output processing and is sent out the interface. In case 2, the outbound packet is temporarily queued until the SAs get created by key management. In case 3, the packet is discarded and an appropriate counter is incremented. Note that none of this NRL code is specific to any particular KM protocol. Anything that can fit on PF_KEY will work just fine. Note also that ipv6_output() should be substituted for ip_output() throughout the above when IPv6 is used instead of IPv4. INPUT PROCESSING: At ip_input() time _after_ reassembly, IPsec input processing is performed if IPsec is present in the packet. If IPsec input processing completes successfully, appropriate flags are set in the incoming mbuf header. Then system policy can be applied to the incoming mbuf chain, discarding the chain if policy dictates. Further upper-layer processing occurs next. Finally, socket-specific application policy is applied and the packet is either discarded or passed to the application. NRL Source code is available within the US for examination at http://web.mit.edu/network/isakmp/ Outside the US, try looking at: ftp://ftp.ripe.net/ipv6/nrl/IPv6_domestic.tar.gz IMHO the "identity" values of an IPsec Security Association can be very important when implementing support for various policies. Examples of widely used identities are USER_FQDN (e.g. "user@full-domain"), FQDN (e.g. "fully-qualified-domain-name), CONNECTION-ID (e.g. IP address, upper-layer protocol, port number), IP ADDR (an IP address), and IP ADDR RANGE (range of IP addresses). Ran rja@cisco.com Received: from relay.hq.tis.com by neptune.TIS.COM id aa15100; 30 Oct 96 18:26 EST Received: by relay.hq.tis.com; id SAA14569; Wed, 30 Oct 1996 18:31:00 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma014566; Wed, 30 Oct 96 18:30:38 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id SAA10370 for ; Wed, 30 Oct 1996 18:32:23 -0500 (EST) Received: by relay.hq.tis.com; id SAA14550; Wed, 30 Oct 1996 18:30:32 -0500 Received: from stilton.cisco.com(171.69.1.161) by relay.tis.com via smap (V3.1.1) id xma014543; Wed, 30 Oct 96 18:30:14 -0500 Received: from cisco.com (localhost.cisco.com [127.0.0.1]) by stilton.cisco.com (8.6.12/8.6.5) with ESMTP id PAA07726; Wed, 30 Oct 1996 15:30:51 -0800 Message-Id: <199610302330.PAA07726@stilton.cisco.com> To: Naganand Doraswamy cc: Bill Sommerfeld , "C. Harald Koch" , Ran Atkinson , ipsec@TIS.COM Subject: Re: allocation of key material into keys In-reply-to: Your message of "Tue, 29 Oct 1996 08:27:25 EST." <2.2.32.19961029132725.00c13120@mailserv-H.ftp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7723.846718251.1@cisco.com> Date: Wed, 30 Oct 1996 15:30:51 -0800 From: David Carrel Sender: ipsec-approval@neptune.tis.com Precedence: bulk I think it is very important that we remove the convention that the Hughes draft uses to bind key generation for both directions of an ESP tunnel to a single key blob. The key management protocol should be useful for many services without having to have specific knowledge about those services. This concept of key derivation becomes IPSEC specific. Instead I believe the KMP should deliver a key blob for each SA that is negotiated. Dave > >Agreed. Each SA/SPI instantiated by the key mgmt protocol needs to > >get a different, independant, blob of entropy. > > > > Correct me if I am wrong. Jim Hughes draft on esp-des currently specifies > deriving the the keys for the Initiator and the Responder from the same > keying materail K. Are we suggesting here that we should be using different > keying materail or can we still use the same keying materail but change the > input to the hash algorithm by padding something. > > --Naganand > ---------------------------------------------------------------- > naganand@ftp.com > Tel #: (508)684-6743 (O) > X-Sender: rah@pop.tiac.net Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Oct 1996 19:07:07 -0500 To: ipsec@neptune.tis.com From: Robert Hettinga Subject: Re: Financial Cryptography 1997 (FC97): General Announcement Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 3:40 pm -0500 10/30/96, Robert Hettinga wrote: > Financial Cryptography 1997 (FC97): > The world's first financial cryptography conference, workshop, and >exhibition! Ack! I'm very, very, sorry. I didn't mean to send this here. I have *no* idea what I was thinking... Cheers, Bob Hettinga ----------------- Robert Hettinga (rah@shipwright.com) e$, 44 Farquhar Street, Boston, MA 02131 USA "The cost of anything is the foregone alternative" -- Walter Johnson The e$ Home Page: http://www.vmeng.com/rah/ Date: Thu, 31 Oct 1996 09:46:34 -0500 From: Hilarie Orman Message-Id: <199610311446.JAA02150@earth.hpc.org> To: ipsec@TIS.COM Subject: Re: proposed IPSEC changes/extensions Sender: ipsec-approval@neptune.tis.com Precedence: bulk > > Certainly support for *sending* packets with arbitrarily-nested headers > > is harder to implement. > Yep! I don't see why. Define the SA's, make a list of them, perform some form of "open" operation with the list. Send. Interpret list, one SA at a time. Hilarie Date: Thu, 31 Oct 1996 09:50:25 -0500 From: Hilarie Orman MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Message-Id: <199610311450.JAA02288@earth.hpc.org> To: msabin@netcom.com Cc: ipsec@TIS.COM In-reply-to: Yourmessage <199610300153.SAA16259@baskerville.CS.Arizona.EDU> Subject: Re: proposed IPSEC changes/extensions Sender: ipsec-approval@neptune.tis.com Precedence: bulk > 2) Compression is stateful, which means that the transmitter and receiver > can get out of sync if packets are missed. Isn't stateful compression is most logically done as a separate protocol, performed prior to any IPSEC encryption? Hilarie Orman Message-ID: Date: 31 Oct 1996 10:02:17 -0400 From: WaterhouseR Subject: ISAKMP Questions To: IPSEC Working Group X-Mailer: Mail*Link SMTP-MS 3.0.2 Sender: ipsec-approval@neptune.tis.com Precedence: bulk The following is based on draft-ietf-ipsec-isakmp-05. I find myself confused re the following. 3.5.6 says "If the basic exchange types are inadequate to meet the requirements within a DOI, a designer can define up to thirteen extra exchange types per DOI." Now Exchange Type is carried in the Header, but DOI is carried in the SA Payload. This seems to imply that every Exchange Type must begin with an SA Payload, something which is probably harmless in Phase 1. But in Phase 2, it appears to have the further implication that the SA Payload be unencrypted (since you can't process the Header without accessing the SA Payload). It has the further implication that if the Payloads are encrypted only one SA can be negotiated at a time between a pair of Negotiation Servers (since you need access to the SPIs to interpret Exchange Type if you are trying to negotiate for more than one association at the same time). My initial reaction is that DOI is mispositioned to support the more general capability suggested in 3.5.6. But perhaps I am overlooking something. Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; MMDF-Warning: Parse error in original version of preceding line at Message-ID: <9610311035.aa17853@neptune.TIS.COM> neptune.TIS.COM cc: ipsec@TIS.COM From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ah-hmac-md5-03.txt Date: Thu, 31 Oct 1996 10:01:43 -0500 Message-ID: <9610311001.aa25654@ietf.org> Sender: ipsec-approval@neptune.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : HMAC-MD5 IP Authentication with Replay Prevention Author(s) : M. Oehler, R. Glenn Filename : draft-ietf-ipsec-ah-hmac-md5-03.txt Pages : 7 Date : 10/30/1996 This document describes a keyed-MD5 transform to be used in conjunction with the IP Authentication Header [RFC-1826]. The particular transform is based on [HMAC-MD5]. An option is also specified to guard against replay attacks. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ah-hmac-md5-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ah-hmac-md5-03.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-md5-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961030145250.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-md5-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ah-hmac-md5-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961030145250.I-D@ietf.org> --OtherAccess-- --NextPart-- Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; MMDF-Warning: Parse error in original version of preceding line at Message-ID: <9610311036.aa17969@neptune.TIS.COM> neptune.TIS.COM cc: ipsec@TIS.COM From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ah-hmac-sha-03.txt Date: Thu, 31 Oct 1996 10:01:47 -0500 Message-ID: <9610311001.aa25671@ietf.org> Sender: ipsec-approval@neptune.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : HMAC-SHA IP Authentication with Replay Prevention Author(s) : S. Chang, R. Glenn Filename : draft-ietf-ipsec-ah-hmac-sha-03.txt Pages : 7 Date : 10/30/1996 This document describes a keyed-SHA transform to be used in conjunction with the IP Authentication Header [RFC-1826]. The particular transform is based on [HMAC-MD5]. An option is also specified to guard against replay attacks. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ah-hmac-sha-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ah-hmac-sha-03.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-sha-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961030150401.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-sha-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ah-hmac-sha-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961030150401.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from relay.hq.tis.com by neptune.TIS.COM id aa02033; 31 Oct 96 13:03 EST Received: by relay.hq.tis.com; id NAA01727; Thu, 31 Oct 1996 13:06:57 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma001704; Thu, 31 Oct 96 13:06:36 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id NAA13697 for ; Thu, 31 Oct 1996 13:08:17 -0500 (EST) Received: by relay.hq.tis.com; id NAA01683; Thu, 31 Oct 1996 13:06:29 -0500 Received: from capone.ch.apollo.hp.com(15.254.24.3) by relay.tis.com via smap (V3.1.1) id xma001657; Thu, 31 Oct 96 13:05:57 -0500 Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id ; Thu, 31 Oct 1996 13:07:14 -0500 Received: from thunk (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.7.5/8.6.12) with ESMTP id NAA00482; Thu, 31 Oct 1996 13:06:59 -0500 (EST) Message-Id: <199610311806.NAA00482@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: Hilarie Orman Cc: msabin@netcom.com, ipsec@TIS.COM Subject: Re: proposed IPSEC changes/extensions In-Reply-To: ho's message of Thu, 31 Oct 1996 09:50:25 -0500. <199610311450.JAA02288@earth.hpc.org> Date: Thu, 31 Oct 1996 13:06:52 -0500 From: Bill Sommerfeld Sender: ipsec-approval@neptune.tis.com Precedence: bulk > Isn't stateful compression most logically done as a separate > protocol, performed prior to any IPSEC encryption? Maybe from a "purity of layers" perspective, but stateful compression requires similar message-sequencing goop as replay detection; there are likely some real efficiencies from handling both at the same time.. - Bill Received: from relay.hq.tis.com by neptune.TIS.COM id aa24094; 31 Oct 96 16:51 EST Received: by relay.hq.tis.com; id QAA10067; Thu, 31 Oct 1996 16:47:33 -0500 From: pau@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma010047; Thu, 31 Oct 96 16:47:10 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id QAA01415 for ; Thu, 31 Oct 1996 16:48:53 -0500 (EST) Received: by relay.hq.tis.com; id QAA10030; Thu, 31 Oct 1996 16:47:03 -0500 Received: from igw3.watson.ibm.com(129.34.139.18) by relay.tis.com via smap (V3.1.1) id xma010018; Thu, 31 Oct 96 16:46:50 -0500 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id QAA18296; Thu, 31 Oct 1996 16:49:02 -0500 Received: from secpwr.watson.ibm.com (secpwr.watson.ibm.com [9.2.24.17]) by mailhub1.watson.ibm.com (8.7.1/10-26-96) with SMTP id QAA14362; Thu, 31 Oct 1996 16:48:49 -0500 Received: by secpwr.watson.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA21928; Thu, 31 Oct 1996 16:51:00 -0500 Date: Thu, 31 Oct 1996 16:51:00 -0500 Message-Id: <9610312151.AA21928@secpwr.watson.ibm.com> To: rja@cisco.com Subject: Re: proposed IPSEC changes/extensions Cc: ipsec@TIS.COM Mime-Version: 1.0 Content-Type: multipart/mixed;boundary=41c6_167e-2781_446b-794b_15fb Sender: ipsec-approval@neptune.tis.com Precedence: bulk --41c6_167e-2781_446b-794b_15fb Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-MD5: AAAAAAAAAAAAAAAAAAAAAA== --41c6_167e-2781_446b-794b_15fb Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-MD5: AAAAAAAAAAAAAAAAAAAAAA== Content-Description: Attachment.txt X-Content-Name: Attachment.txt --41c6_167e-2781_446b-794b_15fb Content-Type: application/octet-stream Content-Transfer-Encoding: quoted-printable Content-MD5: N4bBqVhLUFDTR95uxp+BJA== Content-Description: Reply X-Content-Name: Reply In <9610301530.AA22586@secpwr.watson.ibm.com> Ran Atkinson wrote : >In article <9610301530.AA22586@secpwr.watson.ibm.com> Pau-Chen wrote: > >[ASIDE: Pau-Chen, it would be most helpful in improving readability >of your email if you would not have lines longer than ~70 characters >when you send it out. :-] I did some change, I hope this msg will be fine. > >% My model is the policy will tell which (kind of) SA to use. So the = 1st >% search is done through the policy to determine which (knid of) SA, if = any, >% should be used. Then we go through the existing SA's to see if an SA = meeting >% the policy requirements exists. If one exists, then we can just uses = it. If >% not, one can be created. The policy will carry the notions of = wildcard, >% address range, protocols, port ranges, etc.(God knows what.). (Of = course, a >% simple mechanism is invented to define a "kind of" SA.) > >This is not unlike the NRL implementation, which was described in a = USENIX >paper last January and is freely available to all. For background, = recall >that the NRL code is based on 4.4 BSD and hence uses mbufs. A paper describing IBM's code appeared in the 5th USENIX UNIX Security = Conf., 1995. The title is :=20 "Design and Implementation of Modular Key Management Protocol and IP Secure Tunnel on AIX". > >OUTBOUND PROCESSING: > ip_output() calls ipsec_output_policy() for the outbound > datagram. ipsec_output_policy() decides whether IPsec is > required or not and what kind of IPsec is needed (if needed). > Then ipsec_output_policy() calls the Key Engine to obtain > either an existing SA that conforms to policy or to have > the Key Engine obtain an appropriate SA. > > ipsec_output_policy() has 3 possible return values to ip_output() > when IPsec is needed: > -- IPsec is needed and the SA data is provided in the return. > -- IPsec is needed, but the SAs are not yet available. > -- IPsec is needed, but the SA is not obtainable at all. > > In case 1, the packet goes through IPsec output processing and > is sent out the interface. In case 2, the outbound packet is > temporarily queued until the SAs get created by key management. > In case 3, the packet is discarded and an appropriate counter > is incremented. > > Note that none of this NRL code is specific to any particular KM > protocol. Anything that can fit on PF_KEY will work just fine. > > Note also that ipv6_output() should be substituted for ip_output() > throughout the above when IPv6 is used instead of IPv4. > > >INPUT PROCESSING: > > At ip_input() time _after_ reassembly, IPsec input processing > is performed if IPsec is present in the packet. If IPsec input > processing completes successfully, appropriate flags are set > in the incoming mbuf header. Then system policy can be applied > to the incoming mbuf chain, discarding the chain if policy dictates. =20 > Further upper-layer processing occurs next. Finally, socket-specific=20 > application policy is applied and the packet is either discarded=20 > or passed to the application. > >NRL Source code is available within the US for examination at > http://web.mit.edu/network/isakmp/ >Outside the US, try looking at: > ftp://ftp.ripe.net/ipv6/nrl/IPv6_domestic.tar.gz > >IMHO the "identity" values of an IPsec Security Association can be very >important when implementing support for various policies. Examples of = widely >used identities are USER_FQDN (e.g. "user@full-domain"), FQDN >(e.g. "fully-qualified-domain-name), CONNECTION-ID (e.g. IP address, >upper-layer protocol, port number), IP ADDR (an IP address), and IP = ADDR RANGE >(range of IP addresses). Ran, I am curious how UFDQN would be used in policy, especially in input filtering. Could you elaborate a little more on this ? Thank you. Regards, Pau-Chen > >Ran >rja@cisco.com > > > --41c6_167e-2781_446b-794b_15fb-- Received: from relay.hq.tis.com by neptune.TIS.COM id aa04833; 31 Oct 96 18:46 EST Received: by relay.hq.tis.com; id SAA12560; Thu, 31 Oct 1996 18:50:16 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma012556; Thu, 31 Oct 96 18:49:47 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id SAA05596 for ; Thu, 31 Oct 1996 18:51:33 -0500 (EST) Received: by relay.hq.tis.com; id SAA12552; Thu, 31 Oct 1996 18:49:46 -0500 Received: from netmail.austin.ibm.com(129.35.208.98) by relay.tis.com via smap (V3.1.1) id xma012550; Thu, 31 Oct 96 18:49:42 -0500 Received: from vulcan.austin.ibm.com (vulcan.austin.ibm.com [129.35.56.115]) by netmail.austin.ibm.com (8.6.12/8.6.11) with SMTP id RAA50732 for ; Thu, 31 Oct 1996 17:51:40 -0600 Received: by vulcan.austin.ibm.com (AIX 3.2/UCB 5.64/4.03-client-2.4) for ipsec@tis.com at austin.ibm.com; id AA25929; Thu, 31 Oct 1996 17:51:37 -0600 From: Will Fiveash Message-Id: <9610312351.AA25929@vulcan.austin.ibm.com> Subject: ISPEC docs in AFS To: ipsec@TIS.COM Date: Thu, 31 Oct 1996 17:51:36 -0600 (CST) Reply-To: will@austin.ibm.com X-Mailer: ELM [version 2.4ME+ PL26 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk I put all the IETF IPSEC drafts in: /afs/austin/depts/f13s/projects/ipsec/docs -- Will Fiveash IBM AIX System Development Internet: will@austin.ibm.com 11400 Burnet Road, Bld.905/9551 VNET: FIVEASH AT AUSTIN Austin, TX 78758-3493 Phone:(512) 838-7904(off)/3509(fax), T/L 678-7904 Received: from relay.hq.tis.com by neptune.TIS.COM id aa12016; 31 Oct 96 19:59 EST Received: by relay.hq.tis.com; id UAA13696; Thu, 31 Oct 1996 20:03:46 -0500 From: HUGO@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma013692; Thu, 31 Oct 96 20:03:18 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id UAA06870 for ; Thu, 31 Oct 1996 20:05:03 -0500 (EST) Received: by relay.hq.tis.com; id UAA13686; Thu, 31 Oct 1996 20:03:16 -0500 Received: from igw3.watson.ibm.com(129.34.139.18) by relay.tis.com via smap (V3.1.1) id xma013682; Thu, 31 Oct 96 20:03:13 -0500 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id UAA16524; Thu, 31 Oct 1996 20:05:28 -0500 Received: from yktvmv.watson.ibm.com (yktvmv.watson.ibm.com [9.117.33.29]) by mailhub1.watson.ibm.com (8.7.1/10-26-96) with SMTP id UAA586175; Thu, 31 Oct 1996 20:05:16 -0500 Message-Id: <199611010105.UAA586175@mailhub1.watson.ibm.com> Received: from YKTVMV by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 6616; Thu, 31 Oct 96 20:05:13 EST Date: Thu, 31 Oct 96 19:52:21 EST To: IPSEC@TIS.COM cc: rob.glenn@nist.gov, shu-jen.chang@nist.gov Subject: I-D ACTION:draft-ietf-ipsec-ah-hmac-sha-03.txt Sender: ipsec-approval@neptune.tis.com Precedence: bulk Ref: Your note of Thu, 31 Oct 1996 19:06:38 -0500 I insist with my previous recommendation. Define hmac-sha to output 128 bits (out of the final 160 bits result). It most probably help security and saves up to 64 bits in 64-bit alignments. Hugo PS: I am appending a message that I sent to the list a couple of months ago on this issue. If anyone has a good reason against this recommendation please send it to the list. > Thus, I am proposing that instead of padding the 160 bits of SHA output > to 192 bits, truncate the result to 128 bits. > > Beyond the advantage for bandwidth, this truncation is plausible to > add to the security. > > In general, it is an old practice to truncate MACs. In the context > of keyed-hash this has been explicitely proposed by Preneel and van > Oorschot (Crypto'95). I do not know of any *proof* that > truncating adds to the security. However, there are examples of attacks where > this is the case. And as long as you do not truncate "too much" > then everything indicates that it helps. In particular, I know of no > reason how or why truncating HMAC-SHA to 128 bits would hurt in any scenario. > > Note: Be careful not to get confused with the unkeyed uses of SHA. > There, collision resistance is usually the sacred goal and truncating the > output HURTS HURTS HURTS (because of birthday attacks). > For keyed-hash for message authentication the story is very different. > Actually, the justification for truncation in [PV] is *exactly* > because it helps *against* birthday attacks. > (Yes, I know it sounds confusing but that's the way it is...) > Still in the application of HMAC the 160 bits in the definition of SHA help > as the length of the *intermediate* results of the compression function, > but not as the final result. > > ANyway, truncation as a general method has an advantage (less information > available to the adversary) and a disadvantage (less bits to predict for the > attacker). When truncating 160 to 128 the advatage is far more significant > than the disadvantage (It would be different if we truncated to 64 bits; > that would make me uncomfortable -- 80 bits for SHA or even for MD5 are my > "personal minimum".) > > BTW, in the RFC on HMAC that I am submitting to the IETF there is a section > on truncation of HMAC output. > > ---------- > > The patent issue: > > There is a patent by Novell (US 5349642) that claims keyed hash functions > for message authentication. Such claim would cover (I am not a lawyer!) > all hash based schemes that have ever been suggested in this WG, including HMA > Fortunately, the filing date of that patent is Nov 3 1992, while > Gene Tsudik's paper proposing such functions appeared in Infocom in May 1992. > (This work is also part of Gene's UCLA's PhD dissertation of May 1991). > > The one element that does not appear in Tsudik's work is truncation. > However, truncating the output of MAC functions is an old and very well > known practice in cryptography. For example, > > [MM] Meyer, S. and Matyas, S.M., Cryptography, New York Wiley, 1982. > > [ANSI] ANSI X9.9, ``American National Standard for Financial > Institution Message Authentication (Wholesale),'' American > Bankers Association, 1981. Revised 1986. > > and therefore a hard to defend claim (I'm not a lawyer!!). > > After consulting with Jeff Schiller and the WG chairs, it became clear > to me that the existence of Novell's patent shouldn't be an obstacle to > include a section on truncation in the HMAC rfc, and more significantly, > to propose it for adoption for AH-HMAC-SHA. > > Hugo > Date: 31 Oct 1996 15:55:40 -0400 From: WaterhouseR Subject: One Last Comment To: IPSEC Working Group X-Mailer: Mail*Link SMTP-MS 3.0.2 Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9611010756.aa00194@neptune.TIS.COM> 4. The timer/retry logic is incompletely specified. Consider the second (last) message sent by the Responder to the Initiator in the Base Exchange. The criterion the Rwesponder is to use in this case for turning off his timer/retry is not specified. Also no criterion is provided for the receiving Protocol Machine to clear his states and return to IDLE when nothing is received.