From ipsec-owner@p-o.ans.net Fri Feb 2 19:26:44 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA15804 (5.65c/IDA-1.4.4 for ); Fri, 2 Feb 1996 14:38:16 -0500 Received: by p-o.ans.net id AA14027 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 2 Feb 1996 19:26:52 GMT Date: Fri, 2 Feb 1996 11:26:44 -0800 From: Ran Atkinson Message-Id: <199602021926.LAA20484@puli.cisco.com> To: ipsec@ans.net, saag@tis.com Subject: FYI: ATM Forum public mailing lists Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net I was asked to forward this information to appropriate IETF Working Groups. The main item of interest is probably the "ATM Security" mailing list, though the other lists might also be of interest. These lists are open to anyone, unlike the other "closed, members-only" ATM Forum mailing lists. Ran rja@cisco.com Co-chair, IP Security WG ----- Begin Included Message ----- Date: Thu, 1 Feb 1996 20:47:53 -0500 (EST) To: rolc@nexen.com, af-all@atmforum.com From: Jim Grace Subject: ATM Forum External Mailing Lists now available The ATM Forum has set up the following mailing lists for use by both members and non-members in order to generate a wider discussion on some of the topics which the Forum is pursuing. (Until now, mailing lists maintained by the ATM Forum were for use by member companies only.) The new lists are: af-xpnni@atmforum.com (Private ATM Network-Node Interface) af-xmpoa@atmforum.com (Multiprotocol Routing over ATM) af-xsecurity@atmforum.com (Security and ATM) Anyone may subscribe to these lists, and anyone contributing to the discussion in these areas may send email to these addresses. To subscribe to these lists, send an email message to: af-xpnni-request@atmforum.com (For PNNI) af-xmpoa-request@atmforum.com (For MPOA) af-xsecurity-request@atmforum.com (For Security) containing the following command: subscribe Subsequently, you may remove yourself from the mailing list by sending an email message to the same address containing the following command: unsubscribe ATM Forum members who already subscribe to af-pnni, af-mpoa or af-security will automatically receive all mail sent to the corresponding 'x' list as well. ATM Forum members who already subscribe to all ATM Forum lists will also receive all messages sent to any of these 'x' lists. ATM Forum principal member companies have the option of sending to af-pnni, af-mpoa or af-security for distribution to member companies only, or they may send to the corresponding 'x' lists for a wider distribution. Further questions about the ATM Forum or the mailing lists can be directed to: info@atmforum.com Regards, Jim Grace Vice-Chair, ATM Forum Technical Committee ----- End Included Message ----- ----- End Included Message ----- From ipsec-owner@p-o.ans.net Mon Feb 5 13:27:16 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA17363 (5.65c/IDA-1.4.4 for ); Mon, 5 Feb 1996 09:32:09 -0500 Received: by p-o.ans.net id AA38445 (5.65c/IDA-1.4.4 for ipsec-outgoing); Mon, 5 Feb 1996 14:19:27 GMT From: Nick Pope To: ipsec@ans.net Date: Mon, 5 Feb 1996 13:27:16 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: network security products Priority: normal X-Mailer: Pegasus Mail for Windows (v2.10) Message-Id: <823527719.21815.0@secstan.demon.co.uk> Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net I am working on a report on network security products for a UK market research company: Cambridge Market Intelligence (CMI). CMI is a specialist IT market information provider with a long pedigree of service to blue chip companies worldwide. CMI currently has over 800 clients, including 38 of the top 100 companies worldwide Their Enterprise Library currently covers more than more than 50 technologies. The network security report will include information on: firewalls, network encyptors, single sign on authentication, authentication servers, digital signature, key management, security APIs; for a range of network technologies including: dial up, point to point, X.25, ATM, ISDN, TCP/IP, E-mail, World Wide Beb, EDI, Directories. If your company has a product relating to network security and which would be of interest to CMI's clients, could you E-mail me with contact details including E-mail, FAX and postal (snail mail) address to: pope@secstan.demon.co.uk Nick Pope ------------------------------------- Security & Standards Suite A 191 Moulsham St. Chelmsford Essex CM2 0LG U.K. Tel: +44 1245 495018 Fax: +44 1245 494517 From ipsec-owner@p-o.ans.net Mon Feb 5 14:50:35 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA13364 (5.65c/IDA-1.4.4 for ); Mon, 5 Feb 1996 10:05:08 -0500 Received: by p-o.ans.net id AA38822 (5.65c/IDA-1.4.4 for ipsec-outgoing); Mon, 5 Feb 1996 14:55:38 GMT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-photuris-09.txt Date: Mon, 05 Feb 96 09:50:35 -0500 Message-Id: <9602050950.aa01004@IETF.CNRI.Reston.VA.US> Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Photuris Session Key Management Protocol Author(s) : P. Karn, W. Simpson Filename : draft-ietf-ipsec-photuris-09.txt Pages : 69 Date : 02/01/1996 Photuris is an experimental session-key management protocol intended for use with the IP Security Protocols (AH and ESP). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-photuris-09.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-photuris-09.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 (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-photuris-09.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: <19960201114242.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-photuris-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-photuris-09.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960201114242.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-owner@p-o.ans.net Mon Feb 5 05:30:23 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA15741 (5.65c/IDA-1.4.4 for ); Mon, 5 Feb 1996 10:40:54 -0500 Received: by p-o.ans.net id AA13991 (5.65c/IDA-1.4.4 for ipsec-outgoing); Mon, 5 Feb 1996 15:30:27 GMT Date: Mon, 5 Feb 96 10:30:23 EST From: Tassos Nakassis Message-Id: <9602051530.AA08091@snad.ncsl.nist.gov> To: ipsec@ans.net Subject: Re: network security products Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net No relevant information, I am afraid, Nick!! But it is interesting to see that you are alive and, I presume,well; long time no see! Incidentally, I should apologise for all these Christmas cards that you so generously sent me and I so niggardly did not acknowledge. It would be hard to tell from my behavior but I appreciated both the gesture and the thought behind it. Please give my greetings to your wife and let your son know that I am now at the age when I use in soccer the judo techniques that I learned in earlier you youth; against inexperienced players, sometimes, they work. Give me a buzz if y you are ever in town with time to spare. Tassos From ipsec-owner@p-o.ans.net Mon Feb 5 16:39:55 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA17154 (5.65c/IDA-1.4.4 for ); Mon, 5 Feb 1996 11:49:39 -0500 Received: by p-o.ans.net id AA13073 (5.65c/IDA-1.4.4 for ipsec-outgoing); Mon, 5 Feb 1996 16:37:00 GMT Message-Id: <199602051639.LAA28544@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, 05 Feb 1996 13:27:16 GMT." <823527719.21815.0@secstan.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Feb 1996 11:39:55 -0500 From: Michael Richardson Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net In a galaxy far, far away, : Mon, 05 Feb 1996 13:27:16 GMT > I am working on a report on network security products for a UK market > research company: Cambridge Market Intelligence (CMI). IPSEC is not a place to ask these questions. Try firewalls-request@greatcircle.com please. You might start with: http://www.greatcircle.com/firewalls/ From ipsec-owner@p-o.ans.net Mon Feb 5 16:13:11 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14170 (5.65c/IDA-1.4.4 for ); Mon, 5 Feb 1996 12:24:36 -0500 Received: by p-o.ans.net id AA12299 (5.65c/IDA-1.4.4 for ipsec-outgoing); Mon, 5 Feb 1996 17:12:37 GMT X-Sender: rcraig@lint.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 5 Feb 1996 12:13:11 -0400 To: ipsec@ans.net From: rcraig@cisco.com (Robert Craig) Subject: Re: network security products Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Please include Cisco Systems Network Translation Inc.'s Private Internet Exchange. Robert. From ipsec-owner@p-o.ans.net Mon Feb 5 18:39:53 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA18160 (5.65c/IDA-1.4.4 for ); Mon, 5 Feb 1996 13:45:25 -0500 Received: by p-o.ans.net id AA12292 (5.65c/IDA-1.4.4 for ipsec-outgoing); Mon, 5 Feb 1996 18:36:56 GMT Message-Id: <199602051839.NAA29920@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, 05 Feb 1996 10:30:23 EST." <9602051530.AA08091@snad.ncsl.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Feb 1996 13:39:53 -0500 From: Michael Richardson Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net In a galaxy far, far away, : Mon, 05 Feb 1996 10:30:23 EST > No relevant information, I am afraid, Nick!! Please don't post this to ipsec. Just take it to private email if you have complaints. From ipsec-owner@p-o.ans.net Mon Feb 5 17:40:52 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA12789 (5.65c/IDA-1.4.4 for ); Mon, 5 Feb 1996 13:46:12 -0500 Received: by p-o.ans.net id AA16923 (5.65c/IDA-1.4.4 for ipsec-outgoing); Mon, 5 Feb 1996 18:40:16 GMT X-Sender: rcraig@lint.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 5 Feb 1996 13:40:52 -0400 To: ipsec@ans.net From: rcraig@cisco.com (Robert Craig) Subject: Re: network security products Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Sorry about that, wasn't paying attention to the reply to field. Robert. From ipsec-owner@p-o.ans.net Mon Feb 5 19:34:57 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA18565 (5.65c/IDA-1.4.4 for ); Mon, 5 Feb 1996 14:39:03 -0500 Received: by p-o.ans.net id AA22599 (5.65c/IDA-1.4.4 for ipsec-outgoing); Mon, 5 Feb 1996 19:31:10 GMT Message-Id: <199602051934.OAA00377@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` <199602051639.LAA28544@milkyway.com> In-Reply-To: Your message of "Mon, 05 Feb 1996 11:39:55 EST." <199602051639.LAA28544@milkyway.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Feb 1996 14:34:57 -0500 From: Michael Richardson Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net In a galaxy far, far away, : Mon, 05 Feb 1996 11:39:55 EST > IPSEC is not a place to ask these questions. Try > firewalls-request@greatcircle.com please. You might start with: Dang. I replied to the list. Exactly what I hate people doing. Here is some genuine content to go with my appology. I think this topic came up (I know I asked the question once), but seems to have died. The issue was how do deal with a possibly unknown number of gateways between a sender and recipient. The simplest case is a single security gateway with a host behind it. I think the opinion was that IP-AH-IP-AH was the way to do this. This works fine for some finite number of gateways and when the packet will go via the same route each time. It gets to be a pain when the number of gateways gets more than a couple. The gateways could use ICMP "Authentication Required" to get more and more AH headers added.. If one is talking about bandwidth reservation then one wants the packets examined at several places. One could share (via photoris or other) the secret keying information with all these gateways. I dislike this. I don't think Photuris can handle this at present. Or, one could use a public key based digital signature. I worry that checking this signature may take so long that the bandwidth reservation becomes moot due to latency... I know that the bandwidth reservation people (RSVP) are working on something to address this. From my reading, there doesn't seem to be a lot of protection against other people stealing your expensive bandwidth, although draft-ietf-rsvp-md5-01.txt provides protection for the RSVP protocol messages themselves. The biggest reason I can see for widespread use of RSVP type services is that if they are simple a cheap, then we can work around a large number of the denial of service attacks that "ping -f victim" can cause. From ipsec-owner@p-o.ans.net Mon Feb 5 20:47:36 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14198 (5.65c/IDA-1.4.4 for ); Mon, 5 Feb 1996 15:54:10 -0500 Received: by p-o.ans.net id AA12477 (5.65c/IDA-1.4.4 for ipsec-outgoing); Mon, 5 Feb 1996 20:44:47 GMT Message-Id: <9602052042.AA25872@mailserv-F.ftp.com> X-Sender: johara@mailserv-f.ftp.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 05 Feb 1996 15:47:36 -0500 To: ipsec@ans.net From: johara@ftp.com (John T. O'Hara) Subject: Re: network security products Cc: ngoldman@ftp.com X-Mailer: Content-Length: 1485 Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net contact neal goldman product line manager FTP software, inc 2 high st N. Andover, Ma 01845 ngoldman@ftp.com 508 685 4000 He can outline details of our security products which include secure TCP/IP stack secure email secure web ... et al >I am working on a report on network security products for a UK market >research company: Cambridge Market Intelligence (CMI). > >CMI is a specialist IT market information provider with a long >pedigree of service to blue chip companies worldwide. CMI currently >has over 800 clients, including 38 of the top 100 companies worldwide >Their Enterprise Library currently covers more than more than 50 >technologies. > >The network security report will include information on: >firewalls, network encyptors, single sign on authentication, >authentication servers, digital signature, key management, security >APIs; >for a range of network technologies including: dial up, point to point, >X.25, ATM, ISDN, TCP/IP, E-mail, World Wide Beb, EDI, Directories. > >If your company has a product relating to network security and which >would be of interest to CMI's clients, could you E-mail me with contact >details including E-mail, FAX and postal (snail mail) address to: > > pope@secstan.demon.co.uk > > >Nick Pope > >------------------------------------- > > >Security & Standards >Suite A >191 Moulsham St. >Chelmsford >Essex >CM2 0LG >U.K. > >Tel: +44 1245 495018 >Fax: +44 1245 494517 > > From ipsec-owner@p-o.ans.net Mon Feb 5 21:16:44 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14304 (5.65c/IDA-1.4.4 for ); Mon, 5 Feb 1996 16:16:16 -0500 Received: by p-o.ans.net id AA44647 (5.65c/IDA-1.4.4 for ipsec-outgoing); Mon, 5 Feb 1996 21:08:00 GMT Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 5 Feb 1996 16:16:44 -0500 To: ipsec@ans.net From: hughes@hughes.network.com (James P. Hughes) Subject: Re: network security products Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net NSC has encrypting filrewalls at the IP level (with support for X.25, ATM, ISDN) and all applications (TCP/IP, E-mail, World Wide Beb, EDI, Directories). Please check our home page http://www.network.com for more information. If there is more information needed please ask. The encrypting firewall routers ("The Security Routers" and "BorderGuard") are available today and have been shipping to US and international customers for over a year. The Security Router won "Best of Show" in the Spring 1995 Interop Show. >I am working on a report on network security products for a UK market >research company: Cambridge Market Intelligence (CMI). > >CMI is a specialist IT market information provider with a long >pedigree of service to blue chip companies worldwide. CMI currently >has over 800 clients, including 38 of the top 100 companies worldwide >Their Enterprise Library currently covers more than more than 50 >technologies. > >The network security report will include information on: >firewalls, network encyptors, single sign on authentication, >authentication servers, digital signature, key management, security >APIs; >for a range of network technologies including: dial up, point to point, >X.25, ATM, ISDN, TCP/IP, E-mail, World Wide Beb, EDI, Directories. > >If your company has a product relating to network security and which >would be of interest to CMI's clients, could you E-mail me with contact >details including E-mail, FAX and postal (snail mail) address to: > > pope@secstan.demon.co.uk > > >Nick Pope > >------------------------------------- > > >Security & Standards >Suite A >191 Moulsham St. >Chelmsford >Essex >CM2 0LG >U.K. > >Tel: +44 1245 495018 >Fax: +44 1245 494517 -------------- HTTP://WWW.Network.com/~hughes From ipsec-owner@p-o.ans.net Mon Feb 5 12:13:53 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA15733 (5.65c/IDA-1.4.4 for ); Mon, 5 Feb 1996 17:21:31 -0500 Received: by p-o.ans.net id AA21724 (5.65c/IDA-1.4.4 for ipsec-outgoing); Mon, 5 Feb 1996 22:13:56 GMT Date: Mon, 5 Feb 96 17:13:53 EST From: Tassos Nakassis Message-Id: <9602052213.AA14292@snad.ncsl.nist.gov> To: ipsec@ans.net Subject: Re: network security products Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net My excuses; I must have hit R instead of r. Else, I have some e-mail problem I am unaware of. Again, I am truly sorry. Tassos Nakassis From ipsec-owner@p-o.ans.net Mon Feb 5 09:37:00 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA18591 (5.65c/IDA-1.4.4 for ); Mon, 5 Feb 1996 17:52:01 -0500 Received: by p-o.ans.net id AA30819 (5.65c/IDA-1.4.4 for ipsec-outgoing); Mon, 5 Feb 1996 22:41:05 GMT From: Hapeman Dale To: IPSEC Subject: RE: network security products Date: Mon, 05 Feb 96 17:37:00 PST Message-Id: <3116B1D1@smtpj.bah.com> Encoding: 56 TEXT X-Mailer: Microsoft Mail V3.0 Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Mr. Pope, Since you are using a mail list dedicated to advancing the state of network security, I assume that your efforts are in the best interest of the community at large and that you will make the results of your study available to the public. Looking forward to a pointer to a FTP or Web site, Dale ---------- >From: ipsec-owner >To: ipsec >Subject: network security products >Date: Monday, February 05, 1996 1:27PM > >I am working on a report on network security products for a UK market >research company: Cambridge Market Intelligence (CMI). > >CMI is a specialist IT market information provider with a long >pedigree of service to blue chip companies worldwide. CMI currently >has over 800 clients, including 38 of the top 100 companies worldwide >Their Enterprise Library currently covers more than more than 50 >technologies. > >The network security report will include information on: >firewalls, network encyptors, single sign on authentication, >authentication servers, digital signature, key management, security >APIs; >for a range of network technologies including: dial up, point to point, >X.25, ATM, ISDN, TCP/IP, E-mail, World Wide Beb, EDI, Directories. > >If your company has a product relating to network security and which >would be of interest to CMI's clients, could you E-mail me with contact >details including E-mail, FAX and postal (snail mail) address to: > > pope@secstan.demon.co.uk > > >Nick Pope > >------------------------------------- > > >Security & Standards >Suite A >191 Moulsham St. >Chelmsford >Essex >CM2 0LG >U.K. > >Tel: +44 1245 495018 >Fax: +44 1245 494517 > From ipsec-owner@p-o.ans.net Tue Feb 6 00:15:51 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14695 (5.65c/IDA-1.4.4 for ); Mon, 5 Feb 1996 19:28:53 -0500 Received: by p-o.ans.net id AA44651 (5.65c/IDA-1.4.4 for ipsec-outgoing); Tue, 6 Feb 1996 00:19:44 GMT Date: Mon, 5 Feb 1996 16:15:51 -0800 From: Ran Atkinson Message-Id: <199602060015.QAA23655@puli.cisco.com> To: pope@secstan.demon.co.uk Subject: Re: network security products In-Reply-To: <823527719.21815.0@secstan.demon.co.uk> Organization: Internet Engineering Task Force Cc: ipsec@ans.net Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Nick Pope, Your note was not an appropriate use of the IETF's IP Security (IPsec) Working Group Mailing list. Please do NOT repeat that kind of note to the ipsec mailing list. Randall Atkinson rja@cisco.com Co-chair, IP Security WG From ipsec-owner@p-o.ans.net Tue Feb 6 07:49:31 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA16595 (5.65c/IDA-1.4.4 for ); Tue, 6 Feb 1996 03:00:51 -0500 Received: by p-o.ans.net id AA03713 (5.65c/IDA-1.4.4 for ipsec-outgoing); Tue, 6 Feb 1996 07:49:45 GMT From: David A Wagner Message-Id: <199602060749.XAA13045@dawn9.CS.Berkeley.EDU> Subject: Re: Bandwidth reservation and AH, and non-MD5 based AH. To: ipsec@ans.net Date: Mon, 5 Feb 1996 23:49:31 -0800 (PST) Cc: mcr@milkyway.com In-Reply-To: <199602051934.OAA00377@milkyway.com> from "Michael Richardson" at Feb 5, 96 02:34:57 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1233 Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net > If one is talking about bandwidth reservation then one wants the packets > examined at several places. One could share (via photoris or other) the secret > keying information with all these gateways. I dislike this. Hrmm, why? If AH with a symmetrically-keyed MAC is used just for protecting reserved bandwidth (not for secure end-to-end source authentication or message integrity), then it doesn't seem like such a big deal to have to trust a few routers to hold your bandwidth session-key. (After all, you have to trust them to actually give you the bandwidth which they've promised to reserve for you.) I'd expect that you'll exchange short-lived session MAC keys based on some public-key algorithm anyhow, so that oughta decrease the risk even further. But then again, I know nothing about bandwidth reservation. > Or, one could use a public key based digital signature. I worry that checking > this signature may take so long that the bandwidth reservation becomes moot > due to latency... Yeah, that's a problem with public-key stuff: it's so slow. Do note that signature verification is much faster than signature generation when you use RSA with a small public exponent, though it is admittedly still quite slow. From ipsec-owner@p-o.ans.net Tue Feb 6 15:18:34 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA17592 (5.65c/IDA-1.4.4 for ); Tue, 6 Feb 1996 10:35:40 -0500 Received: by p-o.ans.net id AA21290 (5.65c/IDA-1.4.4 for ipsec-outgoing); Tue, 6 Feb 1996 15:18:47 GMT Date: Tue, 6 Feb 1996 10:18:34 -0500 From: JVallese@aol.com Message-Id: <960206101831_314090663@emout07.mail.aol.com> To: Internet-Drafts@cnri.reston.va.us, IETF-Announce@aol.com Cc: ipsec@ans.net Subject: Re: I-D ACTION:draft-ietf-ipsec-photuris-09.txt Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Please stop sending me so much mail. This really getting rediculous. I am greatfull that you replied to me but I only need info reguarding fraud or computer hacking. If there is a way for you to just send me information on the above topics it would be greatlly appreciated. Thank you Jeffrey G. Vallese From ipsec-owner@p-o.ans.net Tue Feb 6 21:24:53 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA18509 (5.65c/IDA-1.4.4 for ); Tue, 6 Feb 1996 17:30:18 -0500 Received: by p-o.ans.net id AA19905 (5.65c/IDA-1.4.4 for ipsec-outgoing); Tue, 6 Feb 1996 21:40:20 GMT Date: Tue, 6 Feb 96 21:24:53 GMT From: "William Allen Simpson" Message-Id: <4783.bsimpson@morningstar.com> To: ipsec@ans.net Subject: Re: I-D ACTION:draft-ietf-ipsec-photuris-09.txt Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Gentlefolk, I believe this draft to be relatively stable, and to include the features and editorial comments requested in the past 2 months. The only significant changes are the new support for passing the moduli from Responder to Initiator, and adding attributes to more clearly detail the AH ESP ordering for each security association. Note that the scenarios and security considerations have been moved to separate drafts, and that other folks are (hopefully) posting a user-keying draft. The nroff difference engine was confused by the massive deletions, so there are no change bars in this draft. Please read every word carefully, and send me your comments. I request that the WG Chair(s) issue Last Call, as was done for SKIP. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-owner@p-o.ans.net Tue Feb 6 17:26:23 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA18121 (5.65c/IDA-1.4.4 for ); Tue, 6 Feb 1996 18:25:45 -0500 Received: by p-o.ans.net id AA27172 (5.65c/IDA-1.4.4 for ipsec-outgoing); Tue, 6 Feb 1996 23:13:53 GMT To: JVallese@aol.com Cc: Cynthia Clark , ipsec@ans.net Subject: RE: Re: I-D ACTION:draft-ietf-ipsec-photuris-09.txt Date: Tue, 06 Feb 96 12:26:23 -0500 From: Cynthia Clark Message-Id: <9602061226.aa16116@IETF.CNRI.Reston.VA.US> Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Hi Jeffrey, Per your request, your email address has been removed from the IETF Announcement mailing list. Because of the mail queue, this might take awhile. Kind Regards, Cynthia Clark ------- Forwarded Message Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13571; 6 Feb 96 10:18 EST Received: from emout07.mx.aol.com by CNRI.Reston.VA.US id aa07809; 6 Feb 96 10:18 EST Received: by emout07.mail.aol.com (8.6.12/8.6.12) id KAA29034; Tue, 6 Feb 1996 10:18:34 -0500 Date: Tue, 6 Feb 1996 10:18:34 -0500 From: JVallese@aol.com Message-ID: <960206101831_314090663@emout07.mail.aol.com> To: Internet-Drafts@CNRI.Reston.VA.US, IETF-Announce@aol.com cc: ipsec@ans.net Subject: Re: I-D ACTION:draft-ietf-ipsec-photuris-09.txt Please stop sending me so much mail. This really getting rediculous. I am greatfull that you replied to me but I only need info reguarding fraud or computer hacking. If there is a way for you to just send me information on the above topics it would be greatlly appreciated. Thank you Jeffrey G. Vallese ------- End of Forwarded Message From ipsec-owner@p-o.ans.net Tue Feb 6 14:06:43 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA15678 (5.65c/IDA-1.4.4 for ); Tue, 6 Feb 1996 19:16:36 -0500 Received: by p-o.ans.net id AA30799 (5.65c/IDA-1.4.4 for ipsec-outgoing); Wed, 7 Feb 1996 00:07:07 GMT Message-Id: <199602070007.AA21119@interlock.ans.net> Date: Tue, 6 Feb 96 19:06:43 EST From: hugo@watson.ibm.com To: IPSEC@ans.net Subject: paper on the new keyed MD5 (HMAC) Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net The paper describing the security analysis behind the proposal in draft-krawczyk-keyed-md5-01.txt (that I also described during the Dallas IETF) is available. You can retrieve it from http://www.research.ibm.com/security/keyed-md5.html or from http://www-cse.ucsd.edu/users/mihir/papers/papers.html The title of the paper is: "Keying hash functions for message authentication" by Bellare, Canetti, and Krawczyk. Notice that the construction proposed to the IETF is called HMAC in the paper. Hugo From ipsec-owner@p-o.ans.net Wed Feb 7 14:36:36 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA18547 (5.65c/IDA-1.4.4 for ); Wed, 7 Feb 1996 10:07:56 -0500 Received: by p-o.ans.net id AA19947 (5.65c/IDA-1.4.4 for ipsec-outgoing); Wed, 7 Feb 1996 14:36:42 GMT Date: Wed, 7 Feb 1996 09:36:36 -0500 X-Sender: rshirey@rosslyn.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipsec@ans.net From: "Robert W. Shirey" Subject: Re: I-D ACTION:draft-ietf-ipsec-photuris-09.txt Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net >Please stop sending me so much mail. This really getting rediculous. I am >greatfull that you replied to me but I only need info reguarding fraud or >computer hacking. If there is a way for you to just send me information on >the above topics it would be greatlly appreciated. >Thank you >Jeffrey G. Vallese Mr. Vallese, 1. Since you obviously don't know the purpose of the list to which you have subscribed, how it is operated, or the sheer number of people on it, you should get off. 2. Since you obviously don't know how to restrict your replies so that thousands of other people don't receive your personal business, you should learn. For that purpose, please consider: When you want to be added to or removed from a mailing list "foo" at host "bar", the proper form of address is to "foo-request@bar". The "-request" suffix is a widely supported Internet convention for communicating with the list administrator. That way, everyone on the list does not get a copy of personal "administrivia". Regards, -Rob- RShirey@BBN.com, Tel 703-284-4641, Sec 284-4600, Fax 284-4777 Robert W. Shirey, BBN Corporation, Mail Stop 30/4C, Suite 1200, 1300 North Seventeenth Street, Arlington, Virginia 22209-3801 USA From ipsec-owner@p-o.ans.net Fri Feb 9 11:18:33 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA16602 (5.65c/IDA-1.4.4 for ); Fri, 9 Feb 1996 06:33:26 -0500 Received: by p-o.ans.net id AA04670 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 9 Feb 1996 11:17:52 GMT Date: Fri, 9 Feb 1996 03:18:33 -0800 From: markson@osmosys.incog.com (Tom Markson) Message-Id: <9602091118.AA19134@monster.incog.com> To: ipsec@ans.net Subject: SKIP Alpha-2 Source release Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Hi, We've just released the Alpha-2 SKIP reference source for SunOS 4.1.3. This is a bug fix release of our Alpha-1 Source reference Source. The source is available from http://skip.incog.com. Included in this mail message are excerpts from the README file for the the package. Enjoy! Tom Markson Sun Microsystems ------------------------------------------------------------------------- ALPHA 2 Release of SKIP Reference Source for SunOS 4.1.3 -------------------------------------------------------- Overview and Release Notes Overview -------- SKIP is a Key-management protocol for IP based protocols. It is an acronym for Simple Key-management for Internet Protocols. SKIP is documented in the SKIP IETF IPSEC draft included in this directory as draft-ietf-ipsec-skip-06.txt. The most recent SKIP draft is always available at http://skip.incog.com and the Internet-Drafts directories. >From this public domain source release, you can build a fully functional IP-layer encryption package which supports DES and Triple-DES for SunOS 4.1.3. This means that every IP networked application can have it's network traffic encrypted. Unlike application level encryption packages, this package encrypts IP packets. Thus, applications do not need to be recompiled or modified to take advantage of encryption. The SKIP source is possible through the efforts of engineers in Sun Microsystems Internet Commerce Group. The developers and designers are Ashar Aziz, Tom Markson, Martin Patterson, Hemma Prafullchandra and Joseph Reveane. Linda Cavanaugh worked on the documentation. The package compiles under both the SunPro compiler and GCC. We expect that this release should port without too much pain to any operating system which uses BSD style networking (mbufs). A legal warning: Because this package contains strong encryption, the Software must not be transferred to persons who are not US citizens or permanent residents of the US, or exported outside the US (except Canada) in any form (including by electronic transmission) without prior written approval from the US Government. Non-compliance with these restrictions constitutes a violation of the U.S. Export Control Laws. This source release may be used for both commercial and noncommercial purposes, subject to the restrictions described in the software and patent license statements. Furthermore, Sun Microsystems has licensed the Stanford public key patents from Cylink Corp. which are available to users of this package on a royalty free basis. The patent statement is in README.PATENT. Be sure to read this, as it contains some restrictions and other important information. Also included in this release is a high speed Big Number package written by Colin Plumb. bnlib/legal.c contains Colin's software license statement. Features -------- 1. SKIP V2 compliant implementation using ESP encapsulation. 2. Support for DES/3DES for traffic and key encryption. 3. Diffie-Hellman Public Key Agreement based system. 4. Full Support for manual establishment of master keys. 5. Support for multiple NSIDs and multiple local certificates. 6. GUI tool for user friendly manipulation of access control lists and key statistics. 7. Command line tools for manipulating access control lists, etc. 8. Implementation of the Certificate Discovery protocol fully integrated into SKIP. 9 Implementation of X.509 public key certificates. 10. Implementation of DSA signature algorithm for certificate signatures. 11. Implementation for MD2, MD5 and SHA message digest algorithms. 12. Implementation of ASN.1 DER encoding/decoding. 13. SunScreen(tm) SKIP compatibility mode. 14. Implementation of hashed public keys as defined in the SKIP draft. Implementation of programs to generate hashed public keys. 15. Certificate utilities to convert X.509 Certificates to hashed keys and print both X.509 and Hashed certificates. 16. High performance Big Number library for Diffie-Hellman calculations. 17. Implementation is effectively "public domain" and may be used both commercially and non-commercially. 18. Patent Agreement with Cylink allows roylaty-free use of the Diffie-Hellman and other Stanford patents with this package for commercial and non-commercial use. Read README.PATENT for some restrictions. 19. Inclusion of prime generation program used to generate the primes in SKIP draft. Release Notes ------------- Here are the release notes for this Alpha 2 release of the SKIP source. 1. This release is a bug fix release for Alpha-1. Major areas of change include: o Fix ESP and AH protocol numbers. o Fix Unsigned DH Public encoding. o Remove truncatation of shared secret (for this release only). o Various other Bug fixes. o Fix Triple DES. 2. This release does not interoperate with Alpha-1. Alpha-1 sites should upgrade. Alpha-1 had a bug where unsigned public keys were being encoded incorrectly. Therefore, unsigned DH keys generated with alpha-1 do not work with Alpha-2. Regenerate your unsigned public keys. X509 Certificates from alpha-1 will continue to work. 3. This release interoperates with Swiss ETH SKIP using unsigned DH keys and DES and triple DES. It was tested at the Dallas 1995 IETF. However, the certificate discovery protocol does not interoperate. This will be fixed in the next release. 4. This release does not fully comply with the SKIP drafts. It is closest to the 05 version of the draft. However, the shared secret is not truncated according to that draft. This change is made to interoperate with the ETH implementation. The next release will correspond to the 06 draft. .... From ipsec-owner@p-o.ans.net Fri Feb 9 14:29:52 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA17256 (5.65c/IDA-1.4.4 for ); Fri, 9 Feb 1996 09:38:44 -0500 Received: by p-o.ans.net id AA14576 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 9 Feb 1996 14:30:19 GMT Organization: ESAT, K.U.Leuven, Belgium Date: Fri, 9 Feb 1996 15:29:52 +0100 From: Bart.Preneel@esat.kuleuven.ac.be Message-Id: <9602091429.AA21279@yourcenar.esat.kuleuven.ac.be> To: ipsec@ans.net Subject: keyed MD5 - papers and software Cc: preneel@esat.kuleuven.ac.be X-Charset: ISO_8859-1 X-Char-Esc: 29 Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Below is a status update on some results regarding keyed MD5 proposals. In July of last year there was much discussion about the security of various proposals. A summary of attacks on the secret prefix, secret suffix, and various envelope methods may be found in the Crypto'95 paper by B. Preneel and P. van Oorschot, `MDx-MAC and Building Fast MACs from Hash Functions', pp.1-14, available at: ftp.esat.kuleuven.ac.be pub/COSIC/preneel mdxmac_crypto95.ps This paper also proposed the MD5-based MAC algorithm called MD5-MAC. A reference C implementation (including test values and some timings) of MD5-MAC has been posted at ftp.esat.kuleuven.ac.be pub/COSIC/preneel/md5mac files: README key.dat md5mac.res mddrive2.c global.h md5mac.h md5macc.c speed.res At the Crypto'95 rump session, a key recovery attack on the envelope method of RFC 1828 was announced. This result is contained in our paper to be presented at Eurocrypt'96 in May, ``On the security of two MAC algorithms'', a draft version of which is available at ftp.esat.kuleuven.ac.be pub/COSIC/preneel twomacs.ps Bart Preneel bart.preneel@esat.kuleuven.ac.be From ipsec-owner@p-o.ans.net Mon Feb 12 14:39:06 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14269 (5.65c/IDA-1.4.4 for ); Mon, 12 Feb 1996 09:54:37 -0500 Received: by p-o.ans.net id AA12334 (5.65c/IDA-1.4.4 for ipsec-outgoing); Mon, 12 Feb 1996 14:42:46 GMT Date: Mon, 12 Feb 1996 09:39:06 -0500 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199602121439.JAA02761@argon.ncsc.mil> To: ietf-radius@livingston.com, d_nelson@irocz.lkg.dec.com Subject: Re: (radius) FWD: (mobile-ip) MD5 Key recovery attack Cc: ipsec@ans.net X-Sun-Charset: US-ASCII Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net There are (at least :-) two directions in which to look for solutions: 1) Internet Draft "draft-krawczyk-keyed-md5-01.txt" presents an analysis of the use of hash functions as Message Authenticators. It suggests using the construct: Hash(Key, Pad2, Hash(Key, Pad1, Text)) in lieu of other structures such as Hash(Key, Text, Key). The Krawczyk MAC relies on significantly fewer assumptions about the properties of the hash algorithm than do other methods (which were apparently concocted without much in the way of security analysis). 2) The Secure Hash Algorithm (SHA) (ftp://csrc.ncsl.nist.gov/pub/fips/ fip180-1.txt) produces a 160 bit hash value as opposed to MD5's 128 bit value. I am not aware of an analysis of the inherent strengths of the two algorithms, but assuming they are equivalent, SHA's additional 32 bits would increase the work factor of the attack by 2**32. It would be interesting to know if in fact the attack referenced below is effective at all against SHA. Netscape's SSL Version 3 (ftp://ftp.netscape.com/pub/review/ssl-spec.tar.Z) has adopted the Krawczyk MAC using both MD5 and SHA. Also, a very influential vendor consortium recently switched from using MD5 to SHA because, despite the increased size of its hash value, SHA is computationally faster than MD5. Food for thought. Regards, Dave Kemp ================================== > I am forwarding this memo from the mobile-ip IETF mailing list, as it > addresses MD5 used to hide keys (passwords). I haven't been following > this thread on the mobile-ip list, but thought it may be of some interest > to us. > > Regards, > > Dave Nelson > Internetworking Products Engineering Group > Digital Equipment Corporation > > -------------------------------------------------------------------------- > > It seems that MD5 isn't as secure as we thought. > I'd suggest we shop around for a fix to this problem > before finishing Working Group last call. The algorithm > we are using to compute authenticators is (apparently) > called an MD5-envelope algorithm. I'm not a security > weenie, but here's my distillation of the article. > > 1) MD5 was not designed to hide keys. > > 2) It's possible to choose plaintexts and trial keys > in such a way to dramatically reduce the amount of > time needed to recover a key, to about 2**64 > keyed operations on 2**13 plaintexts in some cases. > Were we expecting 2**128 key trials to be needed? > > 3) If keys are chosen poorly, even fewer trials are > needed to find the key. > > The danger could be that, even if 2**64 is still good > enough for our purposes (is it??), that this result > will point the way towards another drastic reduction > in the security of MD5(key||text||key). > > Does anyone know if "suffix-only" mode is more secure > than the "envelope" or "prefix+suffix" mode that we > have specified in the mobile-IP draft? > > Regards, > Charlie Perkins From ipsec-owner@p-o.ans.net Mon Feb 12 04:01:10 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA16549 (5.65c/IDA-1.4.4 for ); Mon, 12 Feb 1996 11:39:26 -0500 Received: by p-o.ans.net id AA19887 (5.65c/IDA-1.4.4 for ipsec-outgoing); Mon, 12 Feb 1996 16:31:18 GMT Date: Mon, 12 Feb 96 10:01:10 CST From: "Pat Calhoun" Message-Id: <9601128241.AA824149688@robogate.usr.com> To: ietf-radius@livingston.com, d_nelson@irocz.lkg.dec.com, dpkemp@missi.ncsc.mil (David P. Kemp) Cc: ipsec@ans.net Subject: Re[2]: (radius) FWD: (mobile-ip) MD5 Key recovery attack Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net >There are (at least :-) two directions in which to look for solutions: >1) Internet Draft "draft-krawczyk-keyed-md5-01.txt" presents an >analysis of the use of hash functions as Message Authenticators. >It suggests using the construct: >Hash(Key, Pad2, Hash(Key, Pad1, Text)) >... >2) The Secure Hash Algorithm (SHA) (ftp://csrc.ncsl.nist.gov/pub/fips/ >fip180-1.txt) produces a 160 bit hash value as opposed to MD5's 128 >bit value. I am not aware of an analysis of the inherent strengths >of the two algorithms, but assuming they are equivalent, SHA's >additional 32 bits would increase the work factor of the attack by >2**32. It would be interesting to know if in fact the attack >referenced below is effective at all against SHA. At the expense of being a pain about my extensions proposal, the extended authentication mechanism allows for alternate encryption schemes. There exists a flag in the message header which is used for this. You will notice that I have only defined the current MD5 method, but there are plenty of bits left which may be used in order to indicate the encoding scheme. I would certainly be interested in talking about any "new" encoding schemes and add these to my proposals. The only lacking piece is that both peers should negotiate an encoding scheme BEFORE authentication begins. This should be done in the NAS-Reboot message, where certain other negotiations exists. Pat R. Calhoun e-mail: pcalhoun@usr.com Project Engineer - Lan Access R&D phone: (847) 933-5181 US Robotics Access Corp. From ipsec-owner@p-o.ans.net Mon Feb 12 22:47:32 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14264 (5.65c/IDA-1.4.4 for ); Mon, 12 Feb 1996 17:52:59 -0500 Received: by p-o.ans.net id AA41178 (5.65c/IDA-1.4.4 for ipsec-outgoing); Mon, 12 Feb 1996 22:47:38 GMT Date: Mon, 12 Feb 1996 14:47:32 -0800 From: Ran Atkinson Message-Id: <199602122247.OAA02865@puli.cisco.com> To: ipsec@ans.net Subject: ADMIN: Straw Poll Results on Key Mgmt Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net % Date: Thu, 4 Jan 1996 10:44:11 -0800 % From: Ran Atkinson % % 1) Can the IPsec WG produce multiple standards-track % protocols for key management ? The consensus is that multiple standards-track protocols can be produced by the working group provided that there are significant differences in applicability among the protocols. The most common example that was mentioned was that multicast key distribution will probably need to be a separate protocol than unicast key distribution. % 2) If yes to the above, then can a protocol not conforming % to the WG requirements for a key management protocol % be on the IETF standards-track ? The consensus is NO. All standards-track protocols MUST conform with the IPsec WG requirements. As of now there are 2 main agreed-upon requirements: (1) Perfect Forward Secrecy (PFS) must be available to users of the protocol that desire PFS. This means that a conforming protocol might have a mode that provides PFS and another mode that doesn't, for example. (2) The key management protocol must be able to negotiate/ indicate the value of each of the components of an IPsec Security Association (RFC-1825) with/to all of the parties to that IPsec Security Association. Users are not necessarily required to use all of those components, but the protocol MUST be capable of providing that support and conforming implementations of the protocol MUST support negotiation/indication of all of those components. % 3) If yes to both of the above, should the WG chairs write up a formal % applicability statement to be accompany each standards-track % key management protocol so that the intended use of that protocol % is made clear? There is overwhelming (possibly unanimous) consensus that the WG chairs should be required to write up a formal applicability statement to accompany each standards-track key management protocol so that the intended use of that protocol is made clear in an RFC. Hence, the co-chairs will do this if/when some protocol moves to standards-track RFC. CONCLUSIONS: (1) None of the proposals currently online appear to fully meet all of the requirements, though it does appear that all of them could be modified to meet all of the requirements. (2) None of the current proposals can go to Last Call at this time because of (1). (3) All of the editors of the current documents should work on refining their proposals to fully meet all of the WG requirements. The co-chairs look forward to seeing revised proposals in LA. In a situation like this one where the WG consensus is clear, the WG chairs do not have any real discretion on handling matters. We are forbidden by IETF standards process from doing anything contrary to WG consensus, so our hands are completely tied on holding a Last Call at this time. Paul Lambert Randall Atkinson From ipsec-owner@p-o.ans.net Tue Feb 13 15:09:46 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA12552 (5.65c/IDA-1.4.4 for ); Tue, 13 Feb 1996 10:44:03 -0500 Received: by p-o.ans.net id AA27205 (5.65c/IDA-1.4.4 for ipsec-outgoing); Tue, 13 Feb 1996 15:36:43 GMT Date: Tue, 13 Feb 96 15:09:46 GMT From: "William Allen Simpson" Message-Id: <4825.bsimpson@morningstar.com> To: ipsec@ans.net Subject: Re: ADMIN: Straw Poll Results on Key Mgmt Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net > From: Ran Atkinson > The consensus is NO. All standards-track protocols MUST conform with > the IPsec WG requirements. As of now there are 2 main agreed-upon > requirements: > (1) Perfect Forward Secrecy (PFS) must be available to users of > the protocol that desire PFS. This means that a conforming > protocol might have a mode that provides PFS and another mode > that doesn't, for example. > I remember this one. > (2) The key management protocol must be able to negotiate/ > indicate the value of each of the components of an IPsec > Security Association (RFC-1825) with/to all of the parties to > that IPsec Security Association. Users are not necessarily > required to use all of those components, but the protocol MUST > be capable of providing that support and conforming implementations > of the protocol MUST support negotiation/indication of > all of those components. > I don't remember this one, and in fact, don't understand it. Each of what components? Where did this requirement arise? I have examined RFC-1825, and find the use of the word "component" exactly once: 2. DESIGN OBJECTIVES This section describes some of the design objectives of this security architecture and its component mechanisms. So, let us assume that the "components" are actually "mechanisms". The next chapter of RFC-1825 specifies "mechanisms": 3. IP-LAYER SECURITY MECHANISMS There are two cryptographic security mechanisms for IP. The first is the Authentication Header which provides integrity and authentication without confidentiality [Atk95a]. The second is the Encapsulating Security Payload which always provides confidentiality, and (depending on algorithm and mode) might also provide integrity and authentication [Atk95b]. The two IP security mechanisms may be used together or separately. Thus, the "component mechanisms" are AH and ESP. > % 3) If yes to both of the above, should the WG chairs write up a formal > % applicability statement to be accompany each standards-track > % key management protocol so that the intended use of that protocol > % is made clear? > > There is overwhelming (possibly unanimous) consensus that the WG chairs > should be required to write up a formal applicability statement to accompany > each standards-track key management protocol so that the intended use of > that protocol is made clear in an RFC. Hence, the co-chairs will do this > if/when some protocol moves to standards-track RFC. > It couldn't have been unanimous, since I opposed it. Any Applicability Statements belong in the documents themselves, as has long been the IETF practice. Photuris contains an Applicability Statement. > CONCLUSIONS: > (1) None of the proposals currently online appear to fully meet all > of the requirements, though it does appear that all of them could > be modified to meet all of the requirements. Well, since I don't know what you are talking about, perhaps you could indicate exactly where Photuris doesn't meet some such requirement? Are you saying that Photuris doesn't provide support for PFS, and/or doesn't support AH and ESP? You _have_ read the drafts, haven't you? I call for the rest of the WG to bombard the chairs with their support for Photuris. If it is found in the next few days to be lacking such public WG support, I will instead publish immediately as Experimental, pursuant to RFC-1602. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-owner@p-o.ans.net Tue Feb 13 17:46:14 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA15617 (5.65c/IDA-1.4.4 for ); Tue, 13 Feb 1996 12:49:03 -0500 Received: by p-o.ans.net id AA19955 (5.65c/IDA-1.4.4 for ipsec-outgoing); Tue, 13 Feb 1996 17:46:25 GMT Date: Tue, 13 Feb 1996 09:46:14 -0800 From: Ran Atkinson Message-Id: <199602131746.JAA04324@puli.cisco.com> To: ipsec@ans.net Subject: [ADMIN] mailing list changes coming soon Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net All, TIS has kindly agreed to become the new home for the IPsec mailing list. This transition should occur during the next few weeks. The list will be handled by MajorDomo once it is transitioned to TIS, so response to subscription changes should be a bit faster. It will continue to be automatically archived with the archives available via anonymous ftp. Jim Galvin has been kind enough to handle this for us. He'll be posting more detailed information on the transition as it occurs. I really appreciate all of his help in making this happen. Ran rja@inet.org From ipsec-owner@p-o.ans.net Tue Feb 13 17:46:54 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA18434 (5.65c/IDA-1.4.4 for ); Tue, 13 Feb 1996 12:49:03 -0500 Received: by p-o.ans.net id AA21755 (5.65c/IDA-1.4.4 for ipsec-outgoing); Tue, 13 Feb 1996 17:46:48 GMT Date: Tue, 13 Feb 1996 12:46:54 -0500 Message-Id: <9602131746.AA22260@MAILSERV-H.FTP.COM> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipsec@ans.net From: naganand@ftp.com (Naganand Doraswamy) Subject: ICMP messages Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Suppose say I want all packets going from host A to host B encrypted/authenticated and an error occurs. The ICMP packet that I send back will also be encrypted or authenticated and hence one will not be able to understand the ICMP messages as either an SPI is incorrect or the keys are incorrect. Now, do we say that ICMP messages are not encrypted? In that case we cannot say that all packets going from host A to host B are to be encrypted? Thanks, --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)659-6743 (O) From ipsec-owner@p-o.ans.net Tue Feb 13 18:44:33 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA18049 (5.65c/IDA-1.4.4 for ); Tue, 13 Feb 1996 13:51:57 -0500 Received: by p-o.ans.net id AA30821 (5.65c/IDA-1.4.4 for ipsec-outgoing); Tue, 13 Feb 1996 18:44:46 GMT Date: Tue, 13 Feb 1996 13:44:33 -0500 From: Theodore Ts'o Message-Id: <9602131844.AA01295@dcl.MIT.EDU> To: ipsec@ans.net Cc: ipsec@ans.net In-Reply-To: William Allen Simpson's message of Tue, 13 Feb 96 15:09:46 GMT, <4825.bsimpson@morningstar.com> Subject: Re: ADMIN: Straw Poll Results on Key Mgmt Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 1106 Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Bill, The requirement which Ran is referring to in RFC-1825 is that the key management protocol must be able to negotiate all of the parameters which may be associated with a security association, as found in section 1.4 of RFC-1825. This includes Encryption Algorith, Security Association Lifetime, and sensitivity label. In other words, those things addressed by Schertler's ISAKMP protocol. Right now we have a number of differnet proposals on the table, none of which completely meet all of the original requirements. However, it wouldn't be that hard to fix this; it wouldn't be hard for SKIP to add PFS, or Photoris to add support for full Security Association attributes negotiation, etc. Instead of bickering around playing procedural games and raising meta-issues, if the various people who are proposing key management protocols to this wg simply sat down and did the work to meet all of the requirements as originally specified by this wg, we could be done in relatively short order. I really don't think it's all that hard for any of the proposals currently on the table. - Ted From ipsec-owner@p-o.ans.net Tue Feb 13 19:04:12 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA15814 (5.65c/IDA-1.4.4 for ); Tue, 13 Feb 1996 14:13:12 -0500 Received: by p-o.ans.net id AA12525 (5.65c/IDA-1.4.4 for ipsec-outgoing); Tue, 13 Feb 1996 19:05:15 GMT Date: Tue, 13 Feb 1996 14:04:12 -0500 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199602131904.OAA04424@argon.ncsc.mil> To: ietf-radius@livingston.com Subject: Re: (mobile-ip) MD5 Key recovery attack Cc: ipsec@ans.net X-Sun-Charset: US-ASCII Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Yesterday, I wrote: > Netscape's SSL Version 3 (ftp://ftp.netscape.com/pub/review/ssl-spec.tar.Z) > has adopted the Krawczyk MAC using both MD5 and SHA. Also, a very > influential vendor consortium recently switched from using MD5 to SHA > because, despite the increased size of its hash value, SHA is > computationally faster than MD5. Several prominent experts have pointed out that the SHA is NOT faster than MD5. I have not yet been able to get clarification from the source of the above information - I may have misinterpreted what he said, or it may apply only in special circumstances. In any case, it is clear that on general purpose computers such as those that might be expected to host a RADIUS server, MD5 is faster than SHA. Sorry for the mis-information. Dave Kemp From ipsec-owner@p-o.ans.net Tue Feb 13 09:50:43 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA18446 (5.65c/IDA-1.4.4 for ); Tue, 13 Feb 1996 14:57:26 -0500 Received: by p-o.ans.net id AA16994 (5.65c/IDA-1.4.4 for ipsec-outgoing); Tue, 13 Feb 1996 19:54:40 GMT Message-Id: <199602131954.AA25949@interlock.ans.net> From: smb@research.att.com To: ipsec@ans.net Subject: Re: ICMP messages Date: Tue, 13 Feb 96 14:50:43 EST Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Suppose say I want all packets going from host A to host B encrypted/authenticated and an error occurs. The ICMP packet that I se nd back will also be encrypted or authenticated and hence one will not be able to understand the ICMP messages as either an SPI is incorrect or the k eys are incorrect. Now, do we say that ICMP messages are not encrypted? In that case we c annot say that all packets going from host A to host B are to be encrypted? Thanks, --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)659-6743 (O) Worse yet, if an intermediate route generates the ICMP bounce, there won't be enough information in the returned portion of the header to tie it to a particular socket. From ipsec-owner@p-o.ans.net Tue Feb 13 22:06:34 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA17523 (5.65c/IDA-1.4.4 for ); Tue, 13 Feb 1996 17:29:05 -0500 Received: by p-o.ans.net id AA38431 (5.65c/IDA-1.4.4 for ipsec-outgoing); Tue, 13 Feb 1996 22:26:24 GMT Date: Tue, 13 Feb 96 22:06:34 GMT From: "William Allen Simpson" Message-Id: <4827.bsimpson@morningstar.com> To: ipsec@ans.net Subject: Re: ADMIN: Straw Poll Results on Key Mgmt Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net > From: "Theodore Ts'o" > The requirement which Ran is referring to in RFC-1825 is that > the key management protocol must be able to negotiate all of the > parameters which may be associated with a security association, as found > in section 1.4 of RFC-1825. This includes > Encryption Algorith, Photuris has this. > Security Association Lifetime, Photuris has this. > and sensitivity label. > Photuris has this. Although it is only "recommended" in RFC-1825, and therefore only listed as a Photuris extension, not required in the base protocol. > Right now we have a number of differnet proposals on the table, > none of which completely meet all of the original requirements. Not true. Photuris includes all of the features listed in RFC-1825 1.4. This should not be surprising, as I also made contributions to that list. So, it must be some other set of requirements that Photuris does not meet. > However, it wouldn't be that hard to fix this; it wouldn't be hard for > SKIP to add PFS, or Photoris to add support for full Security > Association attributes negotiation, etc. Instead of bickering around > playing procedural games and raising meta-issues, if the various people > who are proposing key management protocols to this wg simply sat down > and did the work to meet all of the requirements as originally specified > by this wg, we could be done in relatively short order. Ted, Phil and I already did this long ago. I'm tired of the procedural games that others are playing. That explicitly includes our chairs. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-owner@p-o.ans.net Tue Feb 13 22:32:52 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA18669 (5.65c/IDA-1.4.4 for ); Tue, 13 Feb 1996 18:14:09 -0500 Received: by p-o.ans.net id AA04859 (5.65c/IDA-1.4.4 for ipsec-outgoing); Tue, 13 Feb 1996 23:12:24 GMT Date: Tue, 13 Feb 96 22:32:52 GMT From: "William Allen Simpson" Message-Id: <4828.bsimpson@morningstar.com> To: ipsec@ans.net Subject: Re: ICMP messages Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net > From: naganand@ftp.com (Naganand Doraswamy) > Suppose say I want all packets going from host A to host B > encrypted/authenticated and an error occurs. The ICMP packet that I send > back will also be encrypted or authenticated and hence one will not be able > to understand the ICMP messages as either an SPI is incorrect or the keys > are incorrect. > True, but then any ICMP error message may also be dropped enroute, and therefore you cannot depend on the error message transmission. > Now, do we say that ICMP messages are not encrypted? I do not believe that a general blanket statement can be made, except that ICMP messages dealing with security failures cannot be encrypted. Keep in mind this is also a problem with authentication, when the key is lost. So, the security failure messages cannot be authenticated either. This is one of the reasons why the Security Failures is a separate ICMP message set. > In that case we cannot > say that all packets going from host A to host B are to be encrypted? > Certainly not! As usual, a more sophisticated model is needed. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-owner@p-o.ans.net Tue Feb 13 22:40:06 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA17394 (5.65c/IDA-1.4.4 for ); Tue, 13 Feb 1996 18:14:10 -0500 Received: by p-o.ans.net id AA17148 (5.65c/IDA-1.4.4 for ipsec-outgoing); Tue, 13 Feb 1996 23:12:25 GMT Date: Tue, 13 Feb 96 22:40:06 GMT From: "William Allen Simpson" Message-Id: <4829.bsimpson@morningstar.com> To: ipsec@ans.net Subject: Re: ICMP messages Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net > From: smb@research.att.com > Worse yet, if an intermediate route generates the ICMP bounce, there > won't be enough information in the returned portion of the header to > tie it to a particular socket. > Only if you are using the same Destination+SPI for more than one socket. In general, this is not a problem for VPNs or mobility, since the tunnel is between hosts. It is only a problem for user-user keys, and then only for those not using automated key management to coordinate the SPIs. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-owner@p-o.ans.net Tue Feb 13 13:54:13 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA17203 (5.65c/IDA-1.4.4 for ); Tue, 13 Feb 1996 19:01:48 -0500 Received: by p-o.ans.net id AA22542 (5.65c/IDA-1.4.4 for ipsec-outgoing); Tue, 13 Feb 1996 23:59:38 GMT Message-Id: <199602132359.AA03105@interlock.ans.net> From: smb@research.att.com To: ipsec@ans.net Subject: Re: ICMP messages Date: Tue, 13 Feb 96 18:54:13 EST Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net From: Bill.Simpson@um.cc.umich.edu > From: smb@research.att.com > Worse yet, if an intermediate route generates the ICMP bounce, there > won't be enough information in the returned portion of the header to > tie it to a particular socket. > Only if you are using the same Destination+SPI for more than one socket. In general, this is not a problem for VPNs or mobility, since the tunnel is between hosts. It is only a problem for user-user keys, and then only for those not using automated key management to coordinate the SP Is. I beg your pardon? First you say ``only if you are using the same Destination+SPI for more than one socket.'', which is the case for host-host keys. Then you say ``only a problem for user-user keys'', in which case you're less likely to have multiple sockets per SPI. (Though it's not impossible, of course.) Scenarios I have in mind are things like ``destination unreachable'', from an intermediate router. With a VPN, there will be a lot of sockets sharing the same SPI for the firewall-to-firewall key. This is true whether key management is manual or automated. I confess that I'm surprised by your response, since I seem to remember talking about this with you, and you agreeing that this was a problem. From ipsec-owner@p-o.ans.net Wed Feb 14 00:39:42 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA12702 (5.65c/IDA-1.4.4 for ); Tue, 13 Feb 1996 19:42:53 -0500 Received: by p-o.ans.net id AA03666 (5.65c/IDA-1.4.4 for ipsec-outgoing); Wed, 14 Feb 1996 00:40:14 GMT Date: Tue, 13 Feb 1996 19:39:42 -0500 From: Theodore Ts'o Message-Id: <9602140039.AA01581@dcl.MIT.EDU> To: "William Allen Simpson" Cc: ipsec@ans.net In-Reply-To: William Allen Simpson's message of Tue, 13 Feb 96 22:06:34 GMT, <4827.bsimpson@morningstar.com> Subject: Re: ADMIN: Straw Poll Results on Key Mgmt Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 360 Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Date: Tue, 13 Feb 96 22:06:34 GMT From: "William Allen Simpson" Not true. Photuris includes all of the features listed in RFC-1825 1.4. This should not be surprising, as I also made contributions to that list. You're right; my apologies. I hadn't thought to look in draft-ietf-ipsec-photuris-ext-01.txt. - Ted From ipsec-owner@p-o.ans.net Wed Feb 14 11:49:44 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA17637 (5.65c/IDA-1.4.4 for ); Wed, 14 Feb 1996 07:00:44 -0500 Received: by p-o.ans.net id AA11075 (5.65c/IDA-1.4.4 for ipsec-outgoing); Wed, 14 Feb 1996 11:50:22 GMT Message-Id: <2.2.32.19960214114944.0035aad0@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 14 Feb 1996 06:49:44 -0500 To: ipsec@ans.net, ipsec@ans.net From: Robert Moskowitz Subject: Re: ADMIN: Straw Poll Results on Key Mgmt Cc: ipsec@ans.net Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net At 01:44 PM 2/13/96 -0500, Theodore Ts'o wrote: > > Right now we have a number of differnet proposals on the table, >none of which completely meet all of the original requirements. >However, it wouldn't be that hard to fix this; it wouldn't be hard for >SKIP to add PFS, or Photoris to add support for full Security >Association attributes negotiation, etc. Instead of bickering around >playing procedural games and raising meta-issues, if the various people >who are proposing key management protocols to this wg simply sat down >and did the work to meet all of the requirements as originally specified >by this wg, we could be done in relatively short order. I really don't >think it's all that hard for any of the proposals currently on the >table. Seconded. What is the Draft deadline? If any of these protocols are serious, let's see revisions to work on for LA. BTW, I will be at the ISOC security symposium next week to discuss any of this. Robert Moskowitz Chrysler Corporation (810) 758-8212 From ipsec-owner@p-o.ans.net Wed Feb 14 16:43:53 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA12609 (5.65c/IDA-1.4.4 for ); Wed, 14 Feb 1996 12:04:51 -0500 Received: by p-o.ans.net id AA30866 (5.65c/IDA-1.4.4 for ipsec-outgoing); Wed, 14 Feb 1996 16:58:25 GMT Date: Wed, 14 Feb 96 16:43:53 GMT From: "William Allen Simpson" Message-Id: <4833.bsimpson@morningstar.com> To: ipsec@ans.net Subject: Re: ADMIN: Straw Poll Results on Key Mgmt Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net > From: "Theodore Ts'o" > Instead of bickering around > playing procedural games and raising meta-issues, It has been suggested in private email that calling for public "support for Photuris" [my earlier message] is "playing procedural games". Gentlefolk, that is our process. The chairs are procedurally constrained by the public comments. Apparently, the chairs have received nothing but negative comments. It is common for us during protocol design to detail only the flaws. If there is not sufficient support for the chairs to go ahead with Photuris, then I certainly wouldn't want to waste any more time in the WG with the proposal. Instead, lacking WG support, it should be published as Experimental as originally intended, and the WG can get on with SKIP as may be the consensus desired. There are only a few days remaining for draft cut off. The time to announce your support is now.... Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-owner@p-o.ans.net Wed Feb 14 16:27:04 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA17474 (5.65c/IDA-1.4.4 for ); Wed, 14 Feb 1996 12:04:51 -0500 Received: by p-o.ans.net id AA44682 (5.65c/IDA-1.4.4 for ipsec-outgoing); Wed, 14 Feb 1996 16:58:21 GMT Date: Wed, 14 Feb 96 16:27:04 GMT From: "William Allen Simpson" Message-Id: <4831.bsimpson@morningstar.com> To: ipsec@ans.net Subject: Re: ICMP messages Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net > From: smb@research.att.com > I beg your pardon? First you say ``only if you are using the same > Destination+SPI for more than one socket.'', which is the case for > host-host keys. Not in host-host tunnel mode. In that case, there is no socket. As explained in RFC-1853, soft state needs to be maintained for the tunnel endpoints to reflect the ICMP messages to the originating host. This may be that same host, of course, when the tunnel is internally generated. The same soft state can be reflected to the sockets individually. > Then you say ``only a problem for user-user keys'', in > which case you're less likely to have multiple sockets per SPI. (Though > it's not impossible, of course.) > Some folks have contemplated such. Indeed, your CBC concatenation attack requires that the same SPI be used by more than one user. While we probably cannot prohibit this behaviour for manually keyed implementations, Photuris clearly states that such sharing is not allowed because it is not secure, and contains mechanisms to prevent this from happening. > Scenarios I have in mind are things like ``destination unreachable'', from > an intermediate router. With a VPN, there will be a lot of sockets > sharing the same SPI for the firewall-to-firewall key. This is true > whether key management is manual or automated. > The distinction is that the firewalls' tunnel has no sockets itself, and therefore no need to search the internal headers. > I confess that I'm surprised by your response, since I seem to remember > talking about this with you, and you agreeing that this was a problem. > I cannot remember the details of our conversation. Perhaps I was agreeing that it is a problem for users sharing the same host SPI, which lead to the restriction in Photuris. I do not believe this is a problem for VPNs following RFC-1853. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-owner@p-o.ans.net Wed Feb 14 17:57:20 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14282 (5.65c/IDA-1.4.4 for ); Wed, 14 Feb 1996 13:04:57 -0500 Received: by p-o.ans.net id AA27377 (5.65c/IDA-1.4.4 for ipsec-outgoing); Wed, 14 Feb 1996 18:00:56 GMT Date: Wed, 14 Feb 1996 19:57:20 +0200 From: "Angelos D. Keromytis" Message-Id: <199602141757.TAA24687@vicky> Organization: Hellenic Telecommunications & Telematics Applications Company FORTHnet S.A., P.O.Box 2219, Heraklio, Crete, Greece 71003 tel: +30(81)391200 fax: +30(81)391201 To: ipsec@ans.net Subject: Re: ADMIN: Straw Poll Results on Key Mgmt Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net I do believe Photuris fulfills all the requirements of the WG; if the chairs believe i'm at fault, i invite them to tell me why it is so. Regards, -Angelos From ipsec-owner@p-o.ans.net Wed Feb 14 19:08:14 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA18032 (5.65c/IDA-1.4.4 for ); Wed, 14 Feb 1996 14:10:40 -0500 Received: by p-o.ans.net id AA22741 (5.65c/IDA-1.4.4 for ipsec-outgoing); Wed, 14 Feb 1996 19:08:05 GMT Date: Wed, 14 Feb 1996 14:08:14 -0500 Message-Id: <9602141908.AA03604@MAILSERV-H.FTP.COM> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipsec@ans.net From: naganand@ftp.com (Naganand Doraswamy) Subject: Re: ADMIN: Straw Poll Results on Key Mgmt Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net We have started Photuris implementation. At this point, we have been able to implement it from the spec and I beleive is conforms to most of the requirments in RFC1825. I say most because I have not thought about all possible scenarios. If the Admin's and the working group feel that there are deficiencies in the current key management drafts, I guess those should be enumerated as Angelos mentioned in his mail. Having a key management protocol is critical for the acceptance of IPSEC and we have to come up with standard(s) as soon as possible. Regards, --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)659-6743 (O) From ipsec-owner@p-o.ans.net Wed Feb 14 20:48:19 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA18501 (5.65c/IDA-1.4.4 for ); Wed, 14 Feb 1996 15:56:52 -0500 Received: by p-o.ans.net id AA22546 (5.65c/IDA-1.4.4 for ipsec-outgoing); Wed, 14 Feb 1996 20:48:53 GMT Message-Id: <199602142011.PAA04686@inner.net> X-Mailer: exmh version 1.6.5 12/11/95 To: ipsec@ans.net Subject: Straw Poll and Photuris X-Reposting-Policy: With explicit permission only Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Feb 1996 15:48:19 -0500 From: Craig Metz Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net As a result of some private communications, I'd just like to publicly voice that I think that the Photuris protocol is a viable and reasonable contender for Internet standards-track status and shouldn't be derailed. However, I also think that it's very important the the spec document be as well done as possible, and I have not seen anything in the new straw poll consensus that is an unreasonable requirement for a specification to provide. I'd like to see the Photuris spec changed to meet these requirements so that it (and we) can move on to more important things like trying to implement. -Craig From ipsec-owner@p-o.ans.net Wed Feb 14 13:50:56 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA18163 (5.65c/IDA-1.4.4 for ); Wed, 14 Feb 1996 18:57:08 -0500 Received: by p-o.ans.net id AA37773 (5.65c/IDA-1.4.4 for ipsec-outgoing); Wed, 14 Feb 1996 23:49:12 GMT From: canetti@theory.lcs.mit.edu (Ran Canetti) Date: Wed, 14 Feb 96 18:50:56 EST Message-Id: <199602142350.AA08957@blackbird.lcs.mit.edu> To: d_nelson@irocz.lkg.dec.com, ietf-radius@livingston.com, ipsec@ans.net Subject: Re: (radius) FWD: (mobile-ip) MD5 Key recovery attack Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net >From: dpkemp@missi.ncsc.mil (David P. Kemp) >Message-Id: <199602121439.JAA02761@argon.ncsc.mil> > >There are (at least :-) two directions in which to look for solutions: > > 1) Internet Draft "draft-krawczyk-keyed-md5-01.txt" presents an > analysis of the use of hash functions as Message Authenticators. > It suggests using the construct: > > Hash(Key, Pad2, Hash(Key, Pad1, Text)) > > in lieu of other structures such as Hash(Key, Text, Key). > The Krawczyk MAC relies on significantly fewer assumptions about > the properties of the hash algorithm than do other methods (which > were apparently concocted without much in the way of security > analysis). Just to expand a bit: the above scheme is assured to serve as a good MAC as long as the following two conditions hold. (This applies for any iterated hash function, in particular MD5 and SHA). 1. The hash function is collision-free. This is what hash functions are designed for. (In fact, only a considerably weaker-than-standard collision-freeness assumption is needed, namely that collisions are hard to find when the iterated construction starts with a *random and secret* IV, rather than with the fixed public IV. Furthermore, parallel collision-finding attacks a la Van-Oorschot-Weiner are infeasible here.) 2. The internal compression function of the hash function is a good MAC on 512 bit messages. This is a minimal security requirement that is believed to hold for both MD5 and SHA. This scheme is proposed and analyzed in the paper "Keying Hash Functions for Message Authentication" by Mihir Bellare, Hugo Krawczyk and myself, available at http://www-cse.ucsd.edu/users/mihir http://www.research.ibm.com/security/keyed-md5.html It is also summarized in the above Internet Draft. Ran Canetti From ipsec-owner@p-o.ans.net Thu Feb 15 00:19:24 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA16482 (5.65c/IDA-1.4.4 for ); Wed, 14 Feb 1996 19:53:11 -0500 Received: by p-o.ans.net id AA14461 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 15 Feb 1996 00:47:50 GMT X-Sender: piper@fluffy.tgv.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 14 Feb 1996 16:19:24 -0800 To: ipsec@ans.net From: piper@TGV.COM (Derrell Piper) Subject: Re: (radius) FWD: (mobile-ip) MD5 Key recovery attack Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net >>From: dpkemp@missi.ncsc.mil (David P. Kemp) >>Message-Id: <199602121439.JAA02761@argon.ncsc.mil> >> >>There are (at least :-) two directions in which to look for solutions: >> >> 1) Internet Draft "draft-krawczyk-keyed-md5-01.txt" presents an >> analysis of the use of hash functions as Message Authenticators. >> It suggests using the construct: >> >> Hash(Key, Pad2, Hash(Key, Pad1, Text)) >> >> in lieu of other structures such as Hash(Key, Text, Key). >> The Krawczyk MAC relies on significantly fewer assumptions about >> the properties of the hash algorithm than do other methods (which >> were apparently concocted without much in the way of security >> analysis). In light of this work, are there any plans to update RFC1828? Derrell Piper | piper@tgv.com | 408/457-5384 TGV, Inc. | 101 Cooper Street | Santa Cruz, CA 95060 USA From ipsec-owner@p-o.ans.net Thu Feb 15 07:24:14 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA15789 (5.65c/IDA-1.4.4 for ); Thu, 15 Feb 1996 02:56:47 -0500 Received: by p-o.ans.net id AA21342 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 15 Feb 1996 07:48:58 GMT Date: Thu, 15 Feb 96 07:24:14 GMT From: "William Allen Simpson" Message-Id: <4845.bsimpson@morningstar.com> To: ipsec@ans.net Subject: Re: Straw Poll and Photuris Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net > From: Craig Metz > However, I also think that it's very important the the spec document be as > well done as possible, and I have not seen anything in the new straw poll > consensus that is an unreasonable requirement for a specification to provide. Indeed, neither have I. Except that the straw poll statement goes beyond the actual results of the 3 questions in the poll itself to indicate a "conclusion" not indicated in any of the responses to the poll, and not germain to the questions in the poll. CONCLUSIONS: (1) None of the proposals currently online appear to fully meet all of the requirements, though it does appear that all of them could be modified to meet all of the requirements. How can this "conclusion" be reached, when examination of the list archives yields not a single response to the straw poll mentioning that none of the proposals fully meets the requirements? This conclusion does not in any way represent "consensus". It may be the personal opinion of one or more chairs, but that is not within their purview to impose upon the rest of us. > I'd like to see the Photuris spec changed to meet these requirements so that > it (and we) can move on to more important things like trying to implement. > It has been admitted that Photuris meets every single requirement listed in RFC-1825 section 1.4 and section 2. What requirement do you mean? Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-owner@p-o.ans.net Thu Feb 15 13:15:51 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA12680 (5.65c/IDA-1.4.4 for ); Thu, 15 Feb 1996 08:27:37 -0500 Received: by p-o.ans.net id AA14462 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 15 Feb 1996 13:16:21 GMT Date: Thu, 15 Feb 1996 07:15:51 -0600 (CST) From: Todd Graham Lewis X-Sender: todd@ns.election.net To: ipsec@ans.net Subject: Re: Straw Poll and Photuris In-Reply-To: <4845.bsimpson@morningstar.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net On Thu, 15 Feb 1996, William Allen Simpson wrote: (...) > Except that the straw poll statement goes beyond the actual results of > the 3 questions in the poll itself to indicate a "conclusion" not > indicated in any of the responses to the poll, and not germain to the > questions in the poll. > > CONCLUSIONS: > (1) None of the proposals currently online appear to fully > meet all of the requirements, though it does appear that > all of them could be modified to meet all of the > requirements. > > How can this "conclusion" be reached, when examination of the list > archives yields not a single response to the straw poll mentioning that > none of the proposals fully meets the requirements? (...) > It has been admitted that Photuris meets every single requirement listed > in RFC-1825 section 1.4 and section 2. What requirement do you mean? I am confused as well by the nature of the previous days' objections. My impression has been that Photuris does meet these requirements. I have been wrong on these sorts of issues in the past, and I do not claim any great insight into the issue. However, I personally would appreciate it those bearing objections would state "Photuris is not ready to progress beyond draft stage because it does not meet requirement (X) as stated in (Y) as evinced by the following quote from (Z)." I think that such an approach might enable all of us to have a better idea of the sense of the working group, which I think is what the chairs are seeking. My opinion, _in the absence of such specific objections_, is that Photuris has met the aforementioned requirements, and it should be allowed to advance. Todd Lewis todd@wooster.org From ipsec-owner@p-o.ans.net Thu Feb 15 15:15:03 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14181 (5.65c/IDA-1.4.4 for ); Thu, 15 Feb 1996 10:21:59 -0500 Received: by p-o.ans.net id AA03678 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 15 Feb 1996 15:17:30 GMT Date: Thu, 15 Feb 96 16:15:03 +0100 Message-Id: <9602151515.AA09401@gmv.es> From: Julio Sanchez To: ipsec@ans.net In-Reply-To: (message from Todd Graham Lewis on Thu, 15 Feb 1996 07:15:51 -0600 (CST)) Subject: Re: Straw Poll and Photuris Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net > Date: Thu, 15 Feb 1996 07:15:51 -0600 (CST) > From: Todd Graham Lewis > > My opinion, _in the absence of such specific objections_, is that Photuris > has met the aforementioned requirements, and it should be allowed to advance. I second this position. Please, tell what is wrong with Photuris here so that we can all hear it and think about it. Maybe I have been to sleepy, but I am yet to hear any strong objection. Maybe it's that those like me who agree with the general principles behind Photuris have been quiet. This has nothing to do with blanket approval, it's rather than we are happy with the way the Photuris design team has addressed those weaknesses pointed to them. But I thought this was the IETF way, you don't speak unless you object. Maybe I was wrong. -- Julio Sanchez, SGI Soluciones Globales Internet Tel/Fax: 91/804 14 05 WWW: http://www.esegi.es jsanchez@esegi.es jsanchez@gmv.es PGP Key fingerprint = E5 29 93 6F 41 4E 00 E2 90 11 A1 8C 72 D0 DE 71 From ipsec-owner@p-o.ans.net Thu Feb 15 01:55:58 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA16540 (5.65c/IDA-1.4.4 for ); Thu, 15 Feb 1996 13:00:19 -0500 Received: by p-o.ans.net id AA21326 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 15 Feb 1996 17:55:42 GMT Date: Thu, 15 Feb 96 09:55:58 PST From: "baldwin" Message-Id: <9601158244.AA824406719@snail.rsa.com> To: ipsec@ans.net Subject: Photuris and Skip should both advance quickly Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net From where I sit talking to IP security product vendors, both Photuris and SKIP in their current forms meet the market requirements for large rapidly growing markets. The SKIP protocol has unique advantages in the area of multi-cast transmissions, and the Photuris has advantages for high security point to point communication that includes perfect forward secrecy. Vendors need both. Users will buy both. The IETF should help the vendors meet these growing user demands as soon as possible. Further delay in the working group will cause the vendors to move on by themselves, which history shows will cause problems down the road. This is a time for hard work by smart people cooperating with each other. This is not a time for dragging heals! --Bob P.S. This is my personal opinion, not a company statement. Received: from dawn7.cs.berkeley.edu by neptune.TIS.COM id aa29747; 15 Feb 96 16:04 EST Received: (from daw@localhost) by dawn7.CS.Berkeley.EDU (8.6.11/8.6.9) id NAA04780 for ipsec@neptune.tis.com; Thu, 15 Feb 1996 13:07:03 -0800 From: David A Wagner Message-Id: <199602152107.NAA04780@dawn7.CS.Berkeley.EDU> Subject: support for Photuris To: ipsec@neptune.tis.com Date: Thu, 15 Feb 1996 13:07:02 -0800 (PST) Reply-To: daw@cs.berkeley.edu X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 305 Sender: ipsec-request@neptune.tis.com Precedence: bulk I just wanted to express my support for Photuris: IMHO, it looks like a reasonable solution. I'm comfortable with Photuris; my personal feeling is that it should be allowed to advance... Are there any substantive objections to Photuris, in terms of the ipsec requirements for a key management protocol? Received: from jekyll.piermont.com by neptune.TIS.COM id aa01984; 15 Feb 96 17:48 EST Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) with SMTP id RAA27364; Thu, 15 Feb 1996 17:51:09 -0500 (EST) Message-Id: <199602152251.RAA27364@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: daw@cs.berkeley.edu cc: ipsec@neptune.tis.com Subject: Re: support for Photuris In-reply-to: Your message of "Thu, 15 Feb 1996 13:07:02 PST." <199602152107.NAA04780@dawn7.CS.Berkeley.EDU> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Thu, 15 Feb 1996 17:51:08 -0500 From: "Perry E. Metzger" Sender: ipsec-request@neptune.tis.com Precedence: bulk David A Wagner writes: > I just wanted to express my support for Photuris: IMHO, it looks like > a reasonable solution. I'm comfortable with Photuris; my personal feeling > is that it should be allowed to advance... > > Are there any substantive objections to Photuris, in terms of the ipsec > requirements for a key management protocol? I think that there are details in Photuris that need to be worked with and possibly changed. I think we also need more field experience and probably a bunch more experimentation. However, the fundamentals of the Photuris approach are sound and I feel comfortable with them. I think we might go from proposed standard back to proposed a second time once we have more experience if that experience dictates more than cosmetic changes, but thats another story. I certainly feel Photuris is what we want and that it should move forward. Perry Received: from stilton.cisco.com by neptune.TIS.COM id aa04740; 15 Feb 96 20:59 EST Received: from cisco.com (localhost.cisco.com [127.0.0.1]) by stilton.cisco.com (8.6.8+c/8.6.5) with ESMTP id SAA20239; Thu, 15 Feb 1996 18:01:48 -0800 Message-Id: <199602160201.SAA20239@stilton.cisco.com> To: ipsec@neptune.tis.com Cc: palamber@us.oracle.com, rja@inet.org, jis@mit.edu Subject: Working group requirements Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <20092.824436101.1@cisco.com> Date: Thu, 15 Feb 1996 18:01:42 -0800 From: David Carrel Sender: ipsec-request@neptune.tis.com Precedence: bulk As long as we are on the subject, I would like to suggest that we make support for RSVP a requirement for the key management protocol. Support for RSVP is not difficult and most of the current proposals will already support it. Those that do not could be made to without too much effort. The requirement is basically that unique SPIs be available for each flow. A draft by Lou Berger and Tim O'Malley is promissed to be available soon. On another topic related to requirements, I do not agree that Photuris meets the working group requirements. For example, section 1.4 of RFC 1825 is nigh impossible to acomodate for an interoperable implementation based on the Photuris draft and the extentions draft. The entire draft(s) has become unwieldy. Dave ---------------------------------------------------------------------------- David Carrel | E-mail: carrel@cisco.com Security Development, cisco Systems | phone: (408) 526-5207 170 W. Tasman Drive | fax: (408) 526-4952 San Jose, CA 95134-1706 | ---------------------------------------------------------------------------- Received: from simon.cs.cornell.edu by neptune.TIS.COM id aa07081; 16 Feb 96 0:15 EST Received: from cloyd.cs.cornell.edu (CLOYD.CS.CORNELL.EDU [128.84.227.15]) by simon.cs.cornell.edu (8.6.10/R1.4) with ESMTP id AAA29921; Fri, 16 Feb 1996 00:18:02 -0500 Received: from gilling.cs.cornell.edu (GILLING.CS.CORNELL.EDU [128.84.254.180]) by cloyd.cs.cornell.edu (8.6.10/M1.8) with ESMTP id AAA07185; Fri, 16 Feb 1996 00:18:00 -0500 From: Lewis McCarthy Received: (lew@localhost) by gilling.cs.cornell.edu (8.6.10/C1.3) id AAA24472; Fri, 16 Feb 1996 00:17:51 -0500 Date: Fri, 16 Feb 1996 00:17:51 -0500 Message-Id: <199602160517.AAA24472@gilling.cs.cornell.edu> To: carrel@cisco.com Subject: Re: Working group requirements Cc: ipsec@neptune.tis.com Sender: ipsec-request@neptune.tis.com Precedence: bulk On IPsec, you wrote: > I do not agree that Photuris meets the working group requirements. > For example, section 1.4 of RFC 1825 is nigh impossible to acomodate [sic] > for an interoperable implementation based on the Photuris draft and the > extentions [sic] draft. The entire draft(s) has become unwieldy. I think it would be extremely useful for you to elaborate on precisely _how_ the Security Associations section of RFC 1825 is "nigh impossible" to accommodate for an interoperable implementation based on the drafts. The WG seems to be spending days upon days effectively 'voting' on whether or not Photuris meets the WG requirements. At this stage of the game, this strikes me as a bit silly. IMHO everyone (including the chairs) should be getting down to brass tacks, so the remaining technical objections can be resolved one way or another. -Lewis Received: from www.wooster.org by neptune.TIS.COM id aa17505; 16 Feb 96 12:06 EST Received: (from todd@localhost) by ns.election.net (8.7.1/8.6.9) id LAA06657; Fri, 16 Feb 1996 11:08:12 -0600 Date: Fri, 16 Feb 1996 11:08:10 -0600 (CST) From: Todd Graham Lewis X-Sender: todd@ns.election.net To: Lewis McCarthy cc: carrel@cisco.com, ipsec@neptune.tis.com Subject: Re: Working group requirements In-Reply-To: <199602160517.AAA24472@gilling.cs.cornell.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipsec-request@neptune.tis.com Precedence: bulk On Fri, 16 Feb 1996, Lewis McCarthy wrote: > I think it would be extremely useful for you to elaborate on precisely _how_ > the Security Associations section of RFC 1825 is "nigh impossible" to > accommodate for an interoperable implementation based on the drafts. The WG > seems to be spending days upon days effectively 'voting' on whether or not > Photuris meets the WG requirements. At this stage of the game, this strikes > me as a bit silly. IMHO everyone (including the chairs) should be getting > down to brass tacks, so the remaining technical objections can be resolved > one way or another. I strenuously agree with this objection. I want to see the list of reasons why advancing Photuris is unacceptable. I would like to see line-by-line references, as many members of this working group have done in the past. I think that the amount of time we are spending on this is silly. I say this because there are many members of this group more adept at addressing the issues than myself. My impression is that Photuris is ready to advance. If others disagree, then you should make your objections known. If you do not, then I will pat myself on the back for being such a smart guy and then press for Photuris' advancement. However, in the last 72 hours the only objection has been an un-referenced opinion that implementation of the RFC1825 Security Association requirements would be impossible (an objection that I do not understand after having re-read RFC1825 and the draft Photuris spec.) This leads me to believe that there are no members of the group who bear serious objections to Photuris' advancement. I think that the Chairs should seriously consider taking appropriate steps to insure that we can meet the already-stretched timeframe for getting something (Photuris and/or others) out the door. Todd Lewis todd@wooster.org P.s., (In reference to carrel@cisco.com) Reflecting over the development cycle through which Photuris has gone, I am of the opinion that its level of complexity is the result of its absolute demand for integrity. If others could come up with a key-management method of less complexity which achieves equivalent results, then I wish that they had done so in a timely manner. I personally think that any protocol "nigh" able to "accomodate section 1.4 of RFC1825" will be just as "unwieldy" as Photuris, and I wish that people with real objections (if there are any) would come forward so that we can finish this business and get on with securing IP traffic ASAP. I don't think that this is an unreasonable demand. I do think that the chairs are being awfully generous to those with objections to Photuris. I also think that those with objections might just be Phantoms of a collectively over-active imagination, and this opinion will strengthen as time goes on and these phantom objections continue to keep themselves hidden from the rest of us too dumb to think them up ourselves. Todd Received: from relay.tis.com by neptune.TIS.COM id aa03931; 19 Feb 96 18:29 EST Received: by relay.tis.com; id SAA15726; Mon, 19 Feb 1996 18:31:21 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma015719; Mon, 19 Feb 96 18:30:53 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01979; Mon, 19 Feb 96 18:29:53 EST Received: by relay.tis.com; id SAA15716; Mon, 19 Feb 1996 18:30:51 -0500 Received: from milkyway.com(198.53.167.2) by relay.tis.com via smap (V3.1) id xma015714; Mon, 19 Feb 96 18:30:25 -0500 Received: from jupiter.milkyway.com (jupiter.milkyway.com [192.168.77.9]) by internet with ESMTP (DuhMail/2.0) id SAA25926; Mon, 19 Feb 1996 18:26:43 -0500 Received: from milkyway.com (root@metis.milkyway.com [192.168.77.21]) by jupiter.milkyway.com (8.6.12/8.6.12) with ESMTP id SAA10382 for ; Mon, 19 Feb 1996 18:30:32 -0500 Received: from metis.milkyway.com by milkyway.com (8.6.12/BSDI-Client) id SAA29613; Mon, 19 Feb 1996 18:42:04 -0500 Message-Id: <199602192342.SAA29613@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, 05 Feb 1996 23:49:31 PST." <199602060749.XAA13045@dawn9.CS.Berkeley.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Feb 1996 18:41:59 -0500 From: Michael Richardson Sender: ipsec-request@neptune.tis.com Precedence: bulk In a galaxy far, far away, : Mon, 05 Feb 1996 23:49:31 PST > If AH with a symmetrically-keyed MAC is used just for protecting reserved > bandwidth (not for secure end-to-end source authentication or message > integrity), then it doesn't seem like such a big deal to have to trust a > few routers to hold your bandwidth session-key. I agree. It doesn't sound that bad. But, which routers do I share the secret with? My packet could go via different routes each time. The routers could be "owned" by malevolent entities. How do I negotiate the AH key for the RSVP differently from the one I use for authentication? I'd like to use RSVP on *all* my data. It seems like an ideal way to cope with many denial of service attacks. RSVP specifies that the recipient sets up the reservations. IPsec does a similar thing: the receiver picks the SPI. So in any public key system, the recipient has to let the router know what public key is going to be signing which SPI. I have to review RSVP again to figure out how that works... (RSVP does provide for having AH protected RSVP messages. But it also provides its own encryption facilities. I think it should stick to AH) > (After all, you have to trust them to actually give you the bandwidth which > they've promised to reserve for you.) Yes, then the question arises: how close to the backbone do I have to reserve bandwidth for? Do I let other people reserve bandwidth for their data to leave my domain of physical control over my 56k link? > Yeah, that's a problem with public-key stuff: it's so slow. Do note that > signature verification is much faster than signature generation when you use > RSA with a small public exponent, though it is admittedly still quite slow. Yes, I've read that paper. Received: from optima.cs.arizona.edu by neptune.TIS.COM id aa24377; 20 Feb 96 19:14 EST Received: from uncial.CS.Arizona.EDU by optima.cs.arizona.edu (5.65c/15) via SMTP id AA12208; Tue, 20 Feb 1996 17:17:00 MST Received: by uncial.CS.Arizona.EDU; (5.65/1.1.8.2/08Nov94-0446PM) id AA27794; Tue, 20 Feb 1996 17:16:57 -0700 Date: Tue, 20 Feb 1996 17:16:57 -0700 From: Hilarie Orman Message-Id: <9602210016.AA27794@uncial.CS.Arizona.EDU> To: ipsec@neptune.tis.com Subject: Oakley draft Sender: ipsec-request@neptune.tis.com Precedence: bulk I've recently submitted a draft for a key exchange protocol named Oakley; the draft will be available in the archives and also as http://www.cs.arizona.edu/xkernel/Papers/draft-ietf-ipsec-oakley-00.txt. The technical rationale for Oakley is that two parties can establish variation in the underlying problem facing a concerted passive attacker who has recorded traffic and extensive time and resources. The algorithms are not new --- just Diffie-Hellman, encryption, etc., but the combinations may provide a good degree of confidence in long-term privacy. Oakley is intended for key exchange only; it separates the establishment and naming of keying material from its eventual use. The design stands on its own, but allows it (or will allow it) to be a component of ISAKMP for establishing AH/ESP security associations. I am distributing the Oakley draft even though it is far from complete or perfect; the imperfections afflict many particulars. It is my hope that its basic precepts can be understood and discussed now, and this will indicate if it has any merit within the working group. I'd like to note that undertaking this task has been a humbling experience (even without yet experiencing the lively public commentary that draft writers provoke), and I take my hat off to those who have trodden the draft path ahead of me. If you will be at the ISOC SNDSS meeting, you'll see on Friday that I have bought a hat specifically for this purpose. Received: from relay.tis.com by neptune.TIS.COM id aa08607; 21 Feb 96 11:36 EST Received: by relay.tis.com; id LAA12471; Wed, 21 Feb 1996 11:38:35 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma012468; Wed, 21 Feb 96 11:38:09 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10096; Wed, 21 Feb 96 11:37:06 EST Received: by relay.tis.com; id LAA12461; Wed, 21 Feb 1996 11:38:05 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma012454; Wed, 21 Feb 96 11:37:58 -0500 Received: from puli.cisco.com by interlock.ans.net with SMTP id AA19314 (InterLock SMTP Gateway 3.0 for ); Wed, 21 Feb 1996 11:38:54 -0500 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id IAA16711 for ipsec@ans.net; Wed, 21 Feb 1996 08:38:46 -0800 Date: Wed, 21 Feb 1996 08:38:46 -0800 From: Ran Atkinson Message-Id: <199602211638.IAA16711@puli.cisco.com> To: ipsec@ans.net Subject: IPsec Implementation Survey: NRL Sender: ipsec-request@neptune.tis.com Precedence: bulk ------------------------------------------ IPSEC Implementation Survey Name of Implementation: NRL Security Protocols: ESP, AH -- for BOTH IPv4 and IPv6 Security Transforms: ESP-DES, AH-MD5 Key Management: manual, PF_KEY interface for key management daemons Lineage of Code: derived from and portable to 4.4-Lite BSD Location of Source Code: ftp://ftp.ripe.net/ipv6/nrl/IPv6_domestic.tar.gz for the September 1995 alpha release. January 1996 alpha-2 release is not yet at an ftp site, but should appear soon in the protected "US-only" archives at ftp.c2.org. Point of Contact: ipv6-bugs@cs.nrl.navy.mil Received: from relay.tis.com by neptune.TIS.COM id aa14609; 21 Feb 96 17:00 EST Received: by relay.tis.com; id RAA19509; Wed, 21 Feb 1996 17:02:02 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma019502; Wed, 21 Feb 96 17:01:33 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA29200; Wed, 21 Feb 96 17:00:32 EST Received: by relay.tis.com; id RAA19499; Wed, 21 Feb 1996 17:01:31 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma019493; Wed, 21 Feb 96 17:01:02 -0500 Received: from inet-user-gw-1.us.oracle.com by interlock.ans.net with SMTP id AA02841 (InterLock SMTP Gateway 3.0 for ); Wed, 21 Feb 1996 17:02:01 -0500 Received: from mailsun2.us.oracle.com by inet-user-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id OAA27155; Wed, 21 Feb 1996 14:01:29 -0800 Received: by mailsun2.us.oracle.com (8.7.1/37.8) id OAA17218; Wed, 21 Feb 1996 14:03:59 -0800 (PST) Message-Id: <199602212203.OAA17218@mailsun2.us.oracle.com> Date: 21 Feb 96 13:26:18 -0800 From: "PALAMBER.US.ORACLE.COM" To: ipsec@ans.net Subject: IPSEC Implementation Survey Mime-Version: 1.0 Sender: ipsec-request@neptune.tis.com Precedence: bulk I have recieved several requests for the location of source code for ipsec implementations. Our working group also needs to coordinate interoperability testing amoung ourselves. To this end, would ipsec implementors please fill out the following survey and post your completed survey to the ipsec mailing list. Thanks in advance, Paul A. Lambert ipsec co-chair ------------------------------------------- IPSEC Implementation Survey Name of Implementation: Security Protocols: Security Transforms: Key Management: Lineage of Code: Location of Source Code: Point of Contact: ------------------------------------------- Received: from relay.tis.com by neptune.TIS.COM id aa15325; 21 Feb 96 17:33 EST Received: by relay.tis.com; id RAA20381; Wed, 21 Feb 1996 17:35:20 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma020378; Wed, 21 Feb 96 17:34:52 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA00988; Wed, 21 Feb 96 17:33:50 EST Received: by relay.tis.com; id RAA20371; Wed, 21 Feb 1996 17:34:50 -0500 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1) id xma020354; Wed, 21 Feb 96 17:34:23 -0500 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id OAA15980; Wed, 21 Feb 1996 14:35:27 -0800 Received: by mailsun2.us.oracle.com (8.7.1/37.8) id OAA21701; Wed, 21 Feb 1996 14:37:34 -0800 (PST) Message-Id: <199602212237.OAA21701@mailsun2.us.oracle.com> Date: 21 Feb 96 14:31:41 -0800 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: IPSEC Implementation Survey Cc: PALAMBER@us.oracle.com Mime-Version: 1.0 Sender: ipsec-request@neptune.tis.com Precedence: bulk I have received several requests for the location of source code for ipsec implementations. Our working group also needs to coordinate interoperability testing among ourselves. To this end, would ipsec implementors please fill out the following survey and post your completed survey to the ipsec mailing list. Thanks in advance, Paul A. Lambert ipsec co-chair ************************************************************ IPSEC Implementation Survey Name of Implementation: Security Protocols: Security Transforms: Key Management: Lineage of Code: Location of Source Code: Point of Contact: ************************************************************ Received: from relay.tis.com by neptune.TIS.COM id aa15635; 21 Feb 96 17:46 EST Received: by relay.tis.com; id RAA20596; Wed, 21 Feb 1996 17:47:50 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma020594; Wed, 21 Feb 96 17:47:21 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01539; Wed, 21 Feb 96 17:46:20 EST Received: by relay.tis.com; id RAA20591; Wed, 21 Feb 1996 17:47:20 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma020588; Wed, 21 Feb 96 17:46:59 -0500 Received: from shark.mel.dit.CSIRO.AU by interlock.ans.net with SMTP id AA04340 (InterLock SMTP Gateway 3.0 for ); Wed, 21 Feb 1996 17:47:58 -0500 Received: from koel.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA02241 (5.65c/IDA-1.4.4/DIT-1.3 for ipsec@ans.net); Thu, 22 Feb 1996 09:47:51 +1100 Message-Id: <199602212247.AA02241@shark.mel.dit.csiro.au> X-Mailer: exmh version 1.6 4/21/95 To: ipsec@ans.net Subject: IP encapsulation proposal Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Feb 1996 09:47:50 +1100 From: Bob Smart Sender: ipsec-request@neptune.tis.com Precedence: bulk The last call for the Mobile-IP proposals (to go to Proposed Standard) includes one document > 2. IP Encapsulation within IP > with broad applicability beyond Mobility. It also has strong interactions with security in general and IPSEC in particular. So I hope the members of this list have had a look at it. Bob Smart Received: from relay.tis.com by neptune.TIS.COM id aa16875; 21 Feb 96 19:03 EST Received: by relay.tis.com; id TAA21481; Wed, 21 Feb 1996 19:05:24 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma021474; Wed, 21 Feb 96 19:04:58 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03749; Wed, 21 Feb 96 19:03:56 EST Received: by relay.tis.com; id TAA21455; Wed, 21 Feb 1996 19:04:54 -0500 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1) id xma021450; Wed, 21 Feb 96 19:04:43 -0500 Received: from maildig1.us.oracle.com by inet-smtp-gw-1.us.oracle.com with SMTP (8.6.12/37.7) id QAA31823; Wed, 21 Feb 1996 16:05:52 -0800 Received: by maildig1.us.oracle.com (5.65v3.2/37.8) id AA15881; Wed, 21 Feb 1996 16:05:44 -0800 Message-Id: <9602220005.AA15881@maildig1.us.oracle.com> Date: Wed, 21 Feb 1996 16:05:44 -0800 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: Re: IPSEC Implementation Survey X-Orcl-Application: In-Reply-To:UNX02.US.ORACLE.COM:ipsec-request@neptune.tis.com's message of 21-Feb-96 14:31 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Boundary-16782935-0-0 Sender: ipsec-request@neptune.tis.com Precedence: bulk --Boundary-16782935-0-0 Sorry for the double post with the survey, but our new Majordomo list server sent me a odd (obvious only now non-fatal) error. p.l. --Boundary-16782935-0-0 Content-Type: message/rfc822 Date: 21 Feb 96 14:31:41 From:"PALAMBER.US.ORACLE.COM" To: ipsec@tis.com Subject: IPSEC Implementation Survey Cc: PALAMBER@us.oracle.com X-Orcl-Application: Mime-Version: 1.0 X-Orcl-Application: Sender: ipsec-request@neptune.tis.com X-Orcl-Application: Precedence: bulk I have received several requests for the location of source code for ipsec implementations. Our working group also needs to coordinate interoperability testing among ourselves. To this end, would ipsec implementors please fill out the following survey and post your completed survey to the ipsec mailing list. Thanks in advance, Paul A. Lambert ipsec co-chair ************************************************************ IPSEC Implementation Survey Name of Implementation: Security Protocols: Security Transforms: Key Management: Lineage of Code: Location of Source Code: Point of Contact: ************************************************************ --Boundary-16782935-0-0-- Received: from relay.tis.com by neptune.TIS.COM id aa18636; 21 Feb 96 21:19 EST Received: by relay.tis.com; id VAA22507; Wed, 21 Feb 1996 21:10:24 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma022500; Wed, 21 Feb 96 21:09:56 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06460; Wed, 21 Feb 96 21:08:55 EST Received: by relay.tis.com; id VAA22491; Wed, 21 Feb 1996 21:09:54 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma022483; Wed, 21 Feb 96 21:09:45 -0500 Received: from servo.qualcomm.com by interlock.ans.net with SMTP id AA09262 (InterLock SMTP Gateway 3.0 for ); Wed, 21 Feb 1996 21:10:47 -0500 Received: (from karn@localhost) by servo.qualcomm.com (8.7.3/8.7.2/1.6) id SAA14877; Wed, 21 Feb 1996 18:10:45 -0800 (PST) Date: Wed, 21 Feb 1996 18:10:45 -0800 (PST) From: Phil Karn Message-Id: <199602220210.SAA14877@servo.qualcomm.com> To: ipsec@ans.net In-Reply-To: <4831.bsimpson@morningstar.com> Subject: Re: ICMP messages Sender: ipsec-request@neptune.tis.com Precedence: bulk ICMP is a real pain in the IPSEC context. I'm not sure we can really make all the cases work right, especially with tunnels. But I'm not sure this is even a problem. Because spurious ICMP messages are so easily generated in the Internet, and because you can't count on them being generated even when they're warranted, most hosts already treat them as purely advisory in nature. They are mostly counted and ignored except when a human wants to look at them while debugging a network path. In the context of IPSEC, ICMP messages are even more problematic when you consider that many are unsigned and could be easily faked. I'm a little uncomfortable even with Bill's otherwise elegant idea of a "security failure" ICMP message (re)triggering Photuris key exchange because of the possibility of an attacker generating spurious ICMP messages as a way to cause hosts to waste a lot of CPU time (re)doing public key algorithms. I'm afraid I don't have any real solutions here. Comments? Phil Received: from relay.tis.com by neptune.TIS.COM id aa20607; 22 Feb 96 0:14 EST Received: by relay.tis.com; id AAA23731; Thu, 22 Feb 1996 00:16:25 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma023726; Thu, 22 Feb 96 00:15:57 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10519; Thu, 22 Feb 96 00:14:56 EST Received: by relay.tis.com; id AAA23718; Thu, 22 Feb 1996 00:15:55 -0500 Received: from nsco.network.com(129.191.1.1) by relay.tis.com via smap (V3.1) id xma023712; Thu, 22 Feb 96 00:15:45 -0500 Received: from by nsco.network.com (4.1/1.34) id AB04228; Wed, 21 Feb 96 23:19:42 CST Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 Feb 1996 00:18:15 -0500 To: ipsec@TIS.COM From: "James P. Hughes" Subject: draft-ietf-ipsec-esp-des-md5-00.txt Sender: ipsec-request@neptune.tis.com Precedence: bulk For your consideration. jim 8<------------------------------------------------------------------>8 Security Working Group J. Hughes Request for Comments: DRAFT Network Systems Corp. February 1996 Combined DES-CBC, MD5 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 author. 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, authentication, integrity and optional replay prevention into a single packet format. This draft extends rfc1829. Discussion This draft allows a combination of MD5 and DES-CBC. The goal is to ensure that the packet is authentic, can not be modified in transit, or replayed. Replay is optional. The inclusion of the replay field is negotiated as a part of the key exchange. Hughes FORMFEED[Page 1] RFC DRAFT February 1987 The combinations of trasformations are summarized below. DES-CBC MD5 Replay RFC1829(ESP) Yes No No RFC1828(AH) No Yes No This Draft Yes Yes No This Draft Yes Yes Yes Packet Format The only difference from rfc1829 is s the inclusion of a MD5 residual and an optional replay field. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Initialization Vector (IV) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- --- | | ^ ^ ~ Payload Data ~ | | | | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Padding (0-7 bytes) | MD5 | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Pad Length | Payload Type | | DES- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CBC | | | | + Replay Prevention Field (optional) + | | | | v | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- | | | | + MD5 Residual + | | | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- Replay Prevention Replay prevention field is a 64 bit value that is used to make sure that a previous packet can not be sent again and be accepted as valid traffic. Hughes FORMFEED[Page 2] RFC DRAFT February 1987 The format of the replay field is two 32 bit fields. The first 32 bits is a session specific nonce. This value will be constant for the entire time that this key is in use. If both directions use the same encryption key, each directions shall use a different nonce. For example, the nonce can be the time of day that this session was established. This field is negotiated as a part of the key exchange. The second 32 bits is a simple binary up counter. The replay prevention is provided by making sure that the nonce is correct and that the counter is going up. 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. (Rfc1829 recommends changing the keys at least this often.) Note: It is possible to use the "incrementing IV" method discussed in rfc1829, but there are 2 problems. First, the "incrementing IV" method discussed in rfc1829 does not cover sending a packet which is recorded in one direction in the other direction (if both directions are using the same key). Second, the "incrementing IV" method described in rfc1829 is not checked for integrity. Changes in the IV will show through in the first block of the plaintext and may or may not be detected by the host once the packets are decrypted. MD5 Residual The MD5 residual is a 128 bit MD5 (rfc1321) of the payload, padding, pad length, payload type and optional replay field. Note that the length of the area that the MD5 covers is a multiple of 64 bits. Note: This MD5 is not keyed nor includes any header nor other information than is specified here. Security Considerations The claims of privacy, integrity, authentication, and optional replay prevention are made in this draft. Privacy is provided by DES-CBC. (This could actually be performed by any 64 bit block algorithm in CBC mode.) See the discussion of DES- CBC in rfc1829. Hughes FORMFEED[Page 3] RFC DRAFT February 1987 Integrity is provided by the combination of DES and MD5. Since the MD5 residual is under the DES transformation, the packet can not be changed in a reliable way that will not be detected by MD5. Authentication is provided since only the source and destination know the DES key. Since the MD5 is under the DES transformation, it can not be checked until after the packet is decrypted. If the MD5 is correct, it proves that it must have been encrypted by the source, since only the source knows the key. (If an evesdropper knows the keys, all bets are off anyway..) Replay prevention is provided by the combination of a constantly increasing count with a nonce, and the replay field is covered by MD5 and MD5 is transformed by DES. Author's Address: James P. Hughes Network Systems Corporation Brooklyn Park, MN hughes@network.com http://www.network.com/~hughes Hughes FORMFEED[Page 4] -------------- HTTP://WWW.Network.com/~hughes Received: from relay.tis.com by neptune.TIS.COM id aa21405; 22 Feb 96 1:24 EST Received: by relay.tis.com; id BAA24184; Thu, 22 Feb 1996 01:25:55 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma024177; Thu, 22 Feb 96 01:25:27 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA11840; Thu, 22 Feb 96 01:24:26 EST Received: by relay.tis.com; id BAA24169; Thu, 22 Feb 1996 01:25:25 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma024163; Thu, 22 Feb 96 01:25:19 -0500 Received: from ietf.cnri.reston.va.us by interlock.ans.net with SMTP id AA13790 (InterLock SMTP Gateway 3.0 for ); Thu, 22 Feb 1996 01:26:22 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa17143; 21 Feb 96 9:44 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: ipsec@ans.net From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-ipsec-oakley-00.txt Date: Wed, 21 Feb 96 09:44:33 -0500 Message-Id: <9602210944.aa17143@IETF.CNRI.Reston.VA.US> Sender: ipsec-request@neptune.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Oakley Key Determination Protocol Author(s) : H. Orman Filename : draft-ietf-ipsec-oakley-00.txt Pages : 31 Date : 02/20/1996 This document describes a protocol, named OAKLEY, by which two authenticated parties can agree on secure and secret keying material. The basic mechanism is the Diffie-Hellman key exchange algorithm. This protocol supports Perfect Forward Secrecy, compatibility with the ISAKMP protocol for managing security associations, user-defined abstract group structures for use with the Diffie-Hellman algorithm, key updates, and incorporation of keys distributed via out-of-band mechanisms. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-oakley-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-oakley-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 (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-oakley-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: <19960220154420.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-oakley-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-oakley-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960220154420.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- Received: from relay.tis.com by neptune.TIS.COM id aa27770; 22 Feb 96 8:47 EST Received: by relay.tis.com; id IAA28358; Thu, 22 Feb 1996 08:49:04 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma028348; Thu, 22 Feb 96 08:48:31 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22752; Thu, 22 Feb 96 08:47:30 EST Received: by relay.tis.com; id IAA28345; Thu, 22 Feb 1996 08:48:30 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma028332; Thu, 22 Feb 96 08:48:15 -0500 Received: from ns.newbridge.com by interlock.ans.net with SMTP id AA18759 (InterLock SMTP Gateway 3.0 for ); Thu, 22 Feb 1996 08:49:12 -0500 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id IAA23169 for ; Thu, 22 Feb 1996 08:49:11 -0500 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma023134; Thu Feb 22 08:48:50 1996 Received: from tsntsrv1.timestep.com (tsntsrv1.timestep.com [138.120.156.80]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with ESMTP id IAA18349 for ; Thu, 22 Feb 1996 08:48:50 -0500 Received: from Microsoft Mail (PU Serial #1121) by tsntsrv1.timestep.com (PostalUnion/SMTP(tm) v2.1.8d for Windows NT(tm)) id AA-1996Feb22.082500.1121.20882; Thu, 22 Feb 1996 08:49:19 -0500 From: Stephane Lacelle To: 'ipsec' Message-Id: <1996Feb22.082500.1121.20882@tsntsrv1.timestep.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Organization: TimeStep Corporation Date: Thu, 22 Feb 1996 08:49:19 -0500 Subject: Re: IPSEC Implementation Survey Sender: ipsec-request@neptune.tis.com Precedence: bulk TimeStep Corp. implementation successfully interoperated with Raptor and SCC at RSA Conference. ************************************************************ IPSEC Implementation Survey Name of Implementation: TimeStep PERMIT Security Protocols: ESP, AH, proprietary Security Transforms: ESP-DES Key Management: proprietary, manual Lineage of Code: from scratch Location of Source Code: proprietary Point of Contact: Stephane Lacelle ************************************************************ --- stephane Received: from relay.tis.com by neptune.TIS.COM id aa28698; 22 Feb 96 9:31 EST Received: by relay.tis.com; id JAA29724; Thu, 22 Feb 1996 09:33:29 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma029720; Thu, 22 Feb 96 09:33:01 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25365; Thu, 22 Feb 96 09:31:59 EST Received: by relay.tis.com; id JAA29708; Thu, 22 Feb 1996 09:32:59 -0500 Received: from charrua.bellcore.com(192.4.6.118) by relay.tis.com via smap (V3.1) id xma029694; Thu, 22 Feb 96 09:32:37 -0500 Received: (from afa@localhost) by charrua.bellcore.com (8.6.9/8.6.10) id JAA00572; Thu, 22 Feb 1996 09:33:16 -0500 Date: Thu, 22 Feb 1996 09:33:15 -0500 (EST) From: Antonio Fernandez X-Sender: afa@charrua To: "PALAMBER.US.ORACLE.COM" Cc: ipsec@TIS.COM, Antonio Fernandez , Milton Anderson , Clyde L Monma Subject: Re: IPSEC Implementation Survey In-Reply-To: <199602212237.OAA21701@mailsun2.us.oracle.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipsec-request@neptune.tis.com Precedence: bulk > ************************************************************ > IPSEC Implementation Survey > > > Name of Implementation: > Security Protocols: > Security Transforms: > Key Management: > Location of Source Code: > Point of Contact: > ************************************************************ Received: from relay.tis.com by neptune.TIS.COM id aa00472; 22 Feb 96 11:02 EST Received: by relay.tis.com; id LAA02313; Thu, 22 Feb 1996 11:04:38 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma002302; Thu, 22 Feb 96 11:04:09 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01444; Thu, 22 Feb 96 11:03:08 EST Received: by relay.tis.com; id LAA02297; Thu, 22 Feb 1996 11:04:08 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma002293; Thu, 22 Feb 96 11:04:04 -0500 Received: from ietf.cnri.reston.va.us by interlock.ans.net with SMTP id AA21398 (InterLock SMTP Gateway 3.0 for ); Thu, 22 Feb 1996 11:05:02 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa20189; 22 Feb 96 9:24 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: ipsec@ans.net From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-ipsec-skip-pfs-00.txt Date: Thu, 22 Feb 96 09:24:41 -0500 Message-Id: <9602220924.aa20189@IETF.CNRI.Reston.VA.US> Sender: ipsec-request@neptune.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : SKIP extension for Perfect Forward Secrecy (PFS) Author(s) : A. Aziz Filename : draft-ietf-ipsec-skip-pfs-00.txt Pages : 11 Date : 02/21/1996 This document describes an optional extension specifying how to use an ephemeral Diffie-Hellman exchange in conjunction with the SKIP protocol in order to provide perfect forward secrecy for situations where forward secrecy is necessary. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-skip-pfs-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-pfs-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 (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-skip-pfs-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: <19960221161154.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-skip-pfs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-skip-pfs-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960221161154.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- Received: from relay.tis.com by neptune.TIS.COM id aa04851; 22 Feb 96 14:41 EST Received: by relay.tis.com; id OAA07802; Thu, 22 Feb 1996 14:43:05 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma007791; Thu, 22 Feb 96 14:42:40 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA12903; Thu, 22 Feb 96 14:41:35 EST Received: by relay.tis.com; id OAA07786; Thu, 22 Feb 1996 14:42:35 -0500 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1) id xma007778; Thu, 22 Feb 96 14:42:21 -0500 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id LAA22964; Thu, 22 Feb 1996 11:43:20 -0800 Received: by mailsun2.us.oracle.com (8.7.1/37.8) id LAA18576; Thu, 22 Feb 1996 11:45:27 -0800 (PST) Message-Id: <199602221945.LAA18576@mailsun2.us.oracle.com> Date: 22 Feb 96 11:38:07 -0800 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: IPSEC Draft Agenda at IETF 35 Mime-Version: 1.0 Sender: ipsec-request@neptune.tis.com Precedence: bulk DRAFT Agenda of the IPSEC Working Group Thirty-Fifth IETF as of 2/22/96 (March 4-5, 1996) MONDAY, March 4, 1996 1930-2200 IP Security Protocol WG 19:30 Introductions - brief background - work items - liaisons ESP/AH ------ 19:45 RSVP & IPsec presentation, Lou Berger (BBN) 20:05 ESP/AH Implementation summary, Ran (cisco) 20:20 ESP transform for DES-CBC, unkeyed MD5, & replay protection, Jim Hughes (Network Systems) Key Management ------ 20:45 Status and Progrssion of ISAKMP/SKIP/Photuris, Paul (Oracle) 21:00 Patent Status Update, Paul (Oracle) 21:15 ISAKMP update, Mark Schertler (US DoD) 21:55 Summary and Action Items 22:00 Adjourn TUESDAY, March 5, 1996 0900-1130 IP Security Protocol WG 9:00 Introductions - brief review of 3/4/96 meeting and work items 9:15 Oakley Key Exchange, Hilarie Orman (Univ. of Arizona) 10:05 SKIP and extensions for PFS, Ashar Aziz (Sun) 10:45 Photuris update, Phil Karn (Qualcomm) 11:25 Summary and Action Items 11:30 Adjourn Received: from relay.tis.com by neptune.TIS.COM id aa05726; 22 Feb 96 15:27 EST Received: by relay.tis.com; id PAA09111; Thu, 22 Feb 1996 15:29:06 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma009107; Thu, 22 Feb 96 15:28:38 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16455; Thu, 22 Feb 96 15:27:36 EST Received: by relay.tis.com; id PAA09102; Thu, 22 Feb 1996 15:28:36 -0500 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1) id xma009091; Thu, 22 Feb 96 15:28:10 -0500 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id MAA00276; Thu, 22 Feb 1996 12:29:13 -0800 Date: Thu, 22 Feb 1996 12:29:13 -0800 From: Ran Atkinson Message-Id: <199602222029.MAA00276@puli.cisco.com> To: ipsec@TIS.COM Subject: Regarding Bill's draft Sender: ipsec-request@neptune.tis.com Precedence: bulk All, I've been gone out of town taking care of family matters and have just now resurfaced and caught up on email/lists. Several folks have asked for detailed discussion on the problems with Bill's draft. Those folks apparently are new subscribers to the IPsec list because the technical problems have been discussed at some length over the course of the past year. From where I sit, the main problem is that Bill refuses to edit his draft in conformance with RFC-1825 and Working Group consensus (he made a public refusal to make needed changes last November in a posting to the IPsec list, for example). Now I'll try to rehash some of the highlights for newcomers to this list. 1) There is a well-known attack possible by one user on a multi-user system against another user on the same multi-user system. This has been described in the past at length and is often called the "mutually suspicious users" problem. This was discussed at length, most recently during the Fall of 1995 on the IPsec list. Bill's draft does not have language on this topic that is consistent with the WG consensus, as I noted in a message to the IPsec list on 9 Nov 1995 entitled "naming and terminology". Bill explicitly refused to make the change and his draft continues to be broken in this area. One possible fix would be to rephrase part of Section 1.8 of Bill's draft to replace the text reading "When required for secure multi-user environments, ..." with "On multi-user systems,..." or "On multi-user systems having discretionary access controls (DAC), ..." AND replace the text reading "Each secure multi-user operating system MUST..." with "Each multi-user operating system SHOULD...". Implementation support for user-oriented keying on "multi-user systems" is specified by RFC-1825 in section 4.6 paragraph 5. Additionally, the "Design Notes" of Section 1.8 need to be deleted. NRL's implementation is an existence proof that support for user- oriented keying does NOT require significant changes to an OS or its APIs, contrary to Bill's incorrect assertion. Please note that this item has NOTHING to do with "multi-level security". 2) The draft incorrectly and unreasonably constrains the security policies that users may have. In section 2.5.1, Bill requires that authentication policy may only be determined by the receiver when in fact this is not a useful or necessary restriction (as has been discussed on the IPsec list in the past). The NRL implementation is again a counter-example to Bill's incorrect assertion in that it permits sender or receiver to each set their own policies on authentication. The same problem occurs in section 2.5.2 where Bill asserts that encryption policy is a sender decision. This is not a useful or necessary restriction either. In particular, experiments at NRL using the NRL implementation demonstrated that the receiver can require the sender to use encryption for a session (e.g. telnet or ftp sessions where the TCP session will never become established). Again, these were both discussed on the list in some detail and so this is not a new problem with Bill's draft. To fix this problem, Bill needs to remove the language in his draft that restricts the security policies that users can have. 3) Bill's draft does not fully conform with Section 1.4 of RFC-1825. To conform, the following changes need to be made: - The text in draft-ietf-ipsec-photuris-ext-01.txt, Section 2.7 needs to be detailed sufficiently that 2 independent implementers could create interoperable implementations that successfully pass the Sensitivity Label between them. A sufficient approach would be to define the label values and semantics for the US DoD levels specified in RFC-1108, reserve most label values to IANA for future allocation, and reserve a small number of label values for private use amongst consenting parties. - The sensitivity label option needs to be moved into the main draft-ietf-ipsec-photuris-*.txt draft because it is a standard component of an IPsec Security Association. This isn't hard and I've told this to Bill in the past, but he hasn't yet made the changes and in the past has specifically refused to change and fix this on grounds that he personally doesn't believe in Sensitivity Labels. For newcomers, I'll note that sensitivity labels aren't really a military-unique feature. For example, GE has a multi-level security policy (Class I information is "all GE employees, but no outsiders" while Class II information is more restricted, for example). 4) The DNS-SIG option should be detailed with both syntax and semantics. DNS Security is about to move to Proposed Standard and the DNS is likely to be a primary near-term way for hosts to obtain each others' certificates. The DNS Security spec is plenty stable for Bill to finish this item now. 5) Section 2.11 of draft-ietf-ipsec-photuris-ext-01.txt MUST be deleted. It is WAY outside the scope of Bill's draft to modify any standards track protocol and the attempt to do so is more than sufficient grounds to bar publication as ANY kind of RFC until that section is deleted. 6) Please also see Bill Sommerfeld's note to the IPsec list with a subject of "Re: IPsec mailing list", date of 9 Oct 1995 16:57:19 and his note subject "Re: Security Problems in Photuris #2" dated 12 Oct 1995 15:25:28 and the note from Ron Rivest with subject "Photuris terminology" dated 12 Oct 1995 19:54:57 for other unresolved technical problems (generally all of those notes suggest easy simple changes to fix the problems). In summary, the main obstacle to progress is Bill's unwillingness to work with the standards process and edit in accordance with WG consensus, existing standards-track protocols, and the WG requirements. If the draft should move to WG Last Call in the future, I would not be surprised if additional technical issues resurfaced or appeared new. Ran rja@cisco.com Received: from relay.tis.com by neptune.TIS.COM id aa06882; 22 Feb 96 16:17 EST Received: by relay.tis.com; id QAA10712; Thu, 22 Feb 1996 16:19:30 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma010692; Thu, 22 Feb 96 16:19:00 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20935; Thu, 22 Feb 96 16:17:58 EST Received: by relay.tis.com; id QAA10685; Thu, 22 Feb 1996 16:18:58 -0500 Received: from ilback.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma010673; Thu, 22 Feb 96 16:18:39 -0500 Received: from ietf.cnri.reston.va.us by interlock.ans.net with SMTP id AA26034 (InterLock SMTP Gateway 3.0 for ); Thu, 22 Feb 1996 16:19:40 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa24654; 22 Feb 96 9:46 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: ipsec@ans.net From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-ipsec-isakmp-04.txt, .ps Date: Thu, 22 Feb 96 09:46:53 -0500 Message-Id: <9602220946.aa24654@IETF.CNRI.Reston.VA.US> Sender: ipsec-request@neptune.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Internet Security Association and Key Management Protocol (ISAKMP) Author(s) : D. Maughan, M. Schertler Filename : draft-ietf-ipsec-isakmp-04.txt, .ps Pages : 59 Date : 02/21/1996 This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and cryptographic keys in an Internet environment. A Security Association protocol that negotiates, establishes, modifies and deletes Security Associations and their attributes is required for an evolving Internet, where there will be numerous security mechanisms and several options for each security mechanism. The key management protocol must be robust in order to handle public key generation for the Internet community at large and private key requirements for those private networks with that requirement. The Internet Security Association and Key Management Protocol (ISAKMP) defines the procedures for authenticating a communicating peer, creation and management of Security Associations, key generation techniques, and threat mitigation (e.g. denial of service and replay attacks). All of these are necessary to establish and maintain secure communications (via IP Security Service or any other security protocol) in an Internet environment. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-isakmp-04.txt". Or "get draft-ietf-ipsec-isakmp-04.ps". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-04.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 (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-04.txt". Or "FILE /internet-drafts/draft-ietf-ipsec-isakmp-04.ps". 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: <19960222094519.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960222094519.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- Received: from relay.tis.com by neptune.TIS.COM id aa08563; 22 Feb 96 18:10 EST Received: by relay.tis.com; id SAA13592; Thu, 22 Feb 1996 18:11:42 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma013587; Thu, 22 Feb 96 18:11:13 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA26151; Thu, 22 Feb 96 18:10:12 EST Received: by relay.tis.com; id SAA13584; Thu, 22 Feb 1996 18:11:12 -0500 Received: from unknown(15.255.152.2) by relay.tis.com via smap (V3.1) id xma013582; Thu, 22 Feb 96 18:11:08 -0500 Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA215080718; Thu, 22 Feb 1996 15:11:59 -0800 Message-Id: <199602222311.AA215080718@relay.hp.com> Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com id AA163040872; Thu, 22 Feb 1996 18:14:32 -0500 X-Mailer: exmh version 1.6.2 7/18/95 To: ipsec@TIS.COM Subject: Re: Regarding Bill's draft... another Bill's open issues with photuris Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 22 Feb 1996 18:11:57 -0500 From: Bill Sommerfeld Sender: ipsec-request@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii Here's a follow up on the issues which I raised earlier which Ran suggested might not have been addressed. Please also see Bill Sommerfeld's note to the IPsec list with a subject of "Re: IPsec mailing list", date of 9 Oct 1995 16:57:19 The crucial part of this (the possibility of using change_message to replay the creation of an SPI which was previously deleted) has been resolved. I would, however, like to see some text in the draft regarding ways to prevent SPI's from significantly outlasting the shared secret initially used to create them. I'd prefer to see text requiring the SPI to die when the shared secret used to create it expires, but could live with something more liberal.. The sender should stop using the SPI immediately when it expires. The receiver should allow a grace period of on the order of a minute or two to allow for slews in real-time clock frequency between the systems and to allow any packets in flight to be received. and his note subject "Re: Security Problems in Photuris #2" dated 12 Oct 1995 15:25:28 and the note from Ron Rivest with subject "Photuris terminology" dated 12 Oct 1995 19:54:57 for other unresolved technical problems (generally all of those notes suggest easy simple changes to fix the problems). The 12 Oct message raises some more important issues. As best I can tell, a number of places in photuris-09.txt require the use of the now-known-to-be-vulnerable hash(key | data | key) structure for implementing a keyed MAC. I'd like to echo Hugo's request to make a change to Photuris to replace all occurances of hash (concat(key, data, key)) with keyed_hash(key, data) There are a bunch of places where hash(key, data, key) is used: - section 5.4 privacy method key generation. - section 5.5 identity verification - section 5.6 session key computation - section 6.1.7 integrity verification on change_message The way it's used in the change_message appears to me as if it might allow the keyed hash to become a target for chosen-plaintext attacks. I think the other uses are less of a risk, but then I'm not really a cryptographer. Recommended high-level changes: 1) Redefine the following hash algorithm families as keyed hashes: validity-method identity-choice privacy-method key generation SPI session key generation 2) define the key used for validity-method, privacy-method keygen, and SPI session keygen as the shared-secret 3) define the key used for the identity-choice algorithm as the shared secret, concatenated or otherwise combined with the authentication secret-key if there was one. I believe that this could be done in a way which preserves interoperability with existing implemenations of Photuris if this is a concern. I believe these answer Hugo's original objection, but naturally I'd like to see a "real cryptographer" review these, especially #3. These perhaps go further than is strictly necessary (perhaps only the validity-message change is really needed to avoid "bare" use of key|data|key, but I think we should be conservative with how we use the cryptographic primitives..) - Bill -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMSz4NFpj/0M1dMJ/AQHY0wP8Durc4LS8/d2ylEVEHWBXr8BCZvR0Yazj EQcXWLz7oJ9BS6bur0f0cSW/AhxQ7tbbojeHqZgLIdEivAVzazZ8MGYnugDSXaUB rHXxWnyt3JhEOhE8m7rgqyyqfDawV4VU9eTEuzoOw/bu0lMiWB6HYg5qqsg7zgn6 Hwdej8cJafU= =vNgI -----END PGP SIGNATURE----- Received: from relay.tis.com by neptune.TIS.COM id aa09319; 22 Feb 96 19:04 EST Received: by relay.tis.com; id TAA14030; Thu, 22 Feb 1996 19:06:12 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma014024; Thu, 22 Feb 96 19:05:43 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27584; Thu, 22 Feb 96 19:04:42 EST Received: by relay.tis.com; id TAA14021; Thu, 22 Feb 1996 19:05:42 -0500 Received: from ilback.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma014017; Thu, 22 Feb 96 19:05:18 -0500 Received: from venera.isi.edu by interlock.ans.net with SMTP id AA27732 (InterLock SMTP Gateway 3.0 for ); Thu, 22 Feb 1996 19:06:20 -0500 Received: from egy.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 22 Feb 1996 16:06:16 -0800 Posted-Date: Thu, 22 Feb 96 16:03:07 PST Received: by egy.isi.edu (5.65c/4.0.3-4) id ; Thu, 22 Feb 1996 16:03:07 -0800 Date: Thu, 22 Feb 96 16:03:07 PST From: Avneesh Sachdev To: ipsec@ans.net Cc: asachdev@isi.edu Subject: IPSEC Implementation Service Message-Id: Sender: ipsec-request@neptune.tis.com Precedence: bulk ------------------------------------------- IPSEC Implementation Survey Name of Implementation: USC/ISI Security Protocols: IPv4 AH Security Transforms: null, Internet checksum, MD5, proprietary null and Internet checksum for performance measurement Key Management: Statically configured keys implementation for performance measurement only Lineage of Code: SunOS 4.1.3, using "from scratch" and code adapted from the NRL IPv6 BSDI implementation Location of Source Code: to be announced in March Point of Contact: Joe Touch (touch@isi.edu) ------------------------------------------- Received: from relay.tis.com by neptune.TIS.COM id aa12927; 23 Feb 96 0:48 EST Received: by relay.tis.com; id AAA16695; Fri, 23 Feb 1996 00:50:08 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma016693; Fri, 23 Feb 96 00:49:40 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA04466; Fri, 23 Feb 96 00:48:38 EST Received: by relay.tis.com; id AAA16690; Fri, 23 Feb 1996 00:49:38 -0500 Received: from merit.edu(35.1.1.42) by relay.tis.com via smap (V3.1) id xma016688; Fri, 23 Feb 96 00:49:33 -0500 Received: from Bill.Simpson.DialUp.Mich.Net (pm001-01.dialip.mich.net [35.1.48.50]) by merit.edu (8.7.3/merit-2.0) with SMTP id AAA06296 for ; Fri, 23 Feb 1996 00:50:32 -0500 (EST) Date: Fri, 23 Feb 96 05:20:11 GMT From: William Allen Simpson Message-Id: <4932.bsimpson@morningstar.com> To: ipsec@TIS.COM Subject: Re: Regarding Bill's draft Sender: ipsec-request@neptune.tis.com Precedence: bulk Ah, thank you, finally something solid that I can actually refute! > From: Ran Atkinson > Now I'll try to rehash some of the highlights > for newcomers to this list. > Gosh, Ran, start right off by insulting most of the posters in the past 2 weeks. 2 implementors, and several others who have been active in this group for over 2 years! I saw only 1 new name.... In brief, it is apparent that the chairs haven't read any draft in the past 5 months, let alone the most recent. Most of the "issues" raised here (#1, #2, and three in #6) were addressed as soon as they were raised. In the #6 cases, as long ago as last October!!! Since I am about to go to bed and cannot write such a long message now, I will handle individual points in later messages. However, I can quickly dispense with a few: > 3) Bill's draft does not fully conform with Section 1.4 of RFC-1825. > > To conform, the following changes need to be made: > - The text in draft-ietf-ipsec-photuris-ext-01.txt, Section 2.7 > > 4) The DNS-SIG option should be detailed with both syntax and semantics. > > 5) Section 2.11 of draft-ietf-ipsec-photuris-ext-01.txt MUST be deleted. All of these are in the Extensions draft. That draft is not germane to the "last call". It is not finished. It contains those items which as clearly indicated ARE _NOT_ REQUIRED in every implementation. In fact, nobody could agree on even the format of these things, such as Security Labels, DNS-SIG, or the AH_Sequence. There are ongoing WGs which are deciding these items, and the Extensions will be published when they are resolved. So, let's stick with the actual Photuris draft, which has the required to implement base protocol. > In summary, the main obstacle to progress is Bill's unwillingness to > work with the standards process and edit in accordance with WG consensus, > existing standards-track protocols, and the WG requirements. > This is unmitigated hogwash!!! I have made 10 drafts in the past year, with several significant improvements and dozens of editorial changes. Some folks (including my cohort Phil) have complained that there are _too_ many options from conforming to "WG consensus". At least one of the comments stated: "we are happy with the way the Photuris design team has addressed those weaknesses pointed to them." Seems to me that not only have you not read the drafts, but you are completely out of touch with the WG! Bill.Simpson@um.cc.umich.edu 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 aa14611; 23 Feb 96 3:23 EST Received: by relay.tis.com; id DAA18169; Fri, 23 Feb 1996 03:25:00 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma018167; Fri, 23 Feb 96 03:24:31 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA07674; Fri, 23 Feb 96 03:23:29 EST Received: by relay.tis.com; id DAA18164; Fri, 23 Feb 1996 03:24:30 -0500 Received: from interlock.ans.net(147.225.5.5) by relay.tis.com via smap (V3.1) id xma018162; Fri, 23 Feb 96 03:24:13 -0500 Received: by interlock id AA23607 (InterLock SMTP Gateway 3.0 for ipsec@ans.net); Fri, 23 Feb 1996 03:24:56 -0500 Received: by interlock (Protected-side Proxy Mail Agent-2); Fri, 23 Feb 1996 03:24:56 -0500 Received: by interlock (Protected-side Proxy Mail Agent-1); Fri, 23 Feb 1996 03:24:56 -0500 Message-Id: <199602230821.KAA11093@del.tla.org> X-Mailer: exmh version 1.6.2 7/18/95 To: ipsec@ans.net Subject: IPsec Implementation Survey: JI Reply-To: ji@hol.gr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Feb 1996 10:21:49 +0200 From: John Ioannidis Sender: ipsec-request@neptune.tis.com Precedence: bulk ------------------------------------------ IPSEC Implementation Survey Name of Implementation: JI Security Protocols: ESP, AH, Protocol-4 encapsultation Security Transforms: ESP-DES, AH-MD5 Key Management: manual, Photuris; PF_ENCAP keying i/f, PF_ROUTE extensionsl Lineage of Code: Written from scratch, entirely in Greece, for BSD/OS 2.0, Location of Source Code: ji's home machine The promised end-January-96 release is not ready yet; it should be (freely) available from ftp.ripe.net RSN. Point of Contact: ji@hol.gr ------------------------------------------ Received: from relay.tis.com by neptune.TIS.COM id aa20408; 23 Feb 96 9:45 EST Received: by relay.tis.com; id JAA22223; Fri, 23 Feb 1996 09:46:54 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma022216; Fri, 23 Feb 96 09:46:25 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19151; Fri, 23 Feb 96 09:45:23 EST Received: by relay.tis.com; id JAA22213; Fri, 23 Feb 1996 09:46:24 -0500 Received: from merit.edu(35.1.1.42) by relay.tis.com via smap (V3.1) id xma022211; Fri, 23 Feb 96 09:46:23 -0500 Received: from Bill.Simpson.DialUp.Mich.Net (pm002-04.dialip.mich.net [141.211.7.140]) by merit.edu (8.7.3/merit-2.0) with SMTP id JAA17193 for ; Fri, 23 Feb 1996 09:47:25 -0500 (EST) Date: Fri, 23 Feb 96 14:38:34 GMT From: William Allen Simpson Message-Id: <4934.bsimpson@morningstar.com> To: ipsec@TIS.COM Subject: Re: IPSEC Draft Agenda at IETF 35 Sender: ipsec-request@neptune.tis.com Precedence: bulk Your agenda seems to be missing 2 drafts, one of which was submitted before the last IETF and still has not been granted agenda time, yet has time for drafts which have not yet appeared. Please add 20 minutes each for: ICMP Security Failures The ESP DES-CBC plus MD5 Transform > 20:05 ESP/AH Implementation summary, Ran (cisco) Also, during or after the implementation summary, I would like to describe current review of the RFC-1828 & 1829 security analysis. Shouldn't take more than 5 minutes. Bill.Simpson@um.cc.umich.edu 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 aa21946; 23 Feb 96 11:04 EST Received: by relay.tis.com; id LAA23978; Fri, 23 Feb 1996 11:06:26 -0500 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 xma023973; Fri, 23 Feb 96 11:05:59 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25648; Fri, 23 Feb 96 11:04:56 EST Received: by relay.tis.com; id LAA23963; Fri, 23 Feb 1996 11:05:56 -0500 Received: from watson.ibm.com(129.34.139.4) by relay.tis.com via smap (V3.1) id xma023949; Fri, 23 Feb 96 11:05:26 -0500 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 0237; Thu, 22 Feb 96 10:00:59 EST Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.02 on VAGENT2" id 7215; Thu, 22 Feb 1996 10:00:59 EST Received: from secpwr.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2Rx) with TCP; Thu, 22 Feb 96 10:00:58 EST Received: by secpwr.watson.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA14784; Thu, 22 Feb 1996 10:03:45 -0500 Date: Thu, 22 Feb 1996 10:03:45 -0500 Message-Id: <9602221503.AA14784@secpwr.watson.ibm.com> To: ipsec@TIS.COM Subject: Re: IPSEC Implementation Survey Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: xEZvzjmJZ+ZYe+MLFsNI9w== Sender: ipsec-request@neptune.tis.com Precedence: bulk > From: "PALAMBER.US.ORACLE.COM" > To: ipsec@TIS.COM > Subject: IPSEC Implementation Survey > Cc: PALAMBER@us.oracle.com > Mime-Version: 1.0 > Sender: ipsec-request@neptune.tis.com > Precedence: bulk > Content-Length: 1004 > Status: RO > > > > I have received several requests for the location of source code for ipsec > implementations. Our working group also needs to coordinate interoperability > testing among ourselves. To this end, would ipsec implementors please fill > out the following survey and post your completed survey to the ipsec mailing > list. > > > Thanks in advance, > > Paul A. Lambert > ipsec co-chair > ************************************************************ IPSEC Implementation Survey Name of Implementation: IBM Security Protocols: ESP, AH, both tunnel and transport mode Security Transforms: ESP-DES (32-bit and 64-bit IV), keyed-MD5, new keyed-MD5 proposed by Hugo Key Management : , SKEME (in progress), Photuris (in Progress) Lineage of Code: IBM Proprietary, about 10k to 15K lines (rough estimate, including ESP, AH, and Key Management). Location of Source Code: Proprietary Point of Contact: pau@yktvmv.vnet.ibm.com ************************************************************ Received: from relay.tis.com by neptune.TIS.COM id aa22575; 23 Feb 96 11:29 EST Received: by relay.tis.com; id LAA24418; Fri, 23 Feb 1996 11:31:26 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma024414; Fri, 23 Feb 96 11:30:58 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27606; Fri, 23 Feb 96 11:29:55 EST Received: by relay.tis.com; id LAA24411; Fri, 23 Feb 1996 11:30:56 -0500 Received: from merit.edu(35.1.1.42) by relay.tis.com via smap (V3.1) id xma024407; Fri, 23 Feb 96 11:30:39 -0500 Received: from Bill.Simpson.DialUp.Mich.Net (pm036-20.dialip.mich.net [141.211.7.62]) by merit.edu (8.7.3/merit-2.0) with SMTP id LAA20274 for ; Fri, 23 Feb 1996 11:31:38 -0500 (EST) Date: Fri, 23 Feb 96 15:03:59 GMT From: William Allen Simpson Message-Id: <4935.bsimpson@morningstar.com> To: ipsec@TIS.COM Subject: Re: Regarding Bill's draft... another Bill's open issues with photuris Sender: ipsec-request@neptune.tis.com Precedence: bulk > From: Bill Sommerfeld > Here's a follow up on the issues which I raised earlier which Ran > suggested might not have been addressed. > > Please also see Bill Sommerfeld's note to the IPsec list with > a subject of "Re: IPsec mailing list", date of 9 Oct 1995 > 16:57:19 > > The crucial part of this (the possibility of using change_message to > replay the creation of an SPI which was previously deleted) has been > resolved. > Thank you. As I remember, you had privately indicated this was solved last October (about 5 drafts ago). On to the new issues: > I would, however, like to see some text in the draft regarding ways to prevent > SPI's from significantly outlasting the shared secret initially used > to create them. I'd prefer to see text requiring the SPI to die when > the shared secret used to create it expires, but could live with > something more liberal.. > Actually, it is a fundamental "feature" of Photuris that the SPIs can last longer than the exchange value: When an Exchange-Value expires (or is replaced by a newer value), the unexpired derived SPIs are not affected. This is important to allow traffic to continue without interruption during new Photuris exchanges. Also, this feature allows Photuris to behave like SKIP (long-term stored SPIs for authentication lasting past reboot). Perhaps you should argue with someone else as to whether this latter facility is useful.... > The sender should stop using the SPI immediately when it expires. The > receiver should allow a grace period of on the order of a minute or > two to allow for slews in real-time clock frequency between the > systems and to allow any packets in flight to be received. > That's a bit harder to do, and sounds implementation dependent (as to both clock frequency and packet trip time). A minute seems rather long, especially when the LifeTime is in seconds. How is this particular to Photuris? Would that be more appropriate to the general architecture document discussing LifeTimes? Certainly, this isn't something you would like to see "negotiated"? An implementation note already exists as to hold time: To prevent resurrection of deleted or expired SPIs, implementations SHOULD remember those SPIs, but mark them as unusable until the Photuris exchange shared-secret used to create them also expires and purges the associated state. Perhaps you are asking for an implementation note that expands this need, such as: When an implementation detects an incoming SPI that has recently expired, but the associated state has not yet been purged, the implementation MAY accept the SPI. The length of time allowed is highly dependent on clock drift and variable packet round trip time, and is therefore implementation dependent. > and his note subject "Re: Security Problems in Photuris #2" dated > 12 Oct 1995 15:25:28 > And again, as already stated above, the suggestion that the "assumptions" about hashing funtions used as signatures be documented resulted in the inclusion of Bill's suggested text (4 drafts ago): The Verification method must not allow "message recovery", to prevent determination of the shared-secret or any long-term distributed secret-key (where applicable). More specifically, it should not be feasible to compute any of the bits of an authenticated message from the verification value. In general, where a secret (such as the shared-secret or session-keys) is involved in any calculation, the algorithms selected should not reveal information about the secret, either directly or indirectly. This was in the Security Consideration for several revisions, and has now been moved to the Security Analysis document. > As best I can tell, a number of places in photuris-09.txt require the > use of the now-known-to-be-vulnerable hash(key | data | key) structure for > implementing a keyed MAC. > ... > > There are a bunch of places where hash(key, data, key) is used: > - section 5.4 privacy method key generation. > - section 5.5 identity verification > - section 5.6 session key computation > - section 6.1.7 integrity verification on change_message > > The way it's used in the change_message appears to me as if it might > allow the keyed hash to become a target for chosen-plaintext attacks. > I think the other uses are less of a risk, but then I'm not really a > cryptographer. > The analysis is faulty. In both cases, the key is both prefixed and appended in order to provide additional key mixing over the potentially large amounts of data. That was a concern raised during earlier drafts, and the drafts were changed to meet that earlier review. There is no opportunity for an "appending attack" on these values. There could not possibly be an "attack" on the key generation. This creates a secret value, the key. An attack on the verification is both unlikely and impractical. This value is encrypted, and therefore also "secret" from an observer. See the Nov 17 paper by Preneel and van Oorschot: "Practical attacks often require that a forgery is _verifiable_ ... Verification of such an attack requires k/m text-MAC pairs." In this case, the MAC is unknown, and therefore not verifiable. More importantly, the attack requires a large number of different chosen-messages. Since it is not possible for an attacker to "choose" the parameters being verified, this attack is impossible. Most importantly, the attack requires an incredibly large number of known-messages, on the order of 2**65 or more! That makes it utterly impractical (also stated by the authors). > Recommended high-level changes: > 1) Redefine the following hash algorithm families as keyed hashes: > validity-method > identity-choice > privacy-method key generation > SPI session key generation > They already are. That is, a hash over the key. MD5 is used in the base document, but other hashes are possible for other Exchange-Schemes. (See Extensions draft for details.) > 2) define the key used for validity-method, privacy-method keygen, > and SPI session keygen as the shared-secret > This is a cryptographically unsound idea. Disclosure of the key for any one of these would disclose the shared-secret used to generate all the other keys. That would make it a serious target. Especially as it is so easy to determine the DES privacy key. The shared-secret is _never_ used directly. As stated: Photuris generation of session-keys involves a cryptographic hash over the shared-secret. The shared-secret is itself only indirectly used for creating those keys that actually protect session traffic. This protects the shared-secret from discovery, and allows repeated use of the shared-secret for generating multiple session-keys. Discovery of one such key should not reveal related session-keys. > 3) define the key used for the identity-choice algorithm as > the shared secret, concatenated or otherwise combined with the > authentication secret-key if there was one. > Again, an incredibly insecure idea. Bill.Simpson@um.cc.umich.edu 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 aa23573; 23 Feb 96 12:16 EST Received: by relay.tis.com; id MAA25020; Fri, 23 Feb 1996 12:17:56 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma025018; Fri, 23 Feb 96 12:17:28 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA00445; Fri, 23 Feb 96 12:16:25 EST Received: by relay.tis.com; id MAA25015; Fri, 23 Feb 1996 12:17:26 -0500 Received: from relay.hp.com(15.255.152.2) by relay.tis.com via smap (V3.1) id xma025013; Fri, 23 Feb 96 12:17:15 -0500 Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA151825891; Fri, 23 Feb 1996 09:18:13 -0800 Message-Id: <199602231718.AA151825891@relay.hp.com> Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com id AA219816048; Fri, 23 Feb 1996 12:20:49 -0500 X-Mailer: exmh version 1.6.2 7/18/95 To: William Allen Simpson Cc: ipsec@TIS.COM Subject: Re: Regarding Bill's draft... another Bill's open issues with photuris In-Reply-To: bsimpson's message of Fri, 23 Feb 1996 15:03:59 +0000. <4935.bsimpson@morningstar.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 23 Feb 1996 12:18:10 -0500 From: Bill Sommerfeld Sender: ipsec-request@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii More importantly, the attack requires a large number of different chosen-messages. Since it is not possible for an attacker to "choose" the parameters being verified, this attack is impossible. That's not at all clear to me. In particular, it seems that in a system using per-user or per-transport-connection SPI's, an active attacker could easily induce a system to create large numbers of SPI's with a third party, each having similar, but not identical parameters. Most importantly, the attack requires an incredibly large number of known-messages, on the order of 2**65 or more! That makes it utterly impractical (also stated by the authors). That's an upper-bound on the strength of this construction, not a lower bound. As an engineer, not a cryptographer, the existance of this weakness makes me suspicious of tying photuris so closely to hash(concat(key,data,key)) instead of a more flexible keyed_hash(key,data). > Recommended high-level changes: > 1) Redefine the following hash algorithm families as keyed hashes: > validity-method > identity-choice > privacy-method key generation > SPI session key generation > They already are. That is, a hash over the key. MD5 is used in the base document, but other hashes are possible for other Exchange-Schemes. (See Extensions draft for details.) I'm sorry, but a keyed hash and a hash over a key and some other data are *NOT* necessarily the same thing. Hash(concat(key,data,key)) is just one way to implement a keyed hash -- it's not necessarily the *best* way. Hugo's work suggests that hash(key1, hash(key2, data)) may be better, but there's no way to cleanly define photuris extensions which use that structure in the future if the base draft insists on the key,data,key form. > 2) define the key used for validity-method, privacy-method keygen, > and SPI session keygen as the shared-secret > This is a cryptographically unsound idea. Why? That's exactly what photuris is doing today! It's doing a keyed hash using the shared secret as the "key" and other fields as the "data". > 3) define the key used for the identity-choice algorithm as > the shared secret, concatenated or otherwise combined with the > authentication secret-key if there was one. > Again, an incredibly insecure idea. Again, this is exactly what photuris is doing today. It's doing a keyed hash using the shared secret as the "key" and other fields as the "data". - Bill -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMS32y1pj/0M1dMJ/AQFXkQP9HoFnI4wUlUnCQtaQLRFMv1lGn90ys6Kn pEeGX/UFkHF77TQomeXxFQ9fOVC4jYocWV0nTJR3R4Y0PM7hIektneApD96pDEW6 vwL2I6rFB1y5SCmjSVA0ATnlLs1I4TUgoM19dWgqp4bSqmsGJJNfkc50deCtTPBv 9ZAsPlHaM9c= =iK8b -----END PGP SIGNATURE----- Received: from relay.tis.com by neptune.TIS.COM id aa23748; 23 Feb 96 12:25 EST Received: by relay.tis.com; id MAA25120; Fri, 23 Feb 1996 12:27:27 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma025113; Fri, 23 Feb 96 12:26:58 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA00821; Fri, 23 Feb 96 12:25:56 EST Received: by relay.tis.com; id MAA25108; Fri, 23 Feb 1996 12:26:56 -0500 Received: from merit.edu(35.1.1.42) by relay.tis.com via smap (V3.1) id xma025104; Fri, 23 Feb 96 12:26:46 -0500 Received: from Bill.Simpson.DialUp.Mich.Net (pm036-11.dialip.mich.net [141.211.7.53]) by merit.edu (8.7.3/merit-2.0) with SMTP id MAA21792 for ; Fri, 23 Feb 1996 12:27:45 -0500 (EST) Date: Fri, 23 Feb 96 17:05:20 GMT From: William Allen Simpson Message-Id: <4937.bsimpson@morningstar.com> To: ipsec@TIS.COM Subject: Regarding ... #6 Sender: ipsec-request@neptune.tis.com Precedence: bulk A small note to cover the bases: > From: Ran Atkinson > 6) Please also see ... > the note from Ron Rivest with subject > "Photuris terminology" dated 12 Oct 1995 19:54:57 > Which read (excerpted): # ***************************************************************** # *** There is nothing in this notion of "signature" that means *** # *** that the message can not be derived from the signature. *** # ***************************************************************** # Indeed, I believe that the CCITT standards distinguish explicitly between # "signature schemes with message recovery" and "signature schemes without # message recovery". # ... # I would suggest adding language of the following form somewhere (such as # on the top of page 23): # # The Signature-Choice method must specify a signature method that # does not have "message recovery": it should not be feasible to # compute the message from the signature. # ... The language appeared in draft -05 on Oct 14! Cannot get much faster than that! Also, in response to other messages, the use of the term Signature was changed to Verification, of which a "signature" is only one example.... Bill.Simpson@um.cc.umich.edu 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 aa25005; 23 Feb 96 13:22 EST Received: by relay.tis.com; id NAA26059; Fri, 23 Feb 1996 13:23:57 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma026052; Fri, 23 Feb 96 13:23:28 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA04381; Fri, 23 Feb 96 13:22:26 EST Received: by relay.tis.com; id NAA26046; Fri, 23 Feb 1996 13:23:26 -0500 Received: from interlock.ans.net(147.225.5.5) by relay.tis.com via smap (V3.1) id xma026038; Fri, 23 Feb 96 13:23:06 -0500 Received: by interlock id AA03941 (InterLock SMTP Gateway 3.0 for ipsec@ans.net); Fri, 23 Feb 1996 13:24:08 -0500 Received: by interlock (Protected-side Proxy Mail Agent-1); Fri, 23 Feb 1996 13:24:08 -0500 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@ans.net From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-ipsec-icmp-fail-01.txt Date: Fri, 23 Feb 96 09:56:12 -0500 Message-Id: <9602230956.aa21798@IETF.CNRI.Reston.VA.US> Sender: ipsec-request@neptune.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : ICMP Security Failures Messages Author(s) : P. Karn, W. Simpson Filename : draft-ietf-ipsec-icmp-fail-01.txt Pages : 4 Date : 02/22/1996 This document specifies ICMP messages for indicating failures when using IP Security Protocols (AH, ESP, and Photuris). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-icmp-fail-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-icmp-fail-01.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 (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-icmp-fail-01.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: <19960222143602.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-icmp-fail-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-icmp-fail-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960222143602.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- Received: from relay.tis.com by neptune.TIS.COM id aa25922; 23 Feb 96 14:20 EST Received: by relay.tis.com; id OAA27290; Fri, 23 Feb 1996 14:22:22 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma027235; Fri, 23 Feb 96 14:21:35 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08982; Fri, 23 Feb 96 14:20:32 EST Received: by relay.tis.com; id OAA27217; Fri, 23 Feb 1996 14:21:31 -0500 Received: from south-station-annex.mit.edu(18.72.1.2) by relay.tis.com via smap (V3.1) id xma027193; Fri, 23 Feb 96 14:20:59 -0500 Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA13409; Fri, 23 Feb 96 14:21:28 EST Received: by dcl.MIT.EDU (5.0/4.7) id AA14437; Fri, 23 Feb 1996 14:21:59 -0500 Date: Fri, 23 Feb 1996 14:21:59 -0500 From: Theodore Ts'o Message-Id: <9602231921.AA14437@dcl.MIT.EDU> To: William Allen Simpson Cc: ipsec@TIS.COM In-Reply-To: William Allen Simpson's message of Fri, 23 Feb 96 05:20:11 GMT, <4932.bsimpson@morningstar.com> Subject: Re: Regarding Bill's draft Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 2017 Sender: ipsec-request@neptune.tis.com Precedence: bulk Bill, My interpretation of the wg requirements is that it is not enough that it be possible for the protocol to support a required functionality, but that a compliant implementation must support it. Users or system administrators may decide not to use such a feature, but they must have the option of _using_ it; ergo, a compliant implementation must support it, in an interoperable fashion. Hence, a compliant implementation of IPV6 must include support for encryption. It is not enough that there be an optional way of doing encryption in IPV6; a compliant implementation must support encryption. Likewise, for SKIP to pass muster vis-a-vis the wg requirements, it is not enough for there to be an optional way of supporting Perfect Forward Secrecy. If SKIP is to meet the wg requirements, all compliant implementations of SKIP must support PFS. And finally, it is not enough that Photoris support certain wg requirements by providing a way to support them in the protocol via an optional Photoris extensions document, where the extensions are very clearly not well-enough defined to create interoperable implementations. In order to meet the wg requirements, all complaint implementations have to support those features listed in the Photuris extensions draft. After all, you'd probably be first to cry foul if the SKIP folks claimed that their protocol meet all of the working group requirements if the PFS was only described in an optional part of the protocol spec, which none of their implementations supported. Likewise, if Photoris is to be considered as meeting all of the wg requirements, then all of these requirements must be met in the base protocol spec, or failing that, in an annex of the protocol spec which is well-formed and which is mandatory for implementors to implement. Hence, I believe that we really do need to address those items found in the Photoris extensions draft, or else consider Photuris as not meeting the wg requirements. Fair's fair, after all.... - Ted Received: from relay.tis.com by neptune.TIS.COM id aa26846; 23 Feb 96 15:13 EST Received: by relay.tis.com; id PAA28994; Fri, 23 Feb 1996 15:15:43 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma028987; Fri, 23 Feb 96 15:15:25 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA12364; Fri, 23 Feb 96 15:14:15 EST Received: by relay.tis.com; id PAA28978; Fri, 23 Feb 1996 15:15:16 -0500 Received: from relay.hp.com(15.255.152.2) by relay.tis.com via smap (V3.1) id xma028965; Fri, 23 Feb 96 15:14:51 -0500 Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA072136548; Fri, 23 Feb 1996 12:15:50 -0800 Message-Id: <199602232015.AA072136548@relay.hp.com> Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com id AA240336706; Fri, 23 Feb 1996 15:18:26 -0500 X-Mailer: exmh version 1.6.2 7/18/95 To: ashar.aziz@Eng.Sun.COM MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Cc: ipsec@TIS.COM Subject: an imperfection in skip-pfs. Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 23 Feb 1996 15:15:47 -0500 From: Bill Sommerfeld Sender: ipsec-request@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii There is a small, but significant, difference between perfect forward secrecy as implemented by Photuris and ISAKMP/OAKLEY, and how it is proposed to be implemented for SKIP in draft-ietf-ipsec-skip-pfs-00.txt. The basic exchange in that draft is: I->J: { g^x, g, p, [Cert_I]g^xj, EMKID_J_I}Kij J->I: { g^y, g, p, [Cert_J]g^xj, EMKID_J_I, EMKID_I_J}Kij While I believe this provides perfect forward secrecy for subsequent traffic keys derived from g^xy, this does not appear to provide perfect forward privacy protection for the identities enclosed in the ephemeral certificates Cert_I and Cert_J. The problem is that the certificate is encrypted with a key g^xj which has an ephemeral public component and a long-term private component. If the long-term DH secret key `j' is later compromised, an attacker than then decrypt both [Cert_I] and [Cert_J] and figure out who the parties to the exchange really are. Photuris does not have this problem, since the identity exchange is encrypted in a completely ephemeral key (g^xy in the terminology used in skip-pft). A quick scan of the OAKLEY draft seems to indicate to me that OAKLEY is essentially identical to Photuris in this regard. - Bill -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMS4gbFpj/0M1dMJ/AQGeKwP7B1KeQp8anXJAQIKYs7ILArs5wynU3pRH ohzWL5037YF0GVcLjxYXmXgMaPKNJUiEIUvMk8oKBR/jftn3pLKGs28Y5t3ZFZKX P9i0HCEznnmFsFzO6aXyqTRFGcpDv1lOTIDgRtm/NaQqjOkWcFVaCowAp1MmOgys ZrUZNfmjhdM= =Amsi -----END PGP SIGNATURE----- Received: from relay.tis.com by neptune.TIS.COM id aa26981; 23 Feb 96 15:22 EST Received: by relay.tis.com; id PAA29374; Fri, 23 Feb 1996 15:24:39 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma029328; Fri, 23 Feb 96 15:23:50 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA12855; Fri, 23 Feb 96 15:22:38 EST Received: by relay.tis.com; id PAA29294; Fri, 23 Feb 1996 15:23:36 -0500 Received: from interlock.ans.net(147.225.5.5) by relay.tis.com via smap (V3.1) id xma029271; Fri, 23 Feb 96 15:23:17 -0500 Received: by interlock id AA07415 (InterLock SMTP Gateway 3.0 for ipsec@ans.net); Fri, 23 Feb 1996 15:24:11 -0500 Received: by interlock (Protected-side Proxy Mail Agent-4); Fri, 23 Feb 1996 15:24:11 -0500 Received: by interlock (Protected-side Proxy Mail Agent-3); Fri, 23 Feb 1996 15:24:11 -0500 Received: by interlock (Protected-side Proxy Mail Agent-2); Fri, 23 Feb 1996 15:24:11 -0500 Received: by interlock (Protected-side Proxy Mail Agent-1); Fri, 23 Feb 1996 15:24:11 -0500 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@ans.net From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-ipsec-icmp-fail-01.txt Date: Fri, 23 Feb 96 09:56:12 -0500 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-Id: <9602230956.aa21798@IETF.CNRI.Reston.VA.US> Sender: ipsec-request@neptune.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : ICMP Security Failures Messages Author(s) : P. Karn, W. Simpson Filename : draft-ietf-ipsec-icmp-fail-01.txt Pages : 4 Date : 02/22/1996 This document specifies ICMP messages for indicating failures when using IP Security Protocols (AH, ESP, and Photuris). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-icmp-fail-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-icmp-fail-01.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 (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-icmp-fail-01.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: <19960222143602.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-icmp-fail-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-icmp-fail-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960222143602.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- Received: from relay.tis.com by neptune.TIS.COM id aa27838; 23 Feb 96 16:07 EST Received: by relay.tis.com; id QAA00935; Fri, 23 Feb 1996 16:09:26 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma000922; Fri, 23 Feb 96 16:08:57 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16085; Fri, 23 Feb 96 16:07:55 EST Received: by relay.tis.com; id QAA00919; Fri, 23 Feb 1996 16:08:56 -0500 Received: from interlock.ans.net(147.225.5.5) by relay.tis.com via smap (V3.1) id xma000912; Fri, 23 Feb 96 16:08:27 -0500 Received: by interlock id AA08944 (InterLock SMTP Gateway 3.0 for ipsec@ans.net); Fri, 23 Feb 1996 16:09:29 -0500 Received: by interlock (Protected-side Proxy Mail Agent-1); Fri, 23 Feb 1996 16:09:29 -0500 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@ans.net From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-ipsec-esp-des-md5-00.txt Date: Fri, 23 Feb 96 10:00:58 -0500 Message-Id: <9602231001.aa22314@IETF.CNRI.Reston.VA.US> Sender: ipsec-request@neptune.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Combined DES-CBC, MD5 and Replay Prevention Security Transform Author(s) : J. Hughes Filename : draft-ietf-ipsec-esp-des-md5-00.txt Pages : 4 Date : 02/22/1996 This draft describes a combination of privacy, authentication, integrity and optional replay prevention into a single packet format. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-esp-des-md5-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-esp-des-md5-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-esp-des-md5-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960222112207.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-des-md5-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-des-md5-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960222112207.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- Received: from relay.tis.com by neptune.TIS.COM id aa00194; 23 Feb 96 18:02 EST Received: by relay.tis.com; id SAA02326; Fri, 23 Feb 1996 18:04:27 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma002322; Fri, 23 Feb 96 18:03:59 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21403; Fri, 23 Feb 96 18:02:56 EST Received: by relay.tis.com; id SAA02313; Fri, 23 Feb 1996 18:03:57 -0500 Received: from merit.edu(35.1.1.42) by relay.tis.com via smap (V3.1) id xma002305; Fri, 23 Feb 96 18:03:52 -0500 Received: from Bill.Simpson.DialUp.Mich.Net (pm001-03.dialip.mich.net [35.1.48.52]) by merit.edu (8.7.3/merit-2.0) with SMTP id SAA02472 for ; Fri, 23 Feb 1996 18:04:49 -0500 (EST) Date: Fri, 23 Feb 96 21:31:11 GMT From: William Allen Simpson Message-Id: <4943.bsimpson@morningstar.com> To: Theodore Ts'o Cc: ipsec@TIS.COM Subject: Re: Regarding Bill's draft Sender: ipsec-request@neptune.tis.com Precedence: bulk > From: "Theodore Ts'o" > My interpretation of the wg requirements is that it is not > enough that it be possible for the protocol to support a required > functionality, but that a compliant implementation must support it. > .... Ted, I agree with everything you eloquently said (so I won't repeat the rest), as you make no mention of any particular requirement. For the remainder of this message, I will make the assumption that you are referring to Sensitivity Labels, as you did in an earlier message. If you are interested, just tell me about the details, and I'll whip up a little separate draft in a few minutes. So far, nobody has detailed enough description about how such an option might be formatted and negotiated. It was removed to the extensions draft for lack of interest. Sensitivity Labels are clearly not required (by the working group, or any proposed standard, or otherwise). Complaint implementations of IP Security are not required to support them. I will go one step further. In a separate message, I will call for the removal of mention of Sensitivity Labels in the "architecture" document as we go to Draft Standard. For lack of 2 implementations. Bill.Simpson@um.cc.umich.edu 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 aa00193; 23 Feb 96 18:02 EST Received: by relay.tis.com; id SAA02327; Fri, 23 Feb 1996 18:04:27 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma002323; Fri, 23 Feb 96 18:03:59 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21404; Fri, 23 Feb 96 18:02:57 EST Received: by relay.tis.com; id SAA02312; Fri, 23 Feb 1996 18:03:57 -0500 Received: from merit.edu(35.1.1.42) by relay.tis.com via smap (V3.1) id xma002303; Fri, 23 Feb 96 18:03:43 -0500 Received: from Bill.Simpson.DialUp.Mich.Net (pm001-03.dialip.mich.net [35.1.48.52]) by merit.edu (8.7.3/merit-2.0) with SMTP id SAA02466 for ; Fri, 23 Feb 1996 18:04:44 -0500 (EST) Date: Fri, 23 Feb 96 21:15:10 GMT From: William Allen Simpson Message-Id: <4941.bsimpson@morningstar.com> To: ipsec@TIS.COM Subject: Re: Regarding Bill's draft... another Bill's open issues with Sender: ipsec-request@neptune.tis.com Precedence: bulk > From: Bill Sommerfeld > More importantly, the attack requires a large number of different > chosen-messages. Since it is not possible for an attacker to "choose" > the parameters being verified, this attack is impossible. > > That's not at all clear to me. In particular, it seems that in a > system using per-user or per-transport-connection SPI's, an active > attacker could easily induce a system to create large numbers of SPI's > with a third party, each having similar, but not identical parameters. > I am not following you; since it's apparently easy, please give a concrete example of such an exchange. > Most importantly, the attack requires an incredibly large number of > known-messages, on the order of 2**65 or more! That makes it utterly > impractical (also stated by the authors). > > That's an upper-bound on the strength of this construction, not a > lower bound. > How true (although the number I gave was the smallest bound in the paper). In fact, it could be guessed on the very first try. It's just not very likely (1:2**65). And there would be no confirmation of success. > As an engineer, not a cryptographer, the existance of this weakness > makes me suspicious of tying photuris so closely to > hash(concat(key,data,key)) instead of a more flexible > keyed_hash(key,data). > Thanks for your opinion. > They already are. That is, a hash over the key. MD5 is used in the > base document, but other hashes are possible for other Exchange-Schemes. > (See Extensions draft for details.) > > I'm sorry, but a keyed hash and a hash over a key and some other data > are *NOT* necessarily the same thing. Hash(concat(key,data,key)) is just one > way to implement a keyed hash -- it's not necessarily the *best* way. > Never-the-less, it is _one_ way, and at this time is the one with field experience and both qualitative and quantitative analysis. > Hugo's work suggests that hash(key1, hash(key2, data)) may be better, > but there's no way to cleanly define photuris extensions which use > that structure in the future if the base draft insists on the > key,data,key form. > Huh? You mean Kaliski and Robshaw. Hugo suggested some other variant for another purpose. And I don't understand your latter assertion, as Photuris has clear and clean extension mechanisms. > > 2) define the key used for validity-method, privacy-method keygen, > > and SPI session keygen as the shared-secret > > > This is a cryptographically unsound idea. > > Why? That's exactly what photuris is doing today! It's doing a keyed > hash using the shared secret as the "key" and other fields as the > "data". > I don't see any "data" or "hash" in your suggestion. If you are suggesting that Photuris use the same method that it does today, then we are in complete agreement. > > 3) define the key used for the identity-choice algorithm as > > the shared secret, concatenated or otherwise combined with the > > authentication secret-key if there was one. > > > Again, an incredibly insecure idea. > > Again, this is exactly what photuris is doing today. It's doing a > keyed hash using the shared secret as the "key" and other fields as > the "data". > Again, ditto. Bill.Simpson@um.cc.umich.edu 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 aa00530; 23 Feb 96 18:17 EST Received: by relay.tis.com; id SAA02634; Fri, 23 Feb 1996 18:19:27 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma002632; Fri, 23 Feb 96 18:18:58 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21955; Fri, 23 Feb 96 18:17:56 EST Received: by relay.tis.com; id SAA02629; Fri, 23 Feb 1996 18:18:57 -0500 Received: from interlock.ans.net(147.225.5.5) by relay.tis.com via smap (V3.1) id xma002625; Fri, 23 Feb 96 18:18:31 -0500 Received: by interlock id AA12542 (InterLock SMTP Gateway 3.0 for ipsec@ans.net); Fri, 23 Feb 1996 18:19:33 -0500 Received: by interlock (Protected-side Proxy Mail Agent-1); Fri, 23 Feb 1996 18:19:33 -0500 Date: Fri, 23 Feb 1996 15:18:25 -0800 From: John Kennedy Message-Id: <199602232318.PAA25839@netcom13.netcom.com> To: ipsec@ans.net Subject: Sender: ipsec-request@neptune.tis.com Precedence: bulk Attached is a copy of a new draft for the working group's review. Comments should be sent to the IPSEC mailing list (ipsec@ans.net) and/or directly to me (jkennedy@cylink.com). Title: Digital Signature Standard (DSS) Profile for X.509 Certificates Abstract: This document describes the ASN.1 [1] encoding for a CCITT 1988 X.509 [2] certificate profiled for use with the U.S. Government's Digital Signature Standard (DSS) [3]. This profile aligns with the base standards and profile references listed below. It is intended to provide guidelines for those developing software that will be used to issue and use DSS certificates. This is to insure that DSS-specific certificate information will be handled consistently throughout the public key infrastructure. X.509 (1993) | ISO/IEC 9594-8 Amendment 1 to ITU Rec. X.509 (1993) | ISO/IEC 9594-8 : 1995 DoD Secure Data Network System (SDNS) SDN.702 Revision 2.7 : 1994 USPS Postal ECS X.509 Certificate and CRL Profile, Rev. 0.5.: 1996 -------------------------------------------------------- IPSEC Working Group John Kennedy Internet Engineering Task Cylink Corporation INTERNET-DRAFT John Marchioni Expires in six months Cylink Corporation February 21, 1996 Digital Signature Standard (DSS) Profile for X.509 Certificates 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@ans.net) or to the authors. 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. Comments should be sent to the IP Security WG mailing list (ipsec@ans.net). 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 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 document describes the ASN.1 [1] encoding for a CCITT 1988 X.509 [2] certificate profiled for use with the U.S. Government's Digital Signature Standard (DSS) [3]. This profile aligns with the base standards and profile references listed below. It is intended to provide guidelines for those developing software that will be used to issue and use DSS certificates. This is to insure that DSS-specific certificate information will be handled consistently throughout the public key infrastructure. X.509 (1993) | ISO/IEC 9594-8 Amendment 1 to ITU Rec. X.509 (1993) | ISO/IEC 9594-8 : 1995 DoD Secure Data Network System (SDNS) SDN.702 Revision 2.7 : 1994 USPS Postal ECS X.509 Certificate and CRL Profile, Rev. 0.5.: 1996 For details not covered in this document the reader should refer to its base references:X.509 (1993) | ISO/IEC 9594-8 and Amendment 1 to ITU Rec. X.509 (1993) |ISO/IEC 9594-8 : 1995. 1. ASN.1 Definition of Certificate The abstract definition of the certificate is as follows: Certificate ::= SIGNED { SEQUENCE { version [0] Version DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueIdentifier [1] IMPLICIT UniqueIdentifier OPTIONAL, -- if present, must be v2 or v3 subjectUniqueIdentifer [2] IMPLICIT UniqueIdentifier OPTIONAL, -- if present, must be v2 or v3 extensions [3] Extensions OPTIONAL }} Version ::= INTEGER { v1(0), v2(1), v3(2) } CertificateSerialNumber ::= INTEGER AlgorithmIdentifier ::= SEQUENCE { algorithm ALGORITHM.&id ({SupportedAlgorithms}), parameters ALGORITHM.&id ({SupportedAlgorithms}{ @algorithm}) OPTIONAL } -- SupportedAlgorithms ALGORITHM ::= {...|...} -- DSA Signature Algorithm -- -- The Digital Signature Algorithm (DSA) is also called the -- Digital Signature Standard (DSS). DSA was developed by -- the U.S. Government. DSA is used in conjunction with -- the SHA-1 one way hash function. (SHA-1 is described in FIPS 180-1). -- DSA is described in FIPS 186. -- The ASN.1 object identifier used to identify this signature -- algorithm is: dsaWithSHA-1 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) country(16) US(840) organization(1) us-government(101) dod(2) infosec(1) algorithms(1) dsa-sha1 (2) } -- DSA Parameters -- When this object identifier is used with the ASN.1 type -- AlgorithmIdentifier, the parameters component of that type is -- optional. If it is absent, the DSA parameters p, q, and g are -- assumed to be known, otherwise the parameters are included using the -- following ASN.1 structure: Dss-Parms ::= SEQUENCE { p OCTET STRING, q OCTET STRING, g OCTET STRING } -- DSA Signature Block -- Prior to the bitstring encoding of the certificate issuer's DSA -- signature, the signature block must be encoded using the -- distinguished rules as follows: Dss-Sig ::= SEQUENCE { r OCTET STRING, s OCTET STRING} Validity ::= SEQUENCE { notBefore UTCTime, notAfter UTCTime } SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING } 2. Certificate Extensions The standard extensions are described in Amendment 1 to ITU Rec. X.509 (1993) | ISO/IEC 9594-8 : 1995. A subset of these extensions will need to be chosen for this profile. The extensions field allows addition of new fields to the certificate structure without modification to the ASN.1 definition. An extension field consists of an extension object identifier, a criticality flag, and a canonical encoding of a data value of an ASN.1 type associated with the object identifier already specified. When a system processes a certificate but does not recognize an extension, if the criticality flag is FALSE, the extension may be ignored and the remainder of the certificate information may be processed as valid. If the criticality flag is TRUE, an unrecognized extension shall cause the system to consider the entire certificate invalid. 3. An overview of the use of the Distinguished Encoding Rules (DER) in Certificate Signature Operations. (1) Sign; The signing application converts the abstract value (or internal representation) of the certificate information into a bit representation using the DER and signs that bit representation. The signature is then appended onto the abstract value, and both values are then BER (Basic Encoding Rules) encoded to provide a transfer syntax. The same encoder used to apply the DER may be used to apply the transfer syntax, so the transfer syntax can also follow the DER. (2) Authenticate; The authenticating application will decode the received certificate (containing the certificate information and issuer signature). This application will then have an abstract value for both the certificate information and a signature. The application will then take the resulting abstract value of the certificate information and re- encode it using the DER to produce the same bit representation that was signed. The received signature can now be authenticated using the exact bitstring representation used in the signing operation. When the DER are applied to information, before that information is signed, the authentication operation (also applying the DER) will always detect if that information has been modified and the incidence of false authentication failures is greatly reduced. 4. Security Considerations Security issues are not discussed in this document 5. References [1] CCITT Recommendation X.208 (1992), "Abstract Syntax Notation One" [2] CCITT Recommendation X.509 (1988),"The Directory - Authentication Framework" [3] FIPS 186 Digital Signature Standard Author's Addresses Questions about this document can be directed to: John Kennedy CYLINK Corporation 910 Hermosa Court Sunnyvale, CA 94086 jkennedy@cylink.com 408-735-5885 John Marchioni CYLINK Corporation 910 Hermosa Court Sunnyvale, CA 94086 johnmarc@cylink.com 408-735-5800 Received: from relay.tis.com by neptune.TIS.COM id aa00679; 23 Feb 96 18:25 EST Received: by relay.tis.com; id SAA02767; Fri, 23 Feb 1996 18:27:27 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma002765; Fri, 23 Feb 96 18:26:58 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22328; Fri, 23 Feb 96 18:25:56 EST Received: by relay.tis.com; id SAA02760; Fri, 23 Feb 1996 18:26:57 -0500 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1) id xma002756; Fri, 23 Feb 96 18:26:52 -0500 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id PAA09276; Fri, 23 Feb 1996 15:27:37 -0800 Date: Fri, 23 Feb 1996 15:27:37 -0800 From: Ran Atkinson Message-Id: <199602232327.PAA09276@puli.cisco.com> To: bsimpson@morningstar.com Subject: Re: Regarding Bill's draft Cc: ipsec@TIS.COM Sender: ipsec-request@neptune.tis.com Precedence: bulk Bill, There are at least 2 independent implementations of RFC-1825 that include support for sensitivity labels. There is no plan to move RFC-1825 through RFC-1827 forward prior to or during LA in any event. Ran rja@cisco.com Received: from relay.tis.com by neptune.TIS.COM id aa01270; 23 Feb 96 19:03 EST Received: by relay.tis.com; id TAA03172; Fri, 23 Feb 1996 19:05:27 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma003164; Fri, 23 Feb 96 19:04:59 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA23261; Fri, 23 Feb 96 19:03:56 EST Received: by relay.tis.com; id TAA03159; Fri, 23 Feb 1996 19:04:57 -0500 Received: from unknown(15.255.152.2) by relay.tis.com via smap (V3.1) id xma003155; Fri, 23 Feb 96 19:04:52 -0500 Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA050620349; Fri, 23 Feb 1996 16:05:50 -0800 Message-Id: <199602240005.AA050620349@relay.hp.com> Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com id AA267500507; Fri, 23 Feb 1996 19:08:27 -0500 X-Mailer: exmh version 1.6.2 7/18/95 To: William Allen Simpson Cc: ipsec@TIS.COM Subject: Re: Regarding Bill's draft... another Bill's open issues with In-Reply-To: bsimpson's message of Fri, 23 Feb 1996 21:15:10 +0000. <4941.bsimpson@morningstar.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 23 Feb 1996 19:05:47 -0500 From: Bill Sommerfeld Sender: ipsec-request@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii > From: Bill Sommerfeld > More importantly, the attack requires a large number of different > chosen-messages. Since it is not possible for an attacker to "choose" > the parameters being verified, this attack is impossible. > > That's not at all clear to me. In particular, it seems that in a > system using per-user or per-transport-connection SPI's, an active > attacker could easily induce a system to create large numbers of SPI's > with a third party, each having similar, but not identical parameters. > I am not following you; since it's apparently easy, please give a concrete example of such an exchange. Ok. Here's an abstract overview. If this is too abstract for you, I'll refine this into something more concrete. Assume that there's a replicated service which we wish to attack: client <----> server A <-----> server B Assume that we are a legitimate client of this replicated service, but are only authorized to change a few things in the service's database. As a legitimate user of this service, we can tweak its database at one site; that site will then "push" our changes to the other sites, and we can then snoop on the network traffic that results. Assume the service is implemented on a set of hosts which implement per-transport-connection SPI's, and the replicas only keep connections open when they have a change to propagate between the replicas. Then, each replication "push" will occur on a separate SPI, and a change-message exchange will occur prior to each push and subsequent to each push to set up and then tear down the new SPI. Thus, as I said earlier, we can induce a system to create and destroy a large number of SPI's with a third party to provide us with a large number of chances to attack the hash function used to validate the Photuris change_message protocol. > I'm sorry, but a keyed hash and a hash over a key and some other data > are *NOT* necessarily the same thing. Hash(concat(key,data,key)) is just one > way to implement a keyed hash -- it's not necessarily the *best* way. > Never-the-less, it is _one_ way, and at this time is the one with field experience and both qualitative and quantitative analysis. I'm not saying "change the bit level encoding". I'm saying "move the abstraction boundary" -- at the layer within Photuris where you dispatch to a particular keyed hash algorithm, keep the key separate from the data; under the covers, it can combine it exactly as it's specified in photuris-09, or in a new way. And I don't understand your latter assertion, as Photuris has clear and clean extension mechanisms. Maybe to you; I had difficulty figuring out from photuris-09 where the abstraction boundary was between the various transforms and their uses. > Why? That's exactly what photuris is doing today! It's doing a keyed > hash using the shared secret as the "key" and other fields as the > "data". > I don't see any "data" or "hash" in your suggestion. If you are suggesting that Photuris use the same method that it does today, then we are in complete agreement. Here is a concrete suggested wording change to address the primary problem. If you accept this change (which I doubt), I'll supply wording to fix up the other places which use hash(concat(key,data,key)) Change 6.1.7 to the following text: 6.1.7. Integrity Verification This message is authenticated using the Validity-Method indicated by the current Scheme-Choice. It is separate from any authentication specified for Security Associations (see "Exchange Scheme List"). The Verification field is calculated using the specified Validity-Method keyed hash, given the computed shared secret as a key, and the following concatenated values as the input data: + the Initiator Cookie, + the Responder Cookie, + the SPI Owner (receiver) Identity Verification, + the SPI User (sender) Identity Verification, + the Type, LifeTime and SPI, + the Attribute-Choices following the Verification field, Note that the order of the Identity Verification fields is different in each direction. If the verification fails, the users are notified, and a Photuris Error_Message (Type 7, Code 3) is sent, without adding or deleting any Security Associations. On success, normal operation begins with the authentication and/or encryption of user datagrams. Add section 6.1.8: 6.1.8. Validity Methods Each exchange scheme specifies a particular validity method to use to authenticate subsequent change_message packets. Validity Methods are keyed hash functions, supplied with two inputs: a key (a sequence of bytes) the data to be hashed (a sequence of bytes) They produce a single output: a hash value (a multiple precision integer) It should be infeasible to determine the value of the key given a large number of (data, hash) pairs. - --- Change the paragraph of Section 9.5 starting with "Validity Method" to: - ---- Validity-Method When specified as a Validity-Method, an MD5 hash is calculated over the concatenation of the supplied key the supplied data the supplied key again. Neither occurance of the key is padded to any particular alignment. The resulting Verification field is 128-bits (18 octets including Size). -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMS5WVFpj/0M1dMJ/AQGoVQP8CCSX5ZoF55MLk16rj8eV3CwjGZvk4ZoK 871e1hLoHz4HN6M7cY1LWS+LfBrYZ/Ep1uNucTr7LVsLheWiUFIk67RJm6GJTdks +FqsZ+JrqAwmXE7XVboTmhXkyywK710XSQmjrl8OlUUHuaf5jD7alSpwXBBVgOvZ 7y6wtNMIQ7E= =biCa -----END PGP SIGNATURE----- Received: from relay.tis.com by neptune.TIS.COM id aa10511; 24 Feb 96 9:28 EST Received: by relay.tis.com; id JAA07998; Sat, 24 Feb 1996 09:30:06 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma007993; Sat, 24 Feb 96 09:29:37 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08728; Sat, 24 Feb 96 09:28:34 EST Received: by relay.tis.com; id JAA07990; Sat, 24 Feb 1996 09:29:36 -0500 Received: from volitans.morningstar.com(137.175.2.11) by relay.tis.com via smap (V3.1) id xma007987; Sat, 24 Feb 96 09:29:14 -0500 Received: from gefilte.MorningStar.Com by volitans.MorningStar.Com (8.7.1/95070701) id OAA04406; Sat, 24 Feb 1996 14:30:16 GMT From: Karl Fox Received: by gefilte.MorningStar.Com (5.65a/94012401) id AA15693; Sat, 24 Feb 96 09:30:14 -0500 Date: Sat, 24 Feb 96 09:30:14 -0500 Message-Id: <9602241430.AA15693@gefilte.MorningStar.Com> To: "PALAMBER.US.ORACLE.COM" Cc: ipsec@TIS.COM Subject: IPSEC Implementation Survey In-Reply-To: <199602212237.OAA21701@mailsun2.us.oracle.com> References: <199602212237.OAA21701@mailsun2.us.oracle.com> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Sender: ipsec-request@neptune.tis.com Precedence: bulk ************************************************************ IPSEC Implementation Survey Name of Implementation: Morning Star SecureConnect Security Protocols: ESP, AH Security Transforms: ESP-DES, AH-MD5 Key Management: manual Lineage of Code: scratch Location of Source Code: proprietary Point of Contact: Karl Fox ************************************************************ -- Karl Fox, servant of God, employee of Morning Star Technologies 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 451 1883 Received: from relay.tis.com by neptune.TIS.COM id aa11124; 24 Feb 96 10:19 EST Received: by relay.tis.com; id KAA08151; Sat, 24 Feb 1996 10:21:06 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma008146; Sat, 24 Feb 96 10:20:37 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA09555; Sat, 24 Feb 96 10:19:35 EST Received: by relay.tis.com; id KAA08141; Sat, 24 Feb 1996 10:20:36 -0500 Received: from merit.edu(35.1.1.42) by relay.tis.com via smap (V3.1) id xma008137; Sat, 24 Feb 96 10:20:20 -0500 Received: from Bill.Simpson.DialUp.Mich.Net (pm012-26.dialip.mich.net [141.211.7.194]) by merit.edu (8.7.3/merit-2.0) with SMTP id KAA21264 for ; Sat, 24 Feb 1996 10:21:21 -0500 (EST) Date: Sat, 24 Feb 96 14:39:57 GMT From: William Allen Simpson Message-Id: <4949.bsimpson@morningstar.com> To: ipsec@TIS.COM Subject: Rhetoric Sender: ipsec-request@neptune.tis.com Precedence: bulk From time to time, I have been privately chastised for being too direct in my replies. This has been known to make some folks think that there is an unwritten subtext such as: "as any fool can see". > Subject: Re: Regarding Bill's draft... another Bill's open issues with > > I'll point out that Bill Sommerfeld is a not-stupid... > I have had two folks tell me in the past 3 months that there are a few of you out there that actually won't publically comment on my work, for fear of being personnally flayed. Gentlefolk, please take note that Bill and Bill get along quite amicably in person. I consider Ran a good freind (albeit you might not know that from our public exchanges). It may interest you to know that this written perception problem is not uncommon in scientific venues. Quoting "Social Epistemology", 1992, v. 6, n. 2, pp. 231-240, entitled "Howe and Lyne bully the critics", by Henry Howe (an ecologist) and John Lyne (a rhetorician): Rhetoric is not used in this essay 'solely in a pejorative sense'. _Au_contraire_, rhetorics bind together and help organize practices. Whether rhetoric is good or bad depends on whether it is, well, good or bad. ... Lyne wants it on record that he has no interest in an end to rhetoric. Like [a critic], he wants 'better rhetoric'. A number of critics decry our intemperance, calling into question what they perceive to be innuendo, sneers, back-biting metaphor, and _ad_hominem_ attacks. Sticks and stones. We reject the characterization that our attacks are _ad_hominem_. If we term an idea 'muddled' or a claim 'unrealistic', we really think that the adjectives describe muddled ideas and unrealistic claims, not muddled or unrealistic individuals. Bill.Simpson@um.cc.umich.edu 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 aa11125; 24 Feb 96 10:19 EST Received: by relay.tis.com; id KAA08152; Sat, 24 Feb 1996 10:21:06 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma008147; Sat, 24 Feb 96 10:20:38 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA09556; Sat, 24 Feb 96 10:19:35 EST Received: by relay.tis.com; id KAA08140; Sat, 24 Feb 1996 10:20:36 -0500 Received: from merit.edu(35.1.1.42) by relay.tis.com via smap (V3.1) id xma008136; Sat, 24 Feb 96 10:20:06 -0500 Received: from Bill.Simpson.DialUp.Mich.Net (pm012-26.dialip.mich.net [141.211.7.194]) by merit.edu (8.7.3/merit-2.0) with SMTP id KAA21255 for ; Sat, 24 Feb 1996 10:21:06 -0500 (EST) Date: Sat, 24 Feb 96 13:35:05 GMT From: William Allen Simpson Message-Id: <4946.bsimpson@morningstar.com> To: Ran Atkinson Cc: ipsec@TIS.COM Subject: Sensitivity Labels Sender: ipsec-request@neptune.tis.com Precedence: bulk Gentlefolk, I propose that we officially remove the recommendation for Sensitivity Labels from RFC-1825, for several reasons: A) Although there are many (> 6) interoperable implementations of RFC-1828 and RFC-1829, none of them implement Sensitivity Labels. B) Since RFC-1828 and RFC-1829 are more than ready to go to Draft Standard, but interoperability of Sensitivity Labels has not been demonstrated, by RFC-1602 we MUST remove Sensitivity Labels from our official WG documents. C) Sensitivity Labels are ill-defined. D) Commercial vendors have not found a demand for Sensitivity Labels. > From: Ran Atkinson > There are at least 2 independent implementations of RFC-1825 that include > support for sensitivity labels. > Please indicate which implementations? And if you cite NRL, please detail commands for manual configuration of the security association that implement the feature. > There is no plan to move RFC-1825 through RFC-1827 forward prior to > or during LA in any event. > Then, you have not followed the Standards Process in RFC-1602. The time for updating them is upon us. Last Spring, we (the WG) allowed Ran Atkinson to publish RFC-1825 to RFC-1827 without removing some of the nits, in order to make forward progress. Since then, he has been browbeating Photuris with an obscure "requirement" (clearly "RECOMMENDED" not "REQUIRED" in RFC-1825) for Sensitivity Labels. There have been two respondents that have called for Sensitivity Labels (in Photuris) in the past 3 weeks: 1) Ran Atkinson 2) Theodore Ts'o I have spoken to the latter, and he assures me that his interest is in having a "level playing field" for the protocol descriptions, not in actually implementing Sensitivity Labels; nor has MIT any requirement or current plans for deployment. I will note here that someone has sent private messages "quoting" me as stating: "i don't care for sensitivity labels". I have examined both the IPSec and my personal archives, and cannot find this string at any location. Dissemination of such false and out of context quote information is excrable. My previous _privately_ expressed position was "Personally, I don't care. It is a pretty simple thing to add syntactically, but takes 10-20 pages to describe all the security considerations." I will note that I have previously cooperated with regard to Sensitivity Labels. Last September, at the request of Ran and NSA, I added the "Modify" capability to Photuris. The sole reason was to modify Sensitivity Labels on the fly. Last October, the WG, including Sommerfeld, Orman, Bellovin and Housley (citing earlier IEEE arguments), called for the removal of the Modify capability. As to WG consensus, no public support (other than Atkinson) was expressed for inclusion of Sensitivity Labels in Photuris. Therefore, it was removed to the "for future work" Extensions draft. Bill.Simpson@um.cc.umich.edu 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 aa12108; 24 Feb 96 11:46 EST Received: by relay.tis.com; id LAA08604; Sat, 24 Feb 1996 11:48:06 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma008601; Sat, 24 Feb 96 11:47:37 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA11126; Sat, 24 Feb 96 11:46:34 EST Received: by relay.tis.com; id LAA08598; Sat, 24 Feb 1996 11:47:36 -0500 Received: from merit.edu(35.1.1.42) by relay.tis.com via smap (V3.1) id xma008596; Sat, 24 Feb 96 11:47:26 -0500 Received: from Bill.Simpson.DialUp.Mich.Net (pm002-17.dialip.mich.net [141.211.7.153]) by merit.edu (8.7.3/merit-2.0) with SMTP id LAA22850 for ; Sat, 24 Feb 1996 11:48:20 -0500 (EST) Date: Sat, 24 Feb 96 15:26:21 GMT From: William Allen Simpson Message-Id: <4951.bsimpson@morningstar.com> To: Bill Sommerfeld Cc: ipsec@TIS.COM Subject: Re: Regarding Bill's draft... another Bill's open issues with Sender: ipsec-request@neptune.tis.com Precedence: bulk > From: Bill Sommerfeld > Ok. Here's an abstract overview. If this is too abstract for you, > I'll refine this into something more concrete. > No, that was good enough for me to understand that you are measuring the wrong text-message pairs. > Assume that there's a replicated service which we wish to attack: > > client <----> server A <-----> server B > ... > > As a legitimate user of this service, we can tweak its database at one > site; that site will then "push" our changes to the other sites, and > we can then snoop on the network traffic that results. > ... > > Thus, as I said earlier, we can induce a system to create and destroy > a large number of SPI's with a third party to provide us with a large > number of chances to attack the hash function used to validate the > Photuris change_message protocol. > Now I understand. Clever. But, there are several reasons why this attack provably (P&vO) cannot succeed: 1) The shared-secret between the other parties will be different, even when the target uses the same public value, as the other party will have a different public value. You cannot use your SA with server A to influence the SAs between A and B. No calculable relation. 2) You have no control over the SPI used (or any other parameter, visible or invisible), and therefore cannot get the requisite number of "chosen" message pairs. 3) Much (or most) of the material covered by the hash is hidden (encrypted), and therefore you cannot see the data that you want to measure to get the "known" message pairs. 4) The actual hash is also hidden (encrypted), and therefore you cannot verify any forgery attempts. > I'm not saying "change the bit level encoding". I'm saying "move the > abstraction boundary" -- at the layer within Photuris where you > dispatch to a particular keyed hash algorithm, keep the key separate > from the data; under the covers, it can combine it exactly as it's > specified in photuris-09, or in a new way. > Aha, why didn't you say so in the first place? > I had difficulty figuring out from photuris-09 where the > abstraction boundary was between the various transforms and their > uses. > > Here is a concrete suggested wording change to address the primary problem. > If you accept this change (which I doubt), I'll supply wording to fix up the > other places which use hash(concat(key,data,key)) > Surprise! Accepted. Well, I won't add a separate section, and I'm not that fond of certain phraseology, but I will rearrange the text in the manner that you suggest. Seems reasonable to me! The Validity-Method keyed cryptographic hashing function is supplied with two inputs: - the computed shared-secret, - the data to be hashed (as a concatenated sequence of octets). The resulting hash value is stored in the Verification field (variable precision number). The Validity-Method cryptographic hash is calculated over the following concatenated data values: + the Initiator Cookie, + the Responder Cookie, + the SPI Owner (receiver) Identity Verification, + the SPI User (sender) Identity Verification, + the Type, LifeTime and SPI, + the Attribute-Choices following the Verification field. Validity-Method When specified as a Validity-Method, as described in "Integrity Verification", an MD5 hash is calculated over the concatenation of MD5( key, data, key, md5fill ) The leading key is not padded to any particular alignment. The resulting Verification field is 128-bits (18 octets including Size). Bill.Simpson@um.cc.umich.edu 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 aa13768; 24 Feb 96 14:04 EST Received: by relay.tis.com; id OAA09318; Sat, 24 Feb 1996 14:06:06 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma009316; Sat, 24 Feb 96 14:05:46 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13694; Sat, 24 Feb 96 14:04:35 EST Received: by relay.tis.com; id OAA09311; Sat, 24 Feb 1996 14:05:36 -0500 Received: from interlock.ans.net(147.225.5.5) by relay.tis.com via smap (V3.1) id xma009306; Sat, 24 Feb 96 14:05:28 -0500 Received: by interlock id AA23890 (InterLock SMTP Gateway 3.0 for ipsec@ans.net); Sat, 24 Feb 1996 14:06:26 -0500 Received: by interlock (Protected-side Proxy Mail Agent-3); Sat, 24 Feb 1996 14:06:26 -0500 Received: by interlock (Protected-side Proxy Mail Agent-2); Sat, 24 Feb 1996 14:06:26 -0500 Message-Id: <199602241730.AA13651@sdnpk.undp.org> Received: by interlock (Protected-side Proxy Mail Agent-1); Sat, 24 Feb 1996 14:06:26 -0500 From: Ashar Aziz To: ipsec@ans.net Date: Sat, 24 Feb 1996 17:23:14 +0000 X-Total-Enclosures: 1 Subject: Re: an imperfection in skip-pfs Priority: normal X-Mailer: Pegasus Mail for Windows (v2.01) Sender: ipsec-request@neptune.tis.com Precedence: bulk > From: Bill Sommerfeld > While I believe this provides perfect forward secrecy for subsequent > traffic keys derived from g^xy, this does not appear to provide > perfect forward privacy protection for the identities enclosed in the > ephemeral certificates Cert_I and Cert_J. Bill, You are correct that the SKIP PFS draft does not provide equal protection for identity information as it does for traffic. However, the same is true of OAKLEY (and I believe Photuris, though I dont have a draft at hand to check), albeit in a different manner. With, e.g., OAKLEY, the identity information is revealed in the unauthenticated phase, meaning that identity information would be disclosed under an active (intruder-in-the-middle) attack. Of course, traffic is secure against active forms of attack, since it is transmitted in the authenticated phase. An intruder-in-the-middle attack on SKIP PFS does not disclose identity information. There are some additional points to consider. The most common usage of the anonymity feature is likely to be for mobile users, making secured access to corporate information across the Internet. In this scenario, J is an organizational firewall, and I is the mobile user. Compromise of the mobile user's long-term keys does not disclose identity information. Only compromise of the firewall's long term keys discloses identity information. >From a practical point of view, a mobile user's long-term keys are more likely to be compromised than the long-term keys of a physically protected organizational firewall. Therefore, considering only identity protection, one has to ask oneself what is a greater threat: a) The possibility of a compromise of a firewall's long-term keys or b) the possibility of an intruder-in-the-middle attack on the key exchange. If a) is a greater threat then the identity protection provided by Photuris/Oakley is better. If b) is a greater threat then the identity protection provided by SKIP PFS is better. In favor of the identity protection provided by Photuris/Oakley, it is worth noting that identity disclosure requires an attack on each key exchange, wherease with SKIP PFS compromise of a firewall's long-term keys discloses identity information for a large number of exchanges. However, in principle if one can perform an active attack on one key exchange, one could perform active attacks on many key exchanges. Given these different tradeoffs, my own view is that the anonymity protection of SKIP PFS is adequate, however I am open to modifying this if the WG believes a) to be a greater threat than b). (It is possible for the anonymity protection for SKIP PFS to be more like Oakley/Photuris, at the cost of some additional complexity.) Regards, Ashar. -------------- Enclosure number 1 ---------------- >From ashar Sat, 24 Feb 1996 12:12:54 PST +0500 remote from sunpak Received: from ashar@sunpak by sunpak.sdnpk.undp.org (PMail+UDG PegWaf v0.26 93.04.04) id 3761 for ipsec@ans.net; Sat, 24 Feb 1996 12:12:54 PST +0500 From: ashar@sunpak.sdnpk.undp.org (Ashar Aziz) To: ipsec@ans.net Date: Sat, 24 Feb 1996 12:12:53 +0000 Subject: Re: an imperfection in skip-pfs. (fwd) Priority: normal X-mailer: Pegasus Mail for Windows (v2.01) > From: Bill Sommerfeld > While I believe this provides perfect forward secrecy for subsequent > traffic keys derived from g^xy, this does not appear to provide > perfect forward privacy protection for the identities enclosed in the > ephemeral certificates Cert_I and Cert_J. Bill, You are correct that the SKIP PFS draft does not provide equal protection to identity information as it does to traffic. However, the same is true of OAKLEY (and I believe Photuris, though I dont have a draft at hand to check), albeit in a different manner. With, e.g., OAKLEY, the identity information is revealed in the unauthenticated phase, meaning that identity information would be disclosed under an active (intruder-in-the-middle) attack. Of course, traffic is secure against active forms of attack, since it is transmitted in the authenticated phase. An intruder-in-the-middle attack on SKIP PFS does not disclose identity information. There are some additional points to consider. The most common usage of the anonymity feature is likely to be for mobile users, making secured access to corporate information across the Internet. In this scenario, J is an organizational firewall, and I is the mobile user. Compromise of the mobile user's long-term keys does not disclose identity information. Only compromise of the firewall's long term keys discloses identity information. >From a practical point of view, a mobile user's long-term keys are more likely to be compromised than the long-term keys of a physically protected organizational firewall. This is why the identities are protected with g^xj and not g^ij. Therefore, considering only identity protection, one has to ask oneself what is a greater threat: a) The possibility of a compromise of a firewall's long-term keys or b) the possibility of an intruder-in-the-middle attack on the key exchange. If a) is a greater threat then the identity protection provided by Photuris/Oakley is better. If b) is a greater threat then the identity protection provided by SKIP PFS is better. In favor of the identity protection provided by Photuris/Oakley, it is worth noting that identity disclosure requires an attack on each key exchange, wherease with SKIP PFS compromise of a firewall's long-term keys discloses identity information for a large number of exchanges. However, in principle if one can perform an active attack on one key exchange, one could perform active attacks on many key exchanges. Given these different tradeoffs, my own view is that the anonymity protection of SKIP PFS is adequate, however I am open to modifying this if the WG believes a) to be a greater threat than b). (It is possible for the anonymity protection for SKIP PFS to be more like Oakley/Photuris, at the cost of some additional complexity.) Regards, Ashar. Received: from relay.tis.com by neptune.TIS.COM id aa15084; 24 Feb 96 15:56 EST Received: by relay.tis.com; id PAA09867; Sat, 24 Feb 1996 15:58:06 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma009862; Sat, 24 Feb 96 15:57:41 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA15707; Sat, 24 Feb 96 15:56:34 EST Received: by relay.tis.com; id PAA09859; Sat, 24 Feb 1996 15:57:36 -0500 Received: from interlock.ans.net(147.225.5.5) by relay.tis.com via smap (V3.1) id xma009857; Sat, 24 Feb 96 15:57:34 -0500 Received: by interlock id AA24774 (InterLock SMTP Gateway 3.0 for ipsec@ans.net); Sat, 24 Feb 1996 15:58:34 -0500 Received: by interlock (Protected-side Proxy Mail Agent-4); Sat, 24 Feb 1996 15:58:34 -0500 Received: by interlock (Protected-side Proxy Mail Agent-3); Sat, 24 Feb 1996 15:58:34 -0500 Received: by interlock (Protected-side Proxy Mail Agent-2); Sat, 24 Feb 1996 15:58:34 -0500 Received: by interlock (Protected-side Proxy Mail Agent-1); Sat, 24 Feb 1996 15:58:34 -0500 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Sat, 24 Feb 1996 13:01:46 -0800 From: John Kennedy To: bsimpson@morningstar.com, jkennedy@netcom.com Cc: ipsec@ans.net, ietf-pkix@tandem.com Subject: Re: -Reply Content-Length: 1890 Sender: ipsec-request@neptune.tis.com Precedence: bulk Good observation. I'll consider (re)submission to the PKIX group after the meeting in LA when I have had a chance to chat with the appropriate working group chairs. I don't disagree with you, but timing constraints dictated the current approach. For now, the DSS Certificate draft submission has been approved by the IPSEC co-chairs and will proceed through the IPSEC group. [We're all just one big, happy family anyway, right? :)] Regards, John Kennedy CYLINK >>> William Allen Simpson 02/24/96 06:35am >>> John, you sent this to the wrong group. You want the PKIX group. Please update your draft accordingly. > Date: Fri, 23 Feb 1996 15:18:25 -0800 > From: John Kennedy > > Attached is a copy of a new draft for the working group's review. > Comments should be sent to the IPSEC mailing list (ipsec@ans.net) > and/or directly to me (jkennedy@cylink.com). > > Title: Digital Signature Standard (DSS) Profile for X.509 Certificates > > > Abstract: > > This document describes the ASN.1 [1] encoding for a CCITT 1988 X.509 [2] > certificate profiled for use with the U.S. Government's Digital Signature > Standard (DSS) [3]. > > This profile aligns with the base standards and profile references > listed below. It is intended to provide guidelines for those developing > software that will be used to issue and use DSS certificates. This is > to insure that DSS-specific certificate information will be handled > consistently throughout the public key infrastructure. > > X.509 (1993) | ISO/IEC 9594-8 > Amendment 1 to ITU Rec. X.509 (1993) | ISO/IEC 9594-8 : 1995 > DoD Secure Data Network System (SDNS) SDN.702 Revision 2.7 : 1994 > USPS Postal ECS X.509 Certificate and CRL Profile, Rev. 0.5.: 1996 > > > ----------------------------- Received: from orodruin.cs.berkeley.edu by neptune.TIS.COM id aa15568; 24 Feb 96 16:38 EST Received: from espresso.CS.Berkeley.EDU.mammoth (espresso.CS.Berkeley.EDU [128.32.33.40]) by orodruin.CS.Berkeley.EDU (8.7.Gamma.0/8.7.Gamma.0) with SMTP id NAA14781 for ; Sat, 24 Feb 1996 13:41:46 -0800 (PST) Received: by espresso.CS.Berkeley.EDU.mammoth (5.x/SMI-SVR4) id AA12870; Sat, 24 Feb 1996 13:41:33 -0800 From: David A Wagner Message-Id: <9602242141.AA12870@espresso.CS.Berkeley.EDU.mammoth> Subject: draft-ietf-ipsec-icmp-fail-01.txt To: ipsec@neptune.tis.com Date: Sat, 24 Feb 1996 13:41:33 -0800 (PST) Reply-To: daw@cs.berkeley.edu X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-request@neptune.tis.com Precedence: bulk draft-ietf-ipsec-icmp-fail-01.txt creates a small security hole. In particular, it defines a ICMP 'decryption failed' message, which leaks a little information about an encrypted datagram. Let me use the standard DES-CBC transform as an example: the last encrypted block contains padding, padding-length, and payload-type. The padding-length may be as large as 255 to hide the length of the plaintext payload. I claim this length can be recovered by taking advantage of the ICMP failure messages. Here's the attack. Take a long DES-CBC-ESP encrypted IP datagram, for which you want to know the true length of the payload. Delete all the ciphertext blocks except the last N blocks (and set the IV to be the N+1 to last ciphertext block), send the resulting datagram, and check whether you get a ICMP 'decryption failed' error. If the padding-length byte was greater than 8N-2, you will receive a 'decryption failed' error (because presumably the receiver will send a 'decryption failed' ICMP error when the decrypted padding-length value is greater than the length of the encrypted payload). If the padding-length is at most 8N-2, the decryption will succeed (although some nonsense bits will be sent up to the transport protocol's port-- no harm done). A binary search over N will quickly find the datagram's secret length (plus or minus 8 bytes or so). So this cut-and-paste replay attack on DES-CBC, and its interaction with the ICMP failure draft, opens a minor security weakness: an active attacker can recover the length of the plaintext payload without too much effort. (What other scarier, subtler interactions are out there? Eek.) A fix? One fix is to never use DES-CBC without authentication, I suppose. Received: from relay.tis.com by neptune.TIS.COM id aa25916; 25 Feb 96 8:30 EST Received: by relay.tis.com; id IAA13158; Sun, 25 Feb 1996 08:32:37 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma013145; Sun, 25 Feb 96 08:32:16 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02036; Sun, 25 Feb 96 08:31:04 EST Received: by relay.tis.com; id IAA13142; Sun, 25 Feb 1996 08:32:07 -0500 Received: from ktik0.ethz.ch(129.132.66.42) by relay.tis.com via smap (V3.1) id xma013140; Sun, 25 Feb 96 08:31:56 -0500 Received: from komsys-pc-gc.ethz.ch (dynppp48.dialup.ethz.ch [192.33.93.48]) by ktik0 (8.6.8.1/8.6.6) with SMTP id OAA18408; Sun, 25 Feb 1996 14:32:40 +0100 Message-Id: <2.2.32.19960225134151.0069ee18@ktik0.ethz.ch> X-Sender: caronni@ktik0.ethz.ch (Unverified) X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 25 Feb 1996 14:41:51 +0100 To: ipsec@TIS.COM, skip-info@tik.ee.ethz.ch, skip@tik.ee.ethz.ch From: Germano Caronni Subject: Re: PFS SKIP Draft Sender: ipsec-request@neptune.tis.com Precedence: bulk > SKIP extension for Perfect Forward Secrecy (PFS) > >This document describes an optional extension specifying how to use an >ephemeral Diffie-Hellman exchange in conjunction with the SKIP protocol >in order to provide perfect forward secrecy for situations where forward >secrecy is necessary. Anonymity is also offered. (Or will be, after modification) >In addition a new type of Master Key-ID (MKID) type is defined here, to >indicate the use of ephemeral master keys. In addition to perfect >forward secrecy, principal anonymity is also supported in the context of >the ephemeral certificate exchange. How about using 'NSID' instead of 'MKID type' ? >2. Cryptographic Description of Ephemeral Certificate Exchange > >Cryptographic Notation used for describing Ephemeral Certificates: > >Note: All exponentiations (e.g. g^x) are mod p. The mod p reduction is >assumed, and is omitted for the sake of brevity. > >g^x: Ephemeral Diffie-Hellman public value of initiator (I) >g^y: Ephemeral Diffie-Hellman public value of responder (J) >g^i: Certified long-term Diffie-Hellman value of initiator >g^j: Certified long-term Diffie-Hellman value of responder >Cert_I: Long-Lived Certificate of initiator, containing value g^i >Cert_J: Long-Lived Certificate of responder, containing value g^j >{Message}K: Message authenticated with a Message Authentication Code > (MAC) computed using key K >[Message]K: Message encrypted using key K >EMKID_J_I: Ephemeral Master Key-ID used in packets from J to I >EMKID_I_J: Ephemeral Master Key-ID used in packets from I to J > >The ephemeral certificate exchange is described using the >notation above as follows: > >I->J: { g^x, g, p, [Cert_I]g^xj, EMKID_J_I}Kij >J->I: { g^y, g, p, [Cert_J]g^xj, EMKID_J_I, EMKID_I_J}Kij I see two problems with this exchange. One has already been pointed out by Bill Sommerfeld: >The problem is that the certificate is encrypted with a key g^xj which >has an ephemeral public component and a long-term private component. >If the long-term DH secret key `j' is later compromised, an attacker >than then decrypt both [Cert_I] and [Cert_J] and figure out who the >parties to the exchange really are. The other (not so immediate) problem is the employment of authentication using Kij on the outmost level. An atacker having a bunch of ressources, who can lay hands on either one of the secret value 'i' or 'j', can then go and combine the value with the public value of a probable partner. He can verify his guess by simply recalculating the authentication. If it matches, he has found the partners. Both problems can easily be fixed, if we allow for a 3-pass exchange. I am aware that this complicates the issue of key establishment, but if somebody wants PFS and anonymity bad enough, he will have to pay the price, e.g.: I->J: g^x, g, p, Cookie_1 J->I: {g^y, g, p, [Cert_J, EMKID_I_J, Cookie_1, Cookie_2}Kij]g^xy I->J: [{g^x, g, p, Cert_I, EMKID_J_I, Cookie_2}Kij]g^xy Cookie_1 & _2 allow I & J to check that the peer really holds Kij, and is not an impostor reusing some old messages. I admitt that I just reinvented the wheel, for a 'full' solution see e.g. page 5 of the current Oakley draft ;-) But I believe the exchange presented above is sufficient for the special case SKIP PFS key exchange needs. >The values EMKID_I_J and EMKID_J_I refer to the ephemeral >Master Key-ID to be used in SKIP packets sent from I to J >and J to I, respectively. I picks the ephemeral MKID to >be used in packets sent from J to I, and J picks the >ephemeral MKID to be used in packets sent from I to J. As a distinct namespace is defined for the EMKIDs, you _must_ define the size of these new key IDs. I suggest using 32 bit. >The encryption of each principal's certificate using g^xj is optional. >It is used to provide anonymity of the parties involved in the >ephemeral exchange. In case anonymity is not desired or necessary >(e.g. node to node communications) the encryption using g^xj may >be omitted. Change this to g^xy >3. > >"Cert MAC Alg" identifies the MAC algorithm which is used to compute a >MAC over the certificate contents. The scope of the MAC computation is >the entire certificate, with the MAC field treated as zero filled for >the purposes of the MAC computation. Always if a MAC is present, it must be encrypted usig an g^xy derived key, if anonymity is to be provided. > >The "Validity Interval" specifies how long the ephemeral master key >derived from this exchange should be used for. This value is in seconds. >A responder MAY choose a different value for this field than the >initiator, in which case the actual validity interval for this master >key is the minimum of the two values in the exchange. At the end of the >validity interval, the ephemeral master key and the all associated >secret information is destroyed by both the responder and the initiator. >A new exchange may be initiated either subsequent or prior to the expiry >of the ephemeral master key, in case there is still encrypted traffic >that needs to be sent in PFS mode. Here lies another small problem: It is not clear when the interval *starts*. Provided that the time of the participating systems is not vulnerable to attack, it might be better to use 'Expires at (seconds GMT since xxx)', or 'Expires at SKIP N=xxx'. Perhaps it could also be defined that if a new key exchange using the same EMKID is initiated, the old keying material is droppped. Or an authenticated ICMP message could be defined that has the meaning 'drop all ephemeral keying material partaining to me'. >When I receives an ephemeral certificate, it uses the value EMKID_J_I to >locate the request for which this is the corresponding response. A non- >zero EMKID_I_J field indicates that this a response to an ephemeral >certificate request initiated by I, as opposed to a new certificate >exchange initiated by J. > .P ^^^^ >7. Security Considerations > >The topic of this memo is security. My word. ;-) Section 7 currently holds negligible content. You could add a discussion of advantages / disadvantages against pure SKIP? I hope my abovementioned protocol & arguments are valid. Comments anyone? Friendly greetings, Germano p.s. Concerning key separation issues: As Hugo suggested some months ago, it would be wise to use different keying material for different crypt & auth algs in SKIP. How about adding the two algorithm numbers to the key speration process? Received: from relay.tis.com by neptune.TIS.COM id aa27894; 25 Feb 96 11:18 EST Received: by relay.tis.com; id LAA13636; Sun, 25 Feb 1996 11:20:37 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma013629; Sun, 25 Feb 96 11:20:13 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA04746; Sun, 25 Feb 96 11:19:05 EST Received: by relay.tis.com; id LAA13619; Sun, 25 Feb 1996 11:20:07 -0500 Received: from interlock.ans.net(147.225.5.5) by relay.tis.com via smap (V3.1) id xma013611; Sun, 25 Feb 96 11:20:01 -0500 Received: by interlock id AA03621 (InterLock SMTP Gateway 3.0 for ipsec@ans.net); Sun, 25 Feb 1996 11:20:59 -0500 Received: by interlock (Protected-side Proxy Mail Agent-3); Sun, 25 Feb 1996 11:20:59 -0500 Received: by interlock (Protected-side Proxy Mail Agent-2); Sun, 25 Feb 1996 11:20:59 -0500 Received: by interlock (Protected-side Proxy Mail Agent-1); Sun, 25 Feb 1996 11:20:59 -0500 Message-Id: Date: Sunday, 25 February 1996 11:19am ET To: jkennedy@cylink.com, johnmarc@cylink.com Cc: lovornj@dyniet.com, ipsec@ans.net From: Richard.Ankney@fisc.com Subject: Comments on DSS Certificate RFC Sender: ipsec-request@neptune.tis.com Precedence: bulk I have a few comments on the draft: 1. What is the representation of the actual subjectPublicKey? Given the use of the DoD algorithm identifier, I assume it's the one from the Mosaic documentation, ie. version number + type + privileges + the actual key. All that's needed for commercial use is the actual key. If you're only conveying the actual key, you can't very well use the DoD identifier, since it implies a different structure. I suggest using the representation in ANSI X9.57, which is just an INTEGER. OIDs are: algorithm OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) } dsa OBJECT IDENTIFIER ::= { algorithm 12 } dsaWithSHA-1 OBJECT IDENTIFIER ::= { algorithm 27 } 2. All of the parameters and signature fields are conveyed as OCTET STRINGs. Are these big-endian integers? If so they could be conveyed as ASN.1 INTEGERs per X9.57; this only changes the tags, not the actual data within the fields. X9.57 uses the following: DSAParameters ::= SEQUENCE { modulusLength INTEGER, -- length of p in bits prime1 INTEGER, -- modulus p prime2 INTEGER, -- modulus q base INTEGER } -- base g DSASignature ::= SEQUENCE { r INTEGER, s INTEGER } Regards, Rich Received: from relay.tis.com by neptune.TIS.COM id aa28651; 25 Feb 96 12:16 EST Received: by relay.tis.com; id MAA13833; Sun, 25 Feb 1996 12:18:07 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma013831; Sun, 25 Feb 96 12:17:38 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA05740; Sun, 25 Feb 96 12:16:34 EST Received: by relay.tis.com; id MAA13828; Sun, 25 Feb 1996 12:17:37 -0500 Received: from interlock.ans.net(147.225.5.5) by relay.tis.com via smap (V3.1) id xma013826; Sun, 25 Feb 96 12:17:11 -0500 Received: by interlock id AA04066 (InterLock SMTP Gateway 3.0 for ipsec@ans.net); Sun, 25 Feb 1996 12:18:12 -0500 Received: by interlock (Protected-side Proxy Mail Agent-1); Sun, 25 Feb 1996 12:18:12 -0500 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@ans.net From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-ipsec-dss-cert-00.txt Date: Sun, 25 Feb 96 12:01:35 -0500 Message-Id: <9602251201.aa14169@IETF.CNRI.Reston.VA.US> Sender: ipsec-request@neptune.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : DSS Profile for X.509 Certificates Author(s) : John Kennedy, John Marchioni Filename : draft-ietf-ipsec-dss-cert-00.txt Pages : 3 Date : 02/24/1996 This document describes the ASN.1 encoding for an CCITT 1988 X.509 certificate profiled for use with the NIST Digital Signature Standard (DSS). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-dss-cert-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-dss-cert-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 (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-dss-cert-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: <19960225113743.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-dss-cert-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-dss-cert-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960225113743.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- Received: from [35.1.1.42] by neptune.TIS.COM id aa29275; 25 Feb 96 12:59 EST Received: from Bill.Simpson.DialUp.Mich.Net (pm001-02.dialip.mich.net [35.1.48.51]) by merit.edu (8.7.3/merit-2.0) with SMTP id NAA19135 for ; Sun, 25 Feb 1996 13:02:14 -0500 (EST) Date: Sun, 25 Feb 96 17:16:29 GMT From: William Allen Simpson Message-ID: <4959.bsimpson@morningstar.com> To: daw@cs.berkeley.edu Cc: ipsec@neptune.tis.com Subject: Re: draft-ietf-ipsec-icmp-fail-01.txt Sender: ipsec-request@neptune.tis.com Precedence: bulk > From: David A Wagner > draft-ietf-ipsec-icmp-fail-01.txt creates a small security hole. > > In particular, it defines a ICMP 'decryption failed' message, which leaks a > little information about an encrypted datagram. > > Let me use the standard DES-CBC transform as an example: the last encrypted > block contains padding, padding-length, and payload-type. The padding-length > may be as large as 255 to hide the length of the plaintext payload. I claim > this length can be recovered by taking advantage of the ICMP failure messages. > Thank you for the excellent analysis. However, in order to make network protocols work in a user environment, we need error feedback mechanisms for the protocols. > Delete all the ciphertext > blocks except the last N blocks (and set the IV to be the N+1 to last > ciphertext block), > ... > A fix? One fix is to never use DES-CBC without authentication, I suppose. > As that is the fix for several other problems, I certainly recommend it. Indeed, it is already recommended in the RFC. Another more specific fix is to use the 32-bit IV facility, instead of the 64-bit. That prevents setting the IV (above). I will be recommending this at the LA IETF meeting. Bill.Simpson@um.cc.umich.edu 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 aa29890; 25 Feb 96 13:48 EST Received: by relay.tis.com; id NAA14180; Sun, 25 Feb 1996 13:50:07 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma014178; Sun, 25 Feb 96 13:49:39 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA07301; Sun, 25 Feb 96 13:48:35 EST Received: by relay.tis.com; id NAA14173; Sun, 25 Feb 1996 13:49:37 -0500 Received: from interlock.ans.net(147.225.5.5) by relay.tis.com via smap (V3.1) id xma014167; Sun, 25 Feb 96 13:49:30 -0500 Received: by interlock id AA05035 (InterLock SMTP Gateway 3.0 for ipsec@ans.net); Sun, 25 Feb 1996 13:50:31 -0500 Received: by interlock (Protected-side Proxy Mail Agent-1); Sun, 25 Feb 1996 13:50:31 -0500 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 From: Internet-Drafts@cnri.reston.va.us Cc: ipsec@ans.net Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-simpson-esp-des1md5-01.txt Date: Sun, 25 Feb 96 13:20:28 -0500 Message-Id: <9602251320.aa16851@IETF.CNRI.Reston.VA.US> Sender: ipsec-request@neptune.tis.com Precedence: bulk --NextPart This announcement is a retransmission. A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : The ESP DES-CBC plus MD5 Transform Author(s) : P. Metzger, W. Simpson, D.A. Wagner Filename : draft-simpson-esp-des1md5-01.txt Pages : 16 Date : 02/25/1996 This document describes use of DES-CBC for privacy, plus MD5 for integrity, in the IP Encapsulating Security Payload (ESP). 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-esp-des1md5-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-simpson-esp-des1md5-01.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 (192.12.192.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-esp-des1md5-01.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: <19960225131738.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-simpson-esp-des1md5-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-simpson-esp-des1md5-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960225131738.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- Received: from relay.tis.com by neptune.TIS.COM id aa16665; 26 Feb 96 6:28 EST Received: by relay.tis.com; id GAA18508; Mon, 26 Feb 1996 06:30:09 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma018503; Mon, 26 Feb 96 06:29:40 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA24295; Mon, 26 Feb 96 06:28:36 EST Received: by relay.tis.com; id GAA18500; Mon, 26 Feb 1996 06:29:39 -0500 Received: from pilot.is.chrysler.com(204.189.94.147) by relay.tis.com via smap (V3.1) id xma018496; Mon, 26 Feb 96 06:29:20 -0500 Received: by pilot.firewall.is.chrysler.com; id GAA03537; Mon, 26 Feb 1996 06:53:47 -0500 Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilot.is.chrysler.com via smap (g3.0.1) id sma003531; Mon, 26 Feb 96 06:53:46 -0500 Received: from rgm3 (rgm3.is.chrysler.com) by clhubgw1.is.chrysler.com (5.x/SMI-4.1) id AA06650; Mon, 26 Feb 1996 06:32:06 -0500 Message-Id: <2.2.32.19960226112937.002e76c4@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 26 Feb 1996 06:29:37 -0500 To: William Allen Simpson , Ran Atkinson From: Robert Moskowitz Subject: Re: Sensitivity Labels Cc: ipsec@TIS.COM Sender: ipsec-request@neptune.tis.com Precedence: bulk At 01:35 PM 2/24/96 GMT, William Allen Simpson wrote: >Gentlefolk, > >I propose that we officially remove the recommendation for Sensitivity >Labels from RFC-1825, for several reasons: > Sensitivity labels. What an interesting concept. Seems like I was just in a discussion about them. Oh yes that was at the EMail security meeting were it was shown that only MSP has'm and the others are going to need them. But is for secure 'objects' and we are dealing with secure 'streams', right? So what is the role of sensitivity for streams? An interesting question for sure one that is not jelling right now. Do the labels map to those in MSP? The docs are all there, put up by Spyrus. Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.tis.com by neptune.TIS.COM id aa18275; 26 Feb 96 8:10 EST Received: by relay.tis.com; id IAA19419; Mon, 26 Feb 1996 08:12:39 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma019407; Mon, 26 Feb 96 08:12:17 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27839; Mon, 26 Feb 96 08:11:06 EST Received: by relay.tis.com; id IAA19403; Mon, 26 Feb 1996 08:12:09 -0500 Received: from ktik0.ethz.ch(129.132.66.42) by relay.tis.com via smap (V3.1) id xma019396; Mon, 26 Feb 96 08:11:37 -0500 Received: from komsys-pc-gc.ethz.ch (komsys-pc-gc.ethz.ch [129.132.66.22]) by ktik0 (8.6.8.1/8.6.6) with SMTP id OAA24207; Mon, 26 Feb 1996 14:12:19 +0100 Message-Id: <2.2.32.19960226132134.006a8ccc@ktik0.ethz.ch> X-Sender: caronni@ktik0.ethz.ch (Unverified) X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 26 Feb 1996 14:21:34 +0100 To: ipsec@TIS.COM From: Germano Caronni Subject: IPsec Implementation Survey: ETHZ Cc: skip@tik.ee.ethz.ch Sender: ipsec-request@neptune.tis.com Precedence: bulk IPSEC Implementation Survey Name of Implementation: ETHZ / ENskip Security Protocols: SKIP (draft 6), limited AH & ESP (SPI=1) Security Transforms: ESP-DES, ESP-3DES, ESP-IDEA, ESP-RC4, AH-MD5 (some of these transforms are not yet standarized) Key Management: only via SKIP, (manual, X.509 and 'DH public value' keying). (plus non-standardized PFS) Lineage of Code: Works under Solaris 2.4+, IRIX, NetBSD, Nextstep. Location of Source Code: ftp://ftp.tik.ee.ethz.ch/pub/packages/skip (X.509 and PFS not yet publicly available) Point of Contact: skip@tik.ee.ethz.ch Received: from relay.tis.com by neptune.TIS.COM id aa20816; 26 Feb 96 10:06 EST Received: by relay.tis.com; id KAA22144; Mon, 26 Feb 1996 10:08:39 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma022142; Mon, 26 Feb 96 10:08:22 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA05406; Mon, 26 Feb 96 10:07:06 EST Received: by relay.tis.com; id KAA22139; Mon, 26 Feb 1996 10:08:09 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma022137; Mon, 26 Feb 96 10:07:59 -0500 Received: from hp.com by interlock.ans.net with SMTP id AA12713 (InterLock SMTP Gateway 3.0 for ); Mon, 26 Feb 1996 10:08:58 -0500 Received: from gnlab003.grenoble.hp.com by hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA195593905; Mon, 26 Feb 1996 03:25:06 -0800 Received: from stendhal.grenoble.hp.com by gnlab003.grenoble.hp.com with SMTP (1.38.193.4/15.5+ECS 3.3) id AA00544; Mon, 26 Feb 1996 12:25:03 +0100 Message-Id: <9602261125.AA00544@gnlab003.grenoble.hp.com> To: ipsec@ans.net Subject: Suscribe Date: Mon, 26 Feb 96 12:25:02 +0100 From: Guillaume Oget Sender: ipsec-request@neptune.tis.com Precedence: bulk add ipsec Received: from relay.tis.com by neptune.TIS.COM id aa21831; 26 Feb 96 10:59 EST Received: by relay.tis.com; id LAA23155; Mon, 26 Feb 1996 11:01:39 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma023151; Mon, 26 Feb 96 11:01:11 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA09993; Mon, 26 Feb 96 11:00:06 EST Received: by relay.tis.com; id LAA23148; Mon, 26 Feb 1996 11:01:09 -0500 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1) id xma023145; Mon, 26 Feb 96 11:01:03 -0500 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id IAA07128 for ipsec@tis.com; Mon, 26 Feb 1996 08:02:03 -0800 Date: Mon, 26 Feb 1996 08:02:03 -0800 From: Ran Atkinson Message-Id: <199602261602.IAA07128@puli.cisco.com> To: ipsec@TIS.COM Subject: Re: Sensitivity Labels Sender: ipsec-request@neptune.tis.com Precedence: bulk % Gentlefolk, % % I propose that we officially remove the recommendation for Sensitivity % Labels from RFC-1825, for several reasons: % % A) Although there are many (> 6) interoperable implementations of % RFC-1828 and RFC-1829, none of them implement Sensitivity Labels. At least 2 do implement sensitivity labels. % B) Since RFC-1828 and RFC-1829 are more than ready to go to Draft % Standard, but interoperability of Sensitivity Labels has not been % demonstrated, by RFC-1602 we MUST remove Sensitivity Labels from our % official WG documents. RFC-1828 and RFC-1829 are NOT ready to go to Draft Standard. In fact, they CANNOT go to Draft Standard because RFC-1825 through RFC-1827 are not ready to move forward. Further, RFC-1829 is known to be vulnerable to active attacks. % C) Sensitivity Labels are ill-defined. Hardly. See RFC-1108. % D) Commercial vendors have not found a demand for Sensitivity Labels. Also untrue. The set of workstation vendors that implement Sensitivity Labels includes HP, DEC, IBM, Sun and the set of router vendors includes at least Cisco and Network Systems. % Then, you have not followed the Standards Process in RFC-1602. The time % for updating them is upon us. False. We are NOT required to move them forward at the first opportunity to do so. There is no process violation in waiting until things are ready to move forward. Ran rja@cisco.com Received: from relay.tis.com by neptune.TIS.COM id aa25739; 26 Feb 96 13:37 EST Received: by relay.tis.com; id NAA26821; Mon, 26 Feb 1996 13:39:04 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma026811; Mon, 26 Feb 96 13:38:36 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21119; Mon, 26 Feb 96 13:37:30 EST Received: by relay.tis.com; id NAA26801; Mon, 26 Feb 1996 13:38:34 -0500 Received: from unknown(35.1.1.42) by relay.tis.com via smap (V3.1) id xma026795; Mon, 26 Feb 96 13:38:32 -0500 Received: from Bill.Simpson.DialUp.Mich.Net (pm059-23.dialip.mich.net [141.211.5.91]) by merit.edu (8.7.3/merit-2.0) with SMTP id NAA21090 for ; Mon, 26 Feb 1996 13:39:26 -0500 (EST) Date: Mon, 26 Feb 96 18:28:30 GMT From: William Allen Simpson Message-Id: <4978.wsimpson@greendragon.com> To: ipsec@TIS.COM Subject: Re: Sensitivity Labels Sender: ipsec-request@neptune.tis.com Precedence: bulk > From: Ran Atkinson > % I propose that we officially remove the recommendation for Sensitivity > % Labels from RFC-1825, for several reasons: > % > % A) Although there are many (> 6) interoperable implementations of > % RFC-1828 and RFC-1829, none of them implement Sensitivity Labels. > > At least 2 do implement sensitivity labels. > This is distinctly odd. Although this message seems to be a reply to my message, the relevant request is deleted and not answered. Instead, we have proof by assertion. Repeating a claim does not make it so.... A) Although there are many (> 6) interoperable implementations of RFC-1828 and RFC-1829, none of them implement Sensitivity Labels. ... > From: Ran Atkinson > There are at least 2 independent implementations of RFC-1825 that include > support for sensitivity labels. > Please indicate which implementations? And if you cite NRL, please detail commands for manual configuration of the security association that implement the feature. Bill.Simpson@um.cc.umich.edu 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 aa27407; 26 Feb 96 14:45 EST Received: by relay.tis.com; id OAA28592; Mon, 26 Feb 1996 14:47:25 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma028579; Mon, 26 Feb 96 14:47:02 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA26853; Mon, 26 Feb 96 14:45:55 EST Received: by relay.tis.com; id OAA28570; Mon, 26 Feb 1996 14:46:58 -0500 Received: from merit.edu(35.1.1.42) by relay.tis.com via smap (V3.1) id xma028518; Mon, 26 Feb 96 14:45:39 -0500 Received: from Bill.Simpson.DialUp.Mich.Net (pm035-00.dialip.mich.net [141.211.7.11]) by merit.edu (8.7.3/merit-2.0) with SMTP id OAA24069 for ; Mon, 26 Feb 1996 14:46:10 -0500 (EST) Date: Mon, 26 Feb 96 19:17:29 GMT From: William Allen Simpson Message-Id: <4983.wsimpson@greendragon.com> To: ipsec@TIS.COM Subject: Re: Sensitivity Labels Sender: ipsec-request@neptune.tis.com Precedence: bulk > From: Ran Atkinson > % C) Sensitivity Labels are ill-defined. > > Hardly. See RFC-1108. > I re-read RFC-1108, just to make sure my memory wasn't utterly failing, and I found this statement at the very top, in the title: U.S. Department of Defense Security Options for the Internet Protocol How does that apply to commercial implementations? How does that apply to international implementations? ---- Moreover, these are examples of facilities for "explicit" labels, rather than "implicit" labels (indicated per SPI) used for IP Security. I find that the application of these labels are used for particular objectives (from RFC-1108 page 2): This option is used by end systems and intermediate systems of an internet to: a. Transmit from source to destination in a network standard representation the common security labels required by computer security models, b. Validate the datagram as appropriate for transmission from the source and delivery to the destination, c. Ensure that the route taken by the datagram is protected to the level required by all protection authorities indicated on the datagram. In order to provide this facility in a general Internet environment, interior and exterior gateway protocols must be augmented to include security label information in support of routing control. What Internet routing protocols support this routing control? How exactly are the proposed IP Security Sensitivity Labels used in "network layer" routing without this routing control? ---- See also RFC-1457, which complains that there is no standard network label format, discusses translation problems, and examines the current status of labels in the protocol stack (including IEEE and ISO). Indeed, RFC-1457 recommendations appear to indicate that implicit labels are best applied at the link and transport layers, not the network layer. ---- Again, the RFC-1825 Sensitivity Label recommendations were misguided and ill-defined, and implementation experience has shown that we have no need of them. I urge the WG to clearly indicate that they should be removed. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 Received: from orodruin.cs.berkeley.edu by neptune.TIS.COM id aa00610; 26 Feb 96 16:45 EST Received: from espresso.CS.Berkeley.EDU.mammoth (espresso.CS.Berkeley.EDU [128.32.33.40]) by orodruin.CS.Berkeley.EDU (8.7.Gamma.0/8.7.Gamma.0) with SMTP id NAA23379; Mon, 26 Feb 1996 13:47:48 -0800 (PST) Received: by espresso.CS.Berkeley.EDU.mammoth (5.x/SMI-SVR4) id AA14103; Mon, 26 Feb 1996 13:47:34 -0800 From: David A Wagner Message-Id: <9602262147.AA14103@espresso.CS.Berkeley.EDU.mammoth> Subject: Re: draft-ietf-ipsec-esp-des-md5-00.txt To: "James P. Hughes" Date: Mon, 26 Feb 1996 13:47:33 -0800 (PST) Cc: ipsec@neptune.tis.com In-Reply-To: from "James P. Hughes" at Feb 22, 96 00:18:15 am Reply-To: daw@cs.berkeley.edu X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-request@neptune.tis.com Precedence: bulk > Security Working Group J. Hughes > Request for Comments: DRAFT Network Systems Corp. > February 1996 > > > Combined DES-CBC, MD5 and Replay Prevention Security Transform So let me first thank you for spending your time to draft a transform which includes confidentiality & integrity & replay protection in ESP! Unfortunately, your current text has some serious flaws (though I think they can be fixed within your basic framework). I'll explain. First, you use unkeyed MD5 for integrity protection. This is altogether insufficient (even though the MD5 digest is encrypted). I've included an attack at the bottom of this email if you want more details. You need to use *keyed* MD5 for integrity; use one of the MD5 MACs that is detailed in the AH ipsec RFCs. (HMAC looks ideal.) The MD5 MAC should cover everything in the ESP header and afterwards that it can; in particular, it should protect the SPI and the IV (which you don't have it doing currently). You might consider placing the MD5 MAC output at the beginning of the encrypted data, rather than the end: that way it will have an additional IV-like randomizing influence. Second, the replay protection mechanism you describe is insufficient: it requires a counter to be increasing. Since IP datagrams frequently arrive out-of-order, you'll be dropping an awful lot of packets. Instead, the receiver needs some sort of window for sequence numbers. (Steve Kent suggested a simple scheme along these lines.) I do like the idea of the 32 bit session specific nonce in the replay protection field. Good! You should mention that there will be significant difficulties in getting replay protection to work well in the case of multiple senders per SPI. (One hack which might work if there are just a few senders is to give each sender a different 32 bit session specific nonce.) I don't know of any good way to handle many-sender replay protection; leave that issue for the future, I suppose. Third, now there will be key scheduling issues. Since the MD5 MAC will be keyed, we will need two keys. DON'T use the same key for both MD5 and DES; this is a horrible idea. (I'll elaborate on why if you like.) The MD5 & DES keys should be chosen independently. Since security associations typically only allow one transform key to be associated with them (in the implementations I've seen), you'll need a way to specify the MD5 & DES keys from the transform key. One simple solution is to have a 56+128 = 184 bit transform key: use the first 56 bits of the transform key as the DES key, and the last 128 bits as the MD5 key. You'll have to be very careful to warn people to make sure those bits are independent, though-- this solution might be tempting fate a bit. A more sophisticated & safer solution is to have a 128 bit transform key, and then specify a simple key schedule to generate the DES & MD5 keys, e.g. MD5-key = MD5("md5mac" || transform-key) DES-key = MD5("descbc" || transform-key). You should probably include a little note to implementors who are tempted to make an export-weakened version of this transform, as well: though that should be highly discouraged, such implementors should take care to only reveal bits of the DES-key in the Espionage Enabling Field, and MUST NOT reveal bits of the transform-key or the MD5-key. I've been thinking about these issues a lot; in fact, I think I wrote some text for a possible transform along these lines a while ago...it might still be floating around somewhere. But don't get the wrong idea: I'm not criticizing your draft because of some "not invented here" syndrome-- I just happened to have thought a lot about this stuff already, and would like to help get it right. Thanks for taking the time to work on this transform! I hope this note will help you improve its security. P.S. Here's an example of an attack on unkeyed MD5, as used for integrity protection. I think there's more discussion of these topics in Tsudik's paper on hash-based MACs (which is even available on the web somewhere!). If I want to get you to sign a message M, then I calculate X = M || md5(M) || M' for any M', get you to sign X, and receive DES-CBC(X || md5(X)) = DES-CBC(M || md5(M) || M' || md5(X)). Now remember that I can trim from the end of DES-CBC to short messages; so trim off the encrypted M' & md5(X) blocks, to get DES-CBC(M || md5(M)) which is a forged signed & encrypted version of M. There are probably sharper attacks; but this should be enough to convince you that an unkeyed function is unsuitable for use as a MAC. Received: from relay.tis.com by neptune.TIS.COM id aa01353; 26 Feb 96 17:13 EST Received: by relay.tis.com; id RAA02225; Mon, 26 Feb 1996 17:14:55 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma002220; Mon, 26 Feb 96 17:14:26 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA11904; Mon, 26 Feb 96 17:13:21 EST Received: by relay.tis.com; id RAA02215; Mon, 26 Feb 1996 17:14:25 -0500 Received: from rsa.com(192.80.211.33) by relay.tis.com via smap (V3.1) id xma002211; Mon, 26 Feb 96 17:14:22 -0500 Received: from snail.rsa.com by RSA.COM with SMTP id AA21765; Mon, 26 Feb 96 14:06:52 PST Received: from cc:Mail by snail.rsa.com id AA825372697; Mon, 26 Feb 96 14:11:24 PST Date: Mon, 26 Feb 96 14:11:24 PST From: tim Message-Id: <9601268253.AA825372697@snail.rsa.com> To: ipsec@TIS.COM Subject: On-line Test Sender: ipsec-request@neptune.tis.com Precedence: bulk Greetings, Thought some people on this list would be interested in the on-line test we're undertaking this week. Ten vendors implementing IPSec in their products will be doing an interoperability test. We'll be posting the results as they come in. You can see them at www.rsa.com. Regards, Tim Matthews Received: from relay.tis.com by neptune.TIS.COM id aa01756; 26 Feb 96 17:27 EST Received: by relay.tis.com; id RAA02429; Mon, 26 Feb 1996 17:28:55 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xmaa02426; Mon, 26 Feb 96 17:28:27 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA12539; Mon, 26 Feb 96 17:27:21 EST Received: by relay.tis.com; id RAA02423; Mon, 26 Feb 1996 17:28:25 -0500 Received: from unknown(157.185.80.205) by relay.tis.com via smap (V3.1) id xma002382; Mon, 26 Feb 96 17:28:07 -0500 Received: from katahdin.columbia.sparta.com by columbia.sparta.com (4.1/cfm-7-21-95) id AA10550; Mon, 26 Feb 96 17:26:23 EST Received: by katahdin.columbia.sparta.com (5.61/SMI-4.1) id AA09481; Mon, 26 Feb 96 17:26:17 -0500 From: Howard Weiss Message-Id: <9602262226.AA09481@katahdin.columbia.sparta.com> Subject: Re: Sensitivity Labels To: William Allen Simpson Date: Mon, 26 Feb 1996 17:26:14 -0500 (EST) Cc: ipsec@TIS.COM In-Reply-To: <4983.wsimpson@greendragon.com> from "William Allen Simpson" at Feb 26, 96 07:17:29 pm Organization: SPARTA Inc. (Secure Systems Engineering Division) Usmail: 9861 Broken Land Parkway, Suite 300, Columbia MD 21046 Phone: (410) 381-9400 x201 Fax: (410) 381-5559 X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6081 Sender: ipsec-request@neptune.tis.com Precedence: bulk > > > From: Ran Atkinson > > % C) Sensitivity Labels are ill-defined. > > > > Hardly. See RFC-1108. > > > I re-read RFC-1108, just to make sure my memory wasn't utterly failing, > and I found this statement at the very top, in the title: > > U.S. Department of Defense > Security Options for the Internet Protocol > > How does that apply to commercial implementations? > > How does that apply to international implementations? > > ---- Check out the newly emerging security label standards - NIST's "Standard Security Label" (SSL) and the DoD version "Common Security Label" (CSL) [MIL-STD-2045-48501]. These were adapted/extended from the IPSO (RFC-1108) and the Common IPSO (CIPSO). The SSL and the CSL were carefully harmonized - in other words, they say the same things. So, here we have what will be a security label standard applicable to the civil/commercial world as well as the military community. > > Moreover, these are examples of facilities for "explicit" labels, rather > than "implicit" labels (indicated per SPI) used for IP Security. > But why should "explict" labels be precluded? There are times when they are explicitly needed (see below). > I find that the application of these labels are used for > particular objectives (from RFC-1108 page 2): > > This option is used by end systems and intermediate systems of an > internet to: > > a. Transmit from source to destination in a network standard > representation the common security labels required by computer > security models, > > b. Validate the datagram as appropriate for transmission from > the source and delivery to the destination, > > c. Ensure that the route taken by the datagram is protected to > the level required by all protection authorities indicated on > the datagram. In order to provide this facility in a general > Internet environment, interior and exterior gateway protocols > must be augmented to include security label information in > support of routing control. > > What Internet routing protocols support this routing control? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ None deployed, but have you heard of "policy-based" routing? Besides, policy routing is only one issue. Nothing precludes the use of IP security option labels that could be checked by a packet's receipient to determine whether the packet is within an acceptable classification range. This is a *very* useful feature when multiple sensitivity systems are connected together via firewalls or other high assurance guards. For example, presume a multilevel system containing both proprietary and non-proprietary data. Only non-proprietary data may cross the boundary of the firewall/guard and flow out. The MLS system could employ sensitivity labels to provide a basis on which the firewall/guard can easily permit/deny datagrams flowing across its boundary. Many cludges have been put together because of a lack of systems that can support sensitivity labels. > How exactly are the proposed IP Security Sensitivity Labels used in > "network layer" routing without this routing control? The routing controls are only one piece of the puzzle. What precludes anyone from using this in the future (e.g., with policy-based routing)? There is at least one large site that I've been involved with that could have effectively used sensitivity labels on connections if their installed routers could have dealt with the labels without a major performance penalty (which seemed to be a problem with the particular vendor rather than the technical issue of filtering based on security label - other vendors claimed to have no such performance penalties in using IPSO). > See also RFC-1457, which complains that there is no standard network > label format, discusses translation problems, and examines the current > status of labels in the protocol stack (including IEEE and ISO). But this will be overcome by the SSL/CSL > > Indeed, RFC-1457 recommendations appear to indicate that implicit labels > are best applied at the link and transport layers, not the network layer. The age-old problem with network layer labels (e.g., IPSO) is that they could not be protected if the network layer itself was not protected (i.e., not encrypted). As long as there is a means to provide label integrity, the label could be at any layer. > > Again, the RFC-1825 Sensitivity Label recommendations were misguided and > ill-defined, and implementation experience has shown that we have no > need of them. Talk to the Compartmented Workstation (CMW) vendors and the Trusted Systems Interoperability Group (TSIG). From TSIG documentation: " In order for two MLS systems to communicate securely, two kinds of information must be exchanged: * Information, such as user identities, that users themsevles can establish thorugh something that they are, know or posess; and * Information, such as sensitivity labels, which users themselves cannot establish but which trusted systems must establish for them." Obviously, there is at least one group of communicating systems that *do* have a need for sensitivity labels! > I urge the WG to clearly indicate that they should be removed. I urge that they remain. > > Bill.Simpson@um.cc.umich.edu > Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 > Howard Weiss ________________________________________________________________________ | | | Howard Weiss phone (410) 381-9400 x201 | | SPARTA, Inc. (301) 621-8145 x201 (DC)| | 9861 Broken Land Parkway, suite 300 fax: (410) 381-5559 | | Columbia, MD 21046 email: hsw@columbia.sparta.com| |________________________________________________________________________| Received: from relay.tis.com by neptune.TIS.COM id aa02715; 26 Feb 96 18:08 EST Received: by relay.tis.com; id SAA03002; Mon, 26 Feb 1996 18:10:25 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma002994; Mon, 26 Feb 96 18:09:56 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13875; Mon, 26 Feb 96 18:08:51 EST Received: by relay.tis.com; id SAA02991; Mon, 26 Feb 1996 18:09:55 -0500 Received: from unknown(206.1.51.15) by relay.tis.com via smap (V3.1) id xma002989; Mon, 26 Feb 96 18:09:48 -0500 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) with SMTP id SAA11257; Mon, 26 Feb 1996 18:10:18 -0500 (EST) Message-Id: <199602262310.SAA11257@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Howard Weiss Cc: William Allen Simpson , ipsec@TIS.COM Subject: Re: Sensitivity Labels In-Reply-To: Your message of "Mon, 26 Feb 1996 17:26:14 EST." <9602262226.AA09481@katahdin.columbia.sparta.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 26 Feb 1996 18:10:16 -0500 From: "Perry E. Metzger" Sender: ipsec-request@neptune.tis.com Precedence: bulk Howard Weiss writes: > > Moreover, these are examples of facilities for "explicit" labels, rather > > than "implicit" labels (indicated per SPI) used for IP Security. > > But why should "explict" labels be precluded? There are times when > they are explicitly needed (see below). The explicit labels are not precluded. They are handled automatically by the IPsec layer -- if a packet has a security label, it is preserved and handled just fine. We are talking about the key management layer, is not responsible for per packet explicit labeling, only implicit labeling of the SPI. Perry Received: from relay.tis.com by neptune.TIS.COM id aa06879; 26 Feb 96 21:51 EST Received: by relay.tis.com; id VAA05239; Mon, 26 Feb 1996 21:53:28 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma005235; Mon, 26 Feb 96 21:52:59 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19490; Mon, 26 Feb 96 21:51:54 EST Received: by relay.tis.com; id VAA05229; Mon, 26 Feb 1996 21:52:58 -0500 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1) id xma005225; Mon, 26 Feb 96 21:52:32 -0500 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id SAA03924; Mon, 26 Feb 1996 18:53:40 -0800 Received: by mailsun2.us.oracle.com (8.7.1/37.8) id SAA04538; Mon, 26 Feb 1996 18:55:49 -0800 (PST) Message-Id: <199602270255.SAA04538@mailsun2.us.oracle.com> Date: 26 Feb 96 18:17:42 -0800 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM, ipsec@ans.net Subject: Test-IGNORE!!!!!! Mime-Version: 1.0 Sender: ipsec-request@neptune.tis.com Precedence: bulk Please ignore this mailing list test ... Received: from relay.tis.com by neptune.TIS.COM id aa06878; 26 Feb 96 21:51 EST Received: by relay.tis.com; id VAA05240; Mon, 26 Feb 1996 21:53:28 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma005236; Mon, 26 Feb 96 21:53:03 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19489; Mon, 26 Feb 96 21:51:54 EST Received: by relay.tis.com; id VAA05230; Mon, 26 Feb 1996 21:52:58 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma005226; Mon, 26 Feb 96 21:52:37 -0500 Received: from inet-smtp-gw-1.us.oracle.com by interlock.ans.net with SMTP id AA07982 (InterLock SMTP Gateway 3.0 for ); Mon, 26 Feb 1996 21:53:36 -0500 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id SAA03924; Mon, 26 Feb 1996 18:53:40 -0800 Received: by mailsun2.us.oracle.com (8.7.1/37.8) id SAA04538; Mon, 26 Feb 1996 18:55:49 -0800 (PST) Message-Id: <199602270255.SAA04538@mailsun2.us.oracle.com> Date: 26 Feb 96 18:17:42 -0800 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM, ipsec@ans.net Subject: Test-IGNORE!!!!!! Mime-Version: 1.0 Sender: ipsec-request@neptune.tis.com Precedence: bulk Please ignore this mailing list test ... Received: from relay.tis.com by neptune.TIS.COM id aa07020; 26 Feb 96 21:59 EST Received: by relay.tis.com; id WAA05344; Mon, 26 Feb 1996 22:01:28 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma005342; Mon, 26 Feb 96 22:00:59 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19690; Mon, 26 Feb 96 21:59:54 EST Received: by relay.tis.com; id WAA05339; Mon, 26 Feb 1996 22:00:58 -0500 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1) id xma005336; Mon, 26 Feb 96 22:00:44 -0500 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id TAA32164; Mon, 26 Feb 1996 19:01:53 -0800 Received: by mailsun2.us.oracle.com (8.7.1/37.8) id TAA06978; Mon, 26 Feb 1996 19:04:02 -0800 (PST) Message-Id: <199602270304.TAA06978@mailsun2.us.oracle.com> Date: 26 Feb 96 15:59:10 -0800 From: "PALAMBER.US.ORACLE.COM" To: bill.simpson@um.cc.umich.edu Subject: Censure of Mr. Simpson Cc: ipsec@TIS.COM Mime-Version: 1.0 Sender: ipsec-request@neptune.tis.com Precedence: bulk Mr. Simpson, As a chairman of an Internet Engineering Task Force (IETF) working group I find myself in the difficult position of interpreting consensus as a means to mediate the activities of our committee. So, as a chairman (one of two) of the IP Security (IPSEC) working group, I must inform you of the consensus of the committee regarding your participation in this working group and the status of your submittals to this committee. There is strong consensus in the IPSEC working group that your behavior in this committee is unacceptable. There is strong consensus that your ongoing diatribe on the mailing list is detrimental to the progress of the working group. You continue to ignore direct requests by the chairs to edit specifications that you have submitted, so none of documents submitted by you to IPSEC reflect the working group consensus. Consensus does not belong to the individual with the loudest voice or the fastest typing fingers. You loudly declare group acceptance for documents that you submit, but offend, insult and ignore those that comment on these specifications. Your attempts to control the editing of working group specifications does not improve or expedite the creation of good technical documents, but can only be viewed as the self serving promotion of your own business interests and ego. Editors for a working group specification should not be allowed to select themselves by being the first to publish, but rather should be selected as the best individual to document a technical topic. You have taken advantage of flaws in the Internet process to subvert the orderly progression of technical ideas. By rushing to publish a document under your own name you ignore the contributions of others, and claim squatters rights on the technical domain of others. The design for the key management protocol Photuris was created by Phil Karn. Phil's consistent effort and valuable technical contributions have lead to our current IPSEC consensus on a "hybrid Diffie-Hellman STS-like" cryptographic mechanism. In December, you (Bill Simpson) were "fired" as Phil's supporting editor for the "Photuris" specification. You refused to edit the document to meet working group consensus and refused to step down as Phil's assistant in the documentation process. You asserted that you were an "author" of the Photuris specification and not an "editor". In this context you threatened both individuals and the IETF with a lawsuit if you were "removed". To avoid using any text that you might have generated, the chairs of the IPSEC working group have encouraged Hillary Orman to become the editor for the IPSEC key exchange specification. Her excellent effort has resulted in the draft-ietf-ipsec-oakley-00.txt specification. This specification is intended to meet the working group direction for a "hybrid Differ-Hellman STS-like" cryptographic mechanism. Your affiliation with the Photuris specification has resulted in a document that lacks clarity and group acceptance. I strongly encourage you to reexamine the "help" that you are giving to Mr. Karn. The "security transform" specifications in the IPSEC committee have also suffered from your "authorship". An editor, Jim Hughes, has been selected to edit working group specifications on the IPSEC security transforms. His first Internet Draft on this topic has been submitted and other transforms (IDEA, triple-DES, or others) will follow soon. I am confident that these documents will reflect the contributions and expert ice of the whole committee. Your belligerent and disruptive behavior in the IPSEC working group is not the first case of your misbehavior in Internet working groups. At least three other working groups have had to censure your participation. You consistently insult and intimidate members of Internet committees and manipulate the IETF to promote your own interests over those of the working groups. The interaction of the IETF by electronic mail has created a unique form of committee interaction that replaces meeting halls with e-mail lists, votes with consensus and membership with subscription. Disruptive behavior in any forum is unacceptable and the IETF will be forced by your actions to investigate suitable disciplinary actions in our network community. If this were a "physical" meeting run by Robert's Rules of Order, we could vote to have you expelled from the meeting. As chairman, I wish that we could "banish" you from our list and I am confident that a very large majority of the IPSEC mailing list would approve. In summary Mr. Simpson, your continued work on the Photuris specification, security transform specifications and your ongoing diatribes on this mailing list are detrimental to the progress of the IPSEC working group. I request that you abstain from making pronouncements on working group goals and group consensus. I suggest that you apologize to the working group and severely limit your postings to the IPSEC mailing list. Paul A. Lambert IPSEC Co-Chair Received: from relay.tis.com by neptune.TIS.COM id aa07419; 26 Feb 96 22:22 EST Received: by relay.tis.com; id WAA05518; Mon, 26 Feb 1996 22:24:28 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma005516; Mon, 26 Feb 96 22:24:00 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20158; Mon, 26 Feb 96 22:22:54 EST Received: by relay.tis.com; id WAA05511; Mon, 26 Feb 1996 22:23:58 -0500 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1) id xma005507; Mon, 26 Feb 96 22:23:51 -0500 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id TAA09507; Mon, 26 Feb 1996 19:24:35 -0800 Received: by mailsun2.us.oracle.com (8.7.1/37.8) id TAA09891; Mon, 26 Feb 1996 19:26:44 -0800 (PST) Message-Id: <199602270326.TAA09891@mailsun2.us.oracle.com> Date: 26 Feb 96 19:23:08 -0800 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: IPSEC Implementation Survey Cc: swan-dev@rsa.com Mime-Version: 1.0 Sender: ipsec-request@neptune.tis.com Precedence: bulk The following nine individuals and vendors have responded to the IPSEC implementation survey. ERPIPSEC ETHZ / ENskip IBM JI KA9Q NOS Morning Star SecureConnect Network Systems BorderGuard and Security Router NRL Sun ICG TimeStep PERMIT USC/ISI The results of this first survey (as of February 26, 1996) are provided below. _______________________________________________________________________ Name of Implementation: ERPIPSEC, BELLCORE, Antonio Fernandez Security Protocols: ESP, AH Security Transforms: ESP-DES, AH-MD5_128,64,32 Key Management: manual Location of Source Code: proprietary Point of Contact: Antonio Fernandez, afa@bellcore.com _______________________________________________________________________ Name of Implementation: ETHZ / ENskip Security Protocols: SKIP (draft 6), limited AH & ESP (SPI=1) Security Transforms: ESP-DES, ESP-3DES, ESP-IDEA, ESP-RC4, AH-MD5 (some of these transforms are not yet standarized) Key Management: only via SKIP, (manual, X.509 and 'DH public value' keying). (plus non-standardized PFS) Lineage of Code: Works under Solaris 2.4+, IRIX, NetBSD, Nextstep. Location of Source Code: ftp://ftp.tik.ee.ethz.ch/pub/packages/skip (X.509 and PFS not yet publicly available) Point of Contact: skip@tik.ee.ethz.ch _______________________________________________________________________ Name of Implementation: IBM Security Protocols: ESP, AH, both tunnel and transport mode Security Transforms: ESP-DES (32-bit and 64-bit IV), keyed-MD5, new keyed-MD5 proposed by Hugo Key Management : Manual+Fast Key Refreshment>, SKEME (in progress), Photuris (in Progress) Lineage of Code: IBM Proprietary, about 10k to 15K lines (rough estimate, including ESP, AH, and Key Management). Location of Source Code: Proprietary Point of Contact: pau@yktvmv.vnet.ibm.com _______________________________________________________________________ Name of Implementation: JI Security Protocols: ESP, AH, Protocol-4 encapsultation Security Transforms: ESP-DES, AH-MD5 Key Management: manual, Photuris; PF_ENCAP keying i/f, PF_ROUTE extensionsl Lineage of Code: Written from scratch, entirely in Greece, for BSD/OS 2.0, Location of Source Code: ji's home machine The promised end-January-96 release is not ready yet; it should be (freely) available from ftp.ripe.net RSN. Point of Contact: ji@hol.gr _______________________________________________________________________ Name of Implementation: KA9Q NOS Security Protocols: ESP, AH Security Transforms: ESP-DES & ESP-DES3, each with 0,32 and 64-bit IVs; keyed MD5 Key Management: manual Lineage of Code: scratch Location of Source Code: Not yet released. Will release soon, modulo export rules Point of Contact: karn@unix.ka9q.ampr.org ________________________________________________________________________ Name of Implementation: Morning Star SecureConnect Security Protocols: ESP, AH Security Transforms: ESP-DES, AH-MD5 Key Management: manual Lineage of Code: scratch Location of Source Code: proprietary Point of Contact: Karl Fox _______________________________________________________________________ Name of Implementation: Network Systems BorderGuard and Security Router Security Protocols: Proprietary Security Transforms: Des, Idea, 3DES, NSC1 (proprietary), MD5, Replay, D-H and RSA Key Management: Proprietary Lineage of Code: scratch Location of Source Code: proprietary Point of Contact: Ted Doty ________________________________________________________________________ Name of Implementation: NRL Security Protocols: ESP, AH -- for BOTH IPv4 and IPv6 Security Transforms: ESP-DES, AH-MD5 Key Management: manual, PF_KEY interface for key management daemons Lineage of Code: derived from and portable to 4.4-Lite BSD Location of Source Code: ftp://ftp.ripe.net/ipv6/nrl/IPv6_domestic.tar.gz for the September 1995 alpha release. January 1996 alpha-2 release is not yet at an ftp site, but should appear soon in the protected "US-only" archives at ftp.c2.org. Point of Contact: ipv6-bugs@cs.nrl.navy.mil _______________________________________________________________________ Name of Implementation: Sun ICG Security Protocols: ESP, AH, proprietary Security Transforms: ESP-DES, ESP-DES3, AH/KEYED MD5 Key Management: SKIP Lineage of Code: Location of Source Code: http://skip.incog.com Point of Contact: markson@incog.com _______________________________________________________________________ Name of Implementation: TimeStep PERMIT Security Protocols: ESP, AH, proprietary Security Transforms: ESP-DES Key Management: proprietary, manual Lineage of Code: from scratch Location of Source Code: proprietary Point of Contact: Stephane Lacelle slacelle@timestep.com _______________________________________________________________________ Name of Implementation: USC/ISI Security Protocols: IPv4 AH Security Transforms: null, Internet checksum, MD5, proprietary null and Internet checksum for performance measurement Key Management: Statically configured keys implementation for performance measurement only Lineage of Code: SunOS 4.1.3, using "from scratch" and code adapted from the NRL IPv6 BSDI implementation Location of Source Code: to be announced in March Point of Contact: Joe Touch, touch@isi.edu Received: from relay.tis.com by neptune.TIS.COM id aa07632; 26 Feb 96 22:32 EST Received: by relay.tis.com; id WAA05663; Mon, 26 Feb 1996 22:34:28 -0500 From: smb@research.att.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma005659; Mon, 26 Feb 96 22:34:00 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20377; Mon, 26 Feb 96 22:32:55 EST Received: by relay.tis.com; id WAA05650; Mon, 26 Feb 1996 22:33:58 -0500 Message-Id: <199602270333.WAA05650@relay.tis.com> Received: from ns.research.att.com(192.20.225.4) by relay.tis.com via smap (V3.1) id xma005644; Mon, 26 Feb 96 22:33:30 -0500 Received: from research.att.com by ns; Mon Feb 26 22:31:37 EST 1996 Received: from gryphon by research; Mon Feb 26 22:29:53 EST 1996 Received: by gryphon; Mon Feb 26 22:29:48 EST 1996 To: ipsec@TIS.COM Subject: Re: Sensitivity Labels Date: Mon, 26 Feb 96 22:29:47 EST Sender: ipsec-request@neptune.tis.com Precedence: bulk Count me as a supporter of sensitivity labels. Indeed, I've raised the issue in the past, when I pointed out the desirability for a mechanism by which hosts can inform encrypting routers of their ipsec needs. That is, if my own host is doing encryption, I can easily tell it to use 3DES or DES or ROT13 or what have you. If the encryptor is a separate box, be it a router or even a bump-in-the-cord encryptor, I need something going over the wire. Sensitivity labels are just one example of this, and not the only one. Received: from relay.tis.com by neptune.TIS.COM id aa07911; 26 Feb 96 22:47 EST Received: by relay.tis.com; id WAA05807; Mon, 26 Feb 1996 22:49:28 -0500 From: smb@research.att.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma005805; Mon, 26 Feb 96 22:48:59 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20701; Mon, 26 Feb 96 22:47:54 EST Received: by relay.tis.com; id WAA05802; Mon, 26 Feb 1996 22:48:58 -0500 Message-Id: <199602270348.WAA05802@relay.tis.com> Received: from ns.research.att.com(192.20.225.4) by relay.tis.com via smap (V3.1) id xma005800; Mon, 26 Feb 96 22:48:41 -0500 Received: from research.att.com by ns; Mon Feb 26 22:46:47 EST 1996 Received: from gryphon by research; Mon Feb 26 22:44:55 EST 1996 Received: by gryphon; Mon Feb 26 22:44:47 EST 1996 To: ipsec@TIS.COM Subject: traffic type header Cc: braden@isi.edu, minshall@ipsilon.com Date: Mon, 26 Feb 96 22:44:47 EST Sender: ipsec-request@neptune.tis.com Precedence: bulk The suggestion has been made that we should have an optional traffic type header. That is, we need something that will disclose protocol and port numbers. The purpose would be (a) to permit traffic measurements, and (b) to permit routers to optimize their handling of certain kinds of traffic. (And yes, it's optional, in case traffic analysis is your foe.) Neither IPv6 flows nor IPv4 traffic types are a substitute. Apart from the fact that the former isn't here yet and the latter isn't used, they just don't disclose enough information. But if you're engineering a network, you need to know these things. To give just one example, the amount of http traffic to particular places can be used to justify or refute the need for an organizational Web proxy. As a strawman proposal, let me propose the following header format: u_char next_proto; u_char this_proto; short pad; u_short src_port; u_short dst_port; Arguably, pad should be length, in which case we could have two optional fields: struct in_addr src_host, dst_host; to account for tunnel mode. (Tunnel mode is useful even if you're not trying to hide the host names.) An alternate mechanism would be to define new transforms; if nothing else, that would avoid adding yet another header to the protocol type namespace. It would also be simpler to implement; the obvious ways to do this in a BSD-derived kernel or a streams-based kernel just don't work very well. If there's enough interest (and, of course, not too much opposition), I'll volunteer to write a draft RFC. Received: from relay.tis.com by neptune.TIS.COM id aa09382; 27 Feb 96 0:12 EST Received: by relay.tis.com; id AAA06263; Tue, 27 Feb 1996 00:13:59 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma006261; Tue, 27 Feb 96 00:13:30 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22445; Tue, 27 Feb 96 00:12:25 EST Received: by relay.tis.com; id AAA06256; Tue, 27 Feb 1996 00:13:29 -0500 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1) id xma006251; Tue, 27 Feb 96 00:13:01 -0500 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id VAA21778; Mon, 26 Feb 1996 21:13:57 -0800 Received: by mailsun2.us.oracle.com (8.7.1/37.8) id VAA18728; Mon, 26 Feb 1996 21:16:06 -0800 (PST) Message-Id: <199602270516.VAA18728@mailsun2.us.oracle.com> Date: 26 Feb 96 21:12:31 -0800 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: Re: traffic type header Cc: majordomo-owner@neptune.tis.com X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-request@neptune.tis.com's message of 26-Feb-96 22:44 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Boundary-3510150-0-0 Sender: ipsec-request@neptune.tis.com Precedence: bulk --Boundary-3510150-0-0 Our new mail list system (ipsec@tis.com) retransmits messages in a manner that removes the originators name (at least for the info displayed by my e-mail system). Most messages arrive as "from: ipsec-request@neptune.tis.com". If messages are not "signed", they usually appear anonymous to me. This may be a useful feature, but if you want attribution for your note please add your name in a signature line. Thanks, Paul palamber@us.oracle.com --Boundary-3510150-0-0 Content-Type: message/rfc822 Date: 26 Feb 96 22:44:47 From:"ipsec-request@neptune.tis.com" To: ipsec@tis.com Subject: traffic type header Cc: braden@isi.edu,minshall@ipsilon.com X-Orcl-Application: Mmdf-Warning: Parse error in original version of preceding line at neptune.TIS.COM X-Orcl-Application: Sender: ipsec-request@neptune.tis.com X-Orcl-Application: Precedence: bulk The suggestion has been made that we should have an optional traffic type header. That is, we need something that will disclose protocol and port numbers. The purpose would be (a) to permit traffic measurements, and (b) to permit routers to optimize their handling of certain kinds of traffic. (And yes, it's optional, in case traffic analysis is your foe.) Neither IPv6 flows nor IPv4 traffic types are a substitute. Apart from the fact that the former isn't here yet and the latter isn't used, they just don't disclose enough information. But if you're engineering a network, you need to know these things. To give just one example, the amount of http traffic to particular places can be used to justify or refute the need for an organizational Web proxy. As a strawman proposal, let me propose the following header format: u_char next_proto; u_char this_proto; short pad; u_short src_port; u_short dst_port; Arguably, pad should be length, in which case we could have two optional fields: struct in_addr src_host, dst_host; to account for tunnel mode. (Tunnel mode is useful even if you're not trying to hide the host names.) An alternate mechanism would be to define new transforms; if nothing else, that would avoid adding yet another header to the protocol type namespace. It would also be simpler to implement; the obvious ways to do this in a BSD-derived kernel or a streams-based kernel just don't work very well. If there's enough interest (and, of course, not too much opposition), I'll volunteer to write a draft RFC. --Boundary-3510150-0-0-- Received: from relay.tis.com by neptune.TIS.COM id aa09469; 27 Feb 96 0:17 EST Received: by relay.tis.com; id AAA06316; Tue, 27 Feb 1996 00:19:29 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma006311; Tue, 27 Feb 96 00:19:01 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22552; Tue, 27 Feb 96 00:17:55 EST Received: by relay.tis.com; id AAA06308; Tue, 27 Feb 1996 00:18:59 -0500 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1) id xma006306; Tue, 27 Feb 96 00:18:32 -0500 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id VAA16961; Mon, 26 Feb 1996 21:19:21 -0800 Received: by mailsun2.us.oracle.com (8.7.1/37.8) id VAA19048; Mon, 26 Feb 1996 21:21:30 -0800 (PST) Message-Id: <199602270521.VAA19048@mailsun2.us.oracle.com> Date: 26 Feb 96 21:17:41 -0800 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: Re: IPSEC Implementation Survey Cc: swan-dev@rsa.com X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-request@neptune.tis.com's message of 26-Feb-96 19:23 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Boundary-3510176-0-0 Sender: ipsec-request@neptune.tis.com Precedence: bulk --Boundary-3510176-0-0 Oops, >The following nine individuals and vendors have responded to the IPSEC >implementation survey. Make that: The following eleven.... I suspect that there are other implementations. Any other implementations obviously must not be viable standards compliant products or they would be involved in the IETF process:-) Responses to the IPSEC survey are still solicited. 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 -------------------------------------------------------------- I have received many requests for information on ipsec implementations. Our working group also needs to coordinate interoperability testing among ourselves. To this end, would ipsec implementors please fill out the following survey and post your completed survey to the ipsec mailing list (ipsec@tis.com). Thanks in advance, Paul A. Lambert ipsec co-chair *************************** Attachement ******************** IPSEC Implementation Survey ************************************************************ Name of Implementation: Security Protocols: Security Transforms: Key Management: Lineage of Code: Location of Source Code: Point of Contact: ************************************************************ --Boundary-3510176-0-0 Content-Type: message/rfc822 Date: 26 Feb 96 19:23:08 From:"PALAMBER.US.ORACLE.COM" To: ipsec@tis.com Subject: IPSEC Implementation Survey Cc: swan-dev@rsa.com X-Orcl-Application: Mime-Version: 1.0 X-Orcl-Application: Sender: ipsec-request@neptune.tis.com X-Orcl-Application: Precedence: bulk The following nine individuals and vendors have responded to the IPSEC implementation survey. ERPIPSEC ETHZ / ENskip IBM JI KA9Q NOS Morning Star SecureConnect Network Systems BorderGuard and Security Router NRL Sun ICG TimeStep PERMIT USC/ISI The results of this first survey (as of February 26, 1996) are provided below. _______________________________________________________________________ Name of Implementation: ERPIPSEC, BELLCORE, Antonio Fernandez Security Protocols: ESP, AH Security Transforms: ESP-DES, AH-MD5_128,64,32 Key Management: manual Location of Source Code: proprietary Point of Contact: Antonio Fernandez, afa@bellcore.com _______________________________________________________________________ Name of Implementation: ETHZ / ENskip Security Protocols: SKIP (draft 6), limited AH & ESP (SPI=1) Security Transforms: ESP-DES, ESP-3DES, ESP-IDEA, ESP-RC4, AH-MD5 (some of these transforms are not yet standarized) Key Management: only via SKIP, (manual, X.509 and 'DH public value' keying). (plus non-standardized PFS) Lineage of Code: Works under Solaris 2.4+, IRIX, NetBSD, Nextstep. Location of Source Code: ftp://ftp.tik.ee.ethz.ch/pub/packages/skip (X.509 and PFS not yet publicly available) Point of Contact: skip@tik.ee.ethz.ch _______________________________________________________________________ Name of Implementation: IBM Security Protocols: ESP, AH, both tunnel and transport mode Security Transforms: ESP-DES (32-bit and 64-bit IV), keyed-MD5, new keyed-MD5 proposed by Hugo Key Management : Manual+Fast Key Refreshment>, SKEME (in progress), Photuris (in Progress) Lineage of Code: IBM Proprietary, about 10k to 15K lines (rough estimate, including ESP, AH, and Key Management). Location of Source Code: Proprietary Point of Contact: pau@yktvmv.vnet.ibm.com _______________________________________________________________________ Name of Implementation: JI Security Protocols: ESP, AH, Protocol-4 encapsultation Security Transforms: ESP-DES, AH-MD5 Key Management: manual, Photuris; PF_ENCAP keying i/f, PF_ROUTE extensionsl Lineage of Code: Written from scratch, entirely in Greece, for BSD/OS 2.0, Location of Source Code: ji's home machine The promised end-January-96 release is not ready yet; it should be (freely) available from ftp.ripe.net RSN. Point of Contact: ji@hol.gr _______________________________________________________________________ Name of Implementation: KA9Q NOS Security Protocols: ESP, AH Security Transforms: ESP-DES & ESP-DES3, each with 0,32 and 64-bit IVs; keyed MD5 Key Management: manual Lineage of Code: scratch Location of Source Code: Not yet released. Will release soon, modulo export rules Point of Contact: karn@unix.ka9q.ampr.org ________________________________________________________________________ Name of Implementation: Morning Star SecureConnect Security Protocols: ESP, AH Security Transforms: ESP-DES, AH-MD5 Key Management: manual Lineage of Code: scratch Location of Source Code: proprietary Point of Contact: Karl Fox _______________________________________________________________________ Name of Implementation: Network Systems BorderGuard and Security Router Security Protocols: Proprietary Security Transforms: Des, Idea, 3DES, NSC1 (proprietary), MD5, Replay, D-H and RSA Key Management: Proprietary Lineage of Code: scratch Location of Source Code: proprietary Point of Contact: Ted Doty ________________________________________________________________________ Name of Implementation: NRL Security Protocols: ESP, AH -- for BOTH IPv4 and IPv6 Security Transforms: ESP-DES, AH-MD5 Key Management: manual, PF_KEY interface for key management daemons Lineage of Code: derived from and portable to 4.4-Lite BSD Location of Source Code: ftp://ftp.ripe.net/ipv6/nrl/IPv6_domestic.tar.gz for the September 1995 alpha release. January 1996 alpha-2 release is not yet at an ftp site, but should appear soon in the protected "US-only" archives at ftp.c2.org. Point of Contact: ipv6-bugs@cs.nrl.navy.mil _______________________________________________________________________ Name of Implementation: Sun ICG Security Protocols: ESP, AH, proprietary Security Transforms: ESP-DES, ESP-DES3, AH/KEYED MD5 Key Management: SKIP Lineage of Code: Location of Source Code: http://skip.incog.com Point of Contact: markson@incog.com _______________________________________________________________________ Name of Implementation: TimeStep PERMIT Security Protocols: ESP, AH, proprietary Security Transforms: ESP-DES Key Management: proprietary, manual Lineage of Code: from scratch Location of Source Code: proprietary Point of Contact: Stephane Lacelle slacelle@timestep.com _______________________________________________________________________ Name of Implementation: USC/ISI Security Protocols: IPv4 AH Security Transforms: null, Internet checksum, MD5, proprietary null and Internet checksum for performance measurement Key Management: Statically configured keys implementation for performance measurement only Lineage of Code: SunOS 4.1.3, using "from scratch" and code adapted from the NRL IPv6 BSDI implementation Location of Source Code: to be announced in March Point of Contact: Joe Touch, touch@isi.edu --Boundary-3510176-0-0-- Received: from relay.tis.com by neptune.TIS.COM id aa10500; 27 Feb 96 1:12 EST Received: by relay.tis.com; id BAA06630; Tue, 27 Feb 1996 01:13:59 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma006628; Tue, 27 Feb 96 01:13:30 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA23543; Tue, 27 Feb 96 01:12:25 EST Received: by relay.tis.com; id BAA06625; Tue, 27 Feb 1996 01:13:29 -0500 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1) id xma006623; Tue, 27 Feb 96 01:13:02 -0500 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) with SMTP id BAA11586; Tue, 27 Feb 1996 01:13:34 -0500 (EST) Message-Id: <199602270613.BAA11586@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: "PALAMBER.US.ORACLE.COM" Cc: bill.simpson@um.cc.umich.edu, ipsec@TIS.COM, iesg@cnri.reston.va.us, jis@mit.edu, perry@piermont.com Subject: Re: Censure of Mr. Simpson In-Reply-To: Your message of "26 Feb 1996 15:59:10 PST." <199602270304.TAA06978@mailsun2.us.oracle.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 27 Feb 1996 01:13:33 -0500 From: "Perry E. Metzger" Sender: ipsec-request@neptune.tis.com Precedence: bulk I have carbon copied this message to the IESG. The text of the message which inspired it has been placed at the end. "PALAMBER.US.ORACLE.COM" writes: > In summary Mr. Simpson, your continued work on the Photuris specification, > security transform specifications and your ongoing diatribes on this mailing > list are detrimental to the progress of the IPSEC working group. I request > that you abstain from making pronouncements on working group goals and group > consensus. I suggest that you apologize to the working group and severely > limit your postings to the IPSEC mailing list. Paul; I must respectfully say that although I am not always the biggest fan of Bill's tone of voice, and although I agree that he is frequently more belligerent than many of us would like, 1) I cannot accept the tone of your message 2) I am strongly offended, as a member of this working group, by your choosing to air this matter in what I consider to be an extremely offensive way, and in public, and 3) it is not in your power as a chairman of a working group to censure or censor the members of the group in this manner, and it is improper of you to assert that you can do so, and it is furthermore improper for you to attempt to do so. I have personally been the subject of your fiat reinterpretation of the proper rules of procedure, as when you refused to allow the initial drafts that were published (the contents of which were ultimately adopted by the group) for the ipsec specification to be called draft-ietf-ipsec, in direct contravention of the interpretation of the rules for naming drafts that the POISED working group had arrived at. That move was arbitrary and capricious, but I felt it was unimportant so I chose not to pursue it, and the fact that the drafts in question were ultimately adopted in spite of the active opposition of the chair proved me right. You have demonstrated a tendancy towards arbitrary and capricious actions as chair at other times, such as in your unilateral changes to the group consensus of the Toronto IETF meeting during the course of the San Jose IETF meeting, but again I substantially ignored this as the Toronto proposal was adopted anyway, in spite of your opposition, so I decided not to pursue the matter. I will note, by the way, that it is rather unusual to have to constantly get the work of the group around of the efforts of the chair to derail it. This matter, however, cannot be left unpursued. Regardless of who is fit to edit our drafts, and whether or not Bill Simpson has been excessively beligerant, and whether Bill Simpson should be the editor of the Photuris documents, it is not, as you characterise it, the consensus of the working group that Bill Simpson is deserving of the sort of unmitigated vitriol that you have showered upon him, nor is it the consensus of the working group that one of our most hard working members -- in spite of his rather spirited manner -- be censored by the chairman of the working group. Your statement, and I quote: > I request that you abstain from making pronouncements on working > group goals and group consensus. I suggest that you [...] severely > limit your postings to the IPSEC mailing list. constitutes a totally unacceptable attempt to silence a working group member. As a chairman of a working group, you are, I am afraid, accountable to a much higher standard of behavior, especially in your public comportment, than any ordinary member of the working group would be. In making statements of this form, you must exercise extreme care because you are speaking as chair. The IETF process places substantial powers in the hands of the chair of a working group to report consensus and guide the actions of a working group, and as a result it is necessary that the chair of a working group be observed to be fair, diplomatic and worthy of the trust placed in him by the IETF community. I believe that you have severely violated that trust and ruptured all appearance of fairness. You mention Robert's Rules of Order. I must note that IETF working groups are not parliamentary bodies, do not vote, and are not subject to the parliamentary law. We operate, as many bodies do, based on our own customary procedure, developed over time via precedent and some charters like RFC1602. Under our customs, which have, I will note, the full force of a formal set of bylaws in most jurisdictions, your behavior has been improper. If you disliked what Bill Simpson had to say on the mailing lists, it was possible for you to ignore it. If you disliked the document he was editing, you were free to propose a new one, commission a new one, or write a new one. You have some power to request that he await his turn to speak during in-person meetings and use only a fair share of in-person time, but in general, you are not permitted as chair to silence working group members. Your action in requesting that Bill, in effect, remain silent, is wholely improper under our precedents and our customary rules of procedure. You add insult to injury by making your request in the form of an unmitigated diatribe. You also violate our customs concerning due process. According to that procedure, I must first bring this matter to the attention of the area director, Jeff Schiller, and permit him to examine the issue before formally requesting action on the part of the IESG. However, please be clear that I fully intend to ask that substantive action be taken in this matter. In my opinion, this sort of behavior cannot be tolerated, and I fully intend to pursue this matter to the furthest extent permitted under our rules of procedure. Perry E. Metzger Original message follows: Received: by mailsun2.us.oracle.com (8.7.1/37.8) id TAA06978; Mon, 26 Feb 1996 19:04:02 -0800 (PST) Message-Id: <199602270304.TAA06978@mailsun2.us.oracle.com> Date: 26 Feb 96 15:59:10 -0800 From: "PALAMBER.US.ORACLE.COM" To: bill.simpson@um.cc.umich.edu Subject: Censure of Mr. Simpson Cc: ipsec@TIS.COM Mime-Version: 1.0 Sender: ipsec-request@neptune.tis.com Precedence: bulk Mr. Simpson, As a chairman of an Internet Engineering Task Force (IETF) working group I find myself in the difficult position of interpreting consensus as a means to mediate the activities of our committee. So, as a chairman (one of two) of the IP Security (IPSEC) working group, I must inform you of the consensus of the committee regarding your participation in this working group and the status of your submittals to this committee. There is strong consensus in the IPSEC working group that your behavior in this committee is unacceptable. There is strong consensus that your ongoing diatribe on the mailing list is detrimental to the progress of the working group. You continue to ignore direct requests by the chairs to edit specifications that you have submitted, so none of documents submitted by you to IPSEC reflect the working group consensus. Consensus does not belong to the individual with the loudest voice or the fastest typing fingers. You loudly declare group acceptance for documents that you submit, but offend, insult and ignore those that comment on these specifications. Your attempts to control the editing of working group specifications does not improve or expedite the creation of good technical documents, but can only be viewed as the self serving promotion of your own business interests and ego. Editors for a working group specification should not be allowed to select themselves by being the first to publish, but rather should be selected as the best individual to document a technical topic. You have taken advantage of flaws in the Internet process to subvert the orderly progression of technical ideas. By rushing to publish a document under your own name you ignore the contributions of others, and claim squatters rights on the technical domain of others. The design for the key management protocol Photuris was created by Phil Karn. Phil's consistent effort and valuable technical contributions have lead to our current IPSEC consensus on a "hybrid Diffie-Hellman STS-like" cryptographic mechanism. In December, you (Bill Simpson) were "fired" as Phil's supporting editor for the "Photuris" specification. You refused to edit the document to meet working group consensus and refused to step down as Phil's assistant in the documentation process. You asserted that you were an "author" of the Photuris specification and not an "editor". In this context you threatened both individuals and the IETF with a lawsuit if you were "removed". To avoid using any text that you might have generated, the chairs of the IPSEC working group have encouraged Hillary Orman to become the editor for the IPSEC key exchange specification. Her excellent effort has resulted in the draft-ietf-ipsec-oakley-00.txt specification. This specification is intended to meet the working group direction for a "hybrid Differ-Hellman STS-like" cryptographic mechanism. Your affiliation with the Photuris specification has resulted in a document that lacks clarity and group acceptance. I strongly encourage you to reexamine the "help" that you are giving to Mr. Karn. The "security transform" specifications in the IPSEC committee have also suffered from your "authorship". An editor, Jim Hughes, has been selected to edit working group specifications on the IPSEC security transforms. His first Internet Draft on this topic has been submitted and other transforms (IDEA, triple-DES, or others) will follow soon. I am confident that these documents will reflect the contributions and expert ice of the whole committee. Your belligerent and disruptive behavior in the IPSEC working group is not the first case of your misbehavior in Internet working groups. At least three other working groups have had to censure your participation. You consistently insult and intimidate members of Internet committees and manipulate the IETF to promote your own interests over those of the working groups. The interaction of the IETF by electronic mail has created a unique form of committee interaction that replaces meeting halls with e-mail lists, votes with consensus and membership with subscription. Disruptive behavior in any forum is unacceptable and the IETF will be forced by your actions to investigate suitable disciplinary actions in our network community. If this were a "physical" meeting run by Robert's Rules of Order, we could vote to have you expelled from the meeting. As chairman, I wish that we could "banish" you from our list and I am confident that a very large majority of the IPSEC mailing list would approve. In summary Mr. Simpson, your continued work on the Photuris specification, security transform specifications and your ongoing diatribes on this mailing list are detrimental to the progress of the IPSEC working group. I request that you abstain from making pronouncements on working group goals and group consensus. I suggest that you apologize to the working group and severely limit your postings to the IPSEC mailing list. Paul A. Lambert IPSEC Co-Chair Received: from relay.tis.com by neptune.TIS.COM id aa11910; 27 Feb 96 2:37 EST Received: by relay.tis.com; id CAA07447; Tue, 27 Feb 1996 02:38:49 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma007445; Tue, 27 Feb 96 02:38:24 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25013; Tue, 27 Feb 96 02:37:15 EST Received: by relay.tis.com; id CAA07442; Tue, 27 Feb 1996 02:38:19 -0500 Received: from info.forthnet.gr(139.91.1.17) by relay.tis.com via smap (V3.1) id xma007440; Tue, 27 Feb 96 02:37:48 -0500 Received: from vicky.forthnet.gr by info.forthnet.gr via FORTHnet with SMTP; id JAA26877 (8.6.12/FORTHNET-2.0); Tue, 27 Feb 1996 09:34:41 +0200 (EET DST) Message-Id: <199602270734.JAA26877@info.forthnet.gr> Organization: To: "PALAMBER.US.ORACLE.COM" Cc: bill.simpson@um.cc.umich.edu, ipsec@TIS.COM Subject: Re: Censure of Mr. Simpson (longish) In-Reply-To: Your message of "26 Feb 1996 15:59:10 PST." <199602270304.TAA06978@mailsun2.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <29568.825406486.1@forthnet.gr> Date: Tue, 27 Feb 1996 09:34:46 +0200 From: "Angelos D. Keromytis" MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Sender: ipsec-request@neptune.tis.com Precedence: bulk In message <199602270304.TAA06978@mailsun2.us.oracle.com>, "PALAMBER.US.ORACLE. COM" writes: > >As a chairman of an Internet Engineering Task Force (IETF) working group I >find myself in the difficult position of interpreting consensus as a means to >mediate the activities of our committee. So, as a chairman (one of two) of >the IP Security (IPSEC) working group, I must inform you of the consensus of >the committee regarding your participation in this working group and the >status of your submittals to this committee. There is strong consensus in the > >IPSEC working group that your behavior in this committee is unacceptable. Is there such consensus ? Excuse my doubts. Exactly *HOW* did you decide that the WG felt that way ? It's been 2.5 months since the last IETF meeting, and you've pretty much kept silent on this matter during this time. So either you met a large percentage of the WG (again, excuse my doubts), you received lots of protest mail (in which case i'd like to take a look at them, headers and other ID stripped if necessary), you just kept silent so far (why ?), or you just decided there is consensus. >There is strong consensus that your ongoing diatribe on the mailing list is >detrimental to the progress of the working group. You continue to ignore >direct requests by the chairs to edit specifications that you have submitted, >so none of documents submitted by you to IPSEC reflect the working group >consensus. > I believe the matter of the SLs was/is under discussion ? In this matter at least, my opinion is very much like Bill's; i also believe there are others who want to discuss the issue, rather than let the chair(s) enforce a decision (myself, i believe SLs should not concern us). >Consensus does not belong to the individual with the loudest voice or the >fastest typing fingers. You loudly declare group acceptance for documents >that you submit, but offend, insult and ignore those that comment on these >specifications. Your attempts to control the editing of working group >specifications does not improve or expedite the creation of good technical >documents, but can only be viewed as the self serving promotion of your own >business interests and ego. > Offend ? Insult ? I'll admit Bill is not the easiest person to persuade to do a change in a draft he's editing, but more often that not he's accepted my (and at least another person's) corrections/modifications. I've also found your mail offensive and quite insulting; certainly not the kind of mail i'd expect from a WG chair. The language is quite extreme, to say the least. >both individuals and the IETF with a lawsuit if you were "removed". To avoid >using any text that you might have generated, the chairs of the IPSEC working >group have encouraged Hillary Orman to become the editor for the IPSEC key >exchange specification. Her excellent effort has resulted in the >draft-ietf-ipsec-oakley-00.txt specification. This specification is intended >to meet the working group direction for a "hybrid Differ-Hellman STS-like" While i do believe Hillary is a very suitable editor, i STRONGLY (and i can't possibly emphasize that) object to the way you remove Bill from the process. >cryptographic mechanism. Your affiliation with the Photuris specification has >resulted in a document that lacks clarity and group acceptance. I strongly >encourage you to reexamine the "help" that you are giving to Mr. Karn. > That is for Phil to say. >The "security transform" specifications in the IPSEC committee have also >suffered from your "authorship". An editor, Jim Hughes, has been selected to >edit working group specifications on the IPSEC security transforms. His first >Internet Draft on this topic has been submitted and other transforms (IDEA, >triple-DES, or others) will follow soon. I am confident that these documents >will reflect the contributions and expert ice of the whole committee. > Would you care to be more specific on how the security transform specifications have suffered ? The new draft is far from perfect (actually, i consider it several steps backwards); nothing that can't be fixed, but.... >Your belligerent and disruptive behavior in the IPSEC working group is not the >first case of your misbehavior in Internet working groups. At least three >other working groups have had to censure your participation. You consistently >insult and intimidate members of Internet committees and manipulate the IETF >to promote your own interests over those of the working groups. > Care to back this statement on "promoting his own interests" ? >The interaction of the IETF by electronic mail has created a unique form of >committee interaction that replaces meeting halls with e-mail lists, votes >with consensus and membership with subscription. Disruptive behavior in any >forum is unacceptable and the IETF will be forced by your actions to >investigate suitable disciplinary actions in our network community. If this >were a "physical" meeting run by Robert's Rules of Order, we could vote to >have you expelled from the meeting. As chairman, I wish that we could >"banish" you from our list and I am confident that a very large majority of >the IPSEC mailing list would approve. > WHAT ?!? I'm not overly familiar with what a WG chair can do, but i'm fairly certain this is one of the things he can't (or shouldn't). >In summary Mr. Simpson, your continued work on the Photuris specification, >security transform specifications and your ongoing diatribes on this mailing >list are detrimental to the progress of the IPSEC working group. I request >that you abstain from making pronouncements on working group goals and group >consensus. I suggest that you apologize to the working group and severely >limit your postings to the IPSEC mailing list. > Apologize for having a loud voice, ignoring the chair in favour of discussion within the WG and filling our mailboxes ? I'd like to hear what Ran has to say. -Angelos Received: from relay.tis.com by neptune.TIS.COM id aa18082; 27 Feb 96 8:24 EST Received: by relay.tis.com; id IAA08955; Tue, 27 Feb 1996 08:26:23 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma008934; Tue, 27 Feb 96 08:25:57 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03923; Tue, 27 Feb 96 08:24:48 EST Received: by relay.tis.com; id IAA08928; Tue, 27 Feb 1996 08:25:52 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma008920; Tue, 27 Feb 96 08:25:46 -0500 Received: from snad.ncsl.nist.gov by interlock.ans.net with SMTP id AA17293 (InterLock SMTP Gateway 3.0 for ); Tue, 27 Feb 1996 08:26:45 -0500 Received: from sloth.ncsl.nist.gov by snad.ncsl.nist.gov (4.1/SMI-4.0-MHS-7.0) id AA00567; Tue, 27 Feb 96 08:26:50 EST Date: Tue, 27 Feb 96 08:26:50 EST From: Robert Glenn Message-Id: <9602271326.AA00567@snad.ncsl.nist.gov> To: ipsec@ans.net Subject: IPSEC Implementation Survey: NIST/NSA Sender: ipsec-request@neptune.tis.com Precedence: bulk --------------------------- IPSEC Implementation Survey Name of Implementation: NIST/NSA ESP/AH Implementation Security Protocols: ESP, AH Security Transforms: ESP-DES, AH-MD5, AH-SHA, and various others Key Management: manual, PF_SADB interface for key management daemons Lineage of Code: derived from BSD platforms. Successful installation on BSD/OS, NetBSD, FreeBSD, and DTOS Location of Source Code: Public distribution within the US expected March 1996. Point of Contact: glenn@snad.ncsl.nist.gov --------------------------- Received: from relay.tis.com by neptune.TIS.COM id aa18081; 27 Feb 96 8:24 EST Received: by relay.tis.com; id IAA08953; Tue, 27 Feb 1996 08:26:23 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma008933; Tue, 27 Feb 96 08:25:53 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03924; Tue, 27 Feb 96 08:24:48 EST Received: by relay.tis.com; id IAA08927; Tue, 27 Feb 1996 08:25:52 -0500 Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1) id xma008900; Tue, 27 Feb 96 08:25:29 -0500 Received: from hawpub.watson.ibm.com ([9.2.90.19]) by igw2.watson.ibm.com (8.7.4/8.7.4) with SMTP id IAA21515 for ; Tue, 27 Feb 1996 08:26:36 -0500 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/2/16/96) id AA17516; Tue, 27 Feb 1996 08:26:29 -0500 Message-Id: <9602271326.AA17516@hawpub.watson.ibm.com> Subject: Re: Sensitivity Labels To: ipsec@TIS.COM Date: Tue, 27 Feb 1996 08:26:29 -0500 (EST) From: Uri Blumenthal In-Reply-To: <199602270333.WAA05650@relay.tis.com> from "smb@research.att.com" at Feb 26, 96 10:29:47 pm X-External-Networks: yes Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-request@neptune.tis.com Precedence: bulk smb@research.att.com writes: > Count me as a supporter of sensitivity labels. Me too. Enough of reasons were given here for me to repeat them. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- Received: from relay.tis.com by neptune.TIS.COM id aa19471; 27 Feb 96 9:42 EST Received: by relay.tis.com; id JAA10667; Tue, 27 Feb 1996 09:44:22 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma010657; Tue, 27 Feb 96 09:43:53 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08874; Tue, 27 Feb 96 09:42:48 EST Received: by relay.tis.com; id JAA10652; Tue, 27 Feb 1996 09:43:52 -0500 Received: from raptor.com(204.7.243.11) by relay.tis.com via smap (V3.1) id xma010638; Tue, 27 Feb 96 09:43:30 -0500 Received: from raptor1.raptor.com ([204.7.242.10]) by eagle1.raptor.com via smtpd (for relay.tis.com [192.94.214.100]) with SMTP; 27 Feb 1996 14:43:23 UT Received: from jefe (jefe.raptor.com [204.7.242.32]) by raptor1.raptor.com (8.7.3/8.7.3) with SMTP id JAA07760; Tue, 27 Feb 1996 09:44:21 -0500 (EST) Date: Tue, 27 Feb 1996 09:44:21 -0500 (EST) Message-Id: <199602271444.JAA07760@raptor1.raptor.com> X-Sender: jkraemer@raptor1 X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PALAMBER@us.oracle.com From: jeff kraemer Subject: IPSEC Implementation Survey Cc: ipsec@TIS.COM Sender: ipsec-request@neptune.tis.com Precedence: bulk IPSEC Implementation Survey Name of Implementation: Raptor Systems Security Protocols: ESP, AH, both tunnel and transport modes Security Transforms: ESP-DES (32-bit and 64-bit IV), keyed-MD5 Key Management: manual Lineage of Code: proprietary Location of Source Code: proprietary Point of Contact: jkraemer@raptor.com Received: from relay.tis.com by neptune.TIS.COM id aa20330; 27 Feb 96 10:07 EST Received: by relay.tis.com; id KAA11525; Tue, 27 Feb 1996 10:09:22 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma011517; Tue, 27 Feb 96 10:09:02 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10649; Tue, 27 Feb 96 10:07:48 EST Received: by relay.tis.com; id KAA11512; Tue, 27 Feb 1996 10:08:52 -0500 Received: from unknown(128.19.0.20) by relay.tis.com via smap (V3.1) id xma011503; Tue, 27 Feb 96 10:08:47 -0500 Received: (from martin@localhost) by spica.disa.mil (8.6.10/8.6.10) id KAA05871; Tue, 27 Feb 1996 10:12:01 -0500 Date: Tue, 27 Feb 1996 10:12:01 -0500 From: "Cynthia E. Martin" Message-Id: <199602271512.KAA05871@spica.disa.mil> To: ipsec@TIS.COM, uri@watson.ibm.com Subject: Re: Sensitivity Labels Cc: martin@spica.disa.mil Sender: ipsec-request@neptune.tis.com Precedence: bulk smb@research.att.com writes: > Count me as a supporter of sensitivity labels. uri@watson.ibm.com writes: > Me too. Enough of reasons were given here for me to repeat them. I strongly agree also- for the same reasons. - Cynthia Received: from relay.tis.com by neptune.TIS.COM id aa20775; 27 Feb 96 10:19 EST Received: by relay.tis.com; id KAA11834; Tue, 27 Feb 1996 10:21:22 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma011825; Tue, 27 Feb 96 10:20:54 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA11521; Tue, 27 Feb 96 10:19:48 EST Received: by relay.tis.com; id KAA11818; Tue, 27 Feb 1996 10:20:52 -0500 Received: from unknown(35.1.1.42) by relay.tis.com via smap (V3.1) id xma011814; Tue, 27 Feb 96 10:20:46 -0500 Received: from Bill.Simpson.DialUp.Mich.Net (pm036-04.dialip.mich.net [141.211.7.46]) by merit.edu (8.7.3/merit-2.0) with SMTP id KAA25224 for ; Tue, 27 Feb 1996 10:21:42 -0500 (EST) Date: Mon, 26 Feb 96 21:12:22 GMT From: William Allen Simpson Message-Id: <4992.wsimpson@greendragon.com> To: ipsec@TIS.COM Subject: Call for AH-SHA and ESP-3DES to move forward Sender: ipsec-request@neptune.tis.com Precedence: bulk While I'm thinking about it, we also have sufficient experience with SHA and 3DES to move them from Experimental to Proposed. According to RFC-1602, page 14: Typically, such a specification will be published initially with Experimental or Prototype status (see below), and moved to the standards track only after sufficient implementation or operational experience has been obtained. There seems to be a strong interest in both specifications, and implementations have appeared from Karn and NIST. Bill.Simpson@um.cc.umich.edu 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 aa20776; 27 Feb 96 10:19 EST Received: by relay.tis.com; id KAA11835; Tue, 27 Feb 1996 10:21:22 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma011826; Tue, 27 Feb 96 10:20:54 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA11522; Tue, 27 Feb 96 10:19:48 EST Received: by relay.tis.com; id KAA11817; Tue, 27 Feb 1996 10:20:52 -0500 Received: from unknown(35.1.1.42) by relay.tis.com via smap (V3.1) id xma011813; Tue, 27 Feb 96 10:20:45 -0500 Received: from Bill.Simpson.DialUp.Mich.Net (pm036-04.dialip.mich.net [141.211.7.46]) by merit.edu (8.7.3/merit-2.0) with SMTP id KAA25221 for ; Tue, 27 Feb 1996 10:21:39 -0500 (EST) Date: Mon, 26 Feb 96 20:34:35 GMT From: William Allen Simpson Message-Id: <4991.wsimpson@greendragon.com> To: ipsec@TIS.COM Subject: Call for AH-MD5 and ESP-DES to move forward Sender: ipsec-request@neptune.tis.com Precedence: bulk > From: Ran Atkinson > % B) Since RFC-1828 and RFC-1829 are more than ready to go to Draft > % Standard, but interoperability of Sensitivity Labels has not been > % demonstrated, by RFC-1602 we MUST remove Sensitivity Labels from our > % official WG documents. > > RFC-1828 and RFC-1829 are NOT ready to go to Draft Standard. In Why not? After all, they have the implementations required by RFC-1602, page 14: A specification from which at least two independent and interoperable implementations have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. We have existence proff that the specifications are specified with sufficient clarity to be implemented internationally! > fact, they CANNOT go to Draft Standard because RFC-1825 through RFC-1827 > are not ready to move forward. > RFC-1825 through -1827 are only advancable by experience on -1828 and RFC-1829 -- not the other way around! The former are dependent on implementations of the latter. And you did promise revisions to your RFCs which have not appeared. But, that shouldn't stop the forward progress of the others.... > Further, RFC-1829 is known to be vulnerable to active attacks. > I do not understand. I have seen no new references to attacks on RFC-1829 mentioned on this list since the RFCs were published. The only attack that I am aware of is that described to us by Steve Bellovin last April. It is clearly referenced in the Security Considerations section, as is the use of AH to prevent the attack. Are you now substituting your personal judgement for both WG consensus and IETF consensus? > % Then, you have not followed the Standards Process in RFC-1602. The time > % for updating them is upon us. > > False. We are NOT required to move them forward at the first opportunity > to do so. There is no process violation in waiting until things are > ready to move forward. > Why should they wait for other (tardy) drafts, on which advancement they are not dependent? The implementors desire an expeditious and stable specification. And yes, delaying the Standards Process indefinitely is a process violation in and of itself. That's one of the reasons we have target times, in both Standards Process and the WG Charter.... Is it your personal position that only WG Chair(s) (the royal "We") are "permitted" to ask the WG for an advance on the standards track, and the rest of us must patiently await their pleasure? Bill.Simpson@um.cc.umich.edu 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 aa21697; 27 Feb 96 10:46 EST Received: by relay.tis.com; id KAA12628; Tue, 27 Feb 1996 10:47:57 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma012621; Tue, 27 Feb 96 10:47:28 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13665; Tue, 27 Feb 96 10:46:23 EST Received: by relay.tis.com; id KAA12618; Tue, 27 Feb 1996 10:47:27 -0500 Received: from beach.sctc.com(192.55.214.50) by relay.tis.com via smap (V3.1) id xma012612; Tue, 27 Feb 96 10:47:14 -0500 Received: from beach.sctc.com (daemon@localhost) by beach.sctc.com (8.7.2/8.7.2) with ESMTP id JAA25327 for ; Tue, 27 Feb 1996 09:48:28 -0600 (CST) Received: from sphinx.sctc.com (sphinx.sctc.com [172.17.192.3]) by beach.sctc.com (8.7.2/8.7.2) with ESMTP id JAA25322 for ; Tue, 27 Feb 1996 09:48:27 -0600 (CST) Received: from shade.sctc.com (shade.sctc.com [172.17.192.48]) by sphinx.sctc.com (8.7.1/8.6.10) with SMTP id JAA02937 for ; Tue, 27 Feb 1996 09:48:52 -0600 (CST) Received: (from bnelson@localhost) by shade.sctc.com (8.6.12/8.6.9) id JAA13295 for ipsec@tis.com; Tue, 27 Feb 1996 09:48:52 -0600 From: Brett Nelson Message-Id: <199602271548.JAA13295@shade.sctc.com> Subject: Re: IPSEC Implementation Survey (fwd) To: ipsec@TIS.COM Date: Tue, 27 Feb 1996 09:48:52 -0600 (CST) Company: Secure Computing Corp. Phone: 612.628.1636 Fax: 612.628.2701 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-request@neptune.tis.com Precedence: bulk Forwarded message: >From bnelson@sctc.com Tue Feb 27 09:40 CST 1996 From: Brett Nelson Message-Id: <199602271539.JAA12672@shade.sctc.com> Subject: Re: IPSEC Implementation Survey To: PALAMBER@us.oracle.com (PALAMBER.US.ORACLE.COM) Date: Tue, 27 Feb 1996 09:39:07 -0600 (CST) Cc: swan-dev@RSA.COM In-Reply-To: <199602270341.TAA11268@mailsun2.us.oracle.com> from "PALAMBER.US.ORACLE.COM" at Feb 26, 96 07:34:19 pm Company: Secure Computing Corp. Phone: 612.628.1636 Fax: 612.628.2701 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Content-Length: 558 IPSEC Implementation Survey ************************************************************ Name of Implementation: Secure Computing's Sidewinder Firewall Security Protocols: ESP, AH Security Transforms: DES, MD5 Key Management: manual Lineage of Code: BSD based Location of Source Code: proprietary Point of Contact: Troy de Jongh (dejongh@sctc.com) ************************************************************ -- Brett Nelson Secure Computing Corp. 2675 Long Lake Road Roseville, MN 55113 -- Brett Nelson Secure Computing Corp. 2675 Long Lake Road Roseville, MN 55113 Received: from relay.tis.com by neptune.TIS.COM id aa23679; 27 Feb 96 12:18 EST Received: by relay.tis.com; id MAA14339; Tue, 27 Feb 1996 12:20:29 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma014326; Tue, 27 Feb 96 12:19:57 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19910; Tue, 27 Feb 96 12:18:52 EST Received: by relay.tis.com; id MAA14323; Tue, 27 Feb 1996 12:19:56 -0500 Received: from merit.edu(35.1.1.42) by relay.tis.com via smap (V3.1) id xma014316; Tue, 27 Feb 96 12:19:36 -0500 Received: from Bill.Simpson.DialUp.Mich.Net (pm012-05.dialip.mich.net [141.211.7.173]) by merit.edu (8.7.3/merit-2.0) with SMTP id MAA28499 for ; Tue, 27 Feb 1996 12:20:30 -0500 (EST) Date: Tue, 27 Feb 96 16:29:04 GMT From: William Allen Simpson Message-Id: <4994.wsimpson@greendragon.com> To: ipsec@TIS.COM Cc: iesg@cnri.reston.va.us Subject: Re: Censure of Mr. Simpson Sender: ipsec-request@neptune.tis.com Precedence: bulk I have been privately asked not to reply in detail. Thank you all for your public and private support. In support of Perry's refutation, I will note that this _personal_ animus and _private_ determination of "consensus" was somehow arrived at _before_ I submitted my very first "intentionally disruptive" draft to this WG, as evidenced by following excerpt: From: Paul_Lambert-P15452@email.mot.com Date: 16 Jan 95 13:25:00 -0600 To: Internet-Drafts@CNRI.Reston.VA.US Subject: Re: draft-ietf-ipsec-ah-00.txt Message-Id: Dear Sirs, As working group co-chair of the IETF IP Security Working Group I am writing in regarding to four recently submitted Internet Drafts (I-D) from Bill Simpson and Perry Metzger. The I-D guidelines indicate that you have some control over the naming of these documents. The documents currently have been submitted as: draft-ietf-ipsec-esp-00.txt draft-ietf-ipsec-esp-des-cbc-00.txt draft-ietf-ipsec-ah-00.txt draft-ietf-ipsec-ah-md5-00.txt I would like to request that the names of these I-Ds not include "ietf-ipsec" and that the drafts be identified by the author of the document: draft-simpson-esp-00.txt draft-simpson-esp-des-cbc-00.txt draft-simpson-ah-00.txt draft-simpson-ah-md5-00.txt or draft-metzger- ... etc. An editing team of six people is currently generating a single document that will cover the techniques contained in these drafts. This document will be published this week and represents the "consensus" version of the above mechanisms. Creating new "ipsec-esp" and "ipsec-ah" documents does not represent the working group direction or work items. The strength of the IETF process is based on allowing a diversity of contributions and opinions to be expressed through the I-Ds. Bill and Perry are free to submit I-D drafts, but their current timing and approach is intentionally disruptive to the working group. I will also note that no such "single document" was ever posted and may never have existed. The WG ultimately overturned the Chair's decision in this matter. Bill.Simpson@um.cc.umich.edu 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 aa28427; 27 Feb 96 16:04 EST Received: by relay.tis.com; id QAA18129; Tue, 27 Feb 1996 16:05:50 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma018120; Tue, 27 Feb 96 16:05:29 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02235; Tue, 27 Feb 96 16:04:20 EST Received: by relay.tis.com; id QAA18109; Tue, 27 Feb 1996 16:05:23 -0500 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1) id xma018087; Tue, 27 Feb 96 16:04:48 -0500 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id NAA17231; Tue, 27 Feb 1996 13:05:56 -0800 Received: by mailsun2.us.oracle.com (8.7.1/37.8) id NAA08364; Tue, 27 Feb 1996 13:07:53 -0800 (PST) Message-Id: <199602272107.NAA08364@mailsun2.us.oracle.com> Date: 27 Feb 96 13:02:21 -0800 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: Fwd: IPSEC Implementation Cc: naganand@ftp.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Boundary-3523924-0-0 Sender: ipsec-request@neptune.tis.com Precedence: bulk --Boundary-3523924-0-0 Thanks Naganand, Paul ------------- --Boundary-3523924-0-0 Content-Type: message/rfc822 Date: 27 Feb 96 08:53:16 From:"Naganand Doraswamy" To: palamber@us.oracle.com Subject: IPSEC Implementation X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Version 2.0.3 X-Orcl-Application: Mime-Version: 1.0 X-Orcl-Application: Content-Type: text/plain; charset="us-ascii" Paul, I will have working code by the end of the week. However, I thought I would send this to you so that you could include this in the next update you send on implementations. Thanks, IPSEC Implementation Survey Name of Implementation: FTP Software Security Protocols: AH and ESP Security Transforms: ESP-DES, NULL, AH-MD5 Key Management: Manual Lineage of Code: Written from scratch. Looked at NRL implementation. Location of Source Code: Proprietary Point of Contact: naganand@ftp.com --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)659-6743 (O) --Boundary-3523924-0-0-- Received: from relay.tis.com by neptune.TIS.COM id aa03154; 27 Feb 96 19:55 EST Received: by relay.tis.com; id TAA21935; Tue, 27 Feb 1996 19:57:41 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma021930; Tue, 27 Feb 96 19:57:12 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08560; Tue, 27 Feb 96 19:56:08 EST Received: by relay.tis.com; id TAA21927; Tue, 27 Feb 1996 19:57:11 -0500 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1) id xma021925; Tue, 27 Feb 96 19:57:07 -0500 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id QAA10466; Tue, 27 Feb 1996 16:58:16 -0800 Received: by mailsun2.us.oracle.com (8.7.1/37.8) id RAA06943; Tue, 27 Feb 1996 17:00:07 -0800 (PST) Message-Id: <199602280100.RAA06943@mailsun2.us.oracle.com> Date: 27 Feb 96 16:46:02 -0800 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: Re: IPSEC Implementation Survey Mime-Version: 1.0 Sender: ipsec-request@neptune.tis.com Precedence: bulk >From:"Bob Rybicki " >To: PALAMBER@us.oracle.com >Subject: Re: IPSEC Implementation Survey >Cc: dotis@v-one.com,jswang@v-one.com,ttang@v-one.com > > > >Name of Implementation: V-ONE SmartWall >Security Protocols: ESP, AH Tunnel and Transport modes, V-ONE > Mutual Authentication >Security Transforms: ESP-DES, ESP-3DES, RC4, Stream-DES >Key Management: Custom, manual >Lineage of Code: NRL derived, BSD/OS >Location of Source Code: proprietary >Point of Contact: Jason Wang, jswang@v-one.com > > > > >V-ONE Corporation "Security for a Connected World" >Bob Rybicki, >V.P. Business Development >Tel# 301-838-8900 >Fax# 301-838-8909 Received: from relay.tis.com by neptune.TIS.COM id aa06865; 27 Feb 96 22:31 EST Received: by relay.tis.com; id WAA23706; Tue, 27 Feb 1996 22:33:32 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma023702; Tue, 27 Feb 96 22:33:04 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10624; Tue, 27 Feb 96 22:31:58 EST Received: by relay.tis.com; id WAA23699; Tue, 27 Feb 1996 22:33:02 -0500 Received: from mercury.sun.com(192.9.25.1) by relay.tis.com via smap (V3.1) id xma023697; Tue, 27 Feb 96 22:32:56 -0500 Received: by mercury.Sun.COM (Sun.COM) id IAA05501; Tue, 27 Feb 1996 08:16:30 -0800 Received: from sabretooth.Eng.Sun.COM (sabretooth-46.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17337; Tue, 27 Feb 1996 08:15:04 -0800 Received: from elrond.Eng.Sun.COM by sabretooth.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id IAA02595; Tue, 27 Feb 1996 08:14:52 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id IAA18839; Tue, 27 Feb 1996 08:13:53 -0800 Date: Tue, 27 Feb 1996 08:13:53 -0800 From: Dan Nessett Message-Id: <199602271613.IAA18839@elrond.Eng.Sun.COM> To: PALAMBER@us.oracle.com, perry@piermont.com Subject: Re: Censure of Mr. Simpson Cc: bill.simpson@um.cc.umich.edu, ipsec@TIS.COM, iesg@cnri.reston.va.us, jis@mit.edu X-Sun-Charset: US-ASCII Sender: ipsec-request@neptune.tis.com Precedence: bulk To the members of the IPSEC working group, I am no longer active in this group, having moved on to other duties. However, based on prior interactions with Mr. Simpson, I fully support the move by Paul Lambert to attempt to bring order into the working group proceedings. As evidence I hereby make public a post Mr. Simpson sent to me in regards to in-band keying. I have retained a record of the prior email on this topic, which I believe shows Mr. Simpson had no reason to adopt an insulting and scurrilous writing style. It is interesting that Mr. Simpson's defender in this controversy is Mr. Metzger. Dan Nessett ====== From Bill.Simpson@um.cc.umich.edu Wed Mar 15 06:25:01 1995 To: Danny.Nessett@Eng (Dan Nessett) Cc: perry@imsi.com Subject: reserved SAID values Perry, will you please shut up on this issue. If this fellow is such an asshole that he can't read "for future use", and such an incompetent that he can't write a draft on how to use one, then he deserves to sink in his own shit. He's just trying to piggyback on our work. You, Ran, Jeff, Ted, Deering and I have all said "write a draft". You are just dragging out the debate, by giving him a prompt to reply. Just leave it alone. Ignore him until he has a draft. That's how we work. > From: Danny.Nessett@eng.sun.com (Dan Nessett) > the value of this field shall be 0x00000000. The set of SAID values > in the range 0x00000001 through 0x000000FF are reserved for future > use. > > There is similar language in the ESP I-D. I read this to mean that the > reserved values are "reserved," i.e., not to be used, since they may > be used for some unspecified purpose in the future. If the security documents > are modified to indicate an SAID value that is to mean, "using in-band > keying," then what you say would be true. However, at present it is not. > Bill.Simpson@um.cc.umich.edu Received: from relay.tis.com by neptune.TIS.COM id aa12011; 28 Feb 96 2:47 EST Received: by relay.tis.com; id CAA25341; Wed, 28 Feb 1996 02:48:34 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma025338; Wed, 28 Feb 96 02:48:05 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13608; Wed, 28 Feb 96 02:47:00 EST Received: by relay.tis.com; id CAA25335; Wed, 28 Feb 1996 02:48:04 -0500 Received: from unknown(194.30.193.159) by relay.tis.com via smap (V3.1) id xma025333; Wed, 28 Feb 96 02:47:27 -0500 Received: from del.tla.org (root@ppp52.hol.gr [194.30.192.168]) by prometheus.hol.gr (8.6.12/8.6.12) with ESMTP id JAA29040 for ; Wed, 28 Feb 1996 09:44:19 -0200 Received: from del.tla.org (ji@localhost.tla.org [127.0.0.1]) by del.tla.org (8.7.2/8.6.9) with ESMTP id JAA01763 for ; Wed, 28 Feb 1996 09:45:19 +0200 (EET) Message-Id: <199602280745.JAA01763@del.tla.org> X-Mailer: exmh version 1.6.2 7/18/95 To: ipsec@TIS.COM Subject: Re: Censure of Mr. Simpson In-Reply-To: Dan Nesset's message of "Tue, 27 Feb 1996 08:13:53 PST." <199602271613.IAA18839@elrond.Eng.Sun.COM> Reply-To: ji@hol.gr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Feb 1996 09:45:13 +0200 From: John Ioannidis Sender: ipsec-request@neptune.tis.com Precedence: bulk I find this entire debate to be a *personal* attack on Bill Simpson, and not an attack on his work based on its technical merits. This is simply unacceptable. I urge everybody involved to calm down and re-evaluate their positions. I have stayed silent so far, but I think it is time I spoke up. Remember that we are primarily a *technical* group (and one in a very important area), and we cannot allow technical work to be hindered by personal animosity. Furthermore, whatever Mr. Simpson's failings may be (and I am not necessarily implying there are any), the behavior of a segment of this working group has far exceeded what would be considered acceptable, polite, and civilized. Name-calling and ad hominem attacks have no place here, and some people seem to have fogotten that. Besides, summarily rejecting someone's work because of that someone's alleged personality traits is, to say the least, detrimental to the progress of the group as a whole. Mr. Nessett's mail is what prompted my involvement in this thread, so let me comment on a few points: > [ Dan Nesset's message of "Tue, 27 Feb 1996 08:13:53 PST." <199602271613.IAA18839@elrond.Eng.Sun.COM> ] > To the members of the IPSEC working group, > > I am no longer active in this group, having moved on to other duties. However, > based on prior interactions with Mr. Simpson, I fully support the move by > Paul Lambert to attempt to bring order into the working group proceedings. So you are admitting that you do not know the particulars of this case, and that your reasons for wanting Mr. Simpson silenced are personal, not based on the technical merits of his work. Wonderful! > As evidence I hereby make public a post Mr. Simpson sent to me in regards > to in-band keying. I have retained a record of the prior email on this Maybe my mailer ate it, but there is no date on that message. How recent is it? If it upset you so much, why didn't you bring it to the immediate attention of the group? Elementary good manners dictate that you do not make public a private piece of email without the author's consent. Is *your* proper behavior a function of other people's behavior? And in any case, I don't see a PGP (or other) signature. For all we know, you fabricated this. > topic, which I believe shows Mr. Simpson had no reason to adopt an insulting > and scurrilous writing style. I read the piece of mail. I cannot tell from it whether Mr. Simpson had a reason to adopt what you are calling "insulting and scurrilous." What I see is that you are making public a private piece of e-mail, an act which I (and many others, for that matter) consider unethical. > It is interesting that Mr. Simpson's defender > in this controversy is Mr. Metzger. Your point being? You seem to be implying that there is something wrong about being defended by Mr. Metzger. Whatever your personal animosity towards Mr. Metzger may be, the fact that he is defending Mr. Simpson does not ipso facto imply that the defense should be considered invalid. > > Dan Nessett > /ji Received: from relay.tis.com by neptune.TIS.COM id aa17280; 28 Feb 96 7:43 EST Received: by relay.tis.com; id HAA27208; Wed, 28 Feb 1996 07:45:02 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma027203; Wed, 28 Feb 96 07:44:34 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA17291; Wed, 28 Feb 96 07:43:29 EST Received: by relay.tis.com; id HAA27196; Wed, 28 Feb 1996 07:44:32 -0500 Received: from charrua.bellcore.com(192.4.6.118) by relay.tis.com via smap (V3.1) id xma027190; Wed, 28 Feb 96 07:44:26 -0500 Received: (from afa@localhost) by charrua.bellcore.com (8.6.9/8.6.10) id HAA00714; Wed, 28 Feb 1996 07:44:58 -0500 Date: Wed, 28 Feb 1996 07:44:58 -0500 (EST) From: Antonio Fernandez X-Sender: afa@charrua To: John Ioannidis Cc: ipsec@TIS.COM Subject: Re: Censure of Mr. Simpson In-Reply-To: <199602280745.JAA01763@del.tla.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipsec-request@neptune.tis.com Precedence: bulk On Wed, 28 Feb 1996, John Ioannidis wrote: > I find this entire debate to be a *personal* attack on Bill Simpson, and not > an attack on his work based on its technical merits. This is simply > unacceptable. I urge everybody involved to calm down and re-evaluate their > positions. > Right on target JI, and I fully agree with you Antonio Received: from relay.tis.com by neptune.TIS.COM id aa20553; 28 Feb 96 10:16 EST Received: by relay.tis.com; id KAA00131; Wed, 28 Feb 1996 10:18:35 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma000126; Wed, 28 Feb 96 10:18:08 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25565; Wed, 28 Feb 96 10:17:03 EST Received: by relay.tis.com; id KAA29999; Wed, 28 Feb 1996 10:18:06 -0500 Received: from labs-n.bbn.com(128.89.0.100) by relay.tis.com via smap (V3.1) id xma029989; Wed, 28 Feb 96 10:17:48 -0500 Received: from ARA20.BBN.COM by LABS-N.BBN.COM id aa21094; 28 Feb 96 10:15 EST X-Sender: kent@eudora.bbn.com (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 28 Feb 1996 10:17:48 -0500 To: ji@hol.gr From: Stephen Kent Subject: Re: Censure of Mr. Simpson Cc: ipsec@TIS.COM Sender: ipsec-request@neptune.tis.com Precedence: bulk John, Let me add my support to Paul's censure of Bill, from the perspective of someone who has been involved with the IPSEC WG from the beginning, who has attended a number (though not all) of the Wg meetings, and who reads most of the mail list traffic. I dislike censuring in this context, but I have to admit that Bill's actions in this WG have created a situation that merits such action. Bill's interaction with people via email is almost always very rude and intimidating. I have been the target of some of Bill's tirades in various contexts and have watched him "flame" many others on this and other mailing lists. This behavior has had a chilling effect on some people, causing them to contribute less than they might otherwise. The result is detrimental to the advancement of work in any area and I think we have seen the effects of that in this WG. Several individuals have approached me over the last couple of years and noted that they were deterred from participating in mailing list exchanges becaue of the likelihood of rousing Bill's ire. In another vein, Bill's work as a document editor has been a mixed blessing. The IETF relies on voulenteers to do the real work of standards production and Bill's offer to write a document contributing to that work is laudable. However, the work of this group has suffered from very poor documents in general and several members have cited Bill's documentation of Photuris as an example of specification that does not facilitate independent interoperable implementation. Your individual experience to the contrary, this complaint about Bill's writing still stands. Moreover, Bill's reluctance to make changes to documents based on direction from the WG chairs raises serious questions as to his suitability as an editor for a document of this sort. You suggest that personal animosity has no place in a technical group such as this one, yet it is precisely Bill's personal attacks on individuals that have caused the animosity and resulted in his censure. Any standards activity is a social activity involving individuals with differing technical and personal agendas. A successful WG must integrate these agendas to produce a documents that represent appropriate tradeoffs arrived at via a technical and social process. Bill's behavior has skewed this process and this response from the WG chair is a response to this behavior. Steve Received: from relay.tis.com by neptune.TIS.COM id aa22155; 28 Feb 96 11:06 EST Received: by relay.tis.com; id LAA01703; Wed, 28 Feb 1996 11:08:00 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma001699; Wed, 28 Feb 96 11:07:32 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA29293; Wed, 28 Feb 96 11:06:26 EST Received: by relay.tis.com; id LAA01696; Wed, 28 Feb 1996 11:07:30 -0500 Received: from mercury.sun.com(192.9.25.1) by relay.tis.com via smap (V3.1) id xma001685; Wed, 28 Feb 96 11:07:03 -0500 Received: by mercury.Sun.COM (Sun.COM) id IAA29669; Wed, 28 Feb 1996 08:06:59 -0800 Received: from sabretooth.Eng.Sun.COM (sabretooth-23.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24361; Wed, 28 Feb 1996 08:06:39 -0800 Received: from elrond.Eng.Sun.COM by sabretooth.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id IAA10004; Wed, 28 Feb 1996 08:06:34 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id IAA20108; Wed, 28 Feb 1996 08:05:32 -0800 Date: Wed, 28 Feb 1996 08:05:32 -0800 From: Dan Nessett Message-Id: <199602281605.IAA20108@elrond.Eng.Sun.COM> To: ipsec@TIS.COM, ji@hol.gr Subject: Re: Censure of Mr. Simpson X-Sun-Charset: US-ASCII Sender: ipsec-request@neptune.tis.com Precedence: bulk > > So you are admitting that you do not know the particulars of this case, and > that your reasons for wanting Mr. Simpson silenced are personal, not based on > the technical merits of his work. Wonderful! I believe my post was significant evidence that I do know the particulars of this case. The censure of Mr. Simpson has nothing to do with the technical merits of his work. It addresses his unacceptible behavior in the conduct of IETF work. > > As evidence I hereby make public a post Mr. Simpson sent to me in regards > > to in-band keying. I have retained a record of the prior email on this > > Maybe my mailer ate it, but there is no date on that message. How recent is > it? If it upset you so much, why didn't you bring it to the immediate > attention of the group? Elementary good manners dictate that you do not make > public a private piece of email without the author's consent. Is *your* proper > behavior a function of other people's behavior? And in any case, I don't see a > PGP (or other) signature. For all we know, you fabricated this. Let me address your points in order. There was a date on the message, it was Wed Mar 15 06:25:01 1995. I brought it to the attention of the IESG at the time. If someone writes me a letter threating my life or the well being of my family, I have no obligation to keep it private. In the same vein, if someone is employing terrorist tactics to ensure his point of view prevails, I have no obligation to keep these tactics private. For all you know the complete record of this working group email list is fabricated. You don't even know if Dan Nessett sent this message. > > topic, which I believe shows Mr. Simpson had no reason to adopt an insulting > > and scurrilous writing style. > > I read the piece of mail. I cannot tell from it whether Mr. Simpson had a > reason to adopt what you are calling "insulting and scurrilous." What I see is > that you are making public a private piece of e-mail, an act which I (and many > others, for that matter) consider unethical. In regards to the ethics of divulging mail sent to me privately, see above. If you believe there are any circumstances in which the writing style of the message in question is excusable, then we have no basis for a continued exploration of this topic. > > > It is interesting that Mr. Simpson's defender > > in this controversy is Mr. Metzger. > > Your point being? You seem to be implying that there is something wrong about > being defended by Mr. Metzger. Whatever your personal animosity towards Mr. > Metzger may be, the fact that he is defending Mr. Simpson does not ipso facto > imply that the defense should be considered invalid. > The point is that Mr. Metzger's defense of Mr. Simpson may be biased. The evidence for this is the statement by Mr. Simpson that "He's just trying to piggyback on our work." Dan Nessett Received: from relay.tis.com by neptune.TIS.COM id aa25575; 28 Feb 96 13:30 EST Received: by relay.tis.com; id NAA05249; Wed, 28 Feb 1996 13:32:06 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma005239; Wed, 28 Feb 96 13:31:38 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA07796; Wed, 28 Feb 96 13:30:33 EST Received: by relay.tis.com; id NAA05232; Wed, 28 Feb 1996 13:31:36 -0500 Received: from info.forthnet.gr(139.91.1.17) by relay.tis.com via smap (V3.1) id xma005214; Wed, 28 Feb 96 13:31:06 -0500 Received: from info.forthnet.gr by info.forthnet.gr via FORTHnet with SMTP; id UAA09233 (8.6.12/FORTHNET-2.0); Wed, 28 Feb 1996 20:28:25 +0200 (EET DST) Message-Id: <199602281828.UAA09233@info.forthnet.gr> Organization: To: Dan Nessett Cc: ipsec@TIS.COM, ji@hol.gr Subject: Re: Censure of Mr. Simpson In-Reply-To: Your message of "Wed, 28 Feb 1996 08:05:32 PST." <199602281605.IAA20108@elrond.Eng.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <9199.825532088.1@forthnet.gr> Date: Wed, 28 Feb 1996 20:28:09 +0200 From: "Angelos D. Keromytis" Sender: ipsec-request@neptune.tis.com Precedence: bulk In message <199602281605.IAA20108@elrond.Eng.Sun.COM>, Dan Nessett writes: > >I believe my post was significant evidence that I do know the particulars of >this case. The censure of Mr. Simpson has nothing to do with the technical >merits of his work. It addresses his unacceptible behavior in the conduct >of IETF work. > Speaking for myself, the exerpt you sent didn't prove anything about your knowledge of the case. >Let me address your points in order. There was a date on the message, it was >Wed Mar 15 06:25:01 1995. I brought it to the attention of the IESG at the >time. If someone writes me a letter threating my life or the well being of my >family, I have no obligation to keep it private. In the same vein, if >someone is employing terrorist tactics to ensure his point of view prevails, >I have no obligation to keep these tactics private. For all you know the >complete record of this working group email list is fabricated. You don't >even know if Dan Nessett sent this message. > Sending in public private communications without asking permission first sounds like "terrorist" tactics to me. >In regards to the ethics of divulging mail sent to me privately, see above. >If you believe there are any circumstances in which the writing style of >the message in question is excusable, then we have no basis for a continued >exploration of this topic. > A lot can be said on this, but let's not open a can of worms. >The point is that Mr. Metzger's defense of Mr. Simpson may be biased. The >evidence for this is the statement by Mr. Simpson that "He's just trying to >piggyback on our work." > Biased ? I guess cooperating with Mr. Simpson might make someone object to another's views that it's impossible to work with him. Again, this seems more like a personal attack than a well thought action of a WG chair. -Angelos Received: from relay.tis.com by neptune.TIS.COM id aa29315; 28 Feb 96 15:52 EST Received: by relay.tis.com; id PAA07551; Wed, 28 Feb 1996 15:54:29 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma007542; Wed, 28 Feb 96 15:54:06 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA15732; Wed, 28 Feb 96 15:53:01 EST Received: by relay.tis.com; id PAA07529; Wed, 28 Feb 1996 15:54:03 -0500 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1) id xma007512; Wed, 28 Feb 96 15:53:35 -0500 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) with SMTP id PAA16286; Wed, 28 Feb 1996 15:54:16 -0500 (EST) Message-Id: <199602282054.PAA16286@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Stephen Kent Cc: ji@hol.gr, ipsec@TIS.COM Subject: Re: Censure of Mr. Simpson In-Reply-To: Your message of "Wed, 28 Feb 1996 10:17:48 EST." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 28 Feb 1996 15:54:08 -0500 From: "Perry E. Metzger" Sender: ipsec-request@neptune.tis.com Precedence: bulk Stephen Kent writes: > The IETF relies on voulenteers to do the real work of standards > production and Bill's offer to write a document contributing to that work > is laudable. However, the work of this group has suffered from very poor > documents in general and several members have cited Bill's documentation of > Photuris as an example of specification that does not facilitate > independent interoperable implementation. Your individual experience to > the contrary, this complaint about Bill's writing still stands. Are we angry with Bill for being rude, or are we angry with him because he is a poor writer? I would hate to think that one could be censured for being a poor writer. I will add, however, that in my opinion Bill is a very good writer from an implementors perspective. Perry Received: from relay.tis.com by neptune.TIS.COM id aa01213; 28 Feb 96 17:06 EST Received: by relay.tis.com; id RAA08912; Wed, 28 Feb 1996 17:08:30 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma008896; Wed, 28 Feb 96 17:08:02 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20220; Wed, 28 Feb 96 17:06:56 EST Received: by relay.tis.com; id RAA08883; Wed, 28 Feb 1996 17:08:00 -0500 Received: from info.forthnet.gr(139.91.1.17) by relay.tis.com via smap (V3.1) id xma008875; Wed, 28 Feb 96 17:07:53 -0500 Received: from vicky.forthnet.gr by info.forthnet.gr via FORTHnet with SMTP; id XAA25536 (8.6.12/FORTHNET-2.0); Wed, 28 Feb 1996 23:58:38 +0200 (EET DST) Message-Id: <199602282158.XAA25536@info.forthnet.gr> Organization: To: perry@piermont.com Cc: Stephen Kent , ji@hol.gr, ipsec@TIS.COM Subject: Re: Censure of Mr. Simpson In-Reply-To: Your message of "Wed, 28 Feb 1996 15:54:08 EST." <199602282054.PAA16286@jekyll.piermont.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <28513.825544722.1@forthnet.gr> Date: Wed, 28 Feb 1996 23:58:42 +0200 From: "Angelos D. Keromytis" Sender: ipsec-request@neptune.tis.com Precedence: bulk In message <199602282054.PAA16286@jekyll.piermont.com>, "Perry E. Metzger" writ es: > >Are we angry with Bill for being rude, or are we angry with him >because he is a poor writer? I would hate to think that one could be >censured for being a poor writer. I will add, however, that in my >opinion Bill is a very good writer from an implementors perspective. > I might add here that Bill has asked me a few (hundred) times if this part of the Photuris draft is clear enough, or if that part needs refining. He sent me a copy of the last 2 (or 3?) drafts a few days before they were publically available, to check for errors - and i wasn't the only one. -Angelos Received: from relay.tis.com by neptune.TIS.COM id aa08321; 28 Feb 96 23:38 EST Received: by relay.tis.com; id XAA13550; Wed, 28 Feb 1996 23:40:07 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma013547; Wed, 28 Feb 96 23:39:38 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28385; Wed, 28 Feb 96 23:38:33 EST Received: by relay.tis.com; id XAA13544; Wed, 28 Feb 1996 23:39:37 -0500 Received: from uucp2.netcom.com(163.179.3.2) by relay.tis.com via smap (V3.1) id xma013542; Wed, 28 Feb 96 23:39:36 -0500 Received: by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id UAA22459; Wed, 28 Feb 1996 20:32:19 -0800 Received: from cc:Mail by spysouth.spyrus.com id AA825567603 Wed, 28 Feb 96 20:20:03 Date: Wed, 28 Feb 96 20:20:03 From: "Housley, Russ" Encoding: 223 Text Message-Id: <9601288255.AA825567603@spysouth.spyrus.com> To: ipsec@TIS.COM Subject: Re: Sensitivity Labels Sender: ipsec-request@neptune.tis.com Precedence: bulk smb@research.att.com writes: > Count me as a supporter of sensitivity labels. Me too. Sensitivity labels must be an attribute of a security association. IEEE 802.10c already supports sensitivity labels. ;) Russ Received: from relay.tis.com by neptune.TIS.COM id aa24587; 29 Feb 96 14:25 EST Received: by relay.tis.com; id OAA24226; Thu, 29 Feb 1996 14:27:24 -0500 From: hugo@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma024216; Thu, 29 Feb 96 14:26:55 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27947; Thu, 29 Feb 96 14:25:51 EST Received: by relay.tis.com; id OAA24213; Thu, 29 Feb 1996 14:26:54 -0500 Message-Id: <199602291926.OAA24213@relay.tis.com> Received: from watson.ibm.com(129.34.139.4) by relay.tis.com via smap (V3.1) id xma024211; Thu, 29 Feb 96 14:26:43 -0500 Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 2789; Thu, 29 Feb 96 14:26:02 EST Date: Thu, 29 Feb 96 13:49:30 EST To: ipsec@TIS.COM Cc: rja@cisco.com, PALAMBER@us.oracle.com Subject: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward Sender: ipsec-request@neptune.tis.com Precedence: bulk Ref: Your note of Mon, 26 Feb 96 20:34:35 GMT (attached) I suggest NOT moving forward RFC1828. Let's replace that transform by the keyed-MD5 transform of Bellare, Canetti and Krawczyk, as described in draft-krawczyk-keyed-md5-01.txt. (This function is now named HMAC). This new transform has a strong cryptographic analysis supporting it. The paper showing that (see below) has been presented in several public forums (including RSA conference and MIT's crypto seminar), and has been widely circulated to cryptographers and security experts in the last two months. The feedback has been overwhelming positive (no one objection to its security or analysis). The proposal was warmly welcome in general when I presented it in Dallas' IETF (only the authors of RFC1828 objected). It was in the meantime adopted into a few other protocols. I know of two independent implementations for use with IPSEC/AH. I believe it has all the merits and formal requirements to become an RFC and the DEFAULT transform for AH. I would like this WG to make a decision in that regard. Sincereley and unpolitically (;-) Hugo PS: for those who still didn't read the paper :-) Bellare, M., Canetti, R., and Krawczyk, H., "Keyed Hash Functions and Message Authentication". http://www.research.ibm.com/security/keyed-md5.html Clarification: the name HMAC as used in the paper does not appear in the internet draft draft-krawczyk-keyed-md5-01.txt. However, the described function is the same. Received: from relay.tis.com by neptune.TIS.COM id aa26732; 29 Feb 96 16:07 EST Received: by relay.tis.com; id QAA26012; Thu, 29 Feb 1996 16:08:56 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma026003; Thu, 29 Feb 96 16:08:26 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA07451; Thu, 29 Feb 96 16:07:22 EST Received: by relay.tis.com; id QAA25998; Thu, 29 Feb 1996 16:08:25 -0500 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1) id xma025994; Thu, 29 Feb 96 16:08:20 -0500 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) with SMTP id QAA18882; Thu, 29 Feb 1996 16:09:21 -0500 (EST) Message-Id: <199602292109.QAA18882@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: hugo@watson.ibm.com Cc: ipsec@TIS.COM, rja@cisco.com, PALAMBER@us.oracle.com Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward In-Reply-To: Your message of "Thu, 29 Feb 1996 13:49:30 EST." <199602291926.OAA24213@relay.tis.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Thu, 29 Feb 1996 16:09:19 -0500 From: "Perry E. Metzger" Sender: ipsec-request@neptune.tis.com Precedence: bulk hugo@watson.ibm.com writes: > Ref: Your note of Mon, 26 Feb 96 20:34:35 GMT (attached) > > I suggest NOT moving forward RFC1828. > > Let's replace that transform by the keyed-MD5 transform > of Bellare, Canetti and Krawczyk, > as described in draft-krawczyk-keyed-md5-01.txt. > (This function is now named HMAC). I have no problem with the idea of ultimately advancing the HMAC transform to standard, especially after it has been out for a good while and there has been additional opportunity for cryptographers to attack it, but I disagree with the words "replace". As Paul's survey reveals, many implementations currently implement 1828. Let us instead speak of requiring this new superior transform rather than of "replacing" the old one, which would imply, for example, that identifiers for 1828 in key management protocols would have to point at HMAC instead, which would result in interoperability problems. Perry Received: from relay.tis.com by neptune.TIS.COM id aa27319; 29 Feb 96 16:32 EST Received: by relay.tis.com; id QAA26675; Thu, 29 Feb 1996 16:34:26 -0500 From: hugo@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma026657; Thu, 29 Feb 96 16:33:56 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA09414; Thu, 29 Feb 96 16:32:52 EST Received: by relay.tis.com; id QAA26653; Thu, 29 Feb 1996 16:33:54 -0500 Message-Id: <199602292133.QAA26653@relay.tis.com> Received: from watson.ibm.com(129.34.139.4) by relay.tis.com via smap (V3.1) id xma026644; Thu, 29 Feb 96 16:33:31 -0500 Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 5303; Thu, 29 Feb 96 16:34:02 EST Date: Thu, 29 Feb 96 16:22:35 EST To: perry@piermont.com Cc: ipsec@TIS.COM Subject: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward Sender: ipsec-request@neptune.tis.com Precedence: bulk Ref: Your note of Thu, 29 Feb 1996 16:09:19 -0500 (attached) Perry, > > I have no problem with the idea of ultimately advancing the HMAC > transform to standard, especially after it has been out for a good > while and there has been additional opportunity for cryptographers to > attack it, but I disagree with the words "replace". As Paul's survey > reveals, many implementations currently implement 1828. Let us instead > speak of requiring this new superior transform rather than of > "replacing" the old one, which would imply, for example, that > identifiers for 1828 in key management protocols would have to point > at HMAC instead, which would result in interoperability problems. What I want is that implementations *do* move to this new function. We are doing a lot of implementation work regarding IPSEC, and we talk to many other implementation people involved with IPSEC. The message is very clear: no one has any real problem to implement the new transform, however they will not do that as long as there is another one that is *officially* required by the IPSEC standard. We need to find a way to break this loop. I don't care about the word "replace" just about making clear that IPSEC-AH REQUIRES HMAC (as the default implementation). As a general note: if we can't modify the standards during the standarization process why do we have that process in place. Implementors need to know (and we know!) that changes will occur. This particular one is easy to implement and upgrade. If the decision is that it is too late to change the default algorithm I would recommend this group to be even more careful on any decision about moving any document to standards track. Hugo Received: from relay.tis.com by neptune.TIS.COM id aa27621; 29 Feb 96 16:50 EST Received: by relay.tis.com; id QAA27094; Thu, 29 Feb 1996 16:51:59 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma027082; Thu, 29 Feb 96 16:51:30 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10525; Thu, 29 Feb 96 16:50:26 EST Received: by relay.tis.com; id QAA27079; Thu, 29 Feb 1996 16:51:29 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma027072; Thu, 29 Feb 96 16:51:14 -0500 Received: from inet-smtp-gw-1.us.oracle.com by interlock.ans.net with SMTP id AA29358 (InterLock SMTP Gateway 3.0 for ); Thu, 29 Feb 1996 16:52:12 -0500 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id NAA09891; Thu, 29 Feb 1996 13:52:19 -0800 Received: by mailsun2.us.oracle.com (8.7.1/37.8) id NAA18059; Thu, 29 Feb 1996 13:54:11 -0800 (PST) Message-Id: <199602292154.NAA18059@mailsun2.us.oracle.com> Date: 29 Feb 96 13:36:29 -0800 From: "PALAMBER.US.ORACLE.COM" To: perry@piermont.com Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward Cc: ipsec@ans.net X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:perry@piermont.com's message of 29-Feb-96 16:09 Mime-Version: 1.0 Sender: ipsec-request@neptune.tis.com Precedence: bulk >but I disagree with the words "replace". As Paul's survey >reveals, many implementations currently implement 1828. There has been very strong support for the use of HMAC as the "standard" transform for AH. A "change" of this mechanism sooner, rather than later, would limit the impact on implementors. 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 aa27736; 29 Feb 96 16:52 EST Received: by relay.tis.com; id QAA27133; Thu, 29 Feb 1996 16:54:29 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma027130; Thu, 29 Feb 96 16:54:00 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10645; Thu, 29 Feb 96 16:52:56 EST Received: by relay.tis.com; id QAA27124; Thu, 29 Feb 1996 16:53:59 -0500 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1) id xma027119; Thu, 29 Feb 96 16:53:54 -0500 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) with SMTP id QAA18966; Thu, 29 Feb 1996 16:54:56 -0500 (EST) Message-Id: <199602292154.QAA18966@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: hugo@watson.ibm.com Cc: ipsec@TIS.COM Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward In-Reply-To: Your message of "Thu, 29 Feb 1996 16:22:35 EST." <199602292135.QAA26356@linet02.li.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Thu, 29 Feb 1996 16:54:52 -0500 From: "Perry E. Metzger" Sender: ipsec-request@neptune.tis.com Precedence: bulk hugo@watson.ibm.com writes: > We need to find a way to break this loop. I don't care about the word > "replace" just about making clear that IPSEC-AH REQUIRES HMAC > (as the default implementation). Thats fine, so long as we don't speak of "replacing", and so long as we take some time to allow people to examine the transform. I would want to see some considerable time taken between the time that an HMAC based RFC is issued and the time it is advanced. No personal slight intended, Hugo, but I've learned at this point that the only way to get certainty out of cryptographers is to wait a year or two for the dust to settle thoroughly. I fully believe your statements that no one who has seen your work has had any trouble with it, but recall that similar statements were made the last time around -- it would be better if we gave it some time. This isn't to say we should advance something else in its place, you understand. It is just to say we should be more carefull. > As a general note: if we can't modify the standards during the > standarization process why do we have that process in place. We can alter what is standard. However, it is often bad to alter what already exists. When SMTP got revised, an extensions mechanism was created -- existing SMTPs weren't broken. Sometime soon it will be required that SMTP implementations support ESMTP, but it will doubtless be a long while before ESMTP is totally universal, if ever. Perry Received: from relay.tis.com by neptune.TIS.COM id aa29546; 29 Feb 96 18:15 EST Received: by relay.tis.com; id SAA29041; Thu, 29 Feb 1996 18:17:09 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma029034; Thu, 29 Feb 96 18:16:40 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA14540; Thu, 29 Feb 96 18:15:36 EST Received: by relay.tis.com; id SAA29024; Thu, 29 Feb 1996 18:16:38 -0500 Received: from unknown(198.82.204.99) by relay.tis.com via smap (V3.1) id xma029013; Thu, 29 Feb 96 18:16:17 -0500 Received: from inner.net ([192.168.1.1]) by inner.net (8.7.4/42) with ESMTP id OAA02007; Thu, 29 Feb 1996 14:19:55 -0500 Message-Id: <199602291919.OAA02007@inner.net> X-Mailer: exmh version 1.6.5 12/11/95 To: hugo@watson.ibm.com Cc: ipsec@TIS.COM Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward In-Reply-To: Your message of "Thu, 29 Feb 1996 16:22:35 EST." <199602292133.QAA26653@relay.tis.com> X-Reposting-Policy: With explicit permission only Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 Feb 1996 18:16:57 -0500 From: Craig Metz Sender: ipsec-request@neptune.tis.com Precedence: bulk In message <199602292133.QAA26653@relay.tis.com>, you write: >What I want is that implementations *do* move to this new function. >We are doing a lot of implementation work regarding IPSEC, and we talk >to many other implementation people involved with IPSEC. >The message is very clear: no one has any real problem to implement the >new transform, however they will not do that as long as there is another >one that is *officially* required by the IPSEC standard. What is the patent status of this MAC function? (I don't think anyone would want to have an "oh, by the way" patent problem) -Craig Received: from relay.tis.com by neptune.TIS.COM id aa29765; 29 Feb 96 18:27 EST Received: by relay.tis.com; id SAA29204; Thu, 29 Feb 1996 18:29:07 -0500 From: hugo@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma029200; Thu, 29 Feb 96 18:28:39 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA14934; Thu, 29 Feb 96 18:27:35 EST Received: by relay.tis.com; id SAA29197; Thu, 29 Feb 1996 18:28:38 -0500 Message-Id: <199602292328.SAA29197@relay.tis.com> Received: from watson.ibm.com(129.34.139.4) by relay.tis.com via smap (V3.1) id xma029194; Thu, 29 Feb 96 18:28:25 -0500 Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 7425; Thu, 29 Feb 96 18:29:04 EST Date: Thu, 29 Feb 96 18:22:30 EST To: cmetz@inner.net Cc: ipsec@TIS.COM Subject: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward Sender: ipsec-request@neptune.tis.com Precedence: bulk Ref: Your note of Thu, 29 Feb 1996 18:16:57 -0500 (attached) > From: Craig Metz > > In message <199602292133.QAA26653@relay.tis.com>, you write: > >What I want is that implementations *do* move to this new function. > >We are doing a lot of implementation work regarding IPSEC, and we talk > >to many other implementation people involved with IPSEC. > >The message is very clear: no one has any real problem to implement the > >new transform, however they will not do that as long as there is another > >one that is *officially* required by the IPSEC standard. > > What is the patent status of this MAC function? > > (I don't think anyone would want to have an "oh, by the way" patent > problem) > > -Craig Thanks for asking. This construction has NOT been patented. (I made this statement clear during the Dallas' IETF). It is as free as any other keyed hash function (we heard in Dallas IETF -- see minutes -- that Novel may have a patent on keyed hash functions in general. I do not know any details or what the status of that is). Hugo Received: from relay.tis.com by neptune.TIS.COM id aa00207; 29 Feb 96 18:47 EST Received: by relay.tis.com; id SAA29407; Thu, 29 Feb 1996 18:49:37 -0500 From: hugo@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma029404; Thu, 29 Feb 96 18:49:09 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA15508; Thu, 29 Feb 96 18:48:05 EST Received: by relay.tis.com; id SAA29401; Thu, 29 Feb 1996 18:49:07 -0500 Message-Id: <199602292349.SAA29401@relay.tis.com> Received: from watson.ibm.com(129.34.139.4) by relay.tis.com via smap (V3.1) id xma029399; Thu, 29 Feb 96 18:49:00 -0500 Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 7675; Thu, 29 Feb 96 18:49:43 EST Date: Thu, 29 Feb 96 18:31:34 EST To: perry@piermont.com Cc: ipsec@TIS.COM Subject: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward Sender: ipsec-request@neptune.tis.com Precedence: bulk Ref: Your note of Thu, 29 Feb 1996 16:54:52 -0500 (attached) There is so much traffic in this list these days and I hate contributing more but this may interest other people in addition to Perry. Perry writes: > hugo@watson.ibm.com writes: > > We need to find a way to break this loop. I don't care about the word > > "replace" just about making clear that IPSEC-AH REQUIRES HMAC > > (as the default implementation). > > Thats fine, so long as we don't speak of "replacing", and so long as > we take some time to allow people to examine the transform. I would > want to see some considerable time taken between the time that an HMAC > based RFC is issued and the time it is advanced. No personal slight > intended, Hugo, but I've learned at this point that the only way to > get certainty out of cryptographers is to wait a year or two for the > dust to settle thoroughly. I fully believe your statements that no one Waiting 1-2 years is unrealistic for IETF proposals. However, I wish there was a more orderly scrutiny of security designs for IETF protocols by cryptographers. Photuris is a good example. It took me 6 drafts (from 03 to 09) to convince Simpson to derive *independent* key bits for keyed-MD5 and DES. Photuris still directly signs secret information which is a clearly wrong cryptographic practice. Photuris confuses between MAC keys and data. It does not handle key refreshment in a satisfactory way. It uses unconstrained strings like SPI's as nonces, and incurs in some other cryptographic sins. I didn't see where is the cryptographic community that is inspecting this design. It is actually very hard for cryptographers that are not directly involved with this work to analyze these protocols in the implementation-oriented way that they are written. They should be accompanied by a clear protocol describing the basic flows and cryptographic rationale. But they are not. What we did with HMAC is far more sound cryptographicaly as well as for analysis, for presentation, and for exposure to cryptographers. Moreover, notice that we have very clear proofs of security. That means that there are no heuristics involved in the MAC construction except the minimal and unavoidable assumptions that you need from MD5 (or your favorite hash function). I wish I could always come with such strong arguments for other cryptographic construction that I propose or use. > > As a general note: if we can't modify the standards during the > > standarization process why do we have that process in place. > > We can alter what is standard. However, it is often bad to alter what > already exists. When SMTP got revised, an extensions mechanism was > created -- existing SMTPs weren't broken. Sometime soon it will be > required that SMTP implementations support ESMTP, but it will > doubtless be a long while before ESMTP is totally universal, if > ever. I repeat this very clearly. In my opinion (and I hope people will agree and even say it ;-) NOW is the time to move to the new transform, and, if possible, forget about the previous one. Having two around will only create confusion and interoperability problems. Hugo Received: from relay.tis.com by neptune.TIS.COM id aa00453; 29 Feb 96 19:01 EST Received: by relay.tis.com; id TAA29722; Thu, 29 Feb 1996 19:03:28 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma029712; Thu, 29 Feb 96 19:03:04 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA15773; Thu, 29 Feb 96 19:01:59 EST Received: by relay.tis.com; id TAA29706; Thu, 29 Feb 1996 19:03:01 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma029701; Thu, 29 Feb 96 19:02:49 -0500 Received: from puli.cisco.com by interlock.ans.net with SMTP id AA02736 (InterLock SMTP Gateway 3.0 for ); Thu, 29 Feb 1996 19:03:49 -0500 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.8+c/8.6.5) with SMTP id QAA23756; Thu, 29 Feb 1996 16:03:47 -0800 Message-Id: <199603010003.QAA23756@puli.cisco.com> To: ipsec@ans.net, perry@piermont.com, bill.simpson@cc.umich.edu Subject: technical clarification request to RFC-1828. Date: Thu, 29 Feb 1996 16:03:47 -0800 From: Paul Traina Sender: ipsec-request@neptune.tis.com Precedence: bulk The last thing I feel like doing is stepping into the war over 1828, however I do have a technical concern with regard to the specification of a compliant implementation. I apologise for missing the last call on this document, at the time I was not involved in this area of standards. This is purely a technical clarification, I make no judgements about the appropriateness of the protocol. My issue is entirely based upon what I consider to be an inadequate specification of the padding of the initial key. To my "trained" implementors eye, it's not at all clear from the RFC, and in fact, I had to speak to someone who implemented it correctly at the bake-off who received additional information from Bill. (read: I looked at the NRL code) The RFC does not mis-specify the method of padding, merely it specifies it inadequately. Given that with the additional information, the compliant implementation became obvious, I would request the that the working group insure the clarity of future revisions of 1828. I think some simple pseudo-code would be enough, as long as the "revision" to the RFC1323 MD5Final routine was *strongly* noted. Given that the group seems to be in a war about 1828 and other recently released drafts, now is as good a time as any to nail down some technical details. Sigh, Paul ----------------------------------------------------------------------------- Details: My inadequate interpretation of 1828 caused the following code to be written (the MD5 routines are the canonical ones from 1323): /* * md5_rfc1828 * * User-friendly way to compute keyed MD5 authentication information for * a chunk of data. * * Call it like this: * * char hash[MD5_LEN]; * md5_rfc1828(message, msglength, key, strlen(key), hash, sizeof(hash)); */ #define FILL_LEN 64 /* 512 bit boundaries for fill */ #define MOD_LEN 56 /* pad key to bit 448 modulo 512 */ boolean md5_rfc1828 (void *data, int datalen, char *key, int keylen, uchar *digest, int digestlen) { static uchar padding[FILL_LEN] = { 0x80, 0 }; MD5_CTX context; int padlen; if (digestlen < MD5_LEN) return FALSE; padlen = keylen % FILL_LEN; padlen = padlen < MOD_LEN ? MOD_LEN - padlen : (FILL_LEN+MOD_LEN) - padlen; MD5Init(&context); MD5Update(&context, key, keylen); MD5Update(&context, padding, padlen); MD5Update(&context, data, datalen); MD5Update(&context, key, keylen); MD5Final(digest, &context); return TRUE; } whereas the correct implementation would be: boolean md5_rfc1828 (void *data, int datalen, char *key, int keylen, uchar *digest, int digestlen) { MD5_CTX context; if (digestlen < MD5_LEN) return FALSE; MD5Init(&context); MD5Update(&context, key, keylen); RFC_1828_MD5Final(NULL, &context); /* do padding according to 1828 */ MD5Update(&context, data, datalen); MD5Update(&context, key, keylen); MD5Final(digest, &context); return TRUE; } void RFC_1828_MD5Final (unsigned char *digest, /* message digest */ MD5_CTX *context) /* context */ { unsigned char bits[8]; unsigned int index, padLen; /* Save number of bits */ Encode(bits, context->count, 8); /* * Pad out to 56 mod 64. */ index = (unsigned int) ((context->count[0] >> 3) & 0x3f); padLen = (index < 56) ? (56 - index) : (120 - index); MD5Update(context, PADDING, padLen); /* Append length (before padding) */ MD5Update(context, bits, 8); | if (digest) { /* change to allow RFC1828 padding */ | /* Store state in digest */ | Encode(digest, context->state, 16); | | /* | * Zeroize sensitive information. | */ | MD5_memset((POINTER) context, 0, sizeof(*context)); | } } Received: from relay.tis.com by neptune.TIS.COM id aa01856; 29 Feb 96 20:52 EST Received: by relay.tis.com; id UAA00539; Thu, 29 Feb 1996 20:54:28 -0500 From: smb@research.att.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma000535; Thu, 29 Feb 96 20:54:03 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA17601; Thu, 29 Feb 96 20:52:56 EST Received: by relay.tis.com; id UAA00532; Thu, 29 Feb 1996 20:53:58 -0500 Message-Id: <199603010153.UAA00532@relay.tis.com> Received: from ns.research.att.com(192.20.225.4) by relay.tis.com via smap (V3.1) id xma000529; Thu, 29 Feb 96 20:53:28 -0500 Received: from research.att.com by ns; Thu Feb 29 20:51:50 EST 1996 Received: from gryphon by research; Thu Feb 29 20:48:54 EST 1996 Received: by gryphon; Thu Feb 29 20:48:50 EST 1996 To: perry@piermont.com Cc: hugo@watson.ibm.com, ipsec@TIS.COM Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward Date: Thu, 29 Feb 96 20:48:49 EST Sender: ipsec-request@neptune.tis.com Precedence: bulk hugo@watson.ibm.com writes: > We need to find a way to break this loop. I don't care about the wor d > "replace" just about making clear that IPSEC-AH REQUIRES HMAC > (as the default implementation). Thats fine, so long as we don't speak of "replacing", and so long as we take some time to allow people to examine the transform. I would want to see some considerable time taken between the time that an HMAC based RFC is issued and the time it is advanced. No personal slight intended, Hugo, but I've learned at this point that the only way to get certainty out of cryptographers is to wait a year or two for the dust to settle thoroughly. I fully believe your statements that no one who has seen your work has had any trouble with it, but recall that similar statements were made the last time around -- it would be better if we gave it some time. This isn't to say we should advance something else in its place, you understand. It is just to say we should be more carefull. Of course, all along the unanimous opinion of the cryptographic theoreticians has been that keyed hash functions were an unknown -- they weren't designed to do that, and it wasn't clear that they were secure in this mode. But we went ahead anyway. > As a general note: if we can't modify the standards during the > standarization process why do we have that process in place. We can alter what is standard. However, it is often bad to alter what already exists. When SMTP got revised, an extensions mechanism was created -- existing SMTPs weren't broken. Sometime soon it will be required that SMTP implementations support ESMTP, but it will doubtless be a long while before ESMTP is totally universal, if ever. Right. And if ESMTP had been proposed way back when, before RFC821 was officially blessed, it would have been a different matter. If we're going to change it, now is the time. We should certainly use a different transform number for HMAC, to make the transition easier, but we should have only one full standard. RFC1828 is a ``Proposed Standard''. Let me quote from RFC1880, the current instantiation of STD 1: 4.1.3. Proposed Standard Protocol These are protocol proposals that may be considered by the IESG for standardization in the future. Implementation and testing by several groups is desirable. Revision of the protocol specification is likely. Note carefully: revision is *likely*. If we're going to change it, now is the time -- after it goes to Draft, it's too late for fixes of this nature (absent, say, the discovery of a feasible attack). Received: from relay.tis.com by neptune.TIS.COM id aa01962; 29 Feb 96 20:57 EST Received: by relay.tis.com; id UAA00607; Thu, 29 Feb 1996 20:59:28 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma000603; Thu, 29 Feb 96 20:59:01 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA17705; Thu, 29 Feb 96 20:57:56 EST Received: by relay.tis.com; id UAA00593; Thu, 29 Feb 1996 20:58:58 -0500 Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1) id xma000585; Thu, 29 Feb 96 20:58:45 -0500 Received: from jekyll.piermont.com by interlock.ans.net with SMTP id AA04418 (InterLock SMTP Gateway 3.0 for ); Thu, 29 Feb 1996 20:59:47 -0500 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) with SMTP id UAA19307; Thu, 29 Feb 1996 20:58:25 -0500 (EST) Message-Id: <199603010158.UAA19307@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: "PALAMBER.US.ORACLE.COM" Cc: ipsec@ans.net Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward In-Reply-To: Your message of "29 Feb 1996 13:36:29 PST." <199602292154.NAA18059@mailsun2.us.oracle.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Thu, 29 Feb 1996 20:58:20 -0500 From: "Perry E. Metzger" Sender: ipsec-request@neptune.tis.com Precedence: bulk "PALAMBER.US.ORACLE.COM" writes: > >but I disagree with the words "replace". As Paul's survey > >reveals, many implementations currently implement 1828. > > There has been very strong support for the use of HMAC as the "standard" > transform for AH. A "change" of this mechanism sooner, rather than later, > would limit the impact on implementors. Fine, but that doesn't necessarily mean "replace". Perry Received: from simon.cs.cornell.edu by neptune.TIS.COM id aa02255; 29 Feb 96 21:13 EST Received: from cloyd.cs.cornell.edu (CLOYD.CS.CORNELL.EDU [128.84.227.15]) by simon.cs.cornell.edu (8.6.10/R1.4) with ESMTP id VAA14615 for ; Thu, 29 Feb 1996 21:15:56 -0500 Received: from gilling.cs.cornell.edu (GILLING.CS.CORNELL.EDU [128.84.254.180]) by cloyd.cs.cornell.edu (8.6.10/M1.8) with ESMTP id VAA18815; Thu, 29 Feb 1996 21:15:53 -0500 From: Lewis McCarthy Received: (lew@localhost) by gilling.cs.cornell.edu (8.6.10/C1.3) id VAA10324; Thu, 29 Feb 1996 21:15:43 -0500 Message-Id: <199603010215.VAA10324@gilling.cs.cornell.edu> Subject: Re: technical clarification request to RFC-1828. To: ipsec@neptune.tis.com Date: Thu, 29 Feb 1996 21:15:42 -5300 (EST) In-Reply-To: <199603010003.QAA23756@puli.cisco.com> X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2281 Sender: ipsec-request@neptune.tis.com Precedence: bulk Paul Traina writes: > My issue is entirely based upon what I consider to be an inadequate > specification of the padding of the initial key. [...] > The RFC does not mis-specify the method of padding, merely it specifies it > inadequately. [..] > I think some simple pseudo-code would be enough, as long as the "revision" > to the RFC1323 MD5Final routine was *strongly* noted. (I went digging through a stack of papers before I realized you meant 1321 :) OK, so essentially you seem to be suggesting a clarification (in the RFC) of the following phrasing in Section 2 of 1828: "First, the variable length secret authentication key is filled to the next 512-bit boundary, using the same pad with length technique defined for MD5." How about rephrasing it as: "...512-bit boundary, using the padding technique defined in subsections 3.1 and 3.2 of the MD5 specification [RFC-1321]." I think that makes the method clear, since the relevant parts of MD5Final are conveniently separately numbered in 1321. Would pseudo-code still be preferable in addition to (or instead of) rephrasing like this ? Just to add fuel to the fire, I think the discussion of key length in 1828, subsection 1.1, could stand slight revision. In particular, I think the last sentence "Longer keys are encouraged." is ambiguous. Certainly, longer keys up to 128 bits in length should be encouraged versus shorter keys. But as I understand things, the security of this envelope construction is not increased by using a key with more than 128 bits of entropy, since MD5 only generates a 128-bit hash. (This is already reflected to some extent in the 1828 Security Considerations section, where the van Oorschot/Wiener MD5 supercollider is discussed.) If the key is only pseudorandom, however, then length(key) > 128 may be desirable to ensure at least 128 bits of entropy are present. The Security Considerations section already notes that the specification's security depends on the strength of MD5 and "the strength of the key". I am proposing a more explicit acknowledgement that keys longer than 128 bits are only helpful under certain assumptions about their non-randomness, as a result of the other two considerations. -Lewis (until mid-May)