Received: from relay.tis.com by neptune.TIS.COM id aa08263; 1 Mar 96 6:18 EST Received: by relay.tis.com; id GAA04870; Fri, 1 Mar 1996 06:20:09 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma004865; Fri, 1 Mar 96 06:19:41 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA26980; Fri, 1 Mar 96 06:18:37 EST Received: by relay.tis.com; id GAA04862; Fri, 1 Mar 1996 06:19:39 -0500 Received: from info.forthnet.gr(139.91.1.17) by relay.tis.com via smap (V3.1) id xma004857; Fri, 1 Mar 96 06:19:16 -0500 Received: from vicky.forthnet.gr by info.forthnet.gr via FORTHnet with SMTP; id NAA09205 (8.6.12/FORTHNET-2.0); Fri, 1 Mar 1996 13:14:40 +0200 (EET DST) Message-Id: <199603011114.NAA09205@info.forthnet.gr> Organization: To: hugo@watson.ibm.com Cc: ipsec@TIS.COM, rja@cisco.com, PALAMBER@us.oracle.com Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward In-Reply-To: Your message of "Thu, 29 Feb 1996 13:49:30 EST." <199602291926.OAA24213@relay.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <26518.825678872.1@forthnet.gr> Date: Fri, 01 Mar 1996 13:14:32 +0200 From: "Angelos D. Keromytis" Sender: ipsec-request@neptune.tis.com Precedence: bulk In message <199602291926.OAA24213@relay.tis.com>, hugo@watson.ibm.com writes: >I suggest NOT moving forward RFC1828. > >Let's replace that transform by the keyed-MD5 transform >of Bellare, Canetti and Krawczyk, >as described in draft-krawczyk-keyed-md5-01.txt. >(This function is now named HMAC). I, for one, agree; this transform seems better than the one we currently have. -Angelos Received: from relay.tis.com by neptune.TIS.COM id aa08620; 1 Mar 96 6:52 EST Received: by relay.tis.com; id GAA05153; Fri, 1 Mar 1996 06:54:40 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma005145; Fri, 1 Mar 96 06:54:16 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27670; Fri, 1 Mar 96 06:53:07 EST Received: by relay.tis.com; id GAA05138; Fri, 1 Mar 1996 06:54:10 -0500 Received: from ktik0.ethz.ch(129.132.66.42) by relay.tis.com via smap (V3.1) id xma005134; Fri, 1 Mar 96 06:54:05 -0500 Received: from komsys-pc-gc.ethz.ch (komsys-pc-gc.ethz.ch [129.132.66.22]) by ktik0 (8.6.8.1/8.6.6) with SMTP id MAA11063 for ; Fri, 1 Mar 1996 12:54:58 +0100 Message-Id: <2.2.32.19960301120435.006b4810@ktik0.ethz.ch> X-Sender: caronni@ktik0.ethz.ch X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 01 Mar 1996 13:04:35 +0100 To: ipsec@TIS.COM From: Germano Caronni Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward Sender: ipsec-request@neptune.tis.com Precedence: bulk At 13:36 29.2.96 -0800, you wrote: >There has been very strong support for the use of HMAC as the "standard" >transform for AH. A "change" of this mechanism sooner, rather than later, >would limit the impact on implementors. >From an implementors standpoint, I fully agree. Now is the easiest time to change the algorithm employed. Later will be harder, as implementations will tend to proliferate. So this forum 'simply' needs to make up its mind if it's appropriate to change from 'keyed MD5' to a new transform. HMAC certainly is not weaker than keyed MD5, and strong indications exist that it is indeed stronger, so I for one would prefer to have HMAC in the RFC. Germano Received: from relay.tis.com by neptune.TIS.COM id aa09923; 1 Mar 96 8:27 EST Received: by relay.tis.com; id IAA06158; Fri, 1 Mar 1996 08:29:39 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma006153; Fri, 1 Mar 96 08:29:11 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01930; Fri, 1 Mar 96 08:28:07 EST Received: by relay.tis.com; id IAA06150; Fri, 1 Mar 1996 08:29:09 -0500 Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1) id xma006146; Fri, 1 Mar 96 08:28:57 -0500 Received: from hawpub.watson.ibm.com ([9.2.90.19]) by igw2.watson.ibm.com (8.7.4/8.7.1) with SMTP id IAA23896; Fri, 1 Mar 1996 08:30:07 -0500 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/2/16/96) id AA37794; Fri, 1 Mar 1996 08:30:00 -0500 Message-Id: <9603011330.AA37794@hawpub.watson.ibm.com> Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward To: perry@piermont.com Date: Fri, 1 Mar 1996 08:29:59 -0500 (EST) From: Uri Blumenthal Cc: ipsec@TIS.COM In-Reply-To: <199603010158.UAA19307@jekyll.piermont.com> from "Perry E. Metzger" at Feb 29, 96 08:58:20 pm X-External-Networks: yes Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-request@neptune.tis.com Precedence: bulk Perry E. Metzger writes: > > There has been very strong support for the use of HMAC as the "standard" > > transform for AH. A "change" of this mechanism sooner, rather than later, > > would limit the impact on implementors. > > Fine, but that doesn't necessarily mean "replace". In light of what has already been said, I *strongly suggest* that HMAC should *replace* the current MAC, with, as Steve proposes, a different transform number. And it has to be done NOW. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- Received: from relay.tis.com by neptune.TIS.COM id aa11515; 1 Mar 96 10:02 EST Received: by relay.tis.com; id KAA08495; Fri, 1 Mar 1996 10:04:40 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma008491; Fri, 1 Mar 96 10:04:11 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08778; Fri, 1 Mar 96 10:03:07 EST Received: by relay.tis.com; id KAA08488; Fri, 1 Mar 1996 10:04:10 -0500 Received: from unknown(206.1.51.15) by relay.tis.com via smap (V3.1) id xma008481; Fri, 1 Mar 96 10:03:49 -0500 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) with SMTP id KAA21009; Fri, 1 Mar 1996 10:04:47 -0500 (EST) Message-Id: <199603011504.KAA21009@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: hugo@watson.ibm.com Cc: ipsec@TIS.COM Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward In-Reply-To: Your message of "Thu, 29 Feb 1996 18:31:34 EST." <199602292350.SAA17634@linet02.li.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 01 Mar 1996 10:04:39 -0500 From: "Perry E. Metzger" Sender: ipsec-request@neptune.tis.com Precedence: bulk hugo@watson.ibm.com writes: > Waiting 1-2 years is unrealistic for IETF proposals. Its not unrealistic to wait that long to advance to a high level provided that the proposal is made into an RFC and a proposed standard first so that people know it is standards track. > However, I wish there was a more orderly scrutiny of security designs > for IETF protocols by cryptographers. The process is sometimes chaotic. However, it does, in the end, usually work. Perry Received: from relay.tis.com by neptune.TIS.COM id aa11663; 1 Mar 96 10:08 EST Received: by relay.tis.com; id KAA08660; Fri, 1 Mar 1996 10:10:10 -0500 From: hugo@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma008656; Fri, 1 Mar 96 10:09:42 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA09116; Fri, 1 Mar 96 10:08:38 EST Received: by relay.tis.com; id KAA08647; Fri, 1 Mar 1996 10:09:40 -0500 Message-Id: <199603011509.KAA08647@relay.tis.com> Received: from watson.ibm.com(129.34.139.4) by relay.tis.com via smap (V3.1) id xma008636; Fri, 1 Mar 96 10:09:18 -0500 Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 6285; Fri, 01 Mar 96 10:10:01 EST Date: Fri, 1 Mar 96 10:10:01 EST To: perry@piermont.com Cc: ipsec@TIS.COM Subject: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward Sender: ipsec-request@neptune.tis.com Precedence: bulk Ref: Your note of Fri, 01 Mar 1996 10:04:39 -0500 (attached) > > > However, I wish there was a more orderly scrutiny of security designs > > for IETF protocols by cryptographers. > > The process is sometimes chaotic. However, it does, in the end, > usually work. Right. It works in 95% of the cases. Security is exactly about the remaining 5%. Hugo > > Perry Received: from relay.tis.com by neptune.TIS.COM id aa13244; 1 Mar 96 11:30 EST Received: by relay.tis.com; id LAA10309; Fri, 1 Mar 1996 11:32:52 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma010307; Fri, 1 Mar 96 11:32:25 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA15264; Fri, 1 Mar 96 11:31:20 EST Received: by relay.tis.com; id LAA10300; Fri, 1 Mar 1996 11:32:23 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma010293; Fri, 1 Mar 96 11:32:18 -0500 Received: from jekyll.piermont.com by interlock.ans.net with SMTP id AA17697 (InterLock SMTP Gateway 3.0 for ); Fri, 1 Mar 1996 11:33:19 -0500 Received: (from perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) id LAA21154; Fri, 1 Mar 1996 11:33:11 -0500 (EST) Date: Fri, 1 Mar 1996 11:33:11 -0500 (EST) Message-Id: <199603011633.LAA21154@jekyll.piermont.com> From: "Perry E. Metzger" To: ipsec@ans.net Subject: what I am proposing re HMAC Reply-To: perry@piermont.com X-Reposting-Policy: please ask before redistributing Sender: ipsec-request@neptune.tis.com Precedence: bulk Just to be clear, what I am proposing on HMAC is this: 1) We leave 1828 alone. We do not advance it further but we do not "replace" it, meaning new RFCs do NOT "supersede" it in the way a replacement would. 2) We publish an RFC as a proposed standard for HMAC. 3) We think of the HMAC transform not as a replacement for the existing transforms but as a new transform. Any key negotiation protocols that exist do not replace the meaning of "use the 1828 transform" with using HMAC -- they think of HMAC as a new transform. I do not want the new RFC to "supersede" 1828 as a replacement RFC would. One of the reasons I'm strongly opinioned on this is that I expect this situation will occur over and over in the next decade -- we will discover something and want to replace what people are using. Right now we can fail to advance 1828 as part of this process, but in general what we are doing is creating NEW transforms, not REPLACING old ones. The new transforms are then encouraged to be "must implement". 4) We leave the HMAC RFC at proposed standard long enough for the crypto community to really get its teeth in. Being at proposed should be sufficient to encourage vendors to implement. I know Hugo would probably like it to advance to draft standard more quickly, but my gut instinct says "wait". Proofs are good, I fully believe Hugo is a good crypto guy and that his proofs are excellent, but this is engineering at this point, not math. Proposed standard should be sufficient for a while. 5) If we desire, we may issue a document clarifying 1828 for historical reasons, but we do this as an informational RFC. Perry Received: from relay.tis.com by neptune.TIS.COM id aa14075; 1 Mar 96 12:20 EST Received: by relay.tis.com; id MAA11229; Fri, 1 Mar 1996 12:22:22 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma011225; Fri, 1 Mar 96 12:21:56 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18204; Fri, 1 Mar 96 12:20:51 EST Received: by relay.tis.com; id MAA11216; Fri, 1 Mar 1996 12:21:53 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma011207; Fri, 1 Mar 96 12:21:29 -0500 Received: from relay.hp.com by interlock.ans.net with SMTP id AA19071 (InterLock SMTP Gateway 3.0 for ); Fri, 1 Mar 1996 12:22:22 -0500 Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA021590938; Fri, 1 Mar 1996 09:22:18 -0800 Message-Id: <199603011722.AA021590938@relay.hp.com> Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com id AA243181129; Fri, 1 Mar 1996 12:25:29 -0500 X-Mailer: exmh version 1.6.2 7/18/95 To: perry@piermont.com Cc: ipsec@ans.net Subject: Re: what I am proposing re HMAC In-Reply-To: perry's message of Fri, 01 Mar 1996 11:33:11 -0500. <199603011633.LAA21154@jekyll.piermont.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 01 Mar 1996 12:22:16 -0500 From: Bill Sommerfeld Sender: ipsec-request@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii Just to be clear, what I am proposing on HMAC is this: 1) We leave 1828 alone. We do not advance it further but we do not "replace" it, meaning new RFCs do NOT "supersede" it in the way a replacement would. Agreed, but see the comments to #5 3) We think of the HMAC transform not as a replacement for the existing transforms but as a new transform. Any key negotiation protocols that exist do not replace the meaning of "use the 1828 transform" with using HMAC -- they think of HMAC as a new transform. I do not want the new RFC to "supersede" 1828 as a replacement RFC would. This points out a weakness in the current IPSEC document structure. Each key management method (ISAKMP, Photuris, SKIP, manual) has to solve the exact same problem of "how do I name the transforms". The author of a new transform needs to allocate separate transform id's for each different key management protocol. If there was a common algorithm-id spec defined by the transform-level architecture, the work needed to define new transforms and hook them into the key management infrastructure would be somewhat simplified. [I'd suggest starting with SKIP's algorithm id's because early versions of SKIP have actually been deployed, but it looks to me that the way SKIP handles algorithm id's makes handling combined encryption/MAC/... transforms messy.] One of the reasons I'm strongly opinioned on this is that I expect this situation will occur over and over in the next decade -- we will discover something and want to replace what people are using. Right now we can fail to advance 1828 as part of this process, but in general what we are doing is creating NEW transforms, not REPLACING old ones. The new transforms are then encouraged to be "must implement". I'm in violent agreement with this.. 4) We leave the HMAC RFC at proposed standard long enough for the crypto community to really get its teeth in. Being at proposed should be sufficient to encourage vendors to implement. I know Hugo would probably like it to advance to draft standard more quickly, but my gut instinct says "wait". Proofs are good, I fully believe Hugo is a good crypto guy and that his proofs are excellent, but this is engineering at this point, not math. Proposed standard should be sufficient for a while. 5) If we desire, we may issue a document clarifying 1828 for historical reasons, but we do this as an informational RFC. Instead, why not: (a) in the HMAC draft suggest that implementors implement HMAC-MD5 (or whatever it's called) in addition to 1828 (b) have the IESG relabel 1828 as "historic" when HMAC goes to PS or DS... - Bill -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMTcyQVpj/0M1dMJ/AQEdfgP+K8VcZziZ6NUYyGy6GaL3/KtLvOV/Q7zV WvzHPX77weOh6G2qvaQRmmDU15mih+U1mwEl7FZ/c5ZR2n+XFxL6t4tXiDRugX3G U/PEXtoswpEZUshZ4L7cg6TVqox4U+xV+W3nmJLsBBoL+OZu5Tlt0K49iWE2pmm0 1dhBmEnacIY= =Npz1 -----END PGP SIGNATURE----- Received: from relay.tis.com by neptune.TIS.COM id aa14284; 1 Mar 96 12:29 EST Received: by relay.tis.com; id MAA11484; Fri, 1 Mar 1996 12:31:53 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma011479; Fri, 1 Mar 96 12:31:25 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18642; Fri, 1 Mar 96 12:30:20 EST Received: by relay.tis.com; id MAA11473; Fri, 1 Mar 1996 12:31:23 -0500 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1) id xma011467; Fri, 1 Mar 96 12:31:12 -0500 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) with SMTP id MAA21282; Fri, 1 Mar 1996 12:32:14 -0500 (EST) Message-Id: <199603011732.MAA21282@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: hugo@watson.ibm.com Cc: ipsec@TIS.COM Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward In-Reply-To: Your message of "Fri, 01 Mar 1996 10:10:01 EST." <199603011510.KAA09472@linet02.li.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 01 Mar 1996 12:32:13 -0500 From: "Perry E. Metzger" Sender: ipsec-request@neptune.tis.com Precedence: bulk hugo@watson.ibm.com writes: > > > However, I wish there was a more orderly scrutiny of security designs > > > for IETF protocols by cryptographers. > > > > The process is sometimes chaotic. However, it does, in the end, > > usually work. > > Right. It works in 95% of the cases. > Security is exactly about the remaining 5%. I realize the process may seem like a problem to those who normally work alone on a problem and then proceed to give a document to a set of reviewers for orderly review, but it really isn't. Perhaps we need to use some better tools (a trouble ticket system? I'm not joking) to give people better confidence that edits aren't being dropped on the floor, but the process *does* work in the end, even now. Perry Received: from relay.tis.com by neptune.TIS.COM id aa14829; 1 Mar 96 13:02 EST Received: by relay.tis.com; id NAA12488; Fri, 1 Mar 1996 13:04:19 -0500 From: smb@research.att.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma012484; Fri, 1 Mar 96 13:03:51 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20729; Fri, 1 Mar 96 13:02:47 EST Received: by relay.tis.com; id NAA12478; Fri, 1 Mar 1996 13:03:49 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma012472; Fri, 1 Mar 96 13:03:33 -0500 Received: from research.att.com (ns.research.att.com) by interlock.ans.net with SMTP id AA20470 (InterLock SMTP Gateway 3.0 for ); Fri, 1 Mar 1996 13:04:33 -0500 Message-Id: <199603011804.AA20470@interlock.ans.net> Received: from research.att.com by ns; Fri Mar 1 13:01:55 EST 1996 Received: from gryphon by research; Fri Mar 1 12:58:48 EST 1996 Received: by gryphon; Fri Mar 1 12:58:43 EST 1996 To: perry@piermont.com Cc: ipsec@ans.net Subject: Re: what I am proposing re HMAC Date: Fri, 01 Mar 96 12:58:42 EST Sender: ipsec-request@neptune.tis.com Precedence: bulk Just to be clear, what I am proposing on HMAC is this: 1) We leave 1828 alone. We do not advance it further but we do not "replace" it, meaning new RFCs do NOT "supersede" it in the way a replacement would. 2) We publish an RFC as a proposed standard for HMAC. 3) We think of the HMAC transform not as a replacement for the existing transforms but as a new transform. Any key negotiation protocols that exist do not replace the meaning of "use the 1828 transform" with using HMAC -- they think of HMAC as a new transform. I do not want the new RFC to "supersede" 1828 as a replacement RFC would. One of the reasons I'm strongly opinioned on this is that I expect this situation will occur over and over in the next decade -- we will discover something and want to replace what people are using. Right now we can fail to advance 1828 as part of this process, but in general what we are doing is creating NEW transforms, not REPLACING old ones. The new transforms are then encouraged to be "must implement". 4) We leave the HMAC RFC at proposed standard long enough for the cryp to community to really get its teeth in. Being at proposed should be sufficient to encourage vendors to implement. I know Hugo would probably like it to advance to draft standard more quickly, but my gut instinct says "wait". Proofs are good, I fully believe Hugo is a good crypto guy and that his proofs are excellent, but this is engineering at this point, not math. Proposed standard should be sufficient for a while. 5) If we desire, we may issue a document clarifying 1828 for historical reasons, but we do this as an informational RFC. There's no problem with any of this. But we need point 6 -- the status of 1828 and HMAC as mandatory/recommended/elective etc. What do we tell people they MUST implement? My own view is to make HMAC mandatory and 1828 recommended -- and recommended only because there's already a lot out there. Received: from relay.tis.com by neptune.TIS.COM id aa15248; 1 Mar 96 13:21 EST Received: by relay.tis.com; id NAA12888; Fri, 1 Mar 1996 13:22:49 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma012875; Fri, 1 Mar 96 13:22:20 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21861; Fri, 1 Mar 96 13:21:16 EST Received: by relay.tis.com; id NAA12872; Fri, 1 Mar 1996 13:22:19 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma012869; Fri, 1 Mar 96 13:22:08 -0500 Received: from jekyll.piermont.com by interlock.ans.net with SMTP id AA21033 (InterLock SMTP Gateway 3.0 for ); Fri, 1 Mar 1996 13:23:09 -0500 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) with SMTP id NAA21418; Fri, 1 Mar 1996 13:23:06 -0500 (EST) Message-Id: <199603011823.NAA21418@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: smb@research.att.com MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Cc: ipsec@ans.net Subject: Re: what I am proposing re HMAC In-Reply-To: Your message of "Fri, 01 Mar 1996 12:58:42 EST." <199603011804.NAA29924@linet02.li.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 01 Mar 1996 13:23:01 -0500 From: "Perry E. Metzger" Sender: ipsec-request@neptune.tis.com Precedence: bulk smb@research.att.com writes, re my proposal: > There's no problem with any of this. But we need point 6 -- the status > of 1828 and HMAC as mandatory/recommended/elective etc. What do we > tell people they MUST implement? My own view is to make HMAC mandatory > and 1828 recommended -- and recommended only because there's already > a lot out there. I agree fully with your amendment. This seems like "the right thing". Perry Received: from relay.tis.com by neptune.TIS.COM id aa15803; 1 Mar 96 13:42 EST Received: by relay.tis.com; id NAA13447; Fri, 1 Mar 1996 13:44:49 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma013444; Fri, 1 Mar 96 13:44:20 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA23337; Fri, 1 Mar 96 13:43:16 EST Received: by relay.tis.com; id NAA13441; Fri, 1 Mar 1996 13:44:19 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma013436; Fri, 1 Mar 96 13:43:58 -0500 Received: from igw2.watson.ibm.com by interlock.ans.net with SMTP id AA21688 (InterLock SMTP Gateway 3.0 for ); Fri, 1 Mar 1996 13:44:58 -0500 Received: from hawpub.watson.ibm.com ([9.2.90.19]) by igw2.watson.ibm.com (8.7.4/8.7.1) with SMTP id NAA22500 for ; Fri, 1 Mar 1996 13:44:59 -0500 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/2/16/96) id AA42869; Fri, 1 Mar 1996 13:44:52 -0500 Message-Id: <9603011844.AA42869@hawpub.watson.ibm.com> Subject: Re: what I am proposing re HMAC To: ipsec@ans.net Date: Fri, 1 Mar 1996 13:44:52 -0500 (EST) From: Uri Blumenthal In-Reply-To: <199603011633.LAA21154@jekyll.piermont.com> from "Perry E. Metzger" at Mar 1, 96 11:33:11 am X-External-Networks: yes Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-request@neptune.tis.com Precedence: bulk Perry E. Metzger writes: > Just to be clear, what I am proposing on HMAC is this: > 1) We leave 1828 alone. We do not advance it further but we do not > "replace" it, meaning new RFCs do NOT "supersede" it in the way a > replacement would. I'm against. There are no reasons NOT to "supersede" 1828. > 2) We publish an RFC as a proposed standard for HMAC. > 3) We think of the HMAC transform not as a replacement for the > existing transforms but as a new transform. Yes, certainly. > Any key negotiation > protocols that exist do not replace the meaning of "use the 1828 > transform" with using HMAC -- they think of HMAC as a new > transform. I do not want the new RFC to "supersede" 1828 as a > replacement RFC would. It is a question of what transform will be mandatory and what won't. HMAC should be the mandatory one, for several good reasons. > ...........Right now we can fail to advance 1828 as > part of this process, but in general what we are doing is creating > NEW transforms, not REPLACING old ones. The new transforms are then > encouraged to be "must implement". We are [or should be] making the new transform "must implement" and the old one - "optional". In my eyes it's either a "replace", or very close to it. (:-) -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- Received: from relay.tis.com by neptune.TIS.COM id aa16503; 1 Mar 96 14:17 EST Received: by relay.tis.com; id OAA14110; Fri, 1 Mar 1996 14:19:21 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma014084; Fri, 1 Mar 96 14:18:50 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25640; Fri, 1 Mar 96 14:17:46 EST Received: by relay.tis.com; id OAA14081; Fri, 1 Mar 1996 14:18:49 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma014076; Fri, 1 Mar 96 14:18:32 -0500 Received: from pilot.firewall.is.chrysler.com (pilot.is.chrysler.com) by interlock.ans.net with SMTP id AA22638 (InterLock SMTP Gateway 3.0 for ); Fri, 1 Mar 1996 14:19:32 -0500 Received: by pilot.firewall.is.chrysler.com; id OAA19020; Fri, 1 Mar 1996 14:43:52 -0500 Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilot.is.chrysler.com via smap (g3.0.1) id sma019016; Fri, 1 Mar 96 14:43:50 -0500 Received: from rgm3 ([172.16.8.13]) by clhubgw1.is.chrysler.com (5.x/SMI-4.1) id AA25736; Fri, 1 Mar 1996 14:21:14 -0500 Message-Id: <2.2.32.19960301191824.00381014@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 01 Mar 1996 14:18:24 -0500 To: ipsec@ans.net From: Robert Moskowitz Subject: IETF meetings :( Sender: ipsec-request@neptune.tis.com Precedence: bulk I will not be arriving until Tuesday midnight. I HAVE to be home with the family until after Purim. ERGO I will miss both sessions, sorry. I have been a bit overworked here to get my notes together on what I want for the auto industry (yes I now have a much louder "voice" than in the past), but I can convey that information on wednesday.... See you all then. Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.tis.com by neptune.TIS.COM id aa18104; 1 Mar 96 15:36 EST Received: by relay.tis.com; id PAA16999; Fri, 1 Mar 1996 15:38:43 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma016986; Fri, 1 Mar 96 15:38:21 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA00642; Fri, 1 Mar 96 15:37:15 EST Received: by relay.tis.com; id PAA16974; Fri, 1 Mar 1996 15:38:16 -0500 Received: from unknown(194.100.1.134) by relay.tis.com via smap (V3.1) id xma016945; Fri, 1 Mar 96 15:37:41 -0500 Received: (from ylo@localhost) by trance.olari.clinet.fi (8.6.12/8.6.12) id WAA12732; Fri, 1 Mar 1996 22:41:14 +0200 Date: Fri, 1 Mar 1996 22:41:14 +0200 Message-Id: <199603012041.WAA12732@trance.olari.clinet.fi> From: Tatu Ylonen To: perry@piermont.com Cc: hugo@watson.ibm.com, ipsec@TIS.COM Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward In-Reply-To: <199602292154.QAA18966@jekyll.piermont.com> References: <199602292135.QAA26356@linet02.li.net> <199602292154.QAA18966@jekyll.piermont.com> Organization: Helsinki University of Technology, Finland Sender: ipsec-request@neptune.tis.com Precedence: bulk > > As a general note: if we can't modify the standards during the > > standarization process why do we have that process in place. > > We can alter what is standard. However, it is often bad to alter what > already exists. When SMTP got revised, an extensions mechanism was > created -- existing SMTPs weren't broken. Sometime soon it will be > required that SMTP implementations support ESMTP, but it will > doubtless be a long while before ESMTP is totally universal, if > ever. But, in my understanding IPSEC does not "exist" yet in the same sense as SMTP did. It does not yet have a wide user base, just a few small groups using various implementations. I think it is probably early enough to simply change the spec if it is otherwise justified. (It may not be a bad idea to change the protocol number though if confusion is likely.) Tatu Received: from relay.tis.com by neptune.TIS.COM id aa18172; 1 Mar 96 15:39 EST Received: by relay.tis.com; id PAA17073; Fri, 1 Mar 1996 15:41:13 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma017063; Fri, 1 Mar 96 15:40:43 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA00768; Fri, 1 Mar 96 15:39:39 EST Received: by relay.tis.com; id PAA17060; Fri, 1 Mar 1996 15:40:42 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma017053; Fri, 1 Mar 96 15:40:27 -0500 Received: from inner.net (avarice.inner.net) by interlock.ans.net with SMTP id AA24838 (InterLock SMTP Gateway 3.0 for ); Fri, 1 Mar 1996 15:41:24 -0500 Received: from inner.net ([192.168.1.1]) by inner.net (8.7.4/42) with ESMTP id LAA02374; Fri, 1 Mar 1996 11:43:36 -0500 Message-Id: <199603011643.LAA02374@inner.net> X-Mailer: exmh version 1.6.5 12/11/95 To: uri@watson.ibm.com Cc: ipsec@ans.net Subject: Re: what I am proposing re HMAC In-Reply-To: Your message of "Fri, 01 Mar 1996 13:44:52 EST." <9603011844.AA42869@hawpub.watson.ibm.com> X-Reposting-Policy: With explicit permission only Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 Mar 1996 15:41:02 -0500 From: Craig Metz Sender: ipsec-request@neptune.tis.com Precedence: bulk In message <9603011844.AA42869@hawpub.watson.ibm.com>, you write: >> Any key negotiation >> protocols that exist do not replace the meaning of "use the 1828 >> transform" with using HMAC -- they think of HMAC as a new >> transform. I do not want the new RFC to "supersede" 1828 as a >> replacement RFC would. > >It is a question of what transform will be mandatory and what won't. >HMAC should be the mandatory one, for several good reasons. I guess I may be missing something. People are talking as if RFC-1828 is totally worthless and HMAC is the holy grail, yet I'm not seeing any real data that justifies this conclusion. We know of no *feasable* attacks on RFC-1828, right? And how long have cryptographers been playing with envelope MACs? Now, we have this new MAC. It is probably better. It looks better to us. But it is still new enough that we don't really know. Why the mad rush to replace RFC-1828 with HMAC as the mandatory minimum? First, this obseletes all current implementations. Sure, it's not that difficult to update this, but that doesn't mean you still don't have to do the work and then go through testing cycles again. Second, we're moving from a known to an unknown. How many people have implemented and tested HMAC-based AH? I don't know of any, though the IBM people probably have. At the very least, it doesn't seem like a very good idea to change RFC-1828's status until more people have *implemented* HMAC AH. -Craig Received: from relay.tis.com by neptune.TIS.COM id aa20614; 1 Mar 96 17:30 EST Received: by relay.tis.com; id RAA19700; Fri, 1 Mar 1996 17:32:42 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma019694; Fri, 1 Mar 96 17:32:15 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06709; Fri, 1 Mar 96 17:31:10 EST Received: by relay.tis.com; id RAA19687; Fri, 1 Mar 1996 17:32:12 -0500 Received: from merit.edu(35.1.1.42) by relay.tis.com via smap (V3.1) id xma019681; Fri, 1 Mar 96 17:32:05 -0500 Received: from Bill.Simpson.DialUp.Mich.Net (pm001-02.dialip.mich.net [35.1.48.51]) by merit.edu (8.7.3/merit-2.0) with SMTP id RAA03597 for ; Fri, 1 Mar 1996 17:32:56 -0500 (EST) Date: Fri, 1 Mar 96 21:35:44 GMT From: William Allen Simpson Message-Id: <5033.wsimpson@greendragon.com> To: ipsec@TIS.COM Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward Sender: ipsec-request@neptune.tis.com Precedence: bulk I'm on the road, and don't have a lot of time to reply here: > From: smb@research.att.com > Of course, all along the unanimous opinion of the cryptographic theoreticians > has been that keyed hash functions were an unknown -- they weren't designed > to do that, and it wasn't clear that they were secure in this mode. But > we went ahead anyway. > Yes. And we then learned that the "theoreticians" got it wrong. Randall Atkinson (and Perry and myself and others) originally proposed keying in the most simple and obvious way -- H[key,length,data]. After analysis, we now know that the originally proposed construct is more secure than what the "theoreticians" repeatedly told us we needed to change. As demonstrated within 6 months by other more capable theoreticians. We made a mistake. We made changes without 2 or 3 years of review. We should never have given in to the pressure. I remind you who prompted that change: Date: Tue, 24 Jan 95 18:40:52 EST From: hugo@watson.ibm.com To: bsimpson@MorningStar.Com, IPSEC@ans.net Cc: jis@mit.edu Subject: AH-MD5 Just to break the *quiet* consenus: I personally would prefer to see a prepend+append MD5 for IP authentication. The reasons are a more robust security design, less plausible to suffer yet unknown vulnerabilities or implementation errors, at a very low cost compared to prepend only (notice that MD5, by definition, APPends the length of the information and I didn't see any claims that this causes any significant degradation in performance). Think about his claims in the light of new evidence. > Note carefully: revision is *likely*. If we're going to change it, now is > the time -- after it goes to Draft, it's too late for fixes of this nature > (absent, say, the discovery of a feasible attack). > In retrospect, let me apply the wisdom posted to this list, that prompted Perry and I to make the change to H[key,data,key] rather than Kaliski's proposal: Date: Tue, 14 Mar 95 15:28:27 From: "Housley, Russ" To: Hilarie Orman Cc: ipsec@ans.net Subject: Re[2]: End of WG Last Call for AH+MD5 and ESP+DES+3DES Hilarie said: I think that MD5(key, text, key) may be more secure than the double hash. My understanding is that Kaliski's suggestion was based on the idea that MD5(text) might be a useful subfunction. However, I'm uneasy at the idea of a possible cryptanalysis of MD5(foo,key); not a question I've seen examined before. MD5(key,data,key) is one of the few things we had concensus about. Burt did not say that this was weak, rather he said that the other had more study behind it. I think that we should keep MD5(key,data,key) because it an be computed with one function invocation when implemented in hardware. MD5(MD5(data),key) will require two function invocations in hardware implementations. We now know a very formal analysis shows an IMPRACTICAL attack on H[key,data,key]. But, between the 2 choices, practicality was a principle consideration. That is one of the reasons that DES was chosen over 3DES as required to implement. Yes, we know it's weaker than we'd like. But we _know_ the weaknesses. And it's strong enough for practical purposes. Now, if we wait long enough, we might find even better choices. We have something that works. There is no hurry! WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 Received: from relay.tis.com by neptune.TIS.COM id aa20615; 1 Mar 96 17:30 EST Received: by relay.tis.com; id RAA19699; Fri, 1 Mar 1996 17:32:42 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma019693; Fri, 1 Mar 96 17:32:15 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06708; Fri, 1 Mar 96 17:31:10 EST Received: by relay.tis.com; id RAA19688; Fri, 1 Mar 1996 17:32:12 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma019683; Fri, 1 Mar 96 17:32:06 -0500 Received: from merit.edu by interlock.ans.net with SMTP id AA27321 (InterLock SMTP Gateway 3.0 for ); Fri, 1 Mar 1996 17:33:02 -0500 Received: from Bill.Simpson.DialUp.Mich.Net (pm001-02.dialip.mich.net [35.1.48.51]) by merit.edu (8.7.3/merit-2.0) with SMTP id RAA03601 for ; Fri, 1 Mar 1996 17:32:59 -0500 (EST) Date: Fri, 1 Mar 96 22:03:36 GMT From: William Allen Simpson Message-Id: <5034.wsimpson@greendragon.com> To: ipsec@ans.net Subject: NMAC not HMAC, SHA not MD5 Sender: ipsec-request@neptune.tis.com Precedence: bulk > From: "Perry E. Metzger" > Subject: what I am proposing re HMAC > 1) We leave 1828 alone. We do not advance it further but we do not > "replace" it, meaning new RFCs do NOT "supersede" it in the way a > replacement would. Disagree. We should advance to Draft Standard. We have met the requirements for Draft Standard. > 2) We publish an RFC as a proposed standard for HMAC. Disagree. We should publish a proposed standard for NMAC, which has supporting analysis from multiple researchers. Oh, and I've already written the draft.... HMAC is merely conjectural, and is less efficient to implement than NMAC. And HMAC derives its security from NMAC. If anything, HMAC has a few very specious assumptions. > 3) We think of the HMAC transform not as a replacement for the > existing transforms but as a new transform. Any key negotiation > protocols that exist do not replace the meaning of "use the 1828 > transform" with using HMAC -- they think of HMAC as a new > transform. I do not want the new RFC to "supersede" 1828 as a > replacement RFC would. One of the reasons I'm strongly opinioned on > this is that I expect this situation will occur over and over in > the next decade -- we will discover something and want to replace > what people are using. Right now we can fail to advance 1828 as > part of this process, but in general what we are doing is creating > NEW transforms, not REPLACING old ones. > Agreed! Particularly with the latter. > 4) We leave the HMAC RFC at proposed standard long enough for the crypto > community to really get its teeth in. Being at proposed should be > sufficient to encourage vendors to implement. I know Hugo would > probably like it to advance to draft standard more quickly, but my > gut instinct says "wait". Agreed. > 5) If we desire, we may issue a document clarifying 1828 for > historical reasons, but we do this as an informational RFC. > This is called an "applicability statement" and it is already provided for in our standards process. I have already begun writing it. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 Received: from relay.tis.com by neptune.TIS.COM id aa21422; 1 Mar 96 18:09 EST Received: by relay.tis.com; id SAA20154; Fri, 1 Mar 1996 18:11:16 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma020152; Fri, 1 Mar 96 18:10:47 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA07764; Fri, 1 Mar 96 18:09:43 EST Received: by relay.tis.com; id SAA20149; Fri, 1 Mar 1996 18:10:46 -0500 Received: from merit.edu(35.1.1.42) by relay.tis.com via smap (V3.1) id xma020147; Fri, 1 Mar 96 18:10:21 -0500 Received: from Bill.Simpson.DialUp.Mich.Net (pm001-00.dialip.mich.net [35.1.48.49]) by merit.edu (8.7.3/merit-2.0) with SMTP id SAA04611 for ; Fri, 1 Mar 1996 18:11:22 -0500 (EST) Date: Fri, 1 Mar 96 22:37:07 GMT From: William Allen Simpson Message-Id: <5036.wsimpson@greendragon.com> To: ipsec@TIS.COM Subject: Hugo tutors (Was: (IMPORTANT) ...) Sender: ipsec-request@neptune.tis.com Precedence: bulk > Date: Thu, 29 Feb 96 18:31:34 EST > From: hugo@watson.ibm.com > There is so much traffic in this list these days and I hate contributing > more but this may interest other people in addition to Perry. > > Waiting 1-2 years is unrealistic for IETF proposals. > However, I wish there was a more orderly scrutiny of security designs > for IETF protocols by cryptographers. > > Photuris is a good example. It took me 6 drafts (from 03 to 09) > to convince Simpson to derive *independent* key bits for keyed-MD5 and DES. This is a patently false and misleading statement. Since, until draft -09, AH and ESP always had different SPIs, they also always had independently derived keys. With the advent of the WG request this winter for the _complication_ of having AH and ESP _share_ the same SPI, then the key schedule of ESP-DES in Photuris was required to change. A more _complicated_ design engendered a more _complicated_ keying schedule. No surprise there; these requests seem to avalanche. I find it personally insulting that Hugo claims to have to teach us simple and practical cryptographic features. I will leave it to the rest of you to decide whether he is on track about other "cryptographic sins". > cryptographic sins. I didn't see where is the cryptographic community > that is inspecting this design. I have in hand a quote from another cryptographic analyst: "I am impressed with the thoroughness of the Photuris spec." Thanks anyway.... WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 Received: from relay.tis.com by neptune.TIS.COM id aa22688; 1 Mar 96 19:37 EST Received: by relay.tis.com; id TAA21286; Fri, 1 Mar 1996 19:39:47 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma021280; Fri, 1 Mar 96 19:39:18 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA09469; Fri, 1 Mar 96 19:38:14 EST Received: by relay.tis.com; id TAA21274; Fri, 1 Mar 1996 19:39:17 -0500 Received: from orodruin.cs.berkeley.edu(128.32.38.24) by relay.tis.com via smap (V3.1) id xma021270; Fri, 1 Mar 96 19:39:15 -0500 Received: from espresso.CS.Berkeley.EDU.mammoth (espresso.CS.Berkeley.EDU [128.32.33.40]) by orodruin.CS.Berkeley.EDU (8.7.Gamma.0/8.7.Gamma.0) with SMTP id QAA25358; Fri, 1 Mar 1996 16:40:17 -0800 (PST) Received: by espresso.CS.Berkeley.EDU.mammoth (5.x/SMI-SVR4) id AA20983; Fri, 1 Mar 1996 16:40:01 -0800 From: David A Wagner Message-Id: <9603020040.AA20983@espresso.CS.Berkeley.EDU.mammoth> Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward To: William Allen Simpson Date: Fri, 1 Mar 1996 16:40:00 -0800 (PST) Cc: ipsec@TIS.COM In-Reply-To: <5033.wsimpson@greendragon.com> from "William Allen Simpson" at Mar 1, 96 09:35:44 pm Reply-To: daw@cs.berkeley.edu X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-request@neptune.tis.com Precedence: bulk > Randall Atkinson (and Perry and myself and others) originally proposed > keying in the most simple and obvious way -- H[key,length,data]. > > After analysis, we now know that the originally proposed construct is > more secure than what the "theoreticians" repeatedly told us we needed > to change. As demonstrated within 6 months by other more capable > theoreticians. Technical nitpick: I assume you are claiming that recent attacks on the envelope method show that it's less secure than H[key,length,data] ?? If so, you're mistaken. (Is this really important, anyhow?) The collision-based attacks of Preneel & van Oorschot which apply to the envelope method also apply to H[key,length,data] in exactly the same way. Furthermore, the comments of Kaliski & Robshaw apply to the H[key,length,data] construction (which notably has no padding after the key): short messages might be vulnerable to certain techniques, such as linear cryptanalysis. The envelope method in RFC1828 is strengthened against the short-message concern. We're seeing incremental improvements in hash-based MAC technology due to research by the cryptographers-- that much is apparent, I think. Apolitically yours, -- Dave Wagner Received: from relay.tis.com by neptune.TIS.COM id aa24641; 1 Mar 96 22:17 EST Received: by relay.tis.com; id WAA23549; Fri, 1 Mar 1996 22:19:16 -0500 From: smb@research.att.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma023546; Fri, 1 Mar 96 22:18:55 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA11993; Fri, 1 Mar 96 22:17:44 EST Received: by relay.tis.com; id WAA23543; Fri, 1 Mar 1996 22:18:46 -0500 Message-Id: <199603020318.WAA23543@relay.tis.com> Received: from ns.research.att.com(192.20.225.4) by relay.tis.com via smap (V3.1) id xma023540; Fri, 1 Mar 96 22:18:31 -0500 Received: from research.att.com by ns; Fri Mar 1 22:16:37 EST 1996 Received: from gryphon by research; Fri Mar 1 22:13:40 EST 1996 Received: by gryphon; Fri Mar 1 22:13:35 EST 1996 To: ipsec@TIS.COM Subject: bump-in-the-stack encryptor paper Date: Fri, 01 Mar 96 22:13:34 EST Sender: ipsec-request@neptune.tis.com Precedence: bulk Folks on this list might want to take a look at a paper by David Wagner and myself: ftp://ftp.research.att.com/dist/smb/bisconf.ps. It describes an IPSEC implementation for MS-DOS. Perhaps of more interest than the paper itself are two subtle attacks on IPSEC modules, a fragmentation attack and a routing attack. --Steve Bellovin Received: from relay.tis.com by neptune.TIS.COM id aa29681; 2 Mar 96 7:10 EST Received: by relay.tis.com; id HAA27038; Sat, 2 Mar 1996 07:12:46 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma027035; Sat, 2 Mar 96 07:12:17 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19126; Sat, 2 Mar 96 07:11:13 EST Received: by relay.tis.com; id HAA27029; Sat, 2 Mar 1996 07:12:16 -0500 Received: from unknown(35.1.1.42) by relay.tis.com via smap (V3.1) id xma027025; Sat, 2 Mar 96 07:12:05 -0500 Received: from Bill.Simpson.DialUp.Mich.Net (pm002-20.dialip.mich.net [141.211.7.156]) by merit.edu (8.7.3/merit-2.0) with SMTP id HAA19052 for ; Sat, 2 Mar 1996 07:12:57 -0500 (EST) Date: Sat, 2 Mar 96 11:23:26 GMT From: William Allen Simpson Message-Id: <5037.wsimpson@greendragon.com> To: ipsec@TIS.COM Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward Sender: ipsec-request@neptune.tis.com Precedence: bulk > From: David A Wagner > I assume you are claiming that recent attacks on the envelope method > show that it's less secure than H[key,length,data] ?? If so, you're > mistaken. (Is this really important, anyhow?) > Hmmm, we can put our heads together and compare at LA, but looking at "MDx-MAC" proposition 4 (page 6), finding internal collisions, but no key recovery (yet): / / 2/(s+1) * 2 ** 64 for H[key,length,data] \/ versus "Two MAC" proposition 2 (page 5), with key recovery: / / 2 * 2 ** 64 for H[key,data,key] \/ Seems much weaker to me.... > Furthermore, the comments of Kaliski & Robshaw apply to the > H[key,length,data] construction (which notably has no padding after > the key): short messages might be vulnerable to certain techniques, > such as linear cryptanalysis. Actually, Atkinson's initial key was always padded (since 1993). Although we argued about whether it should be to 128-bits or 512-bits. The consideration was always for efficiency, however; promoted block alignment for IPng and allowed precomputation. And as you may remember, Metzger and I were whipsawed back and forth on the key padding issue by the crypto-theoreticians for several months! I can refer you to messages from Colin Plumb, Eric Rains, Burt Kaliski, Russ Housley, Hilary Orman, Rich Schroeppel, and of course the ubiquitous IBM trio of Amir, Hugo and Uri. > The envelope method in RFC1828 is > strengthened against the short-message concern. > Yes. And I thank you for the contribution. But the reason that it was so easily accepted was it fit with precomputation, and was easy to code! > We're seeing incremental improvements in hash-based MAC technology due > to research by the cryptographers-- that much is apparent, I think. > Yes. I don't see any reason to leap off to yet another transform without considerable validation by multiple analysts. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 Received: from relay.tis.com by neptune.TIS.COM id aa00504; 2 Mar 96 8:22 EST Received: by relay.tis.com; id IAA27246; Sat, 2 Mar 1996 08:24:16 -0500 From: smb@research.att.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma027244; Sat, 2 Mar 96 08:23:47 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19962; Sat, 2 Mar 96 08:22:43 EST Received: by relay.tis.com; id IAA27241; Sat, 2 Mar 1996 08:23:46 -0500 Message-Id: <199603021323.IAA27241@relay.tis.com> Received: from ns.research.att.com(192.20.225.4) by relay.tis.com via smap (V3.1) id xma027239; Sat, 2 Mar 96 08:23:27 -0500 Received: from research.att.com by ns; Sat Mar 2 08:21:37 EST 1996 Received: from gryphon by research; Sat Mar 2 08:17:25 EST 1996 Received: by gryphon; Sat Mar 2 08:17:22 EST 1996 To: ipsec@TIS.COM Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward Date: Sat, 02 Mar 96 08:17:22 EST Sender: ipsec-request@neptune.tis.com Precedence: bulk Who else, besides Bill, thinks that we should go with the current transforms instead of HMAC? Received: from relay.tis.com by neptune.TIS.COM id aa10210; 3 Mar 96 0:01 EST Received: by relay.tis.com; id AAA01291; Sun, 3 Mar 1996 00:03:16 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma001287; Sun, 3 Mar 96 00:02:47 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02216; Sun, 3 Mar 96 00:01:43 EST Received: by relay.tis.com; id AAA01284; Sun, 3 Mar 1996 00:02:46 -0500 Received: from theory.lcs.mit.edu(18.52.0.92) by relay.tis.com via smap (V3.1) id xma001282; Sun, 3 Mar 96 00:02:44 -0500 Received: from cuckoo.lcs.mit.edu by theory.lcs.mit.edu (5.65c/TOC-1.2S) id AA23248; Sun, 03 Mar 96 00:03:45 EST From: Ran Canetti Received: by cuckoo.lcs.mit.edu (5.65c/TOC-1.2C) id AA02132; Sun, 03 Mar 96 00:04:09 EST Date: Sun, 03 Mar 96 00:04:09 EST Message-Id: <199603030504.AA02132@cuckoo.lcs.mit.edu> To: ipsec@TIS.COM Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward Sender: ipsec-request@neptune.tis.com Precedence: bulk The following telegraphic presentation attempts at summing up our relevant knowledge, accumulated during the past year or two, on the use of keyed hash functions as MACs. I hope it will help in clarifying the current discussion. I will consider the following schemes: * The "prepend key and length" scheme, PKL(msg) = Hash(key,length,msg) * The "envelope" scheme, ENV(msg) = Hash(key,pad,msg,key) * The HMAC scheme, HMAC(msg) = Hash(key,pad1, Hash(key,pad2,msg)) * The NMAC scheme, NMAC(msg) = Hash_key1 (Hash_key2(msg)) (This last scheme is similar to HMAC, with the exceptions that it uses two keys instead of one, and puts the keys in the IV of the hash function instead of in the first part of the input.) I) No feasible attack is currently known against any of these schemes. If this is satisfactory then any of the above schemes will do. However, one may want to have a better assurance than that for a standard. Thus, attempts have been made to gain further assurance in the security of schemes by proving statements of the sort: "If the underlying hash function enjoys property X then scheme Y is a good MAC". The weaker property X is, the more assurance we have in the security of scheme Y. I am not aware of any other method for gaining assurance in the security of a MAC scheme based on cryptographic hash functions. II) The only claim I know, of the sort described above, regarding PKL and ENV is: "If the compression function of the underlying hash function is pseudorandom then PKL and ENV are good MACs". This was the first statement of this sort that was proven, regarding any scheme; thus at the time ENV and PKL gave the best assurance. However, Pseudorandomness is quite a strong assumption. III) On the more recently proposed NMAC scheme one can show that "If the hash function is collision-free (in a very weak sense) and the compression function is a good MAC on 512-bit messages then NMAC is a good MAC". Here the required properties of the hash function are much weaker than pesudorandomness. In fact, they are quite minimal in the sense that if they are not satisfied by some hash function then it is hard to imagine that this hash function can be used to genrate MACs in any way at all. In particular, this is the best security guarantee known for a hash-based MAC. However, NMAC has the drawbacks that it uses two keys rather than one and that it requires a small change in the code of the hash function (i.e., putting the keys in the IV). Thus HMAC was proposed as a compromise. HMAC uses only one key and requires no change in the code of the hash function. However, an additional "mixing" property of the compression function is assumed. Still, the combined assumptions on the hash function are near-minimal and in particular much weaker than those of (II). In short, out of the schemes that use a single 128-bit key and do not change the code of the underlying hash function, HMAC provides the strongest assurance in its security. I must say that, given that all these schemes are of comparable efficiency, I find it hard to imagine why the forum would want to adopt a scheme that provides weaker assurance than HMAC. Ran Canetti Received: from relay.tis.com by neptune.TIS.COM id aa19250; 3 Mar 96 15:13 EST Received: by relay.tis.com; id PAA04293; Sun, 3 Mar 1996 15:15:51 -0500 From: braden@isi.edu MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma004291; Sun, 3 Mar 96 15:15:22 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA12628; Sun, 3 Mar 96 15:14:17 EST Received: by relay.tis.com; id PAA04288; Sun, 3 Mar 1996 15:15:21 -0500 Received: from venera.isi.edu(128.9.0.32) by relay.tis.com via smap (V3.1) id xma004282; Sun, 3 Mar 96 15:14:59 -0500 Received: from can.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 3 Mar 1996 12:15:48 -0800 Date: Sun, 3 Mar 96 12:16:08 PST Posted-Date: Sun, 3 Mar 96 12:16:08 PST Message-Id: <9603032016.AA18663@can.isi.edu> Received: by can.isi.edu (4.1/4.0.3-4) id ; Sun, 3 Mar 96 12:16:08 PST To: ipsec@TIS.COM, smb@research.att.com Subject: Re: traffic type header Cc: braden@isi.edu, minshall@ipsilon.com Sender: ipsec-request@neptune.tis.com Precedence: bulk *> From smb@research.att.com Mon Feb 26 19:49:50 1996 *> From: smb@research.att.com *> To: ipsec@tis.com *> Subject: traffic type header *> Cc: braden@ISI.EDU, minshall@ipsilon.com *> Date: Mon, 26 Feb 96 22:44:47 EST *> Content-Length: 1551 *> X-Lines: 36 *> *> The suggestion has been made that we should have an optional traffic type header. *> That is, we need something that will disclose protocol and port numbers. The *> purpose would be (a) to permit traffic measurements, and (b) to permit routers *> to optimize their handling of certain kinds of traffic. and (c) support integrated services, in particular RSVP. Bob Braden Received: from relay.tis.com by neptune.TIS.COM id aa19919; 3 Mar 96 16:00 EST Received: by relay.tis.com; id QAA04480; Sun, 3 Mar 1996 16:02:51 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma004478; Sun, 3 Mar 96 16:02:24 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13149; Sun, 3 Mar 96 16:01:18 EST Received: by relay.tis.com; id QAA04471; Sun, 3 Mar 1996 16:02:22 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma004462; Sun, 3 Mar 96 16:01:57 -0500 Received: from ktik0 (ktik0.ethz.ch) by interlock.ans.net with SMTP id AA20640 (InterLock SMTP Gateway 3.0 for ); Sun, 3 Mar 1996 16:02:57 -0500 Received: from komsys-pc-gc.ethz.ch (laptop30.ietf.interop.net [130.128.2.30]) by ktik0 (8.6.8.1/8.6.6) with SMTP id WAA19442 for ; Sun, 3 Mar 1996 22:02:49 +0100 Message-Id: <2.2.32.19960303211235.006a55ac@ktik0.ethz.ch> X-Sender: caronni@ktik0.ethz.ch (Unverified) X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 03 Mar 1996 22:12:35 +0100 To: ipsec@ans.net From: Germano Caronni Subject: Re: An observation or two Sender: ipsec-request@neptune.tis.com Precedence: bulk At 13:15 7.1.96 -0800, you wrote: >I will offer just a technical observation or two speaking only for myself. > >ANY hybrid Diffie-Hellman scheme can provide Perfect Forward Secrecy. >Your mention of one-time pads was entirely extraneous. Moreover, there >is a lot of experience with deployed systems indicating the Hybrid >Diffie-Hellman is not too expensive computationally or otherwise impractical. By now I have recovered Diffies paper, and done some more hunting for literature. But sincerly I found no **definition** of the term 'perfect forward secrecy', anywhere. Do you have a reference at hand, which introduces this term? Otherwise I feel like defining it myself. And the expression 'perfect' is a very dangerous one ;-) which really leads to OTPs. Certainly I agree with you, hybrid DH _is_ practical. It's just not a perfect solution. >Second, as near as I can tell, none of the current drafts meet _all_ of the >WG requirements. Hence, your misunderstanding that this is about SKIP >(hint: the questions are NOT specific to SKIP) is not well founded. Well, one learns ;-) I sometimes have the impression that the non-progression of the different standards is not wholedly based due to technical reasons. From an idealistic point of view (let's call it Secure Internet) I want IPSEC to move on. I do not care if it moves into the Photuris direction, Oakley, SKIP, or all of them at the same time, as long has we finally get some progress. Compared to the initial WG schedule IPSEC is about one year (or more?) late... Then naturally I have some personal preferences, but I believe I need not elaborate on those ;->> -- and they are not exactly relevant in the standardisation process. I definitvely have a problem with the working group requirements. They - let me exagerate - do NOT exist. What we have is a collage of emails and proceedings, which contain partially colliding requirements. Also this inexistant list has mutated more than once or twice. I fear most people that 'know' the WG requirements and talk about them on the mailing list, have views of their own as to what these requirements are. I would really enjoy seeing a list, perhaps even stating which draft satisfies which requirements. Naturally this is no easy task, and as I am not even able to bring out a little transorm (sigh) draft in time, I will not volunteer to do this. Well, sorry for this rather longish mail, perhaps I will now sleep better. Talk to you soon, Germano Received: from relay.tis.com by neptune.TIS.COM id aa22047; 3 Mar 96 18:43 EST Received: by relay.tis.com; id SAA05556; Sun, 3 Mar 1996 18:45:34 -0500 From: Bart.Preneel@esat.kuleuven.ac.be MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma005554; Sun, 3 Mar 96 18:45:14 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA15090; Sun, 3 Mar 96 18:44:00 EST Received: by relay.tis.com; id SAA05551; Sun, 3 Mar 1996 18:45:04 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma005546; Sun, 3 Mar 96 18:45:00 -0500 Received: from mailserv.esat.kuleuven.ac.be by interlock.ans.net with SMTP id AA22209 (InterLock SMTP Gateway 3.0 for ); Sun, 3 Mar 1996 18:45:58 -0500 Received: from yourcenar.esat.kuleuven.ac.be by mailserv (5.67b8/IDA/v1.5) id AA13359; Mon, 4 Mar 1996 00:43:41 +0100 Organization: ESAT, K.U.Leuven, Belgium Received: by yourcenar.esat.kuleuven.ac.be (5.65/ESAT-v1.2) id AA07467; Mon, 4 Mar 1996 00:43:27 +0100 Date: Mon, 4 Mar 1996 00:43:27 +0100 Message-Id: <9603032343.AA07467@yourcenar.esat.kuleuven.ac.be> To: ipsec@ans.net Subject: MACs based on hash X-Charset: ISO_8859-1 X-Char-Esc: 29 Sender: ipsec-request@neptune.tis.com Precedence: bulk Some comments on the proposals for MAC constructions: > * The "prepend key and length" scheme, PKL(msg) = Hash(key,length,msg) > * The "envelope" scheme, ENV(msg) = Hash(key,pad,msg,key) > * The HMAC scheme, HMAC(msg) = Hash(key,pad1, Hash(key,pad2,msg)) > * The NMAC scheme, NMAC(msg) = Hash_key1 (Hash_key2(msg)) For the first two of these schemes, we know that there is a reduction to the pseudo-randomness of the underlying compression function (PKL ENV); For the NMAC: "we know that if the hash function is collision-free (for a secret IV) and the compression function is a good MAC on 512-bit messages then NMAC is a good MAC". For HMAC, we need an additional mixing property of the compression function. You forgot to mention MDx-MAC (see the Crypto'95 paper of Paul van Oorschot and myself), for which there exist a security proof based on the pseudo-randomness of the underlying compression function which is keyed in both the IV and the message input. All these reductions are very nice from a theoretical standpoint (really a good piece of work). However, as a practical cryptanalyst, I have the following remarks: 1. very little cryptanalysis has been done on MD4 and MD5; nevertheless, some quite good results have been obtained already (from the cryptanalyst's point of view). 2. no work at all has been done on properties of MD5 when part of the input is a secret key. 3. it is even not obvious at all where to put this key: which part of the input is the "natural" place to put it? (in my humble opinion, it should be put in every part of the input, but this is based on my intuition). 4. for all of these there exists a forgery attack which is unrealistic if the underlying function (with the same parameters) is really strong; for the first two schemes, this (unrealistic) attack allows for key recovery rather than forgery. However, no one has yet analyzed how much this can be improved if MD5 is used as underlying function. In view of all of this, for all of you who want to use any of these constructions based on MD5, I recommend to be very careful and take the most conservative one you can afford. I wonder how many of you would be prepared to use any of these schemes if the US government had proposed them... (sorry, couldn't resist). The good news is that you can make many mistakes, since there are only very few cryptanalysts, and their time is very scarce (there are many algorithms). That means it can take many years before they find the time to try to break any of these schemes. It's up to you to decide whether you can ignore their warnings. Good luck. Bart Preneel PS Below some more details (for those of you who want to know): --------------------------------------------------------------------------- 1. Up till now very little cryptanalysis has been performed on MD4 and MD5 (compared to for example the amount of work on DES). I believe the total effort is less than 1 personyear. MD4 was badly broken (research effort of about 5 manmonths; collisions in 1 second on a PC), and it can be anticipated based on this that collisions will be found for MD5 in the next 12 to 24 months. The main issue is just to find a few competent people who want to spend a sufficient amount of time. 2. Up till now NO work has been done on the evaluation of the compression function of MD5 as a pseudo-random function. Some people claim that the fact that the compression function of MD5 is a MAC or a pseudorandom function is a design criterion for MD5. In my opinion it is at best a by-product of the design, and a by-product which _never_ has been checked for. The reason for this is that usually MD5 is not used with secret input, but only with known/chosen inputs. The only property which has been evaluated and which approximates this is preimage resistance: if you are given the complete output, find a preimage. What is required for a MAC are properties of the compression function for which _part_ of the input is fixed and secret; one then is allowed to look at many outputs for chosen values of the remaining inputs. As far as I know, there is only one class of concrete primitives which have been checked for such a property, namely ...block ciphers. (unfortunately they are slower and cannot be exported). The properties required are totally different from collision resistance or one-wayness: for example, the existence of probabilistic linear relations between part of the input (where you have put the key) and the output could lead to linear cryptanalysis of MD5; such an attack would not change anything to the security of the hash function as a collision resistant or (second) preimage resistant function. 3. it is even not obvious at all where to put this key: which part of the input is the "natural" place to put it? If one uses MD5 as a MAC or as a pseudorandom function, you have to insert the key somewhere. In my humble opinion, there is no obvious place to do this; if you look at MD5 as a block cipher, the message input would be the key, and the IV would be the plaintext. NMAC enters the key in the IV, and the [BCK] paper contains the following claim: "As it turns out, the latter approach has some significant analytical advantages". Moreover, if you one would design a hash function according to the Merkle-Damgaard principle, i.e., derive the collision resistance of the hash function from that of the compression function (such as Snefru of Merkle), there would be no distinction between the IV and the message input. So it is quite confusing to me that putting the key in the IV input can have analytical advantages. The fact that there is no obvious place to put the key, is the reason why in MDx-MAC the key is put both in the IV and in the message input. The idea behind this is that since the compression function is not designed to hide any of its inputs in the way which a pseudo-random function should, the key should be involved in _every_ input. I agree that this is not a security proof, but in my opinion it is a sound design principle. 4. for all of these schemes there exists a forgery attack which is unrealistic if the underlying function (with the same parameters) is really strong; for the first two schemes, this (unrealistic) attack allows for key recovery rather than forgery. However, no one has yet analyzed how much this can be improved if MD5 is used as underlying function. Since the time of cryptanalysts is scarce, and our knowledge of cryptographic algorithms is limited, we often have to rely on certificational weaknesses. For example MD5 has as certificational weakness that its compression function is not collision resistant, and the construction of RFC 1828 has as certificational weakness that an unrealistic forgery attack can be extended to an unrealistic key recovery attack. For me as a cryptographer this would be sufficient to never use RFC1828 based on MD5. And the fact that the attack for any compression function takes $2^{66}$ chosen texts does not mean that this could not be improved for MD5.. ---------------------------------------------------------------------------- Received: from relay.tis.com by neptune.TIS.COM id aa25115; 3 Mar 96 23:29 EST Received: by relay.tis.com; id XAA06710; Sun, 3 Mar 1996 23:31:34 -0500 From: hugo@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma006706; Sun, 3 Mar 96 23:31:06 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18355; Sun, 3 Mar 96 23:30:00 EST Received: by relay.tis.com; id XAA06703; Sun, 3 Mar 1996 23:31:04 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma006701; Sun, 3 Mar 96 23:30:37 -0500 Received: from watson.ibm.com by interlock.ans.net with SMTP id AA25705 (InterLock SMTP Gateway 3.0 for ); Sun, 3 Mar 1996 23:31:38 -0500 Message-Id: <199603040431.AA25705@interlock.ans.net> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 3023; Sun, 03 Mar 96 23:31:14 EST Date: Sun, 3 Mar 96 23:31:14 EST To: Bart.Preneel@esat.kuleuven.ac.be, ipsec@ans.net Subject: MACs based on hash Sender: ipsec-request@neptune.tis.com Precedence: bulk Ref: Your note of Mon, 4 Mar 1996 00:43:27 +0100 (attached) Bart Preneel writes: > In view of all of this, for all of you who want to use any of these > constructions based on MD5, I recommend to be very careful and take the > most conservative one you can afford. Agreed. Given that this group has decided to go with an MD5-based MAC, we got to be careful and cautious. This is the exact reason why we came up with HMAC and propose it as a default MAC for AH: it is (among all studied candidates) the one scheme to require the least assumptions on MD5 in order for the resultant MAC to be secure (yet it requires no performance degradation or changes to MD5). Hugo Received: from relay.tis.com by neptune.TIS.COM id aa27581; 4 Mar 96 2:53 EST Received: by relay.tis.com; id CAA07845; Mon, 4 Mar 1996 02:54:49 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma007843; Mon, 4 Mar 96 02:54:24 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20878; Mon, 4 Mar 96 02:53:15 EST Received: by relay.tis.com; id CAA07839; Mon, 4 Mar 1996 02:54:19 -0500 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1) id xma007836; Mon, 4 Mar 96 02:54:18 -0500 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id XAA03920 for ipsec@tis.com; Sun, 3 Mar 1996 23:55:17 -0800 Date: Sun, 3 Mar 1996 23:55:17 -0800 From: Ran Atkinson Message-Id: <199603040755.XAA03920@puli.cisco.com> To: ipsec@TIS.COM Subject: IPsec transforms Sender: ipsec-request@neptune.tis.com Precedence: bulk [personal opinion] I think the WG should seriously consider moving both RFC-1828 and RFC-1829 to Historic. Hugo's HMAC transform should be seriously considered to be moved to Proposed Standard and replace RFC-1828 as the mandatory-to-implement AH transform. Similarly, Jim Hughes' DES+MD5+replay-protection ESP transform should be reviewed/edited and then seriously considered to be moved to Proposed Standard and replace RFC-1829 as the mandatory-to-implement ESP transform. [WG chair speaking] This is precisely the correct time to consider these kinds of significant technical changes to the IPsec transforms. Because RFC-1825 thru RFC-1827 are not yet ready to be considered for advancement to Draft Standard, RFC-1828 and RFC-1829 cannot yet be considered for advancement to Draft Standard in any event. Any appeals of this decision should be made directly to the Security AD and should NOT clutter this list further. In general, if one believes the chair(s) have made a meaningful incorrect process decision the correct procedure is to appeal to the Security AD. The Security AD is empowered to overrule the chair(s) of the WG. Ran rja@cisco.com Received: from relay.tis.com by neptune.TIS.COM id aa04261; 5 Mar 96 17:02 EST Received: by relay.tis.com; id RAA12288; Tue, 5 Mar 1996 17:04:32 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma012273; Tue, 5 Mar 96 17:04:02 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08143; Tue, 5 Mar 96 17:02:56 EST Received: by relay.tis.com; id RAA12264; Tue, 5 Mar 1996 17:04:00 -0500 Received: from stilton.cisco.com(171.69.1.161) by relay.tis.com via smap (V3.1) id xma012256; Tue, 5 Mar 96 17:03:40 -0500 Received: from cisco.com (localhost.cisco.com [127.0.0.1]) by stilton.cisco.com (8.6.8+c/8.6.5) with ESMTP id OAA12594 for ; Tue, 5 Mar 1996 14:04:41 -0800 Message-Id: <199603052204.OAA12594@stilton.cisco.com> To: ipsec@TIS.COM Subject: cisco ISAKMP/OAKLEY implementation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <12588.826063480.1@cisco.com> Date: Tue, 05 Mar 1996 14:04:40 -0800 From: David Carrel Sender: ipsec-request@neptune.tis.com Precedence: bulk This is just a recap of what I said at the IPSEC mtg Monday night for those that weren't there or those who missed the URLs. cisco is making available a reference implementation of ISAKMP with OAKLEY extensions. We plan to make this available mid April or earlier. The implementation works with the NRL PF Key socket and runs on BSD 4.4 platforms such as BSDi, NetBSD and FreeBSD. It should port to other OSes easily as it runs entirely in user space. We plan to do interoperability testing over the net between our implementation, the NSA implementation (to be available soon from MIT, I'm told) and the implementation from the Brittish Defense Research Agency. Others are welcome and encouraged to join in. The implementation is free in source code form and we have purchased licensing that allows it to be copied and used in commercial or non-commercial products without royalties. The intent is to move things in the IPSEC forward by making code available and as unrestricted as possible. The exact license will be online shortly after I get back to San Jose on our anonymous ftp site. The README file in: ftp://ftp.cisco.com/isakmp-oakley/README will have the exact location of the license and other files including instructions for downloading the code. A mailing list has been set up for discussions and announcements relatng to our implementation. The list is isakmp-oakley@cisco.com and you can add yourself by sending email to majordomo@cisco.com with the line subscribe isakmp-oakley in the body of the message. The mailing list is being archived in the same anonymous ftp directory. Of course, access to our code is limited to sites in the US and Canada. Dave ---------------------------------------------------------------------------- David Carrel | E-mail: carrel@cisco.com Security Development, cisco Systems | phone: (408) 526-5207 170 W. Tasman Drive | fax: (408) 526-4952 San Jose, CA 95134-1706 | ---------------------------------------------------------------------------- Received: from relay.tis.com by neptune.TIS.COM id aa05229; 5 Mar 96 17:57 EST Received: by relay.tis.com; id RAA13669; Tue, 5 Mar 1996 17:59:28 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma013666; Tue, 5 Mar 96 17:58:59 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10328; Tue, 5 Mar 96 17:57:54 EST Received: by relay.tis.com; id RAA13661; Tue, 5 Mar 1996 17:58:58 -0500 Received: from uucp5.netcom.com(163.179.3.5) by relay.tis.com via smap (V3.1) id xma013657; Tue, 5 Mar 96 17:58:29 -0500 Received: by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id OAA02428; Tue, 5 Mar 1996 14:36:04 -0800 Received: from cc:Mail by spysouth.spyrus.com id AA826064531 Tue, 05 Mar 96 14:22:11 Date: Tue, 05 Mar 96 14:22:11 From: "Housley, Russ" Encoding: 2048 Text Message-Id: <9602058260.AA826064531@spysouth.spyrus.com> To: perry@piermont.com, hugo@watson.ibm.com Cc: ipsec@TIS.COM Subject: Re: Call for AH-MD5 and ESP-DES to move forward Sender: ipsec-request@neptune.tis.com Precedence: bulk Perry: I agree with Hugo. Replace is the correct action. Russ ______________________________ Reply Separator _________________________________ Subject: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward Author: hugo@watson.ibm.com at internet Date: 2/29/96 4:22 PM Ref: Your note of Thu, 29 Feb 1996 16:09:19 -0500 (attached) Perry, > > I have no problem with the idea of ultimately advancing the HMAC > transform to standard, especially after it has been out for a good > while and there has been additional opportunity for cryptographers to > attack it, but I disagree with the words "replace". As Paul's survey > reveals, many implementations currently implement 1828. Let us instead > speak of requiring this new superior transform rather than of > "replacing" the old one, which would imply, for example, that > identifiers for 1828 in key management protocols would have to point > at HMAC instead, which would result in interoperability problems. What I want is that implementations *do* move to this new function. We are doing a lot of implementation work regarding IPSEC, and we talk to many other implementation people involved with IPSEC. The message is very clear: no one has any real problem to implement the new transform, however they will not do that as long as there is another one that is *officially* required by the IPSEC standard. We need to find a way to break this loop. I don't care about the word "replace" just about making clear that IPSEC-AH REQUIRES HMAC (as the default implementation). As a general note: if we can't modify the standards during the standarization process why do we have that process in place. Implementors need to know (and we know!) that changes will occur. This particular one is easy to implement and upgrade. If the decision is that it is too late to change the default algorithm I would recommend this group to be even more careful on any decision about moving any document to standards track. Hugo Received: from relay.tis.com by neptune.TIS.COM id aa01165; 7 Mar 96 2:48 EST Received: by relay.tis.com; id CAA06772; Thu, 7 Mar 1996 02:49:36 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma006768; Thu, 7 Mar 96 02:49:08 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13649; Thu, 7 Mar 96 02:48:03 EST Received: by relay.tis.com; id CAA06762; Thu, 7 Mar 1996 02:49:06 -0500 Received: from copilot.is.chrysler.com(204.189.94.148) by relay.tis.com via smap (V3.1) id xma006758; Thu, 7 Mar 96 02:49:02 -0500 Received: by pilotx.firewall.is.chrysler.com; id DAA27715; Thu, 7 Mar 1996 03:17:15 -0500 Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilotx.is.chrysler.com via smap (g3.0.1) id sma027703; Thu, 7 Mar 96 03:16:50 -0500 Received: from rgm3 ([172.16.8.15]) by clhubgw1.is.chrysler.com (5.x/SMI-4.1) id AA07099; Thu, 7 Mar 1996 02:51:28 -0500 Message-Id: <2.2.32.19960307074720.00346d94@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 07 Mar 1996 02:47:20 -0500 To: Tatu Ylonen , perry@piermont.com From: Robert Moskowitz Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward Cc: hugo@watson.ibm.com, ipsec@TIS.COM Sender: ipsec-request@neptune.tis.com Precedence: bulk At 10:41 PM 3/1/96 +0200, Tatu Ylonen wrote: > >But, in my understanding IPSEC does not "exist" yet in the same sense >as SMTP did. It does not yet have a wide user base, just a few small >groups using various implementations. I think it is probably early >enough to simply change the spec if it is otherwise justified. >(It may not be a bad idea to change the protocol number though if >confusion is likely.) I should point out that TELNET went through a similar problem; right now I forget the option, envirnoment, I think. They did it wrong, big time, and there were already implementations, and Borman had to carefully architect the movement to the 'right' way. You have it much easier. with a new transform # and a clear statement that HMAC is the required transform with the old one perhaps 'historical' Let's do a last call on HMAC, please. As a consumer I expect you all to do this. Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.tis.com by neptune.TIS.COM id aa01164; 7 Mar 96 2:48 EST Received: by relay.tis.com; id CAA06773; Thu, 7 Mar 1996 02:49:36 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma006769; Thu, 7 Mar 96 02:49:08 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13650; Thu, 7 Mar 96 02:48:03 EST Received: by relay.tis.com; id CAA06763; Thu, 7 Mar 1996 02:49:06 -0500 Received: from copilot.is.chrysler.com(204.189.94.148) by relay.tis.com via smap (V3.1) id xma006759; Thu, 7 Mar 96 02:49:03 -0500 Received: by pilotx.firewall.is.chrysler.com; id DAA27728; Thu, 7 Mar 1996 03:17:16 -0500 Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilotx.is.chrysler.com via smap (g3.0.1) id sma027705; Thu, 7 Mar 96 03:16:52 -0500 Received: from [172.16.8.15] by clhubgw1.is.chrysler.com (5.x/SMI-4.1) id AB07099; Thu, 7 Mar 1996 02:51:32 -0500 Message-Id: <2.2.32.19960307074723.00346d94@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 07 Mar 1996 02:47:23 -0500 To: Ran Atkinson , ipsec@TIS.COM From: Robert Moskowitz Subject: Re: IPsec transforms Sender: ipsec-request@neptune.tis.com Precedence: bulk At 11:55 PM 3/3/96 -0800, Ran Atkinson wrote: > >[personal opinion] > > I think the WG should seriously consider moving both RFC-1828 and >RFC-1829 to Historic. Hugo's HMAC transform should be seriously >considered to be moved to Proposed Standard and replace RFC-1828 >as the mandatory-to-implement AH transform. Similarly, Jim Hughes' >DES+MD5+replay-protection ESP transform should be reviewed/edited >and then seriously considered to be moved to Proposed Standard >and replace RFC-1829 as the mandatory-to-implement ESP transform. I agree, personally. With my IAB hat on, this is the process we should follow. Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.tis.com by neptune.TIS.COM id aa09263; 7 Mar 96 11:36 EST Received: by relay.tis.com; id LAA13762; Thu, 7 Mar 1996 11:38:17 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma013760; Thu, 7 Mar 96 11:37:49 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01834; Thu, 7 Mar 96 11:36:44 EST Received: by relay.tis.com; id LAA13755; Thu, 7 Mar 1996 11:37:47 -0500 Received: from rsa.com(192.80.211.33) by relay.tis.com via smap (V3.1) id xma013751; Thu, 7 Mar 96 11:37:37 -0500 Received: from snail.rsa.com by RSA.COM with SMTP id AA02291; Thu, 7 Mar 96 08:29:45 PST Received: from cc:Mail by snail.rsa.com id AA826216778; Thu, 07 Mar 96 08:39:25 PST Date: Thu, 07 Mar 96 08:39:25 PST From: baldwin Message-Id: <9602078262.AA826216778@snail.rsa.com> To: ipsec@TIS.COM Subject: AH vs. ESP with MD5 Sender: ipsec-request@neptune.tis.com Precedence: bulk I have a couple questions about the goals for the revised ESP that includes integrity and replay protection. 1) Is the new ESP suppose to eliminate the need for the AH transform? - If so, the current draft does not provide any integrity checks on the IP header, so an attacker can modify those fields in transit. Maybe that is not considered to be a threat. - If not, then a secuure implementation that includes both AH and ESP will have to perform two MD5 digests on the payload. That is a 33% performance hit for large packets [with the original AH-ESP, the payload is scanned once for the AH digest and once for the DES-CBC, the new ESP-DES-CBC-MD5 requires an additional scan of MD5 on the plaintext payload]. 2) Do ESP packets need to be self describing in terms of the features they support (e.g., whether replay protection is included)? The current design assumes that the SPI determines all the required features. --Bob Received: from relay.tis.com by neptune.TIS.COM id aa10704; 7 Mar 96 13:05 EST Received: by relay.tis.com; id NAA14740; Thu, 7 Mar 1996 13:07:17 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma014732; Thu, 7 Mar 96 13:06:48 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA05967; Thu, 7 Mar 96 13:05:43 EST Received: by relay.tis.com; id NAA14729; Thu, 7 Mar 1996 13:06:47 -0500 Received: from unknown(128.127.2.122) by relay.tis.com via smap (V3.1) id xma014727; Thu, 7 Mar 96 13:06:37 -0500 Received: from ftp.com by ftp.com ; Thu, 7 Mar 1996 13:07:36 -0500 Received: from mailserv-H.ftp.com by ftp.com ; Thu, 7 Mar 1996 13:07:36 -0500 Received: from naganand-1.ftp.com (laptop206.ietf.interop.net) by MAILSERV-H.FTP.COM (5.x/SMI-SVR4) id AA11318; Thu, 7 Mar 1996 13:07:56 -0500 Date: Thu, 7 Mar 1996 13:07:56 -0500 Message-Id: <9603071807.AA11318@MAILSERV-H.FTP.COM> X-Sender: naganand@mailserv-H.ftp.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: baldwin From: Naganand Doraswamy Subject: Re: AH vs. ESP with MD5 Cc: ipsec@TIS.COM X-Mailer: Sender: ipsec-request@neptune.tis.com Precedence: bulk >1) Is the new ESP suppose to eliminate the need for the AH transform? > - If so, the current draft does not provide any integrity checks > on the IP header, so an attacker can modify those fields in > transit. Maybe that is not considered to be a threat. > - If not, then a secuure implementation that includes both AH > and ESP will have to perform two MD5 digests on the payload. > That is a 33% performance hit for large packets [with the > original AH-ESP, the payload is scanned once for the AH digest > and once for the DES-CBC, the new ESP-DES-CBC-MD5 requires > an additional scan of MD5 on the plaintext payload]. > The new ESP transform does not eliminate AH. AH is still useful in cases where you dont need to encrypt the data. Also, you may have may only perfrom AH and not ESP for export. >2) Do ESP packets need to be self describing in terms of the features > they support (e.g., whether replay protection is included)? > The current design assumes that the SPI determines all the > required features. > >From what I understand talking to the editors, it is still not decided whether replay protection is mandatory or optional. There should be some discussion on this in the mailing list. Regards, --Naganand Received: from relay.tis.com by neptune.TIS.COM id aa10986; 7 Mar 96 13:24 EST Received: by relay.tis.com; id NAA14908; Thu, 7 Mar 1996 13:26:47 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma014903; Thu, 7 Mar 96 13:26:18 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06483; Thu, 7 Mar 96 13:25:13 EST Received: by relay.tis.com; id NAA14900; Thu, 7 Mar 1996 13:26:17 -0500 Received: from unknown(137.175.2.11) by relay.tis.com via smap (V3.1) id xma014898; Thu, 7 Mar 96 13:26:02 -0500 Received: from gefilte.MorningStar.Com by volitans.MorningStar.Com (8.7.1/95070701) id SAA24199; Thu, 7 Mar 1996 18:27:02 GMT From: Karl Fox Received: by gefilte.MorningStar.Com (5.65a/94012401) id AA04683; Thu, 7 Mar 96 13:27:02 -0500 Date: Thu, 7 Mar 96 13:27:02 -0500 Message-Id: <9603071827.AA04683@gefilte.MorningStar.Com> To: ipsec@TIS.COM Subject: Alternative transform encapsulation scheme Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Sender: ipsec-request@neptune.tis.com Precedence: bulk Now that we're heading toward individual do-everything transforms rather than layered orthogonal functions, the concept of separate AH and ESP protocols seems a bit awkward. Consider a different protocol, perhaps called `Security Transform', that might look like this: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transform ID | Length | Next Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Optional Transform Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Transforms could be layered if desired. The length field would make it easy to parse even if you didn't understand a particular transform type. All of our code would become simpler, and the RSVP folks would love this more uniform format. The Next Header field would be slightly problematic; encrypting transforms would want to obscure it somehow (perhaps destroying it after storing a copy down in the opaque area) while not obscuring portions of the Optional Transform Data field such as initialization vectors. I know it's pretty late in the game to begin talking about something like this, but it only recently became appropriate because of the recent change in attitudes toward combined transforms. -- Karl Fox, servant of God, employee of Morning Star Technologies 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 451 1883 Received: from relay.tis.com by neptune.TIS.COM id aa11758; 7 Mar 96 14:03 EST Received: by relay.tis.com; id OAA15538; Thu, 7 Mar 1996 14:05:47 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma015522; Thu, 7 Mar 96 14:05:20 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08653; Thu, 7 Mar 96 14:04:15 EST Received: by relay.tis.com; id OAA15515; Thu, 7 Mar 1996 14:05:17 -0500 Received: from unknown(206.1.51.15) by relay.tis.com via smap (V3.1) id xma015509; Thu, 7 Mar 96 14:05:10 -0500 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) with SMTP id OAA11949; Thu, 7 Mar 1996 14:06:00 -0500 (EST) Message-Id: <199603071906.OAA11949@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: baldwin Cc: ipsec@TIS.COM Subject: Re: AH vs. ESP with MD5 In-Reply-To: Your message of "Thu, 07 Mar 1996 08:39:25 PST." <9602078262.AA826216778@snail.rsa.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Thu, 07 Mar 1996 14:05:55 -0500 From: "Perry E. Metzger" Sender: ipsec-request@neptune.tis.com Precedence: bulk baldwin writes: > I have a couple questions about the goals for the revised ESP > that includes integrity and replay protection. > > 1) Is the new ESP suppose to eliminate the need for the AH transform? No, not at all. It was intended all the way back to the origins of the current proposal that ESP would be able to contain arbitrary opaque transforms. > 2) Do ESP packets need to be self describing in terms of the features > they support (e.g., whether replay protection is included)? > The current design assumes that the SPI determines all the > required features. You answered your own question -- the ESP packets are totally opaque, and no information other than the SPI is needed. Perry Received: from relay.tis.com by neptune.TIS.COM id aa12728; 7 Mar 96 14:50 EST Received: by relay.tis.com; id OAA16511; Thu, 7 Mar 1996 14:52:17 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma016506; Thu, 7 Mar 96 14:51:49 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA12167; Thu, 7 Mar 96 14:50:44 EST Received: by relay.tis.com; id OAA16500; Thu, 7 Mar 1996 14:51:47 -0500 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1) id xma016492; Thu, 7 Mar 96 14:51:30 -0500 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) with SMTP id OAA12006; Thu, 7 Mar 1996 14:52:31 -0500 (EST) Message-Id: <199603071952.OAA12006@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Karl Fox Cc: ipsec@TIS.COM Subject: Re: Alternative transform encapsulation scheme In-Reply-To: Your message of "Thu, 07 Mar 1996 13:27:02 EST." <9603071827.AA04683@gefilte.MorningStar.Com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Thu, 07 Mar 1996 14:52:31 -0500 From: "Perry E. Metzger" Sender: ipsec-request@neptune.tis.com Precedence: bulk Karl Fox writes: > Now that we're heading toward individual do-everything transforms > rather than layered orthogonal functions, the concept of separate AH > and ESP protocols seems a bit awkward. ESP is not the "encrypting protocol". It is the OPAQUE protocol. The idea always was that AH was there to provide for non-opaque encapsulated packets in which it was possible to determine what the contents were without understanding the SPI, and ESP was always intended to provide for any combination of (encryption/authentication/replay/etc) that did not need to be transparent. Perry Received: from relay.tis.com by neptune.TIS.COM id aa13929; 7 Mar 96 15:52 EST Received: by relay.tis.com; id PAA17686; Thu, 7 Mar 1996 15:54:47 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma017671; Thu, 7 Mar 96 15:54:21 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16075; Thu, 7 Mar 96 15:53:15 EST Received: by relay.tis.com; id PAA17664; Thu, 7 Mar 1996 15:54:18 -0500 Received: from unknown(192.86.155.81) by relay.tis.com via smap (V3.1) id xma017655; Thu, 7 Mar 96 15:54:08 -0500 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id MAA03590; Thu, 7 Mar 1996 12:55:06 -0800 Received: by mailsun2.us.oracle.com (8.7.1/37.8) id MAA27585; Thu, 7 Mar 1996 12:57:22 -0800 (PST) Message-Id: <199603072057.MAA27585@mailsun2.us.oracle.com> Date: 07 Mar 96 11:42:23 -0800 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: Re: AH vs. ESP with MD5 X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-request@neptune.tis.com's message of 07-Mar-96 08:39 Mime-Version: 1.0 Sender: ipsec-request@neptune.tis.com Precedence: bulk >From: baldwin >1) Is the new ESP suppose to eliminate the need for the AH transform? No. Requirements were identified for an authentication only protocol, especially in the IPv6 environment. These requirements could be reexamined, but are a separate issue from combining confidentiality and integrity in a single ESP transform. > - If so, the current draft does not provide any integrity checks > on the IP header, so an attacker can modify those fields in > transit. Maybe that is not considered to be a threat. First no not so, we are not eliminating AH. Integrity checks can be provided if required on the IP header using AH. > - If not, then a secure implementation that includes both AH > and ESP will have to perform two MD5 digests on the payload. > That is a 33% performance hit for large packets [with the > original AH-ESP, the payload is scanned once for the AH digest > and once for the DES-CBC, the new ESP-DES-CBC-MD5 requires > an additional scan of MD5 on the plaintext payload]. True, an end-system would be foolish to request unnecessary extra encapsulations. The situation you describe could occur in various tunneling scenarios that should be supported. For example using ESP end-to-end and AH between firewalls that are carrying the end-to-end ESP. >2) Do ESP packets need to be self describing in terms of the features > they support (e.g., whether replay protection is included)? No, this has not been the design paradigm for ESP. It is much more efficient for processing and bits on the wire to have implicit definitions. > The current design assumes that the SPI determines all the > required features. Yes. Paul -------------------------------------------------------------- Received: from relay.tis.com by neptune.TIS.COM id aa08331; 9 Mar 96 11:52 EST Received: by relay.tis.com; id LAA00899; Sat, 9 Mar 1996 11:54:27 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma000889; Sat, 9 Mar 96 11:54:16 -0500 Received: from by tis.com (4.1/SUN-5.64) id AC01693; Sat, 9 Mar 96 11:53:13 EST Received: by relay; id FAA02316; Sat, 9 Mar 1996 05:40:17 -0500 Received: from unknown(205.179.16.1) by relay.tis.com via smap (V3.1) id xma002300; Sat, 9 Mar 96 05:39:42 -0500 Received: (from thuy@localhost) by main.geminisecure.com (8.6.9/8.6.9) id OAA05598; Thu, 7 Mar 1996 14:51:34 -0800 Date: Thu, 7 Mar 1996 14:51:33 -0800 (PST) From: Thuy Nguyen To: PALAMBER@us.oracle.com, ipsec@TIS.COM Cc: swan-dev@rsa.com, "Dr. Tao" Subject: Re: IPSEC Implementation Survey Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipsec-request@neptune.tis.com Precedence: bulk Name of Implementation: Gemini Trusted Security Firewall-Guard (GTFW-GD) Security Protocols: 1. IPSec (ESP,AH): Public-Private 2. IPCSO & IPSec: Private-Private (IP Crypto-Seal Option) (Integrity, Authentication, Confidentiality) Security Transforms: DES, Key MD5, Trusted Crypto-Seals Key Management: 1. Manual for Trusted Public-Private Internetwork 2. A1 Trusted Distribution Key Management Extended for Trusted Private-Private Internetwork 3. Customized Lineage of Code: 1. Trusted Software 2. Platform: GTFW-GD on Gemini Trusted Network Processor with Integrated Encryption certified at Class A1 Location of Source Code: Proprietary Point of Contact: Dr. Tien F. Tao, tft@main.geminisecure.com Received: from relay.tis.com by neptune.TIS.COM id aa09498; 9 Mar 96 13:30 EST Received: by relay.tis.com; id NAA01933; Sat, 9 Mar 1996 13:32:54 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma001931; Sat, 9 Mar 96 13:32:25 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02984; Sat, 9 Mar 96 13:31:22 EST Received: by relay.tis.com; id NAA01928; Sat, 9 Mar 1996 13:32:24 -0500 Received: from volitans.morningstar.com(137.175.2.11) by relay.tis.com via smap (V3.1) id xma001926; Sat, 9 Mar 96 13:32:05 -0500 Received: from gefilte.MorningStar.Com by volitans.MorningStar.Com (8.7.1/95070701) id SAA25491; Sat, 9 Mar 1996 18:33:10 GMT From: Karl Fox Received: by gefilte.MorningStar.Com (5.65a/94012401) id AA07448; Sat, 9 Mar 96 13:33:09 -0500 Date: Sat, 9 Mar 96 13:33:09 -0500 Message-Id: <9603091833.AA07448@gefilte.MorningStar.Com> To: perry@piermont.com Cc: ipsec@TIS.COM Subject: Re: Alternative transform encapsulation scheme In-Reply-To: <199603071952.OAA12006@jekyll.piermont.com> References: <9603071827.AA04683@gefilte.MorningStar.Com> <199603071952.OAA12006@jekyll.piermont.com> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Sender: ipsec-request@neptune.tis.com Precedence: bulk Perry E. Metzger writes: > > Karl Fox writes: > > Now that we're heading toward individual do-everything transforms > > rather than layered orthogonal functions, the concept of separate AH > > and ESP protocols seems a bit awkward. > > ESP is not the "encrypting protocol". It is the OPAQUE protocol. My apologies; it's fairly easy to miss that point, since RFC 1827 mentions encryption and decryption 64 times while only mentioning `opaque' twice in a fairly minor way in the syntax section. > The idea always was that AH was there to provide for non-opaque > encapsulated packets in which it was possible to determine what the > contents were without understanding the SPI, and ESP was always > intended to provide for any combination of > (encryption/authentication/replay/etc) that did not need to be > transparent. So will these forthcoming authentication+opacity transforms authenticate the outermost IP header the way AH does? If they don't, won't we have to use AH anyway and thereby authenticate the packet twice? If they do, then it looks like RFC 1827 will have to have some significant changes to allow the transform to operate on the encapsulating IP headers. For example, section 4.1, `ESP in Tunnel-mode' says to discard the outside cleartext headers, and section 4.3, `Authentication', says Some transforms provide authentication as well as confidentiality and integrity. It then goes on to talk exclusively about how to use AH in combination with ESP. -- Karl Fox, servant of God, employee of Morning Star Technologies 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 451 1883 Received: from relay.tis.com by neptune.TIS.COM id aa10431; 9 Mar 96 14:52 EST Received: by relay.tis.com; id OAA02187; Sat, 9 Mar 1996 14:54:24 -0500 From: smb@research.att.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma002185; Sat, 9 Mar 96 14:53:55 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03273; Sat, 9 Mar 96 14:52:52 EST Received: by relay.tis.com; id OAA02182; Sat, 9 Mar 1996 14:53:54 -0500 Message-Id: <199603091953.OAA02182@relay.tis.com> Received: from ns.research.att.com(192.20.225.4) by relay.tis.com via smap (V3.1) id xma002180; Sat, 9 Mar 96 14:53:26 -0500 Received: from research.att.com by ns; Sat Mar 9 14:51:43 EST 1996 Received: from gryphon by research; Sat Mar 9 14:48:37 EST 1996 Received: by gryphon; Sat Mar 9 14:48:32 EST 1996 To: Karl Fox Cc: perry@piermont.com, ipsec@TIS.COM Subject: Re: Alternative transform encapsulation scheme Date: Sat, 09 Mar 96 14:48:32 EST Sender: ipsec-request@neptune.tis.com Precedence: bulk There's a lot that needs to be rethought. I could quite easily be persuaded that we shouldn't, that we should simply decree that ESP must be used only in conjunction with AH -- we've got to get this stuff deployed ASAP. One small change -- the addition of replay protection -- does seem to be needed, though. > So will these forthcoming authentication+opacity transforms > authenticate the outermost IP header the way AH does? If they don't, As David Wagner and I have pointed out before, in most contexts there's little reason to authenticate the outer header. Fields are either (a) constant, in which case there's no reason to authenticate them, (b) too variable, such as the checksum, (c) hop-by-hop (TTL), or (d) bound to the key, in which case why bother. Received: from relay.tis.com by neptune.TIS.COM id aa10796; 9 Mar 96 15:19 EST Received: by relay.tis.com; id PAA02274; Sat, 9 Mar 1996 15:21:54 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma002272; Sat, 9 Mar 96 15:21:25 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03374; Sat, 9 Mar 96 15:20:22 EST Received: by relay.tis.com; id PAA02269; Sat, 9 Mar 1996 15:21:24 -0500 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1) id xma002267; Sat, 9 Mar 96 15:21:11 -0500 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) with SMTP id PAA16596; Sat, 9 Mar 1996 15:22:00 -0500 (EST) Message-Id: <199603092022.PAA16596@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Karl Fox Cc: ipsec@TIS.COM Subject: Re: Alternative transform encapsulation scheme In-Reply-To: Your message of "Sat, 09 Mar 1996 13:33:09 EST." <9603091833.AA07448@gefilte.MorningStar.Com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Sat, 09 Mar 1996 15:21:59 -0500 From: "Perry E. Metzger" Sender: ipsec-request@neptune.tis.com Precedence: bulk Karl Fox writes: > So will these forthcoming authentication+opacity transforms > authenticate the outermost IP header the way AH does? You bring up an interesting question. Perhaps they should. This is a matter for discussion. Perry Received: from relay.tis.com by neptune.TIS.COM id aa21101; 11 Mar 96 17:26 EST Received: by relay.tis.com; id RAA25196; Mon, 11 Mar 1996 17:28:39 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma025192; Mon, 11 Mar 96 17:28:14 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA07828; Mon, 11 Mar 96 17:27:10 EST Received: by relay.tis.com; id RAA25185; Mon, 11 Mar 1996 17:28:09 -0500 Received: from unknown(35.1.1.42) by relay.tis.com via smap (V3.1) id xma025181; Mon, 11 Mar 96 17:28:02 -0500 Received: from Bill.Simpson.DialUp.Mich.Net (pm001-01.dialip.mich.net [35.1.48.50]) by merit.edu (8.7.4/merit-2.0) with SMTP id RAA26655 for ; Mon, 11 Mar 1996 17:29:04 -0500 (EST) Date: Mon, 11 Mar 96 21:42:41 GMT From: William Allen Simpson Message-Id: <5040.wsimpson@greendragon.com> To: ipsec@TIS.COM Subject: Re: Alternative transform encapsulation scheme Sender: ipsec-request@neptune.tis.com Precedence: bulk > From: smb@research.att.com > Date: Sat, 09 Mar 96 14:48:32 EST > > There's a lot that needs to be rethought. I could quite easily be > persuaded that we shouldn't -- we've got to get this stuff > deployed ASAP. I'm with Bellovin on this. I don't think we need a non-orthogonal transform (even though I've written a draft). The deployed AH-MD5 + ESP-DES is adequate. > that we should simply decree that ESP > must be used only in conjunction with AH We already did, when the ESP transform doesn't provide integrity!!! In addition to the numerous references in RFC-1825, -1826, and -1827, RFC-1829 (ESP-DES) clearly states: The usual (ICMP, TCP, UDP) transport checksum can detect this attack, but on its own is not considered cryptographically strong. In this situation, user or connection oriented integrity checking is needed [RFC-1826]. And you promised to write up a more thorough analysis of your attack.... > One small change -- the addition of replay protection -- > does seem to be needed, though. > Why? Doesn't the underlying transport _already_ protect against replay? That is, TCP and ICMP already protect themselves against replay. So, you are recommending that the next version of -1826 provide a replay prevention mechanism? We've discussed this before, but Atkinson was opposed. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 Received: from relay.tis.com by neptune.TIS.COM id aa21100; 11 Mar 96 17:26 EST Received: by relay.tis.com; id RAA25197; Mon, 11 Mar 1996 17:28:39 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma025191; Mon, 11 Mar 96 17:28:14 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA07827; Mon, 11 Mar 96 17:27:10 EST Received: by relay.tis.com; id RAA25186; Mon, 11 Mar 1996 17:28:09 -0500 Received: from unknown(35.1.1.42) by relay.tis.com via smap (V3.1) id xma025182; Mon, 11 Mar 96 17:28:06 -0500 Received: from Bill.Simpson.DialUp.Mich.Net (pm001-01.dialip.mich.net [35.1.48.50]) by merit.edu (8.7.4/merit-2.0) with SMTP id RAA26659 for ; Mon, 11 Mar 1996 17:29:07 -0500 (EST) Date: Mon, 11 Mar 96 22:07:45 GMT From: William Allen Simpson Message-Id: <5041.wsimpson@greendragon.com> To: ipsec@TIS.COM Subject: AH and ESP Orthogonality Sender: ipsec-request@neptune.tis.com Precedence: bulk For the past several years, this WG (and others such as SIP, SIPP, and IPng, and other protocol designers such as SSL) strongly supported orthogonality between the Authentication and Encapsulation (both privacy and compression) facilities. Recently, the WG chairs (without any stimulating WG comments) have tried to move the WG toward a non-orthogonal all-in-one approach for ESP. Last week, Ran Atkinson stood at the microphone, and stated (without elaboration) that his previous support for an orthogonal approach was "a serious mistake". I ask, what was the mistake? WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 Received: from relay.tis.com by neptune.TIS.COM id aa22588; 11 Mar 96 18:24 EST Received: by relay.tis.com; id SAA26059; Mon, 11 Mar 1996 18:26:11 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma026055; Mon, 11 Mar 96 18:25:42 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA09736; Mon, 11 Mar 96 18:24:42 EST Received: by relay.tis.com; id SAA26052; Mon, 11 Mar 1996 18:25:41 -0500 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1) id xma026050; Mon, 11 Mar 96 18:25:38 -0500 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) with SMTP id SAA29953; Mon, 11 Mar 1996 18:26:36 -0500 (EST) Message-Id: <199603112326.SAA29953@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: William Allen Simpson Cc: ipsec@TIS.COM Subject: Re: AH and ESP Orthogonality In-Reply-To: Your message of "Mon, 11 Mar 1996 22:07:45 GMT." <5041.wsimpson@greendragon.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 11 Mar 1996 18:26:35 -0500 From: "Perry E. Metzger" Sender: ipsec-request@neptune.tis.com Precedence: bulk William Allen Simpson writes: > For the past several years, this WG (and others such as SIP, SIPP, and > IPng, and other protocol designers such as SSL) strongly supported > orthogonality between the Authentication and Encapsulation (both privacy > and compression) facilities. > > Recently, the WG chairs (without any stimulating WG comments) have tried > to move the WG toward a non-orthogonal all-in-one approach for ESP. I must admit that I actually somewhat agree with the all-in-one approach. In Toronto, when the current formats were produced, we agreed that we needed separate AH and ESP transforms not because one would handle authentication and the other encryption, but because AH was needed to provide a transparent encapsulation while ESP would provide an opaque encapsulation. The reasons we had for permitting ESP transforms to include any combination of encryption, authentication and integrity checking was partially because this would save a substantial number of bits on the wire for slow links. Our notion initially was that we were cutting the gordion knot of which particular services were to be provided by leaving most of that to the transform documents, permitting transforms that essentially did anything, and simply specifying a method (the SPI) for determining which transform was in use. This is not to say that only all-in-one transforms should exist, but I think there is indeed a place for them some of the time. Perry Received: from relay.tis.com by neptune.TIS.COM id aa23163; 11 Mar 96 18:47 EST Received: by relay.tis.com; id SAA26271; Mon, 11 Mar 1996 18:49:11 -0500 From: smb@research.att.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma026269; Mon, 11 Mar 96 18:48:42 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10180; Mon, 11 Mar 96 18:47:42 EST Received: by relay.tis.com; id SAA26266; Mon, 11 Mar 1996 18:48:41 -0500 Message-Id: <199603112348.SAA26266@relay.tis.com> Received: from ns.research.att.com(192.20.225.4) by relay.tis.com via smap (V3.1) id xma026264; Mon, 11 Mar 96 18:48:22 -0500 Received: from research.att.com by ns; Mon Mar 11 18:47:04 EST 1996 Received: from gryphon by research; Mon Mar 11 18:42:17 EST 1996 Received: by gryphon; Mon Mar 11 18:42:15 EST 1996 To: William Allen Simpson Cc: ipsec@TIS.COM Subject: Re: AH and ESP Orthogonality Date: Mon, 11 Mar 96 18:42:14 EST Sender: ipsec-request@neptune.tis.com Precedence: bulk For the past several years, this WG (and others such as SIP, SIPP, and IPng, and other protocol designers such as SSL) strongly supported orthogonality between the Authentication and Encapsulation (both privacy and compression) facilities. Recently, the WG chairs (without any stimulating WG comments) have tried to move the WG toward a non-orthogonal all-in-one approach for ESP. Last week, Ran Atkinson stood at the microphone, and stated (without elaboration) that his previous support for an orthogonal approach was a serious mistake". I ask, what was the mistake? While not completely worthless, ESP without both integrity protection and replay prevention is significantly weakened in many real environments. We therefore have a situation where ESP must be used in conjunction with AH, and no document saying so. Worse yet, we're paying the overhead price for a new header twice. I'm planning on writing an RFC explaining this, but I won't be able to get to it till next week, most likely -- I have other writing committments to finish up first. Received: from relay.tis.com by neptune.TIS.COM id aa24695; 11 Mar 96 19:46 EST Received: by relay.tis.com; id TAA26868; Mon, 11 Mar 1996 19:48:41 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma026865; Mon, 11 Mar 96 19:48:16 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA11379; Mon, 11 Mar 96 19:47:15 EST Received: by relay.tis.com; id TAA26854; Mon, 11 Mar 1996 19:48:14 -0500 Received: from merit.edu(35.1.1.42) by relay.tis.com via smap (V3.1) id xma026837; Mon, 11 Mar 96 19:47:39 -0500 Received: from Bill.Simpson.DialUp.Mich.Net (pm001-02.dialip.mich.net [35.1.48.51]) by merit.edu (8.7.4/merit-2.0) with SMTP id TAA00801 for ; Mon, 11 Mar 1996 19:48:47 -0500 (EST) Date: Tue, 12 Mar 96 00:26:58 GMT From: William Allen Simpson Message-Id: <5044.wsimpson@greendragon.com> To: ipsec@TIS.COM Subject: Re: AH and ESP Orthogonality Sender: ipsec-request@neptune.tis.com Precedence: bulk > From: smb@research.att.com > We therefore have a situation where ESP must be used in conjunction with > AH, and no document saying so. Hmmm, perhaps I am mistaken, but as I have already quoted the "documents saying so" in a previous message, do I need to quote them again? Why do you think that the documents don't say so? Is there a suggestion you could make to improve the text? > Worse yet, we're paying the overhead > price for a new header twice. > True. That was the tradeoff for orthogonality. It was 8 bytes for AH. But, if we also require AH for message origin authentication, while ESP provides integrity, we haven't saved anything. As noted by Bob Baldwin last week, we have a bigger hit for processing costs, too. So, which do you prefer? 33% slower processing??? Look folks, we discussed this all last year. We knew about the cut and paste attack before we wrote the documents. We referenced the Bellovin presentation in the documents. The "mistake" that Atkinson made MUST be something else that we didn't already know about. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 Received: from relay.tis.com by neptune.TIS.COM id aa25152; 11 Mar 96 20:09 EST Received: by relay.tis.com; id UAA27115; Mon, 11 Mar 1996 20:11:12 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma027113; Mon, 11 Mar 96 20:10:43 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA11814; Mon, 11 Mar 96 20:09:43 EST Received: by relay.tis.com; id UAA27110; Mon, 11 Mar 1996 20:10:41 -0500 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1) id xma027104; Mon, 11 Mar 96 20:10:12 -0500 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id RAA03173; Mon, 11 Mar 1996 17:11:20 -0800 Received: by mailsun2.us.oracle.com (8.7.1/37.8) id RAA16565; Mon, 11 Mar 1996 17:13:37 -0800 (PST) Message-Id: <199603120113.RAA16565@mailsun2.us.oracle.com> Date: 11 Mar 96 17:07:59 -0800 From: "PALAMBER.US.ORACLE.COM" To: wsimpson@umich.edu Subject: Re: AH and ESP Orthogonality Cc: ipsec@TIS.COM X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-request@neptune.tis.com's message of 11-Mar-96 22:07 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Boundary-3762205-0-0 Sender: ipsec-request@neptune.tis.com Precedence: bulk --Boundary-3762205-0-0 Mr. Simpson Your comments are out of line! >Recently, the WG chairs (without any stimulating WG comments) have tried >to move the WG toward a non-orthogonal all-in-one approach for ESP. There is a very clear consensous for a mandatory transform with ESP that contains both confidentiality and integrity. I have no bias to drive the specifications toward anything but to complete the best specification capturing the requirements and consensus of the working group. While you may find long exchanges of rhetoric stimulating, most the working group have better ways to spend their free time. Please direct your delusions of intrigue to other venues. If your comments have any purpose besides inflating the count of messages on this list containing your return address, please rephrase them as specific technical recommendations. Paul A. Lambert IPSEC Co-Chair --Boundary-3762205-0-0 Content-Type: message/rfc822 Date: 11 Mar 96 22:07:45 From:"William Allen Simpson " To: ipsec@tis.com Subject: AH and ESP Orthogonality X-Orcl-Application: Sender: ipsec-request@neptune.tis.com X-Orcl-Application: Precedence: bulk For the past several years, this WG (and others such as SIP, SIPP, and IPng, and other protocol designers such as SSL) strongly supported orthogonality between the Authentication and Encapsulation (both privacy and compression) facilities. Recently, the WG chairs (without any stimulating WG comments) have tried to move the WG toward a non-orthogonal all-in-one approach for ESP. Last week, Ran Atkinson stood at the microphone, and stated (without elaboration) that his previous support for an orthogonal approach was "a serious mistake". I ask, what was the mistake? WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 --Boundary-3762205-0-0-- Received: from relay.tis.com by neptune.TIS.COM id aa25699; 11 Mar 96 20:38 EST Received: by relay.tis.com; id UAA27698; Mon, 11 Mar 1996 20:40:54 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma027689; Mon, 11 Mar 96 20:40:25 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA12354; Mon, 11 Mar 96 20:39:25 EST Received: by relay.tis.com; id UAA27684; Mon, 11 Mar 1996 20:40:24 -0500 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1) id xma027680; Mon, 11 Mar 96 20:40:21 -0500 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) with SMTP id UAA17978; Mon, 11 Mar 1996 20:41:09 -0500 (EST) Message-Id: <199603120141.UAA17978@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: William Allen Simpson Cc: ipsec@TIS.COM Subject: Re: AH and ESP Orthogonality In-Reply-To: Your message of "Tue, 12 Mar 1996 00:26:58 GMT." <5044.wsimpson@greendragon.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 11 Mar 1996 20:41:08 -0500 From: "Perry E. Metzger" Sender: ipsec-request@neptune.tis.com Precedence: bulk William Allen Simpson writes: > Look folks, we discussed this all last year. We knew about the cut and > paste attack before we wrote the documents. Actually, we didn't during the initial drafts, and we were discussing combined transforms as long ago as Toronto, though we didn't envision making them mandatory at the time. Anyway, lets just consider the situation on its current technical merits, and not try to figure out who said what when... Perry Received: from relay.tis.com by neptune.TIS.COM id aa08142; 12 Mar 96 8:28 EST Received: by relay.tis.com; id IAA02604; Tue, 12 Mar 1996 08:30:47 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma002599; Tue, 12 Mar 96 08:30:18 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA24470; Tue, 12 Mar 96 08:29:17 EST Received: by relay.tis.com; id IAA02595; Tue, 12 Mar 1996 08:30:17 -0500 Received: from ftp.com(128.127.2.122) by relay.tis.com via smap (V3.1) id xma002589; Tue, 12 Mar 96 08:29:55 -0500 Received: from ftp.com by ftp.com ; Tue, 12 Mar 1996 08:31:04 -0500 Received: from mailserv-H.ftp.com by ftp.com ; Tue, 12 Mar 1996 08:31:04 -0500 Received: from naganand-1.ftp.com (naganand-slippp.ftp.com) by MAILSERV-H.FTP.COM (5.x/SMI-SVR4) id AA17052; Tue, 12 Mar 1996 08:31:24 -0500 Date: Tue, 12 Mar 1996 08:31:24 -0500 Message-Id: <9603121331.AA17052@MAILSERV-H.FTP.COM> X-Sender: naganand@mailserv-H.ftp.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipsec@TIS.COM From: Naganand Doraswamy Subject: AH and ESP othogoanlity X-Mailer: Sender: ipsec-request@neptune.tis.com Precedence: bulk I agree that there are merits performing integrity along with encapsulation. The only problem I see with it is that there will be deployments for IPSEC in the very near future and most of the the implementations have implemented RFC's 1828 and 1829. We definitely cannot stop this as many customers have been asking for it. This may cause configuration problems for old implementation (implementing only 1829) to interoperate with the newer implementation which may support both 1829 and the new transform. Can we allocated numbers to the transforms as most of the key management protocols do so that configuring with manual keying is simplified? --Naganand Received: from relay.tis.com by neptune.TIS.COM id aa08807; 12 Mar 96 8:57 EST Received: by relay.tis.com; id IAA03023; Tue, 12 Mar 1996 08:59:17 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma003010; Tue, 12 Mar 96 08:58:48 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25717; Tue, 12 Mar 96 08:57:47 EST Received: by relay.tis.com; id IAA03007; Tue, 12 Mar 1996 08:58:47 -0500 Received: from unknown(35.1.1.42) by relay.tis.com via smap (V3.1) id xma002989; Tue, 12 Mar 96 08:58:30 -0500 Received: from Bill.Simpson.DialUp.Mich.Net (pm012-27.dialip.mich.net [141.211.7.195]) by merit.edu (8.7.4/merit-2.0) with SMTP id IAA18547 for ; Tue, 12 Mar 1996 08:59:34 -0500 (EST) Date: Tue, 12 Mar 96 13:25:54 GMT From: William Allen Simpson Message-Id: <5048.wsimpson@greendragon.com> To: ipsec@TIS.COM Subject: Re: AH and ESP Orthogonality Sender: ipsec-request@neptune.tis.com Precedence: bulk > From: "Perry E. Metzger" > William Allen Simpson writes: > > Look folks, we discussed this all last year. We knew about the cut and > > paste attack before we wrote the documents. > > Actually, we didn't during the initial drafts, Ah, Perry, but I beg to differ. We knew about general cut and paste against CBC _long_ before we wrote the drafts. It is a "feature" of CBC itself. Atkinson always had words in his drafts about the need for integrity. There was always a strong consensus for providing integrity. Bellovin merely described a specific scenario last April where cut and paste was a problem, and integrity was required. We added words to that effect to our documents. > and we were discussing > combined transforms as long ago as Toronto, though we didn't envision > making them mandatory at the time. > Yes, we were! And we _decided_ as a WG _not_ to use them, that orthogonality was better! > Anyway, lets just consider the situation on its current technical > merits, and not try to figure out who said what when... > My point is that we are rehashing old arguments, and undermining the good work and deployment that this WG generated. There has been no demonstrated need to eliminate orthogonality, and worse, it has been shown to be computationally problematic. What is the NEW attack, that we had not previously considered, that would require a removal of orthogonality? What was Atkinson's "serious mistake"? WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 Received: from relay.tis.com by neptune.TIS.COM id aa11213; 12 Mar 96 10:40 EST Received: by relay.tis.com; id KAA05054; Tue, 12 Mar 1996 10:41:59 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma005050; Tue, 12 Mar 96 10:41:31 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01926; Tue, 12 Mar 96 10:40:30 EST Received: by relay.tis.com; id KAA05043; Tue, 12 Mar 1996 10:41:29 -0500 Date: Tue, 12 Mar 1996 10:41:29 -0500 Received: from labs-n.bbn.com(128.89.0.100) by relay.tis.com via smap (V3.1) id xma005037; Tue, 12 Mar 96 10:41:12 -0500 Received: from COMSEC.BBN.COM by LABS-N.BBN.COM id aa12221; 12 Mar 96 10:41 EST X-Sender: kent@eudora.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: William Allen Simpson From: Stephen Kent Subject: Re: AH and ESP Orthogonality Cc: ipsec@TIS.COM Sender: ipsec-request@neptune.tis.com Precedence: bulk Bill, Having orthogonal transformations was not necessarily a bad idea, but there are benefits to having a better division of responsibility between AH and ESP. For example, the current definition of AH is messy because either AH covers the entirity of an IP datagram (minus mutuable IP header fields) or it covers just upper layer protocols. The distinction is a function of where AH appears relative to ESP. Several of us would prefer a verison of AH that applied to the whole datagram (as described above), period. ESP, if it omits integrity and authenticity facilities, creates a potential need for the embeded use of AH. However, if one were to redefine ESP to include optional authentication and integrity facilities, then there would be no need to embed AH when the required services spanned those now provided separately. This would be more efficient from a bandwidth standpoint, since a single header (ESP) could embody the fields necessary for this larger set of services. As it stands, ESP is a shell and all the detail is added in each transform defintion. This is unfortunate from a document structuring standpoint. It might be preferable if ESP defined optional, variable length fields for carrying the necessary data to support confidentiality and authentication and integrity. The specific fields used for a given SA would be defined at SA establishment, nailing this down for efficient per-packet processing. The result would be to make transform definition documents more modular. Several folks, including yours truly, have expressed a desire to add an anti-replay feature into the IPSEC suite. This could be useful in either AH or ESP, or both. The motivation is to process and drop replayed datagrams at an encrypting router, prior to letting them into a local net environment. (At a host this doesn't offer as much protection from a denial of service perspective, so it is most attractive in the context I cited.) This is a reasonable service to offer either in the context of AH or ESP. The former is especially appropriate if AH is used as an outer layer of protection that is stripped off at a firewall (perhaps with an inner ESP layer that goes all the way to the destination host), and the latter is especially appropriate of an ESP layer (used in tunnel mode) is stripped off at the firewall, with no inner layer IPSEC. The observation that anti-replay is a reasonable feature for both AH and ESP further motivates the creation of a single header that can provide all of the services of AH and ESP, or any subset of the services. I disagree with Perry about opacity being an important feature of ESP. I participated in the Toronto WG meetings and hallway discussions and I don't reacall opacity as a big deal, but I'm getting older so maybe my memory ain't what it should be ;-). In fact, I don't like the fact that the ESP spec is so detail-free and I'm not convinced that we can't have a header that allows for a wide range of combinations of confidentiality, integrity/authenticity, and anti-replay mechanisms, all of which can be optional, combined in a mix-and-match fashion. I think that a new header, providing such a set of features, might be what we should aim for. Steve Received: from relay.tis.com by neptune.TIS.COM id aa13781; 12 Mar 96 12:10 EST Received: by relay.tis.com; id MAA06223; Tue, 12 Mar 1996 12:12:29 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma006221; Tue, 12 Mar 96 12:12:01 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06279; Tue, 12 Mar 96 12:11:00 EST Received: by relay.tis.com; id MAA06216; Tue, 12 Mar 1996 12:11:59 -0500 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1) id xma006212; Tue, 12 Mar 96 12:11:40 -0500 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) with SMTP id MAA01994; Tue, 12 Mar 1996 12:12:37 -0500 (EST) Message-Id: <199603121712.MAA01994@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: William Allen Simpson Cc: ipsec@TIS.COM Subject: Re: AH and ESP Orthogonality In-Reply-To: Your message of "Tue, 12 Mar 1996 13:25:54 GMT." <5048.wsimpson@greendragon.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 12 Mar 1996 12:12:37 -0500 From: "Perry E. Metzger" Sender: ipsec-request@neptune.tis.com Precedence: bulk William Allen Simpson writes: > > From: "Perry E. Metzger" > > William Allen Simpson writes: > > > Look folks, we discussed this all last year. We knew about the cut and > > > paste attack before we wrote the documents. > > > > Actually, we didn't during the initial drafts, > > Ah, Perry, but I beg to differ. We knew about general cut and paste > against CBC _long_ before we wrote the drafts. It is a "feature" of > CBC itself. Actually, Bellovin came up with it in the hallway at Danvers outside the terminal room. I was there when it happened. We had suspicions that it was bad long before, but we didn't "know". Again, however, this is history. Lets try to focus on what is best at the moment, and not on what is historical. > My point is that we are rehashing old arguments, and undermining the > good work and deployment that this WG generated. I don't think that we need to undermine anything, especially if we declare the new transforms to be just that, *new* and better transforms. Thats why I am against the notion of "replacement" and want us to think instead in terms of things being "new and improved". As I've said for a long time, our understanding of these things gets refined with time and we have to expect to be coming up with new transforms for new algorithims every few years for the rest of the lifetime of the net. We should get used to it. Perry Received: from relay.tis.com by neptune.TIS.COM id aa16313; 12 Mar 96 13:44 EST Received: by relay.tis.com; id NAA07503; Tue, 12 Mar 1996 13:46:39 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma007487; Tue, 12 Mar 96 13:46:10 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA09706; Tue, 12 Mar 96 13:45:09 EST Received: by relay.tis.com; id NAA07484; Tue, 12 Mar 1996 13:46:08 -0500 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1) id xma007481; Tue, 12 Mar 96 13:46:00 -0500 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id KAA08031; Tue, 12 Mar 1996 10:47:08 -0800 Date: Tue, 12 Mar 1996 10:47:08 -0800 From: Ran Atkinson Message-Id: <199603121847.KAA08031@puli.cisco.com> To: ipsec@TIS.COM Subject: Re: AH and ESP othogoanlity In-Reply-To: <9603121331.AA17052@MAILSERV-H.FTP.COM> Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: Sender: ipsec-request@neptune.tis.com Precedence: bulk ASIDE: I'm deliberately ignoring the notes to the IPsec list that focus on "history" or "personal issues" rather than technology. My silence does NOT imply that I agree with others' views of history or that I agree with the words that others are putting in my mouth. Mainly, I'm focusing on writing IP code. I prefer writing IP code to playing rhetorical games with history or personal issues. In article <9603121331.AA17052@MAILSERV-H.FTP.COM> Naganand wrote: >I agree that there are merits performing integrity along with encapsulation. >The only problem I see with it is that there will be deployments for IPSEC >in the very near future and most of the the implementations have implemented >RFC's 1828 and 1829. We definitely cannot stop this as many customers have >been asking for it. I don't think anyone has suggested that anyone stop deploying those transforms, though it seems likely that at least RFC-1829 will move off the standards-track to Historic status eventually. It might later become the case that some new transform would be mandatory-to-implement in lieu of RFC-1829, but this could be addressed by adding support for an additional transform whilst not removing support for the RFC-1829 transform -- if an implementer chose to do such. >This may cause configuration problems for old implementation (implementing >only 1829) to interoperate with the newer implementation which may support >both 1829 and the new transform. Can we allocated numbers to the transforms >as most of the key management protocols do so that configuring with manual >keying is simplified? I believe that more or less any publicly documented transform should be allocated its own "transform identifier" by each of the various key management proposals. I specifically asked the ISAKMP authors to add transform identifiers for the current Experimental transforms so that nodes that choose to use those transforms can use ISAKMP for key mgmt. NOTE: I have not fully grok'd Perry's anxiety over the word "replace" and don't want to get into that here and now because it doesn't seem terribly productive here and now. I will note that in my view if RFC-1829 were replaced on the standards-track by an ESP DES-CBC+MD5+Replay transform, this would mean that the replacement ESP DES-CBC+MD5+Replay transform would be allocated a new "transform identifier" (i.e. transform identifier that is different from the one that would remain allocated for RFC-1829). I use "replace" in the context of what the mandatory-to-implement transform would be rather than in the context of what is meant by a particular "transform identifier" number. This is just a matter of good protocol engineering. If a transform changes in a material way, then it needs a new published specification and it needs a new "transform identifier". We will probably continue to add new and better transforms forever in the future as technology advances. Implementers who don't design/build with the assumption that new transforms will eventually come will probably regret it later on. Bottom Line: Naganand and others with similar concerns should not worry about this particular issue. Key mgmt draft authors should allocate transform identifiers for each stable openly-published transform (An Internet-Draft is, by definition, not considered stable but an RFC is stable). Ran rja@cisco.com Received: from relay.tis.com by neptune.TIS.COM id aa17007; 12 Mar 96 14:03 EST Received: by relay.tis.com; id OAA08017; Tue, 12 Mar 1996 14:05:39 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma007999; Tue, 12 Mar 96 14:05:12 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10647; Tue, 12 Mar 96 14:04:11 EST Received: by relay.tis.com; id OAA07989; Tue, 12 Mar 1996 14:05:09 -0500 Received: from merit.edu(35.1.1.42) by relay.tis.com via smap (V3.1) id xma007971; Tue, 12 Mar 96 14:04:41 -0500 Received: from Bill.Simpson.DialUp.Mich.Net (pm012-22.dialip.mich.net [141.211.7.190]) by merit.edu (8.7.4/merit-2.0) with SMTP id OAA29250 for ; Tue, 12 Mar 1996 14:05:43 -0500 (EST) Date: Tue, 12 Mar 96 18:15:56 GMT From: William Allen Simpson Message-Id: <5053.wsimpson@greendragon.com> To: ipsec@TIS.COM Subject: Re: AH and ESP Orthogonality Sender: ipsec-request@neptune.tis.com Precedence: bulk > From: Stephen Kent > Having orthogonal transformations was not necessarily a bad idea, > but there are benefits to having a better division of responsibility > between AH and ESP. I agree. > For example, the current definition of AH is messy > because either AH covers the entirity of an IP datagram (minus mutuable IP > header fields) or it covers just upper layer protocols. The distinction is > a function of where AH appears relative to ESP. Several of us would prefer > a verison of AH that applied to the whole datagram (as described above), > period. > I understand. You raised this last year. But, other analysts prefered the AH "inside" ESP approach. So, there was no agreement. Instead, a flexible mechanism was defined, and the orthogonality allowed both approaches. Indeed, the chairs dictated to Jim Hughes in his DES+MD5 draft that the MD5 apply to the "inside" plaintext, rather than the "outside" ciphertext. There were objections raised from the WG, such as Karn. Outside allows detection of modification sooner, rather than after DES. As you may remember, I'm an "outy" myself. > It might be preferable if ESP defined > optional, variable length fields for carrying the necessary data to support > confidentiality and authentication and integrity. The specific fields used > for a given SA would be defined at SA establishment, nailing this down for > efficient per-packet processing. The result would be to make transform > definition documents more modular. > The result would be to make the transform documents much more difficult to understand and implement. The WG rejected the variable fields approach yet _again_ last week. Instead, we nail down the specific _transforms_ at SA establishment. Same result, easier to implement, easier to verify. > Several folks, including yours truly, have expressed a desire to > add an anti-replay feature into the IPSEC suite. This could be useful in > either AH or ESP, or both. I'm included in that "several folks". We discussed this last year, and again in January of this year. It's in our latest ESP revision, and in Photuris Extensions. But, as you may remember Atkinson's message: Date: Thu, 22 Feb 1996 12:29:13 -0800 Message-Id: <199602222029.MAA00276@puli.cisco.com> 5) Section 2.11 of draft-ietf-ipsec-photuris-ext-01.txt MUST be deleted. It is WAY outside the scope of Bill's draft to modify any standards track protocol and the attempt to do so is more than sufficient grounds to bar publication as ANY kind of RFC until that section is deleted. So, the chairs are rather vehemently against adding replay protection, even as a negotiated option. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 Received: from relay.tis.com by neptune.TIS.COM id aa17006; 12 Mar 96 14:03 EST Received: by relay.tis.com; id OAA08016; Tue, 12 Mar 1996 14:05:39 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma007998; Tue, 12 Mar 96 14:05:12 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10646; Tue, 12 Mar 96 14:04:10 EST Received: by relay.tis.com; id OAA07988; Tue, 12 Mar 1996 14:05:09 -0500 Received: from merit.edu(35.1.1.42) by relay.tis.com via smap (V3.1) id xma007980; Tue, 12 Mar 96 14:04:42 -0500 Received: from Bill.Simpson.DialUp.Mich.Net (pm012-22.dialip.mich.net [141.211.7.190]) by merit.edu (8.7.4/merit-2.0) with SMTP id OAA29256 for ; Tue, 12 Mar 1996 14:05:46 -0500 (EST) Date: Tue, 12 Mar 96 18:36:41 GMT From: William Allen Simpson Message-Id: <5054.wsimpson@greendragon.com> To: ipsec@TIS.COM Subject: Re: AH and ESP othogoanlity Sender: ipsec-request@neptune.tis.com Precedence: bulk > From: Naganand Doraswamy > The only problem I see with it is that there will be deployments for IPSEC > in the very near future and most of the the implementations have implemented > RFC's 1828 and 1829. We definitely cannot stop this as many customers have > been asking for it. > I agree. > This may cause configuration problems for old implementation (implementing > only 1829) to interoperate with the newer implementation which may support > both 1829 and the new transform. Can we allocated numbers to the transforms > as most of the key management protocols do so that configuring with manual > keying is simplified? > Well, I don't particularly like numbers for manual configuration, and the RFC numbers can change as the documents are progressed along standards track. The way I'm doing it is by naming: MD5E AH with MD5 "envelope" MD5N AH with MD5 "nested" SHA1E AH with SHA1 "envelope" SHA1N AH with SHA1 "nested" DES1IV32 ESP with Single DES with 32-bit IV DES1IV64 ESP with Single DES with 64-bit IV DES3IV32 ESP with Triple DES with 32-bit IV DES3IV64 ESP with Triple DES with 64-bit IV Make sense to you? WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 Received: from relay.tis.com by neptune.TIS.COM id aa19717; 12 Mar 96 15:30 EST Received: by relay.tis.com; id PAA09804; Tue, 12 Mar 1996 15:32:11 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma009802; Tue, 12 Mar 96 15:31:43 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA15606; Tue, 12 Mar 96 15:30:42 EST Received: by relay.tis.com; id PAA09799; Tue, 12 Mar 1996 15:31:41 -0500 Date: Tue, 12 Mar 1996 15:31:41 -0500 Received: from labs-n.bbn.com(128.89.0.100) by relay.tis.com via smap (V3.1) id xma009797; Tue, 12 Mar 96 15:31:27 -0500 Received: from COMSEC.BBN.COM by LABS-N.BBN.COM id aa12323; 12 Mar 96 15:30 EST X-Sender: kent@eudora.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: William Allen Simpson From: Stephen Kent Subject: Re: AH and ESP Orthogonality Cc: ipsec@TIS.COM Sender: ipsec-request@neptune.tis.com Precedence: bulk Bill, Some refinements on our dicussion: >I understand. You raised this last year. But, other analysts prefered >the AH "inside" ESP approach. So, there was no agreement. Instead, >a flexible mechanism was defined, and the orthogonality allowed both >approaches. > >Indeed, the chairs dictated to Jim Hughes in his DES+MD5 draft that the >MD5 apply to the "inside" plaintext, rather than the "outside" >ciphertext. There were objections raised from the WG, such as Karn. >Outside allows detection of modification sooner, rather than after DES. AH applied to the whole datagram is useful and a necessary facility, whether provided by the current form of AH or some other header. However, the inside version of AH, applying only to upperlayer protocols, is redundant if one defines ESP transforms that provide the same features. That is why I would suggest that we redefine AH (or define another header) that has one, well-defined scope. >> It might be preferable if ESP defined >> optional, variable length fields for carrying the necessary data to support >> confidentiality and authentication and integrity. The specific fields used >> for a given SA would be defined at SA establishment, nailing this down for >> efficient per-packet processing. The result would be to make transform >> definition documents more modular. >> >The result would be to make the transform documents much more difficult >to understand and implement. The WG rejected the variable fields >approach yet _again_ last week. > >Instead, we nail down the specific _transforms_ at SA establishment. > >Same result, easier to implement, easier to verify. I don't agree with your characterization of the tradeoffs here. One header that permitted various combinations of security services, would be more complex than our existing headers and an individual transform such as single DES with 64-bit IV. However, as more transforms are added, each one tends to duplicate significant pieces of previously defined transforms. Moreover, when the transform includes not just one algorithm, but a combination of algorithms (e.g., DES and MD5) and algorithm parameters, the resulting set of documents gets pretty big in a hurry. general interoperability requires either that everyone uses just the default transform, or that all implementations support many transforms, many with very small differences from one another. It isn't clear to me that there are significant differences in supporting various transforms (as currently defined) vs. supporting a single header type with optional, discretely variable length fields. An implementor still has to deal with some default subset of algorithms and combinations, and then decide what optional ones also will be supported. I'd like to think that the result would be better modularity in the transform definitions, although you clearly believe that the opposite will result. I guess those who would like to see this approach will have to try to write the appropriate documents to see how it works out. As for the cited message from Ran re the Photuris spec, I'm not sure I can distinguish between criticism directed at those documents and the more general issue of inclusion of anti-replay features in IPSEC. Steve Received: from relay.tis.com by neptune.TIS.COM id aa22973; 12 Mar 96 17:25 EST Received: by relay.tis.com; id RAA11122; Tue, 12 Mar 1996 17:27:42 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma011120; Tue, 12 Mar 96 17:27:13 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20559; Tue, 12 Mar 96 17:26:12 EST Received: by relay.tis.com; id RAA11117; Tue, 12 Mar 1996 17:27:12 -0500 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1) id xma011115; Tue, 12 Mar 96 17:26:58 -0500 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id OAA29380; Tue, 12 Mar 1996 14:28:07 -0800 Date: Tue, 12 Mar 1996 14:28:07 -0800 From: Ran Atkinson Message-Id: <199603122228.OAA29380@puli.cisco.com> To: ipsec@TIS.COM Subject: Re: AH and ESP Orthogonality In-Reply-To: <5053.wsimpson@greendragon.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: Sender: ipsec-request@neptune.tis.com Precedence: bulk In article <5053.wsimpson@greendragon.com> Bill Simpson wrote: > Date: Thu, 22 Feb 1996 12:29:13 -0800 > Message-Id: <199602222029.MAA00276@puli.cisco.com> > > 5) Section 2.11 of draft-ietf-ipsec-photuris-ext-01.txt MUST be deleted. > It is WAY outside the scope of Bill's draft to modify any standards > track protocol and the attempt to do so is more than sufficient grounds > to bar publication as ANY kind of RFC until that section is deleted. > >So, the chairs are rather vehemently against adding replay protection, >even as a negotiated option. Bill, Not true. The chairs are opposed to a key management protocol changing the specification of material that is outside the scope of that key management protocol specification. Any attempt by any key management specification to change the specifications contained in RFC-1825 thru RFC-1827 is out of order. Key management proposals MUST conform with RFC-1825 through RFC-1827 and MUST NOT alter those specifications. Changes to RFC-1825 through RFC-1827 may be made only by the working group as a whole. If such changes are to be made, they will be reflected in the revisions of RFC-1825 through RFC-1829 (which I will prepare in I-D form presently). If replay protection is added, then the key management proposals can be modified to reflect that change afterwards. Ran rja@cisco.com Received: from relay.tis.com by neptune.TIS.COM id aa17593; 13 Mar 96 14:44 EST Received: by relay.tis.com; id OAA23262; Wed, 13 Mar 1996 14:46:14 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma023254; Wed, 13 Mar 96 14:45:47 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13082; Wed, 13 Mar 96 14:44:45 EST Received: by relay.tis.com; id OAA23244; Wed, 13 Mar 1996 14:45:44 -0500 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1) id xma023240; Wed, 13 Mar 96 14:45:43 -0500 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id LAA07737; Wed, 13 Mar 1996 11:46:48 -0800 Date: Wed, 13 Mar 1996 11:46:48 -0800 From: Ran Atkinson Message-Id: <199603131946.LAA07737@puli.cisco.com> To: ipsec@TIS.COM Subject: A comment from the co-chair Sender: ipsec-request@neptune.tis.com Precedence: bulk All, The misrepresentations in the notes below are unproductive and unwarranted. The ongoing personal attacks on the chairs and other members of the WG from Bill Simpson are not acceptable behavior in this or any other IETF WG. In future, notes that contain personal attacks will be ignored in toto by the chairs. If Bill keeps up his current behavior, we suggest putting all incoming mail from Bill into /dev/null using a kill file or other similar mechanism. We suggest that others on the list ignore the entire contents of all notes containing personal attacks and simply don't respond to them or their author. It is entirely unproductive to focus on perceptions of history. Instead the discussions should focus on the technical issues before us so that forward progress can be made. Discussions about history, who said what when to whom and so on cannot be objectively confirmed and only cause confusion, contention and divisiveness. They are not productive. As to what Ran has said or what Ran believes, Bill's assertions are quite false. Ran is fairly confused as to how Bill came to his misperception of the facts. Ran's comments quoted below about the inappropriateness of Bill's draft to alter the AH specification clearly indicates that it is a problem of scoping. AH/ESP specification changes MUST NOT be attempted by any key management proposal. Rather, the key management proposals MUST conform to the AH/ESP specs. If the WG later decides to modify the AH/ESP specs at some time, then the key management specs can be correspondingly modified at that future time. The WG chairs understand from the LA IETF meeting that keyed integrity on the protected data of the ESP header is part of the mandatory ESP transform. Similarly, it is our understanding that implementation of support for replay protection as part of ESP is mandatory. Finally, understanding that WG consensus is that the RFC-1829 transform should be obsoleted on the standards track by a new ESP transform. The new transform will have a new transform identifier so as to avoid confusion with RFC-1829. The WG chairs have assigned the Document Editor position for that new ESP transform to Jim Hughes. The new transform will correct these deficiencies in RFC-1829. Once that new transform moves to Proposed Standard, RFC-1829 will move to HISTORIC status and leave the standards track. RFC-1825 through RFC-1828 are not yet able to be considered for advancement to Draft Standard under IETF rules because of the cross dependencies among each other and with the ESP transform. They can be considered for advancement once the new ESP transform has been at Proposed Standard for 6 months and has at least 2 interoperable implementations. As none of the current Key Management proposals currently meet WG requirements (though all could be modified to meet WG requirements), none can proceed to Last Call or onto the Standards Track at this time. It is the prerogative of Working Group Chairs to decide who may edit documents for their working group. Bill Simpson's behavior is incompatible with the requirements of Document Editor for documents to be considered by the IPSEC Working Group for the IETF Standards Track. Documents edited by Bill will not be considered by the Chairs for consideration in the IPSEC Working Group. This does not preclude others from listing Bill as co-author on documents in which he has made significant technical contributions. Randall Atkinson rja@inet.org Co-Chair, IP Security WG PS: Any complaints about this note should be directed at the Security AD, Jeff Schiller . [Quoted notes follow] ---------------------------------------------------------------------- From: wsimpson@greendragon.com (William Allen Simpson) To: ipsec@TIS.COM Subject: AH and ESP Orthogonality Message-ID: <5041.wsimpson@greendragon.com> Date: 11 Mar 96 22:07:45 GMT For the past several years, this WG (and others such as SIP, SIPP, and IPng, and other protocol designers such as SSL) strongly supported orthogonality between the Authentication and Encapsulation (both privacy and compression) facilities. Recently, the WG chairs (without any stimulating WG comments) have tried to move the WG toward a non-orthogonal all-in-one approach for ESP. Last week, Ran Atkinson stood at the microphone, and stated (without elaboration) that his previous support for an orthogonal approach was "a serious mistake". I ask, what was the mistake? WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 ---------------------------------------------------------------------- From: wsimpson@greendragon.com (William Allen Simpson) To: ipsec@TIS.COM Subject: Re: Alternative transform encapsulation scheme Message-ID: <5040.wsimpson@greendragon.com> Date: 11 Mar 96 21:42:41 GMT Lines: 43 > From: smb@research.att.com > Date: Sat, 09 Mar 96 14:48:32 EST > > There's a lot that needs to be rethought. I could quite easily be > persuaded that we shouldn't -- we've got to get this stuff > deployed ASAP. I'm with Bellovin on this. I don't think we need a non-orthogonal transform (even though I've written a draft). The deployed AH-MD5 + ESP-DES is adequate. > that we should simply decree that ESP > must be used only in conjunction with AH We already did, when the ESP transform doesn't provide integrity!!! In addition to the numerous references in RFC-1825, -1826, and -1827, RFC-1829 (ESP-DES) clearly states: The usual (ICMP, TCP, UDP) transport checksum can detect this attack, but on its own is not considered cryptographically strong. In this situation, user or connection oriented integrity checking is needed [RFC-1826]. And you promised to write up a more thorough analysis of your attack.... > One small change -- the addition of replay protection -- > does seem to be needed, though. > Why? Doesn't the underlying transport _already_ protect against replay? That is, TCP and ICMP already protect themselves against replay. So, you are recommending that the next version of -1826 provide a replay prevention mechanism? We've discussed this before, but Atkinson was opposed. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 ---------------------------------------------------------------------- From: wsimpson@greendragon.com (William Allen Simpson) To: ipsec@TIS.COM Subject: Re: AH and ESP Orthogonality Message-ID: <5044.wsimpson@greendragon.com> Date: 12 Mar 96 00:26:58 GMT Lines: 33 > From: smb@research.att.com > We therefore have a situation where ESP must be used in conjunction with > AH, and no document saying so. Hmmm, perhaps I am mistaken, but as I have already quoted the "documents saying so" in a previous message, do I need to quote them again? Why do you think that the documents don't say so? Is there a suggestion you could make to improve the text? > Worse yet, we're paying the overhead > price for a new header twice. > True. That was the tradeoff for orthogonality. It was 8 bytes for AH. But, if we also require AH for message origin authentication, while ESP provides integrity, we haven't saved anything. As noted by Bob Baldwin last week, we have a bigger hit for processing costs, too. So, which do you prefer? 33% slower processing??? Look folks, we discussed this all last year. We knew about the cut and paste attack before we wrote the documents. We referenced the Bellovin presentation in the documents. The "mistake" that Atkinson made MUST be something else that we didn't already know about. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 ---------------------------------------------------------------------- From: wsimpson@greendragon.com (William Allen Simpson) To: ipsec@TIS.COM Newsgroups: cisco.external.ietf.ipsec Subject: Re: AH and ESP Orthogonality Message-ID: <5048.wsimpson@greendragon.com> Date: 12 Mar 96 13:25:54 GMT Lines: 45 > From: "Perry E. Metzger" > William Allen Simpson writes: > > Look folks, we discussed this all last year. We knew about the cut and > > paste attack before we wrote the documents. > > Actually, we didn't during the initial drafts, Ah, Perry, but I beg to differ. We knew about general cut and paste against CBC _long_ before we wrote the drafts. It is a "feature" of CBC itself. Atkinson always had words in his drafts about the need for integrity. There was always a strong consensus for providing integrity. Bellovin merely described a specific scenario last April where cut and paste was a problem, and integrity was required. We added words to that effect to our documents. > and we were discussing > combined transforms as long ago as Toronto, though we didn't envision > making them mandatory at the time. > Yes, we were! And we _decided_ as a WG _not_ to use them, that orthogonality was better! > Anyway, lets just consider the situation on its current technical > merits, and not try to figure out who said what when... > My point is that we are rehashing old arguments, and undermining the good work and deployment that this WG generated. There has been no demonstrated need to eliminate orthogonality, and worse, it has been shown to be computationally problematic. What is the NEW attack, that we had not previously considered, that would require a removal of orthogonality? What was Atkinson's "serious mistake"? WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 ---------------------------------------------------------------------- From: wsimpson@greendragon.com (William Allen Simpson) To: ipsec@TIS.COM Newsgroups: cisco.external.ietf.ipsec Subject: Re: AH and ESP Orthogonality Message-ID: <5053.wsimpson@greendragon.com> Date: 12 Mar 96 18:15:56 GMT Lines: 67 > From: Stephen Kent > Having orthogonal transformations was not necessarily a bad idea, > but there are benefits to having a better division of responsibility > between AH and ESP. I agree. > For example, the current definition of AH is messy > because either AH covers the entirity of an IP datagram (minus mutuable IP > header fields) or it covers just upper layer protocols. The distinction is > a function of where AH appears relative to ESP. Several of us would prefer > a verison of AH that applied to the whole datagram (as described above), > period. > I understand. You raised this last year. But, other analysts prefered the AH "inside" ESP approach. So, there was no agreement. Instead, a flexible mechanism was defined, and the orthogonality allowed both approaches. Indeed, the chairs dictated to Jim Hughes in his DES+MD5 draft that the MD5 apply to the "inside" plaintext, rather than the "outside" ciphertext. There were objections raised from the WG, such as Karn. Outside allows detection of modification sooner, rather than after DES. As you may remember, I'm an "outy" myself. > It might be preferable if ESP defined > optional, variable length fields for carrying the necessary data to support > confidentiality and authentication and integrity. The specific fields used > for a given SA would be defined at SA establishment, nailing this down for > efficient per-packet processing. The result would be to make transform > definition documents more modular. > The result would be to make the transform documents much more difficult to understand and implement. The WG rejected the variable fields approach yet _again_ last week. Instead, we nail down the specific _transforms_ at SA establishment. Same result, easier to implement, easier to verify. > Several folks, including yours truly, have expressed a desire to > add an anti-replay feature into the IPSEC suite. This could be useful in > either AH or ESP, or both. I'm included in that "several folks". We discussed this last year, and again in January of this year. It's in our latest ESP revision, and in Photuris Extensions. But, as you may remember Atkinson's message: Date: Thu, 22 Feb 1996 12:29:13 -0800 Message-Id: <199602222029.MAA00276@puli.cisco.com> 5) Section 2.11 of draft-ietf-ipsec-photuris-ext-01.txt MUST be deleted. It is WAY outside the scope of Bill's draft to modify any standards track protocol and the attempt to do so is more than sufficient grounds to bar publication as ANY kind of RFC until that section is deleted. So, the chairs are rather vehemently against adding replay protection, even as a negotiated option. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 ---------------------------------------------------------------------- Received: from relay.tis.com by neptune.TIS.COM id aa14066; 14 Mar 96 13:22 EST Received: by relay.tis.com; id NAA07888; Thu, 14 Mar 1996 13:24:00 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma007886; Thu, 14 Mar 96 13:23:31 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA29794; Thu, 14 Mar 96 13:22:29 EST Received: by relay.tis.com; id NAA07880; Thu, 14 Mar 1996 13:23:30 -0500 Received: from netcom9.netcom.com(192.100.81.119) by relay.tis.com via smap (V3.1) id xma007877; Thu, 14 Mar 96 13:23:28 -0500 Received: by netcom9.netcom.com (8.6.13/Netcom) id KAA14604; Thu, 14 Mar 1996 10:24:13 -0800 Date: Thu, 14 Mar 1996 10:24:13 -0800 From: John Kennedy Message-Id: <199603141824.KAA14604@netcom9.netcom.com> To: cat-ietf@mit.edu, dns-security@TIS.COM, ietf-pkix@tandem.com, ipsec@TIS.COM, spki@c2.org, www-security@nsmx.rutgers Subject: CYLINK's Support for Open Public Key Standards Sender: ipsec-request@neptune.tis.com Precedence: bulk ---------------------------------------------------------------------------- CYLINK Corporation March 14, 1996 The following is a copy of an announcement I made in the IPSEC and PKIX working group sessions at IETF Los Angeles. In response to numerous requests, I am posting a copy of the announcement to the applicable IETF working group mailing lists. -John Kennedy, CYLINK ---------------------------------------------------------------------------- CYLINK'S SUPPORT FOR OPEN PUBLIC KEY STANDARDS EXISTING AND PROSPECTIVE CYLINK LICENSEES OF THE STANFORD PUBLIC KEY PATENTS MAY SUPPLEMENT THEIR LICENSES IN ACCORDANCE WITH THE FOLLOWING STATEMENT.: ATTACHMENT "A" STATEMENT OF PATENT POSITION Cylink Corporation, through its wholly owned subsidiary Caro-Kann Corporation, holds exclusive sublicensing rights to the following U.S. patents owned by the Leland Stanford Junior University: Cryptographic Apparatus and Method ("Hellman-Diffie")......................... No. 4,200,770 Public Key Cryptographic Apparatus and Method ("Hellman-Merkle")............. No. 4,218,582 In order to promote the widespread use of these inventions from Stanford University and adoption of the [Name IETF Standard] reference by the IETF community, [Name of Licensee] has acquired the right under its sublicense from Cylink to offer the [Name IETF Standard] reference implementation to all third parties on a royalty free basis. This royalty free privilege is limited to use of the [Name IETF Standard] reference implementation in accordance with proposed, pending or approved IETF standards, and applies only when used with Diffie- Hellman key exchange, the Digital Signature Standard, or any other public key techniques which are publicly available for commercial use on a royalty free basis. Any use of the [Name IETF Standard] reference implementation which does not satisfy these conditions and incorporates the practice of public key may require a separate patent license to the Stanford Patents which must be negotiated with Cylink's subsidiary, Caro-Kann Corporation. For additional licensing information please contact: Robert Fougner Director of Licensing CYLINK Corporation 910 Hermosa Court Sunnyvale, CA 94086 (408) 735-5893 ---------------------------------------------------------------------------- Received: from relay.tis.com by neptune.TIS.COM id aa16011; 14 Mar 96 14:10 EST Received: by relay.tis.com; id OAA08747; Thu, 14 Mar 1996 14:12:30 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma008725; Thu, 14 Mar 96 14:12:01 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02563; Thu, 14 Mar 96 14:10:59 EST Received: by relay.tis.com; id OAA08722; Thu, 14 Mar 1996 14:12:00 -0500 Received: from chimay.mach.cs.cmu.edu(128.2.222.167) by relay.tis.com via smap (V3.1) id xma008720; Thu, 14 Mar 96 14:11:59 -0500 Received: from CHIMAY.MACH.CS.CMU.EDU by CHIMAY.MACH.CS.CMU.EDU id aa19577; 14 Mar 96 14:10:48 EST To: John Kennedy Cc: cat-ietf@mit.edu, dns-security@TIS.COM, ietf-pkix@tandem.com, ipsec@TIS.COM, spki@c2.org In-Reply-To: Your message of "Thu, 14 Mar 96 10:24:13 PST" <199603141824.KAA14604@netcom9.netcom.com> From: Dave Johnson Subject: Re: CYLINK's Support for Open Public Key Standards Date: Thu, 14 Mar 96 14:10:46 EST Message-Id: <19575.826830646@CHIMAY.MACH.CS.CMU.EDU> Sender: ipsec-request@neptune.tis.com Precedence: bulk >---------------------------------------------------------------------------- > >CYLINK Corporation >March 14, 1996 > > >The following is a copy of an announcement I made in the IPSEC >and PKIX working group sessions at IETF Los Angeles. In response to >numerous requests, I am posting a copy of the announcement to the >applicable IETF working group mailing lists. > >-John Kennedy, CYLINK > > >---------------------------------------------------------------------------- > >CYLINK'S SUPPORT FOR OPEN PUBLIC KEY STANDARDS > >EXISTING AND PROSPECTIVE CYLINK LICENSEES OF THE STANFORD PUBLIC >KEY PATENTS MAY SUPPLEMENT THEIR LICENSES IN ACCORDANCE WITH THE >FOLLOWING STATEMENT.: > > >ATTACHMENT "A" > > >STATEMENT OF PATENT POSITION > >Cylink Corporation, through its wholly owned subsidiary Caro-Kann >Corporation, holds exclusive sublicensing rights to the following >U.S. patents owned by the Leland Stanford Junior University: > > Cryptographic Apparatus and Method > ("Hellman-Diffie")......................... No. 4,200,770 > > Public Key Cryptographic Apparatus and Method > ("Hellman-Merkle")............. No. 4,218,582 > >In order to promote the widespread use of these inventions >from Stanford University and adoption of the [Name IETF Standard] >reference by the IETF community, [Name of Licensee] has acquired >the right under its sublicense from Cylink to offer the [Name IETF >Standard] reference implementation to all third parties on a royalty free >basis. > >This royalty free privilege is limited to use of the [Name IETF >Standard] reference implementation in accordance with proposed, >pending or approved IETF standards, and applies only when used with >Diffie- Hellman key exchange, the Digital Signature Standard, or any other >public key techniques which are publicly available for commercial >use on a royalty free basis. Any use of the [Name IETF Standard] reference >implementation which does not satisfy these conditions and incorporates >the practice of public key may require a separate patent license >to the Stanford Patents which must be negotiated with Cylink's >subsidiary, Caro-Kann Corporation. > > >For additional licensing information please contact: > > Robert Fougner > Director of Licensing > CYLINK Corporation > 910 Hermosa Court > Sunnyvale, CA 94086 > (408) 735-5893 > >---------------------------------------------------------------------------- How does this apply to a non-profit organization (such as a university) that wants to make a "reference implementation" of an IETF protocol (that uses Diffie-Hellman) freely available? Under the RSAREF license, I think this was possible, but has this changed things? Dave -- David B. Johnson E-mail: dbj@cs.cmu.edu Assistant Professor Home page: http://www.cs.cmu.edu/~dbj Computer Science Department Phone: (412) 268-7399 Carnegie Mellon University Fax: (412) 268-5576 5000 Forbes Avenue Pittsburgh, PA 15213-3891 Received: from relay.tis.com by neptune.TIS.COM id aa24936; 14 Mar 96 20:33 EST Received: by relay.tis.com; id UAA15033; Thu, 14 Mar 1996 20:35:16 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma015031; Thu, 14 Mar 96 20:34:48 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16651; Thu, 14 Mar 96 20:33:45 EST Received: by relay.tis.com; id UAA15026; Thu, 14 Mar 1996 20:34:46 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma015022; Thu, 14 Mar 96 20:34:26 -0500 Received: from RSA.COM by interlock.ans.net with SMTP id AA05901 (InterLock SMTP Gateway 3.0 for ); Thu, 14 Mar 1996 20:35:30 -0500 Received: from snail.rsa.com by RSA.COM with SMTP id AA18737; Thu, 14 Mar 96 17:26:18 PST Received: from cc:Mail by snail.rsa.com id AA826853770; Thu, 14 Mar 96 17:36:15 PST Date: Thu, 14 Mar 96 17:36:15 PST From: baldwin Message-Id: <9602148268.AA826853770@snail.rsa.com> To: ipsec@ans.net Cc: bretth@newbridge.com, "Robert W. Baldwin" , rivest@theory.lcs.mit.edu, Tim Matthews Subject: ESP transform with RC5 Sender: ipsec-request@neptune.tis.com Precedence: bulk IPsec members, I have just submitted two informational RFCs to the Internet Engineering Task Force that specify how the high performance RC5 cipher can be used to add privacy to packets transmitted over the Internet. These two documents were developed by RSA Data Security Inc. and TimeStep Corporation. They are being submitted for review by the security working groups of the IETF. They are currently available from RSA's web and FTP sites. The first document describes the RC5 cipher in sufficient detail to create interoperable implementations. It is titled "The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms" by Bob Baldwin and Ronald Rivest and is available via ftp://ftp.rsa.com/pub/rc5/draft-rsadsi-rc5-00.txt. The other document describes how to use the RC5-CBC cipher to encrypt IP packets following the framework defined by the IP Security Working Group of the IETF. It is titled "The ESP RC5 Transform" and is available via: ftp://ftp.rsa.com/pub/rc5/draft-rsadsi-esp-rc5-00.txt. Please address comments and suggestions to baldwin@rsa.com or to ipsec@ans.net. --Bob Baldwin Received: from relay.tis.com by neptune.TIS.COM id aa14999; 15 Mar 96 15:24 EST Received: by relay.tis.com; id PAA27344; Fri, 15 Mar 1996 15:26:08 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma027316; Fri, 15 Mar 96 15:25:40 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21746; Fri, 15 Mar 96 15:24:37 EST Received: by relay.tis.com; id PAA27309; Fri, 15 Mar 1996 15:25:39 -0500 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1) id xma027303; Fri, 15 Mar 96 15:25:17 -0500 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id MAA02882; Fri, 15 Mar 1996 12:26:23 -0800 Date: Fri, 15 Mar 1996 12:26:23 -0800 From: Ran Atkinson Message-Id: <199603152026.MAA02882@puli.cisco.com> To: ipsec@TIS.COM Subject: Re: ESP transform with RC5 Cc: Sender: ipsec-request@neptune.tis.com Precedence: bulk In article <9602148268.AA826853770@snail.rsa.com>, Bob Baldwin baldwin@rsa.com wrote: > I have just submitted two informational RFCs to the Internet >Engineering Task Force that specify how the high performance RC5 cipher can >be used to add privacy to packets transmitted over the Internet. FYI: A previous conversation via email with Bob Baldwin seems to indicate that RSADSI claims intellectual property rights on RC5 in some countries. Ran rja@cisco.com Received: from relay.tis.com by neptune.TIS.COM id aa16280; 15 Mar 96 16:23 EST Received: by relay.tis.com; id QAA28446; Fri, 15 Mar 1996 16:25:39 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma028436; Fri, 15 Mar 96 16:25:19 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA24810; Fri, 15 Mar 96 16:24:07 EST Received: by relay.tis.com; id QAA28431; Fri, 15 Mar 1996 16:25:09 -0500 Received: from unknown(204.189.94.148) by relay.tis.com via smap (V3.1) id xma028412; Fri, 15 Mar 96 16:24:46 -0500 Received: by pilotx.firewall.is.chrysler.com; id QAA13799; Fri, 15 Mar 1996 16:25:43 -0500 Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilotx.is.chrysler.com via smap (g3.0.1) id sma013786; Fri, 15 Mar 96 16:25:41 -0500 Received: from [172.16.252.10] by clhubgw1.is.chrysler.com (5.x/SMI-4.1) id AB02763; Fri, 15 Mar 1996 16:27:38 -0500 Message-Id: <2.2.32.19960315212443.009b4a90@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 15 Mar 1996 16:24:43 -0500 To: Ran Atkinson , ipsec@TIS.COM From: Robert Moskowitz Subject: Re: A comment from the co-chair Cc: jis@mit.edu Sender: ipsec-request@neptune.tis.com Precedence: bulk At 11:46 AM 3/13/96 -0800, Ran Atkinson wrote: > > As none of the current Key Management proposals currently meet WG >requirements (though all could be modified to meet WG requirements), none >can proceed to Last Call or onto the Standards Track at this time. > Dear colleagues: Well you all know what I mean. I am sitting in the weekly AIAG (automotive industry action group) ANX meeting. I have given them an update of last week's events. Bottom line: I have been instructed to craft an AIAG letter placing a goal of this summer for "a" standard key management protocol. This will be the position of the whole automotive industry, not just one OEM. This letter will go to the lot of you and your senior management (for at least those companies that do major business with the auto industry). Many of you know my personal feelings. I have listened to your debates for some time now. At times I have wanted to say, "children, children...", but I have not as I respect each of your technical abilities. In this area, I recognize that I am just the student. Now all of you as the 'teachers' had better come together, quickly. If any special meetings are needed, within limits I can be available to attend (please avoid friday's and weekends, my family is up in arms about my extended absences ;) ). Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.tis.com by neptune.TIS.COM id aa17258; 15 Mar 96 17:08 EST Received: by relay.tis.com; id RAA29193; Fri, 15 Mar 1996 17:10:09 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma029189; Fri, 15 Mar 96 17:09:41 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA26192; Fri, 15 Mar 96 17:08:37 EST Received: by relay.tis.com; id RAA29184; Fri, 15 Mar 1996 17:09:39 -0500 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1) id xma029180; Fri, 15 Mar 96 17:09:21 -0500 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id RAA12369; Fri, 15 Mar 1996 17:10:16 -0500 (EST) Message-Id: <199603152210.RAA12369@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Ran Atkinson Cc: ipsec@TIS.COM Subject: Re: ESP transform with RC5 In-Reply-To: Your message of "Fri, 15 Mar 1996 12:26:23 PST." <199603152026.MAA02882@puli.cisco.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 15 Mar 1996 17:10:10 -0500 From: "Perry E. Metzger" Sender: ipsec-request@neptune.tis.com Precedence: bulk Ran Atkinson writes: > In article <9602148268.AA826853770@snail.rsa.com>, > Bob Baldwin baldwin@rsa.com wrote: > > > I have just submitted two informational RFCs to the Internet > >Engineering Task Force that specify how the high performance RC5 cipher can > >be used to add privacy to packets transmitted over the Internet. > > A previous conversation via email with Bob Baldwin seems to > indicate that RSADSI claims intellectual property rights on RC5 in some > countries. I'm curious as to whether these are being published as drafts or not; Baldwin lists these as "informational RFCs" rather than as "internet drafts". Perry Received: from relay.tis.com by neptune.TIS.COM id aa12879; 18 Mar 96 12:08 EST Received: by relay.tis.com; id IAA17945; Mon, 18 Mar 1996 08:50:29 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma017937; Mon, 18 Mar 96 08:50:05 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20850; Mon, 18 Mar 96 08:48:55 EST Received: by relay.tis.com; id IAA17934; Mon, 18 Mar 1996 08:49:58 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma017932; Mon, 18 Mar 96 08:49:54 -0500 Received: from pilotx.firewall.is.chrysler.com (copilot.is.chrysler.com) by interlock.ans.net with SMTP id AA15731 (InterLock SMTP Gateway 3.0 for ); Mon, 18 Mar 1996 08:50:55 -0500 Received: by pilotx.firewall.is.chrysler.com; id IAA03036; Mon, 18 Mar 1996 08:50:55 -0500 Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilotx.is.chrysler.com via smap (g3.0.1) id sma003002; Mon, 18 Mar 96 08:50:42 -0500 Received: from rgm3.is.chrysler.com by clhubgw1.is.chrysler.com (5.x/SMI-4.1) id AB08276; Mon, 18 Mar 1996 08:52:40 -0500 Message-Id: <2.2.32.19960318134906.00c0b448@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 18 Mar 1996 08:49:06 -0500 To: baldwin , ipsec@ans.net From: Robert Moskowitz Subject: Re: ESP transform with RC5 Cc: bretth@newbridge.com, "Robert W. Baldwin" , rivest@theory.lcs.mit.edu, Tim Matthews Sender: ipsec-request@neptune.tis.com Precedence: bulk At 05:36 PM 3/14/96 PST, baldwin wrote: >IPsec members, > I have just submitted two informational RFCs to the Internet >Engineering Task Force that specify how the high performance RC5 cipher can >be used to add privacy to packets transmitted over the Internet. This is the second time in the week that I have heard 'RC5', and have not heard it mentioned before this. I realize that many things happen in the crypto field that I do not see right away, but how recent is the introduction of RC5 to the broader crypto community? What review has it had? I ASSUME that it is a symetrical cypher; what are typical key lengths? And the strength of the cypher for a key length compared to other cyrphers: DES, IDEA, RC2, RC4, etc. Is the code in the draft sufficient for a full study? Is this thus a major deviation to RSA's handling of cyphers (compared to RC4, say). Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.tis.com by neptune.TIS.COM id aa13468; 18 Mar 96 12:43 EST Received: by relay.tis.com; id MAA22349; Mon, 18 Mar 1996 12:45:31 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma022344; Mon, 18 Mar 96 12:45:03 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08085; Mon, 18 Mar 96 12:43:57 EST Received: by relay.tis.com; id MAA22341; Mon, 18 Mar 1996 12:45:01 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma022335; Mon, 18 Mar 96 12:44:50 -0500 Received: from relay.hp.com by interlock.ans.net with SMTP id AA23533 (InterLock SMTP Gateway 3.0 for ); Mon, 18 Mar 1996 12:45:36 -0500 Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA232411081; Mon, 18 Mar 1996 09:44:42 -0800 Message-Id: <199603181744.AA232411081@relay.hp.com> Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com id AA146081356; Mon, 18 Mar 1996 12:49:16 -0500 X-Mailer: exmh version 1.6.2 7/18/95 To: Robert Moskowitz Cc: baldwin , ipsec@ans.net, bretth@newbridge.com, rivest@theory.lcs.mit.edu, Tim Matthews Subject: Re: ESP transform with RC5 In-Reply-To: rgm3's message of Mon, 18 Mar 1996 08:49:06 -0500. <2.2.32.19960318134906.00c0b448@pop3hub.is.chrysler.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 18 Mar 1996 12:44:41 -0500 From: Bill Sommerfeld Sender: ipsec-request@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii At 05:36 PM 3/14/96 PST, baldwin wrote: >IPsec members, > I have just submitted two informational RFCs to the Internet >Engineering Task Force that specify how the high performance RC5 cipher can >be used to add privacy to packets transmitted over the Internet. This is the second time in the week that I have heard 'RC5', and have not heard it mentioned before this. I realize that many things happen in the crypto field that I do not see right away, but how recent is the introduction of RC5 to the broader crypto community? ~1995 or thereabouts. This is a *very* new cipher, so it's not something I'd actually want to implement or use until it's had a lot more shakeout time. See Ron Rivest's publications web page: http://theory.lcs.mit.edu/~rivest/publications.html which contains: The RC5 Encryption Algorithm by Ronald L. Rivest. (To appear in Proceedings of the 1994 Leuven Workshop on Algorithms (Springer).) which is a link to: http://theory.lcs.mit.edu/~rivest/rc5.ps The source code included in the paper is "(C) 1995 RSA Data Security Inc.". - Bill -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMU2hAVpj/0M1dMJ/AQEpsgP+I2pvNx2bKdJjwMwNEbCwveKFAZspXSfH mFZ2kn8qL5+IGUoCHToA9bV69kdcfR5ThXWOHvU+YOD44xF718dkwmXli85op0r+ R0k9pCAR0DwNFJkw6drUpF0i6fv6oB20x2XCYH/XIfdaUpq/52VPqb7id0whFnH/ 8dVcspd9pew= =hYgq -----END PGP SIGNATURE----- Received: from relay.tis.com by neptune.TIS.COM id aa14467; 18 Mar 96 13:25 EST Received: by relay.tis.com; id NAA23036; Mon, 18 Mar 1996 13:27:32 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma023024; Mon, 18 Mar 96 13:27:04 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA00994; Mon, 18 Mar 96 13:25:57 EST Received: by relay.tis.com; id NAA23021; Mon, 18 Mar 1996 13:27:01 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma023010; Mon, 18 Mar 96 13:26:35 -0500 Received: from jekyll.piermont.com by interlock.ans.net with SMTP id AA24635 (InterLock SMTP Gateway 3.0 for ); Mon, 18 Mar 1996 13:27:36 -0500 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id NAA22704; Mon, 18 Mar 1996 13:26:55 -0500 (EST) Message-Id: <199603181826.NAA22704@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Robert Moskowitz Cc: baldwin , ipsec@ans.net Subject: Re: ESP transform with RC5 In-Reply-To: Your message of "Mon, 18 Mar 1996 08:49:06 EST." <2.2.32.19960318134906.00c0b448@pop3hub.is.chrysler.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 18 Mar 1996 13:26:45 -0500 From: "Perry E. Metzger" Sender: ipsec-request@neptune.tis.com Precedence: bulk Robert Moskowitz writes: > I realize that many things happen in the crypto field that I do not see > right away, but how recent is the introduction of RC5 to the broader crypto > community? Fairly recent. RC5 is a proprietary algorithm owned by (who else) RSA Data Security Inc. > What review has it had? A little; not what I'd call "strong review" the way that, say, 3DES has had. I don't want to demean its creators, but in general one wants to let these things be examined for quite a while before one trusts them. Perry Received: from relay.tis.com by neptune.TIS.COM id aa14796; 18 Mar 96 13:36 EST Received: by relay.tis.com; id NAA23392; Mon, 18 Mar 1996 13:38:20 -0500 From: touch@isi.edu MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma023383; Mon, 18 Mar 96 13:37:52 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01388; Mon, 18 Mar 96 13:36:46 EST Received: by relay.tis.com; id NAA23380; Mon, 18 Mar 1996 13:37:50 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma023368; Mon, 18 Mar 96 13:37:35 -0500 Received: from venera.isi.edu by interlock.ans.net with SMTP id AA25015 (InterLock SMTP Gateway 3.0 for ); Mon, 18 Mar 1996 13:38:32 -0500 Received: from ash-s.isi.edu (ash-a.isi.edu) by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 18 Mar 1996 10:37:24 -0800 Date: Mon, 18 Mar 1996 10:33:53 -0800 Posted-Date: Mon, 18 Mar 1996 10:33:53 -0800 Message-Id: <199603181833.AA04929@ash-s.isi.edu> Received: by ash-s.isi.edu (5.65c/4.0.3-4) id ; Mon, 18 Mar 1996 10:33:53 -0800 To: rgm3@is.chrysler.com, sommerfeld@apollo.hp.com Subject: Re: ESP transform with RC5 Cc: baldwin@rsa.com, ipsec@ans.net, bretth@newbridge.com, rivest@theory.lcs.mit.edu, tim@rsa.com X-Auto-Sig-Adder-By: faber@isi.edu Sender: ipsec-request@neptune.tis.com Precedence: bulk > From: Bill Sommerfeld > > At 05:36 PM 3/14/96 PST, baldwin wrote: > >IPsec members, > > I have just submitted two informational RFCs to the Internet > >Engineering Task Force that specify how the high performance RC5 cipher can > > >be used to add privacy to packets transmitted over the Internet. > > This is the second time in the week that I have heard 'RC5', and have not > heard it mentioned before this. > > I realize that many things happen in the crypto field that I do not see > right away, but how recent is the introduction of RC5 to the broader crypto > community? > > ~1995 or thereabouts. This is a *very* new cipher, so it's not > something I'd actually want to implement or use until it's had a > lot more shakeout time. > FYI - the algorithm is based on data-dependent rotates. Not to beat a dead horse, but rotates can take anywhere from 3-5 operations on a RISC (which typically don't have rotates), and data-dependent rotates can double that. Joe ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/ Received: from relay.tis.com by neptune.TIS.COM id aa15016; 18 Mar 96 13:41 EST Received: by relay.tis.com; id NAA23526; Mon, 18 Mar 1996 13:43:50 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma023520; Mon, 18 Mar 96 13:43:23 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01520; Mon, 18 Mar 96 13:42:17 EST Received: by relay.tis.com; id NAA23512; Mon, 18 Mar 1996 13:43:21 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma023491; Mon, 18 Mar 96 13:42:53 -0500 Received: from jekyll.piermont.com by interlock.ans.net with SMTP id AA25267 (InterLock SMTP Gateway 3.0 for ); Mon, 18 Mar 1996 13:43:54 -0500 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id NAA22734; Mon, 18 Mar 1996 13:42:24 -0500 (EST) Message-Id: <199603181842.NAA22734@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Bill Sommerfeld Cc: Robert Moskowitz , ipsec@ans.net Subject: Re: ESP transform with RC5 In-Reply-To: Your message of "Mon, 18 Mar 1996 12:44:41 EST." <199603181744.AA232411081@relay.hp.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 18 Mar 1996 13:42:11 -0500 From: "Perry E. Metzger" Sender: ipsec-request@neptune.tis.com Precedence: bulk Bill Sommerfeld writes: > I realize that many things happen in the crypto field that I do > not see right away, but how recent is the introduction of RC5 to > the broader crypto community? > > ~1995 or thereabouts. This is a *very* new cipher, so it's not > something I'd actually want to implement or use until it's had a > lot more shakeout time. Just for context for everyone, the RSA DSI folks are (or at least, were) attempting to push this thing they call S/WAN, which is basically IPsec using RC5 to make it into something proprietary that RSA DSI has a patent on and thus gets royalties for. It doesn't have any real advantages to anyone other than RSA DSI, which has an obvious stake in its widespread deployment... Perry Received: from relay.tis.com by neptune.TIS.COM id aa15607; 18 Mar 96 14:07 EST Received: by relay.tis.com; id OAA24003; Mon, 18 Mar 1996 14:09:51 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma023997; Mon, 18 Mar 96 14:09:22 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02608; Mon, 18 Mar 96 14:08:16 EST Received: by relay.tis.com; id OAA23985; Mon, 18 Mar 1996 14:09:21 -0500 Received: from unknown(192.86.155.81) by relay.tis.com via smap (V3.1) id xma023964; Mon, 18 Mar 96 14:08:51 -0500 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id LAA11118; Mon, 18 Mar 1996 11:09:46 -0800 Received: by mailsun2.us.oracle.com (8.7.1/37.8) id LAA03544; Mon, 18 Mar 1996 11:12:13 -0800 (PST) Message-Id: <199603181912.LAA03544@mailsun2.us.oracle.com> Date: 18 Mar 96 11:04:40 -0800 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: Re: ESP transform with RC5 Mime-Version: 1.0 Sender: ipsec-request@neptune.tis.com Precedence: bulk Bob, >Is this thus a major deviation to RSA's handling of >cyphers (compared to RC4, say). Major, maybe. Different, yes: Algorithm Intellectual Property Protection ------------------------------------------------------- RC4 Trade Secret RC5 Patent (applied for?) IDEA Patent DES Open Does anyone have the patent numbers for RC5 and IDEA? Paul -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com -------------------------------------------------------------- Received: from relay.tis.com by neptune.TIS.COM id aa15929; 18 Mar 96 14:15 EST Received: by relay.tis.com; id OAA24258; Mon, 18 Mar 1996 14:17:51 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma024251; Mon, 18 Mar 96 14:17:25 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03022; Mon, 18 Mar 96 14:16:17 EST Received: by relay.tis.com; id OAA24243; Mon, 18 Mar 1996 14:17:21 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma024237; Mon, 18 Mar 96 14:17:03 -0500 Received: from pilot.firewall.is.chrysler.com (pilot.is.chrysler.com) by interlock.ans.net with SMTP id AA26499 (InterLock SMTP Gateway 3.0 for ); Mon, 18 Mar 1996 14:17:52 -0500 Received: by pilot.firewall.is.chrysler.com; id OAA08008; Mon, 18 Mar 1996 14:17:53 -0500 Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilot.is.chrysler.com via smap (g3.0.1) id sma007990; Mon, 18 Mar 96 14:17:28 -0500 Received: from rgm3 (rgm3.is.chrysler.com) by clhubgw1.is.chrysler.com (5.x/SMI-4.1) id AA13344; Mon, 18 Mar 1996 14:19:25 -0500 Message-Id: <2.2.32.19960318191550.00ab667c@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 18 Mar 1996 14:15:50 -0500 To: touch@isi.edu, sommerfeld@apollo.hp.com From: Robert Moskowitz Subject: Re: ESP transform with RC5 Cc: baldwin@rsa.com, ipsec@ans.net, bretth@newbridge.com, rivest@theory.lcs.mit.edu, tim@rsa.com Sender: ipsec-request@neptune.tis.com Precedence: bulk At 10:33 AM 3/18/96 -0800, touch@ISI.EDU wrote: >> ~1995 or thereabouts. This is a *very* new cipher, so it's not >> something I'd actually want to implement or use until it's had a >> lot more shakeout time. >> > >FYI - the algorithm is based on data-dependent rotates. >Not to beat a dead horse, but rotates can take anywhere >from 3-5 operations on a RISC (which typically don't >have rotates), and data-dependent rotates can double that. Joe, Sorry for my inability to parse your words, but Are you saying that: A) RC5 is not high performance on a RISC or B) RC5 is relatively easy to brute strength attack on a RISC. Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.tis.com by neptune.TIS.COM id aa16676; 18 Mar 96 14:40 EST Received: by relay.tis.com; id OAA24720; Mon, 18 Mar 1996 14:42:21 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma024718; Mon, 18 Mar 96 14:41:53 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA04384; Mon, 18 Mar 96 14:40:47 EST Received: by relay.tis.com; id OAA24705; Mon, 18 Mar 1996 14:41:51 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma024695; Mon, 18 Mar 96 14:41:40 -0500 Received: from optima.CS.Arizona.EDU by interlock.ans.net with SMTP id AA27371 (InterLock SMTP Gateway 3.0 for ); Mon, 18 Mar 1996 14:42:42 -0500 Received: from uncial.CS.Arizona.EDU by optima.cs.arizona.edu (5.65c/15) via SMTP id AA15064; Mon, 18 Mar 1996 12:42:38 MST Received: by uncial.CS.Arizona.EDU; (5.65/1.1.8.2/08Nov94-0446PM) id AA12798; Mon, 18 Mar 1996 12:42:34 -0700 Date: Mon, 18 Mar 1996 12:42:34 -0700 From: Hilarie Orman Message-Id: <9603181942.AA12798@uncial.CS.Arizona.EDU> To: rgm3@is.chrysler.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <2.2.32.19960318134906.00c0b448@pop3hub.is.chrysler.com> Subject: Re: ESP transform with RC5 Sender: ipsec-request@neptune.tis.com Precedence: bulk > I realize that many things happen in the crypto field that I do not see > right away, but how recent is the introduction of RC5 to the broader crypto > community? Was being distributed on the net in 1994; published Dr. Dobb's Journal, January 1995 > What review has it had? See Crypto '95 proceedings; Kaliski has a paper about it. > Is the code in the draft sufficient for a full study? Yes, it's a very short algorithm, full source code is available, and it's probably easier to understand it by reading the code than a description of it. Received: from relay.tis.com by neptune.TIS.COM id aa17065; 18 Mar 96 14:55 EST Received: by relay.tis.com; id OAA25060; Mon, 18 Mar 1996 14:57:51 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma025053; Mon, 18 Mar 96 14:57:26 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA05382; Mon, 18 Mar 96 14:56:16 EST Received: by relay.tis.com; id OAA25046; Mon, 18 Mar 1996 14:57:21 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma025022; Mon, 18 Mar 96 14:56:51 -0500 Received: from internet.milkyway.com (milkyway.com) by interlock.ans.net with SMTP id AA27842 (InterLock SMTP Gateway 3.0 for ); Mon, 18 Mar 1996 14:57:41 -0500 Received: from jupiter.milkyway.com (jupiter.milkyway.com [192.168.77.9]) by internet with ESMTP (DuhMail/2.0) id OAA08761; Mon, 18 Mar 1996 14:51:15 -0500 Received: from milkyway.com (root@metis.milkyway.com [192.168.77.21]) by jupiter.milkyway.com (8.6.12/8.6.12) with ESMTP id OAA13040 for ; Mon, 18 Mar 1996 14:51:47 -0500 Received: from metis.milkyway.com by milkyway.com (8.6.12/BSDI-Client) id PAA03185; Mon, 18 Mar 1996 15:01:52 -0500 Message-Id: <199603182001.PAA03185@milkyway.com> X-Mailer: exmh version 1.6.4 10/10/95 X-Face: x7OynEM*dB$e.2'7pigelLk>5:Nu:%r*iV96{F2XIT.apbrc-vOFSi{yI$3=nJ-Qi)allj4 =)4cWlX@IQ1Dsmk}T4qX~{XI5Z01>PV^cYR'~cL]&ma<{rYg~Ao-:~:sM%z}^M65`;1TZ}Tze"4/=F ~o&8;"SKHwB?%"xpP/=pkhdZVP$rQQ{"{QT`#kcx7!\/y+crQa4^nLEms6_k4O*o#fo[WBs~~&.%jf |;W@E2K#{U~%vhvth^uDLWD` In-Reply-To: Your message of "Mon, 18 Mar 1996 13:42:11 EST." <199603181842.NAA22734@jekyll.piermont.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Mar 1996 15:01:51 -0500 From: Michael Richardson Sender: ipsec-request@neptune.tis.com Precedence: bulk In a galaxy far, far away, perry@piermont.com said: > Just for context for everyone, the RSA DSI folks are (or at least, > were) attempting to push this thing they call S/WAN, which is > basically IPsec using RC5 to make it into something proprietary that > RSA DSI has a patent on and thus gets royalties for. It doesn't have > any real advantages to anyone other than RSA DSI, which has an obvious For a little more context: the RSA folks got most of the firewall vendors together last August to discuss RSA DSI and firewalls. We had a problem: we needed to interoperate on virtual private network technology, particularly when it came to road-warrior notebooks. We agreed that swipe and SKIP were interesting, but that the firewall vendors had to implement something that the PC/Mac stack vendors were going to implement. Thus S/WAN was born. Just take the then current ipsec, nail some parameters down, and take the first step. The various vendors didn't really have anyone that they felt could coordinate their efforts. While RSA Data Systems isn't a dis-interested party, at least they are non-firewall-vendor aligned: we know what their interests are. -- mcr@milkyway.com | Milkyway Networks Corporation Michael C. Richardson | Makers of the Black Hole firewall Senior Research Specialist | info@milkyway.com for BlackHole questions Home: mcr@sandelman.ocunix.on.ca. Received: from relay.tis.com by neptune.TIS.COM id aa18899; 18 Mar 96 16:06 EST Received: by relay.tis.com; id QAA27088; Mon, 18 Mar 1996 16:08:51 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma027075; Mon, 18 Mar 96 16:08:23 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA09576; Mon, 18 Mar 96 16:07:17 EST Received: by relay.tis.com; id QAA27067; Mon, 18 Mar 1996 16:08:22 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma027061; Mon, 18 Mar 96 16:07:54 -0500 Received: from jekyll.piermont.com by interlock.ans.net with SMTP id AA00304 (InterLock SMTP Gateway 3.0 for ); Mon, 18 Mar 1996 16:08:50 -0500 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id QAA22956; Mon, 18 Mar 1996 16:08:29 -0500 (EST) Message-Id: <199603182108.QAA22956@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Michael Richardson Cc: ipsec@ans.net Subject: Re: ESP transform with RC5 In-Reply-To: Your message of "Mon, 18 Mar 1996 15:01:51 EST." <199603182001.PAA03185@milkyway.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 18 Mar 1996 16:08:28 -0500 From: "Perry E. Metzger" Sender: ipsec-request@neptune.tis.com Precedence: bulk Michael Richardson writes: > For a little more context: the RSA folks got most of the firewall vendors > together last August to discuss RSA DSI and firewalls. We had a problem: we > needed to interoperate on virtual private network technology, particularly > when it came to road-warrior notebooks. We agreed that swipe and SKIP were > interesting, but that the firewall vendors had to implement something that > the PC/Mac stack vendors were going to implement. Er, there is perhaps a misperception here. swIPe was a long dead experiment. SKIP is a key management protocol, which fits in the same place in the stack as Photuris or Oakley. We already had perfectly good IPsec transforms written and in place, by the way. > Thus S/WAN was born. Just take the then current ipsec, nail some parameters > down, and take the first step. The only difference I can see between IPsec and S/WAN is that S/WAN uses RC5 instead of something like 3DES. Can you correct me on this? > The various vendors didn't really have anyone that they felt could > coordinate their efforts. The IETF, perhaps? Perry Received: from relay.tis.com by neptune.TIS.COM id aa19293; 18 Mar 96 16:25 EST Received: by relay.tis.com; id QAA27568; Mon, 18 Mar 1996 16:27:22 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma027532; Mon, 18 Mar 96 16:26:53 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10749; Mon, 18 Mar 96 16:25:47 EST Received: by relay.tis.com; id QAA27528; Mon, 18 Mar 1996 16:26:51 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma027522; Mon, 18 Mar 96 16:26:44 -0500 Received: from internet.milkyway.com (milkyway.com) by interlock.ans.net with SMTP id AA00833 (InterLock SMTP Gateway 3.0 for ); Mon, 18 Mar 1996 16:27:39 -0500 Received: from jupiter.milkyway.com (jupiter.milkyway.com [192.168.77.9]) by internet with ESMTP (DuhMail/2.0) id QAA09636; Mon, 18 Mar 1996 16:21:17 -0500 Received: from milkyway.com (root@metis.milkyway.com [192.168.77.21]) by jupiter.milkyway.com (8.6.12/8.6.12) with ESMTP id QAA15963; Mon, 18 Mar 1996 16:22:47 -0500 Received: from metis.milkyway.com by milkyway.com (8.6.12/BSDI-Client) id QAA06003; Mon, 18 Mar 1996 16:32:53 -0500 Message-Id: <199603182132.QAA06003@milkyway.com> X-Mailer: exmh version 1.6.4 10/10/95 X-Face: x7OynEM*dB$e.2'7pigelLk>5:Nu:%r*iV96{F2XIT.apbrc-vOFSi{yI$3=nJ-Qi)allj4 =)4cWlX@IQ1Dsmk}T4qX~{XI5Z01>PV^cYR'~cL]&ma<{rYg~Ao-:~:sM%z}^M65`;1TZ}Tze"4/=F ~o&8;"SKHwB?%"xpP/=pkhdZVP$rQQ{"{QT`#kcx7!\/y+crQa4^nLEms6_k4O*o#fo[WBs~~&.%jf |;W@E2K#{U~%vhvth^uDLWD` In-Reply-To: Your message of "Mon, 18 Mar 1996 16:08:28 EST." <199603182108.QAA22956@jekyll.piermont.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Mar 1996 16:32:51 -0500 From: Michael Richardson Sender: ipsec-request@neptune.tis.com Precedence: bulk In a galaxy far, far away, : Mon, 18 Mar 1996 16:08:28 EST > swIPe was a long dead experiment. SKIP is a key management protocol, > which fits in the same place in the stack as Photuris or Oakley. This was August 1995. Vendors wanted to interoperate *soon* swIPe was on the list because it was out there. SKIP as implemented by SunScreen (not IPsec based) was also out there. Neither had any likelyhood of being found on a 4Mb 486/33 running Win3.11. > We already had perfectly good IPsec transforms written and in place, > by the way. Yes. Which is why the other "options" were quickly discarded. > The only difference I can see between IPsec and S/WAN is that S/WAN > uses RC5 instead of something like 3DES. Can you correct me on this? The original "spec" said MD5 and DES. RSA quickly added RC5. Whether or not anyone actually tested that I don't remember. > The IETF, perhaps? :-) That was my suggestion actually. In the end, we (Milkyway Networks) didn't have the scheduling flexibility to come up with anything to test. Our current VPN is Entrust based. -- mcr@milkyway.com | Milkyway Networks Corporation Michael C. Richardson | Makers of the Black Hole firewall Senior Research Specialist | info@milkyway.com for BlackHole questions Home: mcr@sandelman.ocunix.on.ca. Received: from relay.tis.com by neptune.TIS.COM id aa19603; 18 Mar 96 16:34 EST Received: by relay.tis.com; id QAA27858; Mon, 18 Mar 1996 16:36:23 -0500 From: stroh@vnet.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma027841; Mon, 18 Mar 96 16:35:55 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA11272; Mon, 18 Mar 96 16:34:49 EST Received: by relay.tis.com; id QAA27834; Mon, 18 Mar 1996 16:35:53 -0500 Received: from unknown(147.225.5.2) by relay.tis.com via smap (V3.1) id xma027828; Mon, 18 Mar 96 16:35:51 -0500 Received: from vnet.ibm.com by interlock.ans.net with SMTP id AA01123 (InterLock SMTP Gateway 3.0 for ); Mon, 18 Mar 1996 16:36:50 -0500 Message-Id: <199603182136.AA01123@interlock.ans.net> Received: from AUSVM6.VNET.IBM.COM by vnet.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 8525; Mon, 18 Mar 96 16:36:29 EST Date: Mon, 18 Mar 96 16:36:29 EST To: ipsec@ans.net Subject: Re: ESP transform with RC5 Sender: ipsec-request@neptune.tis.com Precedence: bulk *** Reply to note of 03/18/96 14:06 >From the desk of: IBM Internal Use Only SUBJECT: Re: ESP transform with RC5 Re: absence of rotate on RISC processors Do you mean that an encryption algorithm must not be chosen which uses rotates because RISC processors don't have them, and everyone knows it? (dead horse - argued to death, well decided ) This is not well decided. Its invalid. The RS6000 / PowerPC has single instruction variable count rotates which work in a single cycle. This cycle is likely to be overlapped with something else like I/O and disappear. Even other superscalar RISC processors which do not could still parallelize the sub-operations to some extent and overlap them with I/O. The pentium and 486 have rotate instructions but they are many cycle instructions. Presumably they don't use a barrel shifter. regards, Oscar Strohacker Advisory Engineer/Scientist Data Compression Systems Architecture IBM Microelectronics Division 11400 Burnet Road Austin Texas 78758 o (512) 838-4077 f (512) 838-7004 Internet: stroh @ vnet.ibm.com Received: from relay.tis.com by neptune.TIS.COM id aa19772; 18 Mar 96 16:41 EST Received: by relay.tis.com; id QAA28126; Mon, 18 Mar 1996 16:43:53 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma028109; Mon, 18 Mar 96 16:43:24 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA11753; Mon, 18 Mar 96 16:42:19 EST Received: by relay.tis.com; id QAA28106; Mon, 18 Mar 1996 16:43:23 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma028101; Mon, 18 Mar 96 16:43:15 -0500 Received: from jekyll.piermont.com by interlock.ans.net with SMTP id AA01298 (InterLock SMTP Gateway 3.0 for ); Mon, 18 Mar 1996 16:44:17 -0500 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id QAA23018; Mon, 18 Mar 1996 16:44:05 -0500 (EST) Message-Id: <199603182144.QAA23018@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Michael Richardson Cc: ipsec@ans.net Subject: Re: ESP transform with RC5 In-Reply-To: Your message of "Mon, 18 Mar 1996 16:32:51 EST." <199603182132.QAA06003@milkyway.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 18 Mar 1996 16:44:04 -0500 From: "Perry E. Metzger" Sender: ipsec-request@neptune.tis.com Precedence: bulk I want to make it clear in advance that I'm not trying to be hostile here. E-Mail often removes niceties like facial expression. I'm more trying to figure out what was going on at RSA DSI than anything else. Michael Richardson writes: > In a galaxy far, far away, : Mon, 18 Mar 1996 16:08:28 EST > > swIPe was a long dead experiment. SKIP is a key management protocol, > > which fits in the same place in the stack as Photuris or Oakley. > > This was August 1995. Vendors wanted to interoperate *soon* August 1995 was after the IPsec documents had gone to RFC (indeed, the documents are dated August, 1995). They had long since been in last call and were very stable. You have apparently been misinformed about the timing of our efforts. > swIPe was on the list because it was out there. Actually it wasn't out there any longer; it had more or less been informally withdrawn long before, after the Toronto IETF as I recall. It was just an experiment. > SKIP as implemented by SunScreen (not IPsec based) was also out there. Actually SKIP *is* IPsec based (though I've had interoperation disputes with the SKIP people). > > We already had perfectly good IPsec transforms written and in place, > > by the way. > > Yes. Which is why the other "options" were quickly discarded. > > > The only difference I can see between IPsec and S/WAN is that S/WAN > > uses RC5 instead of something like 3DES. Can you correct me on this? > > The original "spec" said MD5 and DES. RSA quickly added RC5. Why did they have a "spec" at all when we had RFC's 1825-1829 already out? This all strikes me as odd. Perry Received: from relay.tis.com by neptune.TIS.COM id aa20142; 18 Mar 96 16:59 EST Received: by relay.tis.com; id RAA28598; Mon, 18 Mar 1996 17:01:23 -0500 From: touch@isi.edu MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma028596; Mon, 18 Mar 96 17:00:54 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA12850; Mon, 18 Mar 96 16:59:48 EST Received: by relay.tis.com; id RAA28593; Mon, 18 Mar 1996 17:00:53 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma028591; Mon, 18 Mar 96 17:00:27 -0500 Received: from venera.isi.edu by interlock.ans.net with SMTP id AA01869 (InterLock SMTP Gateway 3.0 for ); Mon, 18 Mar 1996 17:01:28 -0500 Received: from ash-s.isi.edu (ash-a.isi.edu) by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 18 Mar 1996 13:56:08 -0800 Date: Mon, 18 Mar 1996 13:52:33 -0800 Posted-Date: Mon, 18 Mar 1996 13:52:33 -0800 Message-Id: <199603182152.AA05148@ash-s.isi.edu> Received: by ash-s.isi.edu (5.65c/4.0.3-4) id ; Mon, 18 Mar 1996 13:52:33 -0800 To: touch@isi.edu, sommerfeld@apollo.hp.com, rgm3@is.chrysler.com Subject: Re: ESP transform with RC5 Cc: baldwin@rsa.com, ipsec@ans.net, bretth@newbridge.com, rivest@theory.lcs.mit.edu, tim@rsa.com X-Auto-Sig-Adder-By: faber@isi.edu Sender: ipsec-request@neptune.tis.com Precedence: bulk > From: Robert Moskowitz > Subject: Re: ESP transform with RC5 > > At 10:33 AM 3/18/96 -0800, touch@ISI.EDU wrote: > > >> ~1995 or thereabouts. This is a *very* new cipher, so it's not > >> something I'd actually want to implement or use until it's had a > >> lot more shakeout time. > >> > > > >FYI - the algorithm is based on data-dependent rotates. > >Not to beat a dead horse, but rotates can take anywhere > >from 3-5 operations on a RISC (which typically don't > >have rotates), and data-dependent rotates can double that. > > Joe, > > Sorry for my inability to parse your words, but > > Are you saying that: > > A) RC5 is not high performance on a RISC This. I suspect it is just "not high performance", period. Joe ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/ Received: from relay.tis.com by neptune.TIS.COM id aa20528; 18 Mar 96 17:13 EST Received: by relay.tis.com; id RAA28888; Mon, 18 Mar 1996 17:15:23 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma028874; Mon, 18 Mar 96 17:14:55 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13573; Mon, 18 Mar 96 17:13:49 EST Received: by relay.tis.com; id RAA28868; Mon, 18 Mar 1996 17:14:53 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma028864; Mon, 18 Mar 96 17:14:40 -0500 Received: from internet.milkyway.com (milkyway.com) by interlock.ans.net with SMTP id AA02281 (InterLock SMTP Gateway 3.0 for ); Mon, 18 Mar 1996 17:15:39 -0500 Received: from jupiter.milkyway.com (jupiter.milkyway.com [192.168.77.9]) by internet with ESMTP (DuhMail/2.0) id RAA10228; Mon, 18 Mar 1996 17:10:44 -0500 Received: from milkyway.com (root@metis.milkyway.com [192.168.77.21]) by jupiter.milkyway.com (8.6.12/8.6.12) with ESMTP id RAA17292 for ; Mon, 18 Mar 1996 17:12:30 -0500 Received: from metis.milkyway.com by milkyway.com (8.6.12/BSDI-Client) id RAA10425; Mon, 18 Mar 1996 17:22:37 -0500 Message-Id: <199603182222.RAA10425@milkyway.com> X-Mailer: exmh version 1.6.4 10/10/95 X-Face: x7OynEM*dB$e.2'7pigelLk>5:Nu:%r*iV96{F2XIT.apbrc-vOFSi{yI$3=nJ-Qi)allj4 =)4cWlX@IQ1Dsmk}T4qX~{XI5Z01>PV^cYR'~cL]&ma<{rYg~Ao-:~:sM%z}^M65`;1TZ}Tze"4/=F ~o&8;"SKHwB?%"xpP/=pkhdZVP$rQQ{"{QT`#kcx7!\/y+crQa4^nLEms6_k4O*o#fo[WBs~~&.%jf |;W@E2K#{U~%vhvth^uDLWD` In-Reply-To: Your message of "Mon, 18 Mar 1996 16:44:04 EST." <199603182144.QAA23018@jekyll.piermont.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Mar 1996 17:22:36 -0500 From: Michael Richardson Sender: ipsec-request@neptune.tis.com Precedence: bulk In a galaxy far, far away, : Mon, 18 Mar 1996 16:44:04 EST > > This was August 1995. Vendors wanted to interoperate *soon* > > August 1995 was after the IPsec documents had gone to RFC (indeed, the > documents are dated August, 1995). They had long since been in last Again, I'm reporting what was discussed. I don't think the timing of the RFCs has much to do with what has been implemented and what has not been implemented. Why was swIPe on the table? I believe that TIS and Raptor have firewalls out their in the field running it. Why was SKIP on the table (and yes, there *is* a pre-IPsec version)? Sun was there talking about it. They *said* there were two versions that that the IPsec version was being worked on as they spoke. > Actually it wasn't out there any longer; it had more or less been > informally withdrawn long before, after the Toronto IETF as I > recall. It was just an experiment. S/WAN is *not* a proposed IETF standard. It is a set of parameters that explains how to interoperate *today*. We could have picked swIPe, for instance. > Why did they have a "spec" at all when we had RFC's 1825-1829 already > out? This all strikes me as odd. The 'spec' is says what S/WAN is going to test. I'd call it a "test spec" more than a design spec. I don't recall discussion about RC4 or RC5 from other than RSA people. But, again, we were pretty clear about what there interests were. Received: from relay.tis.com by neptune.TIS.COM id aa21034; 18 Mar 96 17:33 EST Received: by relay.tis.com; id RAA29336; Mon, 18 Mar 1996 17:35:53 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma029334; Mon, 18 Mar 96 17:35:25 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA14701; Mon, 18 Mar 96 17:34:19 EST Received: by relay.tis.com; id RAA29331; Mon, 18 Mar 1996 17:35:23 -0500 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1) id xma029329; Mon, 18 Mar 96 17:35:12 -0500 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id OAA07192; Mon, 18 Mar 1996 14:36:12 -0800 Received: by mailsun2.us.oracle.com (8.7.1/37.8) id OAA02871; Mon, 18 Mar 1996 14:38:34 -0800 (PST) Message-Id: <199603182238.OAA02871@mailsun2.us.oracle.com> Date: 18 Mar 96 14:22:48 -0800 From: "PALAMBER.US.ORACLE.COM" To: perry@piermont.com Subject: Re: ESP transform with RC5 Cc: ipsec@TIS.COM X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:perry@piermont.com's message of 18-Mar-96 15:12 Mime-Version: 1.0 Sender: ipsec-request@neptune.tis.com Precedence: bulk Perry, Please be fair. >No fee for the use of the patent in free software, >for example, and they don't attempt to assert >rights when they have none. RSA hasn't shown the >same sort of behavior. RSA to their credit has published RSAREF for free non-commercial usage. The IETF process must support the definition of technologies that can be produced by vendors for a profit. Selecting technologies that have no fee for free software limits the creation of "commercial" software. While we all may not like to pay for patented technologies, this mailing list is not an appropriate forum to attack companies attempting to make money on their inventions. Where we can in the standards process we should avoid patented technologies. Where patents are unavoidable or provide significant advantages the working group they are acceptable only when available with a "reasonable" and non-exclusive license. Paul -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com -------------------------------------------------------------- Received: from relay.tis.com by neptune.TIS.COM id aa21141; 18 Mar 96 17:38 EST Received: by relay.tis.com; id RAA29438; Mon, 18 Mar 1996 17:40:24 -0500 From: touch@isi.edu MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma029431; Mon, 18 Mar 96 17:39:56 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA14853; Mon, 18 Mar 96 17:38:50 EST Received: by relay.tis.com; id RAA29418; Mon, 18 Mar 1996 17:39:54 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma029408; Mon, 18 Mar 96 17:39:31 -0500 Received: from venera.isi.edu by interlock.ans.net with SMTP id AA03062 (InterLock SMTP Gateway 3.0 for ); Mon, 18 Mar 1996 17:40:32 -0500 Received: from ash-s.isi.edu (ash-a.isi.edu) by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 18 Mar 1996 14:40:29 -0800 Date: Mon, 18 Mar 1996 14:36:58 -0800 Posted-Date: Mon, 18 Mar 1996 14:36:58 -0800 Message-Id: <199603182236.AA05238@ash-s.isi.edu> Received: by ash-s.isi.edu (5.65c/4.0.3-4) id ; Mon, 18 Mar 1996 14:36:58 -0800 To: ipsec@ans.net, stroh@vnet.ibm.com Subject: Re: ESP transform with RC5 Cc: touch@isi.edu X-Auto-Sig-Adder-By: faber@isi.edu Sender: ipsec-request@neptune.tis.com Precedence: bulk > From: stroh@vnet.ibm.com > Re: absence of rotate on RISC processors > Do you mean that an encryption algorithm must not be chosen which > uses rotates because RISC processors don't have them, and everyone > knows it? > (dead horse - argued to death, well decided ) No. Only that variable-count rotates are not one-cycle opcodes on many processors, and that their use can substantially affect performance of the algorithm. > This is not well decided. Its invalid. The RS6000 / PowerPC has > single instruction variable count rotates which work in a single cycle. SPARC and MIPS don't. Alphas do, but only for 32-bit operands (by doubling the data and shifting it within 64-bit registers). > Even other superscalar RISC processors which do not could still > parallelize the sub-operations to some extent and overlap them > with I/O. Only if the computation is I/O intensive. Authentication and encryption algorithms tend to be compute-intensive, and the one's I've had a chance to look at are also highly linear. The result is that the computations don't overlap at all, and that the number of clocks per basic operation affects the overall algorithm performance. The Sigcomm paper on MD5 ('95) indicated ways to design algorithms which could be computationally efficient, both in hardware and in software. Data-dependent rotates are not one of those ways. Joe > > The pentium and 486 have rotate instructions but they are many > cycle instructions. Presumably they don't use a barrel shifter. ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/ Received: from relay.tis.com by neptune.TIS.COM id aa22581; 18 Mar 96 18:47 EST Received: by relay.tis.com; id SAA00199; Mon, 18 Mar 1996 18:49:24 -0500 From: smb@research.att.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma000192; Mon, 18 Mar 96 18:48:54 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16420; Mon, 18 Mar 96 18:47:49 EST Received: by relay.tis.com; id SAA00189; Mon, 18 Mar 1996 18:48:53 -0500 Message-Id: <199603182348.SAA00189@relay.tis.com> Received: from unknown(192.20.225.4) by relay.tis.com via smap (V3.1) id xma000185; Mon, 18 Mar 96 18:48:29 -0500 Received: from research.att.com by ns; Mon Mar 18 18:46:59 EST 1996 Received: from gryphon by research; Mon Mar 18 18:42:30 EST 1996 Received: by gryphon; Mon Mar 18 18:42:24 EST 1996 To: "PALAMBER.US.ORACLE.COM" Cc: perry@piermont.com, ipsec@TIS.COM Subject: Re: ESP transform with RC5 Date: Mon, 18 Mar 96 18:42:23 EST Sender: ipsec-request@neptune.tis.com Precedence: bulk The IETF process must support the definition of technologies that can e produced by vendors for a profit. Since this is an informational RFC in any event, it doesn't matter much. RFC 1602 puts certain restrictions on standards-track RFCs; it says nothing whatsoever about patents and non-standards documents. It's also worth noting that RC5 poses some interesting technical issues. For example, it is parameterized, and none of the key management mechanisms we are considering seem to support that. Possibly, the parameters could be encoded as part of the key -- but we're moving down a track in which keys are true-random numbers. Besides, it may be necessary to negotiate some of the parameters under certain circumstances -- some folks may only have 40-bit RC5 implementations available to them, for the usual obvious reasons. Received: from relay.tis.com by neptune.TIS.COM id aa24431; 18 Mar 96 20:26 EST Received: by relay.tis.com; id UAA00926; Mon, 18 Mar 1996 20:28:26 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma000924; Mon, 18 Mar 96 20:27:57 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18470; Mon, 18 Mar 96 20:26:51 EST Received: by relay.tis.com; id UAA00919; Mon, 18 Mar 1996 20:27:56 -0500 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1) id xma000915; Mon, 18 Mar 96 20:27:34 -0500 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id RAA23395; Mon, 18 Mar 1996 17:28:32 -0800 Received: by mailsun2.us.oracle.com (8.7.1/37.8) id RAA25111; Mon, 18 Mar 1996 17:31:00 -0800 (PST) Message-Id: <199603190131.RAA25111@mailsun2.us.oracle.com> Date: 18 Mar 96 17:05:58 -0800 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: Re: ESP transform with RC5 X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-request@neptune.tis.com's message of 18-Mar-96 17:22 Mime-Version: 1.0 Sender: ipsec-request@neptune.tis.com Precedence: bulk >From: Michael Richardson <.... > Again, I'm reporting what was discussed. <... stuff removed > Why was swIPe on the table? < ... etc. .. I am not sure where the discussion is going in trying to examine the history of IP layer security mechanisms and proposals. The technology represents many years of research and our Internet focus is often myopic in viewing only the free software or mailing list posted efforts. The original ARPA work was started in the late 70's. Public specifications were available for SP3 in 1988 for IP security complete with a key management protocol (KMP). NLSP circa 1991 is an international specification (derived from SP3) with many implementations in Europe. Commercial implementations based on SP3 and NLSP started to appear in 1992. swIPe was one of the first free implementations posted and so was adopted quickly by some vendors. Significant "commercial" vendor interest did not appear until last year with many Firewall and router vendors backing the use of IP layer security. To my knowledge, all of the S/WAN testing has been directed at the "baseline" definitions of AH and ESP. These are DES and MD5 based encapsulations. Additional algorithms, like RC5, have been added by vendors for "extra credit" (aka perception of market benefits). ESP with RC5 will be an Informational RFCs. ESP-RC5 will not be a "baseline" mechanism since the consensus of the group for a long time has been to use DES as the "mandatory" algorithm for confidentiality. Paul Received: from relay.tis.com by neptune.TIS.COM id aa27676; 19 Mar 96 0:05 EST Received: by relay.tis.com; id AAA02964; Tue, 19 Mar 1996 00:07:58 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma002962; Tue, 19 Mar 96 00:07:30 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21543; Tue, 19 Mar 96 00:06:23 EST Received: by relay.tis.com; id AAA02956; Tue, 19 Mar 1996 00:07:28 -0500 Received: from big-screw.mit.edu(18.72.0.176) by relay.tis.com via smap (V3.1) id xma002953; Tue, 19 Mar 96 00:07:25 -0500 Received: by big-screw id AA04102; Tue, 19 Mar 96 00:07:56 -0500 X-Sender: jis@e40-po.mit.edu (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Mar 1996 00:08:20 -0500 To: William Allen Simpson From: "Jeffrey I. Schiller" Subject: Your Appeal to me regarding replacing IPSEC WG Chair(s) Cc: ipsec@TIS.COM, iesg@ietf.cnri.reston.va.us Sender: ipsec-request@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Monday, March 18, 1996 Bill: I have considered your request to remove the chairs of the IPSEC Working Group. I have taken this matter seriously and have consulted with many people about what they believe is happening in the Working Group. I have also been attending most of the face to face meetings myself and read the mailing list, so I have my own observations as well. My Findings: o Chairing the IPSEC Working Group is a difficult job. There are competing proposals, differing views of the requirements (mostly in terms of how important various requirements are), and investment made by proposal submitters. o You have in the past made significant technical contributions to the IPsec standards. Your technical abilities are considerable when you choose to use them and you are always an active participant. o Your behavior in the working group has been less than professional. You tend to dominate any discussion that interests you. You do not respect the prerogative of the chair(s) to facilitate the working group. o Your behavior causes many people to become intimidated and unwilling to contribute their ideas when you are present. You tend to dominate any discussion that interests you so that other people's useful technical inputs are drowned out or otherwise impeded. Other: I have also had people report to me that you have threatened them with lawsuits and otherwise used intimidation tactics when other avenues of argument were not available to you. Furthermore I interpret your message to the Working Group on 3/14/96 as an attempt to intimidate the chairs and Working Group by making your appeal to me public and threatening to continue to appeal until some body finds in your favor. Remember the motto: "Rough consensus and running code." Rough consensus does not mean a consensus that Bill Simpson will always agree with. By threatening appeals, lawsuits and by just plain shouting people down, you are not participating in a consensus process. You are in violation of the Spirit of the IETF process, in my opinion. Therefore I Conclude: I can find no reason to believe that the Working Group Chairs should be removed on the basis of your appeal. In fact I have discovered that the Working Group chairs have often gone out of their way to ensure that they were as fair as possible to you and your proposals. Furthermore I agree with the Working Group chairs that your behavior has been unacceptable. I interpret Paul's use of the word "fire" to convey to the Working Group members that you have no special status in the working group and members do not have to pay any particular attention to you. I would go so far as to add that as long as your behavior continues to be unacceptable, members of the working group should feel free to ignore you, consensus can well be reached without you. I am sorry that it had to come to this. I believe that you have a strong technical background and good insights. However your talent is wasted if you cannot work and communicate in a civilized manner. At this point you have two choices. You can either appeal my decision to the IESG if you so choose or you can alter your behavior and become a contributing productive member of the IPSEC working group and the IETF as a whole. The choice is yours. -Jeff Schiller Area Director for Security Internet Engineering Steering Group Internet Engineering Task Force -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMU4/88UtR20Nv5BtAQGsDQP/YeWGDQLcNnNGSQRyaxGei2yf6XA5pBGz up7asMKORhbYtM+cQTvF07RbCKslZc9pcUwH9E4i0O4CnY4m3OFx9uvI4rKwcIP1 Csb22Lkd2BwnbV7+732vkkFA4lNHuiDML1NCU5lQaBH43iXXmJklFLpjF1AMsHpc gbJnFc2bbtY= =Owey -----END PGP SIGNATURE----- Received: from relay.tis.com by neptune.TIS.COM id aa29576; 19 Mar 96 2:16 EST Received: by relay.tis.com; id CAA04260; Tue, 19 Mar 1996 02:18:07 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma004258; Tue, 19 Mar 96 02:17:39 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA23408; Tue, 19 Mar 96 02:16:32 EST Received: by relay.tis.com; id CAA04253; Tue, 19 Mar 1996 02:17:37 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma004249; Tue, 19 Mar 96 02:17:17 -0500 Received: from unix.ka9q.ampr.org by interlock.ans.net with SMTP id AA11853 (InterLock SMTP Gateway 3.0 for ); Tue, 19 Mar 1996 02:18:19 -0500 Received: (from karn@localhost) by unix.ka9q.ampr.org (8.7.3/8.6.12) id XAA00300; Mon, 18 Mar 1996 23:20:43 -0800 (PST) Date: Mon, 18 Mar 1996 23:20:43 -0800 (PST) Message-Id: <199603190720.XAA00300@unix.ka9q.ampr.org> From: Phil Karn To: ipsec@ans.net Subject: NSA denies our 3DES license Sender: ipsec-request@neptune.tis.com Precedence: bulk Last month, Qualcomm filed with the State Department an application to export my IP Security (ESP) code for KA9Q NOS to Singapore. Our stated purpose was to encrypt an Internet "tunnel" between Qualcomm's US facilities and our office in Singapore, which is staffed by two US citizens. We stated that the software would be used solely for this purpose and would not be transferred to anyone else. Our application indicated that the software in question supported both single and triple DES. On March 11, the Office of Defense Trade Controls returned our application stamped "RETURNED WITHOUT ACTION". The following form was attached: United States Department of State Bureau of Political-Military Affairs Office of Defense Trade Controls Washington, DC 20520-0602 MAR 11 1996 [stamped] IN REPLY REFER TO DTC CASE - 664149 The enclosed application has been voided and is being RETURNED WITHOUT ACTION for the reasons indicated below: _X_1. Submit a new application including all required background and documentation. Do not return the enclosed application. [25 other unchecked items omitted. These referred mainly to administrative problems like "you used the wrong form", "you didn't file enough copies of the supporting technical data", etc. _X_27. Please submit another license [sic] once your software has been modified so that it no longer contains triple DES. Please specify object code only on your license application. [signed] Darlene Staniszewski Licensing Officer (703) 875-5677 [end of form] So there you have it. NSA makes good on its threat to ANSI X9 that triple DES would not be exportable. This was a case where keeping strong crypto out of the hands of terrorists and unfriendly governments was clearly not at issue. It dealt strictly with the ability of a US corporation to defend its international operations against against industrial espionage. Or, perhaps more to the point, espionage by the NSA. Certainly seems like a good argument in favor of the Leahy bill to me. One mildly interesting thing about this form letter response is that item 27 appeared to be part of the standard form -- it wasn't typed into an "other" field of an existing form. Perhaps they added it to the word processing file for this one occasion. Or perhaps they deny triple DES exports so regularly that they now have a standard form item to deal with it. Phil Karn Received: from relay.tis.com by neptune.TIS.COM id aa05527; 19 Mar 96 8:16 EST Received: by relay.tis.com; id IAA06724; Tue, 19 Mar 1996 08:18:48 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma006721; Tue, 19 Mar 96 08:18:19 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA29873; Tue, 19 Mar 96 08:17:13 EST Received: by relay.tis.com; id IAA06718; Tue, 19 Mar 1996 08:18:18 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma006713; Tue, 19 Mar 96 08:17:56 -0500 Received: from pilotx.firewall.is.chrysler.com (copilot.is.chrysler.com) by interlock.ans.net with SMTP id AA15626 (InterLock SMTP Gateway 3.0 for ); Tue, 19 Mar 1996 08:18:57 -0500 Received: by pilotx.firewall.is.chrysler.com; id IAA15178; Tue, 19 Mar 1996 08:18:58 -0500 Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilotx.is.chrysler.com via smap (g3.0.1) id sma015167; Tue, 19 Mar 96 08:18:47 -0500 Received: from rgm3.is.chrysler.com by clhubgw1.is.chrysler.com (5.x/SMI-4.1) id AD20555; Tue, 19 Mar 1996 08:20:47 -0500 Message-Id: <2.2.32.19960319131657.00e115ec@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Mar 1996 08:16:57 -0500 To: Michael Richardson , ipsec@ans.net From: Robert Moskowitz Subject: Re: ESP transform with RC5 Sender: ipsec-request@neptune.tis.com Precedence: bulk At 03:01 PM 3/18/96 -0500, Michael Richardson wrote: > > For a little more context: the RSA folks got most of the firewall vendors >together last August to discuss RSA DSI and firewalls. We had a problem: we >needed to interoperate on virtual private network technology, particularly >when it came to road-warrior notebooks. We agreed that swipe and SKIP were >interesting, but that the firewall vendors had to implement something that >the PC/Mac stack vendors were going to implement. > Thus S/WAN was born. Just take the then current ipsec, nail some parameters >down, and take the first step. > The various vendors didn't really have anyone that they felt could coordinate >their efforts. While RSA Data Systems isn't a dis-interested party, at least >they are non-firewall-vendor aligned: we know what their interests are. This, of course, is of key interest to the auto industry. We need this sort of interoperability on a fairly large scale. This is why I have been active in the IPSEC wg, in case you haven't guessed ;) Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.tis.com by neptune.TIS.COM id aa06318; 19 Mar 96 9:00 EST Received: by relay.tis.com; id JAA07373; Tue, 19 Mar 1996 09:02:48 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma007371; Tue, 19 Mar 96 09:02:21 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03889; Tue, 19 Mar 96 09:01:14 EST Received: by relay.tis.com; id JAA07364; Tue, 19 Mar 1996 09:02:18 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma007358; Tue, 19 Mar 96 09:02:07 -0500 Received: from pilotx.firewall.is.chrysler.com (copilot.is.chrysler.com) by interlock.ans.net with SMTP id AA16421 (InterLock SMTP Gateway 3.0 for ); Tue, 19 Mar 1996 09:03:07 -0500 Received: by pilotx.firewall.is.chrysler.com; id JAA16125; Tue, 19 Mar 1996 09:03:08 -0500 Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilotx.is.chrysler.com via smap (g3.0.1) id sma016112; Tue, 19 Mar 96 09:02:52 -0500 Received: from rgm3 (rgm3.is.chrysler.com) by clhubgw1.is.chrysler.com (5.x/SMI-4.1) id AA21057; Tue, 19 Mar 1996 09:04:52 -0500 Message-Id: <2.2.32.19960319140102.00e1e19c@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Mar 1996 09:01:02 -0500 To: Phil Karn , ipsec@ans.net From: Robert Moskowitz Subject: Re: NSA denies our 3DES license Sender: ipsec-request@neptune.tis.com Precedence: bulk At 11:20 PM 3/18/96 -0800, Phil Karn wrote: > >So there you have it. NSA makes good on its threat to ANSI X9 that >triple DES would not be exportable. > >This was a case where keeping strong crypto out of the hands of >terrorists and unfriendly governments was clearly not at issue. It >dealt strictly with the ability of a US corporation to defend its >international operations against against industrial espionage. Or, >perhaps more to the point, espionage by the NSA. This raises an interesting question WRT RC5 and smb's note. Can RC5 parameters be set so that it reaches 3DES strength, and if so, if the keying protocol allows for full parameter control, might NSA do the same with RC5 as it is doing to 3DES? Or specify that the keying protocol lock down a certain set of RC5 parameters? OOOps, what have I done? The NSA watchers of this list (not meaning Mark and his fellows, but the 'other side') way now go off and have to figure this all out :) Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.tis.com by neptune.TIS.COM id aa08163; 19 Mar 96 10:16 EST Received: by relay.tis.com; id KAA09335; Tue, 19 Mar 1996 10:18:54 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma009327; Tue, 19 Mar 96 10:18:25 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA09173; Tue, 19 Mar 96 10:17:18 EST Received: by relay.tis.com; id KAA09323; Tue, 19 Mar 1996 10:18:24 -0500 Received: from copilot.is.chrysler.com(204.189.94.148) by relay.tis.com via smap (V3.1) id xma009310; Tue, 19 Mar 96 10:18:03 -0500 Received: by pilotx.firewall.is.chrysler.com; id KAA17360; Tue, 19 Mar 1996 10:19:09 -0500 Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilotx.is.chrysler.com via smap (g3.0.1) id sma017348; Tue, 19 Mar 96 10:19:04 -0500 Received: from rgm3.is.chrysler.com by clhubgw1.is.chrysler.com (5.x/SMI-4.1) id AB22159; Tue, 19 Mar 1996 10:21:03 -0500 Message-Id: <2.2.32.19960319151713.00ca37f8@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Mar 1996 10:17:13 -0500 To: smb@research.att.com, "PALAMBER.US.ORACLE.COM" From: Robert Moskowitz Subject: Re: ESP transform with RC5 Cc: perry@piermont.com, ipsec@TIS.COM Sender: ipsec-request@neptune.tis.com Precedence: bulk At 06:42 PM 3/18/96 EST, smb@research.att.com wrote: > >It's also worth noting that RC5 poses some interesting technical issues. >For example, it is parameterized, and none of the key management mechanisms >we are considering seem to support that. Possibly, the parameters could >be encoded as part of the key -- but we're moving down a track in which >keys are true-random numbers. Besides, it may be necessary to negotiate >some of the parameters under certain circumstances -- some folks may only >have 40-bit RC5 implementations available to them, for the usual obvious >reasons. Seems that an RC4 ESP would have a simliar need? Of course, I'd suspect that only RSA would submit an RC4 ESP and they have already moved on to 5... Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.tis.com by neptune.TIS.COM id aa08685; 19 Mar 96 10:37 EST Received: by relay.tis.com; id KAA10226; Tue, 19 Mar 1996 10:39:22 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma010222; Tue, 19 Mar 96 10:38:56 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10677; Tue, 19 Mar 96 10:37:47 EST Received: by relay.tis.com; id KAA10214; Tue, 19 Mar 1996 10:38:52 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma010205; Tue, 19 Mar 96 10:38:26 -0500 Received: from Fluffy.TGV.COM by interlock.ans.net with SMTP id AA19038 (InterLock SMTP Gateway 3.0 for ); Tue, 19 Mar 1996 10:39:24 -0500 Received: from localhost (localhost [127.0.0.1]) by fluffy.tgv.com (8.7.5/8.7.3) with SMTP id HAA06195 for ipsec@ans.net; Tue, 19 Mar 1996 07:39:08 -0800 (PST) From: Derrell Piper Message-Id: <199603191539.HAA06195@fluffy.tgv.com> To: ipsec@ans.net Subject: Re: NSA denies our 3DES license In-Reply-To: Your message of "Tue, 19 Mar 96 09:01:02 EST." <2.2.32.19960319140102.00e1e19c@pop3hub.is.chrysler.com> Date: Tue, 19 Mar 96 07:39:08 -0800 X-Mts: smtp Sender: ipsec-request@neptune.tis.com Precedence: bulk >Can RC5 parameters be set so that it reaches 3DES strength, and if so, if >the keying protocol allows for full parameter control, might NSA do the same >with RC5 as it is doing to 3DES? Or specify that the keying protocol lock >down a certain set of RC5 parameters? RC5 is a stream cipher that allows for variable length keys. I would guess that RC5 using 40-bit (or less) keys would be exportable, but greater than 40 bits would not. That's what's been done for other ciphers that employ variable length keys. Derrell Piper | piper@tgv.com | 408/457-5384 TGV, Inc. | 101 Cooper Street | Santa Cruz, CA 95060 USA Received: from relay.tis.com by neptune.TIS.COM id aa09312; 19 Mar 96 11:05 EST Received: by relay.tis.com; id LAA11064; Tue, 19 Mar 1996 11:07:52 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma011051; Tue, 19 Mar 96 11:07:26 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA12503; Tue, 19 Mar 96 11:06:18 EST Received: by relay.tis.com; id LAA11038; Tue, 19 Mar 1996 11:07:22 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma011031; Tue, 19 Mar 96 11:07:21 -0500 Received: from columbia.sparta.com (bugs_bunny.columbia.SPARTA.COM) by interlock.ans.net with SMTP id AA20083 (InterLock SMTP Gateway 3.0 for ); Tue, 19 Mar 1996 11:08:17 -0500 Received: from katahdin.columbia.sparta.com by columbia.sparta.com (4.1/cfm-7-21-95) id AA08198; Tue, 19 Mar 96 11:07:43 EST Received: by katahdin.columbia.sparta.com (5.61/SMI-4.1) id AA19845; Tue, 19 Mar 96 11:07:40 -0500 From: Howard Weiss Message-Id: <9603191607.AA19845@katahdin.columbia.sparta.com> Subject: ISO 10164-8 Security Audit Trails To: ipsec@ans.net Date: Tue, 19 Mar 1996 11:07:37 -0500 (EST) Organization: SPARTA Inc. (Secure Systems Engineering Division) Usmail: 9861 Broken Land Parkway, Suite 300, Columbia MD 21046 Phone: (410) 381-9400 x201 Fax: (410) 381-5559 X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 898 Sender: ipsec-request@neptune.tis.com Precedence: bulk I fully realize the IETF aversion to ISO standards (including my own), but I need to ask anyway ..... Does anyone know of any systems that implement standard security audit trails as specified in ISO/IEC 10164-8, 1993 (Information Technology - Open Systems Interconnection - Systems Management - Part 8: Security Audit Trail Function (ITU-T X.740)? Thanks, Howard Weiss ________________________________________________________________________ | | | Howard Weiss phone (410) 381-9400 x201 | | SPARTA, Inc. (301) 621-8145 x201 (DC)| | 9861 Broken Land Parkway, suite 300 fax: (410) 381-5559 | | Columbia, MD 21046 email: hsw@columbia.sparta.com| |________________________________________________________________________| Received: from relay.tis.com by neptune.TIS.COM id aa09506; 19 Mar 96 11:09 EST Received: by relay.tis.com; id LAA11159; Tue, 19 Mar 1996 11:11:52 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma011146; Tue, 19 Mar 96 11:11:24 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA12722; Tue, 19 Mar 96 11:10:17 EST Received: by relay.tis.com; id LAA11137; Tue, 19 Mar 1996 11:11:22 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma011128; Tue, 19 Mar 96 11:10:53 -0500 Received: from RSA.COM by interlock.ans.net with SMTP id AA20219 (InterLock SMTP Gateway 3.0 for ); Tue, 19 Mar 1996 11:11:55 -0500 Received: from snail.rsa.com by RSA.COM with SMTP id AA12673; Tue, 19 Mar 96 08:02:45 PST Received: from cc:Mail by snail.rsa.com id AA827251847; Mon, 18 Mar 96 12:12:24 PST Date: Mon, 18 Mar 96 12:12:24 PST From: baldwin Message-Id: <9602198272.AA827251847@snail.rsa.com> To: ipsec@ans.net Subject: RC5 Security Information Sender: ipsec-request@neptune.tis.com Precedence: bulk For those interested in the security of RC5. Here is the section from the RC5 description document. --Bob 9. Security Considerations The RC5 cipher is relatively new so critical reviews are still being performed. However, the cipher's simple structure makes it easy to analyze and hopefully easier to assess its strength. Reviews so far are very promising. Early results [1] suggest that for RC5 with a 64 bit block size (32 bit word size), 12 rounds will suffice to resist linear and differential cyptanalysis. The 128 bit block version has not been studied as much as the 64 bit version, but it appears that 16 rounds would be an appropriate minimum. Block sizes less than 64 bits are academically interesting but should not be used for cryptographic security. Greater security can be achieved by increasing the number of rounds at the cost of decreasing the throughput of the cipher. The length of the secret key helps determine the cipher's resistance to brute force key searching attacks. A key length of 128 bits should give adequate protection against brute force key searching by a well funded opponent for a couple decades [7]. For RC5 with 12 rounds, the key setup time and data encryption time are the same for all key lengths less than 832 bits, so there is no performance reason for choosing short keys. For larger keys, the key expansion step will run slower because the user key table, LL, will be longer than the expanded key table, S. However, the encryption time will be unchanged since it is only a function of the number of rounds. To comply with export regulations it may be necessary to choose keys that only have 40 unknown bits. A poor way to do this would be to choose a simple 5 byte key. This should be avoided because it would be easy for an opponent to pre-compute key searching information. Another common mechanism is to pick a 128 bit key and publish the first 88 bits. This method may be weak because it reveals a large number of the entries in the user key table, LL, and the key expansion algorithm was not designed to resist attacks when most of LL is known. A better way to conform to the 40 bit rule is to pick a seed value of 128 bits, publish 88 bits of this seed, run the entire seed through a hash function like MD5 [4], and use the 128 bit output of the hash function as the RC5 key. In the case of 40 unknown key bits with 88 known key bits (i.e., 88 salt bits) there should still be 12 or more rounds for the 64 bit block version of RC5, otherwise the value of adding salt bits to the key is likely to be lost. The lifetime of the key also influences security. For high security applications, the key to any 64 bit block cipher should be changed after encrypting 2**32 blocks (2**64 blocks for a 128 bit block cipher). For the case of 64 bit blocks, this rule would recommend changing the key after 2**40 (i.e. 10**12) bytes are encrypted. See Schneier [6] page 183 for further discussion. References [1] Kaliski, Burton S., and Yinqun Lisa Yin, "On Differential and Linear Cryptanalysis of the RC5 Encryption Algorithm", In Advances in Cryptology - Crypto '95, pages 171-184, Springer-Verlag, New York, 1995. [2] Rivest, Ronald L., "The RC5 Encryption Algorithm", In Proceedings of the Second International Workshop on Fast Software Encryption, pages 86-96, Leuven Belgium, December 1994. [3] Rivest, Ronald L., "RC5 Encryption Algorithm", In Dr. Dobbs Journal, number 226, pages 146-148, January 1995. [4] Rivest, Ronald L., "The MD5 Message-Digest Algorithm", RFC 1321. [5] RSA Laboratories, "Public Key Cryptography Standards (PKCS)", RSA Data Security Inc. See ftp.rsa.com. [6] Schneier, Bruce, "Applied Cryptography", Second Edition, John Wiley and Sons, New York, 1996. [7] Business Software Alliance, Matt Blaze et al., "Minimum Key Length for Symmetric Ciphers to Provide Adequate Commercial Security", http://www.bsa.org/bsa/cryptologists.html. Received: from relay.tis.com by neptune.TIS.COM id aa09450; 19 Mar 96 11:08 EST Received: by relay.tis.com; id LAA11122; Tue, 19 Mar 1996 11:10:52 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma011114; Tue, 19 Mar 96 11:10:23 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA12664; Tue, 19 Mar 96 11:09:17 EST Received: by relay.tis.com; id LAA11111; Tue, 19 Mar 1996 11:10:22 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma011109; Tue, 19 Mar 96 11:10:21 -0500 Received: from RSA.COM by interlock.ans.net with SMTP id AA20195 (InterLock SMTP Gateway 3.0 for ); Tue, 19 Mar 1996 11:11:23 -0500 Received: from snail.rsa.com by RSA.COM with SMTP id AA12665; Tue, 19 Mar 96 08:02:06 PST Received: from cc:Mail by snail.rsa.com id AA827251845; Mon, 18 Mar 96 12:09:43 PST Date: Mon, 18 Mar 96 12:09:43 PST From: baldwin Message-Id: <9602198272.AA827251845@snail.rsa.com> To: ipsec@ans.net Subject: RC5 Background Information Sender: ipsec-request@neptune.tis.com Precedence: bulk Here is a short section from the informational RFC on the RC5 cipher. It seems to answer many of the questions we have seen posted to the list. --Bob 1. Executive Summary This document defines three ciphers with enough detail to ensure interoperability between different implementations. The first cipher is the raw RC5 block cipher. The RC5 cipher takes a fixed size input block and produces a fixed sized output block using a transformation that depends on a key. The second cipher, RC5-CBC, is the Cipher Block Chaining (CBC) mode for RC5. It can process messages whose length is a multiple of the RC5 block size. The third cipher, RC5-CBC-Pad, includes padding in the CBC mode to allow it to process inputs of any byte length. The RC5 cipher was invented by Professor Ronald L. Rivest of the Massachusetts Institute of Technology in 1994. It is a very fast and simple algorithm that is parameterized by the block size, the number of rounds, and key length. These parameters can be adjusted to meet different goals for security, performance, and exportability. A patent application has been filed for the RC5 cipher. The terms RC5, RC5-CBC, RC5-CBC-Pad and assorted variations on these are trademarks. Received: from relay.tis.com by neptune.TIS.COM id aa09535; 19 Mar 96 11:10 EST Received: by relay.tis.com; id LAA11171; Tue, 19 Mar 1996 11:12:22 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma011168; Tue, 19 Mar 96 11:11:54 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA12751; Tue, 19 Mar 96 11:10:47 EST Received: by relay.tis.com; id LAA11160; Tue, 19 Mar 1996 11:11:52 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma011147; Tue, 19 Mar 96 11:11:35 -0500 Received: from RSA.COM by interlock.ans.net with SMTP id AA20256 (InterLock SMTP Gateway 3.0 for ); Tue, 19 Mar 1996 11:12:36 -0500 Received: from snail.rsa.com by RSA.COM with SMTP id AA12688; Tue, 19 Mar 96 08:03:25 PST Received: from cc:Mail by snail.rsa.com id AA827251852; Mon, 18 Mar 96 12:14:36 PST Date: Mon, 18 Mar 96 12:14:36 PST From: baldwin Message-Id: <9602198272.AA827251852@snail.rsa.com> To: ipsec@ans.net Subject: RC5 Performance Information Sender: ipsec-request@neptune.tis.com Precedence: bulk One reason for using RC5 in an ESP is to get higher performance. Here are some performance numbers comparing DES and RC5 when encrypting 1024 byte blocks on a 100MHz Pentium and a 200MHz DEC Alpha. Both numbers come from RSADSI's BSAFE 3.0 cryptography toolkit. The DES implementation in BSAFE 3.0 is a slight variation of Eric Young's libdes software and is used with his permission. DES uses a 56 bit key. The RC5 version measured below uses a 128 bit key, 12 rounds of the inner loop, and like DES, is a 64 bit block cipher. 90 MHz Pentium 200 MHz DEC Alpha DES Key Setup 17 MicroSeconds 16 MicroSeconds RC4 Key Setup 57 MicroSeconds 138 MicroSeconds RC5 Key Setup 48 MicroSeconds 26 MicroSeconds DES Encrypt 8.0 MegaBits/Sec 10.6 MegaBits/Sec RC4 Encrypt 65.6 MegaBits/Sec 34.4 MegaBits/Sec RC5 Encrypt 26.3 MegaBits/Sec 24.5 MegaBits/Sec --Bob Received: from relay.tis.com by neptune.TIS.COM id aa09599; 19 Mar 96 11:11 EST Received: by relay.tis.com; id LAA11195; Tue, 19 Mar 1996 11:13:22 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma011189; Tue, 19 Mar 96 11:12:53 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA12808; Tue, 19 Mar 96 11:11:47 EST Received: by relay.tis.com; id LAA11186; Tue, 19 Mar 1996 11:12:52 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma011178; Tue, 19 Mar 96 11:12:42 -0500 Received: from RSA.COM by interlock.ans.net with SMTP id AA20315 (InterLock SMTP Gateway 3.0 for ); Tue, 19 Mar 1996 11:13:44 -0500 Received: from snail.rsa.com by RSA.COM with SMTP id AA12756; Tue, 19 Mar 96 08:04:15 PST Received: from cc:Mail by snail.rsa.com id AA827251893; Mon, 18 Mar 96 13:40:41 PST Date: Mon, 18 Mar 96 13:40:41 PST From: baldwin Message-Id: <9602198272.AA827251893@snail.rsa.com> To: perry@piermont.com Cc: ipsec@ans.net Subject: ESP RC5 and S/WAN Sender: ipsec-request@neptune.tis.com Precedence: bulk Perry, You might want to check out the S/WAN information on http://www.rsa.com/rsa/SWAN. The current effort is aimed at helping vendors to implement AH and ESP with manual DES key loading. There is an interoperability matrix on a sub-page that shows how far the 11 current vendors have gotten (a long way!). S/WAN is basically an initiative run by vendors who are actually implementing the IPsec working group standards, and so far it has been quite successful. A few of the vendors have requested that RSADSI help them get 1) better performance than DES in software, and 2) the ability to sell an IPsec product internationally, or at least being able to create a demo versions that can be downloaded internationally, and 3) a cipher that is stronger than DES. The ESP based on RC5 is a response to these requests. RC5 with 128 bit keys and 12 rounds meets requirements 1 and 3, and a 40 bit RC5 we hope will meet requirements 1 and 2 (so far no vendors has formally requested export of 40 bit RC5). I think the main thing to notice is that 11 vendors now have implementations of DES based ESP. They also all support the MD5 AH header and some of them support the new HMAC nested MD5 integrity check for AH. In this respect, I hope that you can see that RSADSI is help the IPsec group further many of its goals. The vendors of IPsec products will only license technologies from RSADSI if it benefits them and their customers. The S/WAN initiative seeks to complement the good work of the IPsec group to incorporate the perspective of the TCP/IP vendors, many of whom have an global market. --Bob ______________________________ Reply Separator _________________________________ Subject: Re: ESP transform with RC5 Author: perry@piermont.com at INTERNET Date: 3/18/96 11:55 AM Just for context for everyone, the RSA DSI folks are (or at least, were) attempting to push this thing they call S/WAN, which is basically IPsec using RC5 to make it into something proprietary that RSA DSI has a patent on and thus gets royalties for. It doesn't have any real advantages to anyone other than RSA DSI, which has an obvious stake in its widespread deployment... Perry Received: from relay.tis.com by neptune.TIS.COM id aa10197; 19 Mar 96 11:30 EST Received: by relay.tis.com; id LAA11850; Tue, 19 Mar 1996 11:32:18 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma011840; Tue, 19 Mar 96 11:31:51 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13950; Tue, 19 Mar 96 11:30:45 EST Received: by relay.tis.com; id LAA11834; Tue, 19 Mar 1996 11:31:50 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma011814; Tue, 19 Mar 96 11:31:21 -0500 Received: from igw2.watson.ibm.com by interlock.ans.net with SMTP id AA20796 (InterLock SMTP Gateway 3.0 for ); Tue, 19 Mar 1996 11:32:22 -0500 Received: from hawpub.watson.ibm.com ([9.2.90.19]) by igw2.watson.ibm.com (8.7.4/8.7.1) with SMTP id LAA23382; Tue, 19 Mar 1996 11:32:30 -0500 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/2/16/96) id AA32475; Tue, 19 Mar 1996 11:32:21 -0500 Message-Id: <9603191632.AA32475@hawpub.watson.ibm.com> Subject: Re: NSA denies our 3DES license To: Robert Moskowitz Date: Tue, 19 Mar 1996 11:32:20 -0500 (EST) From: Uri Blumenthal Cc: ipsec@ans.net In-Reply-To: <2.2.32.19960319140102.00e1e19c@pop3hub.is.chrysler.com> from "Robert Moskowitz" at Mar 19, 96 09:01:02 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-request@neptune.tis.com Precedence: bulk Robert Moskowitz says: > >So there you have it. NSA makes good on its threat to ANSI X9 that > >triple DES would not be exportable. > > This raises an interesting question WRT RC5 and smb's note. > Can RC5 parameters be set so that it reaches 3DES strength, and if so, if > the keying protocol allows for full parameter control, might NSA do the same > with RC5 as it is doing to 3DES? Or specify that the keying protocol lock > down a certain set of RC5 parameters? 1. Since the number of rounds can be as large as 255 and the same is true for the key length, probably RC5 can approach 3DES strength, further analysis pending. 2. It seems obvious, that no software will be licensed, unless the institution in question can provide guarantees that the limit on number of rounds and length of key are unmodifiable. If such a guarantee is not satisfactory, I'd expect the license to be denied. > OOOps, what have I done? The NSA watchers of this list (not meaning Mark > and his fellows, but the 'other side') way now go off and have to figure > this all out :) (:-) -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- Received: from relay.tis.com by neptune.TIS.COM id aa10324; 19 Mar 96 11:34 EST Received: by relay.tis.com; id LAA11959; Tue, 19 Mar 1996 11:36:18 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma011953; Tue, 19 Mar 96 11:35:49 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA14248; Tue, 19 Mar 96 11:34:42 EST Received: by relay.tis.com; id LAA11950; Tue, 19 Mar 1996 11:35:48 -0500 Received: from merit.edu(35.1.1.42) by relay.tis.com via smap (V3.1) id xma011944; Tue, 19 Mar 96 11:35:21 -0500 Received: from Bill.Simpson.DialUp.Mich.Net (pm012-26.dialip.mich.net [141.211.7.194]) by merit.edu (8.7.5/merit-2.0) with SMTP id LAA14884; Tue, 19 Mar 1996 11:35:56 -0500 (EST) Date: Tue, 19 Mar 96 16:09:26 GMT From: William Allen Simpson Message-Id: <5086.wsimpson@greendragon.com> To: "Jeffrey I. Schiller" Cc: ipsec@TIS.COM, iesg@ietf.cnri.reston.va.us Subject: Re: Your Appeal to me regarding replacing IPSEC WG Chair(s) Sender: ipsec-request@neptune.tis.com Precedence: bulk > Date: Tue, 19 Mar 1996 00:08:20 -0500 > From: "Jeffrey I. Schiller" > I have considered your request to remove the chairs of the > IPSEC Working Group. I have taken this matter seriously and have > consulted with many people about what they believe is happening in the > Working Group. I have also been attending most of the face to face > meetings myself and read the mailing list, so I have my own > observations as well. >... > I can find no reason to believe that the Working Group Chairs > should be removed on the basis of your appeal. Thank you for your decision on my Feb 11 request, with additional issues raised Feb 14, Feb 15, Mar 5, and Mar 10. However, despite your "serious" research, you have based the decision on (at least) two errors of fact: > I have also had people report to me that you have threatened > them with lawsuits and otherwise used intimidation tactics when other > avenues of argument were not available to you. Perhaps you could give more detail on these apocryphal and anonymous charges? > Furthermore I interpret > your message to the Working Group on 3/14/96 as an attempt to > intimidate the chairs and Working Group by making your appeal to me > public and threatening to continue to appeal until some body finds in > your favor. > Perhaps you could specify what message to the Working Group? I cannot find any message from me to the WG on or near that date. Since you failed to answer _any_ of the specifics raised in my appeal, and both of your negative findings are factually unsupported, I will appeal to the IESG as a whole, pursuant to our Standards Process. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 Received: from relay.tis.com by neptune.TIS.COM id aa10868; 19 Mar 96 11:59 EST Received: by relay.tis.com; id MAA12830; Tue, 19 Mar 1996 12:01:13 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma012823; Tue, 19 Mar 96 12:00:40 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA15767; Tue, 19 Mar 96 11:59:34 EST Received: by relay.tis.com; id MAA12820; Tue, 19 Mar 1996 12:00:39 -0500 Received: from merit.edu(35.1.1.42) by relay.tis.com via smap (V3.1) id xma012815; Tue, 19 Mar 96 12:00:24 -0500 Received: from Bill.Simpson.DialUp.Mich.Net (pm012-26.dialip.mich.net [141.211.7.194]) by merit.edu (8.7.5/merit-2.0) with SMTP id LAA14908 for ; Tue, 19 Mar 1996 11:36:06 -0500 (EST) Date: Tue, 19 Mar 96 16:05:22 GMT From: William Allen Simpson Message-Id: <5085.wsimpson@greendragon.com> To: ipsec@TIS.COM Subject: Re: ESP transform with RC5 Sender: ipsec-request@neptune.tis.com Precedence: bulk > From: smb@research.att.com > Date: Mon, 18 Mar 96 18:42:23 EST > It's also worth noting that RC5 poses some interesting technical issues. > For example, it is parameterized, and none of the key management mechanisms > we are considering seem to support that. Photuris provides for parameterization, and in particular, the Photuris extensions document proposes negotiation of parameters for RC5. But then, you may be correct that we are not officially considering Photuris. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 Received: from relay.tis.com by neptune.TIS.COM id aa10897; 19 Mar 96 12:00 EST Received: by relay.tis.com; id MAA12874; Tue, 19 Mar 1996 12:02:09 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma012851; Tue, 19 Mar 96 12:01:42 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA15831; Tue, 19 Mar 96 12:00:35 EST Received: by relay.tis.com; id MAA12844; Tue, 19 Mar 1996 12:01:40 -0500 Received: from unknown(206.1.51.15) by relay.tis.com via smap (V3.1) id xma012832; Tue, 19 Mar 96 12:01:14 -0500 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id MAA25678; Tue, 19 Mar 1996 12:01:38 -0500 (EST) Message-Id: <199603191701.MAA25678@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Robert Moskowitz Cc: ipsec@TIS.COM Subject: Re: ESP transform with RC5 In-Reply-To: Your message of "Tue, 19 Mar 1996 10:17:13 EST." <2.2.32.19960319151713.00ca37f8@pop3hub.is.chrysler.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 19 Mar 1996 12:01:37 -0500 From: "Perry E. Metzger" Sender: ipsec-request@neptune.tis.com Precedence: bulk Robert Moskowitz writes: > Seems that an RC4 ESP would have a simliar need? Of course, I'd suspect > that only RSA would submit an RC4 ESP and they have already moved on to 5... RC4 has entered the public domain, so RSA has no reason to push it since they can't make any money by selling it. It is unknown how good a cipher it is, but it is being studied. Perry Received: from relay.tis.com by neptune.TIS.COM id aa10896; 19 Mar 96 12:00 EST Received: by relay.tis.com; id MAA12873; Tue, 19 Mar 1996 12:02:09 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma012852; Tue, 19 Mar 96 12:01:42 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA15832; Tue, 19 Mar 96 12:00:35 EST Received: by relay.tis.com; id MAA12842; Tue, 19 Mar 1996 12:01:40 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma012826; Tue, 19 Mar 96 12:00:58 -0500 Received: from jekyll.piermont.com by interlock.ans.net with SMTP id AA21795 (InterLock SMTP Gateway 3.0 for ); Tue, 19 Mar 1996 12:01:53 -0500 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id MAA25670; Tue, 19 Mar 1996 12:00:20 -0500 (EST) Message-Id: <199603191700.MAA25670@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Robert Moskowitz Cc: Phil Karn , ipsec@ans.net Subject: Re: NSA denies our 3DES license In-Reply-To: Your message of "Tue, 19 Mar 1996 09:01:02 EST." <2.2.32.19960319140102.00e1e19c@pop3hub.is.chrysler.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 19 Mar 1996 12:00:08 -0500 From: "Perry E. Metzger" Sender: ipsec-request@neptune.tis.com Precedence: bulk Robert Moskowitz writes: > This raises an interesting question WRT RC5 and smb's note. > > Can RC5 parameters be set so that it reaches 3DES strength, If it can be, you can bet it can't be exported. We can't answer that question, however, because we haven't studied RC5 long enough to have anything like a reasonable answer. However, I don't see what the problem is. If you need IPSec for your overseas plants, buy from the Swiss or the Israelis or someone else who isn't stopped at the border. There are lots of overseas vendors for this stuff, so there is no reason to worry. Perry Received: from relay.tis.com by neptune.TIS.COM id aa11139; 19 Mar 96 12:07 EST Received: by relay.tis.com; id MAA13105; Tue, 19 Mar 1996 12:09:15 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma013100; Tue, 19 Mar 96 12:08:47 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16171; Tue, 19 Mar 96 12:07:40 EST Received: by relay.tis.com; id MAA13097; Tue, 19 Mar 1996 12:08:45 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma013095; Tue, 19 Mar 96 12:08:43 -0500 Received: from jekyll.piermont.com by interlock.ans.net with SMTP id AA22244 (InterLock SMTP Gateway 3.0 for ); Tue, 19 Mar 1996 12:09:45 -0500 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id MAA25709; Tue, 19 Mar 1996 12:09:22 -0500 (EST) Message-Id: <199603191709.MAA25709@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Derrell Piper Cc: ipsec@ans.net Subject: Re: NSA denies our 3DES license In-Reply-To: Your message of "Tue, 19 Mar 1996 07:39:08 PST." <199603191539.HAA06195@fluffy.tgv.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 19 Mar 1996 12:09:17 -0500 From: "Perry E. Metzger" Sender: ipsec-request@neptune.tis.com Precedence: bulk Derrell Piper writes: > RC5 is a stream cipher that allows for variable length keys. I believe RC5 is actually a block cipher. Perry Received: from relay.tis.com by neptune.TIS.COM id aa11284; 19 Mar 96 12:13 EST Received: by relay.tis.com; id MAA13194; Tue, 19 Mar 1996 12:15:45 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma013187; Tue, 19 Mar 96 12:15:17 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16347; Tue, 19 Mar 96 12:14:11 EST Received: by relay.tis.com; id MAA13179; Tue, 19 Mar 1996 12:15:16 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma013170; Tue, 19 Mar 96 12:14:47 -0500 Received: from jekyll.piermont.com by interlock.ans.net with SMTP id AA22477 (InterLock SMTP Gateway 3.0 for ); Tue, 19 Mar 1996 12:15:45 -0500 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id MAA25701; Tue, 19 Mar 1996 12:08:10 -0500 (EST) Message-Id: <199603191708.MAA25701@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: baldwin (Robert W. Baldwin) Cc: ipsec@ans.net Subject: Re: ESP RC5 and S/WAN In-Reply-To: Your message of "Mon, 18 Mar 1996 13:40:41 PST." <9602198272.AA827251893@snail.rsa.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 19 Mar 1996 12:08:10 -0500 From: "Perry E. Metzger" Sender: ipsec-request@neptune.tis.com Precedence: bulk "baldwin" writes: > The ESP based on RC5 is a response to these requests. > RC5 with 128 bit keys and 12 rounds meets requirements 1 and 3, > and a 40 bit RC5 we hope will meet requirements 1 and 2 (so far > no vendors has formally requested export of 40 bit RC5). A more honest effort would have pushed 3DES for high security instead of an RSA patented algorithm of still dubious merit. 40 bit keys can be achieved easily for DES by the expedient of doing something like exposing 16 of the bits. There is no good reason for anyone to use RSA DSI proprietary conventional cipher algorithms. Perry Received: from relay.tis.com by neptune.TIS.COM id aa11662; 19 Mar 96 12:30 EST Received: by relay.tis.com; id MAA13472; Tue, 19 Mar 1996 12:32:45 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma013466; Tue, 19 Mar 96 12:32:17 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16760; Tue, 19 Mar 96 12:31:10 EST Received: by relay.tis.com; id MAA13463; Tue, 19 Mar 1996 12:32:15 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma013458; Tue, 19 Mar 96 12:31:49 -0500 Received: from jekyll.piermont.com by interlock.ans.net with SMTP id AA22953 (InterLock SMTP Gateway 3.0 for ); Tue, 19 Mar 1996 12:32:42 -0500 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id MAA25728; Tue, 19 Mar 1996 12:19:05 -0500 (EST) Message-Id: <199603191719.MAA25728@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: baldwin Cc: ipsec@ans.net Subject: Re: RC5 Background Information In-Reply-To: Your message of "Mon, 18 Mar 1996 12:09:43 PST." <9602198272.AA827251845@snail.rsa.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 19 Mar 1996 12:19:05 -0500 From: "Perry E. Metzger" Sender: ipsec-request@neptune.tis.com Precedence: bulk baldwin writes: > Here is a short section from the informational RFC on > the RC5 cipher. It seems to answer many of the questions we have > seen posted to the list. Actually, it doesn't answer the biggest question, which is "is RC5 secure?" The answer its "no one really knows". However, your posting does note something I continue to emphasize... > A patent application has been filed for the RC5 cipher. The terms RC5, > RC5-CBC, RC5-CBC-Pad and assorted variations on these are trademarks. The reason that RSA DSI pushes RC5 is because they own it and will make money off of every user if it is widely used. They have no other good reason for pushing it. If people are really concerned about speed and are willing to use patented algorithms, there are other, better choices that run fast and have better security analysis behind them. Meanwhile, Phil Karn has DES running at over 10Mbps in software on Pentium chips, and there are 3DES chips that run at gigabit speeds. I see no reason that anyone should be seriously considering the use of RC5 unless they have stock in RSA DSI. Perry Received: from relay.tis.com by neptune.TIS.COM id aa11798; 19 Mar 96 12:34 EST Received: by relay.tis.com; id MAA13554; Tue, 19 Mar 1996 12:36:46 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma013548; Tue, 19 Mar 96 12:36:17 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16862; Tue, 19 Mar 96 12:35:11 EST Received: by relay.tis.com; id MAA13543; Tue, 19 Mar 1996 12:36:16 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma013539; Tue, 19 Mar 96 12:36:09 -0500 Received: from jekyll.piermont.com by interlock.ans.net with SMTP id AA23050 (InterLock SMTP Gateway 3.0 for ); Tue, 19 Mar 1996 12:37:09 -0500 Received: (from perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) id MAA25772; Tue, 19 Mar 1996 12:37:08 -0500 (EST) Date: Tue, 19 Mar 1996 12:37:08 -0500 (EST) Message-Id: <199603191737.MAA25772@jekyll.piermont.com> From: "Perry E. Metzger" To: ipsec@ans.net Subject: RC5 Reply-To: perry@piermont.com X-Reposting-Policy: please ask before redistributing Sender: ipsec-request@neptune.tis.com Precedence: bulk I really didn't want to get into a war with marketing flacks from RSA Data Security Inc. over their patented "RC5" encryption algorithm. I believe I've made my point on the topic, and I don't want to waste people's time further with it. I simply encourage people to remember that regardless of your need, there is no good reason to buy RC5 from RSA, although RSA certainly has an economic interest in making you think otherwise, and will doubtless push very hard to get people to use it. Perry Received: from relay.tis.com by neptune.TIS.COM id aa11846; 19 Mar 96 12:35 EST Received: by relay.tis.com; id MAA13578; Tue, 19 Mar 1996 12:37:45 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma013575; Tue, 19 Mar 96 12:37:18 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16881; Tue, 19 Mar 96 12:36:11 EST Received: by relay.tis.com; id MAA13566; Tue, 19 Mar 1996 12:37:16 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma013559; Tue, 19 Mar 96 12:36:49 -0500 Received: from jekyll.piermont.com by interlock.ans.net with SMTP id AA23059 (InterLock SMTP Gateway 3.0 for ); Tue, 19 Mar 1996 12:37:51 -0500 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id MAA25747; Tue, 19 Mar 1996 12:28:45 -0500 (EST) Message-Id: <199603191728.MAA25747@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: baldwin Cc: ipsec@ans.net Subject: Re: RC5 Performance Information In-Reply-To: Your message of "Mon, 18 Mar 1996 12:14:36 PST." <9602198272.AA827251852@snail.rsa.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 19 Mar 1996 12:28:44 -0500 From: "Perry E. Metzger" Sender: ipsec-request@neptune.tis.com Precedence: bulk baldwin writes: > One reason for using RC5 in an ESP is to get higher performance. If one wants higher performance and one is willing to use patented algorithms, there are better ones out there. IBM's SEAL, developed by Don Coppersmith, comes to mind. It also hasn't been studied well enough, but it has been studied better than RC5 and is blazingly fast -- far faster than RC5. If one needs real performance in a firewall or routing product, however, the right answer is hardware. Gigabit 3DES encrypting chips exist. If one insists on software and is willing to use things that are insufficiently studied, code known to be compatible with RC4 and free of any intellectual property restrictions is available on the net, and is faster than RC5. In any case, I believe it is time to get off this topic. The point has been made. Perry Received: from relay.tis.com by neptune.TIS.COM id aa11962; 19 Mar 96 12:38 EST Received: by relay.tis.com; id MAA13666; Tue, 19 Mar 1996 12:40:45 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma013649; Tue, 19 Mar 96 12:40:17 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16991; Tue, 19 Mar 96 12:39:10 EST Received: by relay.tis.com; id MAA13646; Tue, 19 Mar 1996 12:40:15 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma013644; Tue, 19 Mar 96 12:40:05 -0500 Received: from pilotx.firewall.is.chrysler.com (copilot.is.chrysler.com) by interlock.ans.net with SMTP id AA23159 (InterLock SMTP Gateway 3.0 for ); Tue, 19 Mar 1996 12:41:06 -0500 Received: by pilotx.firewall.is.chrysler.com; id MAA19470; Tue, 19 Mar 1996 12:41:08 -0500 Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilotx.is.chrysler.com via smap (g3.0.1) id sma019445; Tue, 19 Mar 96 12:40:55 -0500 Received: from rgm3 (rgm3.is.chrysler.com) by clhubgw1.is.chrysler.com (5.x/SMI-4.1) id AA23701; Tue, 19 Mar 1996 12:42:55 -0500 Message-Id: <2.2.32.19960319173904.00cb42bc@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Mar 1996 12:39:04 -0500 To: perry@piermont.com From: Robert Moskowitz Subject: Re: NSA denies our 3DES license Cc: Phil Karn , ipsec@ans.net Sender: ipsec-request@neptune.tis.com Precedence: bulk At 12:00 PM 3/19/96 -0500, Perry E. Metzger wrote: > >However, I don't see what the problem is. If you need IPSec for your >overseas plants, buy from the Swiss or the Israelis or someone else >who isn't stopped at the border. There are lots of overseas vendors >for this stuff, so there is no reason to worry. Oh, I'm not worried for 'us', but I am worried a little at 'US' ;) Of course it might be interesting to see what the various governments will do when an encrypted tunnel using a very strong RC5 or a 3DES is going between say Chrysler's TIS firewall in Detroit and Robert Bosch's firewall in Frankfurt (I think it is). The international aspect of our industry will challenge a lot of standard positions. Chrysler just opened an office in Antwerp. I haven't investigated if we got the Cylink gear for there like we did for the Austria plant ( only DES based).... Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.tis.com by neptune.TIS.COM id aa12139; 19 Mar 96 12:42 EST Received: by relay.tis.com; id MAA13781; Tue, 19 Mar 1996 12:44:16 -0500 From: smb@research.att.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma013774; Tue, 19 Mar 96 12:43:47 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA17170; Tue, 19 Mar 96 12:42:40 EST Received: by relay.tis.com; id MAA13771; Tue, 19 Mar 1996 12:43:45 -0500 Message-Id: <199603191743.MAA13771@relay.tis.com> Received: from ns.research.att.com(192.20.225.4) by relay.tis.com via smap (V3.1) id xma013769; Tue, 19 Mar 96 12:43:32 -0500 Received: from research.att.com by ns; Tue Mar 19 12:42:05 EST 1996 Received: from gryphon by research; Tue Mar 19 12:41:50 EST 1996 Received: by gryphon; Tue Mar 19 12:41:46 EST 1996 To: Robert Moskowitz Cc: "PALAMBER.US.ORACLE.COM" , perry@piermont.com, ipsec@TIS.COM Subject: Re: ESP transform with RC5 Date: Tue, 19 Mar 96 12:41:45 EST Sender: ipsec-request@neptune.tis.com Precedence: bulk Seems that an RC4 ESP would have a simliar need? Of course, I'd suspect that only RSA would submit an RC4 ESP and they have already moved on to 5... Well, the SKIP folks like RC4, too. But RC4 is a stream cipher, and RC5 is a block cipher, so they address different needs. For practical purposes, there are only two RC4 versions that matter, 40-bit and 128-bit. RC5 has several other variables as well. Received: from relay.tis.com by neptune.TIS.COM id aa12268; 19 Mar 96 12:46 EST Received: by relay.tis.com; id MAA13971; Tue, 19 Mar 1996 12:48:46 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma013953; Tue, 19 Mar 96 12:48:18 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA17348; Tue, 19 Mar 96 12:47:11 EST Received: by relay.tis.com; id MAA13946; Tue, 19 Mar 1996 12:48:15 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma013938; Tue, 19 Mar 96 12:48:08 -0500 Received: from relay.hp.com by interlock.ans.net with SMTP id AA23360 (InterLock SMTP Gateway 3.0 for ); Tue, 19 Mar 1996 12:49:04 -0500 Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA104667732; Tue, 19 Mar 1996 09:48:53 -0800 Message-Id: <199603191748.AA104667732@relay.hp.com> Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com id AA251058012; Tue, 19 Mar 1996 12:53:32 -0500 X-Mailer: exmh version 1.6.2 7/18/95 To: baldwin Cc: perry@piermont.com, ipsec@ans.net Subject: Re: ESP RC5 and S/WAN In-Reply-To: baldwin's message of Mon, 18 Mar 1996 13:40:41 -0800. <9602198272.AA827251893@snail.rsa.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 19 Mar 1996 12:48:51 -0500 From: Bill Sommerfeld Sender: ipsec-request@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii You recently asserted that RC5 with 128 bit keys and 12 rounds is definitely stronger than DES. Given the youth of RC5, I find it difficult to accept your assertion at this time. - Bill -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMU7zfFpj/0M1dMJ/AQFKeAP9H2Z7C+H5py+a9uNfSqUegix/QaKaESQN bEQZcJt+Fm2YeLJfwphGE+ry5GNPW9/UZEYDncOk+oWZ4zc33NGo708ghZdQspqs iF5G6XFEsyAUhRVTjUllkUXhfmZ9Fmhf0tZ6jUuEZCbm6LUFCzdjQrocD+K8NVPs bBxR80eQt5s= =wScO -----END PGP SIGNATURE----- Received: from relay.tis.com by neptune.TIS.COM id aa12557; 19 Mar 96 12:55 EST Received: by relay.tis.com; id MAA14253; Tue, 19 Mar 1996 12:57:15 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma014249; Tue, 19 Mar 96 12:56:48 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA17727; Tue, 19 Mar 96 12:55:42 EST Received: by relay.tis.com; id MAA14237; Tue, 19 Mar 1996 12:56:46 -0500 Received: from stilton.cisco.com(171.69.1.161) by relay.tis.com via smap (V3.1) id xma014227; Tue, 19 Mar 96 12:56:37 -0500 Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by stilton.cisco.com (8.6.8+c/8.6.5) with SMTP id JAA12220; Tue, 19 Mar 1996 09:57:37 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Mar 1996 09:57:40 -0800 To: iesg@ietf.cnri.reston.va.us From: Fred Baker Subject: Re: Your Appeal to me regarding replacing IPSEC WG Chair(s) Cc: ipsec@TIS.COM Sender: ipsec-request@neptune.tis.com Precedence: bulk At 8:09 AM 3/19/96, William Allen Simpson wrote: >Since you failed to answer _any_ of the specifics raised in my appeal, >and both of your negative findings are factually unsupported, I will >appeal to the IESG as a whole, pursuant to our Standards Process. I am prepared to send something like the following to Bill: comments? ______________________________________________________________________ Bill: We have received your appeal. In fact, Jeff's comments do not come from him alone, but were discussed among us in person at the IETF and by email over the last week. His comments represent our consensus. It is the considered opinion of the IESG that the working group chairs hould remain in place, and that you should restrict your position, in this context, to that of a member of the IPSEC working group. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= It has recently been discovered that research causes cancer in rats. Received: from relay.tis.com by neptune.TIS.COM id aa12896; 19 Mar 96 13:07 EST Received: by relay.tis.com; id NAA14630; Tue, 19 Mar 1996 13:09:15 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma014616; Tue, 19 Mar 96 13:08:47 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18513; Tue, 19 Mar 96 13:07:41 EST Received: by relay.tis.com; id NAA14609; Tue, 19 Mar 1996 13:08:46 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma014605; Tue, 19 Mar 96 13:08:45 -0500 Received: from optima.CS.Arizona.EDU by interlock.ans.net with SMTP id AA23988 (InterLock SMTP Gateway 3.0 for ); Tue, 19 Mar 1996 13:09:47 -0500 Received: from uncial.CS.Arizona.EDU by optima.cs.arizona.edu (5.65c/15) via SMTP id AA16022; Tue, 19 Mar 1996 11:09:44 MST Received: by uncial.CS.Arizona.EDU; (5.65/1.1.8.2/08Nov94-0446PM) id AA17746; Tue, 19 Mar 1996 11:09:43 -0700 Date: Tue, 19 Mar 1996 11:09:43 -0700 From: Hilarie Orman Message-Id: <9603191809.AA17746@uncial.CS.Arizona.EDU> To: baldwin@rsa.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <9602198272.AA827251852@snail.rsa.com> Subject: Re: RC5 Performance Information Sender: ipsec-request@neptune.tis.com Precedence: bulk > 90 MHz Pentium 200 MHz DEC Alpha > DES Encrypt 8.0 MegaBits/Sec 10.6 MegaBits/Sec > RC5 Encrypt 26.3 MegaBits/Sec 24.5 MegaBits/Sec I think best DES speed is closer to 18 MBits/Sec on a 200 MHz Alpha; I'd imagine the RC5 time cannot be improved, so a 2/3 ratio is realistic for that machine. Received: from relay.tis.com by neptune.TIS.COM id aa13295; 19 Mar 96 13:25 EST Received: by relay.tis.com; id NAA15291; Tue, 19 Mar 1996 13:27:31 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma015285; Tue, 19 Mar 96 13:27:04 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19532; Tue, 19 Mar 96 13:25:57 EST Received: by relay.tis.com; id NAA15281; Tue, 19 Mar 1996 13:27:01 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma015267; Tue, 19 Mar 96 13:26:44 -0500 Received: from pilotx.firewall.is.chrysler.com (copilot.is.chrysler.com) by interlock.ans.net with SMTP id AA24417 (InterLock SMTP Gateway 3.0 for ); Tue, 19 Mar 1996 13:27:44 -0500 Received: by pilotx.firewall.is.chrysler.com; id NAA20504; Tue, 19 Mar 1996 13:27:45 -0500 Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilotx.is.chrysler.com via smap (g3.0.1) id sma020493; Tue, 19 Mar 96 13:27:35 -0500 Received: from rgm3 (rgm3.is.chrysler.com) by clhubgw1.is.chrysler.com (5.x/SMI-4.1) id AA24353; Tue, 19 Mar 1996 13:29:35 -0500 Message-Id: <2.2.32.19960319182544.00e26d04@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Mar 1996 13:25:44 -0500 To: perry@piermont.com, baldwin (Robert W. Baldwin) From: Robert Moskowitz Subject: Re: ESP RC5 and S/WAN Cc: ipsec@ans.net Sender: ipsec-request@neptune.tis.com Precedence: bulk At 12:08 PM 3/19/96 -0500, Perry E. Metzger wrote: >There is no good reason for anyone to use RSA >DSI proprietary conventional cipher algorithms. Hah! The money pot is big here, why shouldn't RSA get a bigger shot at it (beyond their public key stuff). I'm on the business side of things and I understand this. I will not deny RSA's efforts to get more licensees. Heck, they are only following in IBM's, TI's, Microsoft's and other's footsteps. I do get concern when rape and pillage licensing practices are used. We fought this a lot back in the bad-old IBM days (good old Amdahl and NEC always there when you need them :). I am also concerned about effects on our piece pricing. If I end up adding $1000 cost to 8,000 Chrysler suppliers, our car retail price will go up too. We are not a rich uncle that can be continiously touched for some loose change. If a Pentium 90 can do DES at 8Mb/s that ain't so bad, considering that most of our suppliers wouldn't have more than an ISDN link for some time to come. There are needs for SOFTWARE high speeds that might need a fast cypher (as compared to a cheap hardware pump for a slightly slower cypher). But most real time needs don't need to get over 4Mb/s even on LANs. Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.tis.com by neptune.TIS.COM id aa13371; 19 Mar 96 13:27 EST Received: by relay.tis.com; id NAA15383; Tue, 19 Mar 1996 13:30:02 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma015371; Tue, 19 Mar 96 13:29:34 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19673; Tue, 19 Mar 96 13:28:27 EST Received: by relay.tis.com; id NAA15364; Tue, 19 Mar 1996 13:29:32 -0500 Received: from newdev.harvard.edu(128.103.65.15) by relay.tis.com via smap (V3.1) id xma015349; Tue, 19 Mar 96 13:29:08 -0500 Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id NAA11381; Tue, 19 Mar 1996 13:27:25 -0500 (EST) Date: Tue, 19 Mar 1996 13:27:25 -0500 (EST) From: Scott Bradner Message-Id: <199603191827.NAA11381@newdev.harvard.edu> To: fred@cisco.com, iesg@ietf.cnri.reston.va.us Subject: Re: Your Appeal to me regarding replacing IPSEC WG Chair(s) Cc: ipsec@TIS.COM Sender: ipsec-request@neptune.tis.com Precedence: bulk Fred, I would claim that we have not received an appeal from Bill. The question of the clarity of an appeal cam eup during the discussion over Dave Perkin's SMI process. 1602bis says that --- All appeals must include a detailed and specific description of the facts of the dispute. --- I claim we have not received a specific message from Bill that meets anything like these requirements. I ask that we 1/ wait for a specific detailed message or 2/ tell Bill that he should create such a letter then wait I talked to Bill in LA about appeals & the need to be clear and request specific actions - so he has heard this message Scott Received: from relay.tis.com by neptune.TIS.COM id aa13519; 19 Mar 96 13:31 EST Received: by relay.tis.com; id NAA15515; Tue, 19 Mar 1996 13:34:02 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma015504; Tue, 19 Mar 96 13:33:44 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19924; Tue, 19 Mar 96 13:32:31 EST Received: by relay.tis.com; id NAA15488; Tue, 19 Mar 1996 13:33:36 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma015458; Tue, 19 Mar 96 13:33:02 -0500 Received: from info.forthnet.gr by interlock.ans.net with SMTP id AA24579 (InterLock SMTP Gateway 3.0 for ); Tue, 19 Mar 1996 13:34:00 -0500 Received: from vicky.forthnet.gr by info.forthnet.gr via FORTHnet with SMTP; id UAA17167 (8.6.12/FORTHNET-2.0); Tue, 19 Mar 1996 20:29:59 +0200 (EET DST) Message-Id: <199603191829.UAA17167@info.forthnet.gr> Organization: To: Derrell Piper Cc: ipsec@ans.net Subject: Re: NSA denies our 3DES license In-Reply-To: Your message of "Tue, 19 Mar 1996 07:39:08 PST." <199603191539.HAA06195@fluffy.tgv.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <1545.827260203.1@forthnet.gr> Date: Tue, 19 Mar 1996 20:30:04 +0200 From: "Angelos D. Keromytis" Sender: ipsec-request@neptune.tis.com Precedence: bulk In message <199603191539.HAA06195@fluffy.tgv.com>, Derrell Piper writes: > >RC5 is a stream cipher that allows for variable length keys. I would guess >that RC5 using 40-bit (or less) keys would be exportable, but greater than >40 bits would not. That's what's been done for other ciphers that employ >variable length keys. > RC5 is a block cipher. RC4 is the stream cipher. -Angelos Received: from relay.tis.com by neptune.TIS.COM id aa14339; 19 Mar 96 13:59 EST Received: by relay.tis.com; id OAA16421; Tue, 19 Mar 1996 14:02:02 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma016412; Tue, 19 Mar 96 14:01:34 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21372; Tue, 19 Mar 96 14:00:27 EST Received: by relay.tis.com; id OAA16401; Tue, 19 Mar 1996 14:01:32 -0500 Received: from stilton.cisco.com(171.69.1.161) by relay.tis.com via smap (V3.1) id xma016378; Tue, 19 Mar 96 14:01:15 -0500 Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by stilton.cisco.com (8.6.8+c/8.6.5) with SMTP id LAA17014; Tue, 19 Mar 1996 11:02:04 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Mar 1996 11:02:07 -0800 To: Scott Bradner From: Fred Baker Subject: Re: Your Appeal to me regarding replacing IPSEC WG Chair(s) Cc: iesg@ietf.cnri.reston.va.us, ipsec@TIS.COM Sender: ipsec-request@neptune.tis.com Precedence: bulk At 1:27 PM 3/19/96, Scott Bradner wrote: >I would claim that we have not received an appeal from Bill. Would you suggest, then, that we sit tight and wait (which is most likely to result in Bill doing nothing, and then taking some more public forum to say that we have not responded to his appeal, whereupon we point to the text and say that we're waiting to receive one) or that I drop him a note that says "please forward a 1602bis compliant appeal"? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= It has recently been discovered that research causes cancer in rats. Received: from relay.tis.com by neptune.TIS.COM id aa14580; 19 Mar 96 14:07 EST Received: by relay.tis.com; id OAA16585; Tue, 19 Mar 1996 14:10:02 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma016578; Tue, 19 Mar 96 14:09:35 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21801; Tue, 19 Mar 96 14:08:28 EST Received: by relay.tis.com; id OAA16564; Tue, 19 Mar 1996 14:09:32 -0500 Received: from stilton.cisco.com(171.69.1.161) by relay.tis.com via smap (V3.1) id xma016553; Tue, 19 Mar 96 14:09:17 -0500 Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by stilton.cisco.com (8.6.8+c/8.6.5) with SMTP id LAA18128; Tue, 19 Mar 1996 11:10:19 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Mar 1996 11:10:22 -0800 To: ipsec@TIS.COM From: Fred Baker Subject: Re: Your Appeal to me regarding replacing IPSEC WG Chair(s) Cc: iesg@ietf.cnri.reston.va.us Sender: ipsec-request@neptune.tis.com Precedence: bulk It has been pointed out to me that I mis-edited the CC line, and the preceeding discussion has therefore not been among the IESG. You will, I trust, forgive the error, which is mine. Having said which, the statements made are true: Jeff's comments to Bill do in fact represent the current consensus of the IESG. And, Bill has not made a formal further appeal in the sense described by RFC 1602bis. My suggestion is that if Bill would like to make such an appeal, he should refer to the draft and make a formal appeal, and we will consider it. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= It has recently been discovered that research causes cancer in rats. Received: from relay.tis.com by neptune.TIS.COM id aa15142; 19 Mar 96 14:27 EST Received: by relay.tis.com; id OAA17107; Tue, 19 Mar 1996 14:29:54 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma017101; Tue, 19 Mar 96 14:29:28 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22812; Tue, 19 Mar 96 14:28:19 EST Received: by relay.tis.com; id OAA17095; Tue, 19 Mar 1996 14:29:24 -0500 Received: from newdev.harvard.edu(128.103.65.15) by relay.tis.com via smap (V3.1) id xma017060; Tue, 19 Mar 96 14:28:49 -0500 Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id OAA11777; Tue, 19 Mar 1996 14:28:20 -0500 (EST) Date: Tue, 19 Mar 1996 14:28:20 -0500 (EST) From: Scott Bradner Message-Id: <199603191928.OAA11777@newdev.harvard.edu> To: fred@cisco.com, sob@newdev.harvard.edu Subject: Re: Your Appeal to me regarding replacing IPSEC WG Chair(s) Cc: iesg@ietf.cnri.reston.va.us, ipsec@TIS.COM Sender: ipsec-request@neptune.tis.com Precedence: bulk I would suggest someone (I'll be happy to do so) sending Bill a note requesting a clear appeal if he intends to appeal Scott Received: from relay.tis.com by neptune.TIS.COM id aa16285; 19 Mar 96 15:12 EST Received: by relay.tis.com; id PAA18197; Tue, 19 Mar 1996 15:14:24 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma018187; Tue, 19 Mar 96 15:13:59 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA26128; Tue, 19 Mar 96 15:12:49 EST Received: by relay.tis.com; id PAA18180; Tue, 19 Mar 1996 15:13:54 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma018177; Tue, 19 Mar 96 15:13:53 -0500 Received: from eagle1.raptor.com (raptor.com) by interlock.ans.net with SMTP id AA27559 (InterLock SMTP Gateway 3.0 for ); Tue, 19 Mar 1996 15:14:51 -0500 Received: from raptor1.raptor.com ([204.7.242.10]) by eagle1.raptor.com via smtpd (for interlock.ans.net [147.225.5.2]) with SMTP; 19 Mar 1996 20:14:37 UT Received: from Joe_Tardo.raptor.com (pool031.Max4.San-Francisco.CA.DYNIP.ALTER.NET [153.37.101.31]) by raptor1.raptor.com (8.7.3/8.7.3) with SMTP id PAA07795; Tue, 19 Mar 1996 15:13:29 -0500 (EST) Message-Id: <2.2.32.19960319200830.00690738@204.7.242.10> X-Sender: jtardo@204.7.242.10 X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Mar 1996 12:08:30 -0800 To: Hilarie Orman From: Joe Tardo Subject: Re: RC5 Performance Information Cc: ipsec@ans.net Sender: ipsec-request@neptune.tis.com Precedence: bulk At 11:09 AM 3/19/96 -0700, Hilarie Orman wrote: >> 90 MHz Pentium 200 MHz DEC Alpha >> DES Encrypt 8.0 MegaBits/Sec 10.6 MegaBits/Sec >> RC5 Encrypt 26.3 MegaBits/Sec 24.5 MegaBits/Sec > >I think best DES speed is closer to 18 MBits/Sec on a 200 MHz Alpha; >I'd imagine the RC5 time cannot be improved, so a 2/3 ratio is realistic >for that machine. > So the Alpha does DES 2.5 times faster but RC5 slower? Explain, please. Received: from relay.tis.com by neptune.TIS.COM id aa19063; 19 Mar 96 17:26 EST Received: by relay.tis.com; id RAA21140; Tue, 19 Mar 1996 17:29:04 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma021136; Tue, 19 Mar 96 17:28:36 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02886; Tue, 19 Mar 96 17:27:29 EST Received: by relay.tis.com; id RAA21131; Tue, 19 Mar 1996 17:28:34 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma021127; Tue, 19 Mar 96 17:28:31 -0500 Received: from theory.lcs.mit.edu by interlock.ans.net with SMTP id AA01901 (InterLock SMTP Gateway 3.0 for ); Tue, 19 Mar 1996 17:29:22 -0500 Received: from swan.lcs.mit.edu by theory.lcs.mit.edu (5.65c/TOC-1.2S) id AA11790; Tue, 19 Mar 96 17:29:19 EST From: Ron Rivest Received: by swan.lcs.mit.edu (5.65c/TOC-1.2C) id AA27646; Tue, 19 Mar 96 17:29:18 EST Date: Tue, 19 Mar 96 17:29:18 EST Message-Id: <199603192229.AA27646@swan.lcs.mit.edu> To: ipsec@ans.net Subject: RC5 paper available on the Web Sender: ipsec-request@neptune.tis.com Precedence: bulk Since there has been some inquiry here about RC5, I'd like to note that my original paper describing RC5 is available on the Web in postscript. You can find it from my publications page. My home page is http://theory.lcs.mit.edu/~rivest Cheers, Ron Rivest Received: from relay.tis.com by neptune.TIS.COM id aa19592; 19 Mar 96 17:52 EST Received: by relay.tis.com; id RAA21471; Tue, 19 Mar 1996 17:54:34 -0500 From: stroh@vnet.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma021469; Tue, 19 Mar 96 17:54:05 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03580; Tue, 19 Mar 96 17:52:58 EST Received: by relay.tis.com; id RAA21466; Tue, 19 Mar 1996 17:54:04 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma021464; Tue, 19 Mar 96 17:54:02 -0500 Received: from vnet.ibm.com by interlock.ans.net with SMTP id AA02627 (InterLock SMTP Gateway 3.0 for ); Tue, 19 Mar 1996 17:54:56 -0500 Message-Id: <199603192254.AA02627@interlock.ans.net> Received: from AUSVM6 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 8561; Tue, 19 Mar 96 17:54:34 EST Date: Tue, 19 Mar 96 16:51:07 CST To: ipsec@ans.net Subject: rc5 perf and rotates Sender: ipsec-request@neptune.tis.com Precedence: bulk Bill Sommerfeld writes >> So on the "variable shifts are efficient" front: >> >> yes: HP, IBM, DEC, Intel >> no: Sun, SGI.. I would label your lists "yes" and "maybe". If the SPARC and MIPS implementations use barrel shifters, I still claim its only a couple extra cycles that might even be buried. ... >> Of course, if the algorithm isn't secure, who cares how fast it is.. Right. Who cares if a rotate is fast in an absolute sense? - the question is how fast is the operation versus the operations needed for its cryptanalytic inverse, i.e. its one-way-ness, compared to the alternative. Presumably the crypto paper cited is well reasoned, I'll look it up. If so then they do not depend on the claim that modern processors are slow to rotate in an absolute cycle count sense, which is the claim I dispute. I will need some convincing that algorithms incorporating rotates are inferior in cryptographic efficiency to those excluding them. Rotates would seem to be the best way of achieving information diffusion between bit positions (sub modulo 8) without loss of information. Averaging over all possible shift counts, shifts only move half as much information between bit positions as rotates. The other ALU operations alone are much slower to diffuse information between bit positions (other than adjacent ones). >> >> - Bill Nice analysis. ... >> *I was under the impression that the pentium had a barrel shifter, >> though the 486 didn't, but I may be wrong... You are right, I was mistaken, good catch. Although the RCL/RCR (rotate through carry) variable count instructions take 7-27 clocks, the ROL/ROR variable count instructions take a constant 4. Which only reinforces our point. regards, Oscar Strohacker Advisory Engineer/Scientist Data Compression Systems Architecture IBM Microelectronics Division 11400 Burnet Road Austin Texas 78758 o (512) 838-4077 f (512) 838-7004 Internet: stroh @ vnet.ibm.com Received: from relay.tis.com by neptune.TIS.COM id aa20712; 19 Mar 96 18:54 EST Received: by relay.tis.com; id SAA22171; Tue, 19 Mar 1996 18:56:06 -0500 From: touch@isi.edu MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma022169; Tue, 19 Mar 96 18:55:38 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA04997; Tue, 19 Mar 96 18:54:31 EST Received: by relay.tis.com; id SAA22164; Tue, 19 Mar 1996 18:55:36 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma022160; Tue, 19 Mar 96 18:55:28 -0500 Received: from venera.isi.edu by interlock.ans.net with SMTP id AA03985 (InterLock SMTP Gateway 3.0 for ); Tue, 19 Mar 1996 18:56:29 -0500 Received: from ash-s.isi.edu (ash-a.isi.edu) by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 19 Mar 1996 15:56:19 -0800 Date: Tue, 19 Mar 1996 15:52:47 -0800 Posted-Date: Tue, 19 Mar 1996 15:52:47 -0800 Message-Id: <199603192352.AA07889@ash-s.isi.edu> Received: by ash-s.isi.edu (5.65c/4.0.3-4) id ; Tue, 19 Mar 1996 15:52:47 -0800 To: ipsec@ans.net, stroh@vnet.ibm.com Subject: Re: rc5 perf and rotates Cc: touch@isi.edu X-Auto-Sig-Adder-By: faber@isi.edu Sender: ipsec-request@neptune.tis.com Precedence: bulk > From: stroh@vnet.ibm.com > Date: Tue, 19 Mar 96 16:51:07 CST > To: ipsec@ans.net > Subject: rc5 perf and rotates > > Bill Sommerfeld writes > > >> So on the "variable shifts are efficient" front: > >> > >> yes: HP, IBM, DEC, Intel > >> no: Sun, SGI.. > > I would label your lists "yes" and "maybe". If the SPARC and MIPS > implementations use barrel shifters, I still claim its only a couple extra > cycles that might even be buried. They will not get buried if they are in the critical path, which they appear to be. That couple of cycles multiplies by 24 (2 rotates per round, 12 rounds). > Who cares if a rotate is fast in an absolute sense? - the question is how I do. I run IP at 150 Mbps, and would like to run _some_ security that can keep pace. > I will need some convincing that algorithms incorporating rotates are inferior > in cryptographic efficiency to those excluding them. Rotates would seem to > be the best way of achieving information diffusion between bit positions (sub > modulo 8) without loss of information. Averaging over all possible shift counts, Table lookups might be an alternative, especially if the table is small. Joe ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/ Received: from relay.tis.com by neptune.TIS.COM id aa20965; 19 Mar 96 19:01 EST Received: by relay.tis.com; id TAA22294; Tue, 19 Mar 1996 19:04:06 -0500 From: smb@research.att.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma022292; Tue, 19 Mar 96 19:03:37 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA05178; Tue, 19 Mar 96 19:02:31 EST Received: by relay.tis.com; id TAA22289; Tue, 19 Mar 1996 19:03:36 -0500 Message-Id: <199603200003.TAA22289@relay.tis.com> Received: from ns.research.att.com(192.20.225.4) by relay.tis.com via smap (V3.1) id xma022287; Tue, 19 Mar 96 19:03:27 -0500 Received: from research.att.com by ns; Tue Mar 19 19:01:41 EST 1996 Received: from gryphon by research; Tue Mar 19 19:00:50 EST 1996 Received: by gryphon; Tue Mar 19 19:00:48 EST 1996 To: ipsec@TIS.COM Subject: draft paper available Date: Tue, 19 Mar 96 19:00:47 EST Sender: ipsec-request@neptune.tis.com Precedence: bulk Folks on this list may be interested in a draft of a new paper of mine entitled ``Problem Areas for the IP Security Protocols''. It outlines some of the older attacks we've been discussing, plus a few new ones. Here's the abstract: The Internet Engineering Task Force (IETF) is in the process of adopting standards for IP-layer encryption and authentication (IPSEC). We describe a number of attacks against various versions of these protocols, including confidentiality failures and authentication failures. The implications of these attacks are troubling for the utility of this entire effort. The paper can be picked up from ftp://ftp.research.att.com/dist/smb/badesp.ps. Received: from relay.tis.com by neptune.TIS.COM id aa23828; 19 Mar 96 21:24 EST Received: by relay.tis.com; id VAA23691; Tue, 19 Mar 1996 21:26:06 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma023685; Tue, 19 Mar 96 21:25:38 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA07864; Tue, 19 Mar 96 21:24:31 EST Received: by relay.tis.com; id VAA23677; Tue, 19 Mar 1996 21:25:36 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma023671; Tue, 19 Mar 96 21:25:21 -0500 Received: from volitans.MorningStar.Com by interlock.ans.net with SMTP id AA06080 (InterLock SMTP Gateway 3.0 for ); Tue, 19 Mar 1996 21:26:02 -0500 Received: from gefilte.MorningStar.Com by volitans.MorningStar.Com (8.7.1/95070701) id CAA26207; Wed, 20 Mar 1996 02:26:01 GMT From: Karl Fox Received: by gefilte.MorningStar.Com (5.65a/94012401) id AA09602; Tue, 19 Mar 96 21:26:00 -0500 Date: Tue, 19 Mar 96 21:26:00 -0500 Message-Id: <9603200226.AA09602@gefilte.MorningStar.Com> To: stroh@vnet.ibm.com Cc: ipsec@ans.net Subject: rc5 perf and rotates In-Reply-To: <199603192254.AA02627@interlock.ans.net> References: <199603192254.AA02627@interlock.ans.net> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Sender: ipsec-request@neptune.tis.com Precedence: bulk stroh@vnet.ibm.com writes: > Who cares if a rotate is fast in an absolute sense? I would, if I were using RC5 on a machine without a barrel shifter and I were concerned about timing attacks. -- Karl Fox, servant of God, employee of Morning Star Technologies 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 451 1883 Received: from relay.tis.com by neptune.TIS.COM id aa10496; 20 Mar 96 13:37 EST Received: by relay.tis.com; id NAA06979; Wed, 20 Mar 1996 13:39:36 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma006970; Wed, 20 Mar 96 13:39:08 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08086; Wed, 20 Mar 96 13:38:01 EST Received: by relay.tis.com; id NAA06967; Wed, 20 Mar 1996 13:39:06 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma006962; Wed, 20 Mar 96 13:38:50 -0500 Received: from RSA.COM by interlock.ans.net with SMTP id AA23770 (InterLock SMTP Gateway 3.0 for ); Wed, 20 Mar 1996 13:39:46 -0500 Received: from snail.rsa.com by RSA.COM with SMTP id AA21071; Wed, 20 Mar 96 10:28:58 PST Received: from cc:Mail by snail.rsa.com id AA827347185; Wed, 20 Mar 96 10:39:02 PST Date: Wed, 20 Mar 96 10:39:02 PST From: baldwin Message-Id: <9602208273.AA827347185@snail.rsa.com> To: Karl Fox , ipsec@ans.net Subject: RC5 and timing attacks Sender: ipsec-request@neptune.tis.com Precedence: bulk Karl, The way we avoid timing attacks on RC5 is to make sure that our implementation runs in constant time. The methods are: 1) Using a fixed-time rotate instruction if the CPU has one, or 2) Performing rotation by two shift and mask operations that together take a fixed amount of time (e.g., rotate right three positions is implemented as a shift right 3 that takes 3 cycles and a shift left 29 (= 32 - 3) that takes 29 cycles for a constant total of 32 cycles. 3) Other tricks are possible on CPUs that perform shifts in variable time (e.g., shift one and shift eight may both take one cycle, but shift two takes two cycles). One of the reasons for buying the BSAFE 3.0 crypto toolkit is to make sure these are done right on each platform. OK, I know that was a product plug, but I couldn't resist :-). --Bob ______________________________ Reply Separator _________________________________ Subject: rc5 perf and rotates Author: Karl Fox at INTERNET Date: 3/19/96 9:26 PM stroh@vnet.ibm.com writes: > Who cares if a rotate is fast in an absolute sense? I would, if I were using RC5 on a machine without a barrel shifter and I were concerned about timing attacks. -- Karl Fox, servant of God, employee of Morning Star Technologies 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 451 1883 Received: from relay.tis.com by neptune.TIS.COM id aa27699; 22 Mar 96 11:25 EST Received: by relay.tis.com; id LAA15645; Fri, 22 Mar 1996 11:27:40 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma015637; Fri, 22 Mar 96 11:27:12 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06445; Fri, 22 Mar 96 11:26:05 EST Received: by relay.tis.com; id LAA15627; Fri, 22 Mar 1996 11:27:10 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma015615; Fri, 22 Mar 96 11:26:41 -0500 Received: from bnr.ca (x400gate.bnr.ca) by interlock.ans.net with SMTP id AA19070 (InterLock SMTP Gateway 3.0 for ); Fri, 22 Mar 1996 11:27:41 -0500 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 22 Mar 1996 10:46:11 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 22 Mar 1996 10:46:01 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 22 Mar 1996 10:46:00 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 22 Mar 1996 10:46:00 -0500 Date: Fri, 22 Mar 1996 10:46:00 -0500 X400-Originator: mleech@bcarh6dc.ott.bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;<199603221546.AA242249560@bcarh6] X400-Content-Type: P2-1984 (2) Content-Identifier: SMBs "Problem... From: "marcus (m.d.) leech" Message-Id: <199603221546.AA242249560@bcarh6dc.ott.bnr.ca> To: ipsec@ans.net Subject: SMBs "Problem Areas for the IP Security Protocols"--where do we go from here? Organization: Nortel Technologies, System Security Services X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2364 Sender: ipsec-request@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Having read Steve Bellovins thoughtful paper, I'm not as depressed as I could be. Some things become clear after reading the paper: If you care about confidentiality, then you must also care about integrity/authenticity. Replay is definitely a problem, particularly in light of UDP socket re-use. Because of this, replay protection would need to be built into all three of AH only, ESP only, AH+ESP. It's likely that a combined ESP transform that provides all three of: Confidentiality Integrity/Authenticity Replay protection Would be a useful thing for us to do as a WG. Jim Hughes' document is almost there, except for unkeyed MD5. Bill Simpson has an all-in-one document that, at least superficially, seems OK. I haven't seen any discussion of his document, I suspect due to censure by the WG chairs. Ran had said that Photuris, as it stands now, does not address all of the requirements of a key-management protocol for endorsement by the IETF. I'd Ran to review his perceptions of what those requirements are. I know that I'm no longer clear on what the "hard" requirements are, and I believe that there is some confusion about those requirements. In view of Steve Bellovins recent paper, a new requirement has emerged of a "special case" of rapid-rekey in that a block of SPIs (and associated keying material) could potentially be negotiated in a single key management exchange. This seems to me to be a useful model to investigate; particularly in those situations where a given host may need to rapidly establish security associations to a number of other hosts, but security requirements indicate that per-connection/session keying is desirable. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQBVAwUBMVLLNap9EtiCAjydAQEZvAH9GcI7zjTwTpxzPFUlztyqsYma5S6DaozP rPoU2pc5voD44NpNmWn055W5WSty37KFQCon+eH9tdE6tNfkzAlYQQ== =+NA0 -----END PGP SIGNATURE----- -- ---------------------------------------------------------------------- Marcus Leech Mail: Dept 4C16, MS 238, CAR Systems Security Architect Phone : (ESN) 395-4901 (613) 763-9145 Systems Security Services Fax : (ESN) 393-7679 (613) 763-7679 Nortel Technologies mleech@bnr.ca -----------------Expressed opinions are my own, not my employers------ Received: from relay.tis.com by neptune.TIS.COM id aa01583; 22 Mar 96 14:46 EST Received: by relay.tis.com; id OAA19838; Fri, 22 Mar 1996 14:48:54 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma019824; Fri, 22 Mar 96 14:48:25 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21381; Fri, 22 Mar 96 14:47:18 EST Received: by relay.tis.com; id OAA19818; Fri, 22 Mar 1996 14:48:24 -0500 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1) id xma019815; Fri, 22 Mar 96 14:48:19 -0500 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id LAA05739 for ipsec@tis.com; Fri, 22 Mar 1996 11:49:22 -0800 Date: Fri, 22 Mar 1996 11:49:22 -0800 From: Ran Atkinson Message-Id: <199603221949.LAA05739@puli.cisco.com> To: ipsec@TIS.COM Subject: Request for Implementation Status Sender: ipsec-request@neptune.tis.com Precedence: bulk All, This is the draft revised IETF IPsec WG's Implementation Status "template". Suggestions on new data fields or revised structure should be sent to me and Paul via private email. If you have an implementation of any portion of the IETF IPsec specifications and are willing to let this be known in public, please fill this in and email it to me for consolidation into the master list. I expect to post a revised summary in a few days time. Folks who were listed in previous summaries have already been sent a ping by me and so can safely ignore this note. Suggested answers are in parenthesis ready for you to edit. Thanks, Randall Atkinson Co-Chair, IPsec WG, IETF ______________________________________________________________________ Name of Implementation: (name of your implementation/product) Organisation: (name of your organisation) Which IP versions are supported: (IPv4, IPv6, or IPv4 and IPv6) Implements RFC-1825 & RFC-1826 AH: (YES, NO, In Progress, Planned, Partial) Implements RFC-1825 & RFC-1827 ESP: (YES, NO, In Progress, Planned, Partial) Implements RFC-1828 AH MD5: (YES, NO, In Progress, Planned, Partial) Implements RFC-1829 ESP DES-CBC:(YES, NO, In Progress, Planned, Partial) Other AH Implemented Transforms: (none, AH-HMAC-MD5, AH-SHA, proprietary) Other ESP Implemented Transforms: (none, ESP-3DES, ESP-RC4, ESP-RC5, ESP-DES-MD5-Replay, proprietary) Key Management: (manual, ISAKMP, ISAKMP+Oakley, Oakley, Photuris, SKIP, proprietary) Platforms: (4.4-Lite BSD, Solaris, IRIX, , STREAMS, LINUX, etc) Lineage of IPsec Code: (, ETHZ, JI, KA9Q, NIST, NRL, SUN, not applicable) Lineage of Key Mgmt Code: (, SUN, ETHZ, JI, cisco, not applicable) Location of Source Code: (provide URL if freely available, use the word "proprietary" if isn't freely available) Point of Contact: (email address, optionally also phone/fax/name) Claimed Interoperability: (list of systems that your implementation fully interoperates with) _______________________________________________________________________ Received: from relay.tis.com by neptune.TIS.COM id aa01950; 22 Mar 96 14:56 EST Received: by relay.tis.com; id OAA20113; Fri, 22 Mar 1996 14:58:55 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma020096; Fri, 22 Mar 96 14:58:26 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22494; Fri, 22 Mar 96 14:57:19 EST Received: by relay.tis.com; id OAA20089; Fri, 22 Mar 1996 14:58:24 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma020083; Fri, 22 Mar 96 14:58:19 -0500 Received: from relay.hp.com by interlock.ans.net with SMTP id AA25408 (InterLock SMTP Gateway 3.0 for ); Fri, 22 Mar 1996 14:59:17 -0500 Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA094134753; Fri, 22 Mar 1996 11:59:14 -0800 Message-Id: <199603221959.AA094134753@relay.hp.com> Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com id AA119165047; Fri, 22 Mar 1996 15:04:07 -0500 X-Mailer: exmh version 1.6.2 7/18/95 To: "marcus (m.d.) leech" Cc: ipsec@ans.net Subject: Re: SMBs "Problem Areas for the IP Security Protocols"--where do we go from here? In-Reply-To: mleech's message of Fri, 22 Mar 1996 10:46:00 -0500. <199603221546.AA242249560@bcarh6dc.ott.bnr.ca> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 22 Mar 1996 14:59:11 -0500 From: Bill Sommerfeld Sender: ipsec-request@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii I saw at least one other important observation of Steve's: The IP layer deals with one-way datagrams, but just about anything non-trivial above the IP layer involves two-way communication at some point (Ok, the mbone broadcasts of NASA select are one-way, but that's an exception..), and it's important to correctly associate a message with its reply. therefore, there must be some facility in the key management protocol to allow SPI's to be "paired", so that an "incoming SPI" can be associated with a "outgoing SPI", with the result that replies to incoming traffic received using the incoming SPI are sent using the outgoing SPI. I'm not quite sure how this generalizes to multicast traffic. - Bill -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMVMGg1pj/0M1dMJ/AQEHlQP9GdOZzCRv9UQ85lyLM2OL9SOPYNH0co97 8M7+5la6TV9ZCfqoeyUjY+iG+Qib4v36quFbmq2pqHo7tY5XxOPDXVdSvz4aa8eJ BT8ly7J+aqDN1Ed0UddyXUA4S58PlQJKb/pSIH2Ju0w2xSE5n2RlkhTqfsj8FKim 5Pk0sWYmqPE= =0NLi -----END PGP SIGNATURE----- Received: from relay.tis.com by neptune.TIS.COM id aa02125; 22 Mar 96 15:01 EST Received: by relay.tis.com; id PAA20229; Fri, 22 Mar 1996 15:03:24 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma020219; Fri, 22 Mar 96 15:02:57 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22986; Fri, 22 Mar 96 15:01:49 EST Received: by relay.tis.com; id PAA20210; Fri, 22 Mar 1996 15:02:54 -0500 Received: from unknown(192.86.155.81) by relay.tis.com via smap (V3.1) id xma020191; Fri, 22 Mar 96 15:02:23 -0500 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id LAA04364; Fri, 22 Mar 1996 11:54:57 -0800 Received: by mailsun2.us.oracle.com (8.7.1/37.8) id LAA09305; Fri, 22 Mar 1996 11:57:27 -0800 (PST) Message-Id: <199603221957.LAA09305@mailsun2.us.oracle.com> Date: 22 Mar 96 11:48:34 -0800 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: IPsec Implementation Survey - March 22 Cc: swan-dev@rsa.com Mime-Version: 1.0 Sender: ipsec-request@neptune.tis.com Precedence: bulk Minor errors (like the mailing list address) and one addition to the ipsec implementation survey are attached below. Paul -------------- The following 18 individuals and vendors have responded to the IPSEC implementation survey. ERPIPSEC ETHZ / ENskip GTFW-GD IBM JI KA9Q NOS Morning Star Network Systems NIST/NSA NRL Raptor Systems Sidewinder Sun ICG TimeStep PERMIT TIS Gauntlet USC/ISI V-ONE SmartWall The results of this survey (as of March 22, 1996) are provided below. Please submit any updates or new entries to the ipsec mailing list (ipsec@tis.com) Paul A. Lambert IPsec Co-Chair _______________________________________________________________________ Name of Implementation: ERPIPSEC, BELLCORE, Antonio Fernandez Security Protocols: ESP, AH Security Transforms: ESP-DES, AH-MD5_128,64,32 Key Management: manual Location of Source Code: proprietary Point of Contact: Antonio Fernandez, afa@bellcore.com _______________________________________________________________________ Name of Implementation: ETHZ / ENskip Security Protocols: SKIP (draft 6), limited AH & ESP (SPI=1) Security Transforms: ESP-DES, ESP-3DES, ESP-IDEA, ESP-RC4, AH-MD5 (some of these transforms are not yet standarized) Key Management: only via SKIP, (manual, X.509 and 'DH public value' keying). (plus non-standardized PFS) Lineage of Code: Works under Solaris 2.4+, IRIX, NetBSD, Nextstep. Location of Source Code: ftp://ftp.tik.ee.ethz.ch/pub/packages/skip (X.509 and PFS not yet publicly available) Point of Contact: skip@tik.ee.ethz.ch _______________________________________________________________________ Name of Implementation: Gemini Trusted Security Firewall-Guard (GTFW-GD) Security Protocols: 1. IPSec (ESP,AH): Public-Private 2. IPCSO & IPSec: Private-Private (IP Crypto-Seal Option) (Integrity, Authentication, Confidentiality) Security Transforms: DES, Key MD5, Trusted Crypto-Seals Key Management: 1. Manual for Trusted Public-Private Internetwork 2. A1 Trusted Distribution Key Management Extended for Trusted Private-Private Internetwork 3. Customized Lineage of Code: 1. Trusted Software 2. Platform: GTFW-GD on Gemini Trusted Network Processor with Integrated Encryption certified at Class A1 Location of Source Code: Proprietary Point of Contact: Dr. Tien F. Tao, tft@main.geminisecure.com _______________________________________________________________________ Name of Implementation: IBM Security Protocols: ESP, AH, both tunnel and transport mode Security Transforms: ESP-DES (32-bit and 64-bit IV), keyed-MD5, new keyed-MD5 proposed by Hugo Key Management : Manual+Fast Key Refreshment>, SKEME (in progress), Photuris (in Progress) Lineage of Code: IBM Proprietary, about 10k to 15K lines (rough estimate, including ESP, AH, and Key Management). Location of Source Code: Proprietary Point of Contact: pau@yktvmv.vnet.ibm.com _______________________________________________________________________ Name of Implementation: JI Security Protocols: ESP, AH, Protocol-4 encapsultation Security Transforms: ESP-DES, AH-MD5 Key Management: manual, Photuris; PF_ENCAP keying i/f, PF_ROUTE extensionsl Lineage of Code: Written from scratch, entirely in Greece, for BSD/OS 2.0, Location of Source Code: ji's home machine The promised end-January-96 release is not ready yet; it should be (freely) available from ftp.ripe.net RSN. Point of Contact: ji@hol.gr _______________________________________________________________________ Name of Implementation: KA9Q NOS Security Protocols: ESP, AH Security Transforms: ESP-DES & ESP-DES3, each with 0,32 and 64-bit IVs; keyed MD5 Key Management: manual Lineage of Code: scratch Location of Source Code: Not yet released. Will release soon, modulo export rules Point of Contact: karn@unix.ka9q.ampr.org ________________________________________________________________________ Name of Implementation: Morning Star SecureConnect Security Protocols: ESP, AH Security Transforms: ESP-DES, AH-MD5 Key Management: manual Lineage of Code: scratch Location of Source Code: proprietary Point of Contact: Karl Fox _______________________________________________________________________ Name of Implementation: Network Systems BorderGuard and Security Router Security Protocols: Proprietary Security Transforms: Des, Idea, 3DES, NSC1 (proprietary), MD5, Replay, D-H and RSA Key Management: Proprietary Lineage of Code: scratch Location of Source Code: proprietary Point of Contact: Ted Doty _______________________________________________________________________ Name of Implementation: NIST/NSA ESP/AH Implementation Security Protocols: ESP, AH Security Transforms: ESP-DES, AH-MD5, AH-SHA, and various others Key Management: manual, PF_SADB interface for key management daemons Lineage of Code: derived from BSD platforms. Successful installation on BSD/OS, NetBSD, FreeBSD, and DTOS Location of Source Code: Public distribution within the US expected March 1996. Point of Contact: glenn@snad.ncsl.nist.gov ________________________________________________________________________ Name of Implementation: NRL Security Protocols: ESP, AH -- for BOTH IPv4 and IPv6 Security Transforms: ESP-DES, AH-MD5 Key Management: manual, PF_KEY interface for key management daemons Lineage of Code: derived from and portable to 4.4-Lite BSD Location of Source Code: ftp://ftp.ripe.net/ipv6/nrl/IPv6_domestic.tar.gz for the September 1995 alpha release. January 1996 alpha-2 release is not yet at an ftp site, but should appear soon in the protected "US-only" archives at ftp.c2.org. Point of Contact: ipv6-bugs@cs.nrl.navy.mil _______________________________________________________________________ Name of Implementation: ONNET, FTP Software, Inc. Security Protocols: ESP, AH Security Transforms: ESP-DES, AH-MD5 Key Management: manual Location of Source Code: proprietary Point of Contact: Naganand Doraswamy naganand@ftp.com Name of Implementation: Raptor Systems Security Protocols: ESP, AH, both tunnel and transport modes Security Transforms: ESP-DES (32-bit and 64-bit IV), keyed-MD5 Key Management: manual Lineage of Code: proprietary Location of Source Code: proprietary Point of Contact: jkraemer@raptor.com _______________________________________________________________________ Name of Implementation: Sun ICG Security Protocols: ESP, AH, proprietary Security Transforms: ESP-DES, ESP-DES3, AH/KEYED MD5 Key Management: SKIP Lineage of Code: Location of Source Code: http://skip.incog.com Point of Contact: markson@incog.com _______________________________________________________________________ Name of Implementation: Secure Computing's Sidewinder Firewall Security Protocols: ESP, AH Security Transforms: DES, MD5 Key Management: manual Lineage of Code: BSD based Location of Source Code: proprietary Point of Contact: Troy de Jongh (dejongh@sctc.com) _______________________________________________________________________ Name of Implementation: TimeStep PERMIT Security Protocols: ESP, AH, proprietary Security Transforms: ESP-DES Key Management: proprietary, manual Lineage of Code: from scratch Location of Source Code: proprietary Point of Contact: Stephane Lacelle slacelle@timestep.com _______________________________________________________________________ Name of Implementation: Trusted Information Systems Gauntlet Security Protocols: ESP, AH Tunnel and Transport modes Security Transforms: ESP-DES, ESP-3DES Key Management: Custom, manual Lineage of Code: NRL derived, BSD/OS Location of Source Code: proprietary Point of Contact: Rick Murphy, rick@tis.com _______________________________________________________________________ Name of Implementation: USC/ISI Security Protocols: IPv4 AH Security Transforms: null, Internet checksum, MD5, proprietary null and Internet checksum for performance measurement Key Management: Statically configured keys implementation for performance measurement only Lineage of Code: SunOS 4.1.3, using "from scratch" and code adapted from the NRL IPv6 BSDI implementation Location of Source Code: to be announced in March Point of Contact: Joe Touch, touch@isi.edu _______________________________________________________________________ Name of Implementation: V-ONE SmartWall Security Protocols: ESP, AH Tunnel and Transport modes, V-ONE Mutual Authentication Security Transforms: ESP-DES, ESP-3DES, RC4, Stream-DES Key Management: Custom, manual Lineage of Code: NRL derived, BSD/OS Location of Source Code: proprietary Point of Contact: Jason Wang, jswang@v-one.com _______________________________________________________________________ ---- End of Message ---- Received: from [192.94.214.100] by neptune.TIS.COM id aa03065; 22 Mar 96 15:37 EST Received: by relay.tis.com; id PAA21115; Fri, 22 Mar 1996 15:39:01 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma021109; Fri, 22 Mar 96 15:38:34 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA26189; Fri, 22 Mar 96 15:37:26 EST Received: by relay.tis.com; id PAA21100; Fri, 22 Mar 1996 15:38:31 -0500 Received: from optima.cs.arizona.edu(192.12.69.5) by relay.tis.com via smap (V3.1) id xma021089; Fri, 22 Mar 96 15:38:19 -0500 Received: from avenir.cs.arizona.edu by optima.cs.arizona.edu (5.65c/15) via SMTP id AA25708; Fri, 22 Mar 1996 13:39:19 MST Date: Fri, 22 Mar 1996 13:39:16 MST From: Oliver Spatscheck Message-Id: <199603222039.AA12055@avenir.cs.arizona.edu> Received: by avenir.cs.arizona.edu; Fri, 22 Mar 1996 13:39:16 MST To: ipsec@TIS.COM Subject: IPsec Implementation Sender: ipsec-request@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- ______________________________________________________________________ Name of Implementation: IPSEC Organisation: University of Arizona. Which IP versions are supported: IPv4 Implements RFC-1825 & RFC-1826 AH: YES Implements RFC-1825 & RFC-1827 ESP: YES Implements RFC-1828 AH MD5: YES Implements RFC-1829 ESP DES-CBC:YES Other AH Implemented Transforms: none Other ESP Implemented Transforms: ESP-3DES Key Management: manual, Photuris (draft version 8) includeing elliptic curve groups. Platforms: xKernel Lineage of IPsec Code: University of Arizona Lineage of Key Mgmt Code: University of Arizona Location of Source Code: ftp://ftp.cs.arizona.edu/xkernel/xkernel.v3.2.security.tar.Z Point of Contact: ho@cs.arizona.edu Claimed Interoperability: KA9Q NOS (AH MD5, ESP DES-CBC), JI (Photuris, AH MD5) _______________________________________________________________________ Oliver - ----- Grad student and research assistant 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.2 iQCVAwUBMVMP8DnVPgUZ7uZJAQGdNAP+NwV40AAE4iocXYxgnvR1o8T50LMa0jXe ptILDf/EcCyJ4sfogvHkpNsDz0ZjRVwCo0t5TVhp4dwRniTN28RAPeB2zbxt6SGC SzZQUupgpp4H4+T78xa10puGNRjZnqTt5Mx8Yg5BoXxeGKeJEk7xRoTLE1XNWfJ/ 56sbCoHZryg= =b6+P -----END PGP SIGNATURE----- Received: from relay.tis.com by neptune.TIS.COM id aa04222; 22 Mar 96 16:24 EST Received: by relay.tis.com; id QAA22214; Fri, 22 Mar 1996 16:26:31 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma022205; Fri, 22 Mar 96 16:26:03 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA29926; Fri, 22 Mar 96 16:24:56 EST Received: by relay.tis.com; id QAA22198; Fri, 22 Mar 1996 16:26:01 -0500 Received: from arl-img-4.compuserve.com(198.4.7.4) by relay.tis.com via smap (V3.1) id xma022175; Fri, 22 Mar 96 16:25:46 -0500 Received: by arl-img-4.compuserve.com (8.6.10/5.950515) id QAA26834; Fri, 22 Mar 1996 16:24:24 -0500 Date: 22 Mar 96 16:23:07 EST From: Dave Schroeder <73543.2035@compuserve.com> To: Shelly Subject: We would like to participate in survey.. Message-Id: <960322212306_73543.2035_FHD19-2@CompuServe.COM> Sender: ipsec-request@neptune.tis.com Precedence: bulk The following 18 individuals and vendors have responded to the IPSEC implementation survey. ERPIPSEC ETHZ / ENskip GTFW-GD IBM JI KA9Q NOS Morning Star Network Systems NIST/NSA NRL Raptor Systems Sidewinder Sun ICG TimeStep PERMIT TIS Gauntlet USC/ISI V-ONE SmartWall The results of this survey (as of March 22, 1996) are provided below. Please submit any updates or new entries to the ipsec mailing list (ipsec@tis.com) ************************************************************ Posted: 22-Mar-1996, 16:23:02 EST From: Dave Schroeder, Director of Marketing The Software Group Limited / USA Office 209 N. Columbia, Chapel Hill, NC 27514 Tel: 919-933-6770 Fax: 919-933-8862 daves@software.group.com Compuserve: 73543,2035 URL = http://www.group.com ************************************************************ Received: from relay.tis.com by neptune.TIS.COM id aa03822; 24 Mar 96 9:35 EST Received: by relay.tis.com; id JAA04365; Sun, 24 Mar 1996 09:37:34 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma004363; Sun, 24 Mar 96 09:37:13 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02120; Sun, 24 Mar 96 09:35:57 EST Received: by relay.tis.com; id JAA04360; Sun, 24 Mar 1996 09:37:04 -0500 Received: from ktik0.ethz.ch(129.132.66.42) by relay.tis.com via smap (V3.1) id xma004358; Sun, 24 Mar 96 09:37:01 -0500 Received: from komsys-pc-gc.ethz.ch (dynppp40.dialup.ethz.ch [192.33.93.40]) by ktik0 (8.6.8.1/8.6.6) with SMTP id PAA25447; Sun, 24 Mar 1996 15:37:32 +0100 Message-Id: <2.2.32.19960324143927.0073bb2c@ktik0.ethz.ch> X-Sender: caronni@ktik0.ethz.ch X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 24 Mar 1996 15:39:27 +0100 To: ipsec@TIS.COM From: Germano Caronni Subject: IPSEC Key Mgmt Requirements Cc: skip@tik.ee.ethz.ch Sender: ipsec-request@neptune.tis.com Precedence: bulk Hello everybody, some weeks ago, I asked myself: What are THE requirements of the IPSEC working group where key management issues are concerned. After hunting the archives, and seeing some contradictory informations, none all to clear to me. I tried to collect them, and Paul Lambert was most helpful. (Thank you!) Please, could you read these, and send me feedback as to which are missing, and which are not valid anymore? I would like to have *one* document describing the requirements of this group. If I get enough feedback, I will try and make an updated version in about 10 days. Requirements, first try ----------------------- - Support AH/ESP security transforms on the IP Layer - Support optional use of Perfect Forward Secrecy. Mandatory to implement but optional to use. - Support Multiple Types of Security Exchanges What does this mean?? - Application Layer Key Management An application that establishes a connection must be able to indicate what keying material to use, and must be able to understand if the peer is authenticated or not. -- I personally would like to make this optional. Providing security on a per-host basis should be sufficient, should it not? - Use Public Key Techniques for Key Establishment such as establishing a shared secret using DH, or RSA - Support Discovery of applicable netowrk layer transforms, e.g. finding out if ESP-DES or ESP-DES3 or AH-MD5 or ... is to be used. - Support User Oriented Authentication Services - Support Optional Use of Anti-Clogging Techniques - Provide Authentication with Anonymity agains passive attackers - Anonymous Key Establishment (key exchange with no authentication) - Certificate Support for X.509 ?? Glossary -------- Perfect forward secrecy: It signifies that master encryption keys are short lived (ranging from minutes to weeks), and are (or can be) authenticated using long lived authentication keys. Security exchanges: I don't know. Please tell me. Anti-Clogging: A mechanism (such as cookie exchange) to limit the possibility of non-man-in-the-middle active attacks. Provides a weak (non-cryptographic) authentication of the initiator of a request that is usually computationally costly by exchanging a simple challenge-response. Thus denies the attacker the possibility to swamp a host with requests. Rationale --------- Each requirement should offer a rationale why it is there. Anybody having them at hand? Thank you very much & friendly greetings, Germano Caronni Received: from relay.tis.com by neptune.TIS.COM id aa24270; 25 Mar 96 13:00 EST Received: by relay.tis.com; id NAA14423; Mon, 25 Mar 1996 13:02:22 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma014414; Mon, 25 Mar 96 13:02:06 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08108; Mon, 25 Mar 96 13:00:52 EST Received: by relay.tis.com; id NAA14399; Mon, 25 Mar 1996 13:01:59 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma014390; Mon, 25 Mar 96 13:01:40 -0500 Received: from puli.cisco.com by interlock.ans.net with SMTP id AA15982 (InterLock SMTP Gateway 3.0 for ); Mon, 25 Mar 1996 13:02:32 -0500 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id KAA19344 for ipsec@ans.net; Mon, 25 Mar 1996 10:02:09 -0800 Date: Mon, 25 Mar 1996 10:02:09 -0800 From: Ran Atkinson Message-Id: <199603251802.KAA19344@puli.cisco.com> To: ipsec@ans.net Subject: ADMIN: Straw Poll Results on Key Mgmt Sender: ipsec-request@neptune.tis.com Precedence: bulk Folks, The key management requirements were published in the note Paul and I sent to the IPsec list on 12 February regarding Straw Poll Results. There ought not be a lot of mystery or confusion about them. Germano's recent note does not seem to be entirely the same as the published requirements. (NB: I've appended that note below in case folks didn't save it off.) For those new to the IETF process, the IETF does not mandate how functions are used but it does mandate how functions are implemented. So a conforming key management specification will mandate "implementation" of support for the key management requirements. This does not mean that a particular implementation of such a conforming specification is precluded from having options or knobs to permit the user to do things somewhat differently. Ran rja@cisco.com ----- Begin Included Message ----- From rja Mon Feb 12 14:47:36 1996 Date: Mon, 12 Feb 1996 14:47:32 -0800 From: Ran Atkinson Message-Id: <199602122247.OAA02865@puli.cisco.com> To: ipsec@ans.net Subject: ADMIN: Straw Poll Results on Key Mgmt Content-Length: 3005 % Date: Thu, 4 Jan 1996 10:44:11 -0800 % From: Ran Atkinson % % 1) Can the IPsec WG produce multiple standards-track % protocols for key management ? The consensus is that multiple standards-track protocols can be produced by the working group provided that there are significant differences in applicability among the protocols. The most common example that was mentioned was that multicast key distribution will probably need to be a separate protocol than unicast key distribution. % 2) If yes to the above, then can a protocol not conforming % to the WG requirements for a key management protocol % be on the IETF standards-track ? The consensus is NO. All standards-track protocols MUST conform with the IPsec WG requirements. As of now there are 2 main agreed-upon requirements: (1) Perfect Forward Secrecy (PFS) must be available to users of the protocol that desire PFS. This means that a conforming protocol might have a mode that provides PFS and another mode that doesn't, for example. (2) The key management protocol must be able to negotiate/ indicate the value of each of the components of an IPsec Security Association (RFC-1825) with/to all of the parties to that IPsec Security Association. Users are not necessarily required to use all of those components, but the protocol MUST be capable of providing that support and conforming implementations of the protocol MUST support negotiation/indication of all of those components. % 3) If yes to both of the above, should the WG chairs write up a formal % applicability statement to be accompany each standards-track % key management protocol so that the intended use of that protocol % is made clear? There is overwhelming (possibly unanimous) consensus that the WG chairs should be required to write up a formal applicability statement to accompany each standards-track key management protocol so that the intended use of that protocol is made clear in an RFC. Hence, the co-chairs will do this if/when some protocol moves to standards-track RFC. CONCLUSIONS: (1) None of the proposals currently online appear to fully meet all of the requirements, though it does appear that all of them could be modified to meet all of the requirements. (2) None of the current proposals can go to Last Call at this time because of (1). (3) All of the editors of the current documents should work on refining their proposals to fully meet all of the WG requirements. The co-chairs look forward to seeing revised proposals in LA. In a situation like this one where the WG consensus is clear, the WG chairs do not have any real discretion on handling matters. We are forbidden by IETF standards process from doing anything contrary to WG consensus, so our hands are completely tied on holding a Last Call at this time. Paul Lambert Randall Atkinson ----- End Included Message ----- Received: from relay.tis.com by neptune.TIS.COM id aa24346; 25 Mar 96 13:04 EST Received: by relay.tis.com; id NAA14560; Mon, 25 Mar 1996 13:06:52 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma014554; Mon, 25 Mar 96 13:06:36 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08268; Mon, 25 Mar 96 13:05:17 EST Received: by relay.tis.com; id NAA14544; Mon, 25 Mar 1996 13:06:25 -0500 Received: from ktik0.ethz.ch(129.132.66.42) by relay.tis.com via smap (V3.1) id xma014534; Mon, 25 Mar 96 13:06:15 -0500 Received: from kom30.ethz.ch (kom30 [129.132.66.8]) by ktik0 (8.6.8.1/8.6.6) with ESMTP id TAA02742; Mon, 25 Mar 1996 19:01:11 +0100 From: Germano Caronni Received: (caronni@localhost) by kom30.ethz.ch (8.6.8.1/8.6.6) id TAA08343; Mon, 25 Mar 1996 19:01:08 +0100 Message-Id: <199603251801.TAA08343@kom30.ethz.ch> Subject: Re: IPSEC Key Mgmt Requirements To: ipsec@TIS.COM Date: Mon, 25 Mar 1996 19:01:07 +0100 (MET) Cc: palamber@us.oracle.com, jis@mit.edu, rja@cisco.com In-Reply-To: <199603251704.JAA16536@puli.cisco.com> from "Ran Atkinson" at Mar 25, 96 09:04:02 am X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Content-Length: 444 Sender: ipsec-request@neptune.tis.com Precedence: bulk I have been informed that my question & proposal about Key Management Requirements is out of order. I apologize to the group for the unneeded mail, and am sorry for mis-stepping. *** Everybody please ignore my previous mail. *** I hereby retract my question & proposal. Could somebody of you please send me the official WG requirements, as they are valid **now** ? My excuses & thank you very much for your patience, Germano Caronni Received: from relay.tis.com by neptune.TIS.COM id aa27296; 25 Mar 96 15:48 EST Received: by relay.tis.com; id PAA17660; Mon, 25 Mar 1996 15:50:47 -0500 From: gmcgreal@ire.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma017648; Mon, 25 Mar 96 15:50:24 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18410; Mon, 25 Mar 96 15:49:10 EST Received: by relay.tis.com; id PAA17645; Mon, 25 Mar 1996 15:50:18 -0500 Received: from uu5.psi.com(38.145.226.3) by relay.tis.com via smap (V3.1) id xma017635; Mon, 25 Mar 96 15:49:46 -0500 Received: by uu5.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA03633 for ; Mon, 25 Mar 96 15:33:33 -0500 Received: from cc:Mail by uu1023.ire.com id AA827795544 Mon, 25 Mar 96 15:12:24 Date: Mon, 25 Mar 96 15:12:24 Encoding: 1223 Text Message-Id: <9602258277.AA827795544@uu1023.ire.com> To: ipsec@TIS.COM, Ran Atkinson Subject: Re: Request for Implementation Status Sender: ipsec-request@neptune.tis.com Precedence: bulk ______________________________ Reply Separator _________________________________ Name of Implementation: SafeNet Organisation: Information Resources Engineering, Inc. Which IP versions are supported: IPv4 Implements RFC-1825 & RFC-1826 AH: Planned Implements RFC-1825 & RFC-1827 ESP: YES Implements RFC-1828 AH MD5: Planned, Partial Implements RFC-1829 ESP DES-CBC:In Progress, Partial Other AH Implemented Transforms: none Other ESP Implemented Transforms: ESP-DES-Counter-ANSI X9.9 Key Management: ANSI X9.17ckd, ANSI X9.57, ANSI X9.42 (in progress) SKIP (in progess) Northern Telecom (planned) Platforms: V.34 modem IP over PPP (SafeNet/Dial) (OS independent), Ethernet gateway (SafeNet/LAN), Ethernet host interface (SafeNet/LAN) Lineage of IPsec Code: Information Resources Engineering, Inc. Lineage of Key Mgmt Code: Information Resources Engineering, Inc. Location of Source Code: proprietary Point of Contact: gmcgreal@ire.com 410-931-7500 FAX 410-931-7524 Claimed Interoperability: Sun (in progress), S/WAN (in progress), Northern (planned) _______________________________________________________________________ Received: from relay.tis.com by neptune.TIS.COM id aa02706; 25 Mar 96 22:11 EST Received: by relay.tis.com; id WAA22714; Mon, 25 Mar 1996 22:13:46 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma022712; Mon, 25 Mar 96 22:13:17 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28416; Mon, 25 Mar 96 22:12:09 EST Received: by relay.tis.com; id WAA22709; Mon, 25 Mar 1996 22:13:16 -0500 Received: from ns.research.att.com(192.20.225.4) by relay.tis.com via smap (V3.1) id xma022707; Mon, 25 Mar 96 22:13:03 -0500 Received: from research.att.com by ns; Mon Mar 25 22:12:06 EST 1996 Received: from smb.research.att.com by research; Mon Mar 25 22:11:24 EST 1996 Received: from smb.research.att.com (smb@localhost) by smb.research.att.com (8.6.12/8.6.10) with ESMTP id WAA04910 for ; Mon, 25 Mar 1996 22:11:22 -0500 Message-Id: <199603260311.WAA04910@smb.research.att.com> X-Authentication-Warning: smb.research.att.com: smb owned process doing -bs From: Steve Bellovin To: ipsec@TIS.COM Subject: new draft of my paper Date: Mon, 25 Mar 1996 22:11:21 -0500 Sender: ipsec-request@neptune.tis.com Precedence: bulk I normally wouldn't announce a new version of a draft paper this soon; however, David Wagner has found a fascinating new attack called the ``short block'' attack. It's described in Section 3.8. The attack can recover read most user-to-host traffic on a large class of telnet sessions (though not all), using 2^8 known plaintext blocks and a simple active attack. This attack can be defeated if AH is used outside of ESP, protecting the integrity of the encrypted message (i.e., IP-AH-ESP-TCP is safe); using AH inside of ESP is not safe. The paper is in ftp://ftp.research.att.com/dist/smb/badesp.ps Received: from relay.tis.com by neptune.TIS.COM id aa10537; 26 Mar 96 7:49 EST Received: by relay.tis.com; id HAA27909; Tue, 26 Mar 1996 07:51:40 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma027905; Tue, 26 Mar 96 07:51:12 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08215; Tue, 26 Mar 96 07:50:02 EST Received: by relay.tis.com; id HAA27902; Tue, 26 Mar 1996 07:51:10 -0500 Received: from unknown(204.189.94.148) by relay.tis.com via smap (V3.1) id xma027899; Tue, 26 Mar 96 07:50:44 -0500 Received: by pilotx.firewall.is.chrysler.com; id HAA16512; Tue, 26 Mar 1996 07:51:44 -0500 Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilotx.is.chrysler.com via smap (g3.0.1) id sma016504; Tue, 26 Mar 96 07:51:19 -0500 Received: from rgm3 by clhubgw1.is.chrysler.com (SMI-8.6/SMI-4.1) id HAA23571; Tue, 26 Mar 1996 07:53:26 -0500 Message-Id: <2.2.32.19960326124754.00bc0d00@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Mar 1996 07:47:54 -0500 To: Steve Bellovin , ipsec@TIS.COM From: Robert Moskowitz Subject: Re: new draft of my paper Sender: ipsec-request@neptune.tis.com Precedence: bulk At 10:11 PM 3/25/96 -0500, Steve Bellovin wrote: >I normally wouldn't announce a new version of a draft paper this >soon; however, David Wagner has found a fascinating new attack >called the ``short block'' attack. It's described in Section 3.8. >The attack can recover read most user-to-host traffic on a large >class of telnet sessions (though not all), using 2^8 known plaintext >blocks and a simple active attack. This attack can be defeated if AH >is used outside of ESP, protecting the integrity of the encrypted >message (i.e., IP-AH-ESP-TCP is safe); using AH inside of ESP is not >safe. Excuse, please, my naivety, but to what extent would a compression before encryption defeat known plaintext attacks? It would seem that compression could eliminate all known plaintext unless the plaintext was so long a block to always get compressed the same way. Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.tis.com by neptune.TIS.COM id aa10633; 26 Mar 96 7:56 EST Received: by relay.tis.com; id HAA27960; Tue, 26 Mar 1996 07:58:40 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma027956; Tue, 26 Mar 96 07:58:11 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08510; Tue, 26 Mar 96 07:57:02 EST Received: by relay.tis.com; id HAA27953; Tue, 26 Mar 1996 07:58:10 -0500 Received: from unknown(192.20.225.4) by relay.tis.com via smap (V3.1) id xma027951; Tue, 26 Mar 96 07:58:02 -0500 Received: from research.att.com by ns; Tue Mar 26 07:57:14 EST 1996 Received: from raptor.research.att.com by research; Tue Mar 26 07:53:49 EST 1996 Received: from roc (localhost [127.0.0.1]) by raptor.research.att.com (8.7.5/8.7) with ESMTP id HAA06625; Tue, 26 Mar 1996 07:53:49 -0500 (EST) Message-Id: <199603261253.HAA06625@raptor.research.att.com> To: Robert Moskowitz Cc: ipsec@TIS.COM Subject: Re: new draft of my paper Date: Tue, 26 Mar 1996 07:53:49 -0500 From: Steven Bellovin Sender: ipsec-request@neptune.tis.com Precedence: bulk At 10:11 PM 3/25/96 -0500, Steve Bellovin wrote: >I normally wouldn't announce a new version of a draft paper this >soon; however, David Wagner has found a fascinating new attack >called the ``short block'' attack. It's described in Section 3.8. >The attack can recover read most user-to-host traffic on a large >class of telnet sessions (though not all), using 2^8 known plaintext >blocks and a simple active attack. This attack can be defeated if AH >is used outside of ESP, protecting the integrity of the encrypted >message (i.e., IP-AH-ESP-TCP is safe); using AH inside of ESP is not >safe. Excuse, please, my naivety, but to what extent would a compression bef ore encryption defeat known plaintext attacks? It would seem that compres sion could eliminate all known plaintext unless the plaintext was so long a block to always get compressed the same way. Compression would help, but perhaps not that much -- there's still the IP header, the compression dictionary, any incompressible sections, etc. 2^8 blocks isn't that much, and because of the way CBC works even repeated plaintext like IP header addresses will be different each time. Received: from relay.tis.com by neptune.TIS.COM id aa13071; 26 Mar 96 10:02 EST Received: by relay.tis.com; id JAA29582; Tue, 26 Mar 1996 09:56:10 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma029580; Tue, 26 Mar 96 09:55:42 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA14348; Tue, 26 Mar 96 09:54:33 EST Received: by relay.tis.com; id JAA29577; Tue, 26 Mar 1996 09:55:40 -0500 Received: from servo.qualcomm.com(129.46.128.14) by relay.tis.com via smap (V3.1) id xma029573; Tue, 26 Mar 96 09:55:15 -0500 Received: (from karn@localhost) by servo.qualcomm.com (8.7.3/8.7.2/1.7.1) id GAA27027; Tue, 26 Mar 1996 06:56:10 -0800 (PST) Date: Tue, 26 Mar 1996 06:56:10 -0800 (PST) From: Phil Karn Message-Id: <199603261456.GAA27027@servo.qualcomm.com> To: smb@research.att.com Cc: rgm3@is.chrysler.com, ipsec@TIS.COM In-Reply-To: <199603261253.HAA06625@raptor.research.att.com> (message from Steven Bellovin on Tue, 26 Mar 1996 07:53:49 -0500) Subject: Re: new draft of my paper Sender: ipsec-request@neptune.tis.com Precedence: bulk I seem to recall that I originally proposed padding with zeros, with the receiver required to drop packets that didn't comply. My original thinking was to provide some measure against garbage flooding, but it seems like that also helps resist Wagner's attack. I don't remember how the text got changed, but it's not important. The question is, do we want to change the ESP spec re padding? Phil Received: from relay.tis.com by neptune.TIS.COM id aa16228; 26 Mar 96 12:51 EST Received: by relay.tis.com; id MAA02221; Tue, 26 Mar 1996 12:53:50 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma002217; Tue, 26 Mar 96 12:53:21 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA24021; Tue, 26 Mar 96 12:52:12 EST Received: by relay.tis.com; id MAA02211; Tue, 26 Mar 1996 12:53:20 -0500 Received: from ns.research.att.com(192.20.225.4) by relay.tis.com via smap (V3.1) id xma002205; Tue, 26 Mar 96 12:53:02 -0500 Received: from research.att.com by ns; Tue Mar 26 12:52:08 EST 1996 Received: from raptor.research.att.com by research; Tue Mar 26 12:47:19 EST 1996 Received: from roc (loopback [127.0.0.1]) by raptor.research.att.com (8.7.5/8.7) with ESMTP id MAA11204; Tue, 26 Mar 1996 12:47:18 -0500 (EST) Message-Id: <199603261747.MAA11204@raptor.research.att.com> To: Phil Karn Cc: rgm3@is.chrysler.com, ipsec@TIS.COM Subject: Re: new draft of my paper Date: Tue, 26 Mar 1996 12:47:18 -0500 From: Steven Bellovin Sender: ipsec-request@neptune.tis.com Precedence: bulk I seem to recall that I originally proposed padding with zeros, with the receiver required to drop packets that didn't comply. My original thinking was to provide some measure against garbage flooding, but it seems like that also helps resist Wagner's attack. Yup. I don't remember how the text got changed, but it's not important. The question is, do we want to change the ESP spec re padding? We could make that change, but I suspect that it's a palliative measure at best. The real answer is integrity-checking, done right. Received: from relay.tis.com by neptune.TIS.COM id aa23270; 26 Mar 96 19:40 EST Received: by relay.tis.com; id TAA09018; Tue, 26 Mar 1996 19:42:36 -0500 From: hugo@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma009006; Tue, 26 Mar 96 19:42:07 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13236; Tue, 26 Mar 96 19:40:58 EST Received: by relay.tis.com; id TAA09002; Tue, 26 Mar 1996 19:42:06 -0500 Message-Id: <199603270042.TAA09002@relay.tis.com> Received: from watson.ibm.com(129.34.139.4) by relay.tis.com via smap (V3.1) id xma008998; Tue, 26 Mar 96 19:41:51 -0500 Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 3913; Tue, 26 Mar 96 19:41:49 EST Date: Tue, 26 Mar 96 19:38:56 EST To: ipsec@TIS.COM Cc: smb@research.att.com Subject: new draft of my paper Sender: ipsec-request@neptune.tis.com Precedence: bulk Ref: Your note of Tue, 26 Mar 1996 12:47:18 -0500 (attached) smb@research.att.com says > > We could make that change, but I suspect that it's a palliative measure > at best. The real answer is integrity-checking, done right. Bravo, bravo! Let's do it right (as decided in LA). Hugo Received: from relay.tis.com by neptune.TIS.COM id aa07034; 27 Mar 96 12:23 EST Received: by relay.tis.com; id MAA20342; Wed, 27 Mar 1996 12:25:02 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma020335; Wed, 27 Mar 96 12:24:34 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA14761; Wed, 27 Mar 96 12:23:24 EST Received: by relay.tis.com; id MAA20332; Wed, 27 Mar 1996 12:24:32 -0500 Received: from copilot.is.chrysler.com(204.189.94.148) by relay.tis.com via smap (V3.1) id xma020320; Wed, 27 Mar 96 12:24:01 -0500 Received: by pilotx.firewall.is.chrysler.com; id MAA11640; Wed, 27 Mar 1996 12:24:41 -0500 Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilotx.is.chrysler.com via smap (g3.0.1) id sma011627; Wed, 27 Mar 96 12:24:13 -0500 Received: from rgm3 by clhubgw1.is.chrysler.com (SMI-8.6/SMI-4.1) id MAA16027; Wed, 27 Mar 1996 12:26:19 -0500 Message-Id: <2.2.32.19960327172410.00caf354@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Mar 1996 12:24:10 -0500 To: ipsec@TIS.COM From: Robert Moskowitz Subject: PPTP ???? Sender: ipsec-request@neptune.tis.com Precedence: bulk Has anyone looked into this new PPTP ? That is Point-to-point Tunnel Protocol? It is being marketed much to what many of us are working IPSec (and probably MobileIP).... Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.tis.com by neptune.TIS.COM id aa08100; 27 Mar 96 13:09 EST Received: by relay.tis.com; id NAA20970; Wed, 27 Mar 1996 13:11:32 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma020947; Wed, 27 Mar 96 13:11:03 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16546; Wed, 27 Mar 96 13:09:54 EST Received: by relay.tis.com; id NAA20944; Wed, 27 Mar 1996 13:11:02 -0500 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1) id xma020940; Wed, 27 Mar 96 13:10:50 -0500 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id NAA02838; Wed, 27 Mar 1996 13:11:32 -0500 (EST) Message-Id: <199603271811.NAA02838@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Robert Moskowitz Cc: ipsec@TIS.COM Subject: Re: PPTP ???? In-Reply-To: Your message of "Wed, 27 Mar 1996 12:24:10 EST." <2.2.32.19960327172410.00caf354@pop3hub.is.chrysler.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 27 Mar 1996 13:11:31 -0500 From: "Perry E. Metzger" Sender: ipsec-request@neptune.tis.com Precedence: bulk Robert Moskowitz writes: > Has anyone looked into this new PPTP ? That is Point-to-point > Tunnel Protocol? > > It is being marketed much to what many of us are working IPSec (and probably > MobileIP).... Haven't heard of it. Who has done it, and where? .pm Received: from relay.tis.com by neptune.TIS.COM id aa08845; 27 Mar 96 13:42 EST Received: by relay.tis.com; id NAA21498; Wed, 27 Mar 1996 13:44:32 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma021493; Wed, 27 Mar 96 13:44:04 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18455; Wed, 27 Mar 96 13:42:54 EST Received: by relay.tis.com; id NAA21488; Wed, 27 Mar 1996 13:44:02 -0500 Received: from unknown(199.71.190.98) by relay.tis.com via smap (V3.1) id xma021482; Wed, 27 Mar 96 13:43:36 -0500 Received: by janus.border.com id <18433-1>; Wed, 27 Mar 1996 13:45:03 -0500 Message-Id: <96Mar27.134503est.18433-1@janus.border.com> To: perry@piermont.com Cc: Robert Moskowitz , ipsec@TIS.COM Subject: Re: PPTP ???? References: <199603271811.NAA02838@jekyll.piermont.com> In-Reply-To: perry's message of "Wed, 27 Mar 1996 13:11:31 -0500". <199603271811.NAA02838@jekyll.piermont.com> From: "C. Harald Koch" Organization: Border Network Technologies Inc. Phone: +1 416 368 7157 X-Uri: Date: Wed, 27 Mar 1996 13:44:08 -0500 Sender: ipsec-request@neptune.tis.com Precedence: bulk In message <199603271811.NAA02838@jekyll.piermont.com>, "Perry E. Metzger" writes: > > Robert Moskowitz writes: > > Has anyone looked into this new PPTP ? That is Point-to-point > > Tunnel Protocol? > > > > Haven't heard of it. Who has done it, and where? It's from Microsoft and a couple of terminal server people. It's PPP from a remote dialup hub tunnelled (over IP) to your home office PPP server for "secure remote access", i.e. user dials into local ISP; ISP relays PPP packets directly to head-office, encapsulated inside IP; user thinks he's got a direct PPP link to the office, but with a local telephone call. I haven't looked closely at the spec, but I vaguely remember some sort of encryption or authentication on the tunnel portion of the link... A press release is at The spec is available from: and In Microsoft Word format, of course :-( Naturally, any errors in this description are mine, and no doubt the result of bugs in my wetware... -- C. Harald Koch | Border Network Technologies Inc. chk@border.com | Senior System Developer +1 416 368 7157 (voice) | 20 Toronto Street, Suite 400, Toronto ON M5C 2B8 +1 416 368 7789 (fax) | Tary: a unit of intelligence; As in "military". Received: from relay.tis.com by neptune.TIS.COM id aa26573; 28 Mar 96 10:20 EST Received: by relay.tis.com; id KAA07322; Thu, 28 Mar 1996 10:22:59 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma007319; Thu, 28 Mar 96 10:22:31 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA26154; Thu, 28 Mar 96 10:21:22 EST Received: by relay.tis.com; id KAA07303; Thu, 28 Mar 1996 10:22:29 -0500 Received: from joseph.cs.berkeley.edu(128.32.37.122) by relay.tis.com via smap (V3.1) id xma007294; Thu, 28 Mar 96 10:22:00 -0500 Received: (from daw@localhost) by joseph.cs.berkeley.edu (8.6.12/8.6.9) id HAA08984; Thu, 28 Mar 1996 07:24:23 -0800 To: ipsec@TIS.COM Path: not-for-mail From: David Wagner Newsgroups: isaac.lists.ipsec Subject: Re: new draft of my paper Date: 28 Mar 1996 07:23:56 -0800 Organization: ISAAC Group, UC Berkeley Lines: 12 Message-Id: <4jeauc$8oc@joseph.cs.berkeley.edu> References: <199603260311.WAA04910@smb.research.att.com> Reply-To: daw@cs.berkeley.edu Sender: ipsec-request@neptune.tis.com Precedence: bulk In article <199603260311.WAA04910@smb.research.att.com>, Steve Bellovin wrote: > I normally wouldn't announce a new version of a draft paper this > soon; however, David Wagner has found a fascinating new attack > called the ``short block'' attack. I should point out that the current state of the art attack described in his paper contains numerous significant contributions from Steve Bellovin as well; credit where credit is due. I thank him for his help! -- Dave Wagner Received: from relay.tis.com by neptune.TIS.COM id aa05281; 28 Mar 96 16:53 EST Received: by relay.tis.com; id QAA16322; Thu, 28 Mar 1996 16:55:57 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma016315; Thu, 28 Mar 96 16:55:29 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA17188; Thu, 28 Mar 96 16:54:19 EST Received: by relay.tis.com; id QAA16311; Thu, 28 Mar 1996 16:55:27 -0500 Received: from mail11.digital.com(192.208.46.10) by relay.tis.com via smap (V3.1) id xma016306; Thu, 28 Mar 96 16:55:25 -0500 Received: from vanna.ljo.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA31338; Thu, 28 Mar 1996 16:45:27 -0500 Received: from ibgcore2.ibg.ljo.dec.com by vanna.ljo.dec.com; (5.65/1.1.8.2/10Oct94-8.2MPM) id AA02661; Thu, 28 Mar 1996 16:38:16 -0500 Received: from ibgmail.ljo.dec.com by ibgcore1.ibg.ljo.dec.com; (5.65v3.2/1.1.8.2/17Oct95-0542PM) id AA26297; Thu, 28 Mar 1996 12:43:27 -0500 Received: from plugh.ibg.ljo.dec.com by ibgmail.ljo.dec.com; (5.65/1.1.8.2/01Jan96-0534PM) id AA14451; Thu, 28 Mar 1996 12:43:22 -0500 Received: by plugh.ibg.ljo.dec.com; (5.65v3.2/1.1.8.2/29Aug95-1247PM) id AA01221; Thu, 28 Mar 1996 12:43:20 -0500 Date: Thu, 28 Mar 1996 12:43:20 -0500 (EST) From: Jeff Needle To: "Perry E. Metzger" Cc: ipsec@TIS.COM Subject: Re: PPTP ???? In-Reply-To: <199603271811.NAA02838@jekyll.piermont.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk > > Has anyone looked into this new PPTP ? That is Point-to-point > > Tunnel Protocol? > > > > It is being marketed much to what many of us are working IPSec (and probably > > MobileIP).... > > Haven't heard of it. Who has done it, and where? Microsoft is doing it, with the help of 3Com, Ascend, ECI Telematics, and U.S. Robotics. Information is available at: ftp://ftp.microsoft.com/developr/drg/pptp It's Microsoft's stab at tunneling with Windows NT. Jeff +------------------------------+------------------------------------------+ |Jeff Needle |needle@ibg.ljo.dec.com | |Digital Equipment Corporation | http://www.tiac.net/users/needle | |30 Porter Road LJO2-1/D13 |Phone: 508-486-2160 | |Littleton, MA 01460-1446 |FAX: 508-467-2851 | +-------------------------------------------------------------------------+ |Internet Software Business Unit, Technical Support | +------------------------------+------------------------------------------+ Received: from relay.tis.com by neptune.TIS.COM id aa07560; 28 Mar 96 18:54 EST Received: by relay.tis.com; id SAA18509; Thu, 28 Mar 1996 18:57:14 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma018502; Thu, 28 Mar 96 18:56:47 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21377; Thu, 28 Mar 96 18:55:36 EST Received: by relay.tis.com; id SAA18499; Thu, 28 Mar 1996 18:56:44 -0500 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1) id xma018495; Thu, 28 Mar 96 18:56:20 -0500 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id SAA11430; Thu, 28 Mar 1996 18:54:51 -0500 (EST) Message-Id: <199603282354.SAA11430@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Jeff Needle Cc: ipsec@TIS.COM Subject: Re: PPTP ???? In-Reply-To: Your message of "Thu, 28 Mar 1996 12:43:20 EST." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Thu, 28 Mar 1996 18:54:50 -0500 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Jeff Needle writes: > Microsoft is doing it, with the help of 3Com, Ascend, ECI Telematics, and > U.S. Robotics. Information is available at: > > ftp://ftp.microsoft.com/developr/drg/pptp > > It's Microsoft's stab at tunneling with Windows NT. All the docs are in word, which I don't have. Does anyone have a translation into ASCII? .pm Received: from relay.tis.com by neptune.TIS.COM id aa09254; 28 Mar 96 20:50 EST Received: by relay.tis.com; id UAA20628; Thu, 28 Mar 1996 20:53:14 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma020626; Thu, 28 Mar 96 20:52:50 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA23408; Thu, 28 Mar 96 20:51:35 EST Received: by relay.tis.com; id UAA20623; Thu, 28 Mar 1996 20:52:44 -0500 Received: from mail13.digital.com(192.208.46.30) by relay.tis.com via smap (V3.1) id xma020621; Thu, 28 Mar 96 20:52:33 -0500 Received: from vanna.ljo.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA03070; Thu, 28 Mar 1996 20:51:01 -0500 Received: from ibgcore2.ibg.ljo.dec.com by vanna.ljo.dec.com; (5.65/1.1.8.2/10Oct94-8.2MPM) id AA06988; Thu, 28 Mar 1996 20:40:37 -0500 Received: from tunnel2.imc.das.dec.com by ibgcore2.ibg.ljo.dec.com; (5.65v3.2/1.1.8.2/23Oct95-1203AM) id AA03980; Thu, 28 Mar 1996 20:47:31 -0500 Message-Id: <2.2.32.19960329015132.00697f14@pop.ibg.ljo.dec.com> X-Sender: needle@pop.ibg.ljo.dec.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 28 Mar 1996 20:51:32 -0500 To: perry@piermont.com From: Jeff Needle Subject: Re: PPTP ???? Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk >All the docs are in word, which I don't have. Does anyone have a >translation into ASCII? Sure, I've put it up at http://www.spitbrook.destek.com:81/pptp.txt. While you're there, you can read about and download an evaluation copy of the solution that Digital is shipping today ;-). Jeff +------------------------------+------------------------------------------+ |Jeff Needle |needle@ibg.ljo.dec.com | |Digital Equipment Corporation | http://www.tiac.net/users/needle | |30 Porter Road LJO2-1/D13 |Phone: 508-486-2160 | |Littleton, MA 01460-1446 |FAX: 508-467-2851 | +-------------------------------------------------------------------------+ | Internet Software Business Unit, Technical Support | | *** via the Digital Internet Tunnel *** | +------------------------------+------------------------------------------+ Received: from relay.tis.com by neptune.TIS.COM id aa19634; 29 Mar 96 9:00 EST Received: by relay.tis.com; id JAA27295; Fri, 29 Mar 1996 09:02:41 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma027287; Fri, 29 Mar 96 09:02:13 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06288; Fri, 29 Mar 96 09:01:04 EST Received: by relay.tis.com; id JAA27281; Fri, 29 Mar 1996 09:02:11 -0500 Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay.tis.com via smap (V3.1) id xma027265; Fri, 29 Mar 96 09:01:48 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa15271; 29 Mar 96 9:02 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: ipsec@TIS.COM From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-ipsec-hmac-md5-00.txt Date: Fri, 29 Mar 96 09:02:30 -0500 Message-Id: <9603290902.aa15271@IETF.CNRI.Reston.VA.US> Sender: ipsec-approval@neptune.tis.com Precedence: bulk --NextPart A New 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. Title : HMAC-MD5: Keyed-MD5 for Message Authentication Author(s) : H. Krawczyk, M. Bellare, R. Canetti Filename : draft-ietf-ipsec-hmac-md5-00.txt Pages : 8 Date : 03/28/1996 This document describes a keyed-MD5 mechanism (called HMAC-MD5) for use as a message authentication code (or, integrity check value). It is mainly intended for integrity verification of information transmitted over open networks (e.g., Internet) between parties that share a common secret key. The proposed mechanism combines the (key-less) MD5 hash function [RFC-1321] with a shared secret key. The description of HMAC-MD5 in this document is independent of its use in any particular protocol. An analogous mechanism can be used in combination with other iterative hash functions, e.g., SHA. 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-hmac-md5-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-hmac-md5-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) 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-hmac-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. For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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: <19960328141449.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-hmac-md5-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-hmac-md5-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960328141449.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- Received: from relay.tis.com by neptune.TIS.COM id aa23006; 29 Mar 96 11:36 EST Received: by relay.tis.com; id LAA00211; Fri, 29 Mar 1996 11:39:11 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma000203; Fri, 29 Mar 96 11:38:43 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA15239; Fri, 29 Mar 96 11:37:34 EST Received: by relay.tis.com; id LAA00192; Fri, 29 Mar 1996 11:38:41 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma000175; Fri, 29 Mar 96 11:38:20 -0500 Received: from RSA.COM by interlock.ans.net with SMTP id AA25430 (InterLock SMTP Gateway 3.0 for ); Fri, 29 Mar 1996 11:39:09 -0500 Received: from snail.rsa.com by RSA.COM with SMTP id AA15426; Fri, 29 Mar 96 08:29:39 PST Received: from cc:Mail by snail.rsa.com id AA828117333; Fri, 29 Mar 96 08:40:20 PST Date: Fri, 29 Mar 96 08:40:20 PST From: baldwin Message-Id: <9602298281.AA828117333@snail.rsa.com> To: ipsec@ans.net Cc: rivest@theory.lcs.mit.edu Subject: draft-baldwin-esp-rc5-00.txt Sender: ipsec-approval@neptune.tis.com Precedence: bulk The draft we have written on how to use RC5 in an IPsec ESP is now on the IETF file servers. The access information is given below. All comments and suggestions are appreciated. --Bob Baldwin A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The ESP RC5 Transform Author(s) : B. W. Howard and R. W. Baldwin Filename : draft-baldwin-esp-rc5-00.txt Pages : 10 Date : 03/20/1996 This document describes the RC5-CBC security transform for the IP Encapsulating Security Payload (ESP) based on the DES-CBC transform described in RFC-1829 and RFC-1827. The RC5 cipher allows for greater performance, security and exportability than the DES cipher. A companion document [Baldwin96] describes RC5 in sufficient detail to construct interoperable systems. 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-baldwin-esp-rc5-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-baldwin-esp-rc5-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-baldwin-esp-rc5-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. For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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: <19960328141449.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-baldwin-esp-rc5-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-baldwin-esp-rc5-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960328141449.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- Received: from relay.tis.com by neptune.TIS.COM id aa23048; 29 Mar 96 11:37 EST Received: by relay.tis.com; id LAA00231; Fri, 29 Mar 1996 11:39:41 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma000217; Fri, 29 Mar 96 11:39:13 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA15249; Fri, 29 Mar 96 11:38:04 EST Received: by relay.tis.com; id LAA00212; Fri, 29 Mar 1996 11:39:11 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma000207; Fri, 29 Mar 96 11:39:09 -0500 Received: from RSA.COM by interlock.ans.net with SMTP id AA25467 (InterLock SMTP Gateway 3.0 for ); Fri, 29 Mar 1996 11:40:09 -0500 Received: from snail.rsa.com by RSA.COM with SMTP id AA15446; Fri, 29 Mar 96 08:30:39 PST Received: from cc:Mail by snail.rsa.com id AA828117393; Fri, 29 Mar 96 08:41:19 PST Date: Fri, 29 Mar 96 08:41:19 PST From: baldwin Message-Id: <9602298281.AA828117393@snail.rsa.com> To: ipsec@ans.net, rivest@theory.lcs.mit.edu Subject: draft-baldwin-rc5-00.txt Sender: ipsec-approval@neptune.tis.com Precedence: bulk The draft that describes how to create interoperable implementations of the RC5 cipher and its various modes is now available for the IETF file servers. We would appreciate any comments and suggestions on this draft. --Bob Baldwin A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms Author(s) : R. W. Baldwin and R. L. Rivest Filename : draft-baldwin-rc5-00.txt Pages : 35 Date : 03/20/1996 This document defines four ciphers with enough detail to ensure interoperability between different implementations. The first cipher is the raw RC5 block cipher. The RC5 cipher takes a fixed size input block and produces a fixed sized output block using a transformation that depends on a key. The second cipher, RC5-CBC, is the Cipher Block Chaining (CBC) mode for RC5. It can process messages whose length is a multiple of the RC5 block size. The third cipher, RC5-CBC-Pad, handles plaintext of any length, though the ciphertext will be longer than the plaintext by at most the size of a single RC5 block. The RC5-CTS cipher is the Cipher Text Stealing mode of RC5, which handles plaintext of any length and the ciphertext length matches the plaintext length. The RC5 cipher was invented by Professor Ronald L. Rivest of the Massachusetts Institute of Technology in 1994. It is a very fast and simple algorithm that is parameterized by the block size, the number of rounds, and key length. These parameters can be adjusted to meet different goals for security, performance, and exportability. RSA Data Security Incorporated has filed a patent application on the RC5 cipher and for trademark protection for RC5, RC5-CBC, RC5-CBC-Pad, RC5-CTS and assorted variations. 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-baldwin-rc5-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-baldwin-rc5-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-baldwin-rc5-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. For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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: <19960328141449.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-baldwin-rc5-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-baldwin-rc5-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960328141449.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- Received: from relay.tis.com by neptune.TIS.COM id aa01740; 29 Mar 96 19:51 EST Received: by relay.tis.com; id TAA07237; Fri, 29 Mar 1996 19:53:16 -0500 From: hugo@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma007233; Fri, 29 Mar 96 19:52:47 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03250; Fri, 29 Mar 96 19:51:38 EST Received: by relay.tis.com; id TAA07228; Fri, 29 Mar 1996 19:52:46 -0500 Message-Id: <199603300052.TAA07228@relay.tis.com> Received: from unknown(129.34.139.4) by relay.tis.com via smap (V3.1) id xma007224; Fri, 29 Mar 96 19:52:40 -0500 Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9197; Fri, 29 Mar 96 19:52:02 EST Date: Fri, 29 Mar 96 19:51:42 EST To: IPSEC@TIS.COM Subject: HMAC-MD5 Sender: ipsec-approval@neptune.tis.com Precedence: bulk An internet draft with specifications of HMAC-MD5 has been posted. (draft-ietf-ipsec-hmac-md5-txt.00). It is intended especialy for implementers of the IPSEC standards since this transform was the one chosen in the LA meeting of IPSEC as the mandatory to implement transform in AH (and combined AH/ESP). The draft contains the definition of the function, some discussion of security, and sample code (and test vectors). (A couple of successful interoperability tests of AH using HMAC-MD5 as described in this draft were already accomplished) Anyone with significant comments on the presentation please let me know so I can reflect them in the RFC where this function will be described. Hugo Received: from relay.tis.com by neptune.TIS.COM id aa09902; 30 Mar 96 8:24 EST Received: by relay.tis.com; id IAA11837; Sat, 30 Mar 1996 08:27:11 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma011833; Sat, 30 Mar 96 08:26:42 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA11539; Sat, 30 Mar 96 08:25:32 EST Received: by relay.tis.com; id IAA11830; Sat, 30 Mar 1996 08:26:41 -0500 Received: from merit.edu(35.1.1.42) by relay.tis.com via smap (V3.1) id xma011828; Sat, 30 Mar 96 08:26:13 -0500 Received: from Bill.Simpson.DialUp.Mich.Net (pm002-23.dialip.mich.net [141.211.7.159]) by merit.edu (8.7.5/merit-2.0) with SMTP id IAA23847 for ; Sat, 30 Mar 1996 08:27:10 -0500 (EST) Date: Fri, 29 Mar 96 02:30:56 GMT From: William Allen Simpson Message-Id: <5160.bsimpson@morningstar.com> To: ipsec@TIS.COM Subject: Re: PPTP ???? Sender: ipsec-approval@neptune.tis.com Precedence: bulk > From: "C. Harald Koch" > It's from Microsoft and a couple of terminal server people. It's PPP from a > remote dialup hub tunnelled (over IP) to your home office PPP server for > "secure remote access", i.e. user dials into local ISP; ISP relays PPP > packets directly to head-office, encapsulated inside IP; user thinks he's > got a direct PPP link to the office, but with a local telephone call. > > I haven't looked closely at the spec, but I vaguely remember some sort of > encryption or authentication on the tunnel portion of the link... > Sounds like what Morningstar was doing a few years back. And they just got bought by Ascend.... WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 Received: from relay.tis.com by neptune.TIS.COM id aa21098; 31 Mar 96 3:17 EST Received: by relay.tis.com; id DAA18269; Sun, 31 Mar 1996 03:19:25 -0500 From: ERI2@frcu.eun.eg MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma018267; Sun, 31 Mar 96 03:18:56 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22728; Sun, 31 Mar 96 03:17:47 EST Received: by relay.tis.com; id DAA18264; Sun, 31 Mar 1996 03:18:55 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma018258; Sun, 31 Mar 96 03:18:25 -0500 Received: from FRCU.EUN.EG by interlock.ans.net with SMTP id AA28437 (InterLock SMTP Gateway 3.0 for ); Sun, 31 Mar 1996 03:19:16 -0500 Received: from FRCU.EUN.EG by FRCU.EUN.EG (PMDF V4.2-11 #3805) id <01I2ZGQYFE7K000EV2@FRCU.EUN.EG>; Sun, 31 Mar 1996 10:17:02 O Date: Sun, 31 Mar 1996 10:17:02 +0000 (O) Subject: Request of information To: ipsec@ans.net Message-Id: <01I2ZGQYFXIA000EV2@FRCU.EUN.EG> X-Vms-To: IN%"ipsec@ans.net" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: ipsec-approval@neptune.tis.com Precedence: bulk Hello every body I am looking for references which describe the operation of Kerberos in several domains. I will be very grateful if someone could help me. Regards, Heba Aslan Electronics Research Institute El Tahrir St. Dokki Cairo, Egypt E-mail: ERI2@FRCU.EUN.EG Received: from relay.tis.com by neptune.TIS.COM id aa18645; 2 Apr 96 23:41 EST Received: by relay.tis.com; id QAA29296; Tue, 2 Apr 1996 16:45:14 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma029287; Tue, 2 Apr 96 16:44:46 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA11785; Tue, 2 Apr 96 16:43:35 EST Received: by relay.tis.com; id QAA29281; Tue, 2 Apr 1996 16:44:44 -0500 Received: from exchange.microsoft.com(131.107.243.48) by relay.tis.com via smap (V3.1) id xma029264; Tue, 2 Apr 96 16:44:17 -0500 Received: by yuri.microsoft.com with Microsoft Exchange (IMC 4.0.837.3) id <01BB209A.4943C090@yuri.microsoft.com>; Tue, 2 Apr 1996 13:42:50 -0800 Message-Id: From: "Dwight Krossa (Exchange)" To: "'ipsec@TIS.COM'" Cc: "Dwight Krossa (Exchange)" Subject: PPTP ???? Date: Tue, 2 Apr 1996 13:42:43 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: ipsec-approval@neptune.tis.com Precedence: bulk PPTP is point-to-point tunneling protocol, a networking technology that supports multiprotocol virtual private networks (VPN), enabling remote users to access corporate networks securely across the Internet.=20 Using PPTP, remote users can employ the Microsoft=AE Windows=AE 95 and Windows NT=99 Workstation operating systems and other point-to-point protocol (PPP)-enabled systems to dial into a local Internet service to connect to their corporate network via the Internet. For more information,=20 http://www.microsoft.com/backoffice/ntserver/pptppr.htm For the complete specification: http://www.microsoft.com/intdev/inttech/pptp.htm Cheers Dwight Krossa Microsoft Corporation > >---------- >From: Robert Moskowitz[SMTP:rgm3@is.chrysler.com] >Sent: Wednesday, March 27, 1996 9:24 AM >To: ipsec@TIS.COM >Subject: PPTP ???? > >Has anyone looked into this new PPTP ? That is Point-to-point Tunnel >Protocol? > >It is being marketed much to what many of us are working IPSec (and >probably >MobileIP).... > >Robert Moskowitz >Chrysler Corporation >(810) 758-8212 > > > > > > Received: from relay.tis.com by neptune.TIS.COM id aa07742; 3 Apr 96 17:40 EST Received: by relay.tis.com; id RAA28516; Wed, 3 Apr 1996 17:42:52 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma028506; Wed, 3 Apr 96 17:42:33 -0500