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 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA26965; Wed, 3 Apr 96 17:41:21 EST Received: by relay.tis.com; id RAA28479; Wed, 3 Apr 1996 17:42:29 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma028473; Wed, 3 Apr 96 17:41:57 -0500 Received: from relay-2.mail.demon.net (disperse.demon.co.uk) by interlock.ans.net with SMTP id AA07268 (InterLock SMTP Gateway 3.0 for ); Wed, 3 Apr 1996 17:42:52 -0500 Received: from post.demon.co.uk ([158.152.1.72]) by relay-2.mail.demon.net id aa16624; 3 Apr 96 22:27 +0100 Received: from drsec.demon.co.uk ([158.152.74.182]) by relay-3.mail.demon.net id aa23906; 3 Apr 96 22:25 +0100 Message-Id: Date: Wed, 3 Apr 1996 22:24:52 +0100 To: ERI2@frcu.eun.eg Cc: ipsec@ans.net From: Dave Rogers Subject: Re: Request of information In-Reply-To: <01I2ZGQYFXIA000EV2@FRCU.EUN.EG> Mime-Version: 1.0 X-Mailer: Turnpike Version 1.10 Sender: ipsec-approval@neptune.tis.com Precedence: bulk In message <01I2ZGQYFXIA000EV2@FRCU.EUN.EG>, ERI2@frcu.eun.eg writes > >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. > > Try looking at : http://www.es.net/pub/esnet-doc/auth-and-security This is a report on the use of Kerberos within a multi-realm environment. Other documents in the same location provide general information on Kerberos. -- ------------------------------------------------------------------------- David Rogers Email: drogers@drsec.demon.co.uk OpenVision Technologies Ltd daver@openv.co.uk Yorktown House, 8 Frimley Road Tel: +44 (0) 1276 683060 Camberley, Surrey, UK GU15 3HS Fax: +44 (0) 1276 683755 ------------------------------------------------------------------------- Received: from relay.tis.com by neptune.TIS.COM id aa02278; 8 Apr 96 10:39 EDT Received: by relay.tis.com; id KAA03828; Mon, 8 Apr 1996 10:41:33 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma003824; Mon, 8 Apr 96 10:41:11 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03844; Mon, 8 Apr 96 10:40:02 EDT Received: by relay.tis.com; id KAA03814; Mon, 8 Apr 1996 10:41:04 -0400 Received: from host33.epoch.ncsc.mil(144.51.25.33) by relay.tis.com via smap (V3.1) id xma003806; Mon, 8 Apr 96 10:40:54 -0400 Received: from dolphin.ncsc.mil (dolphin.epoch.ncsc.mil) by zeus.epoch.ncsc.mil (4.1/SMI-SVR4) id AA17168; Mon, 8 Apr 96 10:30:59 EDT Received: by dolphin.ncsc.mil (4.1/SMI-4.1) id AA04398; Mon, 8 Apr 96 10:39:47 EDT Date: Mon, 8 Apr 96 10:39:47 EDT From: "W. Douglas Maughan" Message-Id: <9604081439.AA04398@dolphin.ncsc.mil> To: ipsec@TIS.COM Subject: ANNOUNCE: ISAKMP v0.1 is now available Sender: ipsec-approval@neptune.tis.com Precedence: bulk We are pleased to announce that the first release of ISAKMP is now available. It is based on draft-ietf-ipsec-isakmp-04 which was distributed prior to the Los Angeles IETF. The software can be downloaded from: http://web.mit.edu/network/isakmp We would like to thank MIT for providing the anonymous FTP service and, specifically, Jeff Schiller for assisting in this process. Douglas Maughan Mark Schertler Received: from relay.tis.com by neptune.TIS.COM id aa12945; 8 Apr 96 22:03 EDT Received: by relay.tis.com; id WAA18533; Mon, 8 Apr 1996 22:05:54 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma018531; Mon, 8 Apr 96 22:05:26 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02379; Mon, 8 Apr 96 22:04:19 EDT Received: by relay.tis.com; id WAA18528; Mon, 8 Apr 1996 22:05:24 -0400 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma018526; Mon, 8 Apr 96 22:05:08 -0400 Received: from ctrvx1.Vanderbilt.Edu by interlock.ans.net with SMTP id AA05966 (InterLock SMTP Gateway 3.0 for ); Mon, 8 Apr 1996 22:06:07 -0400 Received: from ctrvax.Vanderbilt.Edu by ctrvax.Vanderbilt.Edu (PMDF V5.0-5 #11488) id <01I3B9Q8SFOG8XEC6E@ctrvax.Vanderbilt.Edu> for listys@ctrvax.Vanderbilt.Edu; Mon, 08 Apr 1996 21:03:19 -0500 (CDT) Date: Mon, 08 Apr 1996 21:03:19 -0500 (CDT) From: BEZALEL GAVISH Subject: Proceedings of 4th International Conference on Telecommunications Systems To: listys: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Message-Id: <01I3B9Q8SPBM8XEC6E@ctrvax.Vanderbilt.Edu> X-Vms-To: IN%"listys" X-Vms-Cc: GAVISHB Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: ipsec-approval@neptune.tis.com Precedence: bulk The fourth International Conference on Telecommunication Systems was held March 21-24, 1996, in Nashville, TN. Close to 150 participants from 27 countries gave over 85 presentations on a variety of topics. Proceedings containing the papers presented during the conference have been produced. A few remaining copies of the proceedings are available for sale. The table of contents and ordering information are located at URL http://www.vanderbilt.edu/Owen/gavish/tsm96proceedings.html ------------------------------------------------------------------------------- Bezalel Gavish Owen Graduate School of Management Vanderbilt University Nashville, TN, 37203 Bitnet: GAVISHB@VUCTRVAX Internet: GAVISHB@CTRVAX.VANDERBILT.EDU Tel: (615) 322-3659 Home: (615) 370-0813 FAX: (615) 343-7177 ------------------------------------------------------------------------------- Received: from relay.tis.com by neptune.TIS.COM id aa24823; 19 Apr 96 9:36 EDT Received: by relay.tis.com; id JAA29383; Fri, 19 Apr 1996 09:38:34 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma029378; Fri, 19 Apr 96 09:38:05 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28160; Fri, 19 Apr 96 09:37:04 EDT Received: by relay.tis.com; id JAA29366; Fri, 19 Apr 1996 09:38:03 -0400 Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay.tis.com via smap (V3.1) id xma029358; Fri, 19 Apr 96 09:37:54 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10457; 19 Apr 96 9:14 EDT 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-simpson-photuris-schemes-00.txt Date: Fri, 19 Apr 96 09:14:49 -0400 Message-Id: <9604190914.aa10457@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. Title : Photuris Schemes and Privacy Protection Author(s) : P. Karn, W. Simpson Filename : draft-simpson-photuris-schemes-00.txt Pages : 9 Date : 04/18/1996 Photuris is an experimental session-key management protocol intended for use with the IP Security Protocols (AH and ESP). Extensible Exchange Schemes are provided to enable future implementation changes without affecting the basic protocol. An important improvement in security is provided by protecting exchanges with encryption. 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-simpson-photuris-schemes-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-simpson-photuris-schemes-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-simpson-photuris-schemes-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: <19960418141116.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-simpson-photuris-schemes-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-simpson-photuris-schemes-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960418141116.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- Received: from relay.tis.com by neptune.TIS.COM id aa00265; 21 Apr 96 18:28 EDT Received: by relay.tis.com; id SAA27469; Sun, 21 Apr 1996 18:29:40 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma027466; Sun, 21 Apr 96 18:29:20 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA00890; Sun, 21 Apr 96 18:29:33 EDT Received: by relay.tis.com; id SAA27462; Sun, 21 Apr 1996 18:29:10 -0400 Received: from tik1.ethz.ch(129.132.119.131) by relay.tis.com via smap (V3.1) id xma027460; Sun, 21 Apr 96 18:29:09 -0400 Received: from ktik0 (ktik0 [129.132.66.42]) by tik1.ethz.ch (8.7.5/8.7.3) with ESMTP id AAA00857; Mon, 22 Apr 1996 00:30:45 +0200 (MET DST) 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 AAA22462; Mon, 22 Apr 1996 00:30:38 +0200 Message-Id: <2.2.32.19960421223444.006e30f8@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: Mon, 22 Apr 1996 00:34:44 +0200 To: ipsec@TIS.COM From: Germano Caronni Subject: IETF Draft for ESP with stream ciphers Cc: skip-info@tik.ee.ethz.ch, skip@tik.ee.ethz.ch Sender: ipsec-approval@neptune.tis.com Precedence: bulk Hello everybody, some time ago, Marcel (Waldvogel) and I have submitted an internet draft, which gives a proposal on how 'Encapsulated Security Payload' can be implemented for stream ciphers, at the same time offering mechanisms for replay protection. Now we would be very interested in the opinion of the IPSEC working group, and possible other readers. Is 'esp-stream' of interest? What do the members and chairs think about the fitness of this document? If it is relevant, perhaps we could move it into the 'draft-ietf-ipsec-*' name domain? We are also very much looking forward to technical comments... Friendly greetings, Germano p.s. the doucment is online as draft-caronni-esp-stream-00.txt, or as http://www.tik.ee.ethz.ch/~skip/esp-stream.txt Received: from relay.tis.com by neptune.TIS.COM id aa18471; 22 Apr 96 13:31 EDT Received: by relay.tis.com; id NAA09472; Mon, 22 Apr 1996 13:32:24 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma009463; Mon, 22 Apr 96 13:31:59 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01012; Mon, 22 Apr 96 13:32:21 EDT Received: by relay.tis.com; id NAA09447; Mon, 22 Apr 1996 13:31:57 -0400 Received: from franklin.seas.gwu.edu(128.164.9.2) by relay.tis.com via smap (V3.1) id xma009432; Mon, 22 Apr 96 13:31:37 -0400 Received: from felix.seas.gwu.edu (root@felix.seas.gwu.edu [128.164.9.3]) by franklin.seas.gwu.edu (8.7.1/8.7.1) with ESMTP id NAA07020 for ; Mon, 22 Apr 1996 13:34:16 -0400 (EDT) Received: from reto.seas.gwu.edu (reto@felix [128.164.9.3]) by felix.seas.gwu.edu (8.7.1/8.7.1) with SMTP id NAA00230 for ; Mon, 22 Apr 1996 13:34:11 -0400 (EDT) Message-Id: <199604221734.NAA00230@felix.seas.gwu.edu> X-Sender: reto@seas.gwu.edu X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 22 Apr 1996 13:35:47 -0400 To: ipsec@TIS.COM From: Reto Haeni Subject: Routing Header info of IPng against traffic analysis? Sender: ipsec-approval@neptune.tis.com Precedence: bulk Hi As I was working through the IPng specifications, I realized that no options are implemented to prevent traffic analysis in IPsec. Could the Routing Header information been set up that the list of intermediate nodes changes when the system setting provide a list of alternative routing paths? An error condition could arise similar to the definition in the fragmentation header, if not all packets are received to complete reassembly of the message within 60 seconds (a long time but I think this would be a reasonable waiting time if you are concerned about traffic analysis). This would prevent most attempts to traffic analysis and complete the good IPsec spec. I am looking forward to your comments greetings Reto ------------------------------------------------------------------ at the George Washington University, Washington DC reto@seas.gwu.edu Received: from relay.tis.com by neptune.TIS.COM id aa19253; 22 Apr 96 14:16 EDT Received: by relay.tis.com; id OAA00910; Mon, 22 Apr 1996 14:17:33 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma000907; Mon, 22 Apr 96 14:17:06 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA04204; Mon, 22 Apr 96 14:17:28 EDT Received: by relay.tis.com; id OAA00900; Mon, 22 Apr 1996 14:17:04 -0400 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1) id xma000894; Mon, 22 Apr 96 14:16:51 -0400 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id OAA18138; Mon, 22 Apr 1996 14:19:14 -0400 (EDT) Message-Id: <199604221819.OAA18138@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Reto Haeni Cc: ipsec@TIS.COM Subject: Re: Routing Header info of IPng against traffic analysis? In-Reply-To: Your message of "Mon, 22 Apr 1996 13:35:47 EDT." <199604221734.NAA00230@felix.seas.gwu.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 22 Apr 1996 14:19:08 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Reto Haeni writes: > As I was working through the IPng specifications, I realized that > no options are implemented to prevent traffic analysis in IPsec. > > Could the Routing Header information been set up that the list of > intermediate nodes changes when the system setting provide a > list of alternative routing paths? An error condition could arise > similar to the definition in the fragmentation header, if not all > packets are received to complete reassembly of the message within 60 > seconds (a long time but I think this would be a reasonable waiting > time if you are concerned about traffic analysis). Changing routing paths isn't sufficient to prevent traffic analysis. Stopping traffic analysis is fairly complicated and beyond the scope of the IPSec work... .pm Received: from relay.tis.com by neptune.TIS.COM id aa23587; 22 Apr 96 17:36 EDT Received: by relay.tis.com; id RAA05414; Mon, 22 Apr 1996 17:37:36 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma005411; Mon, 22 Apr 96 17:37:08 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA17233; Mon, 22 Apr 96 17:37:31 EDT Received: by relay.tis.com; id RAA05404; Mon, 22 Apr 1996 17:37:06 -0400 Received: from unknown(171.69.1.174) by relay.tis.com via smap (V3.1) id xma005398; Mon, 22 Apr 96 17:36:46 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id OAA20423; Mon, 22 Apr 1996 14:38:49 -0700 Date: Mon, 22 Apr 1996 14:38:49 -0700 From: Ran Atkinson Message-Id: <199604222138.OAA20423@puli.cisco.com> To: caronni@tik.ee.ethz.ch Subject: Re: IETF Draft for ESP with stream ciphers In-Reply-To: <2.2.32.19960421223444.006e30f8@ktik0.ethz.ch> Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk In article <2.2.32.19960421223444.006e30f8@ktik0.ethz.ch> Germanno wrote: >some time ago, Marcel (Waldvogel) and I have submitted an internet draft, >which gives a proposal on how 'Encapsulated Security Payload' can be >implemented for stream ciphers, at the same time offering mechanisms for >replay protection. > >Now we would be very interested in the opinion of the IPSEC working group, >and possible other readers. Is 'esp-stream' of interest? The main issue with the current draft is that it does not specify a particular stream algorithm. An ESP transform MUST specify a particular algorithm as part of the transform so that when key management negotiates use of that transform, both sides know which algorithm to use. So perhaps my fundamental request is that this be edited into a transform for a specific algorithm or possibly for two specific algorithms (with some note that each algorithm would need its own "transform identifier" for key management use. It is NOT the case that the current spec works for all stream algorithms, for example the "Stream Offset" as currently defined will not work when more than 64 bits of crypto-sync are needed for some algorithm. While algorithm-independence is important for the base AH and ESP specs, it should not be a goal for a transform document since transform documents are supposed to specify how to use a single particular crypto algorithm with AH or ESP. >What do the members and chairs think about the fitness of this document? As an ordinary person, my take on this is that it has limited applicability and should probably become an Experimental RFC or Informational RFC. I do not know the patent status of SEAL in various countries, but IETF practice is to avoid standardising patented techniques when unpatented techniques (e.g. DES CFB) exist. Given the existence of fairly fast DES code (e.g. Karn's i386 assembly) and commercial high-speed DES chips, I'm not sure that this particular tradeoff of speed for less security is one that I'd be making. I would want MD5 (or equivalent) integrity/authentication to be added to the transform because we know that strong integrity/authentication is needed to obtain commercial-grade security. I'm aware of MD5 code in software that does better than OC-3 rate now on a commercial 64-bit RISC processor. I'm also aware of MD5 hardware that is well above OC-3 rates. In general, I do not agree with all of the conclusions of RFC-1810 because of private discussions I've had with employees of National Semiconductor (these discussions actually date back prior to my arrival at cisco). >If it is relevant, perhaps we could move it into the 'draft-ietf-ipsec-*' >name domain? Only if the WG decides it should be a standards-track document. It is not yet clear to me that there is anything like consensus that this draft should be on the standards-track. I've been told from above that we should not be standardising any transform that is vulnerable to published attacks. The WG in LA made it clear that RFC-1828 and RFC-1829 should be replaced-on-the-standards-track with new transforms having improved security properties. So I'd view addition of MD5 (or similar, SHA would be fine with me personally) integrity/ authentication to be needed before this draft goes anywhere. Ran rja@cisco.com Received: from relay.tis.com by neptune.TIS.COM id aa23650; 22 Apr 96 17:39 EDT Received: by relay.tis.com; id RAA05445; Mon, 22 Apr 1996 17:40:36 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma005438; Mon, 22 Apr 96 17:40:08 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA17298; Mon, 22 Apr 96 17:40:31 EDT Received: by relay.tis.com; id RAA05432; Mon, 22 Apr 1996 17:40:06 -0400 Received: from unknown(171.69.1.174) by relay.tis.com via smap (V3.1) id xma005422; Mon, 22 Apr 96 17:39:55 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id OAA00456; Mon, 22 Apr 1996 14:42:29 -0700 Date: Mon, 22 Apr 1996 14:42:29 -0700 From: Ran Atkinson Message-Id: <199604222142.OAA00456@puli.cisco.com> To: ipsec@TIS.COM Subject: Re: Routing Header info of IPng against traffic analysis? In-Reply-To: <199604221819.OAA18138@jekyll.piermont.com> References: <199604221734.NAA00230@felix.seas.gwu.edu> Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: Sender: ipsec-approval@neptune.tis.com Precedence: bulk Reto Haeni wrote: % As I was working through the IPng specifications, I realized that % no options are implemented to prevent traffic analysis in IPsec. In article <199604221819.OAA18138@jekyll.piermont.com> Perry wrote: >Changing routing paths isn't sufficient to prevent traffic analysis. > >Stopping traffic analysis is fairly complicated and beyond the scope >of the IPSec work... It is not clear to me that it is feasible to prevent traffic analysis anywhere above the link layer. Folks really interested in this might want to consult [VK85] for relevant background material. Ran rja@cisco.com Received: from relay.tis.com by neptune.TIS.COM id aa24671; 22 Apr 96 18:40 EDT Received: by relay.tis.com; id SAA06085; Mon, 22 Apr 1996 18:41:10 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma006083; Mon, 22 Apr 96 18:40:42 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18663; Mon, 22 Apr 96 18:41:05 EDT Received: by relay.tis.com; id SAA06078; Mon, 22 Apr 1996 18:40:41 -0400 Received: from foo-5-10.ipsilon.com(205.226.5.12) by relay.tis.com via smap (V3.1) id xma006074; Mon, 22 Apr 96 18:40:34 -0400 Received: from mailhost.ipsilon.com (localhost [127.0.0.1]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id PAA10174; Mon, 22 Apr 1996 15:43:04 -0700 Message-Id: <199604222243.PAA10174@mailhost.Ipsilon.COM> X-Mailer: exmh version 1.6.4 10/10/95 To: Ran Atkinson Cc: ipsec@TIS.COM Subject: ports in the clear... In-Reply-To: Your message of "Mon, 22 Apr 1996 14:42:29 PDT." <199604222142.OAA00456@puli.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Apr 1996 15:43:04 -0700 From: Greg Minshall Sender: ipsec-approval@neptune.tis.com Precedence: bulk > It is not clear to me that it is feasible to prevent traffic analysis > anywhere above the link layer. Folks really interested in this might want > to consult [VK85] for relevant background material. Did i mention my desire to expose the source and destination TCP/UDP ports (via some new fields in the IPSEC header) when doing encryption? There are lots of reasons, from bean counting ("what % of the internet traffic is web traffic?") to firewalls to "best effort QoS" (make telnet port low latency; make ftp data port high throughput). Greg Received: from relay.tis.com by neptune.TIS.COM id aa24847; 22 Apr 96 18:50 EDT Received: by relay.tis.com; id SAA06194; Mon, 22 Apr 1996 18:51:10 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma006192; Mon, 22 Apr 96 18:50:42 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18847; Mon, 22 Apr 96 18:51:05 EDT Received: by relay.tis.com; id SAA06189; Mon, 22 Apr 1996 18:50:41 -0400 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1) id xma006187; Mon, 22 Apr 96 18:50:17 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id PAA27485; Mon, 22 Apr 1996 15:52:26 -0700 Date: Mon, 22 Apr 1996 15:52:26 -0700 From: Ran Atkinson Message-Id: <199604222252.PAA27485@puli.cisco.com> To: minshall@ipsilon.com Subject: Re: ports in the clear... Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Greg Minshall wrote: % Did i mention my desire to expose the source and destination TCP/UDP ports % (via some new fields in the IPSEC header) when doing encryption? Yes. You've mentioned this several times. My answers remain the same. You'll shoud concentrate on convincing everyone else first, because there is ZERO chance I'll be convinced to open up the ports and ULP identifier with ESP. % There are lots of reasons, from bean counting ("what % of the internet % traffic is web traffic?") So add a counter for encrypted traffic. Not a good argument. % to firewalls Should be implementing IPsec anyway. Most firewalls are becoming encrypting firewalls already. Not a good argument. % to "best effort QoS" (make telnet port low latency; % make ftp data port high throughput). Use RSVP instead. See the RSVP+IPsec draft for how to make it work. Your unstated reason is that it relates to how the Ipsilon product works and that won't persuade me either. Nothing says that users must use encryption. If they choose to do so, then they ought not have their ports and ULP identifier in cleartext. Ran rja@inet.org Received: from relay.tis.com by neptune.TIS.COM id aa25287; 22 Apr 96 19:18 EDT Received: by relay.tis.com; id TAA06638; Mon, 22 Apr 1996 19:19:30 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma006634; Mon, 22 Apr 96 19:19:02 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19292; Mon, 22 Apr 96 19:19:24 EDT Received: by relay.tis.com; id TAA06631; Mon, 22 Apr 1996 19:19:00 -0400 Received: from unknown(194.100.8.234) by relay.tis.com via smap (V3.1) id xma006627; Mon, 22 Apr 96 19:18:30 -0400 Received: from pilari.ssh.fi (pilari.ssh.fi [192.168.2.1]) by muuri.ssh.fi (8.7.5/8.7.3) with ESMTP id CAA16607; Tue, 23 Apr 1996 02:20:58 +0300 (EET DST) Received: (from ylo@localhost) by pilari.ssh.fi (8.7.5/8.7.3) id CAA24256; Tue, 23 Apr 1996 02:20:57 +0300 (EET DST) Date: Tue, 23 Apr 1996 02:20:57 +0300 (EET DST) Message-Id: <199604222320.CAA24256@pilari.ssh.fi> From: Tatu Ylonen To: Greg Minshall Cc: ipsec@TIS.COM Subject: ports in the clear... In-Reply-To: <199604222243.PAA10174@mailhost.Ipsilon.COM> References: <199604222142.OAA00456@puli.cisco.com> <199604222243.PAA10174@mailhost.Ipsilon.COM> Organization: Helsinki University of Technology, Finland Sender: ipsec-approval@neptune.tis.com Precedence: bulk > There are lots of reasons, from bean counting ("what % of the > internet traffic is web traffic?") to firewalls to "best effort QoS" > (make telnet port low latency; make ftp data port high throughput). Using port numbers for quality of service is The Wrong Way To Do It. The TOS (Type of Service) field is for this, and it reveals much less other information. Attaching type of service semantics to port numbers makes adding new services extremely painful, because it is impossible to control their routing priority. IPTOS is much more flexible, extensible, and scalable. Almost all machines already set IPTOS in outgoing packets according to the type of the service. Tatu Received: from relay.tis.com by neptune.TIS.COM id aa26166; 22 Apr 96 20:14 EDT Received: by relay.tis.com; id UAA07276; Mon, 22 Apr 1996 20:14:41 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma007270; Mon, 22 Apr 96 20:14:13 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20084; Mon, 22 Apr 96 20:14:36 EDT Received: by relay.tis.com; id UAA07267; Mon, 22 Apr 1996 20:14:11 -0400 Received: from foo-5-10.ipsilon.com(205.226.5.12) by relay.tis.com via smap (V3.1) id xma007260; Mon, 22 Apr 96 20:13:52 -0400 Received: from mailhost.ipsilon.com (localhost [127.0.0.1]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id RAA13196; Mon, 22 Apr 1996 17:16:22 -0700 Message-Id: <199604230016.RAA13196@mailhost.Ipsilon.COM> X-Mailer: exmh version 1.6.4 10/10/95 To: Ran Atkinson Cc: ipsec@TIS.COM Subject: Re: ports in the clear... In-Reply-To: Your message of "Mon, 22 Apr 1996 15:52:26 PDT." <199604222252.PAA27485@puli.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Apr 1996 17:16:22 -0700 From: Greg Minshall Sender: ipsec-approval@neptune.tis.com Precedence: bulk Ran, > Your unstated reason is that it relates to how the Ipsilon product works > and that won't persuade me either. Foo. I'm fairly principled; my discomfort with hiding the port numbers predates Ipsilon. (But, you are right that this would also make some of our stuff easier in operational networks.) [But, maybe you didn't mean this statement to be for public consumption?] > Nothing says that users must use encryption. If they choose to do so, > then they ought not have their ports and ULP identifier in cleartext. I guess i don't know any argument from first principles that says what should, and what shouldn't, be in the clear (except that it's clear that people want their telnet passwords and their payroll data, etc., to be encrypted). If, for example, ports and ULP were in the IPng header (sort of like in XNS), then one might not think of encrypting them (thinking of them as part of the "address"). Greg Received: from relay.tis.com by neptune.TIS.COM id aa26674; 22 Apr 96 20:42 EDT Received: by relay.tis.com; id UAA07723; Mon, 22 Apr 1996 20:43:41 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma007716; Mon, 22 Apr 96 20:43:13 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20541; Mon, 22 Apr 96 20:43:36 EDT Received: by relay.tis.com; id UAA07707; Mon, 22 Apr 1996 20:43:11 -0400 Received: from foo-5-10.ipsilon.com(205.226.5.12) by relay.tis.com via smap (V3.1) id xma007702; Mon, 22 Apr 96 20:43:04 -0400 Received: from mailhost.ipsilon.com (localhost [127.0.0.1]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id RAA13992; Mon, 22 Apr 1996 17:45:02 -0700 Message-Id: <199604230045.RAA13992@mailhost.Ipsilon.COM> X-Mailer: exmh version 1.6.4 10/10/95 To: Tatu Ylonen Cc: ipsec@TIS.COM Subject: Re: ports in the clear... In-Reply-To: Your message of "Tue, 23 Apr 1996 02:20:57 +0300." <199604222320.CAA24256@pilari.ssh.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Apr 1996 17:45:02 -0700 From: Greg Minshall Sender: ipsec-approval@neptune.tis.com Precedence: bulk Tatu, Actually, the poor IP TOS field has an inglorious history of having been somewhat useless. The original definition never had very much use. The more current separation of precedence, etc., may have a bit more utility, though the fact that it is set at the end station (and, therefore, of dubious correctness) is a bit troubling. (You might look at Christian Huitema's "Routing in the Internet", section 3.3.2, for a *very* brief discussion.) (The canonical danger is an e'mail program that advertises "i'll get your mail there faster than that other e'mail program", and then doing that by setting bits in TOS.) *One* advantage of looking at port numbers is that it scales, to some degree. It also *may* reflect closer to what is actually going on (i.e., this really *is* a telnet session; unless, of course, the two ends are conspiring). (For some of the background, you might want to look at Floyd, S., and Jacobson, V., Link-sharing and Resource Management Models for Packet Networks. IEEE/ACM Transactions on Networking, Vol. 3 No. 4, pp. 365-386, August 1995.) (But, you are right, by doing this, when you field a new "application", you need to add new administrative configuration information to routers.) Sorry, though, for highjacking ipsec for *this* more packet management discussion. Greg Received: from relay.tis.com by neptune.TIS.COM id aa26945; 22 Apr 96 21:03 EDT Received: by relay.tis.com; id VAA07977; Mon, 22 Apr 1996 21:04:11 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma007975; Mon, 22 Apr 96 21:03:42 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20892; Mon, 22 Apr 96 21:04:05 EDT Received: by relay.tis.com; id VAA07972; Mon, 22 Apr 1996 21:03:41 -0400 Received: from lint.cisco.com(171.68.223.44) by relay.tis.com via smap (V3.1) id xma007970; Mon, 22 Apr 96 21:03:33 -0400 Received: from pferguso-pc.cisco.com (c2robo6.cisco.com [171.68.13.38]) by lint.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id SAA21188; Mon, 22 Apr 1996 18:04:39 -0700 Message-Id: <199604230104.SAA21188@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 22 Apr 1996 21:05:39 -0400 To: Greg Minshall From: Paul Ferguson Subject: Re: ports in the clear... Cc: Ran Atkinson , ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Believe it or not, you'd be surprised how many bean counters there are in this world. People want to account for data flows. - paul At 03:43 PM 4/22/96 -0700, Greg Minshall wrote: >Did i mention my desire to expose the source and destination TCP/UDP ports >(via some new fields in the IPSEC header) when doing encryption? > >There are lots of reasons, from bean counting ("what % of the internet traffic >is web traffic?") to firewalls to "best effort QoS" (make telnet port low >latency; make ftp data port high throughput). > >Greg > Received: from relay.tis.com by neptune.TIS.COM id aa28282; 22 Apr 96 22:24 EDT Received: by relay.tis.com; id WAA09416; Mon, 22 Apr 1996 22:24:57 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma009412; Mon, 22 Apr 96 22:24:28 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22223; Mon, 22 Apr 96 22:24:51 EDT Received: by relay.tis.com; id WAA09409; Mon, 22 Apr 1996 22:24:27 -0400 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1) id xma009407; Mon, 22 Apr 96 22:24:19 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id TAA11920 for ipsec@tis.com; Mon, 22 Apr 1996 19:26:59 -0700 Date: Mon, 22 Apr 1996 19:26:59 -0700 From: Ran Atkinson Message-Id: <199604230226.TAA11920@puli.cisco.com> To: ipsec@TIS.COM Subject: apology Sender: ipsec-approval@neptune.tis.com Precedence: bulk I did not intend to impune Greg Minshall's character in my earlier note. He had been open in previous face-to-face discussions (e.g. in the hallways at USENIX) about the advantages of open ports for the Ipsilon product. He says his concerns about open ports predate Ipsilon and I take him at his word on that. If the user didn't want the ports and transport-layer covered up, then the user would have used an upper-layer security service (e.g. PEM, PGP, SSL, whatever) instead of IPsec. Uncovering the ports within the context of IPsec is unwise and contrary to the intent of the IPsec work. Ran rja@inet.org Received: from relay.tis.com by neptune.TIS.COM id aa00960; 23 Apr 96 2:18 EDT Received: by relay.tis.com; id WAA09275; Mon, 22 Apr 1996 22:09:27 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma009268; Mon, 22 Apr 96 22:08:58 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21993; Mon, 22 Apr 96 22:09:22 EDT Received: by relay.tis.com; id WAA09263; Mon, 22 Apr 1996 22:08:57 -0400 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1) id xma009258; Mon, 22 Apr 96 22:08:46 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id TAA29312; Mon, 22 Apr 1996 19:11:26 -0700 Date: Mon, 22 Apr 1996 19:11:26 -0700 From: Ran Atkinson Message-Id: <199604230211.TAA29312@puli.cisco.com> To: pferguso@cisco.com Subject: Re: ports in the clear... Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Paul, I understand that there are folks who want to count packets. However, the _purpose_ of using IPsec is to make it difficult for an adversary to know what is going on. If a user has turned on IPsec for his traffic, its because the user does not want this information in the clear, else the user would have used upper-layer security services instead of IPsec. Ran rja@cisco.com Received: from relay.tis.com by neptune.TIS.COM id aa04520; 23 Apr 96 7:12 EDT Received: by relay.tis.com; id HAA14450; Tue, 23 Apr 1996 07:13:56 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma014448; Tue, 23 Apr 96 07:13:27 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA29780; Tue, 23 Apr 96 07:13:50 EDT Received: by relay.tis.com; id HAA14445; Tue, 23 Apr 1996 07:13:26 -0400 Received: from lint.cisco.com(171.68.223.44) by relay.tis.com via smap (V3.1) id xma014443; Tue, 23 Apr 96 07:13:13 -0400 Received: from pferguso-pc.cisco.com (c1robo3.cisco.com [171.68.13.3]) by lint.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id EAA11111; Tue, 23 Apr 1996 04:14:49 -0700 Message-Id: <199604231114.EAA11111@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 23 Apr 1996 07:15:50 -0400 To: Ran Atkinson From: Paul Ferguson Subject: Re: ports in the clear... Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Completely understood. I was stating the obvious. :-/ - paul At 07:11 PM 4/22/96 -0700, Ran Atkinson wrote: >Paul, > > I understand that there are folks who want to count packets. >However, the _purpose_ of using IPsec is to make it difficult for an >adversary to know what is going on. If a user has turned on IPsec for his >traffic, its because the user does not want this information in the clear, >else the user would have used upper-layer security services instead of >IPsec. > >Ran >rja@cisco.com > > > Received: from relay.tis.com by neptune.TIS.COM id aa06455; 23 Apr 96 9:07 EDT Received: by relay.tis.com; id JAA16474; Tue, 23 Apr 1996 09:08:13 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma016466; Tue, 23 Apr 96 09:07:45 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06060; Tue, 23 Apr 96 09:08:08 EDT Received: by relay.tis.com; id JAA16460; Tue, 23 Apr 1996 09:07:43 -0400 Received: from dfw-ix5.ix.netcom.com(206.214.98.5) by relay.tis.com via smap (V3.1) id xma016457; Tue, 23 Apr 96 09:07:41 -0400 Received: from pon-mi2-16.ix.netcom.com (pon-mi2-16.ix.netcom.com [205.186.168.80]) by dfw-ix5.ix.netcom.com (8.6.13/8.6.12) with SMTP id GAA13531; Tue, 23 Apr 1996 06:14:51 -0700 Received: by pon-mi2-16.ix.netcom.com with Microsoft Mail id <01BB30F4.C1D90780@pon-mi2-16.ix.netcom.com>; Tue, 23 Apr 1996 09:10:46 -0400 Message-Id: <01BB30F4.C1D90780@pon-mi2-16.ix.netcom.com> From: Brad Wilson To: "pferguso@cisco.com" , 'Ran Atkinson' Cc: "ipsec@TIS.COM" Subject: RE: ports in the clear... Date: Tue, 23 Apr 1996 08:59:09 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk >> I understand that there are folks who want to count packets. >> However, the _purpose_ of using IPsec is to make it difficult for an >> adversary to know what is going on. If a user has turned on IPsec for his >> traffic, its because the user does not want this information in the clear, >> else the user would have used upper-layer security services instead of >> IPsec. If bean counters want to count traffic, they could always use encrypting firewalls. I agree with Ran; don't comprimise the security of the protocol for bean counters (which is the only "real" argument I've seen). Brad -- Brad Wilson, Crucial Software crucial@ix.netcom.com +1 (810) 620-9803 Custom software engineering services for Microsoft Windows NT and Windows 95 Received: from relay.tis.com by neptune.TIS.COM id aa07722; 23 Apr 96 10:05 EDT Received: by relay.tis.com; id KAA17862; Tue, 23 Apr 1996 10:06:13 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma017856; Tue, 23 Apr 96 10:05:45 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10424; Tue, 23 Apr 96 10:06:08 EDT Received: by relay.tis.com; id KAA17849; Tue, 23 Apr 1996 10:05:43 -0400 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1) id xma017845; Tue, 23 Apr 96 10:05:16 -0400 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id KAA20863; Tue, 23 Apr 1996 10:07:46 -0400 (EDT) Message-Id: <199604231407.KAA20863@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Greg Minshall Cc: Ran Atkinson , ipsec@TIS.COM Subject: Re: ports in the clear... In-Reply-To: Your message of "Mon, 22 Apr 1996 15:43:04 PDT." <199604222243.PAA10174@mailhost.Ipsilon.COM> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 23 Apr 1996 10:07:45 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Greg Minshall writes: > Did i mention my desire to expose the source and destination TCP/UDP ports > (via some new fields in the IPSEC header) when doing encryption? Unfortunately, that conflicts with the desire many others have to reduce the amount of traffic analysis that can be done. It also has the problem that there is no way for a traffic monitor to know what kind of ESP transform is being used and thus which portion of the ESP header to look in -- since the only thing constant across ESP transforms is the 32 bit SPI header, it is very hard indeed to know you are using a transformt that exposes anything. At this point, given the extensive implementations out in the field, changing everything for everyone might be hard. The reason for AH was, of course, to have "exposed" datagrams that were authenticated. There may be some other ways to achieve the QoS goal you have, though... .pm Received: from relay.tis.com by neptune.TIS.COM id aa07779; 23 Apr 96 10:09 EDT Received: by relay.tis.com; id KAA17909; Tue, 23 Apr 1996 10:10:13 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma017905; Tue, 23 Apr 96 10:09:45 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10719; Tue, 23 Apr 96 10:10:08 EDT Received: by relay.tis.com; id KAA17899; Tue, 23 Apr 1996 10:09:43 -0400 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1) id xma017894; Tue, 23 Apr 96 10:09:16 -0400 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id KAA20874; Tue, 23 Apr 1996 10:11:55 -0400 (EDT) Message-Id: <199604231411.KAA20874@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: Routing Header info of IPng against traffic analysis? In-Reply-To: Your message of "Mon, 22 Apr 1996 14:42:29 PDT." <199604222142.OAA00456@puli.cisco.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 23 Apr 1996 10:11:55 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Ran Atkinson writes: > In article <199604221819.OAA18138@jekyll.piermont.com> Perry wrote: > >Stopping traffic analysis is fairly complicated and beyond the scope > >of the IPSec work... > > It is not clear to me that it is feasible to prevent traffic analysis > anywhere above the link layer. I tend to agree that you need link opacity to do serious traffic analysis prevention, although I believe you could do partial work with cover traffic and such. However, what we are talking about is now a very complicated subject for research, not something for this working group to be doing. I believe you and I are in violent agreement on this. Perry Received: from relay.tis.com by neptune.TIS.COM id aa09516; 23 Apr 96 11:24 EDT Received: by relay.tis.com; id LAA19594; Tue, 23 Apr 1996 11:25:57 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma019579; Tue, 23 Apr 96 11:25:29 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA15322; Tue, 23 Apr 96 11:25:52 EDT Received: by relay.tis.com; id LAA19572; Tue, 23 Apr 1996 11:25:27 -0400 Received: from unknown(198.53.167.2) by relay.tis.com via smap (V3.1) id xma019561; Tue, 23 Apr 96 11:25:02 -0400 Received: from jupiter.milkyway.com (jupiter.milkyway.com [192.168.77.9]) by internet with ESMTP (DuhMail/2.0) id LAA05084; Tue, 23 Apr 1996 11:20:54 -0400 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 LAA22309 for ; Tue, 23 Apr 1996 11:24:55 -0400 Received: from metis.milkyway.com by milkyway.com (8.6.12/BSDI-Client) id LAA05214; Tue, 23 Apr 1996 11:47:20 -0400 Message-Id: <199604231547.LAA05214@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, 22 Apr 1996 21:05:39 EDT." <199604230104.SAA21188@lint.cisco.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="===_-1_Tue_Apr_23_11:47:13_EDT_1996"; micalc=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 23 Apr 1996 11:47:13 -0400 From: Michael Richardson Sender: ipsec-approval@neptune.tis.com Precedence: bulk --===_-1_Tue_Apr_23_11:47:13_EDT_1996 Content-Type: text/plain; charset=us-ascii In a galaxy far, far away, : Mon, 22 Apr 1996 21:05:39 EDT > Believe it or not, you'd be surprised how many bean counters there > are in this world. People want to account for data flows. If people want to account for traffic flow, then they should reject attempts to send encrypted packets through. Simple. The whole point of encrypted traffic flow is to keep information private. Otherwise, people who want privacy will just build tunnels, there will be no port numbers to see, and the bean counters will just be back where they started, only they'll be paying an extra IP header per packet. The existence of ESP headers will not likely cause all the traffic to become encrypted. I doubt AH headers will be that common for typical http access. HTTP is expensive enough as it is... If you want to count bytes, then buy a device that supports IPsec. Firewalls are examples of such a device. I proposed one method that a firewall could interact with IPsec in draft-richardson-ipsec-aft-00.txt. I'm less convinced that this is the way to do it now than a month ago, though. -- 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. --===_-1_Tue_Apr_23_11:47:13_EDT_1996 Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2i iQBVAwUBMXz7gBUFVvYhcjNpAQF/FwIAhC7aigpXUqoGFQ6NJXUAtqeVUJr5Pt64 rJAShgN0txxEldJNbCBQVbq8KxSzIloCCWdBbFbPeKqDwr9LsP6U4w== =gt0Q -----END PGP MESSAGE----- --===_-1_Tue_Apr_23_11:47:13_EDT_1996-- Received: from relay.tis.com by neptune.TIS.COM id aa10047; 23 Apr 96 11:37 EDT Received: by relay.tis.com; id LAA19873; Tue, 23 Apr 1996 11:38:58 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma019865; Tue, 23 Apr 96 11:38:29 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA15960; Tue, 23 Apr 96 11:38:52 EDT Received: by relay.tis.com; id LAA19862; Tue, 23 Apr 1996 11:38:28 -0400 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1) id xma019860; Tue, 23 Apr 96 11:37:44 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id IAA15454 for ipsec@tis.com; Tue, 23 Apr 1996 08:40:18 -0700 Date: Tue, 23 Apr 1996 08:40:18 -0700 From: Ran Atkinson Message-Id: <199604231540.IAA15454@puli.cisco.com> To: ipsec@TIS.COM Subject: MONTREAL IETF: IPSEC Sender: ipsec-approval@neptune.tis.com Precedence: bulk The tentative schedule for IPsec in Montreal is: Tuesday, June 25 at 1530 (opposite dhc, rolc) Wednesday, June 26 at 1530 (opposite agentx, dhc) Folks with proposed agenda items should email their proposals to both Paul Lambert and me and we'll try to put together an agenda. Ran rja@cisco.com Received: from relay.tis.com by neptune.TIS.COM id aa11239; 23 Apr 96 12:29 EDT Received: by relay.tis.com; id MAA21063; Tue, 23 Apr 1996 12:30:23 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma021050; Tue, 23 Apr 96 12:29:49 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA17797; Tue, 23 Apr 96 12:30:11 EDT Received: by relay.tis.com; id MAA21043; Tue, 23 Apr 1996 12:29:46 -0400 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1) id xma020952; Tue, 23 Apr 96 12:28:59 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id JAA07496 for ipsec@tis.com; Tue, 23 Apr 1996 09:31:30 -0700 Date: Tue, 23 Apr 1996 09:31:30 -0700 From: Ran Atkinson Message-Id: <199604231631.JAA07496@puli.cisco.com> To: ipsec@TIS.COM Subject: reference correction Sender: ipsec-approval@neptune.tis.com Precedence: bulk It looks like maybe I typo'd the other day. Perhaps I should have said [VK83], which is cited in more detail in RFC-1825, among other places. Ran rja@cisco.com Received: from relay.tis.com by neptune.TIS.COM id aa11261; 23 Apr 96 12:30 EDT Received: by relay.tis.com; id MAA21110; Tue, 23 Apr 1996 12:31:48 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma021106; Tue, 23 Apr 96 12:31:24 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA17850; Tue, 23 Apr 96 12:31:42 EDT Received: by relay.tis.com; id MAA21099; Tue, 23 Apr 1996 12:31:17 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1) id xma021083; Tue, 23 Apr 96 12:30:55 -0400 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id JAA22629; Tue, 23 Apr 1996 09:33:28 -0700 Received: by mailsun2.us.oracle.com (8.7.1/37.8) id JAA14678; Tue, 23 Apr 1996 09:36:15 -0700 (PDT) Message-Id: <199604231636.JAA14678@mailsun2.us.oracle.com> Date: 23 Apr 96 09:29:50 -0700 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: IPsec at Montreal IETF Mime-Version: 1.0 Sender: ipsec-approval@neptune.tis.com Precedence: bulk FYI, >This is to confirm two session of IPSEC as follows: > > Tuesday, June 25 at 1530 (opposite dhc, rolc) > Wednesday, June 26 at 1530 (opposite agentx, dhc) Individuals requesting time on the agenda should send Ran and myself e-mail (rja@cisco.com, palamber@us.oracle.com). 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 aa16653; 23 Apr 96 15:48 EDT Received: by relay.tis.com; id PAA26415; Tue, 23 Apr 1996 15:49:45 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma026406; Tue, 23 Apr 96 15:49:17 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA26535; Tue, 23 Apr 96 15:49:39 EDT Received: by relay.tis.com; id PAA26399; Tue, 23 Apr 1996 15:49:15 -0400 Received: from foo-5-10.ipsilon.com(205.226.5.12) by relay.tis.com via smap (V3.1) id xma026346; Tue, 23 Apr 96 15:49:11 -0400 Received: from mailhost.ipsilon.com (localhost [127.0.0.1]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id MAA08435; Tue, 23 Apr 1996 12:49:08 -0700 Message-Id: <199604231949.MAA08435@mailhost.Ipsilon.COM> X-Mailer: exmh version 1.6.4 10/10/95 To: Ran Atkinson Cc: ipsec@TIS.COM Subject: Re: clear ports In-Reply-To: Your message of "Mon, 22 Apr 1996 19:26:59 PDT." <199604230226.TAA11920@puli.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Apr 1996 12:49:07 -0700 From: Greg Minshall Sender: ipsec-approval@neptune.tis.com Precedence: bulk Ran, > If the user didn't want the ports and transport-layer covered up, then the > user would have used an upper-layer security service (e.g. PEM, PGP, SSL, > whatever) instead of IPsec. Uncovering the ports within the context of > IPsec is unwise and contrary to the intent of the IPsec work. I guess i'm not convinced that a priori it is necessary to require that ESP cover up the protocol/ports. I think that in many many cases, what people are trying to keep private is the payload of the transport data (eg, passwords, payroll data, etc.). I think that in some cases, traffic analysis (at the level of ports/protocol) is something people want to protect. Below is (what i believe to be) the IPSEC charter; i don't believe that it answers the question "to encrypt ports/protocol or not to encrypt ports/protocol?". Additionally, i suspect that the effort required to design, develop, and deploy IPSEC is going to make it widely used in the place of things such as TELNET encryption, FTP encryption, SSL, etc. I.e., it is going to solve all these problems, it is there (and, hopefully, ubiquitous), and people will use it. Cheers, Greg ---- Rapid advances in communication technology have accentuated the need for security in the Internet. The IP Security Protocol Working Group (IPSEC) will develop mechanisms to protect client protocols of IP. A security protocol in the network layer will be developed to provide cryptographic security services that will flexibly support combinations of authentication, integrity, access control, and confidentiality. The protocol formats for the IP Authentication Header (AH) and IP Encapsulating Security Payload (ESP) will be independent of the cryptographic algorithm. The preliminary goals will specifically pursue host-to-host security followed by subnet-to-subnet and host-to-subnet topologies. Protocol and cryptographic techniques will also be developed to support the key management requirements of the network layer security. The Internet Key Management Protocol (IKMP) will be specified as an application layer protocol that is independent of the lower layer security protocol. The protocol will initially support public key-based techniques. Flexibility in the protocol will allow eventual support of Key Distribution Centers (KDC), such as are used by Kerberos. Received: from relay.tis.com by neptune.TIS.COM id aa19648; 23 Apr 96 18:44 EDT Received: by relay.tis.com; id SAA01047; Tue, 23 Apr 1996 18:45:17 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma001038; Tue, 23 Apr 96 18:44:48 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03948; Tue, 23 Apr 96 18:45:11 EDT Received: by relay.tis.com; id SAA01035; Tue, 23 Apr 1996 18:44:47 -0400 Received: from dfw-ix5.ix.netcom.com(206.214.98.5) by relay.tis.com via smap (V3.1) id xma001033; Tue, 23 Apr 96 18:44:34 -0400 Received: from pon-mi2-24.ix.netcom.com (pon-mi2-24.ix.netcom.com [205.186.168.88]) by dfw-ix5.ix.netcom.com (8.6.13/8.6.12) with SMTP id PAA16209 for ; Tue, 23 Apr 1996 15:51:50 -0700 Received: by pon-mi2-24.ix.netcom.com with Microsoft Mail id <01BB3145.4DDF39C0@pon-mi2-24.ix.netcom.com>; Tue, 23 Apr 1996 18:47:21 -0400 Message-Id: <01BB3145.4DDF39C0@pon-mi2-24.ix.netcom.com> From: Brad Wilson To: "ipsec@TIS.COM" Subject: RE: clear ports Date: Tue, 23 Apr 1996 18:47:08 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk Greg Minshall wrote: >> I guess i'm not convinced that a priori it is necessary to require that ESP >> cover up the protocol/ports. ... >> Below is (what i believe to be) the IPSEC charter; i don't believe that it >> answers the question "to encrypt ports/protocol or not to encrypt >> ports/protocol?". ... >> The IP Security Protocol Working Group (IPSEC) will >> develop mechanisms to protect client protocols of IP. This certainly sounds like "protecting protocol and port" information. At the very least, it would seem that there is a strong desire to protect these things, regardless of whether or not the actual words "encrypt ports and protocols" are present in the very short summary that you point to. Brad -- Brad Wilson, Crucial Software crucial@ix.netcom.com +1 (810) 620-9803 Custom software engineering services for Microsoft Windows NT and Windows 95 Received: from relay.tis.com by neptune.TIS.COM id aa20323; 23 Apr 96 19:22 EDT Received: by relay.tis.com; id TAA01425; Tue, 23 Apr 1996 19:23:47 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma001423; Tue, 23 Apr 96 19:23:18 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA04762; Tue, 23 Apr 96 19:23:41 EDT Received: by relay.tis.com; id TAA01417; Tue, 23 Apr 1996 19:23:17 -0400 Received: from foo-5-10.ipsilon.com(205.226.5.12) by relay.tis.com via smap (V3.1) id xma001406; Tue, 23 Apr 96 19:22:47 -0400 Received: from mailhost.ipsilon.com (localhost [127.0.0.1]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id QAA15501; Tue, 23 Apr 1996 16:24:47 -0700 Message-Id: <199604232324.QAA15501@mailhost.Ipsilon.COM> X-Mailer: exmh version 1.6.4 10/10/95 To: Brad Wilson Cc: "ipsec@TIS.COM" Subject: Re: clear ports In-Reply-To: Your message of "Tue, 23 Apr 1996 18:47:08 EDT." <01BB3145.4DDF39C0@pon-mi2-24.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Apr 1996 16:24:46 -0700 From: Greg Minshall Sender: ipsec-approval@neptune.tis.com Precedence: bulk enough! i agree, tail between my legs, that, in fact, "protect client protocols of IP" is certainly most reasonably read as protecting ports (which, in general, i still believe to be at least worrisome and, possibly, a mistake)! Received: from relay.tis.com by neptune.TIS.COM id aa22544; 23 Apr 96 21:55 EDT Received: by relay.tis.com; id VAA03406; Tue, 23 Apr 1996 21:56:56 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xmab03403; Tue, 23 Apr 96 21:56:31 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA07086; Tue, 23 Apr 96 21:56:51 EDT Received: by relay.tis.com; id VAA03397; Tue, 23 Apr 1996 21:56:26 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1) id xma003393; Tue, 23 Apr 96 21:56:11 -0400 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id SAA21810; Tue, 23 Apr 1996 18:58:49 -0700 Received: by mailsun2.us.oracle.com (8.7.1/37.8) id TAA22695; Tue, 23 Apr 1996 19:01:36 -0700 (PDT) Message-Id: <199604240201.TAA22695@mailsun2.us.oracle.com> Date: 23 Apr 96 18:55:19 -0700 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: ESP over TCP? Mime-Version: 1.0 Sender: ipsec-approval@neptune.tis.com Precedence: bulk Greg, >I guess i'm not convinced that a priori it is necessary to require that ESP >cover up the protocol/ports. ESP is simple because it "encapsulates" the payload. Exposing port numbers is a very bad idea because it violates implementation layering, it violates some security policies, it is transport layer specific, etc. QOS is another issue and could be addressed in a variety of ways. If you have requirements for a better encapsulation protocol over TCP, would ESP over TCP work? 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 aa04190; 24 Apr 96 10:28 EDT Received: by relay.tis.com; id KAA10773; Wed, 24 Apr 1996 10:29:42 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma010771; Wed, 24 Apr 96 10:29:13 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA23872; Wed, 24 Apr 96 10:29:37 EDT Received: by relay.tis.com; id KAA10768; Wed, 24 Apr 1996 10:29:12 -0400 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1) id xma010761; Wed, 24 Apr 96 10:28:42 -0400 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id KAA23967; Wed, 24 Apr 1996 10:31:13 -0400 (EDT) Message-Id: <199604241431.KAA23967@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Greg Minshall Cc: Ran Atkinson , ipsec@TIS.COM Subject: Re: clear ports In-Reply-To: Your message of "Tue, 23 Apr 1996 12:49:07 PDT." <199604231949.MAA08435@mailhost.Ipsilon.COM> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 24 Apr 1996 10:31:11 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Greg Minshall writes: > I guess i'm not convinced that a priori it is necessary to require > that ESP cover up the protocol/ports. I think that in many many > cases, what people are trying to keep private is the payload of the > transport data (eg, passwords, payroll data, etc.). 1) Lots of our users are going to be interested in preventing detailed port and protocol information from being seen. Conservative security design says "hide everything you don't absolutely need to expose". I can think of excellent reasons that one doesn't want protocol and port information on the wire in the general case -- that could give away very valuable traffic analysis information which can be used to help break a security system, for example. 2) Our current design would be very hard to change in this regard. ESP was designed to be fully opaque, and there is no way for an observer to know what the transform used on an ESP packet is, because the only indicator of all that stuff is a prenegotiated 32 bit number. 3) I personally don't want this information leaking if I'm the guy sending the packets. Long term paranoia from the security consulting world has leaked into my psyche. If I don't need to expose information, and I don't know how it could be used to attack me, I don't want it out. Just because I can't think of a use for information offhand doesn't mean it won't be exploited -- indeed, the history of this field shows that it most certainly *will* be exploited at some point. .pm Received: from relay.tis.com by neptune.TIS.COM id aa07586; 24 Apr 96 12:56 EDT Received: by relay.tis.com; id MAA14187; Wed, 24 Apr 1996 12:57:22 -0400 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 xma014184; Wed, 24 Apr 96 12:56:53 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA05005; Wed, 24 Apr 96 12:57:17 EDT Received: by relay.tis.com; id MAA14181; Wed, 24 Apr 1996 12:56:52 -0400 Received: from venera.isi.edu(128.9.0.32) by relay.tis.com via smap (V3.1) id xma014179; Wed, 24 Apr 96 12:56:37 -0400 Received: from ash.isi.edu (ash-a.isi.edu) by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 24 Apr 1996 09:59:12 -0700 Date: Wed, 24 Apr 1996 09:58:57 -0700 Posted-Date: Wed, 24 Apr 1996 09:58:57 -0700 Message-Id: <199604241658.AA08056@ash.isi.edu> Received: by ash.isi.edu (5.65c/4.0.3-4) id ; Wed, 24 Apr 1996 09:58:57 -0700 To: ipsec@TIS.COM, PALAMBER@us.oracle.com Subject: Re: ESP over TCP? X-Auto-Sig-Adder-By: faber@isi.edu Sender: ipsec-approval@neptune.tis.com Precedence: bulk > From ipsec-request@neptune.tis.com Tue Apr 23 19:27:54 1996 > Date: 23 Apr 96 18:55:19 -0700 > From: "PALAMBER.US.ORACLE.COM" > To: ipsec@tis.com > Subject: ESP over TCP? > > Greg, ... > ESP is simple because it "encapsulates" the payload. Exposing port numbers is > a very bad idea because it violates implementation layering, it violates some ... > Paul Why is implementation layering good? 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 aa18642; 25 Apr 96 2:04 EDT Received: by relay.tis.com; id CAA28439; Thu, 25 Apr 1996 02:05:35 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma028411; Thu, 25 Apr 96 02:05:12 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA00479; Thu, 25 Apr 96 02:05:33 EDT Received: by relay.tis.com; id CAA28405; Thu, 25 Apr 1996 02:05:06 -0400 Received: from merit.edu(35.1.1.42) by relay.tis.com via smap (V3.1) id xma028399; Thu, 25 Apr 96 02:05:01 -0400 Received: from Bill.Simpson.DialUp.Mich.Net (pm002-22.dialip.mich.net [141.211.7.158]) by merit.edu (8.7.5/merit-2.0) with SMTP id CAA18184 for ; Thu, 25 Apr 1996 02:07:38 -0400 (EDT) Date: Thu, 25 Apr 96 05:49:14 GMT From: William Allen Simpson Message-Id: <5286.wsimpson@greendragon.com> To: Greg Minshall Cc: ipsec@TIS.COM Subject: Re: clear ports Sender: ipsec-approval@neptune.tis.com Precedence: bulk > From: Greg Minshall > I guess i'm not convinced that a priori it is necessary to require that ESP > cover up the protocol/ports. I think that in many many cases, what people are > trying to keep private is the payload of the transport data (eg, passwords, > payroll data, etc.). I think that in some cases, traffic analysis (at the > level of ports/protocol) is something people want to protect. > While it is true that very few folks are really worried about traffic analysis, it might be possible that breaking the session-keys could use information about what protocol header is inside the encrypted data, to look for regular patterns. So, it is probably best to hide that information. Meanwhile, I think your problem model can be easily solved (from my meager understanding of your product) by thinking about the two major cases: firewall virtual private networks, and client/server. 1) Firewall VPNs will look to your product very much like a single flow. The packet sizes might change, but in general the forwarding will be identical on every packet. Should be a fast decision for you. I doubt there are many firewalls using TOS, but it is certainly possible, and you could cue off that for different services. But I would expect that the firewalls have already done the WFQ and such for their own users, and you won't be able to add much value. 2) For client to server and vice versa, you have 2 routing clues; the addresses (of course) and the SPIs. Different users will have different SPIs. Each telnet or FTP will have a different SPI. The SPI behaves very much like a port pair, albeit you don't know for what services. If you are looking at characteristics of the flows, the TOS associated with the SPI might help here, too. > Below is (what i believe to be) the IPSEC charter; i don't believe that it > answers the question "to encrypt ports/protocol or not to encrypt > ports/protocol?". > Well, I wouldn't put too much faith in that charter. Look at the dates for completion.... 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 aa21448; 25 Apr 96 6:01 EDT Received: by relay.tis.com; id GAA00967; Thu, 25 Apr 1996 06:02:35 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma000963; Thu, 25 Apr 96 06:02:06 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03689; Thu, 25 Apr 96 06:02:31 EDT Received: by relay.tis.com; id GAA00958; Thu, 25 Apr 1996 06:02:05 -0400 Received: from copilot.is.chrysler.com(204.189.94.148) by relay.tis.com via smap (V3.1) id xma000954; Thu, 25 Apr 96 06:02:02 -0400 Received: by pilotx.firewall.is.chrysler.com; id GAA27756; Thu, 25 Apr 1996 06:04:36 -0400 Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilotx.is.chrysler.com via smap (g3.0.1) id sma027752; Thu, 25 Apr 96 06:04:25 -0400 Received: from rgm3 by clhubgw1-nf0.is.chrysler.com (8.7.5/SMI-4.1) id GAA05991; Thu, 25 Apr 1996 06:06:56 -0400 (EDT) Message-Id: <2.2.32.19960425100407.0090ba08@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, 25 Apr 1996 06:04:07 -0400 To: Ran Atkinson , pferguso@cisco.com From: Robert Moskowitz Subject: Re: ports in the clear... Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk I've been quite busy of late in too many venues. I am on a plane heading home from DC where I explained to a bunch of interesting people what the auto industry will need in security (I am now the chair of the AIAG security work group, thanks people for educating me, I'm really dangerous now ;). My general feeling is expose as little as possible and damn the bean counters. This is true for real time security like in IPSec and hopefully at some point with object security (S/MIME and MSP flunk the test it seems). I do not want someone to figure out that a particular multicast session is a CAD virtual reality process (yeah, I'm going to need all of this with multicast too) based on the port number that every competitor uses for this, as sometimes we are partners. ARGH! End-to-end will be needed, but the firewalls will be in the way, so IPSec will have some real challenges; at trusted firewall that maintains the secure channel on each side? Oh boy. I think I just got myself a life time job, anyone want to trade? :) Oh, I had a site visit to ISUZU and they use Net10, just like Chrysler and Ford dealers do and I think one other OEM. So end-to-end will be interesting. Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.tis.com by neptune.TIS.COM id aa04128; 29 Apr 96 8:29 EDT Received: by relay.tis.com; id IAA24518; Mon, 29 Apr 1996 08:30:12 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma024504; Mon, 29 Apr 96 08:29:45 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08678; Mon, 29 Apr 96 08:30:05 EDT Received: by relay.tis.com; id IAA24490; Mon, 29 Apr 1996 08:29:42 -0400 Received: from interlock.ans.net(147.225.5.5) by relay.tis.com via smap (V3.1) id xma024483; Mon, 29 Apr 96 08:29:15 -0400 Received: by interlock.ans.net id AA06000 (InterLock SMTP Gateway 3.0 for ipsec@ans.net); Mon, 29 Apr 1996 08:31:47 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 29 Apr 1996 08:31:47 -0400 Message-Id: <3039866563.1.p01152@psilink.com> Date: Mon, 29 Apr 96 08:27:46 -0500 To: ipsec@ans.net From: jeff pickering Organization: phase2 networks Subject: SKIP X-Mailer: PSILink-DOS (3.5.2) Sender: ipsec-approval@neptune.tis.com Precedence: bulk I would like some feedback on the status of SKIP, ie: - what is its status? likely to go to RFC? - where is it likely to be used? eg. Does it have a different range of applications than photuris or do the two protocols do the same thing and therefore the market will decide what to use and where? Anybody response would be greatly appreciated. Thanks jeff Received: from relay.tis.com by neptune.TIS.COM id aa08247; 29 Apr 96 12:14 EDT Received: by relay.tis.com; id MAA29364; Mon, 29 Apr 1996 12:15:47 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma029360; Mon, 29 Apr 96 12:15:19 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA29236; Mon, 29 Apr 96 12:15:40 EDT Received: by relay.tis.com; id MAA29357; Mon, 29 Apr 1996 12:15:17 -0400 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1) id xma029355; Mon, 29 Apr 96 12:15:13 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id JAA25285; Mon, 29 Apr 1996 09:17:50 -0700 Date: Mon, 29 Apr 1996 09:17:50 -0700 From: Ran Atkinson Message-Id: <199604291617.JAA25285@puli.cisco.com> To: p01152@psilink.com Subject: Re: SKIP status In-Reply-To: <3039866563.1.p01152@psilink.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk In article <3039866563.1.p01152@psilink.com> Jeff Pickering wrote: >I would like some feedback on the status of SKIP, ie: > >- what is its status? This is an "official" response in my role as co-chair of the IPsec WG. SKIP is currently a set of Internet-Drafts. It is one of 2 proposals under active consideration for possible publication as Proposed Standard RFCs for key management. The two proposals under active consideration are: SKIP ISAKMP with Oakley extensions (ISAKMP+Oakley) SKIP and ISAKMP+Oakley each have freely distributable implementations of the most recent drafts in progress. Each has resolved the issue of the Diffie-Hellman patent in precisely the same way. Each has support from at least one major vendor. A third proposal, known as Photuris, is not currently under active consideration for standards-track RFC because its editor has repeatedly refused to edit that document to conform to WG consensus. At the LA IETF meeting in March, Jeff Schiller (Security Area Director) took a straw poll on key management. There was nothing close to consensus behind any of the proposals at that time. The IETF requires that there be rough consensus in the WG _before_ a proposal can go to Proposed Standard RFC. It is unclear when such consensus will emerge, so the RFCs are being published as Experimental status so that more experience can be obtained. >- likely to go to RFC? Several of the SKIP documents, the ISAKMP document, and the Oakley document are all going to become Experimental RFCs (not standards-track) in the near term (most are already in the queue at the RFC Editor and will appear whenever the RFC Editor gets to them). It is VERY important to recall that many RFCs are not standards-track and hence publication as an RFC does not necessarily mean anything. The widely deployed Internet protocols (e.g. TCP, IP, UDP) are all standards-track RFCs, so the status of the RFC does make some difference in the probable deployment. Ran rja@inet.org Co-Chair, IPsec WG Received: from relay.tis.com by neptune.TIS.COM id aa16747; 29 Apr 96 20:33 EDT Received: by relay.tis.com; id UAA12146; Mon, 29 Apr 1996 20:34:19 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma012140; Mon, 29 Apr 96 20:33:52 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20819; Mon, 29 Apr 96 20:34:13 EDT Received: by relay.tis.com; id UAA12129; Mon, 29 Apr 1996 20:33:50 -0400 Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1) id xma012119; Mon, 29 Apr 96 20:33:41 -0400 Received: from [128.89.30.10] (ARA10.BBN.COM [128.89.30.10]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id UAA17816; Mon, 29 Apr 1996 20:39:15 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 29 Apr 1996 20:37:52 -0400 To: touch@isi.edu From: Stephen Kent Subject: Re: ESP over TCP? Cc: ipsec@TIS.COM, PALAMBER@us.oracle.com Sender: ipsec-approval@neptune.tis.com Precedence: bulk Joe, Implementation layering is advantageous to the extent that it allows easier retrofitting of new protocols, especially encapsulation protocols like ESP. The downside of implementation layering is potentially poorer performance vs. implementations that cross layer boundaries to reduce buffer copying, etc. Steve Received: from relay.tis.com by neptune.TIS.COM id aa19036; 30 Apr 96 0:17 EDT Received: by relay.tis.com; id AAA14413; Tue, 30 Apr 1996 00:18:25 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma014409; Tue, 30 Apr 96 00:17:58 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25097; Tue, 30 Apr 96 00:18:18 EDT Received: by relay.tis.com; id AAA14403; Tue, 30 Apr 1996 00:17:55 -0400 Received: from hughes.network.com(129.191.63.2) by relay.tis.com via smap (V3.1) id xma014399; Tue, 30 Apr 96 00:17:31 -0400 Received: by hughes.network.com (940816.SGI.8.6.9/940406.SGI) id XAA24687; Mon, 29 Apr 1996 23:19:41 -0500 Date: Mon, 29 Apr 1996 23:19:41 -0500 From: "James P. Hughes" Message-Id: <199604300419.XAA24687@hughes.network.com> Apparently-To: internet-drafts@cnri.reston.va.us Apparently-To: ipsec@tis.com Apparently-To: draft-ietf-ipsec-esp-des-md5-01.txt@tis.com Sender: ipsec-approval@neptune.tis.com Precedence: bulk Security Working Group IPsec Working Group Request for Comments: DRAFT J. Hughes, Editor April 1996 Expires in Six months Combined DES-CBC, HMAC and Replay Prevention Security Transform Status of this Memo This document is a submission to the IETF Internet Protocol Security (IPSEC) Working Group. Comments are solicited and should be addressed to the working group mailing list (ipsec@tis.com) or to the editor. This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts draft documents are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract This draft describes a combination of privacy and optionally, authentication, integrity and replay prevention into a single packet format. This document is the result of significant work by several major contributors and the IPsec working group as a whole. These contributors, cited later in this document, provided many of the key technical details summarized in this document. Hughes [Page 1] RFC DRAFT April 1996 Discussion This draft allows a combination of MD5 and DES-CBC. In addition to privacy, the goal of this transform is to ensure that the packet is authentic, can not be modified in transit, or replayed. The valid combinations of this transformation are summarized below. Name Description -------- -------------- esp-DES-IV32 Privacy Tunnel (32 IV) esp-DES-IV64 Privacy Tunnel (64 IV) esp-DES-HMAC-RP DES, HMAC, Replay (Mandatary transform) The combinations of transformations are negotiated at key establishment time such as described in ISA/KMP [Maughan96] and Oakley [Orman96]. To conform with this RFC, of the 3 transforms documented in this RFC, only esp-DES-HMAC-RP shall be implemented. Packet Format There are 3 slightly different packet formats. Format with 32 bit IV (esp-DES-IV32) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- | | ^ ~ Payload Data ~ | | | DES + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CBC | | Padding (0-7 bytes) | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Pad Length | Payload Type | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- Hughes [Page 2] RFC DRAFT April 1996 Format with a 64 bit IV: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 64 bit IV + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- | | ^ ~ Payload Data ~ | | | DES + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CBC | | Padding (0-7 bytes) | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Pad Length | Payload Type | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- Format with DES, HMAC and replay (esp-DES-HMAC-RP) (This is the Mandatary transform) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- | Security Parameters Index (SPI) | ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Replay Prevention Field | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- | | | ^ HMAC ~ Payload Data ~ | | | | DES | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CBC | | | Padding (0-7 bytes) | | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Pad Length | Payload Type | v v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ | | ~ HMAC Residual ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security Parameters Index This field is negotiated at key setup and shall not be 0 [RFC-1825] Hughes [Page 3] RFC DRAFT April 1996 Initialization Vector IV for the first block is either formed from the replay field or from a 32 or 64 bit IV field. The section on replay describes the calculation of the IV when the replay field is present. If a 64 bit IV is used, the entire 64 bits are the IV. If a 32 bit IV is used, the 32 bit IV and its compliment are then concatenated to form the 64 bit IV and that is them XORed by the IV key. Replay Prevention Replay Prevention is an unsigned 32 bit up counter starting at a value of 1. The replay field is also used to create the IV for the first block of ciphertext. This is accomplished by concatenating the SPI and the replay field and XORing this against 64 bits of IV key material (see section on keys). The resulting 64 bits are the IV. The key must not be used for a period of time that allows the counter to wrap, that is, to transmit more than 2^32 packets using a single key. If more than 2^32 packets are transmitted, the counter will alias back to the initial value. Counter wrapping shall be considered a replay attack. At the receiving point, the replay value is assured to be increasing. The implementation may accept of out of order packets. The number of packets wiling to accept out of order is an implementation detail. If a "out of order window" is supported, the implementation shall ensure that any and all packets accepted out of order are guaranteed not to have arrived before. That is, the implementation will accept any packet at most once. An example may allow the most recent 32 packets to be allowed to arrive out of order. That is, these 32 packets can arrive in any sequence relative to each other except that these packets are guaranteed to arrive only once. Other window sizes are optional, both larger and smaller. Appendix A has actual code that implement a 32 packet replay window Hughes [Page 4] RFC DRAFT April 1996 and a test routine to show how it works. Payload The payload contains data that is described by the payload type field. This is a byte length field that can end on any boundary within a word. Padding Shall contains the number of pad bytes to fill the space between the end of the payload and the "pad length" field so that the "payload type" field ends on a double word boundary. Padding bytes man be initialized with random data. More than the minimum bytes necessary to achieve a double word boundary may inserted provided that the total number of bytes added are less than 255. Pad Length Shall contain an unsigned number of bytes of padding. A value of 0 means there was no padding and that the byte immediately preceding the Pad Length field is the last byte of the payload. Payload Type Describes what the payload is. The values are described in: ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers Hughes [Page 5] RFC DRAFT April 1996 HMAC Residual The HMAC residual is a 128 bit residue described in [Krawczyk96]. This covers the SPI, replay, payload, padding, pad length, payload type. HMAC is a keyed algorithm and shall use the HMAC key as described in the section on keys. Key Material The key material for the transform is provided by key management protocol. These bits will be hashed down so that the quality of the bits do not need to have 100% entropy. There are 4 keys. The key management key "K", the "DES Key", the "IV key" and the "HMAC key". The key provided by the key management layer is K. All the other keys are derived from that key. Let MD5(x|y) describes taking the residual x concatenated with y. Let Truncate(x,n) takes the first n bits from x and discards the rest. DES Key = Truncate(MD5( DPad | K ),64) IV Key = Truncate(MD5( IPad | K ),64) HMAC Key = MD5( HPad | K ) where each _Pad is 512 bit string. DPad = 0x5C repeated 64 times. IPad = 0xAC repeated 64 times. HPad = 0x53 repeated 64 times. The 16 byte intermediate residuals can be precalculated from these constants. This method will work with key material from the key server of any size, caveat emptor. Hughes [Page 6] RFC DRAFT April 1996 Security Considerations The claims of privacy, integrity, authentication, and optional replay prevention are made in this draft. I will not try to diagram all the security considerations. A good text is [Schneier95]. Privacy is provided by DES-CBC [Schneier95]. Integrity is provided by HMAC [Krawczyk96]. Authentication is provided since only the source and destination know the HMAC key. If the HMAC is correct, it proves that it must have been added by the source, since only the source knows the HMAC key. Replay prevention is provided by the combination of a constantly increasing count, the SPI and the HMAC key. The integrity of the replay field is provided by the HMAC. There are active attacks to esp-DES-IV32 and esp-DES-IV64 which can (in certain circumstances) compromise the confidentiality of messages encrypted under the DES privacy transform, when no message integrity protection is in use [Bellovin96]. The ESP-DES-HMAC-RP transform described in this draft is immune to this active attack. (AH [RFC-1826], in some modes, can also provide immunity to this attack [Bellovin96].) References [Bellovin96] Bellovin, S., "Problem Areas for the IP Security Protocols", AT&T Research, ftp://ftp.research.att.com/dist/smb/badesp.ps, July, 1996. [Krawczyk96] Krawczyk, H., Bellare, M., Canetti, R., "HMAC-MD5: Keyed-MD5 for Message Authentication", http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ipsec- hmac-md5-00.txt, March, 1996 [Maughan96] Maughan, D., Schertler, M. Internet Security Association and Key Management Protocol (ISAKMP) http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ipsec- isakmp-04.txt, February, 1996 Hughes [Page 7] RFC DRAFT April 1996 [Orman96] Orman, H., "The Oakley Key Determination Protocol", http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ipsec- oakley-00.txt, February, 1996. [RFC-1825] Atkinson, R, "Security Architecture for the Internet Protocol", ftp://ds.internic.net/rfc/rfc1825.txt, August 1995. [RFC-1826] Atkinson, R, "IP Authentication Header", ftp://ds.internic.net/rfc/rfc1826.txt, August 1995. [Schneier95] Schneier, B., "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7 Acknowledgements This document is the result of significant work by several major contributors. They include (in alphabetical order): Robert W. Baldwin RSA Labs. Kevin Kingdon RSA Labs Hugo Krawczyk IBM Corporation Perry Metzger Piermont Information Services Bill Simpson Computer Systems Consulting Services David A Wagner University of California at Berkeley Hughes [Page 8] RFC DRAFT April 1996 In addition, the contributions of the entire IPSEC Working Group are acknowledged. The IPsec working group can be contacted through the chairs: Ran Atkinson Cisco Systems Paul Lambert Oracle Corporation Editor's Address James P. Hughes Network Systems Corporation Hughes [Page 9] RFC DRAFT April 1996 Appendix A This is a routine that implements a 32 packet window. This is intended on being an implementation sample. #include #include typedef unsigned long u_long; enum { ReplayWindowSize = 32 }; u_long bitmap = 0; /* session state - must be 32 bits */ u_long lastSeq = 0; /* session state */ /* Returns 0 if packet disallowed, 1 if packet permitted */ int ChkReplayWindow(u_long seq); int ChkReplayWindow(u_long seq) { u_long diff; if (seq == 0) return 0; /* first == 0 or wrapped */ if (seq > lastSeq) { /* new larger sequence number */ diff = seq - lastSeq; if (diff < ReplayWindowSize) { /* In window */ bitmap <<= diff; while (diff > 1) bitmap &= ~(1 << --diff); bitmap |= 1; /* set bit for this packet */ } else bitmap = 1; /* This packet has a "way larger" */ lastSeq = seq; return 1; /* larger is good */ } diff = lastSeq - seq; if (diff >= ReplayWindowSize) return 0; /* too old or wrapped */ if (bitmap & (1 << diff)) return 0; /* this packet already seen */ bitmap |= (1 << diff); /* mark as seen */ return 1; /* out of order but good */ } Hughes [Page 10] RFC DRAFT April 1996 char string_buffer[512]; #define STRING_BUFFER_SIZE sizeof(string_buffer) int main() { int result; u_long last, current, bits; printf("Input initial state (bits in hex, last msgnum):0); if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) exit(0); sscanf(string_buffer, "%lx %lu", &bits, &last); if (last != 0) bits |= 1; bitmap = bits; lastSeq = last; printf("bits:%08lx last:%lu0, bitmap, lastSeq); printf("Input value to test (current):0); while (1) { if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) break; sscanf(string_buffer, "%lu", ¤t); result = ChkReplayWindow(current); printf("%-3s", result ? "OK" : "BAD"); printf(" bits:%08lx last:%lu0, bitmap, lastSeq); } return 0; } Hughes [Page 11] RFC DRAFT April 1996 Appendix B, Sample Packet Format This appendix contains sample packets for use by implementors checking the their implementations. This is not intended to be a complete test, but it intended to be a single data point. The keys used in this example are: DES Key = 12345678 9abcdef0 IV Key = 87654321 0fedcba9 HMAC Key = 01020304 05060708 090a0b0c 0d0e0f10 Sample packet format in mode esp-DES-IV64 (Privacy Tunnel (64 IV)) Offset Field Data encoded packet 00 SPI 00000100 04 IV 45454545 08 a6a6a6a6 0c data 11111111 2a7440e8 10 22222222 182aaace 14 33333333 5709748b 18 44444444 2b73fd63 1c 00000000 4da53aea 1c Pad 00000604 d2b2c83b Sample packet format in mode esp-DES-HMAC-RP (DES, HMAC, Replay (Mandatary transform). Offset Field Data encoded packet 00 SPI 00000100 04 Replay 00000001 08 data 11111111 885da058 0c 22222222 c548a6f4 10 33333333 f1576af7 14 44444444 eadcc0f0 18 00000000 7d7ad17a 1c Pad 00000604 9284ed5a 20 HMAC d6e8a3f2 24 bfebd36e 28 aa0cf05f 2c ac278b32 Hughes [Page 12] Received: from relay.tis.com by neptune.TIS.COM id aa19054; 30 Apr 96 0:17 EDT Received: by relay.tis.com; id AAA14425; Tue, 30 Apr 1996 00:18:56 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma014419; Tue, 30 Apr 96 00:18:28 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25111; Tue, 30 Apr 96 00:18:48 EDT Received: by relay.tis.com; id AAA14414; Tue, 30 Apr 1996 00:18:25 -0400 Received: from hughes.network.com(129.191.63.2) by relay.tis.com via smap (V3.1) id xma014410; Tue, 30 Apr 96 00:18:11 -0400 Received: by hughes.network.com (940816.SGI.8.6.9/940406.SGI) id XAA24691; Mon, 29 Apr 1996 23:20:00 -0500 Date: Mon, 29 Apr 1996 23:20:00 -0500 From: "James P. Hughes" Message-Id: <199604300420.XAA24691@hughes.network.com> To: internet-drafts@cnri.reston.va.us, ipsec@TIS.COM Subject: draft-ietf-ipsec-esp-des-md5-01.txt Sender: ipsec-approval@neptune.tis.com Precedence: bulk Security Working Group IPsec Working Group Request for Comments: DRAFT J. Hughes, Editor April 1996 Expires in Six months Combined DES-CBC, HMAC and Replay Prevention Security Transform Status of this Memo This document is a submission to the IETF Internet Protocol Security (IPSEC) Working Group. Comments are solicited and should be addressed to the working group mailing list (ipsec@tis.com) or to the editor. This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts draft documents are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract This draft describes a combination of privacy and optionally, authentication, integrity and replay prevention into a single packet format. This document is the result of significant work by several major contributors and the IPsec working group as a whole. These contributors, cited later in this document, provided many of the key technical details summarized in this document. Hughes [Page 1] RFC DRAFT April 1996 Discussion This draft allows a combination of MD5 and DES-CBC. In addition to privacy, the goal of this transform is to ensure that the packet is authentic, can not be modified in transit, or replayed. The valid combinations of this transformation are summarized below. Name Description -------- -------------- esp-DES-IV32 Privacy Tunnel (32 IV) esp-DES-IV64 Privacy Tunnel (64 IV) esp-DES-HMAC-RP DES, HMAC, Replay (Mandatary transform) The combinations of transformations are negotiated at key establishment time such as described in ISA/KMP [Maughan96] and Oakley [Orman96]. To conform with this RFC, of the 3 transforms documented in this RFC, only esp-DES-HMAC-RP shall be implemented. Packet Format There are 3 slightly different packet formats. Format with 32 bit IV (esp-DES-IV32) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- | | ^ ~ Payload Data ~ | | | DES + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CBC | | Padding (0-7 bytes) | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Pad Length | Payload Type | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- Hughes [Page 2] RFC DRAFT April 1996 Format with a 64 bit IV: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 64 bit IV + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- | | ^ ~ Payload Data ~ | | | DES + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CBC | | Padding (0-7 bytes) | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Pad Length | Payload Type | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- Format with DES, HMAC and replay (esp-DES-HMAC-RP) (This is the Mandatary transform) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- | Security Parameters Index (SPI) | ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Replay Prevention Field | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- | | | ^ HMAC ~ Payload Data ~ | | | | DES | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CBC | | | Padding (0-7 bytes) | | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Pad Length | Payload Type | v v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ | | ~ HMAC Residual ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security Parameters Index This field is negotiated at key setup and shall not be 0 [RFC-1825] Hughes [Page 3] RFC DRAFT April 1996 Initialization Vector IV for the first block is either formed from the replay field or from a 32 or 64 bit IV field. The section on replay describes the calculation of the IV when the replay field is present. If a 64 bit IV is used, the entire 64 bits are the IV. If a 32 bit IV is used, the 32 bit IV and its compliment are then concatenated to form the 64 bit IV and that is them XORed by the IV key. Replay Prevention Replay Prevention is an unsigned 32 bit up counter starting at a value of 1. The replay field is also used to create the IV for the first block of ciphertext. This is accomplished by concatenating the SPI and the replay field and XORing this against 64 bits of IV key material (see section on keys). The resulting 64 bits are the IV. The key must not be used for a period of time that allows the counter to wrap, that is, to transmit more than 2^32 packets using a single key. If more than 2^32 packets are transmitted, the counter will alias back to the initial value. Counter wrapping shall be considered a replay attack. At the receiving point, the replay value is assured to be increasing. The implementation may accept of out of order packets. The number of packets wiling to accept out of order is an implementation detail. If a "out of order window" is supported, the implementation shall ensure that any and all packets accepted out of order are guaranteed not to have arrived before. That is, the implementation will accept any packet at most once. An example may allow the most recent 32 packets to be allowed to arrive out of order. That is, these 32 packets can arrive in any sequence relative to each other except that these packets are guaranteed to arrive only once. Other window sizes are optional, both larger and smaller. Appendix A has actual code that implement a 32 packet replay window Hughes [Page 4] RFC DRAFT April 1996 and a test routine to show how it works. Payload The payload contains data that is described by the payload type field. This is a byte length field that can end on any boundary within a word. Padding Shall contains the number of pad bytes to fill the space between the end of the payload and the "pad length" field so that the "payload type" field ends on a double word boundary. Padding bytes man be initialized with random data. More than the minimum bytes necessary to achieve a double word boundary may inserted provided that the total number of bytes added are less than 255. Pad Length Shall contain an unsigned number of bytes of padding. A value of 0 means there was no padding and that the byte immediately preceding the Pad Length field is the last byte of the payload. Payload Type Describes what the payload is. The values are described in: ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers Hughes [Page 5] RFC DRAFT April 1996 HMAC Residual The HMAC residual is a 128 bit residue described in [Krawczyk96]. This covers the SPI, replay, payload, padding, pad length, payload type. HMAC is a keyed algorithm and shall use the HMAC key as described in the section on keys. Key Material The key material for the transform is provided by key management protocol. These bits will be hashed down so that the quality of the bits do not need to have 100% entropy. There are 4 keys. The key management key "K", the "DES Key", the "IV key" and the "HMAC key". The key provided by the key management layer is K. All the other keys are derived from that key. Let MD5(x|y) describes taking the residual x concatenated with y. Let Truncate(x,n) takes the first n bits from x and discards the rest. DES Key = Truncate(MD5( DPad | K ),64) IV Key = Truncate(MD5( IPad | K ),64) HMAC Key = MD5( HPad | K ) where each _Pad is 512 bit string. DPad = 0x5C repeated 64 times. IPad = 0xAC repeated 64 times. HPad = 0x53 repeated 64 times. The 16 byte intermediate residuals can be precalculated from these constants. This method will work with key material from the key server of any size, caveat emptor. Hughes [Page 6] RFC DRAFT April 1996 Security Considerations The claims of privacy, integrity, authentication, and optional replay prevention are made in this draft. I will not try to diagram all the security considerations. A good text is [Schneier95]. Privacy is provided by DES-CBC [Schneier95]. Integrity is provided by HMAC [Krawczyk96]. Authentication is provided since only the source and destination know the HMAC key. If the HMAC is correct, it proves that it must have been added by the source, since only the source knows the HMAC key. Replay prevention is provided by the combination of a constantly increasing count, the SPI and the HMAC key. The integrity of the replay field is provided by the HMAC. There are active attacks to esp-DES-IV32 and esp-DES-IV64 which can (in certain circumstances) compromise the confidentiality of messages encrypted under the DES privacy transform, when no message integrity protection is in use [Bellovin96]. The ESP-DES-HMAC-RP transform described in this draft is immune to this active attack. (AH [RFC-1826], in some modes, can also provide immunity to this attack [Bellovin96].) References [Bellovin96] Bellovin, S., "Problem Areas for the IP Security Protocols", AT&T Research, ftp://ftp.research.att.com/dist/smb/badesp.ps, July, 1996. [Krawczyk96] Krawczyk, H., Bellare, M., Canetti, R., "HMAC-MD5: Keyed-MD5 for Message Authentication", http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ipsec- hmac-md5-00.txt, March, 1996 [Maughan96] Maughan, D., Schertler, M. Internet Security Association and Key Management Protocol (ISAKMP) http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ipsec- isakmp-04.txt, February, 1996 Hughes [Page 7] RFC DRAFT April 1996 [Orman96] Orman, H., "The Oakley Key Determination Protocol", http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ipsec- oakley-00.txt, February, 1996. [RFC-1825] Atkinson, R, "Security Architecture for the Internet Protocol", ftp://ds.internic.net/rfc/rfc1825.txt, August 1995. [RFC-1826] Atkinson, R, "IP Authentication Header", ftp://ds.internic.net/rfc/rfc1826.txt, August 1995. [Schneier95] Schneier, B., "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7 Acknowledgements This document is the result of significant work by several major contributors. They include (in alphabetical order): Robert W. Baldwin RSA Labs. Kevin Kingdon RSA Labs Hugo Krawczyk IBM Corporation Perry Metzger Piermont Information Services Bill Simpson Computer Systems Consulting Services David A Wagner University of California at Berkeley Hughes [Page 8] RFC DRAFT April 1996 In addition, the contributions of the entire IPSEC Working Group are acknowledged. The IPsec working group can be contacted through the chairs: Ran Atkinson Cisco Systems Paul Lambert Oracle Corporation Editor's Address James P. Hughes Network Systems Corporation Hughes [Page 9] RFC DRAFT April 1996 Appendix A This is a routine that implements a 32 packet window. This is intended on being an implementation sample. #include #include typedef unsigned long u_long; enum { ReplayWindowSize = 32 }; u_long bitmap = 0; /* session state - must be 32 bits */ u_long lastSeq = 0; /* session state */ /* Returns 0 if packet disallowed, 1 if packet permitted */ int ChkReplayWindow(u_long seq); int ChkReplayWindow(u_long seq) { u_long diff; if (seq == 0) return 0; /* first == 0 or wrapped */ if (seq > lastSeq) { /* new larger sequence number */ diff = seq - lastSeq; if (diff < ReplayWindowSize) { /* In window */ bitmap <<= diff; while (diff > 1) bitmap &= ~(1 << --diff); bitmap |= 1; /* set bit for this packet */ } else bitmap = 1; /* This packet has a "way larger" */ lastSeq = seq; return 1; /* larger is good */ } diff = lastSeq - seq; if (diff >= ReplayWindowSize) return 0; /* too old or wrapped */ if (bitmap & (1 << diff)) return 0; /* this packet already seen */ bitmap |= (1 << diff); /* mark as seen */ return 1; /* out of order but good */ } Hughes [Page 10] RFC DRAFT April 1996 char string_buffer[512]; #define STRING_BUFFER_SIZE sizeof(string_buffer) int main() { int result; u_long last, current, bits; printf("Input initial state (bits in hex, last msgnum):0); if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) exit(0); sscanf(string_buffer, "%lx %lu", &bits, &last); if (last != 0) bits |= 1; bitmap = bits; lastSeq = last; printf("bits:%08lx last:%lu0, bitmap, lastSeq); printf("Input value to test (current):0); while (1) { if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) break; sscanf(string_buffer, "%lu", ¤t); result = ChkReplayWindow(current); printf("%-3s", result ? "OK" : "BAD"); printf(" bits:%08lx last:%lu0, bitmap, lastSeq); } return 0; } Hughes [Page 11] RFC DRAFT April 1996 Appendix B, Sample Packet Format This appendix contains sample packets for use by implementors checking the their implementations. This is not intended to be a complete test, but it intended to be a single data point. The keys used in this example are: DES Key = 12345678 9abcdef0 IV Key = 87654321 0fedcba9 HMAC Key = 01020304 05060708 090a0b0c 0d0e0f10 Sample packet format in mode esp-DES-IV64 (Privacy Tunnel (64 IV)) Offset Field Data encoded packet 00 SPI 00000100 04 IV 45454545 08 a6a6a6a6 0c data 11111111 2a7440e8 10 22222222 182aaace 14 33333333 5709748b 18 44444444 2b73fd63 1c 00000000 4da53aea 1c Pad 00000604 d2b2c83b Sample packet format in mode esp-DES-HMAC-RP (DES, HMAC, Replay (Mandatary transform). Offset Field Data encoded packet 00 SPI 00000100 04 Replay 00000001 08 data 11111111 885da058 0c 22222222 c548a6f4 10 33333333 f1576af7 14 44444444 eadcc0f0 18 00000000 7d7ad17a 1c Pad 00000604 9284ed5a 20 HMAC d6e8a3f2 24 bfebd36e 28 aa0cf05f 2c ac278b32 Hughes [Page 12] jim Received: from relay.tis.com by neptune.TIS.COM id aa29585; 30 Apr 96 13:16 EDT Received: by relay.tis.com; id NAA26523; Tue, 30 Apr 1996 13:17:55 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma026519; Tue, 30 Apr 96 13:17:32 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20875; Tue, 30 Apr 96 13:17:47 EDT Received: by relay.tis.com; id NAA26514; Tue, 30 Apr 1996 13:17:25 -0400 Received: from relay.hp.com(15.255.152.2) by relay.tis.com via smap (V3.1) id xma026508; Tue, 30 Apr 96 13:17:19 -0400 Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA124944796; Tue, 30 Apr 1996 10:19:57 -0700 Message-Id: <199604301719.AA124944796@relay.hp.com> Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com id AA255834801; Tue, 30 Apr 1996 13:20:01 -0400 X-Mailer: exmh version 1.6.2 7/18/95 To: "James P. Hughes" Cc: ipsec@TIS.COM Subject: Re: draft-ietf-ipsec-esp-des-md5-01.txt In-Reply-To: hughes's message of Mon, 29 Apr 1996 23:20:00 -0500. <199604300420.XAA24691@hughes.network.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 30 Apr 1996 13:19:54 -0400 From: Bill Sommerfeld Sender: ipsec-approval@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii quoting from the draft: This draft describes a combination of privacy and optionally, authentication, integrity and replay prevention into a single packet format. and later: The combinations of transformations are negotiated at key establishment time such as described in ISA/KMP [Maughan96] and Oakley [Orman96]. To conform with this RFC, of the 3 transforms documented in this RFC, only esp-DES-HMAC-RP shall be implemented. Ok, is integrity protection mandatory or not? My impression (and please correct me if I'm wrong) was that the consensus of the WG at the LA IETF was that privacy without integrity was too dangerous to implement; however, this draft is internally inconsistant about whether integrity is mandatory, and specifies transforms which it says should not be implemented. What's changed? - Bill -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMYZLtFpj/0M1dMJ/AQFV2QP9FTCQ0W9OmUjcr9ZUsDtliflNMca4SEeg 7r+Gdd0D24KPaJji24FHZdf/JpM45mrlGYf4AzsQ9gBbLN2+uyinqVH4K9F1QQ5X 5sgUVrCC+ylq4uVMTak55f48Pq3pBmOKv+8jaeoULOgGD3WPi1YVHyG8IOZkSyB/ zMlgCYfKAho= =YX9J -----END PGP SIGNATURE----- Received: from relay.tis.com by neptune.TIS.COM id aa29637; 30 Apr 96 13:19 EDT Received: by relay.tis.com; id NAA26635; Tue, 30 Apr 1996 13:20:55 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma026609; Tue, 30 Apr 96 13:20:27 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21065; Tue, 30 Apr 96 13:20:47 EDT Received: by relay.tis.com; id NAA26597; Tue, 30 Apr 1996 13:20:25 -0400 Received: from ftp.com(128.127.2.122) by relay.tis.com via smap (V3.1) id xma026583; Tue, 30 Apr 96 13:20:14 -0400 Received: from ftp.com by ftp.com ; Tue, 30 Apr 1996 13:22:49 -0400 Received: from athena.ftp.com by ftp.com ; Tue, 30 Apr 1996 13:22:49 -0400 Message-Id: <2.2.32.19960430172549.00950e68@mailserv-H.ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 30 Apr 1996 13:25:49 -0400 To: "James P. Hughes" From: Naganand Doraswamy Subject: Re: draft-ietf-ipsec-esp-des-md5-01.txt Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Is there any security reason as to why we ae XORing the IV key when we use 32 bit IV and replay protection and not when using IV lenght of 64 bits. If there is none, then I would suggest that we make it uniform and either XOR with IV key for all transform or dont do it for any transform. Thanks, --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) Received: from relay.tis.com by neptune.TIS.COM id aa00924; 30 Apr 96 14:12 EDT Received: by relay.tis.com; id OAA28532; Tue, 30 Apr 1996 14:13:19 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma028525; Tue, 30 Apr 96 14:12:53 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA23933; Tue, 30 Apr 96 14:13:12 EDT Received: by relay.tis.com; id OAA28521; Tue, 30 Apr 1996 14:12:49 -0400 Received: from snad.ncsl.nist.gov(129.6.55.1) by relay.tis.com via smap (V3.1) id xma028511; Tue, 30 Apr 96 14:12:21 -0400 Received: by snad.ncsl.nist.gov (4.1/SMI-4.0-MHS-7.0) id AA00644; Tue, 30 Apr 96 14:14:51 EDT Date: Tue, 30 Apr 96 14:14:51 EDT From: Robert Glenn Message-Id: <9604301814.AA00644@snad.ncsl.nist.gov> To: internet-drafts@cnri.reston.va.us, ipsec@TIS.COM Subject: draft-ietf-ipsec-ah-hmac-md5-00.txt Sender: ipsec-approval@neptune.tis.com Precedence: bulk Network Working Group M. Oehler (NSA) R. Glenn (NIST) Internet Draft May 1, 1996 HMAC-MD5 IP Authentication with Replay Prevention Status of This Memo Distribution of this memo is unlimited. This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on: ftp.is.co.za (Africa) nic.nordu.net (Europe) ds.internic.net (US East Coast) ftp.isi.edu (US West Coast) munnari.oz.au (Pacific Rim) Abstract This document describes a keyed-MD5 transform to be used in conjunction with the IP Authentication Header [RFC-1826]. The particular transform is based on [HMAC-MD5]. An option is also specified to guard against replay attacks. Oehler, Glenn [Page 1] INTERNET DRAFT May 1, 1996 Expires November 1996 Contents 1. Introduction...................................................3 1.1 Keys........................................................3 1.2 Data Size...................................................4 2. Packet Format..................................................4 2.1 Replay Prevention...........................................4 2.2 Authentication Data Calculation.............................5 3. Security Considerations........................................6 ACKNOWLEDGMENTS....................................................6 REFERENCES.........................................................6 CONTACTS...........................................................6 Oehler, Glenn [Page 2] INTERNET DRAFT May 1, 1996 Expires November 1996 1. Introduction The Authentication Header (AH) [RFC-1826] provides integrity and authentication for IP datagrams. The transform specified in this document uses a keyed-MD5 mechanism [HMAC-MD5]. The mechanism uses the (key-less) MD5 hash function [RFC-1321] which produces a message authentication code. When combined with an AH Key, authentication data is produced. This value is placed in the Authentication Data field of the AH [RFC-1826]. This value is also the basis for the data integrity service offered by the AH protocol. To provide protection against replay attacks, a Replay Prevention field is included as a transform option. The Security Parameters Index (SPI) [RFC-1825] is used to determine whether this option is included in the AH. Familiarity with the following documents is assumed: "Security Architecture for the Internet Protocol" [RFC-1825], "IP Authentication Header" [RFC-1826], and "HMAC-MD5: Keyed-MD5 for Message Authentication" [HMAC-MD5]. 1.1 Keys The "AH Key" is used as a shared secret between two communicating parties. The Key is not a "cryptographic key" as used in a traditional sense. Instead, the AH key (shared secret) is hashed with the transmitted data and thus, assures that an intervening party cannot duplicate the authentication data. Even though an AH key is not a cryptographic key, the rudimentary concerns of cryptographic keys still apply. Consider that the algorithm and most of the data used to produce the output is known. The strength of the transform lies in the singular mapping of the key (which needs to be strong) and the IP datagram (which is known) to the authentication data. Thus, implementations should, and as frequently as possible, change the AH key. Keys need to be chosen at random, or generated using a cryptographically strong pseudo-random generator seeded with a random seed. [HMAC-MD5] There is no mandated key size for the HMAC-MD5 transform. Implementations must support a key length of any size, except zero. It is advised that keys be chosen as the length of the hash output, or 128-bits for MD5. For other key lengths, the following concerns must be considered. A key length of zero is prohibited and implementations should provide an alert, since the authentication data would be identical to that of MD5, solely. Less than 16 bytes is strongly discouraged as it would Oehler, Glenn [Page 3] INTERNET DRAFT May 1, 1996 Expires November 1996 decrease the security strength of the function. Keys longer than 16 bytes are acceptable, but the extra length would not significantly increase the function strength. A longer key may be advisable if the randomness of the key is suspect. MD5 operates on 64-byte blocks. Keys longer than 64 bytes are first hashed using MD5. The resulting hash is then used to calculate the authentication data. 1.2 Data Size MD5 produces a 128-bit value which is used as the authentication data. It is naturally 64 bit aligned and thus, does not need any padding for machines with native double words. 2. Packet Format +---------------+---------------+---------------+---------------+ | Next Header | Length | RESERVED | +---------------+---------------+---------------+---------------+ | SPI | +---------------+---------------+---------------+---------------+ + Replay Prevention (optional) | +---------------+---------------+---------------+---------------+ | | + Authentication Data | | | +---------------+---------------+---------------+---------------+ 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 The Next Header, RESERVED, and SPI fields are specified in [RFC- 1826]. The Length field is the length of the Replay Prevention field and the Authentication Data in 32-bit words. 2.1 Replay Prevention The Replay Prevention field is a 32 bit value used to guarantee that each packet exchanged between two parties is different. This field is similar to the one specified in [ESP-DES-MD5]. The SPI is used to determine whether or not the field is included in the packet (i.e. if it is not included, the header will have the SPI directly followed by the Authentication Data). Without this field it is possible to attack a system by retransmitting packets. The 32-bit field is an up counter starting at a value of 1. The secret shared key must not be used for a period of time that allows the counter to wrap, that is, to transmit more than 2^32 packets using a single key. Oehler, Glenn [Page 4] INTERNET DRAFT May 1, 1996 Expires November 1996 Upon receipt, the replay value is assured to be increasing. The implementation may accept of out of order packets. The number of packets to accept out of order is an implementation detail. If a "out of order window" is supported, the implementation shall ensure that any and all packets accepted out of order are guaranteed not to have arrived before. That is, the implementation will accept any packet at most once. [ESP-DES-MD5] provides example code that implements a 32 packet replay window and a test routine to show how it works. 2.2 Authentication Data Calculation The authentication data is the output of the authentication algorithm (MD5). This value is calculated over the entire IP datagram. Fields within the datagram that are variant during transit and the authentication data field itself, must contain all zeros [RFC-1826]. The Replay Prevention field if present, is included in the calculation. The definition and reference implementation of MD5 appears in [RFC- 1321]. Let 'text' denote the data to which HMAC-MD5 is to be applied and K be the message authentication secret key shared by the parties. We define two fixed and different strings ipad and opad as follows (the 'i' and 'o' are mnemonics for inner and outer): ipad = the byte 0x36 repeated 64 times opad = the byte 0x5C repeated 64 times. To compute HMAC-MD5 over the data `text' we perform MD5(K XOR opad, MD5(K XOR ipad, text)) Namely, (1) append zeros to the end of K to create a 64 byte string (e.g., if K is of length 16 bytes it will be appended with 48 zero bytes 0x00) (2) XOR (bitwise exclusive-OR) the 64 byte string computed in step (1) with ipad (3) append the data stream 'text' to the 64 byte string resulting from step (2) (4) apply MD5 to the stream generated in step (3) (5) XOR (bitwise exclusive-OR) the 64 byte string computed in step (1) with opad (6) append the MD5 result from step (4) to the 64 byte string resulting from step (5) (7) apply MD5 to the stream generated in step (6) and output the result This computation is described in more detail, along with example code and performance improvements, in [HMAC-MD5]. Oehler, Glenn [Page 5] INTERNET DRAFT May 1, 1996 Expires November 1996 3. Security Considerations The security of this transform depends heavily on the strength of MD5 and the associated secret key. [HMAC-MD5] contains a detailed discussion on the strengths and weaknesses of MD5. Acknowledgments This document is largely based on text written by Hugo Krawczyk. The format used was derived from work by William Simpson and Perry Metzger. The text on replay prevention is derived directly from work by Jim Hughes. References [RFC-1825] R. Atkinson, "Security Architecture for the Internet Protocol", RFC-1852, Naval Research Laboratory, July 1995. [RFC-1826] R. Atkinson, "IP Authentication Header", RFC-1826, August 1995. [RFC-1828] P. Metzger, W. A. Simpson, "IP Authentication using Keyed MD5", RFC-1828, August 1995. [RFC-1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC-1321, April 1992. [HMAC-MD5] H. Krawczyk, M. Bellare, R. Canetti, "HMAC-MD5: Keyed-MD5 for Message Authentication", Internet Draft, March, 1996. [ESP-DES-MD5] J. Hughes, "Combined DES-CBC, MD5, and Replay Prevention Security Transform", Internet Draft, April, 1996. Contacts Michael J. Oehler National Security Agency Atn: R23, INFOSEC Research and Development 9800 Savage Road Fort Meade, MD 20755 mjo@tycho.ncsc.mil Robert Glenn NIST Building 820, Room 455 Gaithersburg, MD 20899 rob.glenn@nist.gov Oehler, Glenn [Page 6] Received: from relay.tis.com by neptune.TIS.COM id aa00942; 30 Apr 96 14:13 EDT Received: by relay.tis.com; id OAA28562; Tue, 30 Apr 1996 14:14:19 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma028549; Tue, 30 Apr 96 14:13:51 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA24016; Tue, 30 Apr 96 14:14:11 EDT Received: by relay.tis.com; id OAA28546; Tue, 30 Apr 1996 14:13:49 -0400 Received: from snad.ncsl.nist.gov(129.6.55.1) by relay.tis.com via smap (V3.1) id xma028543; Tue, 30 Apr 96 14:13:46 -0400 Received: by snad.ncsl.nist.gov (4.1/SMI-4.0-MHS-7.0) id AA00678; Tue, 30 Apr 96 14:16:27 EDT Date: Tue, 30 Apr 96 14:16:27 EDT From: Robert Glenn Message-Id: <9604301816.AA00678@snad.ncsl.nist.gov> To: internet-drafts@cnri.reston.va.us, ipsec@TIS.COM Subject: draft-ietf-ipsec-ah-hmac-sha-00.txt Sender: ipsec-approval@neptune.tis.com Precedence: bulk Network Working Group S. Chang (NIST) R. Glenn (NIST) May 1, 1996 Internet Draft HMAC-SHA IP Authentication with Replay Prevention Status of This Memo Distribution of this memo is unlimited. This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on: ftp.is.co.za (Africa) nic.nordu.net (Europe) ds.internic.net (US East Coast) ftp.isi.edu (US West Coast) munnari.oz.au (Pacific Rim) Abstract This document describes a keyed-SHA transform to be used in conjunction with the IP Authentication Header [RFC-1826]. The particular transform is based on [HMAC-MD5]. An option is also specified to guard against replay attacks. Chang, Glenn [Page 1] INTERNET DRAFT May 1, 1996 Expires November 1996 Contents 1. Introduction...................................................3 1.1 Keys........................................................3 1.2 Data Size...................................................4 2 Packet Format..................................................4 2.1 Replay Prevention...........................................4 2.2 Authentication Data Calculation.............................5 3. Security Considerations........................................6 ACKNOWLEDGMENTS....................................................6 REFERENCES.........................................................6 CONTACTS...........................................................6 Chang, Glenn [Page 2] INTERNET DRAFT May 1, 1996 Expires November 1996 1. Introduction The IP Authentication Header (AH) provides integrity and authentication for IP datagrams [RFC-1826]. The transform specified in this document uses a keyed-SHA mechanism based on [HMAC-MD5]. The mechanism uses the (key-less) SHA hash function [FIPS-180-1] which produces a message authentication code. When combined with an AH Key, authentication data is produced. This value is placed in the Authentication Data field of the AH [RFC-1826]. This value is also the basis for the data integrity service offered by the AH protocol. To provide protection against replay attacks, a Replay Prevention field is included as a transform option. The Security Parameters Index (SPI) [RFC-1825] is used to determine whether this option is included in the AH. Familiarity with the following documents is assumed: "Security Architecture for the Internet Protocol" [RFC-1825], "IP Authentication Header" [RFC-1826], and "HMAC-MD5: Keyed-MD5 for Message Authentication" [HMAC-MD5]. 1.1 Keys The "AH Key" is used as a shared secret between two communicating parties. The Key is not a "cryptographic key" as used in a traditional sense. Instead, the AH key (shared secret) is hashed with the transmitted data and thus, assures that an intervening party cannot duplicate the authentication data. Even though an AH key is not a cryptographic key, the rudimentary concerns of cryptographic keys still apply. Consider that the algorithm and most of the data used to produce the output is known. The strength of the transform lies in the singular mapping of the key (which needs to be strong) and the IP datagram (which is known) to the authentication data. Thus, implementations should, and as frequently as possible, change the AH key. Keys need to be chosen at random, or generated using a cryptographically strong pseudo-random generator seeded with a random seed. [HMAC-MD5] There is no mandated key size for the HMAC-SHA transform. Implementations must support a key length of any size, except zero. It is advised that keys be chosen as the length of the hash output, or 160-bits for SHA. For other key lengths, the following concerns must be considered. A key length of zero is prohibited and implementations should provide an alert, since the authentication data would be identical to that of Chang, Glenn [Page 3] INTERNET DRAFT May 1, 1996 Expires November 1996 SHA, solely. SHA operates on 64-byte blocks. Keys longer than 64 bytes are first hashed using SHA. The resulting hash is then used to calculated the authentication data. 1.2 Data Size SHA generates a message digest of 160 bits, which is automatically aligned on a 32-bit word boundary. However, some implementations may require 64-bit alignment of the IP headers, in which case, 32 zero bits are appended as padding to the SHA output. The length of the Authentication Data, specified in the Length field of the AH in 32- bit words, should include the padding bits. Therefore, an implementation that appends a 32-bit padding to the SHA output will have a length of six 32-bit words. The padded bits are ignored at the receiving end. 2. Packet Format +---------------+---------------+---------------+---------------+ | Next Header | Length | RESERVED | +---------------+---------------+---------------+---------------+ | SPI | +---------------+---------------+---------------+---------------+ | Replay Prevention (optional) | +---------------+---------------+---------------+---------------+ | | + Authentication Data | | | +---------------+---------------+---------------+---------------+ 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 The Next Header, RESERVED, and SPI fields are specified in [RFC- 1826]. The Length field is the length of the Replay Prevention field and the Authentication Data in 32-bit words. 2.1 Replay Prevention The Replay Prevention field is a 32 bit value used to guarantee that each packet exchanged between two parties is different. This field is similar to the one specified in [ESP-DES-MD5]. The SPI is used to determine whether or not the field is included in the packet (i.e. if it is not included, the header will have the SPI directly followed by the Authentication Data). Without this field it is possible to attack a system by retransmitting packets. The 32-bit field is an up counter starting at a value of 1. The secret shared key must not be used for a period of time that Chang, Glenn [Page 4] INTERNET DRAFT May 1, 1996 Expires November 1996 allows the counter to wrap, that is, to transmit more than 2^32 packets using a single key. Upon receipt, the replay value is assured to be increasing. The implementation may accept of out of order packets. The number of packets to accept out of order is an implementation detail. If a "out of order window" is supported, the implementation shall ensure that any and all packets accepted out of order are guaranteed not to have arrived before. That is, the implementation will accept any packet at most once. [ESP-DES-MD5] provides example code that implements a 32 packet replay window and a test routine to show how it works. 2.2 Authentication Data Calculation The computation of the 160-bit SHA digest is described in [FIPS-180-1]. The digest is calculated over the entire IP datagram. Fields within the datagram that are variant during transit and the authentication data field itself, must contain all zeros prior to the computation [RFC-1826]. The Replay Prevention field, if present, is included in the calculation. To compute HMAC-SHA over the data 'text', the following is calculated: SHA (K XOR epad, SHA (K XOR ipad, text)) where 'K' denotes the secret key shared by the parties, and 'epad', 'ipad' denotes a fixed string for internal and external padding respectively. The two strings are: ipad = the byte 0x36 repeated 64 times, epad = the byte 0x5C repeated 64 times. The calculation of the authentication data consists of the following steps: (1) append zeros to the end of K to create a 64 byte string (e.g., if K is of length 20 bytes it will be appended with 44 zero bytes 0x00) (2) XOR (bitwise exclusive-OR) the 64 byte string computed in step (1) with ipad (3) concatenate to the 64 byte string resulting from step (2) the data stream 'text' (4) apply SHA to the stream generated in step (3) (5) XOR the 64 byte string computed in step (1) with epad (6) concatenate to the 64 byte string resulting from step (5) the SHA result of step (4) (7) apply SHA to the stream generated in step (6) (8) Pad to 64-bit boundary if necessary for word alignment Chang, Glenn [Page 5] INTERNET DRAFT May 1, 1996 Expires November 1996 A similar computation is described in more detail, along with example code and performance improvements, in [HMAC-MD5]. 3. Security Considerations The security provided by this transform is based on the strength of SHA and the associated secret key. At this time there are no known cryptographic attacks against SHA [SCHNEIER]. The 160-bit digest makes SHA more resistant to brute force attacks than MD4 and MD5 which produce a 128-bit digest. Acknowledgments This document is largely based on text written by Hugo Krawczyk. The format used was derived from work by William Simpson and Perry Metzger. The text on replay prevention is derived directly from work by Jim Hughes. References [RFC-1825] R. Atkinson, "Security Architecture for the Internet Protocol", RFC-1825, August 1995. [RFC-1826] R. Atkinson, "IP Authentication Header", RFC-1826, August 1995. [RFC-1828] P. Metzger, W. A. Simpson, "IP Authentication using Keyed MD5", RFC-1828, August 1995. [HMAC-MD5] H. Krawczyk, M. Bellare, R. Canetti, "HMAC-MD5: Keyed-MD5 for Message Authentication", Internet Draft, March, 1996. [FIPS-180-1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995. [SCHNEIER] B. Schneier, "Applied Cryptography Protocols, Algorithms, and Source Code in C", John Wiley & Sons, Inc. 1994. [ESP-DES-MD5] J. Hughes, "Combined DES-CBC, MD5, and Replay Prevention Security Transform", Internet Draft, April, 1996. Contacts Shu-jen Chang NIST Building 820, Room 456 Gaithersburg, MD 20899 shu-jen.chang@nist.gov Robert Glenn NIST Building 820, Room 455 Gaithersburg, MD 20899 Chang, Glenn [Page 6] INTERNET DRAFT May 1, 1996 Expires November 1996 rob.glenn@nist.gov Chang, Glenn [Page 7] Received: from relay.tis.com by neptune.TIS.COM id aa04697; 30 Apr 96 17:27 EDT Received: by relay.tis.com; id RAA04411; Tue, 30 Apr 1996 17:29:02 -0400 From: pau@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 xma004408; Tue, 30 Apr 96 17:28:34 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06524; Tue, 30 Apr 96 17:28:55 EDT Received: by relay.tis.com; id RAA04402; Tue, 30 Apr 1996 17:28:33 -0400 Received: from unknown(129.34.139.6) by relay.tis.com via smap (V3.1) id xma004395; Tue, 30 Apr 96 17:28:06 -0400 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id RAA21905; Tue, 30 Apr 1996 17:30:51 -0400 Received: from secpwr.watson.ibm.com (secpwr.watson.ibm.com [9.2.23.21]) by mailhub1.watson.ibm.com (8.7.1/03-28-96) with SMTP id RAA61502; Tue, 30 Apr 1996 17:30:36 -0400 Received: by secpwr.watson.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA18708; Tue, 30 Apr 1996 17:35:15 -0400 Date: Tue, 30 Apr 1996 17:35:15 -0400 Message-Id: <9604302135.AA18708@secpwr.watson.ibm.com> To: hughes@network.com Subject: RE:draft-ietf-ipsec-des-md5-00.txt Cc: ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: pjr0iOW6NPyG6+xxBe9+rA== Sender: ipsec-approval@neptune.tis.com Precedence: bulk James, I would suggest in the esp-DES-HMAC-RP transform, the source and destination addresses of the IP packet (which will carry the IPSEC payload) be included in the HMAC computation to provide a sense of direction. These addresses do not have to appear in the actual packet transmitted. This is to provide some defense against reflection attacks. I think this is necessary since it is likely the same set of keys will be used in both directions. I must admit I am not sure if it is possible for some routers to change the source/destination addresses during transmission. Regards, Pau-Chen Received: from relay.tis.com by neptune.TIS.COM id aa05008; 30 Apr 96 17:58 EDT Received: by relay.tis.com; id RAA05115; Tue, 30 Apr 1996 17:59:35 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma005106; Tue, 30 Apr 96 17:59:07 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA07514; Tue, 30 Apr 96 17:59:27 EDT Received: by relay.tis.com; id RAA05100; Tue, 30 Apr 1996 17:59:05 -0400 Received: from relay.hp.com(15.255.152.2) by relay.tis.com via smap (V3.1) id xma005081; Tue, 30 Apr 96 17:58:47 -0400 Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA121881684; Tue, 30 Apr 1996 15:01:25 -0700 Message-Id: <199604302201.AA121881684@relay.hp.com> Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com id AA028681690; Tue, 30 Apr 1996 18:01:30 -0400 X-Mailer: exmh version 1.6.2 7/18/95 To: pau@watson.ibm.com Cc: hughes@network.com, ipsec@TIS.COM Subject: Re: draft-ietf-ipsec-des-md5-00.txt In-Reply-To: pau's message of Tue, 30 Apr 1996 17:35:15 -0400. <9604302135.AA18708@secpwr.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 30 Apr 1996 18:01:23 -0400 From: Bill Sommerfeld Sender: ipsec-approval@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii James, I would suggest in the esp-DES-HMAC-RP transform, the source and destination addresses of the IP packet (which will carry the IPSEC payload) be included in the HMAC computation to provide a sense of direction. These addresses do not have to appear in the actual packet transmitted. This is to provide some defense against reflection attacks. I think this is necessary since it is likely the same set of keys will be used in both directions. Huh? All of the proposed key mgmt protocols I've looked at in any detail generate different keys (and different SPI's) in each direction. - Bill -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMYaNrFpj/0M1dMJ/AQGOmwP9ECO7L+FKXkVKpka3W2Up8notvGI/JLjN pZ1N/Uyypb8x0jWDfeDW9DBZswWkmOeBZNkH7lXQc3oLUzadZvCV2jUAO+fahWCy ipMK+ZgPC+Vp6MXji1QyesHQSABJ1xgtH7q6KHtTmtesePTGS6XiUpWgopq7dITQ 521B2uYhX/A= =P2Vk -----END PGP SIGNATURE-----